[EPEL-devel] Re: arch-specific package in CS10 blocking EPEL 10 request

[Petr Pisar]

V Wed, Sep 04, 2024 at 09:15:23AM +0100, Paul Howarth napsal(a):
> I got a request to build rgb for EPEL 10
> (https://bugzilla.redhat.com/show_bug.cgi?id=2309102), which is not
> surprising as I did the same for EPEL 9. A local test build of that package
> failed due to a missing dependency of 'pkgconfig(xorg-macros)', so
> I requested an EPEL 10 build of xorg-x11-util-macros to resolve that
> (https://bugzilla.redhat.com/show_bug.cgi?id=2309121).
> 
> That package request was then declined:
> 
>   fedpkg request-branch epel10
>   Could not execute request_branch: This package is already an EL
>   package, therefore it cannot be in EPEL. If this is a mistake
> 
> Looking at the compose metadata, it appears that xorg-x11-util-macros
> is in CRB, but only for the aarch64 architecture.
> 
> So, my questions are:
> 1. Is this intentional (seems unlikely, given that this is fundamental
> to building just about anything using xorg-x11), and

EPEL can barely answer this. You should open a ticket for CentOS Stream at
 against "RHEL" project and "xorg-x11-util-macros"
component.

> 2. If this *is* intentional, what should be done to facilitate building
> rgb and similarly-affected packages in EPEL?
> 
I guess a procedure for missing binary packages

applies here. You import xorg-x11-util-macros sources under
"xorg-x11-util-macros-epel" name and disable building on aarch64, maybe
changing the package from noarch to fullarch will be necessary.

-- Petr



signature.asc
Description: PGP signature
-- 
___
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: dnf failing to pull from epel - HTTP 404

[Petr Pisar]

V Tue, Apr 11, 2023 at 12:04:21PM -, Deon W napsal(a):
> Hello! 
> 
> For about the last 24 hours, all my RHEL server have been choking on any dnf
> commands, because of a HTTP 404 error on the mirror it's pulling from. It's
> trying to hit this URL, but the page doesn't exist
> -  
> [https://mirrors.kernel.org/fedora-epel/8/Everything/x86_64/repodata/1ab76d70e07a54428243e0698ef38d6aeacfb9dc4367654dc4e094fa020a0bea-filelists.xml.gz].
> 
> When I look at repomd.xml,
> 1ab76d70e07a54428243e0698ef38d6aeacfb9dc4367654dc4e094fa020a0bea is listed,
> but the link does indeed point to a 404. When I check other mirrors like
> epel.mirror.digitalpacific.com.au, the same behaviour is replicated
> - reference is in the repomd.xml but the actual content is missing from the
> repo.
> 
A canonical source for the mirrors is
.
repomd.xml there has revision 1681174565 (i.e. 2023-04-11T00:56:05+00:00).
That location references filelists file that exists.

mirrors.kernel.org' repo.xml has revision 1681001231
(2023-04-09T00:47:11+00:00) indeed with a missing filelists file. I don't know
what's the casue, but I guess once the mirror catches the canonical source,
everything will work again for you.

-- Petr


signature.asc
Description: PGP signature
___
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 8 Modules get the axe on Halloween 2022

[Petr Pisar]

V Mon, Oct 10, 2022 at 12:54:44PM -0500, Carl George napsal(a):
> One of the biggest problems with modularity in EPEL is the our current
> implementation doesn't allow requiring modules from another build
> system [0][1].  Has some other third party implementation solved this?
>  And more importantly, do any third party modules exist that require
> EPEL modules?
> 
I was told that there are companies which build and deploy
their own modules. I have no other datails. Especially whether their modules
depend on EPEL modules.

A special example are RHEL rebuilds. E.g. Oracle can reproduce RHEL modules,
including dependencies, with exact name-stream-version-context-architecture
string
.

However, I think this problem is of topic now. If EPEL and MBS people were
able to tackle it they wouldn't call off modules from EPEL.

-- Petr


signature.asc
Description: PGP signature
___
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 8 Modules get the axe on Halloween 2022

[Petr Pisar]

V Fri, Oct 07, 2022 at 08:56:41AM -0400, Stephen Smoogen napsal(a):
> On Fri, 7 Oct 2022 at 03:34, Petr Pisar  wrote:
> 
> > V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> > > - epel-release will be updated.
> > > -- epel-modular will set enabled = 0
> >
> > Does it only mean releasing a new epel-release package with epel-modular
> > configuration file set to "enabled = 0", or does it also involve more magic
> > like editing that configuration with RPM scriptlets.
> >
> > I ask because configuration files edited by a user are not subject of RPM
> > updates. rpm tool installs updated files under a new file name and keeps
> > the original intact, effectively unupdated.
> >
> >
> My original thought was turning if off for new users, but I am realizing
> because we defined it to be on by default.. we will be breaking existing
> users. Thanks for questioning my logic as it was wrong.
>
Just confirming that epel-release dist-git reads:

$ grep yum.repos.d/epel-modular.repo  epel-release.spec 
%config(noreplace) %{_sysconfdir}/yum.repos.d/epel-modular.repo

To some extent, it won't break existing users:

Those who have never enabled any EPEL module stream will not miss the content.
They will stop seeing the modules. And that's what we want.

Those who have enabled an EPEL stream because installed packages from it will
stop seeing the EPEL repository. But they will still keep seeing the enabled
streams because DNF backed them up at time of enablement and will present them
as a "@failsafe" repository. These users will be able to inspect and reset
(= unenable) the streams. Though they won't be able to install or reinstall
packages from the stream because DNF does not back up the RPM packages.
I think that's, to some extent, what we want.

Those who have enabled some third-party streams which depend on an EPEL stream
got the EPEL stream also enabled as a dependency. Hence they will be in the
same situation as users from the previous paragraph. However, if the
third-party stream enrolls an update which will require installing a new
package (or enabling a new EPEL stream) they will get a dependency error.
This is an unfortunate situation. We only can recommend to the third-party
supplier to start delivering the stream which has been removed from EPEL.

> There are 2 emailing lists. One of them ate the email that troy sent a
> while ago and held it versus accepting it. I have kicked the server and
> hopefully it gets sent now. That said we need to fix the communication and
> update it for better dates.
> 
Great. The announce list is a low traffic enough so that user reading Troy's
message can panic at the intended level.

> We thought of rebuilding all of the existing modules with an updated
> deprecated somewhere in the data, but since many of them are just branched
> for each release it looked like we would instead say the module was
> deprecated in existing Fedora releases. I expect there is a way to do this,
> but I have no idea what it would break.
> 
Yeah. The sources are shared across all distributions. I wouldn't dare
injecting builds for EPEL8 only. MBS has its own pecularities as it concerns
expanding existing streams resolving the latest module version and that could
affect building depending modules in Fedora.

> > I worry that users do not follow a list called epel-devel because they
> > think
> > it's only for EPEL developers. As such this change will come to them as
> > a surprise.
> >
> >
> There used to be an epel-users list but about 8 real people subscribed to
> it versus N hundred spam accounts. We turned it off after most of the posts
> were needing to be deleted or the few questions being asked were never
> being answered because the developers were not on it.
> 
It's a pitty DNF cannot deliver news to users based an installed package.

DNF only can deliver security news based on a fixed package. And to make it
worse, that feature is unreliable for modular packages because it does not
transport a stream name.

-- Petr


signature.asc
Description: PGP signature
___
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 8 Modules get the axe on Halloween 2022

[Petr Pisar]

V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> - epel-release will be updated.
> -- epel-modular will set enabled = 0

Does it only mean releasing a new epel-release package with epel-modular
configuration file set to "enabled = 0", or does it also involve more magic
like editing that configuration with RPM scriptlets.

I ask because configuration files edited by a user are not subject of RPM
updates. rpm tool installs updated files under a new file name and keeps
the original intact, effectively unupdated.

> October 31 2022:
> - The EPEL 8 modules will be archived and removed.

Does EPEL have any communication channel to EPEL users besides this mailing
list? If it does, do you plan to announce this change there? Preferably ahead
of time.

I worry that users do not follow a list called epel-devel because they think
it's only for EPEL developers. As such this change will come to them as
a surprise.

-- Petr


signature.asc
Description: PGP signature
___
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: Qt update and packages rebuild

[Petr Pisar]

V Tue, Oct 04, 2022 at 10:17:34AM +0200, Germano Massullo napsal(a):
> As I wrote in
> https://bugzilla.redhat.com/show_bug.cgi?id=2129662#c11
> I did not know that epel packages are used also in CentOS Stream, sometimes
> causing issues like the one previously mentioned.
> 
> In fact this behaviour obliges epel maintainers that wanted to maintain RHEL
> only, to work to maintain CentOS Stream too.
> This an additional source of troubles for package maintainers

I guess this strategy was selected

because most EPEL packages keep working in CentOS Stream. Hence EPEL-next
delivers only the few execptions which need a rebuild/patch.

Originally when RHEL 9 did not exist, EPEL-next was a completly separate
repository, but EPEL maintainers were forgetting to build (and debug) for
EPEL-next, hence EPEL-next became completely useless. Thus EPEL-next was
repurposed as an overlay for EPEL.

While EPEL maintainers might see EPEL-next as a nuisance, they should realize
that what's CentOS Stream now, will become RHEL in 6 months. If their EPEL
package breaks in CentOS Stream now, it will become broken in RHEL in
6 months. Ignoring CentOS Stream only postpones an inevitable maintenance
work. I think EPEL maintainers should rather perceive EPEL-next the same way
as Fedora maintainers handle Rawhide.

The only problem is that there is no automatic move of EPEL-next packages to
EPEL after the 6 months. A maintainer needs to repeat the work in EPEL and, if
possible, to remove the unnecessary EPEL-next build manually
.

-- Petr


signature.asc
Description: PGP signature
___
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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9

[Petr Pisar]

V Wed, Aug 31, 2022 at 05:08:59PM -0400, Stephen Smoogen napsal(a):
> When EPEL-8 was launched, it came with some support for modules with the
> hope that a module ecosystem could be built from Fedora packages using RHEL
> modules as an underlying tool. This has never happened and we have ended up
> with a muddle of modular packages which will 'build' but may not install or
> even run on an EL-8 system. Attempts to fix this and work within how EPEL
> is normally built have been tried for several years by different people but
> have not worked.
> 
> At this point it is time to say this experiment with modules in EPEL has
> not worked and focus resources on what does work. I would like to propose
> that modular support is removed from EPEL by January 2023.
> 
> Steps:
> 1. Approval of this proposal by the EPEL Steering committee and any other
> ones required.
> 2. Announcement of end of life to various lists.
> 3. Archiving of the modules on XYZ date to
> /pub/archive/epel/8.-MM/Modular and pointing mirrormanager to that for
> that
> 4. Make changes in bodhi to turn off reporting about modules for EL8.
> 5. Make changes in MBS configs to turn off building modules for EL8.
> 6. Make changes in PDC for EL8 modules
> 7. Make changes in compose scripts and tools to no longer cover EPEL-8
> modules
> 8. Remove epel-8 modules from /pub/epel/8
> 9. Announce closure of this proposal and any lessons learned.
> 
I heard a concern what to do with systems which use EPEL modules. What will
happen after the modules disappear from EPEL repositories?

Thanks to fails-safe machanism in DNF, the metadata for enabled module streams
will be preserved in DNF's local copy. Thus users who have installed the
modules will have them visible in "dnf module list" output even after removing
them from EPEL repository. So far good.

Someone proposed that EPEL should actively try to disable the EPEL modules.
Miro mentioned that the Fedora already did it once

by editing DNF configuration from an RPM scriptlet.

Question is whether EPEL should do it. If EPEL did it, users would lose their
modules and, I think, DNF would start mixing modular and nonmodular packages.
That could cause problems when upgading those systems. One would need to
perform "dnf distrosync --allowerasing" to repair the system.

There could also be a problem if RHEL decided to deliver a module stream with
an identical name. EPEL would then keep disabling the RHEL module.

I believe it's safer not to actively disable the streams on user's systems.

What we could do is write a notice about the end of life into the module
summaries and rebuild the modules. That way users running "dnf module list"
could see the message. But people upgrading after the module removal wouldn't
see anything. We would have keep to modular repository available forever.
Probably the idea of the notice is not worth of it. 

Any opinions how to deal with obsoleting the installed modules?
What currently does EPEL when a maintainer decides to drop a (nonmodular)
package?

-- Petr


signature.asc
Description: PGP signature
___
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: [action required (urgent) ] [Bug 2095649] Error Install ImageMagick and Imagemagick-perl together on RH8 (EPEL8 repository)

[Petr Pisar]

V Sun, Jun 12, 2022 at 12:29:06AM +0100, Sérgio Basto napsal(a):
> On Sat, 2022-06-11 at 17:25 +, bugzi...@redhat.com wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2095649
> 
> Hi, 
> for some reason the build on epel 8 to update ImageMagick-6.9.12 from
> 48 to 50 (
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1972114 ) 
> used  perl-libs-4:5.32.1-471.module+el8.6.0+13324+628a2397 from I guess
> modules repo

Interesting. I'm courious how it could happen. DNF rejects installing modular
packages if they are not listed in a defintion of a module stream. So either
somebody enabled perl:5.32 stream explicitly (improbable), or mock
repositories in Koji are configured with module_hotfixes=true which is alarming.

Koji configuration confirm the other theory:

$ koji mock-config -a x86_64 --target epel8-candidate | grep module_hotfixes
config_opts['yum.conf'] = 
'[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
 
repos\n\n[build]\nname=build\nbaseurl=https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64\nmodule_hotfixes=1\n'

I recommend Koji maintainers to add and use RHEL repositories next to
epel8-build with EPEL8 packages:

[build]
name=build
baseurl=https://kojipkgs.fedoraproject.org/repos/epel8-build/4655904/x86_64

[rhel-AppStream]
name=rhel-AppStream
baseurl=WHEREVER_FEDORA_TAKES_RHEL8_PACKAGES_FROM

-- Petr



signature.asc
Description: PGP signature
___
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: Rhel 9 + Epel 9 - Amavis can't install

[Petr Pisar]

V Wed, May 18, 2022 at 06:49:48AM -0400, Josh Boyer napsal(a):
> On Wed, May 18, 2022 at 6:21 AM Filip Bartmann  wrote:
> >
> > Hello,
> > I try to install amavis in epel for RedHat 9 Stable:
> >
> > dnf install amavis
> > Updating Subscription Management repositories.
> > Last metadata expiration check: 0:02:16 ago on Wed 18 May 2022 12:16:52 PM 
> > CEST.
> > Error:
> >  Problem: conflicting requests
> >   - nothing provides perl(Net::LibIDN) needed by amavis-2.12.2-3.el9.noarch
> > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to 
> > use not only best candidate packages)
> > It want's package Net::LibIDN, but it was not found. How can I install 
> > amavis for RHEL 9?
> 
> The perl-Net-LibIDN package will need to be built for EPEL 9.
> 
It's a known issue since February
. I wish rpmdeplint tests
were performed for EPEL packages
, too.

-- Petr


signature.asc
Description: PGP signature
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Petr Pisar]

V Fri, Mar 11, 2022 at 09:36:08AM +, Richard W.M. Jones napsal(a):
> On Fri, Mar 04, 2022 at 11:14:31AM +, Richard W.M. Jones wrote:
> > On Fri, Mar 04, 2022 at 11:01:20AM +, Richard W.M. Jones wrote:
> > > On Fri, Mar 04, 2022 at 10:51:48AM +, Richard W.M. Jones wrote:
> > > > I'll see if we can move the OCaml packages to CRB.  It seems to be the
> > > > easiest way to fix the original coccinelle build problem.
> > > 
> > > This gets odder.  I see from our internal spreadsheet and downloads
> > > that some of the ocaml packages are in fact already in CRB for RHEL
> > > 9.0, and others are not.  We previously requested that all ocaml-*
> > > packages be added to CRB.
> > > 
> > > Binary packages which are not in CRB but should be:
> > > 
> > > ocaml-calendar*
> > > ocaml-camomile*
> > > ocaml-csexp*
> > > ocaml-csv*
> > > ocaml-curses*
> > > ocaml-dune*
> > > ocaml-fileutils*
> > > ocaml-gettext*
> > > ocaml-libvirt*
> > > ocaml-source
> > > ocaml-xml-light*
> > > 
> > > Do you need a BZ opened to move these packages to CRB?
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2060850
> 
> Currently even with this bug fixed we won't be able to build
> Coccinelle until RHEL 9.1 is released, which is like 9+ months away.
> This (if true) is ridiculous.  Is there some other solution?
> 
That's not ridiculous. That's a release cadence of RHEL.

Maybe you could use EPEL 9 Next which is based on CentOS Stream 9. There is
the change already visible
. However,
I'm not sure whether EPEL 9 Next is still a thing.

-- Petr


signature.asc
Description: PGP signature
___
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] Guidelines for adding subpackages not shipped by RHEL

[Petr Pisar]

Hello,

I happened to hit a request for adding web-assets-devel binary package of
web-assets component to EPEL 9 (bug #2036086) while web-assets-filesystem
binary package is shipped in RHEL. I recall it is allowed, but ones need to
follow some rules which I cannot find now.

Current Packaging guide lines
 do not document
this particular case. The closest one is adding missing architectures (Limited
Arch Packages section).

Do you know the rules for adding the missing subpackages?

I remember that release number needs to be kept lower.
What about component (source package) name. Can I use reuse it, or do we need
to rename it to keep Koji happy in case it has imported CentOS builds?
I guess I should disable subpackages already shipped by RHEL.

-- Petr


signature.asc
Description: PGP signature
___
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: Building EPEL-8 package depending on module

[Petr Pisar]

V Mon, Sep 06, 2021 at 09:10:30AM -0400, Stephen John Smoogen napsal(a):
> On Mon, 6 Sept 2021 at 07:07, Petr Pisar  wrote:
> > V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> > > 2. What is the right approach to build the package that depends on 
> > > modules?
> > >
> > The right approach for building a package that depends on a non-default 
> > stream
> > is building it as another module.
> >
> 
> Sadly that doesn't work either in the Koji system, because MBS does
> not see those modules as belonging to anything it has built. So it
> seems it can only depend on modules which it has built .. So not only
> do we have to build this tool as a module, we also have to build
> pki-deps:10.6 locally.
>
I see. <https://pagure.io/fm-orchestrator/issue/1653> hasn't been touch for
a year.

-- Petr



signature.asc
Description: PGP signature
___
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: Building EPEL-8 package depending on module

[Petr Pisar]

V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> I am trying to build a package for EPEL-8.
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=75036069)
> 
> The build fails with
> 
> No matching package to install: 'glassfish-jaxb-api'
> No matching package to install: 'jaf'
> Not all dependencies satisfied
> Error: Some packages could not be found.
> 
> "glassfish-jaxb-api" and "jaf" are available in AppStream modules "pki-deps" 
> and "jmc".
> 
> 1. Why can't these packages be found? I thought koji auto-resolves/flattens 
> the modules.
> 
Koji only flattens default module streams. Those are flagged with "[d]" in
"dnf module list" output. Those streams are "enabled" by default and therefore
Koji flattens them. Other streams must be explicitly enabled with "dnf module
enable module:stream" and Koji does not flatten them.

glassfish-jaxb-api belongs to pki-deps:10.6 stream (as found by "dnf module
provides glassfish-jaxb-api" command).

pki-deps:10.6 is not a default stream (as reported by "dnf module list
pki-deps"; compare to "dnf module list php").

Therefore Koji does not flatten pki-deps:10.6 module stream and its packages
are not available in an EPEL build root.

Why is not the stream default? (Even if it's the only pki-deps stream.)
Because it's an internal dependency for pki-core:10.6 stream perhaps not
intended for other use.

> 2. What is the right approach to build the package that depends on modules?
>
The right approach for building a package that depends on a non-default stream
is building it as another module.

Please note that due to Fedora policies
 your new module
can't be made default one. Hence if you decide for creating "xstream"
module, your users will have to install xstream with "dnf module install
xstream" (or "dnf module enable xstream && dnf install xstream").

Another option is to skip all the modular things and repackage
glassfish-jaxb-api in EPEL as any other missing package. This is explictly
allowed for packages from RHEL non-default streams
.

-- Petr


signature.asc
Description: PGP signature
___
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: Planning for EPEL9

[Petr Pisar]

V Thu, Jul 08, 2021 at 05:24:05AM -0400, Neal Gompa napsal(a):
> On Thu, Jul 8, 2021 at 5:19 AM Petr Pisar  wrote:
> >
> > V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> > > On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
> > > >
> > > > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > > > Also, people who wish to opt out of this mass rebuild can add
> > > > > 'noautobuild' file to the epel9-next branch beforehand, this however
> > > > > does not stop from creating the epel9 branch, just the package won't
> > > > > be included in the rebuild.
> > > >
> > > > I think there are 3 possible opt outs here:
> > > >
> > > > 1) The epel9-next packager does not intent to maintain the package in 
> > > > epel9,
> > > > only in epel9-next. While we might not like this goes, as long as there 
> > > > is no
> > > > policy against this approach, always creating the branch will create 
> > > > work for
> > > > the packager they have not signed for. I think there should be an opt 
> > > > out for
> > > > branching as well.
> > > >
> > >
> > > This is not a valid use-case.
> >
> > Why?
> >
> > If you were a CentOS user who moved to CentOS Stream, then you are going to
> > use epel9.next. You have no use of epel9.
> >
> 
> That is not the point of epel-next. It's only intended to be a overlay
> for resolving issues between RHEL minor releases (or in this case,
> bootstrapping before RHEL major releases are actually out).
> 
> EPEL-next is usually layered on top of EPEL, not the other way around.
> I'm proposing we layer EPEL on EPEL-next just long enough to do a mass
> rebuild cycle to populate EPEL9, then revert to the normal setup.
> 
I see. So if you are a CentOS Stream user, you need use both epel9 and
epel9-next.

In that case the EPEL 8 Next annoucement
<https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/UYBLBN7WRCGKZZ3KY2SDFU63BDRD5FDL/>
was quite misleading. Especially without reading the linked Wiki page.

DNF should acquire dependencies among repositories. I saw so many EPEL bug
reports explained by missing powertools repository. The history will repeat.

-- Petr


signature.asc
Description: PGP signature
___
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: Planning for EPEL9

[Petr Pisar]

V Thu, Jul 08, 2021 at 04:47:33AM -0400, Neal Gompa napsal(a):
> On Thu, Jul 8, 2021 at 4:41 AM Miro Hrončok  wrote:
> >
> > On 08. 07. 21 2:28, Mohan Boddu wrote:
> > > Also, people who wish to opt out of this mass rebuild can add
> > > 'noautobuild' file to the epel9-next branch beforehand, this however
> > > does not stop from creating the epel9 branch, just the package won't
> > > be included in the rebuild.
> >
> > I think there are 3 possible opt outs here:
> >
> > 1) The epel9-next packager does not intent to maintain the package in epel9,
> > only in epel9-next. While we might not like this goes, as long as there is 
> > no
> > policy against this approach, always creating the branch will create work 
> > for
> > the packager they have not signed for. I think there should be an opt out 
> > for
> > branching as well.
> >
> 
> This is not a valid use-case.

Why?

If you were a CentOS user who moved to CentOS Stream, then you are going to
use epel9.next. You have no use of epel9.

-- Petr


signature.asc
Description: PGP signature
___
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: Where should branch requests be filed?

[Petr Pisar]

V Wed, Jul 07, 2021 at 06:33:51PM -0700, Michel Alexandre Salim napsal(a):
> I'm working on a tool to make it easier to create EPEL branch requests
> in the case where there are transitive dependencies that also need to
> be branched.
> 
> I'm basing it on 
> https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
> which provides some guidelines and some templates; however, it is a bit
> vague on some aspects, namely:
> 
> which product and component should the bug be filed against?
> 
> I've been using Fedora/rawhide (with the FutureFeature keyword) if the package
> has never been branched for EPEL before, and 'Fedora EPEL' / epelX (where X is
> the branch requested) if it has, however, I can't find a written document 
> where
> this is recommended, though I thought I've read it somewhere in the past.
> 
> If I can simply use Fedora/rawhide, this would simplify the tool a lot:
> - we can almost always assume there is a {'product: 'Fedora', 'component': 
> srpm}
>   with some rare exceptions e.g. the srpm is in base CentOS but has missing
>   subpackages (see recent discussion on the topic)
> - if the package is branched for EPEL at some point, we can file the request
>   against {'product': 'Fedora EPEL', 'component': srpm}. But what version to 
> file
>   against?
>   - bpython: https://bugzilla.redhat.com/show_bug.cgi?id=1782782
> phoronix-test-suite: https://bugzilla.redhat.com/show_bug.cgi?id=1976280
> these are the ideal cases; the request is for an 'epel8' branch and 
> 'epel7' and
> 'epel8' are listed as available versions, so the request was filed 
> against 'epel8'
>   - nextcloud-client: https://bugzilla.redhat.com/show_bug.cgi?id=1972910
> this is a request for 'epel8-next', but that is not available as a product
> 
> The tool will thus need to query Bugzilla to locate the component on either
> Fedora EPEL or Fedora, and then figure out what versions are listed; from my
> initial experimentation with python-bugzilla: 
> https://github.com/python-bugzilla/python-bugzilla
> this does not seem trivial.
> 
> If filing against Fedora/rawhide is fine, I can edit the wiki to match. It 
> should
> probably also mention that the EPEL Packagers SIG group can be added as a 
> co-maintainer,
> but I'll experiment with the wording first when testing the tool.
> 
The algorithm for filing bugs is complicated because there are Fedora
maintainers who do not want to deal with EPEL. If I were one of them I would
feel offended that I'm getting requests for EPEL 8 if there is already EPEL 7
maintainer.

I want to say you should bite the bullet and implement it in the complicated
way.

-- Petr


signature.asc
Description: PGP signature
___
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: Planning for EPEL9

[Petr Pisar]

V Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa napsal(a):
> On Wed, Jul 7, 2021 at 8:28 PM Mohan Boddu  wrote:
> > While we are already working on epel9-next enablement, there was a
> > discussion about how to handle epel9 when rhel9 goes GA. It is safe to
> > assume that a lot of the builds that are already in epel9-next at that
> > point of time should work on rhel9.
[...]
> > Couple of questions that need to be answered here:
> > 1. Is 5 times of rebuilds good enough or do we need more?
> > 2. Do the mass rebuild builds have to go through bodhi or can we just
> > directly tag them for stable compose?
> >
> > Any suggestions appreciated.
> >
> 
> This is very exciting!
> 
> However, question here: At least for the bootstrap for RHEL 9 GA,
> couldn't we use the EPEL9 next buildroot to rebuild everything once
> instead of rebuilding 5 times?

That would be indeed helpful when dealing with build cycles. Because whatever
times you attempt to rebuild them without changing their spec files (or spec
macros), you won't succeed.

On the other hand it arises a problem with disappearing (build-)required
packages whose maintainer requested noautobuild after uninheriting epel9-next
builds. (E.g. you would get epel9 packages that you cannot build again.)
But that should not be a big problem because mismatches between those two
requiring and required packages would appear even in the original approach.
Only later. And naturally, maintainers would have to cooperate and agree
wheter to keep or remove both of the packages.

Maybe one could do the mass rebuild twice. The second one without epel9.next
builds to verify that epel9 is self-contained. The scratch rebuilds would do
either.

-- Petr


signature.asc
Description: PGP signature
___
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: anyone knows why perl in epel8 give me a lot of "security" errors ?

[Petr Pisar]

V Wed, May 26, 2021 at 10:30:54AM +0100, Sérgio Basto napsal(a):
> fedpkg clone debhelper
> cd debhelper
> fedpkg srpm && mock -r epel-8-x86_64  --no-clean --rebuild debhelper-
> 13.3.4-1.fc35.src.rpm 
> 
> I can build the package in _all_ others branches but

In epel7 too?

> in epel8 ends with
> "Initialization of state variables in list context currently forbidden
> at /builddir/build/BUILD/debhelper-
> 13.3.4/lib/Debian/Debhelper/Dh_Lib.pm line 2021, near");" "
> 
perl has a "splain" tool which explains the compiler errors and warnings:

$ splain
/usr/bin/splain: Reading from STDIN
Initialization of state variables in list context currently forbidden at 
/home/test/fedora/debhelper/debhelper-13.3.4/lib/Debian/Debhelper/Dh_Lib.pm 
line 2021, near ");"
Initialization of state variables in list context currently forbidden at

/home/test/fedora/debhelper/debhelper-13.3.4/lib/Debian/Debhelper/Dh_Lib.pm 
line 2021, near ");" (#1)
(F) state only permits initializing a single scalar variable, in scalar
context.  So state $a = 42 is allowed, but not state ($a) = 42.  To apply
state semantics to a hash or array, store a hash or array reference in a
scalar variable.

What do we have at the line 2021?:

state %rrr = map { $_ => 1 } split(' ', $rrr_env);

That's it. perl 5.26.3 does not support "state" declaration for hashes (%err).
Here is a one-line reproducer:

$ perl -e 'use v5.24; sub foo {state %rrr = map { $_ => 1 } split(q{ }, q{});}'
Initialization of state variables in list context currently forbidden at -e 
line 1, near ");"
Execution of -e aborted due to compilation errors.

Which can be reduced to:

$ perl -e 'use v5.24; state %rrr = ();'
Initialization of state variables in list context currently forbidden at -e 
line 1, near ");"
Execution of -e aborted due to compilation errors.

Please note that the "use v5.24;" statement is taken from debhelper code.
It's obviously an upstream bug. The code is not valid syntax for perl 5.24.

The state support for non-scalar types was implemented in Perl 5.28.0 (see
"perldoc perl5280delta" command output):

  Initialisation of aggregate state variables
A persistent lexical array or hash variable can now be initialized, by
an expression such as "state @a = qw(x y z)". Initialization of a list
of persistent lexical variables is still not possible.

You should reach out depbhelp upstream to correct the "use v5.24;" into "use
v5.28;". Or you can ask them to refactor the code to support perl 5.26.

If you insist on using that debhelper version on RHEL-8, you can try switching
to perl:5.30 module stream which delivers Perl 5.30.1. But you will have to
rebuild most of the dephelper dependencies for the new perl yourself. (Because
EPEL support for modules is, ehm, mostly undefined and unhelpful.)

-- Petr



signature.asc
Description: PGP signature
___
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 - thoughts and timings

[Petr Pisar]

On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
> I think that could be workable, but I'll toss out another proposal:
> 
> As soon as centos 9 stream exists, we create epel9-playground and allow
> people to branch/add packages to it. Once rhel9 is GA, we setup epel9 as
> usual and epel9-next and point epel9-next to build against stream and
> playground to build against rhel9. 
>
Do you know what CentOS 9 Stream will look like between its first availability
and RHEL 9 GA? I worry that there will surface RHEL 9.1 changes. Then
switching epel9-playground from CentOS 9 Stream to RHEL 9 could manifest
incompatibilities as the build root would regress.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: How do I request an update to ddclient for EL7?

[Petr Pisar]

On Fri, Jan 08, 2021 at 09:11:57AM +, Nick Howitt wrote:
> How do I request an update to ddclient for EL7? It looks like EL8 has moved
> to the forked version, 3.9.1, but EL7 is stuck on the old un-forked version
> of 3.8.3-2 which had its development stopped in 2015. I need a later version
> as Cloudflare's API changed after 2015.
> 
File a request for the upgrade against EL7 ddclient at
.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: missing libc++ (libcxx-devel) in EPEL 8

[Petr Pisar]

On Mon, Oct 12, 2020 at 10:12:09AM +0300, Alexandru Lazarev wrote:
> In EPEL 7 there is such rpm (libcxx-devel - it seems from EPEL repository),
> but in EPEL 8 it isn't.
> 
> How is it possible to have it there as RPM?

Report the request into Bugzilla against "Fedora EPEL" product and "libcxx"
component. I cannot see that it has ever been requested
.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Fast-moving packages in EPEL

[Petr Pisar]

On Sun, Oct 11, 2020 at 02:18:26PM +0200, Christopher Engelhard wrote:
> One thing I forgot that makes things even worse:
> 
> - upstream does not support updates across more than one major version,
> so anybody who actually has the old v10 installed will have their
> installation completely broken by ANY update at this point
> - for the same reason, trying to limit major updates to whenever
> CentOS/RHEL release a new version won't work either.
> 
RHEL releases a minor version every six months. And as I remember, EPEL8
allows breaking upgrades at each new RHEL release. Thus technically, it's
possible to rebase the package every year without getting into conflict with
packaging guidelines. On the other hand, I'm not sure whether the users know
it and expect it.

> I think I'll retire and look into re-adding it via modularity.
> 
You could package each new incompatible version into a separate module stream
and keep maintaining only the latest one. This way the users could switch
to the newer stream whenever they feel comfortable. If they slip switching
to the latest stream, then can migrate any later by hopping through all the
intermediary streams up to the latest one. That could be even automated by
a script.

There is a downside of the modules: There is no mechanism for tracking the
latest stream automatically. DNF team is willing to implement the mechanism,
but so far it's only a conception. It's also dubious whether the new mechanism
would be ported back to RHEL 8. So far users have to switch the streams
manually.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: proposal: EPEL 8 Next

[Petr Pisar]

On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> To solve this problem, I am proposing that we create a new repository called
> EPEL 8 Next.
> 
> - built against CentOS 8 Stream
> - opt-in for packagers (must request epel8-next dist-git branch)
> - opt-in for users (part of epel-release but disabled by default)
> - used *with* epel8, not *instead of*
> 
I agree with all of that. I only don't like the name. Why EPEL 8 Next? If it
is to be use with Stream, why don't we call it EPEL 8 Stream? I think the
meaning of the repository would be easier to understand.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: python2-jsonschema update

[Petr Pisar]

On Thu, Sep 03, 2020 at 08:21:38AM +, TREHIOU Paul wrote:
> I am using the python2-jsonschema package but noticed it is out of date on
> EPEL (2.5.1). On Fedora the latest version is available (3.2.0). Is it
> possible to backport the latest Fedora version into EPEL ?
> 
I recommend you to follow a similar request in Bugzilla
.

> This message and any attachments are confidential and intended for the named
> addressee(s) only.

This mailing list is public. Do not send confidentatial messages here.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Soname bump of libb2 on F31/EPEL7

[Petr Pisar]

On Wed, May 27, 2020 at 05:22:04PM -0400, Mukundan Ragavan wrote:
> Scratch build of gtkhash does not appear to pull in libb2-0.98.1. Has
> the buildroot override expired?
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=45077601
> 
It did not expire:

$ bodhi overrides query --builds libb2-0.98.1-2.fc31

 libb2-0.98.1-2.fc31

  Submitter: fschwarz
  Expiration Date: 2020-05-29 00:00:00
  Notes: updating borgbackup due to libb2 update
  Expired: False


Use the following to ensure the override is active:

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31

1 overrides found (1 shown)

So what libb2 build is in the build root?

$ koji wait-repo f31-build --build=libb2-0.98.1-2.fc31
Warning: nvr libb2-0.98.1-2.fc31 is not current in tag f31-build
  latest build in f31-build is libb2-0.98-4.20171225git60ea749.fc31
^C


How is it possible? What happened with the libb2-0.98.1-2.fc31 build:

$ koji list-history --build libb2-0.98.1-2.fc31
Fri May 22 20:48:12 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by sagitter
Fri May 22 20:54:19 2020 libb2-0.98.1-2.fc31 tagged into f31-signing-pending by 
bodhi
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 untagged from f31-signing-pending 
by autopen
Fri May 22 20:54:36 2020 libb2-0.98.1-2.fc31 tagged into 
f31-updates-testing-pending by autopen
Fri May 22 23:00:35 2020 libb2-0.98.1-2.fc31 tagged into f31-override by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-candidate by bodhi
Sat May 23 04:51:56 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-testing by 
bodhi
Sat May 23 04:52:04 2020 libb2-0.98.1-2.fc31 untagged from 
f31-updates-testing-pending by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-updates-testing 
by bodhi
Tue May 26 15:15:47 2020 libb2-0.98.1-2.fc31 untagged from f31-override by bodhi
Tue May 26 15:15:48 2020 libb2-0.98.1-2.fc31 tagged into f31-updates-candidate 
by bodhi [still active]

It was untagged from override by bodhi user on 2020-05-26. That's 3 days before 
the
expiration. It looks like a bug in Bodhi service.

You can try to submit it into override again.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Wed, May 20, 2020 at 09:03:39AM +0100, Paul Howarth wrote:
> What host system are you running that on?

x86_64 Fedora 31 with updates-testing enabled.

After mock finishes bootstrapping DNF, it installs buildrooot and just before
it, it enables the modules:

Complete!
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.2
INFO: Mock Version: 2.2
Start: dnf install
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   499 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.0 MB/s | 7.0 MB 00:06
CentOS-8 - PowerTools   
   516 kB/s | 2.0 MB 00:03
CentOS-8 - Extras   
   6.5 kB/s | 5.9 kB 00:00
epel
   555 kB/s | 6.6 MB 00:12
Dependencies resolved.
===
 Package  ArchitectureVersion   
RepositorySize
===
Enabling module streams:
 mariadb  10.3  
  
 mariadb-devel10.3  
  

Transaction Summary
===

Complete!
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
11 kB/s | 3.9 kB 00:00
CentOS-8 - AppStream
11 kB/s | 4.3 kB 00:00
CentOS-8 - PowerTools   
   9.9 kB/s | 4.3 kB 00:00
CentOS-8 - Extras   
   3.5 kB/s | 1.5 kB 00:00
epel
   4.4 kB/s | 4.7 kB 00:01
epel
   726 kB/s | 6.6 MB 00:09
Dependencies resolved.
===
 Package  ArchitectureVersion   
  Repository  Size
===
Installing:
 bash x86_64  4.4.19-10.el8 
  BaseOS 1.5 M

After installing the buildroot, it installs the Judy-devel package.

I cannot speak much about a mock configuration, because I had my own changes
in the defaults.cfg and site-defaults.cfg, but when mock introduced the
templates I thrown my configuration away. I don't have any changes in
epel-8-x86_64.cfg and the templates.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Wed, May 20, 2020 at 08:10:42AM +0200, Petr Pisar wrote:
> Now you can ask why enabling mariadb-devel:10.3 does not enable mariadb:10.3
> automatically. Especially when mariadb-devel:10.3 run-requires mariadb:10.3
> according to "dnf module info mariadb-devel:10.3" command. The answer is a bug
> in DNF. I think I recall the bugs has already been fixed, but apparantly it's
> still (or again) there.
> 
https://bugzilla.redhat.com/show_bug.cgi?id=1837841

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> On Tue, 19 May 2020 09:07:30 -0400
> Stephen John Smoogen  wrote:
> 
> > On Tue, 19 May 2020 at 06:05, Paul Howarth  wrote:
> > 
> > > On Mon, 18 May 2020 22:29:54 -0600
> > > Orion Poplawski  wrote:
> > >  
> > > > On 5/17/20 6:34 AM, Paul Howarth wrote:  
> > > > > I'm trying to do a local build of gtkwave for EPEL-8.
> > > > >
> > > > > A koji scratch build somehow works:
> > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
> > > > >
> > > > > But a local build does not:
> > > > >
> > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
> > > > > ...
> > > > > Error:
> > > > >   Problem: conflicting requests
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
> > > > > excluded
> > > > >
> > > > > Adding a repo with a local build of Judy doesn't help; that gets
> > > > > excluded too.
> > > > >
> > > > > Any clues?
> > > > >
> > > > > Paul.  
> > > >
> > > > Judy-devel appears to be part of the mariadb-devel module.
> > > > Locally I can do:
> > > >
> > > > dnf module enable mariadb-devel
> > > > dnf install Judy-devel
> > > >
> > > > This was discovered with:
> > > >
> > > > dnf module provides Judy-devel
> > > >
> > > > on RHEL 8.2, though that does not appear to work on CentOS 8.1.
> > > >
> > > > For mock, this seems to work:
> > > >
> > > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel
> > > > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm  
> > >
> > > I tried that and it didn't make any difference for me (building on
> > > F-31). Maybe I need to wait for CentOS 8.2?
> > >
> > >  
> > Hmm do you have the Powertools enabled in that Mock? I see Judy-devel
> > in the CentOS-8.1 tree in Powertools.
> 
> Yes, I'm using vanilla configs straight from mock-core-configs for
> this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> which has the PowerTools repo defined and not disabled.
> 
> (I generally use my own configs and don't touch the original ones, so I
> know that if I try the original ones from upstream then they should
> work as intended)
> 
> Note that the error message doesn't say it can't find Judy-devel, it
> says that it (and Judy) is/are excluded. I don't know why that is.
> 
The message means that the Judy-devel package exists in a repository, but is
not available for an installation, because a module it belongs to is not
active (i.e. not enabled nor default). The correct procedure is enable
the module it belongs to.

"dnf module provides Judy-devel" command returns mariadb-devel:10.3 module.
After enabling that module you get another error message that Judy package is
excluded. That's because Judy package belongs to mariadb:10.3 module. You also
need to enable that module. Then it works. It also works in mock:

$ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel --config-opts 
module_enable=mariadb install Judy-devel
[...]
INFO: installing package(s): Judy-devel
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   539 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.3 MB/s | 7.0 MB 00:05
CentOS-8 - PowerTools   
   442 kB/s | 2.0 MB 00:04
CentOS-8 - Extras   
   5.7 kB/s | 5.9 kB 00:01
epel
   5.2 kB/s | 4.7 kB 00:00
Dependencies resolved.
===
 PackageArchitecture   Version  
  Repository  Size
===
Installing:
 Judy-devel x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   PowerTools   
   76 k
Installing dependencies:
 Judy   x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   AppStream
  131 k

Transaction Summary
===
Install  2 Packages
[...]
Installed:
  Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64  
Judy-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 

Compl

[EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Sat, May 16, 2020 at 11:43:00AM +0200, Antonio Trande wrote:
> On 15/05/20 14:57, Stephen Gallagher wrote:
> > On Fri, May 15, 2020 at 7:57 AM Petr Pisar  wrote:
> >>
> >> On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> >>> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> >>>
> >>>> On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> >>>>> Shortly (Martin is in Cc to confirm):
> >>>>>
> >>>>> 1) Make a module:
> >>>>>
> >>>>> $ fedpkg clone cmake3
> >>>>> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> >>>>> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> >>>>>
> >>>> This will request for creating "cmake3-latest" module and "cmake3-latest"
> >>>> repository and "epel8" stream and "epel8" branch. I don't know if you
> >>>> really
> >>>> want to create "cmake3-latest:epel8" module stream.
> >>>>
> >>>
> >>> Since this is a module, is there any point in using the cmake3 namespace
> >>> over just cmake?
> >>>
> >> I cannot see any point. Maybe if there were cmake-2 or cmake-4 
> >> incompatible to
> >> cmake-3 but installable in parallel, then it would make sense. (Like 
> >> Python.)
> >> Because you cannot install more streams of the same module at the same 
> >> time.
> >> Otherwise I would also go with plain "cmake" module name.
> > 
> > 
> > It turns out, cmake already has a presence[1] in the modules namespace
> > of dist-git. It is a relic of the Modularity 1.0 effort, but it's
> > already there and that will make this easier.
> 
> Petr, can you take care of this module for epel8, too?
> 
I cannot because of a lack of time and interest in CMake. But I can transfer
an ownership of the module to whoever wants it. Also please note that at that
time CMake bundled various libraries and a second build-only cmake-bootstrap
module was needed to build the cmake module properly. I will include it into
the gift.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 06:30:04AM -0500, Richard Shaw wrote:
> On Fri, May 15, 2020 at 6:15 AM Petr Pisar  wrote:
> 
> > On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> > > Shortly (Martin is in Cc to confirm):
> > >
> > > 1) Make a module:
> > >
> > > $ fedpkg clone cmake3
> > > $ fedpkg request-repo --namespace modules --exception cmake3-latest
> > > $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> > >
> > This will request for creating "cmake3-latest" module and "cmake3-latest"
> > repository and "epel8" stream and "epel8" branch. I don't know if you
> > really
> > want to create "cmake3-latest:epel8" module stream.
> >
> 
> Since this is a module, is there any point in using the cmake3 namespace
> over just cmake?
> 
I cannot see any point. Maybe if there were cmake-2 or cmake-4 incompatible to
cmake-3 but installable in parallel, then it would make sense. (Like Python.)
Because you cannot install more streams of the same module at the same time.
Otherwise I would also go with plain "cmake" module name.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Documentation for EPEL modules?

[Petr Pisar]

On Fri, May 15, 2020 at 12:42:15PM +0200, Antonio Trande wrote:
> Shortly (Martin is in Cc to confirm):
> 
> 1) Make a module:
> 
> $ fedpkg clone cmake3
> $ fedpkg request-repo --namespace modules --exception cmake3-latest
> $ fedpkg request-branch --namespace modules --repo cmake3-latest epel8
> 
This will request for creating "cmake3-latest" module and "cmake3-latest"
repository and "epel8" stream and "epel8" branch. I don't know if you really
want to create "cmake3-latest:epel8" module stream.

In Fedora, a name of a module must match the name of the repository, and
a name of a stream must match the name of the branch.

(Technically, it's possible to diverge, but Fedora's infrastructure enforces
it.)

If what you want is "cmake3:latest" module stream, then you need:

$ fedpkg request-repo --namespace modules cmake3
$ fedpkg request-branch --namespace modules --repo cmake3 latest

Also please note that modules undergo a review. So for a new module, you need
an approved review first and the "--exception" argument should not be used.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Updating CMake in EPEL-8: How to create a module?

[Petr Pisar]

On Fri, May 15, 2020 at 08:58:21AM -, Alexander Korsunsky wrote:
> Hi there,
> 
> the version of CMake that is currently packaged with RHEL/CentOS 8 is 3.11,
> which is becoming more and more outdated. Me (and a few other people,
> judging by bug report participation) would quite like to have a newer
> version of CMake on their systems.
> 
> Now, if I understand correctly, according to the EPEL policies,
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy, it is
> prohibited to replace packages from the base distribution. It is, however,
> allowed to replace these packages in modules that are not enabled by
> default.
> 
> Unfortunately, nobody really seems to know how to build modules for EPEL.
> There is documentation for Fedora:
> https://docs.fedoraproject.org/en-US/modularity/making-modules/ . However,
> being not very familiar with modularity, I have no clue which parts of the
> documentation apply to EPEL, and I could not find EPEL-specific
> documentations and recommendations. I have seen some threads on this list
> *discussing* these, but it's hard for me to discern the consensus and best
> practices from mailing list threads.
> 
> Would the Modularity magicians be so kind as to reply with some pointers on
> how to create modules for EPEL? If that already exists, my apologies, I hope
> you can direct me to that resource.
> 
I replied to the same question yesterday on Fedora devel list
.
 

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

[Petr Pisar]

On Tue, May 05, 2020 at 04:00:28PM +0200, Petr Pisar wrote:
> On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
> > On Tue, May 5, 2020 at 12:23 AM Petr Pisar  wrote:
> > >
> > > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> > > > I have not created any bugzila's for these yet.  I have not checked to
> > > > see if these are in -testing already.  This is just a list showing
> > > > what packages currently do not install from EPEL 7.
> > > >
> > > > perl-Image-SubImageFind
> >   - nothing provides libMagickCore.so.5()(64bit) needed by
> > perl-Image-SubImageFind-0.03-1.el7.x86_64
> >   - nothing provides libMagick++.so.5()(64bit) needed by
> > perl-Image-SubImageFind-0.03-1.el7.x86_64
> > 
> > > > perl-X11-GUITest
> > perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind),
> > but none of the providers can be installed
> > 
> > >
> > > I can install these two packages. They were built 6 years ago. Can you 
> > > provide
> > > more details.
> > >
> > 
> > If you are running RHEL or CentOS 7.8 then you cannot install them due
> > to the updated ImageMagick.
> > 
> I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to
> install them because RHEL does not remove old packages from repositories and
> my package manager simply chose the older compatible build (because I did not
> have installed ImageMagick before).
> 
> > It looks like you just need to rebuild perl-Image-SubImageFind and
> > both packages should be able to install.
> > 
> I will rebuild them.
> 
Fixed with perl-Image-SubImageFind-0.03-2.el7.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

[Petr Pisar]

On Tue, May 05, 2020 at 06:35:14AM -0700, Troy Dawson wrote:
> On Tue, May 5, 2020 at 12:23 AM Petr Pisar  wrote:
> >
> > On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> > > I have not created any bugzila's for these yet.  I have not checked to
> > > see if these are in -testing already.  This is just a list showing
> > > what packages currently do not install from EPEL 7.
> > >
> > > perl-Image-SubImageFind
>   - nothing provides libMagickCore.so.5()(64bit) needed by
> perl-Image-SubImageFind-0.03-1.el7.x86_64
>   - nothing provides libMagick++.so.5()(64bit) needed by
> perl-Image-SubImageFind-0.03-1.el7.x86_64
> 
> > > perl-X11-GUITest
> perl-X11-GUITest-0.28-1.el7.x86_64 requires perl(Image::SubImageFind),
> but none of the providers can be installed
> 
> >
> > I can install these two packages. They were built 6 years ago. Can you 
> > provide
> > more details.
> >
> 
> If you are running RHEL or CentOS 7.8 then you cannot install them due
> to the updated ImageMagick.
> 
I see. ImageMagick-6.9.10.68 released in RHEL 7.8 broke ABI. But I was able to
install them because RHEL does not remove old packages from repositories and
my package manager simply chose the older compatible build (because I did not
have installed ImageMagick before).

> It looks like you just need to rebuild perl-Image-SubImageFind and
> both packages should be able to install.
> 
I will rebuild them.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: EPEL 7 packages that fail to install on RHEL / CentOS / SL 7.8

[Petr Pisar]

On Mon, May 04, 2020 at 09:11:00AM -0700, Troy Dawson wrote:
> I have not created any bugzila's for these yet.  I have not checked to
> see if these are in -testing already.  This is just a list showing
> what packages currently do not install from EPEL 7.
> 
> perl-Image-SubImageFind
> perl-X11-GUITest

I can install these two packages. They were built 6 years ago. Can you provide
more details.

The only issue with them I can see is that they were retired in Fedora master.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Broken %python_provide macro for Koji's epel8-playground target?

[Petr Pisar]

On Thu, Apr 30, 2020 at 12:32:26PM -0700, Michel Alexandre Salim wrote:
> Generally speaking (I can make this a separate thread if that helps) - do we
> expect every package in EPEL8 to also be built for EPEL8-playground, either
> through package.cfg or by building directly from the epel8-playground
> branch?

There is no such rule, but in my opinion, it is welcomed for exactly the 
terrible
experience anybody gets when he tries to use epel8-playground.

The purpose of epel8-playground is to diverge when needed. That's why the epel8
branch contains package.cfg by default.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: epel8-playground target ignores build overrides?

[Petr Pisar]

On Tue, Apr 28, 2020 at 09:22:56PM -0700, Michel Alexandre Salim wrote:
> My epel8 build for python-extras succeeded just fine (using python-testtools
> from a build override as a dependency -
> https://bodhi.fedoraproject.org/overrides/python-testtools-2.4.0-3.el8), but
> the epel8-playground build claims python-testtools is not available:
> 
> epel8:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1499241
> 
> epel8-playground:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43889481
> 
> DEBUG util.py:600:  No matching package to install: 'python3-testtools'
> DEBUG util.py:600:  Not all dependencies satisfied
> DEBUG util.py:600:  Error: Some packages could not be found.
> 
> Does the playground setup not take overrides into account?
> 
playground is an independent build target and thus overrides in epel8 and
epel8-playground are independent. But you don't need to create overrides in
epel8-playground because builds there appears in a build root automatically
on next repository regeneration.

However, your problem is not in overrides. Your problem is that
python-testtools package has never been successfully built for
epel8.playground: 

https://koji.fedoraproject.org/koji/packageinfo?packageID=11850

That's probably because of Carl George  deleted the
package.cfg configuration from epel8 branch to mirror the builds into
epel8-buildroot:

commit dd46fcc88a92241e2aa776208cf7ef0dddbab541
Author: Carl George 
Date:   Fri Apr 24 01:06:33 2020 -0500

Revert ""Adding package.cfg file""

This reverts commit 6a8c5775eb802cc8acfb93dfbe7e00d8e92a24a3.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Wed, Mar 11, 2020 at 06:52:12AM -0700, Troy Dawson wrote:
> On Wed, Mar 11, 2020 at 1:25 AM Petr Pisar  wrote:
> >
> > I can only see a small ambiguity regarding build-only packages that are
> > filtered out of the module. I believe the rule about the module names should
> > not apply for these filtered packages.
> >
> 
> If they are filtered out of the module, then end users cannot see
> and/or use them.
> If that is the case, they are fair game for EPEL, and I believe (but
> haven't checked)  that packagers already should be able to request
> them.

I thought so.

> Is there a particular package you know about that I could check?
> 
There can barely be any now because there are no modules in EPEL yet. And you
cannot see any of the filtered packages in RHEL because they are not
distributed to repositories (except the few -devel modules).

> > But that leads me to a question about -devel modules. RHEL delivers some
> > -devel modules in a CRB repository. These -devel modules consists of the
> > filtered packages. Is EPEL going to mimic these -devel modules, or not?
> >
> 
> Can you give an example of a -devel package in CRB that is from a
> package that is filtered from a module?

RHEL-8.1.1:

# dnf module list | grep -e -devel
mariadb-devel10.3 
MariaDB Module  
virt-devel   rhel 
Virtualization module   
virt-devel   rhel 
Virtualization module  

E.g. virt-devel:rhel:8010020190916153839 contains
qemu-kvm-tests-15:2.12.0-88.module+el8.1.0+4233+bc44be3f.x86_64 package.

RHEL-8.2 Beta brings python38-devel:3.8 module.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Tue, Mar 10, 2020 at 02:13:22PM -0700, Troy Dawson wrote:
> We propose adding:
> 
>   In EPEL 8 or later, it is permitted to have module streams which contain
>   packages with alternate versions to those provided in RHEL. These packages
>   may be newer, built with different options, or even older to serve
>   compatibility needs. These MUST NOT be the default stream -- in every
>   case, explicit user action must be required to opt in to these
> versions.  If the
>   RHEL package is in a RHEL module, then the EPEL module must have the same
>   name as the RHEL module.  Any exceptions to the module name must be
>   approved by the EPEL Steering Committee.
> 
That's a reasonable proposal.

I can only see a small ambiguity regarding build-only packages that are
filtered out of the module. I believe the rule about the module names should
not apply for these filtered packages.

But that leads me to a question about -devel modules. RHEL delivers some
-devel modules in a CRB repository. These -devel modules consists of the
filtered packages. Is EPEL going to mimic these -devel modules, or not?

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Thu, Feb 13, 2020 at 07:54:24AM -0500, Matthew Miller wrote:
> I've been saying this for a while as if it's fact, but of course it's not
> actually fact until approved, so I'm puting this to the EPEL team to
> hopefully do so.
> 
> The current guidelines * say:
> 
>EPEL packages should only enhance and never disturb the Enterprise Linux
>distributions they were built for. Thus packages from EPEL should never
>replace packages from the target base distribution - including those on the
>base distribution as well as layered products; kernel-modules further are
>not allowed, as they can disturb the base kernel easily.
> 
> With modularity in EPEL 8, we have the opportunity to allow more flexibility
> while preserving the primary goal of not disturbing the base distribution.
> Therefore, I propose adding:
> 
>   In EPEL 8 or later, it is permitted to have module streams which contain
>   packages with alternate versions to those provided in RHEL. These packages
>   may be newer, built with different options, or even older to serve
>   compatibility needs. These MUST NOT be the default stream -- in every
>   case, explicit user action must be required to opt in to these versions.
> 
> 
> (Note that the base package _does not_ have to be part of a module for this
> to work.)
> 
> What do you think?
> 
> 
Nicely and clearly stated.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Sat, Feb 15, 2020 at 07:15:55PM -0700, Ken Dreyer wrote:
> On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller  
> wrote:
> >
> >   In EPEL 8 or later, it is permitted to have module streams which contain
> >   packages with alternate versions to those provided in RHEL. These packages
> >   may be newer, built with different options, or even older to serve
> >   compatibility needs. These MUST NOT be the default stream -- in every
> >   case, explicit user action must be required to opt in to these versions.
> 
> Is there any chance that a module in EPEL 8 will be named identically
> to a module in RHEL 8? If that happens, what is the process to choose
> between RHEL's module and EPEL's module?
> 
> This is not entirely hypothetical :) We face this situation if we
> consider putting Ceph into a module in RHEL 8 and a module in EPEL 8.
> 
This was discussed in fall last year without any conclusion. There was
a proposal force all EPEL streams having a prefix (e.g "epel-") to prevent
from clashes.

In my opinion the situation with same named streams is similar to situation
with same named packages. If RHEL is going to add new package that already
exists in EPEL, RHEL uses an higher NEVRA of the package and EPEL will remove
the package later. You can do the same with module streams.

Module streams also have versions. The version is based on a RHEL version and
a time when the module was built. That itself ensures incrasing stream
versions. But that's not enough to ensure an upgrade path on package level.

The reason is that if a stream is enabled, all of its versions that exist in
the repositories are inspected and all of their packages are made available. 
That
means that if a RHEL repository contains multiple versions of a stream, then
DNF will see all the historical packages. That would apply to EPEL
repositories too.

A solution is that RHEL will ensurure that each package of the stream will
have an higher NEVRA than the EPEL one. See it's the same as with non-modular
packages. The only difference is that you need account more packages than the
usual one.

The only remaining issue is what to do with packages that existed in EPEL
repository but were not added into RHEL repository. Well, technically it does
not matter that there is an old package.

When it would matter is when RHEL decided to add the package as non-modular
one and at the same time the RHEL stream would be a default one. Then DNF
would prefer the old modular package because the stream is default now. EPEL
could solve it by removing the old module from its repositories. But what if
the the user had already have the package from EPEL stream installed. In that
case, I believe, I'm not sure how exactly DNF implements it, DNF would kept
considering the package as modular because DNF cashes modular metadata of
installed packages for the case when a repository becomes unavailable.

A long term solution is DNF to support obsoleting modular packages by
non-modular packages or handling end-of-life streams better. As far as I know
this has not yet been designed, neither implemented.

So the bottom line is: Prefixed streams should provide a bullet proof
mitigation. Until DNF gains the ability to obsolete a stream, there will be
slight risk of creeping out-dated EPEL content into the installation.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Sat, Feb 15, 2020 at 05:15:56PM -0500, Matthew Miller wrote:
> On Fri, Feb 14, 2020 at 05:14:31PM -0600, Chris Adams wrote:
> > Unless... does RHEL have modules that replace base packages?  I admit, I
> > haven't fully got my head wrapped around all the effects of modularity.
> 
> I'm not sure if RHEL has any such modules, but it is functionally possible.
>   
There is a perl-DBI module that provides a perl-DBI package that replaces
a base perl-DBI package. There are more modules like that.

It's an alternative approach to the stub streams discussed in this thread.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

[Petr Pisar]

On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > From my also little understanding of modularity, this is so you can
> > reinstall base perl packages. In some ways ( I am glossing over things
> > here), modular rpms always beat bare rpms because a module can put in rules
> > to say 'you can install this package but it does not work with these rpms
> > so they need to be removed'. So I think any modules we write which would
> > over-ride non-modular packages, we would also need to write a 'get me back
> > my f'ing defaults' module which stubs in a similar way the perl and some
> > other modules do.
> 
> No, this is not the case. If the module isn't enabled its packages will just
> be ignored. It's only if you enable the module that you get the RPMs from
> that module.
> 
Exactly. If you want to revert back to a non-modular package, just reset the 
module
(e.g. "dnf module --reset perl"). That will disappear modular packages from
from the repository and make the non-modular packages available again.

Here is a simple explanation what enabling a module stream means: If you
enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a list
of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
makes them available (to dnf install, repoquery etc.) and at the same time
makes the same-named packages (either non-modular or from a different stream
of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
When you reset the module, you effectively reverts it. This process of making
the packages avaiable/unavailable DNF calles a modular filtering.

The purpose of the stub (without packages) perl:5.26 stream is different and
mostly unrelated . It is there to enable having modules above the perl module
in an easy way. Otherwise the layered module maintainers would have take care
whether they target Perl 5.26 that is non modular or Perl 5.24 that is
modular. The dummy perl:5.26 stream provides a unified modular interface to
other modules.

EPEL packagers that want to provide an alternative stream to non-modular
packages are not required to provide the dummy streams. Although the dummy
streams can become handy later for the very same reason. The dummy streams can
added later when needed and when found useful.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Need to get Steering Committee consensus: packages in old modules

[Petr Pisar]

On Mon, Feb 03, 2020 at 02:35:43PM -0500, Stephen John Smoogen wrote:
> My main job is working with Fedora Infrastructure, and we are trying to
> work out how to handle:
> 
> https://pagure.io/fedora-infrastructure/issue/8558
> 
> The problem is that various tools filter what packages can be branched into
> Fedora see that libssh2 was in a module that RHEL shipped in 8.0 but it is
> no longer in the release with 8.1.
> 
> Do we need to make libssh2 a module?
> Should we allow libssh2 be branched as a 'bare' package in EPEL proper?
> Other?
> 
RHEL keeps old packages and old modules in repositories. That means even on
a fresh RHEL 8.1 installation you will get a virt:rhel stream that will
provide the libssh2 package. The package will come from an older virt:rhel
module build.

Because DNF prefers modular packages over bare packages, despite that EPEL
provides libssh2 bare package, the EPEL one will be masked and the modular
RHEL one preferred.

Because virt:rhel is a default stream, the stream is active by default and
thus this modular filter applies by default.

Hence adding a bare libssh2 package to EPEL won't help. EPEL needs to
provide a modular libssh2 package with a higher package NEVRA if the goal is
to overtake the libssh2 package maintenance from RHEL to EPEL.

So far my humble knowledge of DNF. I believe DNF team knows about this
limitation and one of their goals for the future is to make a modular package
obsolescence possible.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: How do I request EPEL packages

[Petr Pisar]

On Tue, Jan 14, 2020 at 08:49:48PM +, Nick Howitt wrote:
> Hi,
> There are a number of fc31 packages I'd like to see in EPEL so I can use
> them for Centos7 for wok-3.0 and kimchi-3.0. Two that I need are:
> python3-libguestfs
> python3-pyparted
> 
> I also possibly need:
> python3-pyparted as the pip module throws a error.
> 
> The ones I'd also like so I can avoid pip are:
> python3-configobj
> python3-magic
> python3-cherrypy
> python3-websockify
> python3-cheetah
> 
> I've found a references for creating the request
> - 
> https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL#The_procedure_for_getting_a_package_in_EPEL
> - and I've created an account on bugzilla. If I try to search for any of the
> packages with Classification=Fedora, Product=Fedora EPEL and
> Classification=name_of_package, none of the packages are listed.

python3-configobj is a name of the binary package. Bugzilla enumarates
packages (components in Bugzilla classification) by source package name. You
can get source package name with this commands:

# dnf --quiet repoquery --source python3-configobj
python-configobj-5.0.6-19.fc32.src.rpm

Now if I search for python-configobj in Bugzilla, I get

listing one bug report about adding the package to EPEL 6 (#1288811). 

If you want python-configobj for EPEL 7, file a bug there. There is "File
a new bug in the "python-configobj" component of the "Fedora EPEL" product"

link on search results. You should set the version fields of the bug report to
epel7 if possible. Otherwise use any version available.

If there is no component in "Fedora EPEL" product, report the bug in "Fedora"
component.

In all cases please make the subject of the bug clear that you want to add
a new package into EPEL 8.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Missing packages in EPEL-8, what can be done about that?

[Petr Pisar]

On Mon, Sep 30, 2019 at 01:59:33PM +0200, fil...@centrum.cz wrote:
> I'm on server using munin software and I notice that this
> package is missing from EPEL for CentOS 8.
> 
> I'm trying to build this package in my local mock from Fedora 31
> package, but it fails on perl dependencies.
> 
> What can I do to cowork on this package to be in EPEL repository.
> 
For each missing dependency, file a request to Fedora Bugzilla. If it existed
in EPEL 7, use "Fedora EPEL" product, if it never existed, use "Fedora"
products and the same Fedora component you are missing. Hopefully former
maintainers will add it into EPEL 8.

You can also become a packager and add and maintain the packages yourself in
the EPEL.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Missing packages in EPEL-8, what can be done about that?

[Petr Pisar]

On Mon, Sep 30, 2019 at 11:45:24AM +, LAHAYE Olivier wrote:
> For docbook-utils-pdf, I don't understand why redhat did drop it, and
> I wonder how can EPEL publish only the missing part without breakage if
> redhat updates the 1st half.

This is the burden of a downstream distributor. You never know what the
upstream breaks.

One way EPEL wants to solve it is repackaging the complete package as
a Modularity module and then providing it to users as a non-default module
stream so that users who need it can explictly enable it and consume the
packages from EPEL instead from CentOS/RHEL.

> For perl-QT, Fedora-30 still ships it: https://pkgs.org/download/perl-Qt 
> (v4.14.3-17), but I know it's not well maintained.

It's there by a mistake. (A late Qt rebase broke it and nobody removed it from
the distribution.) It even cannot be installed.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Missing packages in EPEL-8, what can be done about that?

[Petr Pisar]

On Mon, Sep 30, 2019 at 09:34:27AM +, LAHAYE Olivier wrote:
> Unfortunately, I've discovered with centos-8 that many (I really mean MANY)
> packages have been dropped by redhat

Yes, that happens.

> and epel as well.

EPEL did not drop anything. EPEL for a new RHEL always starts with an empty
repository. Any package appears there must be actively requested and packaged.

> redhat dropped docbook-utils-pdf for example (while keeping docbook-utils)
> which I rely on to build the manual.
>
Either buy a RHEL subscription and report a request to Red Hat, or ask EPEL
packagers to package docbook-utils-pdf from the docbook-utils RHEL sources.

> EPEL-8 has dropped xmlstarlet,

File a request to Fedora Bugzilla for adding it.

> perl-Qt

perl-Qt is deader than a dead horse. It requires other libraries that
cannot be even built and many distributions including Fedora and Debian
removed it. Please use a different GUI toolkit.

-- Petr



signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: epel8-playground and centos-stream?

[Petr Pisar]

On Wed, Sep 25, 2019 at 11:16:57AM -0700, Troy Dawson wrote:
> On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson  wrote:
> >
> > On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher  
> > wrote:
> > >
> > > On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa  wrote:
> > > >
> > > > On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi  wrote:
> > > > >
> > > > > After the announcement today of centos-stream, I wonder if it would 
> > > > > make
> > > > > sense to move epel8-playground to build against that instead of the
> > > > > latest rhel8 release?
> > > > >
> > > > > It would make playground less usefull for testing new radical changes
> > > > > against the current stable point release, but on the other hand, the
> > > > > centos stream will become the next stable point release, so it would
> > > > > allow people to test against that and get changes ready that they 
> > > > > could
> > > > > then push in after the next stable point release landed?
> > > > >
> > > > > What do folks think? Bad idea, good idea?
> > >
> > > I think that makes good sense; it will provide a guarantee of early
> > > notice when an upcoming RHEL release might introduce a problematic
> > > change (intentionally or otherwise) and provides Red Hat with feedback
> > > and an opportunity to fix it before RHEL releases. It will also make
> > > our minor release merge windows easier, since we should not get any
> > > major surprises hitting only at Beta or GA.
> > >
> > > If we decide *not* to do this, I think we need to at least have a
> > > policy of updating the buildroot for EPEL8-playground to include the
> > > RHEL minor release beta tree as a lesser version of the same process
> > > as above.
> > >
> 
> Thinking about this I just realized "Bad Idea"
> Why?
> Because streams is always going to be changing.
> It will be almost impossible to know what buildroot a -playground
> package was built with.
> Also, the playground packages get built, whenever they get built.
> There is not set schedule.
> So a stream update could affect package D, but package D doesn't get
> built for 6 month, so we have no idea whether the stream affects
> Package D or not.
> 
We have
.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Amavisd installation broken

[Petr Pisar]

On Wed, Sep 25, 2019 at 11:02:21AM +0200, fil...@centrum.cz wrote:
> Hello, 
> 
> I try to install amavisd on CentOS 8 and it seems to be broen:
> -
> # yum install amavisd-new
> Failed to set locale, defaulting to C
> Last metadata expiration check: 0:04:35 ago on Wed Sep 25 10:57:02 2019.
> Error: 
>  Problem: conflicting requests
>   - nothing provides perl(Digest::SHA1) needed by
> amavisd-new-2.12.0-1.el8.noarch
>   - nothing provides perl(IO::Stringy) needed by
> amavisd-new-2.12.0-1.el8.noarch (try to add '--skip-broken' to skip
> uninstallable packages or '--nobest' to use not only best candidate
> packages)
> -
> Or I am doing some wrong?
> 
You need to enable RHEL CRB (CodeReady Builder) repository. It's someting like
optional repository in RHEL 7.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Petr Pisar]

On Tue, Sep 24, 2019 at 09:13:51PM -0400, Stephen Gallagher wrote:
> > Example: RHEL has two perl streams:
> >
> > perl:5.24
> > perl:5.26 [d]
> >
> > You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
> > adds perl:5.26 into the build root.
> >
> > If you add a perl-Foo module into EPEL, you won't be able to set a default
> > stream, hence you won't be able to have it in the build root and therefore 
> > you
> > won't be able to add a non-modular perl-Bar package that requires a perl-Foo
> > module component into EPEL.
> >
> > The only solution would be either add perl-Bar as a module, or not add
> > perl-Foo as a module. If you go the second path (i.e. no modules), it means
> > you won't be able build none of the packages for the non-default streams 
> > (i.e.
> > perl:5.24).
> 
> Well, another thing to be aware of is that we want to avoid the "every
> package has a separate module" situation, because that way lies
> madness and combinatorial explosion.
> 
> What would be best is if we look at this from top-down, rather than
> bottom-up. (Or, put another way: let's solve the problem the user
> cares about).
> 
> Users as a general rule do not care which libraries they have. They
> care that the application they want to run is available to them.
> 
I cannot agree with most of the statements you made. Fedora users care about
libraries because they are developers. Not about all of them but about many of
them. About much larger number than is a number of applications Fedora
provides. Hence limiting modules to applications is suboptimal.

Starting with few application-centric modules and splitting out modules with
librarires on user's requests is troublesome because you would end up with
multiple modules providing the same or similar or incompatible packages. And
you cannot just replace the old big modules with new slimmer ones because you
cannot retire the old modules, you need to support them to the end of their
life.

Having few fat modules is also problematic because you will find out that they
have common dependencies that would conflict each to other. (You know that
modularity does not solve parallel installability.) Also there are technical
issues in Fedora infrastructure that makes building large modules unreliable.

Therefore in my opinion many smaller modules is the right way. It 
supports sharing packagers work and allows delivering fixes faster.

But I agree that the current modularity implementation does not scale
(performance- and tooling-wise) with a large amount of modules. A proper
solution would be dissolve modules into RPM level so that it's native to RPM
and DNF. But that's somewhat off-topic.

> The point of this is to note that we want to encourage that if you
> have packages that are tightly-coupled (or that are used together more
> often than not), they should go into a module stream together.
> 
Definitely. But my experience of maintaining hunderds of packages and mass
rebuilding thousands of them says that a chance for coupling packages into
modules is miniscule.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Petr Pisar]

On Tue, Sep 24, 2019 at 05:02:42PM -0600, Orion Poplawski wrote:
> On 8/26/19 2:33 AM, Petr Pisar wrote:
> > On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
> > > So, I see the following options for how to handle default streams in RHEL 
> > > 8
> > > 
> > > Option 1: We disallow assigning default streams at all within EPEL 8.
> > > This will protect us against a future change where RHEL wants to set a
> > > default. Additionally, it means that all EPEL modules are explicitly
> > > opt-in and so we don't ever surprise anyone.
> > > 
> > > Option 2: We allow making EPEL streams the default stream if RHEL does
> > > not currently provide a default stream. We set strict policy regarding
> > > what a default stream may contain (such as "must not replace any
> > > package provided by RHEL 8"). If RHEL later decides to set a default
> > > for this stream, the RHEL release engineering must ensure that the
> > > `data.version` value is higher than what EPEL 8 carries.
> > > 
> > > I'm somewhat more in favor of Option 1 here, mostly because it
> > > minimizes the chance of conflicts and ensures the opt-in nature of
> > > EPEL. But I'm willing to hear counter-arguments.
> > > 
> > I don't like the Option 1. It makes adding modularized packages into a build
> > root impossible. Efectivelly forcing everbody to modularize everything or
> > nothing. That's exactly the deficiency the modularity has in Fedora and does
> > not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in
> > Fedora.
> > 
> > Example: RHEL has two perl streams:
> > 
> > perl:5.24
> > perl:5.26 [d]
> > 
> > You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
> > adds perl:5.26 into the build root.
> > 
> > If you add a perl-Foo module into EPEL, you won't be able to set a default
> > stream, hence you won't be able to have it in the build root and therefore 
> > you
> > won't be able to add a non-modular perl-Bar package that requires a perl-Foo
> > module component into EPEL.
> > 
> > The only solution would be either add perl-Bar as a module, or not add
> > perl-Foo as a module. If you go the second path (i.e. no modules), it means
> > you won't be able build none of the packages for the non-default streams 
> > (i.e.
> > perl:5.24).
> > 
> > That effectively pushes modules into the role of leaf-only dependencies.
> > That's quite awkward situation if you consider that RHEL delivers language
> > runtimes as modules. The proposed EPEL policy would devalute the non-default
> > runtimes.
> > 
> > -- Petr
> 
> What if we could have "slave" modules?  I.e. "epel-perl" that would acquire
> the state of the "perl" module and could contain the EPEL perl packages.
> This would require coordination among the EPEL perl packagers to maintain
> the epel-perl module but would also allow it to automatically track the
> state of the RHEL module - and allow it to have a default stream.
> 
Just adding another intermediary module (epel-perl) won't help. It would
suffer from the same issue because we would need a default stream for the
intermediary module.

You would need some magic in DNF that would inherit defaults and
state of enablement from "perl" to the "epel-perl", but that would require
changes in DNF. I don't believe that anybody, especially DNF maintainers were
happy of it.

-- Petr



signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Petr Pisar]

On Tue, Sep 24, 2019 at 08:44:56PM -0400, Stephen Gallagher wrote:
> On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi  wrote:
> >
> > On 8/23/19 10:56 AM, Stephen Gallagher wrote:
> 
> ...
> 
> > > For default profiles, we have some options as well:
> > >
> > > Option 1: We disallow setting default profiles for EPEL streams. Pros:
> > > no risk of conflict with RHEL, should they now or in the future
> > > provide defaults for some streams of this module. Cons: `yum module
> > > install foo[:bar]` would not work (they would need to do `yum module
> > > install foo[:bar]/profilename`) and would likely irritate users.
> > >
> > > Option 2: We allow setting default profiles for EPEL streams. We take
> > > advantage of the defaults merging logic and ensure that if we need to
> > > supplement RHEL AppStream's defaults content, we must ship a
> > > modulemd-defaults document of the same `data.version`. This will allow
> > > them to be merged cleanly. Pros: Optimum user experience (they get the
> > > default profiles installed when they use the simplified install
> > > command). Cons: We need to constantly monitor each RHEL AppStream
> > > release and ensure that we aren't ever overriding (or being overridden
> > > by) RHEL.
> > >
> > >
> > > I think Option 2 is the better choice here (fewer angry users is a
> > > good thing), but I worry a bit about the maintenance burden of keeping
> > > track of the `data.version` values and ensuring they stay in sync. I
> > > think we can probably automate a good deal of this, though.
> >
> >
> > Yeah, I would like to do 2 also if we can manage to make it mostly
> > automated.
> >
> 
> So, after discussing things at today's Modularity WG meeting, we've
> decided to make a breaking change to libmodulemd's merging logic to
> solve this much more cleanly. Full details are in
> https://github.com/fedora-modularity/libmodulemd/issues/368
> 
> With that change in place, Option 2 becomes the obvious correct
> choice, since we won't have to worry about the monitoring of the
> `data.version` values.

That seems reasonable. Thank you.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: XML::Feed.pm perl on CentOS 7

[Petr Pisar]

On Tue, Sep 03, 2019 at 08:33:04AM +0300, Lars Noodén wrote:
> I'm looking for CPAN's XML::Feed.pm for perl 5 for centos 7 via yum but
> not finding anything for it (e.g. perl-XML-Feed.noarch) in the
> repositories.  I have the base, epel, extras, and updates repositories
> available.
> 
[...]
> Is there an additional package repository containing CPAN material for
> CentOS 7 which I must add in order to get XML::Feed?
> 
Who knows.

indicates there was a "DAG packages for Red Hat Linux" repository.

If you want to add it into EPEL, you can try asking Fedora maintainer
.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: perl-LDAP in EPEL 8?

[Petr Pisar]

On Fri, Aug 30, 2019 at 08:51:11AM -0400, Stephen John Smoogen wrote:
> On Fri, 30 Aug 2019 at 07:28, Petr Pisar  wrote:
> >
> > On Fri, Aug 30, 2019 at 12:32:12PM +0200, Maximilian Philipps wrote:
> > > It has now been several months since the release of RHEL 8 and I am
> > > still struggling to get a RHEL 8 into an usable state. Besides the
> > > already mentioned absence of fail2ban and nagios plugins I am now facing
> > > the lack of perl-LDAP.
> > >
> > > In RHEL 7 perl-LDAP was part of the base repo, in RHEL 8 it is
> > > completely missing. According to the epel 8 announcement mail I am
> > > supposed to contact the package maintainer, but from what I have found 
> > > that
> > > package is always just owned by the project in Fedora/Centos.
> > >
> 
> Petr
> 
> I am confused you are listed as the admin of the package.
> 
> owner: jplesnik; admin: ppisar; commit: mbarnes, rstrode, ssp,
> caolanm, caillon, alexl, johnp, rhughes
> 
Owner means the primary maintainer who can administer the package. Admin means
another maintainer. Commit means a person who can change the package source
but who cannot administer the package like adding access to other people.

Yes, I'm one of the maintainer of the package.

Do you need to explain something else?

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: perl-LDAP in EPEL 8?

[Petr Pisar]

On Fri, Aug 30, 2019 at 12:32:12PM +0200, Maximilian Philipps wrote:
> It has now been several months since the release of RHEL 8 and I am
> still struggling to get a RHEL 8 into an usable state. Besides the
> already mentioned absence of fail2ban and nagios plugins I am now facing
> the lack of perl-LDAP.
> 
> In RHEL 7 perl-LDAP was part of the base repo, in RHEL 8 it is
> completely missing. According to the epel 8 announcement mail I am
> supposed to contact the package maintainer, but from what I have found that
> package is always just owned by the project in Fedora/Centos.
> 
> What is required to get that package into epel?

File the request in the Bugzilla against "perl-LDAP" component in "Fedora
EPEL" product in "Fedora" classification. If the component does not exist
there, use a component in "Fedora" product.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Koschei enablement for EPEL 8

[Petr Pisar]

On Wed, Aug 28, 2019 at 09:15:47AM +0200, Mikolaj Izdebski wrote:
> Fedora infrastructure has been asked [1] to enable Koschei [2] for
> EPEL 8. Would this be useful to anyone?

Yes.

> If yes, which of build targets
> (epel8-candidate, epel8-playground-candidate) should Koschei submit
> scratch builds for?
> 
Both? Though I have no idea if people are actually going to use
epel8-playground-candidate.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

[Petr Pisar]

On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote:
> So, I see the following options for how to handle default streams in RHEL 8
> 
> Option 1: We disallow assigning default streams at all within EPEL 8.
> This will protect us against a future change where RHEL wants to set a
> default. Additionally, it means that all EPEL modules are explicitly
> opt-in and so we don't ever surprise anyone.
> 
> Option 2: We allow making EPEL streams the default stream if RHEL does
> not currently provide a default stream. We set strict policy regarding
> what a default stream may contain (such as "must not replace any
> package provided by RHEL 8"). If RHEL later decides to set a default
> for this stream, the RHEL release engineering must ensure that the
> `data.version` value is higher than what EPEL 8 carries.
> 
> I'm somewhat more in favor of Option 1 here, mostly because it
> minimizes the chance of conflicts and ensures the opt-in nature of
> EPEL. But I'm willing to hear counter-arguments.
> 
I don't like the Option 1. It makes adding modularized packages into a build
root impossible. Efectivelly forcing everbody to modularize everything or
nothing. That's exactly the deficiency the modularity has in Fedora and does
not have in RHEL. The Option 1 makes the modularity in EPEL terrible as in
Fedora.

Example: RHEL has two perl streams:

perl:5.24
perl:5.26 [d]

You can add a non-modular perl-Foo package into EPEL bacause EPEL magically
adds perl:5.26 into the build root.

If you add a perl-Foo module into EPEL, you won't be able to set a default
stream, hence you won't be able to have it in the build root and therefore you
won't be able to add a non-modular perl-Bar package that requires a perl-Foo
module component into EPEL.

The only solution would be either add perl-Bar as a module, or not add
perl-Foo as a module. If you go the second path (i.e. no modules), it means
you won't be able build none of the packages for the non-default streams (i.e.
perl:5.24).

That effectively pushes modules into the role of leaf-only dependencies.
That's quite awkward situation if you consider that RHEL delivers language
runtimes as modules. The proposed EPEL policy would devalute the non-default
runtimes.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

[Petr Pisar]

On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote:
> On Fri, 23 Aug 2019 at 06:52, Petr Pisar  wrote:
> > Case: RHEL delivers a non-modular P package. There is no S stream of
> > a M module. Can I add a new M module with a new S stream that will contain
> > a modular P package? I guess it will be allowed. Can I make the stream
> > default? I guess that won't be allowed.
> >
> 
> I would agree with your assessment.
> 
Thank you for the prompt response. I have yet another peculiar corner case of
this one, that I is actually very prominent for me:

We have plenty of Perl packages in RHEL. Most of them are not modularized,
thus they are compatible only with Perl 5.26, a default perl:5.26 stream.
I feel there will be a demand for providing their modularized variants in EPEL
so that users can use them even with non-default perl.

All that can be implemented by adding a new module. This is not a problem. The
problem is that the module will an second-class citizen compating to a module
with net new package due to missing the default stream. The reasong for
banning the default is that the EPEL modular package would mask the
non-modular RHEL package.

Let's I have a theoretcal way how to build that module so thet a context for
perl:5.26 will be an empty, no RPM package. Then making the stream default
would not violate the no-replacement rule.

If a user used perl:5.26, yum would install the non-modular package from RHEL
because there won't by any modular package masking it. If a user enabled 
a different perl stream, yum would install the modular package from EPEL.

Would you accept this solution?

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Rules for shadowing RHEL packages with EPEL modules

[Petr Pisar]

If I read the EPEL 8 annoucement correctly, it's still not possible to build
modules in EPEL. Nevertheless I'd like to know how the rules about "not
replacing RHEL content" will apply to modules. Here are my question:

Case: RHEL delivers an M module with a default S1 stream. There is no S2
stream. Can I add a new S2 stream into EPEL? I guess this will be allowed. If
later RHEL introduces S2 stream, I guess EPEL will remove the S2 module.

Case: RHEL delivers an M module with no default stream, there is no S stream.
Can I add a new S stream into EPEL and make it default? I'm not sure this will
be allowed. There is a risk of creating conflicts between streams transitively
required by another default streams. (Remember the libgit2 module conflict
.)

Case: RHEL delivers a non-modular P package. There is no S stream of
a M module. Can I add a new M module with a new S stream that will contain
a modular P package? I guess it will be allowed. Can I make the stream
default? I guess that won't be allowed.

Case: RHEL delivers a P package. Can I build a modular P package when building 
a new module stream in EPEL only for the purpose of building the module
and then filter out the P package from the module (i.e. a build-only module
component) so that the P package does not get into EPEL repository? I guess
this will be allowed.

Could EPEL product owner (or whoever makes and assert the rules) clarify?
I need to know that to choose the easiest and yet conforming strategy for
adding new modules into EPEL, especially when dealing with RHEL packages
unavailable for some module contexts.

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Does EPEL support people who do not upgrade RHEL?

[Petr Pisar]

On Fri, Jan 04, 2019 at 11:36:31AM -0800, Kevin Fenzi wrote:
> On 1/4/19 12:54 AM, Igor Gnatenko wrote:
> > I believe that EPEL is not meant to support all possible old versions of
> > RHEL. It is built against latest release, so the expectation is that it
> > supports only latest release.
> 
> Correct. We build against and only support the latest minor release in
> both rhel6 and rhel7.
> 
Thanks for the assurance. Then I will proceed.

-- Petr


signature.asc
Description: PGP signature
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Does EPEL support people who do not upgrade RHEL?

[Petr Pisar]

Hello,

I have a question regarding packaging for EPEL.

Fedora renamed perl package to perl-interpreter package and changed all
the occurances in all spec files. Because there are package maintainers who
share spec files between Fedora and EPEL, I added the perl-interpreter
package to EPEL.

Later RHEL-7.6 updated perl to provide perl-interpreter (as a RPM Provides,
not as a real package), so the perl-interpreter package in EPEL is not needed
anymore.

Now the next step is removing perl-interpreter from EPEL as requested in
a bug #1663304. That seems reasonable because EPEL should not deliver things
provided by RHEL.

However, my concern is people who did not upgrade RHEL to 7.6. If I remove
perl-interpreter from EPEL, it could break their systems.

What does an EPEL community recommend?

-- Petr


signature.asc
Description: PGP signature
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org