[EPEL-devel] Re: Incompatible Upgrade Request - singularity-ce

2024-01-29 Thread Neal Gompa 
On Mon, Jan 29, 2024 at 2:32 PM David Trudgian via epel-devel
 wrote:
>
> Dear all,
>
> Following advice from Neal elsewhere on this list [1], I’m requesting that 
> the singularity-ce EPEL packages may be updated to 4.1.0 following the 
> incompatible upgrade procedure. The justification for the upgrade is that 3.x 
> singularity-ce is no longer maintained upstream. Note that because 
> singularity-ce necessarily bundles many Go dependencies specified in upstream 
> go.mod/go.sum, lack of maintenance can quickly lead to inherited security 
> issues.
>
> Upstream singularity-ce (https://github.com/sylabs/singularity) maintenance 
> is limited to the latest x.y minor version, currently 4.1. The upstream 
> project has committed more formally to semantic versioning conventions since 
> 4.0.0, so any 4.y.z minor (y) and patch (z) version updates are expected to 
> be compatible upgrades for EPEL purposes.
>
> At present, singularity-ce in EPEL 7/8/9 has been held at 3.11.5 due to 
> incompatible changes.
>
> Incompatibilities from 3.11.5 -> 4.1.0 are as follows:
>
> (a) The CLI has split some functionality previously provided by the 
> `singularity remote` command into new `singularity registry` and `singularity 
> keyserver` commands.
> (b) The `singularity remote add` command now sets a newly added remote as the 
> default (unless suppressed). Previously the user had to set the default 
> remote manually.
> (c) The `—vm` flag to start `singularity` inside a Virtual Machine has been 
> removed. This was not intended to be user facing, but was used by a separate 
> and proprietary Singularity Desktop project that has been retired for some 
> time. `—vm` was unmaintained, and I don’t believe there is any practical use 
> outside of this context.
>
> (d) Bind mounts are now performed in the order in which they are specified. 
> Previously, image based bind mounts were performed before others.
> (e) Current working directory on the host is now created in the container, 
> restoring a behaviour from Singularity <3.6.0 unless suppressed.
> (f) If the current directory paths on the container and host contains 
> symlinks to different locations, the current working directory is not mounted.
>
> The above are expected to have a minor impact on users. Arguably (d)/(e)/(f) 
> are bug fixes as they address issues reported by users as unexpected 
> behaviour. Changes (e)/(f) were also previously included in the apptainer 
> project's upgrade to their v1.2.0 that was not submitted as an incompatible 
> upgrade.
>
> Highlighting also for Dave Dykstra’s benefit that any thoughts around the 
> relevance of incompatible upgrade policy to (b) & (c) will also be relevant 
> to apptainer’s upcoming 1.3.0 upgrade, as apptainer has pulled both of these 
> changes from singularity-ce upstream.
>
> Other changes in behaviour from 3.11.5 -> 4.1.0 are compatible. Configuration 
> files do not need to be modified.
>

This seems reasonable to me.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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: Packaging a newer singularity-ce as singularity-ce4

2024-01-26 Thread Neal Gompa 
On Fri, Jan 26, 2024 at 9:39 AM David Trudgian via epel-devel
 wrote:
>
> Thanks for your comments.
>
> >> I’ve had some discussion with Jonathan Wright elsewhere about the topic of 
> >> this message, but wanted to verify my understanding is correct before I 
> >> embark on it, and thought I’d do so on list.
> >>
> >> singularity-ce is currently packaged at v4.0.3 in Fedora Rawhide, and 
> >> v.3.11.5 elsewhere (Fedora releases and EPEL).
> >>
> >> We want to make a v4 available to EPEL users, as many would be interested 
> >> in it, but I wouldn’t consider it a compatible update because there are 
> >> some CLI changes, and small behaviour changes.
> >>
> >> My understanding is that in order to provide a 4.x in EPEL, without any 
> >> incompatible update happening for users:
> >>
> >> 1) I create a new package, singularity-ce4, to package the 4.x version. In 
> >> rawhide, this will be the same as the singularity-ce package currently in 
> >> rawhide, but needs new package review etc.
> >
> > Creating a versioned package does NOT require a new review[1], though
> > if you feel that packaging changes are going to be large enough to
> > warrant one, you may still request it.
>
> The linked document mentions - "The package MUST be properly named according 
> to the naming guidelines and MUST NOT conflict with all other versions of the 
> same package.”
>
> (https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_process)
>
> I read this as both versions should be installable at the same time? This is 
> not easily the case here, as singularity has to provide a `run-singularity` 
> executable that may called from a '#!/usr/bin/env run-singularity’ embedded 
> in our container image format.
>
> It’s also perhaps complicated by the fact that we already conflict with the 
> apptainer package that provides /usr/bin/[run-]singularity and attempts to 
> migrate configuration. We both have a ‘Provides/Conflicts: sif-runtime’, and 
> `Provides: alternative-for(singularity)` around this. I’d assume preserving 
> the right behaviour there deserves review. This is all complication arising 
> from singularity-ce and apptainer being separate forks of the project 
> previously known as ’singularity’.
>
> >> 2) For rawhide / upcoming f40 *only*, the new singularity-ce4 package will 
> >> provide/obsolete singularity-ce as it is the same thing … and 
> >> singularity-ce can be retired in rawhide.
> >
> >> 3) When singularity-ce4 is added to EPEL it will *not* provide/obsolete 
> >> singularity-ce, but a message can be added to %post to inform people about 
> >> the availability of v4.
> >
> > Do not do this. %post messages are really only intended to inform
> > users of failures and, frankly, no one reads them until something has
> > gone wrong. Even then, it's only going to be the sysop for the machine
> > that sees it, who may not be the person who deals with Singularity.
>
> Agreed. This was a prior suggestion made to me.
>
> >
> > I don't know anything about Singularity, but if it has a user
> > interface of any kind (like the CLI), what you might want to do is add
> > a wrapper around it that prints your message. That's much more likely
> > to be viewed by the people who would care.
>
> We can certainly do that.
>
> >
> >> At some point in the future, if 3.x is no longer maintainable for good 
> >> reason, then the incompatible update procedure can be pursued to make 
> >> singularity-ce4 provide/obsolete singularity-ce in EPEL 7/8/9 - and 
> >> singularity-ce is fully retired. EPEL 10 will only get singularity-ce4.
> >
> > Is v3 still supported upstream today? If not, you probably want to
> > make the message above a deprecation notice and add an EOL date.
>
> v3 is only minimally supported upstream, and entirely for the purposes of 
> having it in Fedora & EPEL without forcing an incompatible upgrade. It’s 
> unsupported in any other form (outside of commercial LTS). I am both the 
> upstream maintainer and the packager here, both in the context of employment. 
> It would be beneficial if I didn’t need to spend any time on maintaining v3 
> at all, but we are attempting to meet the broad expectations of EPEL, given 
> we are both upstream and packaging...
>
> Since I am both the upstream maintainer, and the downstream packager of 
> singularity-ce, it seems somewhat hard to argue I can’t keep it updated for 
> at least a while with backports to avoid forcing an incompatible update. I do 
> the bundled dependency updates etc. upstream, rather than via packaging 
> patches or similar, for my own convenience.
>
> In previous discussions with others involved in EPEL it seemed that it was 
> perhaps considered reasonable to try and maintain the v3 in EPEL until such 
> time as it drops out of a stable Fedora, or there is a security issue with a 
> fix that is not reasonably practical to back port.

Well, EPEL 7 is EOL in five months, so it may not be worth it to spend
this effort

[EPEL-devel] Re: cloud-utils-growpart package conflict

2023-12-11 Thread Neal Gompa 
On Mon, Dec 11, 2023 at 2:19 PM Leon Fauster via epel-devel
 wrote:
>
> While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
> and RHEL8?
>
> cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms
>
> cloud-utils-growpart noarch 0.33-3.el8 epel
>
> Subpackage conflict?
>

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



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: chromium regression on EL9

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

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


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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: KDE Updated in EPEL9

2023-11-13 Thread Neal Gompa 
On Mon, Nov 13, 2023, 1:29 PM Troy Dawson  wrote:

> KDE has been updated in EPEL9.
> Versions:
> Plasma: 5.27.6
> KF5: 5.108
> Apps: 23.04.3
>
> Known Issues:
> - kdepim-addons - Was not updated due to kf5-kitinerary not being updated
> due to older poplar in RHEL 9.
> -- The older version of kdepim-addons is not liking the newer libraries.
> -- Should be fixed this week.
> - lokalize - Does not install, has never installed.  I kept thinking I
> could get it's dependencies in, but never have.
> -- I will be removing this package from epel9.  Since it was
> un-installable, this shouldn't affect anyone.
>
> Deprecation:
> We are marking the following packages deprecated.  They will not be in
> epel10.  They will continue to be in epel9.
> - plasma-workspace-x11
> - sddm-x11
>

And kwin-x11 too.

>
___
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: python311-dnf for el8 and el9

2023-10-05 Thread Neal Gompa 
On Thu, Oct 5, 2023 at 3:52 PM Ken Dreyer  wrote:
>
> Hi folks,
>
> I have some Python apps that "import dnf". I wanted to run these on
> the parallel Python versions in RHEL 8 and 9, but there's no
> python311-dnf library available.
>
> I haven't looked into this yet. Has anyone else looked at it?
>
> I think I'll need something like
> https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a
> , but for a "python3-dnf" package?
>
> (By the way, thanks Python team for python3.11 in RHEL 8 and 9. That
> is helpful for moving workloads across RHEL versions and helping the
> Python ecosystem move forward. And thank you Miro for python311-rpm!)

Not recently. I looked at it way back in the EPEL 7 Python 3 stack
days... I don't think it'd be too difficult to actually do, based on
what Miro did for the python3-rpm package for EPEL.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: retirement of klee from EPEL 9

2023-09-29 Thread Neal Gompa 
On Fri, Sep 29, 2023 at 9:20 AM Troy Dawson  wrote:
>
> On Thu, Sep 28, 2023 at 8:37 PM Carl George  wrote:
>>
>> It recently came to my attention that the klee package in EPEL 9
>> needed to be rebuilt against the LLVM 15 library that shipped in RHEL
>> 9.2.  I filed a bug for this [0], and then noticed it was assigned to
>> "Orphan Owner".  It looks like the maintainer retired it from Fedora
>> [1][2] due the upstream not being compatible with LLVM 15 [3].  I am
>> not the maintainer of this package, but I intend to retire this
>> package from EPEL 9 to avoid having a package with installation issue
>> lingering around.  The EPEL retirement policy [4] doesn't cover this
>> exact scenario, so I plan to bring it up for discussion at the next
>> EPEL Steering Committee meeting.  We could delay the retirement for
>> one week (the policy for security-related retirements) or two weeks
>> (the policy for lack-of-time retirements), but my preference would be
>> to retire it ASAP.
>>
>> [0] https://bugzilla.redhat.com/show_bug.cgi?id=2241277
>> [1] 
>> https://src.fedoraproject.org/rpms/klee/c/35fdedce2021112b996a9d38bf3e93cf5cf236c8?branch=rawhide
>> [2] 
>> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/SSJWCMXP45ERM76XH6MIW6Z76GIC7DFN/
>> [3] https://github.com/klee/klee/pull/1648
>> [4] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/
>
>
> Since it hasn't been able to be installed since RHEL 9.2 came out, I'm not 
> opposed to doing it ASAP.
> Especially since they not only orphaned it, but they retired it back in 
> January.  And nobody came forward to "unorphan" it back then.
>
> But, since it's not installable, so nobody is going to accidentally install 
> it, there is no rush either.
> Either way is fine by me.
>

Meh, yoink it now.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Cannot run fedpkg mockbuild for epel9 on f38

2023-06-03 Thread Neal Gompa 
On Sat, Jun 3, 2023 at 12:03 PM Stephen Smoogen  wrote:
>
>
>
> On Sat, 3 Jun 2023 at 11:57, Brad Bell  wrote:
>>
>> I am getting the error message below in response to a `fedpkg mockbuild` 
>> command. What am I doing
>> wrong ?
>>
>>  >fedpkg mockbuild
>> ... snip ...
>> ERROR: Mock config 'epel-9-x86_64' not found, see errors above.
>>
>>
>> Here is my system information:
>>
>>  >git branch
>> * epel9
>>rawhide
>>
>>  >uname -a
>> Linux brad-mobile 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 
>> 17:37:39 UTC 2023 x86_64
>> GNU/Linux
>>
>>  >ls /etc/mock | grep epel-9
>> alma+epel-9-aarch64.cfg
>> alma+epel-9-ppc64le.cfg
>> alma+epel-9-s390x.cfg
>> alma+epel-9-x86_64.cfg
>> centos-stream+epel-9-aarch64.cfg
>> centos-stream+epel-9-ppc64le.cfg
>> centos-stream+epel-9-s390x.cfg
>> centos-stream+epel-9-x86_64.cfg
>> oraclelinux+epel-9-aarch64.cfg
>> oraclelinux+epel-9-x86_64.cfg
>> rhel+epel-9-aarch64.cfg
>> rhel+epel-9-ppc64le.cfg
>> rhel+epel-9-s390x.cfg
>> rhel+epel-9-x86_64.cfg
>> rocky+epel-9-aarch64.cfg
>> rocky+epel-9-ppc64le.cfg
>> rocky+epel-9-s390x.cfg
>> rocky+epel-9-x86_64.cfg
>>
>
> You need to choose a distribution to build against and set the configs for it
>
> ln -s /etc/mock/foobar+epel-9-x86_64.cfg /etc/mock/epel-9-x86_64.cfg
> ln -s /etc/mock/foobar+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg
>

I recommend not doing it in /etc, and instead doing it in
~/.config/mock, like so:

ngompa@fedora ~> ls -hal ~/.config/mock/
total 16K
drwxr-xr-x. 1 ngompa ngompa  140 Jun 16  2022 ./
drwxrwxr-x. 1 ngompa ngompa 3.7K Jun  3 12:14 ../
lrwxrwxrwx. 1 ngompa ngompa   33 Feb 12  2022 epel-8-aarch64.cfg ->
/etc/mock/eldistro+epel-8-aarch64.cfg
lrwxrwxrwx. 1 ngompa ngompa   32 Feb 12  2022 epel-8-x86_64.cfg ->
/etc/mock/eldistro+epel-8-x86_64.cfg
lrwxrwxrwx. 1 ngompa ngompa   33 Jun 16  2022 epel-9-aarch64.cfg ->
/etc/mock/eldistro+epel-9-aarch64.cfg
lrwxrwxrwx. 1 ngompa ngompa   32 Jun 16  2022 epel-9-x86_64.cfg ->
/etc/mock/eldistro+epel-9-x86_64.cfg

(I changed my choice to the non-existent "eldistro" intentionally,
substitute with your preferred variant)



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL2RHEL - New Wording? - New Workflow?

2023-03-20 Thread Neal Gompa 
On Mon, Mar 20, 2023 at 5:37 AM Miro Hrončok  wrote:
>
> On 17. 03. 23 0:08, Troy Dawson wrote:
> > This package has been considered important enough to Red Hat's customers 
> > that
> > Red Hat has decided to promote it to be an official part of RHEL.
>
> I know I am late to the party, so feel free to ignore me.
>
> Is it OK to claim guessed reasons for new packages being added to RHEL?
>
> I could think of other reasons as well. E.g. it's not important for customers
> but it's important for Red Hat. Or maybe it is a not-so-important dependency 
> of
> something else.
>

Does Red Hat have any other motivation with RHEL other than a customer
needing the functionality? Those other reasons are generally driven by
someone needing it.

> What I am trying to say, wouldn't it be generally more accurate to simply 
> state:
>
> "Red Hat has decided to promote this package to be an official part of RHEL."
>
> ?

This feels cold, which I think is why Troy was trying to add more color here.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL2RHEL - New Wording? - New Workflow?

2023-03-16 Thread Neal Gompa 
On Thu, Mar 16, 2023 at 7:08 PM Troy Dawson  wrote:
>
> On Thu, Mar 16, 2023 at 3:35 PM Neal Gompa  wrote:
>>
>> On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson  wrote:
>> >
>> > On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson  wrote:
>> >>
>> >>
>> >>
>> >> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster 
>> >>  wrote:
>> >>>
>> >>> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
>> >>>  wrote:
>> >>>
>> >>> > It would be really nice if the wording of the bug could contain some
>> >>> > kind of a "thank you" note to the EPEL maintainers of the package in
>> >>> > question. Not everyone will understand this process as "great, I don't
>> >>> > have to maintain package X anymore, Red Hat will be doing that for me
>> >>> > from now on". Some folks may take it as "Oh no! Red Hat is taking away
>> >>> > my toy! Why?!" Ideally, there should still be a way for EPEL
>> >>> > maintainer(s) to continue contributing to the RHEL package.
>> >>>
>> >>> Perhaps add something like (wordsmithed by someone
>> >>> competent in such things):
>> >>>
>> >>> "The package you have been maintaining in EPEL is now
>> >>> considered important enough to a large enough part of our
>> >>> customers that Red Hat has decided to promote it to being
>> >>> an officially supported part of the product"
>> >>
>> >>
>> >> I like that idea.  It's much more positive.  A nice "Thank you for doing 
>> >> this in EPEL" type of feel.
>> >>
>> >> Troy
>> >
>> >
>> > This is what I have on my ticket.  Respond soon (by tomorrow end of day) 
>> > if you think I need changes.
>> >
>> > Subject:
>> > Notice:  will be automatically retired from epel when RHEL 
>> > . is released
>> >
>> > Comment:
>> > Thank you for your work maintaining  in epel.  This 
>> > package has been considered important enough to Red Hat's customers that 
>> > Red Hat has decided to promote it to be an official part of RHEL.  It will 
>> > be part of RHEL ..  When that is released, EPEL automation 
>> > will remove  from epel.
>> >
>>
>> That is pretty well worded, though you can just use "EPEL "
>> instead of "epel".
>>
>
> I was debating whether to use capital letters or not.  I agree with you, I 
> think it does look better, and I have capital RHEL.
> With the bit I added for Kevin, here is what I currently have
>
> Subject:
> Notice:  will be automatically retired from EPEL  when RHEL 
> . is released
>
> Comment:
>
> Thank you for your work maintaining  in EPEL .  This package 
> has been considered important enough to Red Hat's customers that Red Hat has 
> decided to promote it to be an official part of RHEL.  It will be part of 
> RHEL ..  When that is released, EPEL automation will remove 
>  from EPEL  and close this bug.
>

That looks great!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL2RHEL - New Wording? - New Workflow?

2023-03-16 Thread Neal Gompa 
On Thu, Mar 16, 2023 at 6:10 PM Troy Dawson  wrote:
>
> On Mon, Feb 20, 2023 at 6:33 AM Troy Dawson  wrote:
>>
>>
>>
>> On Sun, Feb 19, 2023 at 6:25 PM Gary Buhrmaster  
>> wrote:
>>>
>>> On Mon, Sep 5, 2022 at 9:33 AM Dominik 'Rathann' Mierzejewski
>>>  wrote:
>>>
>>> > It would be really nice if the wording of the bug could contain some
>>> > kind of a "thank you" note to the EPEL maintainers of the package in
>>> > question. Not everyone will understand this process as "great, I don't
>>> > have to maintain package X anymore, Red Hat will be doing that for me
>>> > from now on". Some folks may take it as "Oh no! Red Hat is taking away
>>> > my toy! Why?!" Ideally, there should still be a way for EPEL
>>> > maintainer(s) to continue contributing to the RHEL package.
>>>
>>> Perhaps add something like (wordsmithed by someone
>>> competent in such things):
>>>
>>> "The package you have been maintaining in EPEL is now
>>> considered important enough to a large enough part of our
>>> customers that Red Hat has decided to promote it to being
>>> an officially supported part of the product"
>>
>>
>> I like that idea.  It's much more positive.  A nice "Thank you for doing 
>> this in EPEL" type of feel.
>>
>> Troy
>
>
> This is what I have on my ticket.  Respond soon (by tomorrow end of day) if 
> you think I need changes.
>
> Subject:
> Notice:  will be automatically retired from epel when RHEL 
> . is released
>
> Comment:
> Thank you for your work maintaining  in epel.  This package 
> has been considered important enough to Red Hat's customers that Red Hat has 
> decided to promote it to be an official part of RHEL.  It will be part of 
> RHEL ..  When that is released, EPEL automation will remove 
>  from epel.
>

That is pretty well worded, though you can just use "EPEL "
instead of "epel".



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL2RHEL - New Wording? - New Workflow?

2023-02-20 Thread Neal Gompa 
On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson  wrote:
>
> On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  wrote:
>>
>> Hi Troy,
>>
>> On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote:
>> > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel <
>> > epel-devel@lists.fedoraproject.org> wrote:
>> >
>> > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote:
>> > > > I think this whole process should be automated. File bugs that say
>> > > > "Heads up:
>> > > > your package will be automatically retired after the release of RHEL
>> > > > X.X" and
>> > > > provide some explanation.
>> > >
>> > > Agreed. This is a pretty mechanical process: all the maintainer would
>> > > do is run "fedpkg retire" for the appropriate branches, and that looks
>> > > reasonable to automate. If we're concerned about bugs in the automation
>> > > retiring packages that shouldn't be impacted, we can have it file a
>> > > ticket for signoff on the EPEL tracker (or have some other process to
>> > > spot check, at least until we're confiden it'll do the right thing).
>> > >
>> >
>> > Sorry for delaying this for so long. Things came up, but now I have some
>> > time.
>> >
>> > I think step one in this automation workflow is to not assign the bugs to
>> > the package at all.
>> > Assign the bugs to EPEL / distribution, but keep them as blockers on the
>> > EPEL2RHEL tracker[1].
>> > This gets rid of the busy maintainer problem.  Where they just read the
>> > subject and do what it says.
>> > This also allows the automation to not have to deal with all the different
>> > packages.
>>
>> I'm not sure filling against distribution is a good idea. I'd just file
>> bugs against the affected component, set the bug assignee to yourself,
>> and close it once you preform the automatic retirement. This way, you
>> won't have to worry about CCing the proper maintainer on the
>> distribution bug and the bugs will be more organized. The subject is a
>> separate problem.
>>
>> > I think for the automation to happen, we also have to get the subject line
>> > updated.
>> > If we can get it to have what release is in it, parsing the subject line is
>> > much easier than going through all the bugzilla comments trying to find
>> > what release this is supposed to come out in.
>> > Something like "Remove yara from epel8 when RHEL 8.7 is released"
>>
>> I'd prefer something like the originally suggested "Notice: PACKAGE_HERE
>> will be automatically retired in RHEL X.X" so it's clear that
>> maintainers don't need to take manual action.
>
>
> That is a good point.
>
> On a related note.
> For the past month or so, as new packages get added to the tracker I've been 
> manually adding a comment that the package shouldn't be retired until (date) 
> which is when (release) will come out.  That has usually been May 2023 when 
> RHEL 8.8 / 9.2 comes out.
> Several of the maintainers have thanked me for the clarification.
> I've been doing this mainly so I can get a feel for what the script should be 
> doing.  But one thing came up that I don't have an answer to.
>
> I haven't said "We will automatically retire this for you" because I don't 
> know who "we" is/are.
> Is it the committee?  (could be, that seems the most likely)
> Is it the epel-packagers-sig? (I don't think that's right.)
> Is it a different "retirement group"?
>
> Thoughts?

It should probably be done by automation, not a person.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Hints for manual upgrading from CentOS 8 Stream to CentOS / Alma / Rockey 9

2023-02-08 Thread Neal Gompa 
On Wed, Feb 8, 2023 at 3:40 PM Richard Shaw  wrote:
>
> I know upgrades are not supported but its for a small home server that really 
> only does two things:
>
> BackupPC and Unifi (which I both maintain)
>
> Anyone had success doing manual upgrades or did you start with a reinstall?
>

I think AlmaLinux's ELevate thing can help you do in-place upgrades:
https://almalinux.org/elevate

You could also try upgrading to RHEL 9:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/upgrading_from_rhel_8_to_rhel_9/index

(RHEL is available for free for individuals:
https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Proposing incompatible upgrade for libkdumpfile (0.4.1 -> 0.5.1)

2023-02-08 Thread Neal Gompa 
On Wed, Feb 8, 2023 at 12:37 PM Troy Dawson  wrote:
>
> On Wed, Feb 8, 2023 at 9:21 AM Michel Alexandre Salim 
>  wrote:
>>
>> Hi all,
>>
>> Per the incompatible upgrade policy[1] I'm proposing upgrading
>> libkdumpfile from 0.4.1 to the latest 0.5.1 in both EPEL 8 and 9.
>>
>> Bugzilla issues:
>> - https://bugzilla.redhat.com/show_bug.cgi?id=2162866 (for 0.5.1 in
>> general)
>> - https://bugzilla.redhat.com/show_bug.cgi?id=2168301 (for EPEL)
>>
>> Up to 0.4.1, libkdumpfile was packaged without the test suite being
>> run, and when I started work on packaging it in Debian I noticed a lot
>> of test failures on non-x86_64 architectures:
>> https://github.com/ptesarik/libkdumpfile/issues/40
>>
>> This is now fixed (0.5.0 is the first version to pass tests cleanly
>> without additional patches on Fedora), but prior to its release we were
>> basically building in Fedora from a post-0.4.1 snapshot
>> (https://src.fedoraproject.org/rpms/libkdumpfile/blob/8b3b02e83af8326562a155581d77f04f2ae84197/f/libkdumpfile.spec)
>> that is likely not ABI compatible with the original 0.4.1 anyway, so
>> there's no reasonable way to backport the architecture fixes to 0.4.1.
>>
>> Change in sonames:
>>
>> [michel@f37-packaging ~]$ comm <(rpmdistro-repoquery fedora rawhide --
>> provides libkdumpfile 2>/dev/null) <(rpmdistro-repoquery centos-stream
>> 9 --provides libkdumpfile 2>/dev/null)
>> libaddrxlat.so.2()(64bit)
>> libaddrxlat.so.2(LIBADDRXLAT_0)(64bit)
>> libaddrxlat.so.3
>> libaddrxlat.so.3()(64bit)
>> libaddrxlat.so.3(LIBADDRXLAT_0)
>> libaddrxlat.so.3(LIBADDRXLAT_0)(64bit)
>> libkdumpfile = 0.4.1-5.el9
>> libkdumpfile = 0.5.0-3.fc38
>> libkdumpfile(x86-32) = 0.5.0-3.fc38
>> libkdumpfile(x86-64) = 0.4.1-5.el9
>> libkdumpfile(x86-64) = 0.5.0-3.fc38
>> libkdumpfile.so.10
>> libkdumpfile.so.10()(64bit)
>> libkdumpfile.so.10(LIBKDUMPFILE_0)
>> libkdumpfile.so.10(LIBKDUMPFILE_0)(64bit)
>> libkdumpfile.so.9()(64bit)
>> libkdumpfile.so.9(LIBKDUMPFILE_0)(64bit)
>>
>> Only drgn currently depends on libkdumpfile, and I plan to rebuild it
>> in the same updates:
>>
>> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>> whatrequires "libaddrxlat.so.2()(64bit)"
>> Last metadata expiration check: 0:12:30 ago on Wed Feb  8 11:02:35
>> 2023.
>> libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>> libkdumpfile-util-0:0.4.1-5.el9.x86_64
>> python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream 9 --
>> whatrequires "libkdumpfile.so.9()(64bit)"
>> Last metadata expiration check: 0:12:40 ago on Wed Feb  8 11:02:35
>> 2023.
>> drgn-0:0.0.22-1.el9.x86_64
>> libkdumpfile-devel-0:0.4.1-5.el9.x86_64
>> libkdumpfile-util-0:0.4.1-5.el9.x86_64
>> python3-libkdumpfile-0:0.4.1-5.el9.x86_64
>>
>> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
>> whatrequires "libaddrxlat.so.2()(64bit)"
>> Last metadata expiration check: 0:00:08 ago on Wed Feb  8 11:15:35
>> 2023.
>> libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>> libkdumpfile-util-0:0.4.1-5.el8.x86_64
>> python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>> [michel@f37-packaging ~]$ rpmdistro-repoquery centos-stream-legacy 8 --
>> whatrequires "libkdumpfile.so.9()(64bit)"
>> Last metadata expiration check: 0:00:16 ago on Wed Feb  8 11:15:35
>> 2023.
>> drgn-0:0.0.22-1.el8.x86_64
>> libkdumpfile-devel-0:0.4.1-5.el8.x86_64
>> libkdumpfile-util-0:0.4.1-5.el8.x86_64
>> python3-libkdumpfile-0:0.4.1-5.el8.x86_64
>>
>> [1]:
>> https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
>>
>> Thanks,
>
>
> If I am reading this correctly, the only package affected would be drgn (from 
> python-drgn).
> It should hopefully just need a rebuild.
> Is that correct?
> Were you planning on rebuilding python-drgn, or contacting the package 
> maintainer and having them do it?
>

He's a co-maintainer of python-drgn, so I assume he's going to
rebuild it himself.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: New EPEL KDE Proposal

2023-01-20 Thread Neal Gompa 
On Fri, Jan 20, 2023 at 2:44 PM Troy Dawson  wrote:
>
> I plan on making two changes to the current EPEL KDE Update Schedule.[1]
>
> ** First:  EPEL 8 KDE Plasma Desktop is going to stay at the releases that 
> they currently are at.  We will backport major security fixes.  Bugs and 
> bugfixes will be best effort.  But we will not do any across the board 
> updates.
> This is due to the older libraries in RHEL 8.  We've hit the limit that the 
> newer KDE versions can run on the older libraries.
> EPEL 8 will have these versions (with a few exceptions)
> plasma - 5.24
> kf5 - 5.96
> kde apps - 22.04 / 21.12 / 21.08 and some 21.04
> qt5 - 5.15
>
> **Second: We will do the across the board updates to the main epel branches 
> [2] every six months instead of once a year.  They will coincide with each 
> RHEL minor release, instead of every other RHEL minor release.
> With the last release, we found that KDE packages like to build on 
> themselves.  Meaning that some 22.04 packages needed a previous version of at 
> least 21.08 to build.  That was fine on epel-next where we had updated each 
> six months.  But when we tried to build on plain epel8 or epel9, things got 
> complicated.
> Doing a release every six months will allow users to get the newer updates 
> faster.  And although it sounds counter-intuitive, it will save the 
> maintainers time.
>
> We haven't officially made this change yet.  So if anyone sees any issues 
> and/or problems.  Please let us know.
>

I fully support this change. I think our users will benefit from this
considerably. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: python-sqlalchemy in RHEL 9.1, retirement in EPEL9

2022-12-12 Thread Neal Gompa 
On Mon, Dec 12, 2022 at 9:53 AM Nils Philippsen  wrote:
>
> Hi there,
>
> the python-sqlalchemy package has been added to RHEL 9.1 lately [1][2]
> and therefore I'll remove it from EPEL 9, as per policy [3].
>
> Mind that the latest version of the package in EPEL 9 has a higher
> version than that available in RHEL, so you’d have to downgrade it in
> order to get the official build.
>

Could you please get it upgraded for RHEL 9.2?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-next repo cleanup (both 8 and 9)

2022-11-30 Thread Neal Gompa 
On Wed, Nov 30, 2022 at 10:24 AM Troy Dawson  wrote:
>
> I have cleaned up the epel-next (both 8 and 9) repo's.
>
> If a package was newer in regular epel than in epel-next, the epel-next 
> package was untagged from epel{8,9}-next.
>
> If a package was the same version-release in both epel and epel-next, I made 
> sure the epel version was installable on CentOS Stream {8,9}, I also checked 
> that the epel-next branches were the same as the epel branch, I also checked 
> to see your building style.  If everything pointed to "remove it from 
> epel-next", I untagged the epel-next package from epel{8,9}-next.
>
> If the epel-next package was newer than what's in epel, I left them alone.
>
> The vast majority of the cleanup happened yesterday, so you should be able to 
> see a smaller epel-next repo now.
>
> If I untagged a package that you feel should be in epel-next, let me know in 
> the next week or two and I can tag them back.
> If I missed your package and you want me to untag it, also let me know.

Thanks for this Troy!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: qt5-qtbase dep problem?

2022-11-10 Thread Neal Gompa 
On Thu, Nov 10, 2022 at 3:11 PM  wrote:
>
> Hi,
>
> I have 2 systems running el8. When I run yum update qt5-qtbase I get the
> following error on both systems:
>
> (tom-lp-21 pts7) # yum update qt5-qtbase
> Updating Subscription Management repositories.
> Last metadata expiration check: 0:01:52 ago on Thu 10 Nov 2022 03:02:34 PM 
> EST.
> Error:
>   Problem: problem with installed package kf5-kxmlgui-5.88.0-1.el8.x86_64
>- package kf5-kxmlgui-5.88.0-1.el8.x86_64 requires 
> libQt5Core.so.5(Qt_5.15.2_PRIVATE_API)(64bit), but none of the providers can 
> be installed
>- package kf5-kxmlgui-5.88.0-1.el8.x86_64 requires qt5-qtbase(x86-64) = 
> 5.15.2, but none of the providers can be installed
>- cannot install both qt5-qtbase-5.15.3-1.el8.x86_64 and 
> qt5-qtbase-5.15.2-4.el8.x86_64
>- cannot install both qt5-qtbase-5.15.3-1.el8.x86_64 and 
> qt5-qtbase-5.15.2-3.el8.x86_64
>- cannot install the best update candidate for package 
> qt5-qtbase-5.15.2-4.el8.x86_64
> (try to add '--allowerasing' to command line to replace conflicting packages 
> or '--skip-broken' to skip uninstallable packages or '--nobest' to use not 
> only best candidate packages)
> (tom-lp-21 pts7) #
>
> Does anyone know how to resolve this?
>

The KDE stack needs to be rebuilt against the new Qt 5.15.3 shipped
with RHEL 8.7. I'm pretty sure Troy is on the case for that. But if
you need to work around it, you can install epel-next-release and use
its repos to upgrade properly for now.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Should we retire weechat from EPEL 7?

2022-10-06 Thread Neal Gompa 
On Thu, Oct 6, 2022 at 7:03 PM Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> We should probably retire weechat from EPEL 7 - it has multiple CVEs
> that can only be fixed by updating to versions >= 3.5, but the spec no
> longer works on EPEL 7 thanks to macros like `%cmake_build` not being
> available.
>
> https://bugz.fedoraproject.org/weechat
>
> I'm not sure either Paul or myself really care enough about EL7 to
> maintain a divergent spec. If someone does still care, PR appreciated to
> fix this, otherwise consider this the first notice that I'll retire this
> branch in a few days.
>

The cmake3 package has all the macros from the mainline cmake package in Fedora.

It should be fully compatible, just swap %cmake_* for %cmake3_*.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Orphaning EPEL Branches

2022-08-23 Thread Neal Gompa 
On Tue, Aug 23, 2022 at 9:00 PM Maxwell G  wrote:
>
> On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote:
> > > * The Pagure API does not allow tagging existing issues. I had planned to
> > > liberally use tags to manage the issues.
> >
> > What? You can do this with the "update issue information" API call:
> > https://pagure.io/api/0/#issues-tab
>
> According to the documentation, the only valid inputs to "Update issue
> information" are "title" and "issue_content". https://pagure.io/pagure/issue/
> 4761 was opened for this and never closed. Is there some undocumented
> parameter?
>

Nope, I misread this. Sorry.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Orphaning EPEL Branches

2022-08-23 Thread Neal Gompa 
On Tue, Aug 23, 2022 at 8:42 PM Maxwell G via epel-devel
 wrote:
>
> On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote:
> > On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> > > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > > > We could create an issue tracker for this. Packagers would have to
> > > > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > > > could have a provenpackager in the SIG go through and manually retire
> > > > the packages that haven't been picked up after six weeks. The later will
> > > > be difficult if we have a large volume, but I don't expect that. We
> > > > could script this if necessary or just ask the submitter to do it
> > > > themself.
> > > >
> > > > This doesn't allow picking up packages in a self-service manner, but I
> > > > don't think that's a huge deal for our case.
> >
> > After some discussion in our weekly EPEL Steering Committee meeting
> > Maxwell's idea seems to lead the way.
> > Maxwell has setup of pagure repo, to track these orphan issues.
> > A pagure repo gives us the opportunity to have a nice README that people
> > can see if they are unsure of the process.
> > A pagure issue also seems more user friendly than a bugzilla.  Both for the
> > person creating the issue, and for others tracking it.
> >
> > https://pagure.io/epel/package-orphan-requests
>
>
> So, I've started working on this. So far, I have a structured issue template,
> and I've started writing a tool to go through the issues and act on them
> (creating an announcement, etc.
> While I had originally wanted to use a Pagure issue tracker, I decided to
> switch to Gitlab half way through. There were three reasons:
>
> * The Pagure API does not allow tagging existing issues. I had planned to
> liberally use tags to manage the issues.

What? You can do this with the "update issue information" API call:
https://pagure.io/api/0/#issues-tab

This is done by the CentOS Hyperscale folks for the package-updates
tracker: https://pagure.io/centos-sig-hyperscale/package-updates

The automation for it is present in that repo.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Default for 'dnf copr enable'

2022-06-27 Thread Neal Gompa 
On Tue, Jun 28, 2022 at 12:09 AM Carl George  wrote:
>
> On Mon, Apr 11, 2022 at 8:38 AM Miroslav Suchý  wrote:
> >
> > Hi.
> > I want to get your feedback:
> >
> > When you enable Copr repository you can run:
> >dnf copr enable myname/project epel-9-x86_64
> > The last parameter is optional and most people usually runs:
> >dnf copr enable myname/project
> >
> > Dnf-plugins-core tries to guess [3] the correct chroot. On Fedora it is 
> > easy.
> > For Fedora 35 it is fedora-35-$arch.
> > But for RHEL/Centos/Centos Stream it is a bit tricky.
> >
> > E.g. for C9S we now defaults to centos-stream-9-$arch. But this gets some 
> > pushback [1,2]. I want to know if this opinion
> > is minority or whether majority of people wants this.
> > I do not think there is an option which is correct. So it is about choosing 
> > a default which is correct for most people.
> >
> > Can you please tell me what is good default for you:
> >
> > Centos Stream 9:
> > 1) epel-9-$arch
> > 2) centos-stream-9-$arch
> > 3) centos-stream+epel-next-9-$arch
> > 4) no default, print error and let user explicitly declare the chroot
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2058471
> > [2] 
> > https://gitlab.com/redhat/centos-stream/rpms/dnf-plugins-core/-/merge_requests/7
> > [3] 
> > https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/copr.py#L472
> >
> > Miroslav
> > ___
> > 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
>
> In most cases, epel-9-$arch will be the correct choice.  In the bug
> [0] it is suggested that when the guess is wrong it's simple to add
> the chroot as an explicit argument.  Instead of making the majority of
> users do `dnf copr enable  epel-9-`, why can't we have a
> tiny number of users do `dnf copr enable 
> centos-stream-9-` and have the plugin guess the correct thing
> for the majority of users?
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=2058471#c1
>

It should have never been changed to behave differently in the first
place. The only real acceptable alternative other than the main epel
chroots is to have it use epel-next chroots for CentOS Stream.
However, those are not available in COPR at this time, so we use the
EPEL ones.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Thoughts: epel-release auto-enable crb repo

2022-06-04 Thread Neal Gompa 
On Sat, Jun 4, 2022 at 10:52 PM Troy Dawson  wrote:
>
> When I first created the EPEL issue to auto-enable crb repo[1] I was only 
> thinking of CAN we do it.  I wasn't thinking SHOULD we do it.
> We've come to the point that we actually can do it.  But before we go down 
> that road, I wanted to take a step back and ask, should we do it.
>
> The more I think about it, the more I think we shouldn't auto-enable the crb 
> repo for epel8 and epel9.  Here are my reasons why.
>
> 1 - The need to auto-enable crb isn't as big as it was before.
> At the time that I wrote that issue, I was getting quite alot of bugs / pings 
> / emails about  epel packages not being installable.  I think on average 
> about 2 a month.
> With epel being in fedora-docs, and with Carl's re-write of how to enable 
> epel, that number has dropped significantly.  I possibly still average one a 
> month, but that's an average over a year, with most of them being last year.
> In short, I believe the documentation is better, and easier to find, allowing 
> people to enable crb on their own, without automation.
>
> 2 - crb isn't an epel repo
> We really shouldn't be messing with other repo's that we, epel, don't own.
>
> 3 - We are taking the choice away from users
> After I stopped and thought about it, there are plenty of scenarios where 
> people want epel for just one or two packages, which do not require crb.
>
> 4 - All the many small side cases.
> auto-enabling crb will have bugs.  RHEL and it's clones are in too many odd 
> places for us to not hit some odd use cases we didn't expect.  We'd have to 
> keep fixing the scripts.
>
> I could go into more explanation on each of those things, but in the end, 
> I've talked myself out of wanting to auto-enable crb for epel8 and epel9.
> But I also wanted to get others' thoughts before I close the bug and pull 
> request.
>
> What do others think?
>

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

I get variations of these two examples at least *once a month*.
Sometimes even filed as Bugzilla reports.

It takes time away from me doing normal work. I can easily imagine
other contributors having similar burdens. For me, this is absolutely
an annoying issue that creates enough overhead to be worth fixing.

Once you get to this level, "crb isn't an epel repo" and "we are
taking the choice away from users" is silly, because we absolutely
depend on crb being enabled and users don't know how we cross into
RHEL repos for dependencies. Heck, many packagers building for EPEL
don't. Even worse, some RHEL folks don't realize how difficult it is
to use RHEL without CRB.

The worst thing that could happen with auto-enabling is that it fails
to run. We can easily just put some output when it fails to tell users
that CRB/PowerTools could not be auto-enabled and for users to ensure
it's enabled. But *not* attempting to auto-enable it means we accept
that RHEL's bad choices on this are impossible to work around. It
would be more tolerable if CentOS Stream had CRB content available by
default like how CentOS Linux 7 has the content from the RHEL 7
optional channel available by default. Sadly, every attempt to make
that happen has failed. Thus, CentOS Stream and RHEL clones (which are
effectively clones of CentOS Stream) don't do it, so we have a
usability problem that causes pain for contributors and users.

To be crystal clear, I would like this fixed for at least the majority
of cases and gracefully fail when it can't be fixed.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: How to remove builds from EPEL 9 Next?

2022-05-27 Thread Neal Gompa 
On Fri, May 27, 2022 at 8:00 AM Miro Hrončok  wrote:
>
> Hey EPEL folks,
>
> The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as
> the frozen set of packages from CentOS Stream made it segfault during build.
>
> So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next.
>
> Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in 
> the
> meantime).
>
> So, we should probbaly build and ship the package in EPEL 9.
> But we should also remove/obsolete/replace the EPEL 9 build somehow.
>
> I suppose there are multiple options here:
>
>
> 1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next
> 2. build in epel9, untag the old epel9-next build
>

Generally, you bump to raise the EVR and then the automation Troy has
can untag everything in EPEL next that's lower than what's in EPEL.

>
> What is the general guideline in this situation?
>
> Related, but not necessarily blocking question: Should EPEL 9 Next be purged
> after each RHEL 9.Y release and all the purged builds built in regular EPEL 9
> instead?
>

Yes, please, for the sake of my mirror hosting space...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: ABI-break changes in CentOS and EPEL dependencies

2022-05-02 Thread Neal Gompa 
On Mon, May 2, 2022 at 9:04 AM Petr Menšík  wrote:
>
> Hi.
>
> I had a discussion about AlmaLinux Beta on root.cz. Some person
> complained CentOS Stream is unusable, because it is breaking ABI of
> packages. He got libpoppler as an example.
>
> I just thought, we have all public code changes on GitLab. Could we mark
> MR containing ABI breaks in a special way? It might help catching those
> changes sooner by maintainers of dependent packages.
>
> If EPEL package depends on rebased CentOS package, is there a good way
> how to handle synchronization to EPEL rebuilds or even rpmfusion
> depending builds? Would some automation helping with this make sense? Is
> it rare enough that it does not need any automatic processing?
>
> I thought if MR were marked with special tag, maybe on its merge some
> bot could open bugzillas or even open PR on depending packages with just
> bumpspec to rebuild. Do you think it would be worth the effort? Does it
> have better alternative?
>

ABI breakages can be detected in CI and noted in some way. That would
be in Zuul, which already runs a bunch of checks.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Qt update and packages rebuild

2022-04-29 Thread Neal Gompa 
On Fri, Apr 29, 2022 at 3:42 PM Troy Dawson  wrote:
>
> On Fri, Apr 29, 2022 at 11:28 AM Germano Massullo 
>  wrote:
>>
>> Recent CentOS Stream Qt update broke some EPEL packages like keepassxc
>> that needed a rebuild against the new Qt version.
>> Can we talk about a way to prevent this from happening again?
>>
>> Best regards
>
>
> Looking at  keepassxc specifically, I'd say take the following line out of 
> the spec file.
>   %{?_qt5:Requires: %{_qt5}%{?_isa} = %{_qt5_version}}
>

This macro is only supposed to be used if the program uses private Qt5
APIs. Unfortunately, according to BRs, it does, so this macro makes
sense to keep.

But someone should talk to upstream and ask why it's using private APIs...




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Does EPEL 9 Koji have older c9s packages than local mock?

2022-04-22 Thread Neal Gompa 
On Fri, Apr 22, 2022 at 2:22 PM Miro Hrončok  wrote:
>
> Hello,
>
> I've been trying to debug a segfault during %check that only occurs in epel9
> Koji, but not in mock.
>
> At the end, I compared the list of packages with:
>
> $ koji list-buildroot 34845388 | sort > koji
> $ mock -r centos-stream+epel-9-x86_64 shell -- rpm -qa | sort > mock
> $ diff -u koji mock | grep -v ' '
> +acl-2.3.1-3.el9.x86_64
> -audit-libs-3.0.7-101.el9.x86_64
> +audit-libs-3.0.7-102.el9.x86_64
> -binutils-gold-2.35.2-17.el9.x86_64
> -binutils-2.35.2-17.el9.x86_64
> +binutils-gold-2.35.2-19.el9.x86_64
> +binutils-2.35.2-19.el9.x86_64
> -centos-gpg-keys-9.0-9.el9.noarch
> -centos-stream-release-9.0-9.el9.noarch
> -centos-stream-repos-9.0-9.el9.noarch
> +centos-gpg-keys-9.0-12.el9.noarch
> +centos-stream-release-9.0-12.el9.noarch
> +centos-stream-repos-9.0-12.el9.noarch
> -crypto-policies-20220203-1.gitf03e75e.el9.noarch
> +crypto-policies-20220404-1.git845c0c1.el9.noarch
> +cryptsetup-libs-2.4.3-4.el9.x86_64
> -cyrus-sasl-lib-2.1.27-19.el9.x86_64
> +cyrus-sasl-lib-2.1.27-20.el9.x86_64
> +dbus-broker-28-5.el9.x86_64
> +dbus-common-1.12.20-5.el9.noarch
> +dbus-1.12.20-5.el9.x86_64
> +device-mapper-libs-1.02.183-4.el9.x86_64
> +device-mapper-1.02.183-4.el9.x86_64
> -elfutils-debuginfod-client-0.186-1.el9.x86_64
> -elfutils-default-yama-scope-0.186-1.el9.noarch
> -elfutils-libelf-0.186-1.el9.x86_64
> -elfutils-libs-0.186-1.el9.x86_64
> -elfutils-0.186-1.el9.x86_64
> -epel-release-9-2.el9.noarch
> +elfutils-debuginfod-client-0.186-3.el9.x86_64
> +elfutils-default-yama-scope-0.186-3.el9.noarch
> +elfutils-libelf-0.186-3.el9.x86_64
> +elfutils-libs-0.186-3.el9.x86_64
> +elfutils-0.186-3.el9.x86_64
> -expat-2.2.10-9.el9.x86_64
> -fedpkg-minimal-1.2.0-4.el9.noarch
> +expat-2.2.10-10.el9.x86_64
> -flexiblas-netlib-3.0.4-7.el9.x86_64
> -flexiblas-openblas-openmp-3.0.4-7.el9.x86_64
> -flexiblas-3.0.4-7.el9.x86_64
> +flexiblas-netlib-3.0.4-8.el9.x86_64
> +flexiblas-openblas-openmp-3.0.4-8.el9.x86_64
> +flexiblas-3.0.4-8.el9.x86_64
> -glibc-common-2.34-25.el9.x86_64
> -glibc-gconv-extra-2.34-25.el9.x86_64
> -glibc-minimal-langpack-2.34-25.el9.x86_64
> -glibc-2.34-25.el9.x86_64
> +glibc-common-2.34-29.el9.x86_64
> +glibc-gconv-extra-2.34-29.el9.x86_64
> +glibc-minimal-langpack-2.34-29.el9.x86_64
> +glibc-2.34-29.el9.x86_64
> -gnutls-3.7.3-6.el9.x86_64
> +gnutls-3.7.3-9.el9.x86_64
> +gpg-pubkey-3228467c-613798eb
> +gpg-pubkey-8483c65d-5ccc5b19
> -krb5-libs-1.19.1-13.el9.x86_64
> +kmod-libs-28-7.el9.x86_64
> +krb5-libs-1.19.1-15.el9.x86_64
> -libgcc-11.2.1-9.4.el9.x86_64
> -libgcrypt-1.10.0-2.el9.x86_64
> -libgfortran-11.2.1-9.4.el9.x86_64
> -libgomp-11.2.1-9.4.el9.x86_64
> +libgcc-11.2.1-10.el9.x86_64
> +libgcrypt-1.10.0-3.el9.x86_64
> +libgfortran-11.2.1-10.el9.x86_64
> +libgomp-11.2.1-10.el9.x86_64
> -libquadmath-11.2.1-9.4.el9.x86_64
> +libquadmath-11.2.1-10.el9.x86_64
> +libseccomp-2.5.2-2.el9.x86_64
> -libstdc++-11.2.1-9.4.el9.x86_64
> +libstdc++-11.2.1-10.el9.x86_64
> -libxml2-2.9.12-4.el9.x86_64
> +libxml2-2.9.13-1.el9.x86_64
> -openblas-openmp-0.3.15-2.el9.x86_64
> +openblas-openmp-0.3.15-3.el9.x86_64
> -openblas-0.3.15-2.el9.x86_64
> -openldap-2.4.59-3.el9.x86_64
> -openssl-libs-3.0.1-12.el9.x86_64
> -openssl-3.0.1-12.el9.x86_64
> +openblas-0.3.15-3.el9.x86_64
> +openldap-2.4.59-4.el9.x86_64
> +openssl-libs-3.0.1-18.el9.x86_64
> +openssl-3.0.1-18.el9.x86_64
> -pyproject-rpm-macros-1.0.0~rc1-1.el9.noarch
> +pyproject-rpm-macros-1.0.1-1.el9.noarch
> -systemd-libs-250-3.el9.x86_64
> +systemd-libs-250-4.el9.x86_64
> +systemd-pam-250-4.el9.x86_64
> +systemd-rpm-macros-250-4.el9.noarch
> +systemd-250-4.el9.x86_64
> -tpm2-tss-3.0.3-7.el9.x86_64
> -zlib-1.2.11-31.el9.x86_64
> +zlib-1.2.11-32.el9.x86_64
>
> This seems like my local mock has newer c9s packages than the Koji build repo.
> Is that expected, or is pulling c9s packages into the build repo stuck on Koji
> side?
>
> Actually, I got an idea that EPEL 9 Koji might already be using (internal?)
> RHEL 9.0, possibly I have missed this switch... However, the
> centos-stream-release package contraditcs taht idea :/
>
> I've checked with an EPEL 9 Next Koji scratchbuild and it got e.g.
> pyproject-rpm-macros-1.0.1-1.el9.

EPEL 9 is frozen on the Feb 24 compose for CentOS Stream 9 until RHEL 9 GA.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Modules for EPEL9

2022-03-24 Thread Neal Gompa 
On Thu, Mar 24, 2022 at 6:38 PM Kevin Fenzi  wrote:
>
> On Thu, Mar 24, 2022 at 07:56:15AM -0700, Troy Dawson wrote:
> > It was talked about December 2021, and pushed off to the new year.
> > https://pagure.io/epel/issue/135
> > It's the new year, and you are the first this year to ask for it.  So, time
> > to get it back in the discussions.
> > Could you please put what modules you want to build in that ticket, so we
> > can help prioritize it.
>
> Personally, I'd be happy just not doing modules at all for epel9 given
> the limitations we have (cannot build any module that requires rhel
> modules). I'd prefer we have folks just use compatiblity packages
> instead.
>

What's stopping us from being able to depend on RHEL modules? Koji now
supports enabling module streams on a per tag basis, so it *should* be
possible now.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2022-03-04 Thread Neal Gompa 
On Fri, Mar 4, 2022 at 6:01 AM 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?
>
> (Insert here my monthly request that there be a single source of truth
> about packages.)

If you already had a ACKed BZ/Jira for these, you can probably
reference that and make the necessary merge requests to comps[1] and
pungi[2].

[1]: https://gitlab.com/redhat/centos-stream/release-engineering/comps
[2]: https://gitlab.com/redhat/centos-stream/release-engineering/pungi-centos



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL-8 Packages needing care and feeding

2022-03-03 Thread Neal Gompa 
On Thu, Mar 3, 2022 at 10:36 AM Stephen John Smoogen  wrote:
>
>
> OK with some help from Miro on the python team, I was able to use the scripts 
> they use regularly to list what dependency problems they have with soon to be 
> orphaned packages. I have included the entire report as an attachment as its 
> big, but the following seem to be packages I could retire now without 
> breaking current packages:
>
[...]
> python-openid-cla puiterwijk 238 weeks ago
> python-openid-teams puiterwijk 238 weeks ago

These two are used for Pagure to support SSO.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2022-03-02 Thread Neal Gompa 
On Wed, Mar 2, 2022 at 8:52 AM Richard W.M. Jones  wrote:
>
> To keep this a bit more specific, we're trying to build coccinelle for
> EPEL 9.  This requires ocaml [compiler] and a bunch of ocaml packages.
> They are mainly in RHEL buildroot.
>
> The problem we're going to have (which to be fair is a problem
> somewhat specific to OCaml linking) is that an alternate OCaml
> compiler built for EPEL will have different hash values[1] for core
> libraries.
>
> If we use a different version from the RHEL compiler, say we use
> Fedora Rawhide version, then all the hashes will be different.
>
> If we use the same version as in RHEL, then most hash values will be
> the same, but if the compiler flags are even slightly different then
> there will be some differences.
>
> OCaml libraries in RHEL that we do ship (ocaml-libnbd and others) will
> not be linkable with code compiled with the EPEL toolchain.
>
> It's entirely possible we don't care about this, and I maybe even
> agree.  But also that people using RHEL with EPEL added will get into
> weird situations if they try to recompile the virt tools packages.
>
> Rich.
>
> [1] Hash values are computed over the modules to prevent linking
> incompatible versions:
>
> $ ocamlobjinfo /usr/lib64/ocaml/unix.cma  | grep Unix
> Unit name: Unix
>  49c6c492a189deeaed5bf77a6793e7fa   Unix
>
> and turned into RPM dependencies:
>
> $ rpm -qR ocaml | grep Unix
> ocaml(Unix) = 49c6c492a189deeaed5bf77a6793e7fa
>

So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
like it would be very beneficial to have it there.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2022-03-01 Thread Neal Gompa 
On Tue, Mar 1, 2022 at 8:20 AM Richard W.M. Jones  wrote:
>
> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones  wrote:
> > >
> > >
> > >   https://bugzilla.redhat.com/show_bug.cgi?id=2058274
> > >
> > > fails to build with:
> > >
> > >   DEBUG util.py:444:  No matching package to install: 'ocaml-dune >= 1.0'
> > >
> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
> > >
> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> > > This seems crazy, is it really correct?
> > >
> >
> > It's not crazy. EPEL is intended to build on RHEL content, which means
> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
> > publish their buildroot repo, then sure, we could use it.
>
> I wasn't very clear, but I was addressing my remark at Red Hat.
> There's really no reason why we (Red Hat) don't publish buildroot, in
> fact my personal view is we ought to for open source reasons.
>
> > Just because it happens to exist in the CentOS Stream 9 buildroot
> > content does not mean we would be able to rely on it once we replace
> > CentOS Stream with RHEL for EPEL 9. Thus, we don't use the CentOS
> > Stream 9 buildroot either.
>
> So this was going to be my next question - is it that difficult to use
> C9S buildroot packages to replace the "missing" ones?  AFAIK they
> ought to be almost identical.  Obviously they are rebuilds and they
> might be a little out of sync, but saves EPEL doing a literal third
> rebuild of the same content!
>

Theoretically, yes. And for some stuff, that would work. It depends on
how sensitive things are and where they lie in the dependency chain.

> > If we did, we'd wind up in a situation where packages were built once
> > and then not buildable ever again. That already kind of happened when
> > we initially had that buildroot repo in the EPEL build environment and
> > it made it way harder for us to figure out what gaps we had for things
> > to build against RHEL later. We've fortunately dealt with the small
> > number of cases that occurred from then.
>
> I'm not sure I totally understand this bit.  Is it right to say that
> packages wouldn't be "buildable ever again" only in the case where we
> used C9S buildroot and then dropped it?  If we just use C9S buildroot
> packages + RHEL 9 packages - forever - we'd be OK?
>

Those packages are not necessarily guaranteed to be installable
forever because they're effectively only there as a side-effect. But
it's *possible* we'd be fine.

There is another issue with using buildroot packages: they're not
signed and mirrored at all. There's no reasonable way to expect
downstreams to be able to figure out how to build our packages with
any reasonable trust. People already don't like the fact that RHEL
doesn't do it, I think they'd be extremely upset if it led to EPEL
packages that people couldn't easily locally (re)build and update.
It's also more common for EPEL packagers to be in environments where
unsigned content is simply flat out blocked by policy, so RPM would
trip up over installing those packages.

And yay supply chain attacks! :(




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

2022-03-01 Thread Neal Gompa 
On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones  wrote:
>
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>
> fails to build with:
>
>   DEBUG util.py:444:  No matching package to install: 'ocaml-dune >= 1.0'
>
> This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>
> I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
> disappearing from the EPEL 9 buildroot") and it seems to indicate that
> RHEL 9 buildroot packages aren't going to be available in EPEL 9.
> This seems crazy, is it really correct?
>

It's not crazy. EPEL is intended to build on RHEL content, which means
we can't depend on something RHEL doesn't publish. If Red Hat wants to
publish their buildroot repo, then sure, we could use it. Just because
it happens to exist in the CentOS Stream 9 buildroot content does not
mean we would be able to rely on it once we replace CentOS Stream with
RHEL for EPEL 9. Thus, we don't use the CentOS Stream 9 buildroot
either.

If we did, we'd wind up in a situation where packages were built once
and then not buildable ever again. That already kind of happened when
we initially had that buildroot repo in the EPEL build environment and
it made it way harder for us to figure out what gaps we had for things
to build against RHEL later. We've fortunately dealt with the small
number of cases that occurred from then.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Does EPEL 9 maintain upgrade path from EPEL 8?

2022-02-19 Thread Neal Gompa 
On Sat, Feb 19, 2022 at 3:21 PM Miro Hrončok  wrote:
>
> Hello,
>
> I have a Fedora package that I've recently also branched for EPEL 9.
>
> The (so called) binary package used to be called "python3-tox", but has been
> renamed to "tox" in Fedora 34. All supported Fedora versions and EPEL 9 have
> the package named as "tox". The package has:
>
>  %py_providespython3-tox
>  # Remove this once Fedora 36 goes EOL:
>  Obsoletes:  python3-tox < 3.24.4-2
>
> However, the EPEL 8 package is still called python3-tox.
>
> Once I remove the Obsoletes line from Fedora, should I worry about merging 
> that
> commit to the epel9 branch or not? Logic dictates that the Obsolete should
> remain in EPEL 9 forever, but I wonder if there is a policy/rule of thumb. 
> E.g.
> in Fedora, we only support upgrades to Fedora N+2. Do we support upgrades of
> EL+EPEL systems as well and how "far"?
>

Ideally, we support EL X-1 -> EL X. So EPEL9 *should* upgrade EPEL8
packages, but I don't know if we enforce this.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL 9: Interested in fails to install reports?

2022-01-27 Thread Neal Gompa 
On Thu, Jan 27, 2022 at 7:37 AM Miro Hrončok  wrote:
>
> Hello EPEL,
>
> would you be interested in automated bugzilla reports for EPEL 9 packages that
> fail to install in the buildroot? Or is it too soon?
>
> When testing upcoming changes in c9s we have found out some packages (e.g.
> ansible-lint) were imported and built in epel9 but they miss runtime
> dependencies (and requests for them don't even exists in bugzilla).
>
> The automated bugzillas could be used to mark blocking the eple9 package
> requests and generally help track things better.
>

I think those would be nice to have, but we don't even run those
checks when updates are submitted in Bodhi. :(

I wish those checks were run so we knew sooner. :(


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Bodhi failure for EPEL9 Build

2022-01-22 Thread Neal Gompa 
On Sat, Jan 22, 2022 at 9:28 PM Frank Crawford  wrote:
>
> Folks,
>
> Any idea what is going on here?  I'm trying to push an update for a
> package (s3cmd) to EPEL9.  The original package worked fine a few weeks
> ago, but this fix is being failed after a day or so sitting testing
> state with the following message:
>
> bodhi - 2022-01-23 02:00:24.585391 (karma: 0)
> FEDORA-EPEL-2022-2454913940 ejected from the push because "Cannot find
> relevant tag for s3cmd-2.2.0-2.el9.  None of ['epel9-testing', 'epel9-
> testing-pending'] are in ['epel9-next-testing-candidate', 'epel7-
> testing-candidate', 'dist-5E-epel-testing-candidate', 'f27-modular-
> updates-candidate', 'f34-container-updates-candidate', 'eln-updates-
> candidate', 'f30-modular-updates-candidate', 'f28-modular-updates-
> candidate', 'f28-container-updates-candidate', 'f30-container-updates-
> candidate', 'epel8-testing-candidate', 'f30-flatpak-updates-candidate',
> 'f35-container-updates-candidate', 'f32-modular-updates-candidate',
> 'f29-modular-updates-candidate', 'f29-container-updates-candidate',
> 'f29-flatpak-updates-candidate', 'f22-updates-candidate', 'f21-updates-
> candidate', 'f25-updates-candidate', 'f24-updates-candidate', 'f23-
> updates-candidate', 'f26-updates-candidate', 'f31-modular-updates-
> candidate', 'dist-6E-epel-testing-candidate', 'f32-flatpak-updates-
> candidate', 'f35-flatpak-updates-candidate
>  ', 'f27-updates-candidate', 'f28-updates-candidate', 'f30-updates-
> candidate', 'f29-updates-candidate', 'el8-modular-updates-candidate',
> 'f32-updates-candidate', 'epel9-testing-candidate', 'f31-updates-
> candidate', 'f31-container-updates-candidate', 'f31-flatpak-updates-
> candidate', 'f34-updates-candidate', 'f34-modular-updates-candidate',
> 'f34-flatpak-updates-candidate', 'f36-container-updates-candidate',
> 'f32-container-updates-candidate', 'epel8-next-testing-candidate',
> 'f35-updates-candidate', 'f35-modular-updates-candidate', 'f33-updates-
> candidate', 'f36-updates-candidate', 'f33-modular-updates-candidate',
> 'f33-container-updates-candidate', 'f33-flatpak-updates-candidate']."
>
> Yet if I look at the EPEL9 properties in bohdi, the two tags exit?
>
> It has happened twice for this job?
>

It looks like this issue? https://pagure.io/releng/issue/10583

You might want to put a comment to note yours there.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: The incredibly shrinking RHEL

2022-01-14 Thread Neal Gompa 
On Fri, Jan 14, 2022 at 7:27 AM Leon Fauster via epel-devel
 wrote:
>
> Am 14.01.22 um 13:02 schrieb Josh Boyer:
> > A fairly accurate list of packages removed in RHEL 9 can be found in
> > our RHEL 9 Adoption documentation:
> >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages
>
>
> It seems that RH does not see RHEL as workstation OS anymore.
> Many tools were/will be removed. I do not need to be bright to
> anticipate that in the future (e.g. RHEL11) the trouble will
> prevails the benefit. EPEL QA is better then ever but it will
> not fill the gap. Thats like swimming agains the stream. Unless
> RH incorporates EPEL into his strategies. Like keeping the volume
> of packages officially and just shifting the borders ... thought.
>

I think that's an unfair characterization. While it's certainly true
that RHEL focuses on server workloads (it's easily an order of
magnitude more sales than workstation ones), it's also true that Red
Hat is *finally* investing in EPEL. This is the *first* RHEL release
where Red Hat is *directly* investing in helping the community bring
up EPEL. The RHEL folks are giving us a path to request packages as
needed from being buildroot-only (thus internal to non-public RHEL
Koji) to published repositories (thus usable by EPEL and
third-parties).

I *personally* have done this now many times with great success, and
the consequence of that is we're able to get content into EPEL faster
than ever before. We're even going to be ready for the RHEL 9.0 GA,
which is something we've never had before.

If you want Red Hat to care more about workstation workloads, then buy
Red Hat Enterprise Linux Workstation[1]. It's not that expensive and
you get support from Red Hat if you pay for standard support. As a
good friend recently said: "Red Hat is coin-operated". Give them
coins, and magic will happen. :)

And for what it's worth, I think Red Hat Enterprise Linux 9 is shaping
up to be a fantastic workstation. It may not be as good as Fedora
Linux at it, but it's head and shoulders better than all the rest.

Can RHEL do better? Absolutely! But let's give credit where it's due:
this is substantially better than three years ago with RHEL 8.

[1]: https://www.redhat.com/en/store/red-hat-enterprise-linux-workstation




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Systemd Units - Build Requires

2022-01-06 Thread Neal Gompa 
On Thu, Jan 6, 2022 at 12:44 PM Salman via epel-devel
 wrote:
>
> Hi All
> I was wanting to confirm what is proper "BuildRequire" for packages with 
> systemd units when using macros %{_unitdir} or %{_userunitdir}
> 
> Should it be simply :
> BuildRequires: systemd
> OR
> BuildRequires: systemd-rpm-macros
>
> Reference: 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/#packaging_filesystem
>

For EPEL 8 and higher, "systemd-rpm-macros" is correct. For EPEL 7,
you'll need "systemd" instead.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Status of python-gevent in EL9

2022-01-04 Thread Neal Gompa 
On Tue, Jan 4, 2022 at 9:45 AM Troy Dawson  wrote:
>
>
>
> On Wed, Dec 29, 2021 at 7:30 AM Stephen John Smoogen  wrote:
>>
>>
>>
>> On Wed, 29 Dec 2021 at 10:19, Orion Poplawski  wrote:
>>>
>>> Can someone shed light on the status of python-gevent in EL9?  It seems
>>> to have been built for CS9:
>>>
>>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=3414
>>>
>>> (though perhaps not tagged?)
>>>
>>> but builds for EPEL9 fail to find it:
>>>
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=80607754
>>>
>>
>> This is a RHEL/CentOS Stream buildroot only package. It is only available in 
>> the koji buildroot and will not be shipped. An equivalent package will need 
>> to be built in EPEL to make builds work.
>
>
> I'm not even sure it's in the buildroot.
> One quick thing to look at is the tags of the builds.
> If you look at both of the builds, you will see that they have no tags.
> This is an indication that at some point the package was built for RHEL9, but 
> has been taken out.
>

python-gevent was retired months ago:
https://gitlab.com/redhat/centos-stream/rpms/python-gevent/-/commit/73165a8ecd3da98543292a9aa4f6924029a1d651



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: GIMP future in RHEL-9

2022-01-03 Thread Neal Gompa 
On Mon, Jan 3, 2022 at 4:46 AM Josef Řídký  wrote:
>
> Hi folks,
>
> just want to send some heads up info about the GIMP package in the RHEL-9 
> release.
>
> As some of you might notice, the GIMP package is missing in RHEL-9. The 
> reason for this is it's requirement of Python 2, which isn't supported in 
> RHEL-9 any more.
>
> During the RHEL-9 prep phase, I gave the information that GIMP authors are 
> working on a new GIMP 3 release, which is going to use Python 3 and once the 
> GIMP 3 is released, the GIMP package will appear in RHEL-9 again.
>
> Carrying this in mind I would like to ask you - *don't* create a gimp branch 
> for EPEL9 as it would create additional problems later once the GIMP 3 is 
> available.
>
> Thank you for your understanding and wish you all the best in 2022.
>

Thanks for letting us know, Josef!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Heads-up: trousers (TPM 1.2) silently orphaned

2021-12-18 Thread Neal Gompa 
On Sat, Dec 18, 2021 at 1:13 PM Adam Williamson
 wrote:
>
> On Fri, 2021-12-17 at 10:35 -0800, Michel Alexandre Salim wrote:
> > On Thu, Dec 16, 2021 at 10:11:53AM -0800, Michel Alexandre Salim wrote:
> > > Hi all,
> > >
> > > `trousers` got silently orphaned around the time an EPEL9 branch for it
> > > was requested: https://bugzilla.redhat.com/show_bug.cgi?id=2032258
> > >
> > > Looks like we're slowly uncoupling ourselves from it, e.g.
> > >
> > > - for ARM, uboot-tools no longer pulls in vboot-utils which pulls in
> > >   trousers: 
> > > https://lists.fedoraproject.org/archives/list/scm-comm...@lists.fedoraproject.org/message/JAAC32MNLJMMENVJG7QUSKHGZFABLUHX/
> > >
> > > - Neal disabled TPM/TSS 1.2 support in strongswan, dropping the trousers
> > >   dependency, in 
> > > https://src.fedoraproject.org/rpms/strongswan/pull-request/13
> > >
> > > but there are several dependencies still around (strongswan still shows
> > > up here as the PR just got merged a few hours ago)
> > >
> > I've taken this package for now.
> >
> > It's probably OK for most of the trousers dependent to drop their
> > dependencies on it though, the use case I have in mind is rather
> > specialized.
>
> It does seem to be used by robosignatory (the thing that signs Fedora
> packages, I think):
>
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/robosignatory/tasks/main.yml#_6

Well, then, I guess it's good that it has a maintainer now...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Requesting branches for epel9

2021-12-16 Thread Neal Gompa 
On Thu, Dec 16, 2021 at 6:26 AM Matthew Miller  wrote:
>
> On Tue, Dec 14, 2021 at 06:31:04AM -0500, Stephen John Smoogen wrote:
> > > Where is that checklist? I found
> > I don't know myself.
>
> Fair -- a lot of this stuff is individual experience and wisdom that we
> haven't recorded, but need to.
>
>
> > > But it seems like "request an EPEL branch" should generally be either 
> > > "Okay!
> > > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are the
> > > other cases?
> >
> > As far as I know this isn't about requesting EPEL branches, as much as
> > requesting any branches by hand. If I add something to Fedora rawhide
> > and then ask for a F34 branch, the same issues can happen. Remember
> > our build infrastructure is a pile of band-aids on top of duct tape on
> > top of bungee cords. Lots of tools are written for a toolchain which
> > existed years ago and have been hacked to make it work with whatever
> > new initiative that comes into play. 'Unexpected' side effects and
> > corner cases happen all the time and the fixing of them tends to add
> > new ones.
>
> Sure. But also, asking people to spend a lot of their time running
> grunt-work tasks means that they have less time to fix when things break,
> let alone re-engineer away some of that tech debt. It seems like we should
> be able to automate the simple cases (adding F34 and F35 branches should be
> even easier, since we don't have the "is it in EL?" question even).
>

It is also possible to automate the "is it in EL?" question too, since
we now have access to a Koji instance we can query for that
information. According to the CentOS Stream 9 contributor guide[1], if
it's in c9s-compose, then it's published content.

[1]: 
https://docs.centos.org/en-US/stream-contrib/quickstart/#_whats_going_on_with_package_x



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Builds for EPEL9

2021-12-13 Thread Neal Gompa 
On Mon, Dec 13, 2021 at 6:13 AM Troy Dawson  wrote:
>
>
>
> On Sat, Dec 11, 2021 at 1:58 AM Frank Crawford  
> wrote:
>>
>> Folks,
>>
>> I'm looking at building a package that currently exists in EPEL8 for
>> EPEL9.  I have a new branch epel9 branch for my package, but when I try
>> to do a mock build or scratch build it fails with the error:
>>
>> Error: Error downloading packages:
>>   Status code: 404 for
>> https://infrastructure.fedoraproject.org/repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesystem-11-13.el9.noarch.rpm
>> (IP: 38.145.60.16)
>>
>> Am I doing anything wrong here, is it just that we can't currently
>> build for EPEL9?
>
>
> You certainly can build for epel9.
> But you haven't said what command(s) you are doing that gives that output.
> Let us know what you are doing, and that will make it possible for us to help.
>

I have the same problem using fedpkg-1.41-2.fc35.

Using "fedpkg --release epel9 mockbuild" fails with that error
consistently. I tried to test builds of a couple of packages locally
before doing branch requests and I couldn't.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed

2021-11-29 Thread Neal Gompa 
On Mon, Nov 29, 2021 at 9:04 AM Matthew Miller  wrote:
>
> On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote:
> > If Fedora and EPEL were to have older versions, we'd have to have a
> > dedicated CDN endpoint for them, because mirrors would seriously have
> > trouble taking it.
>
> How often would such packages be used? If we had a non-default repo
> available but not enabled by default, it could be optional to mirror and
> probably still be okay.
>

I suspect it would be fairly heavily used. There are significant
benefits to having those:

* DeltaRPM would be considerably more useful
* "dnf history undo" would actually work

We could make it non-default and tell people that rollbacks require an
--enablerepo= option, though.

Having its own mirror module would also give mirrors the ability to
opt in, and I wouldn't be surprised if a good chunk of them do.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed

2021-11-29 Thread Neal Gompa 
On Mon, Nov 29, 2021 at 6:42 AM Stephen John Smoogen  wrote:
>
> On Sun, 28 Nov 2021 at 19:32, Nico Kadel-Garcia  wrote:
> >
> > On Sun, Nov 28, 2021 at 7:06 PM Neal Gompa  wrote:
> > >
> > > On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia  
> > > wrote:
> > > >
> > > > On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa  wrote:
> > > > >
> > > > > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia  
> > > > > wrote:
> > > > > >
> > > > > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  
> > > > > > wrote:
> > > > > > >
> > > > > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > > > > > > Hello Fedora EPEL maintainers!
> > > > > > > >
> > > > > > > > First I don't feel comfortable announcing this, I'm not happy 
> > > > > > > > about the
> > > > > > > > situation and so I don't want to be the lightning rod :-).  But 
> > > > > > > > I believe
> > > > > > > > that we can come to acceptable Copr/Mock solution and this 
> > > > > > > > needs to be
> > > > > > > > discussed...  so here we are.
> > > > > > > >
> > > > > > > > By the end of the year 2021 we have to fix our default EPEL 8 
> > > > > > > > Mock
> > > > > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) 
> > > > > > > > as CentOS 8
> > > > > > > > goes EOL by then.
> > > > > > >
> > > > > > >
> > > > > > > I wrote down the possible options and their pros and cons and I 
> > > > > > > done my best to catch all the feedback here.
> > > > > > >
> > > > > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> > > > > > >
> > > > > > > Miroslav
> > > > > >
> > > > > > That seems to be a succinct listing. I think you left out my
> > > > > > suggestion.of "support people re-inventing point releases for 
> > > > > > CentOS",
> > > > > > which is what major CentOS users will do using internal mirrors. due
> > > > > > to concern about unexpected and unwelcome updates of CentOS Stream,
> > > > > > while they assess whether AlmaLinux or Rocky are reliable and stable
> > > > > > enough to use. It's not an uncommon behavior for EPEL itself, partly
> > > > > > because of EPEL's bad habit of deleting RPMs without warning and
> > > > > > stripping out all previous releases. That's caused me problems with
> > > > > > chromium and firefox when updates were incompatible with 
> > > > > > contemporary
> > > > > > regression testing systems.
> > > > > >
> > > > >
> > > > > It's not a "bad habit", it happens because when packages are retired,
> > > > > keeping the packages there does a disservice to the community by
> > > > > effectively forcing a maintenance burden when there's no maintainer.
> > > > > As for stripping out previous releases, that's just how Pungi and
> > > > > Bodhi do update composes at the moment. Someday that'll be fixed, but
> > > > > then we'd have to come up with a policy on how many because there are
> > > > > storage concerns for mirrors if we kept everything published forever.
> > > >
> > > > It causes problems and confusion for people who need to lock down
> > > > evisting versions for deployment. And it happens for packages that are
> > > > not retired, but merely updated. I was bitten by it myself with
> > > > chromium updates last year. It forces users of EPEL to maintain
> > > > internal repos, or out of band access to previously accessible RPMs.
> > > > It's destabilizing and breaks the use of bills-of-material based
> > > > deployments with complete lists of all desired RPMs.
> > > >
> > > > Storage and bandwidth concerns are legitimate concerns, as is
> > > > potentially continuing to publish older releases with known
> > > > vulnerabilities or bugs.  But neither Fedora nor RHEL simply discard
> > > > pre

[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-28 Thread Neal Gompa 
On Thu, Nov 25, 2021 at 2:02 PM Nico Kadel-Garcia  wrote:
>
> On Thu, Nov 25, 2021 at 8:26 AM Neal Gompa  wrote:
> >
> > On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia  wrote:
> > >
> > > On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  wrote:
> > > >
> > > > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > > > Hello Fedora EPEL maintainers!
> > > > >
> > > > > First I don't feel comfortable announcing this, I'm not happy about 
> > > > > the
> > > > > situation and so I don't want to be the lightning rod :-).  But I 
> > > > > believe
> > > > > that we can come to acceptable Copr/Mock solution and this needs to be
> > > > > discussed...  so here we are.
> > > > >
> > > > > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > > > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as 
> > > > > CentOS 8
> > > > > goes EOL by then.
> > > >
> > > >
> > > > I wrote down the possible options and their pros and cons and I done my 
> > > > best to catch all the feedback here.
> > > >
> > > > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> > > >
> > > > Miroslav
> > >
> > > That seems to be a succinct listing. I think you left out my
> > > suggestion.of "support people re-inventing point releases for CentOS",
> > > which is what major CentOS users will do using internal mirrors. due
> > > to concern about unexpected and unwelcome updates of CentOS Stream,
> > > while they assess whether AlmaLinux or Rocky are reliable and stable
> > > enough to use. It's not an uncommon behavior for EPEL itself, partly
> > > because of EPEL's bad habit of deleting RPMs without warning and
> > > stripping out all previous releases. That's caused me problems with
> > > chromium and firefox when updates were incompatible with contemporary
> > > regression testing systems.
> > >
> >
> > It's not a "bad habit", it happens because when packages are retired,
> > keeping the packages there does a disservice to the community by
> > effectively forcing a maintenance burden when there's no maintainer.
> > As for stripping out previous releases, that's just how Pungi and
> > Bodhi do update composes at the moment. Someday that'll be fixed, but
> > then we'd have to come up with a policy on how many because there are
> > storage concerns for mirrors if we kept everything published forever.
>
> It causes problems and confusion for people who need to lock down
> evisting versions for deployment. And it happens for packages that are
> not retired, but merely updated. I was bitten by it myself with
> chromium updates last year. It forces users of EPEL to maintain
> internal repos, or out of band access to previously accessible RPMs.
> It's destabilizing and breaks the use of bills-of-material based
> deployments with complete lists of all desired RPMs.
>
> Storage and bandwidth concerns are legitimate concerns, as is
> potentially continuing to publish older releases with known
> vulnerabilities or bugs.  But neither Fedora nor RHEL simply discard
> previously published versions this way, they aggregate new releases. I
> consider this a longstanding bug for EPEL, and one of the reasons I
> set up internal mirrors in large deployments.
>

This is not true. Fedora and EPEL share the same system, and have the
same issues. The only difference is that the release repo is frozen in
Fedora, so only the updates repo is affected this way. So there's at
most two versions of a package at any time.

RHEL *does* maintain multiple old versions, but their system is
completely different and supports that capability.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: What to do with Rust packaging in EPEL9?

2021-11-27 Thread Neal Gompa 
On Sat, Nov 27, 2021 at 9:40 AM Igor Raits
 wrote:
>
> On Sat, Nov 27, 2021 at 2:51 PM Neal Gompa  wrote:
>>
>> On Sat, Nov 27, 2021 at 4:36 AM Igor Raits
>>  wrote:
>> >
>> > Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means it 
>> > is not possible to get them in EPEL9. That also means, they are already 
>> > outdated and do not support our latest greatest consistent packaging 
>> > across Fedora versions… Right now, I suppose it is still possible to get 
>> > that stuff updated in the Stream9, but later on it will be harder and 
>> > harder I suppose.
>> >
>> > So what should one do if they want up2date stuff through the whole EPEL9 
>> > lifetime?
>>
>> The macros and tools that power the rust packaging stuff (aside from
>> rust-srpm-macros) are not shipped in CentOS/RHEL 9, so we can ship it
>> in EPEL 9 if we want.
>
>
> Hmm, so why does https://gitlab.com/redhat/centos-stream/rpms/rust-packaging 
> exist?
>

It exists as a buildroot only set of packages for Red Hat's own Rust software.

>>
>>
>> rust-srpm-macros has macros that haven't changed much in years, so I
>> don't think that'll be an issue.
>
>
> I do think they changed a bit in the last couple releases (I'm not following 
> it that much these days)… But at some point I'm hoping to make even more 
> changes there and I'd like to avoid adding rust bits into the epel-rpm-macros 
> (or others).
>

We can certainly get those updated over time by sending merge requests
to update them.




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: What to do with Rust packaging in EPEL9?

2021-11-27 Thread Neal Gompa 
On Sat, Nov 27, 2021 at 4:36 AM Igor Raits
 wrote:
>
> Seems rust-srpm-macros and rust-packaging are in the RHEL9 which means it is 
> not possible to get them in EPEL9. That also means, they are already outdated 
> and do not support our latest greatest consistent packaging across Fedora 
> versions… Right now, I suppose it is still possible to get that stuff updated 
> in the Stream9, but later on it will be harder and harder I suppose.
>
> So what should one do if they want up2date stuff through the whole EPEL9 
> lifetime?

The macros and tools that power the rust packaging stuff (aside from
rust-srpm-macros) are not shipped in CentOS/RHEL 9, so we can ship it
in EPEL 9 if we want.

rust-srpm-macros has macros that haven't changed much in years, so I
don't think that'll be an issue.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed

2021-11-25 Thread Neal Gompa 
On Thu, Nov 25, 2021 at 6:19 AM Nico Kadel-Garcia  wrote:
>
> On Thu, Nov 25, 2021 at 3:05 AM Miroslav Suchý  wrote:
> >
> > Dne 22. 11. 21 v 15:00 Pavel Raiskup napsal(a):
> > > Hello Fedora EPEL maintainers!
> > >
> > > First I don't feel comfortable announcing this, I'm not happy about the
> > > situation and so I don't want to be the lightning rod :-).  But I believe
> > > that we can come to acceptable Copr/Mock solution and this needs to be
> > > discussed...  so here we are.
> > >
> > > By the end of the year 2021 we have to fix our default EPEL 8 Mock
> > > configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
> > > goes EOL by then.
> >
> >
> > I wrote down the possible options and their pros and cons and I done my 
> > best to catch all the feedback here.
> >
> > https://docs.google.com/document/d/1wF7-7_y6Ac_oB-kCFdE6VBWPW8o8zjXd2Z0SGy4VxUA/edit?usp=sharing
> >
> > Miroslav
>
> That seems to be a succinct listing. I think you left out my
> suggestion.of "support people re-inventing point releases for CentOS",
> which is what major CentOS users will do using internal mirrors. due
> to concern about unexpected and unwelcome updates of CentOS Stream,
> while they assess whether AlmaLinux or Rocky are reliable and stable
> enough to use. It's not an uncommon behavior for EPEL itself, partly
> because of EPEL's bad habit of deleting RPMs without warning and
> stripping out all previous releases. That's caused me problems with
> chromium and firefox when updates were incompatible with contemporary
> regression testing systems.
>

It's not a "bad habit", it happens because when packages are retired,
keeping the packages there does a disservice to the community by
effectively forcing a maintenance burden when there's no maintainer.
As for stripping out previous releases, that's just how Pungi and
Bodhi do update composes at the moment. Someday that'll be fixed, but
then we'd have to come up with a policy on how many because there are
storage concerns for mirrors if we kept everything published forever.

> The difficulty with switching mock to AlmaLinux or Rocky is that there
> is likely to be significant phase lag with new point releases by Red
> Hat, and that it will inflict quite a bandwidth burden for all the
> "mock" setups in the field. Can they scale up to handle that?

Insofar as "phase lag with new point releases", AlmaLinux made their
release 48 hours after Red Hat did with RHEL. So, frankly, I'm not
worried there with AlmaLinux.

For bandwidth burdens, mirror networks are designed to alleviate that
burden and both have those in place.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed

2021-11-22 Thread Neal Gompa 
On Mon, Nov 22, 2021 at 11:55 AM Carl George  wrote:
>
> On Mon, Nov 22, 2021 at 8:11 AM Miro Hrončok  wrote:
> >
> > On 22. 11. 21 15:00, Pavel Raiskup wrote:
> > > - builds will require a valid Red Hat subscription (the no-cost variant is
> > >OK as well, though [2])
> >
> > I cannot help myself but I consider this very unpleasant for EPEL packagers.
> >
> > Getting and configuring the subscription was always so unfriendly for me 
> > that
> > I've been using EPEL mocks even for my RHEL work. This basically means using
> > EPEL mocks will once again be as complicated as using RHEL.
> >
> > However, enough of my personal views. Since we have not used RHEL for 
> > copr/mock
> > EPEL buidlroots until now, but we used a downstream freely-available 
> > RHEL-copy
> > (CentOS Linux), could we not continue doing so by using e.g. AlmaLinux?
> >
> > --
> > Miro Hrončok
> > --
> > Phone: +420777974800
> > IRC: mhroncok
> > ___
> > devel mailing list -- de...@lists.fedoraproject.org
> > To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
> I'm not aware of a RHEL clone that offers all the architectures that
> EPEL does.  As far as I can tell, the three most popular (Alma, Rocky,
> Oracle) only offer x86_64 and aarch64 but are missing ppc64le and
> s390x.  That said CentOS Linux 8 doesn't offer s390x either, so we
> already have this problem, but switch the EPEL mock chroot to one of
> those clones would make the situation worse by also dropping ppc64le.
>

I've been informed that AlmaLinux is working on ppc64le support, and
it's supposed to be released "soon". Perhaps Jack can provide an
update here?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mock/Copr default epel-8-* configuration to be changed

2021-11-22 Thread Neal Gompa 
On Mon, Nov 22, 2021 at 10:12 AM Carl George  wrote:
>
> On Mon, Nov 22, 2021 at 8:37 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 22/11/2021 15:00, Pavel Raiskup wrote:
> > > - builds will require a valid Red Hat subscription (the no-cost variant is
> > >OK as well, though [2])
> >
> > I'm going to retire all my EPEL8 packages as I can't build/test them in
> > mock without any subscriptions.
> >
> > --
> > Sincerely,
> >Vitaly Zaitsev (vit...@easycoding.org)
> > ___
> > devel mailing list -- de...@lists.fedoraproject.org
> > To unsubscribe send an email to 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/de...@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
>
> This has always been allowed.  EPEL packagers are not required to
> maintain their packages for the entire corresponding RHEL lifecycle.
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_epel
>
> I will point out that it's trivial to avoid dealing with a
> subscription by doing koji scratch builds, or by using the existing
> oraclelinux-epel-8-x86_64 mock chroot, or by submitting equivalent
> {clone}-epel-8-{arch} chroots to mock-core-configs for your preferred
> clone.  Mass retiring all of your epel8 packages seems like an
> overreaction to me, but it is your choice.  If you do decide to go
> that route I hope you're welcoming to other maintainers that offer to
> co-maintainer your packages to be responsible for the epel8 branch
> going forward.  Ideally you would also send an email to epel-devel
> beforehand to avoid a quick retire/unretire churn for the packages
> other maintainers are interested in keeping around.
>

Note that I've submitted a PR to switch from CentOS Linux to
AlmaLinux[1] for similar reasons (my workflow would be totally broken
if I had to deal with the foibles of subscription-manager for building
packages).

[1]: https://github.com/rpm-software-management/mock/pull/803

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL 9 Next Bodhi updates: Set lower days to stable limit?

2021-11-19 Thread Neal Gompa 
On Fri, Nov 19, 2021 at 1:32 PM Kevin Fenzi  wrote:
>
> On Fri, Nov 19, 2021 at 01:22:32PM -0500, Neal Gompa wrote:
> > On Fri, Nov 19, 2021 at 1:15 PM Miro Hrončok  wrote:
> > >
> > > On 19. 11. 21 17:54, Troy Dawson wrote:
> > > >
> > > >
> > > > On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen  > > > <mailto:smo...@gmail.com>> wrote:
> > > >
> > > > On Fri, 19 Nov 2021 at 11:42, Miro Hrončok  > > > <mailto:mhron...@redhat.com>> wrote:
> > > >  >
> > > >  > Hello EPEL people,
> > > >  >
> > > >  > what do you think about setting the Bodhi days to stable limit 
> > > > to 3 days for
> > > >  > EPEL 9 Next (at least until RHEL 9 GA)?
> > > >  >
> > > >
> > > > I think EPEL-9 Next being based off of Stream with its major changes
> > > > should have a small stable limit. 3 days sounds about right.
> > > >
> > > >
> > > > +1
> > >
> > > There seem to be a consensus, do I file a ticket at infra, or does the 
> > > EPSCo
> > > need to approve it a meeting?
> > >
> >
> > Please file a ticket with infra about it.
>
> wow... consensus in 1.5 hours. :)
>
> Perhaps this should be discussed at the next meeting? To allow
> interested parties to actually see it and comment?
>
> Anyhow, I'm personally fine with it, but note that 3 days leaves very
> little time for testing. One of those days is likely mirror sync/getting
> the update, so interested testers would need to update at least every
> day to make sure and not miss out.
>

Considering the state of CentOS Stream 9 and RHEL 9 right now, I'm
inclined to consider it at the same stage as branched Fedora. We can
always raise it later if we want.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL 9 Next Bodhi updates: Set lower days to stable limit?

2021-11-19 Thread Neal Gompa 
On Fri, Nov 19, 2021 at 1:15 PM Miro Hrončok  wrote:
>
> On 19. 11. 21 17:54, Troy Dawson wrote:
> >
> >
> > On Fri, Nov 19, 2021 at 8:46 AM Stephen John Smoogen  > > wrote:
> >
> > On Fri, 19 Nov 2021 at 11:42, Miro Hrončok  > > wrote:
> >  >
> >  > Hello EPEL people,
> >  >
> >  > what do you think about setting the Bodhi days to stable limit to 3 
> > days for
> >  > EPEL 9 Next (at least until RHEL 9 GA)?
> >  >
> >
> > I think EPEL-9 Next being based off of Stream with its major changes
> > should have a small stable limit. 3 days sounds about right.
> >
> >
> > +1
>
> There seem to be a consensus, do I file a ticket at infra, or does the EPSCo
> need to approve it a meeting?
>

Please file a ticket with infra about it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL 9 Next Bodhi updates: Set lower days to stable limit?

2021-11-19 Thread Neal Gompa 
On Fri, Nov 19, 2021 at 11:45 AM Stephen John Smoogen  wrote:
>
> On Fri, 19 Nov 2021 at 11:42, Miro Hrončok  wrote:
> >
> > Hello EPEL people,
> >
> > what do you think about setting the Bodhi days to stable limit to 3 days for
> > EPEL 9 Next (at least until RHEL 9 GA)?
> >
>
> I think EPEL-9 Next being based off of Stream with its major changes
> should have a small stable limit. 3 days sounds about right.
>

Yes, please!



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL9 Rollout Proposals

2021-11-18 Thread Neal Gompa 
On Thu, Nov 18, 2021 at 2:32 PM Troy Dawson  wrote:
>
> In our last EPEL Steering Committee meeting, Carl brought up a new proposal 
> for our epel9 / epel9-next rollout.  Sometimes IRC isn't the best way to 
> explain things like that, it got a little confusing.  Carl and I had a good 
> video chat to clean up confusion and talk about some pros and cons of the 
> various proposals.
> Here are the three proposals.
>
> * PLAN A
> Plan A is basically what we've been working towards for the past couple of 
> months.
> - launch epel9-next now-ish (ideally aligned with c9s launch promotion)
> - After RHEL9 goes GA
> -- perform a mass branch and mass rebuild to populate epel9
> -- launch epel9 after RHEL9 GA is launched.
>
> ** Plan A Pros:
> - epel9-next and epel9 are only set up once, and not changed
> - ready to go now
>
> ** Plan A Cons:
> - complexity and added work of mass branch and mass rebuild
> - mass rebuild will have a moderate rate of failure due to buildroot 
> differences (unshipped devel packages)
> - epel9 not available at rhel9 ga
> - confusing messaging to packagers:
> -- target epel9-next for ~6 months
> -- after epel9 exists target that instead, only use epel9-next when needed
> - confusing messaging to users:
> -- use epel9-next now for c9s and rhel9 beta
> -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
> -- use epel9 primarily once it exists
>
>
> * PLAN B
> - epel9-next stays the way it is currently setup.
> - Setup epel9 using RHEL9 Beta for the buildroot.
> -- Pull in any errata as it comes.
> -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
> - Launch epel9 and epel9-next together (In 1-2 weeks).
> - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 
> GA
>
> ** Plan B Pros:
> - simple messaging to packagers:
> -- epel9 is the primary target, use epel9-next only when needed (same as 
> epel8-next)
> - simple messaging to users:
> -- use epel9 everywhere (epel-next-release is a recommends on c9s)
> - no mass branching
> - no mass rebuild
> - No confusion from using the full CentOS Stream buildroot
> -- epel9 buildroot will only have AppStream, BaseOS and CRB
>
> ** Plan B Cons:
> - potential for large divergence between rhel9 beta and ga
> - changing our messaging right before the launch
>
>
> * PLAN C
> - epel9-next stays the way it is currently setup.
> - setup up epel9 using c9s for the buildroot
> -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
> - freeze epel9 buildroot before c9s switches to 9.1 content
> - launch epel9 and epel9-next together (1-2 weeks)
> - switch epel9 buildroot from frozen c9s to rhel9 ga later
>
> ** Plan C Pros:
> - simple messaging to packagers:
> -- epel9 is the primary target, use epel9-next only when needed (same as 
> epel8-next)
> - simple messaging to users:
> -- use epel9 everywhere (epel-next-release is a recommends on c9s)
> - no mass branching
> - no mass rebuild
> - No confusion from using the full CentOS Stream buildroot
> -- epel9 buildroot will only have AppStream, BaseOS and CRB
>
> ** Plan C Cons:
> - potential infrastructure complexity of freezing the epel9 buildroot
> - changing our messaging right before the launch
>
>
> Please let us know what you think.
> If we do choose to go with Plan B or C we will need to make the decision 
> fairly quickly.
>

I like Plan C, personally. Especially given how easy it is to work
with the RHEL maintainers with CentOS Stream 9 right now, when it's
easy to get content from buildroot added to CRB. Post-GA is way more
painful and slower. There's also the benefit of on-ramping folks using
the RHEL 9 beta too.

I've been testing some builds for an EPEL-like thing for some dev work
effectively by doing Plan C, and it has been working fantastically
well.

So I'd love to see Plan C executed ASAP, so I can move that work into
EPEL proper.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: RFC: generating openssl3 packages from openssl spec

2021-11-09 Thread Neal Gompa 
On Tue, Nov 9, 2021 at 7:38 PM Michel Alexandre Salim
 wrote:
>
> Hi all,
>
> Per https://bugzilla.redhat.com/show_bug.cgi?id=2007031 -- openssl 3.x
> won't be added to RHEL 8, while updated packages are starting to need
> it.
>
> It thus seems to be a good candidate for EPEL; the question is - are we
> allowed to maintain openssl3-* packages from the openssl srpm repo, or
> do we need to explicitly have an epel8-only (possibly F35 and F34 too,
> as they also don't have openssl3) 'openssl3' srpm repo?
>

You'll need an openssl3 SRPM repo, but you could have commits synced
from openssl from CentOS Stream 9.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Plan for EPEL-9

2021-11-08 Thread Neal Gompa 
On Mon, Nov 8, 2021 at 2:18 AM Remi Collet  wrote:
>
> As both RHEL-9 Beta and CentOS 9 Stream are available,
> what are the plan for EPEL-9 ?
>
>
> I really this should be available ASAP to be
> available to our users at GA time.

EPEL 9 Next for CentOS Stream 9 is blocked on the migration of our
s390x systems to z15[1], because currently all s390x builds fail[2].
Once that's taken care of, we'll launch EPEL 9 Next.

[1]: https://pagure.io/fedora-infrastructure/issue/10302
[2]: https://pagure.io/releng/issue/10360


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: To buildroot, or not to buildroot

2021-10-07 Thread Neal Gompa 
On Thu, Oct 7, 2021 at 9:44 AM Troy Dawson  wrote:
>
>
>
> On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa  wrote:
>>
>> On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson  wrote:
>> >
>> >
>> >
>> > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa  wrote:
>> >>
>> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson  wrote:
>> >> >
>> >> > *this is worth a discussion in todays EPEL Steering Committee Meeting*
>> >> >
>> >> > It sounds like the epel9-next is going to startup by building against 
>> >> > the CS buildroot.  Changing it at this time would cause a delay.
>> >> >
>> >> > Thus we need to write some "verify build deps are released" checker.  I 
>> >> > have an idea of how to do this, so I'm willing to volunteer to write 
>> >> > and run something.
>> >> >
>> >> > But, it would be good to have some discussion to determine if we want 
>> >> > to keep using the CS buildroot for epel9-next, always.  Or if we want 
>> >> > to use it just as a bootstrap mechanism, and then switch to building 
>> >> > just off the available CentOS Stream repos at some point.
>> >> >
>> >> > Thoughts?
>> >> > Should we always use buildroot?  Or just keep up until we're fairly 
>> >> > stable?
>> >> >
>> >>
>> >> We should only use the buildroot repo for as long as we need to. The
>> >> *sooner* we can switch to the published content, the better.
>> >
>> >
>> > This was discussed at the EPEL Steering Committee meeting.  Here is the 
>> > summary.
>> > Someone correct me if I'm wrong.
>> >
>> > epel9-next:
>> >  - starts off building off CS buildroot
>> >  - I will write a "check if all build packages are in the normal repos" 
>> > checker, called "will it build" [1]
>> >
>>
>> How are we going to know whether all the build-time and run-time
>> packages are in the normal repos? We need to check generated
>> dependencies too, especially now that it's possible to have dynamic
>> BuildRequires!
>
>
> run-time dependencies:
> That's always been a problem, even without the buildroot.
> But I will also be writing a "will it install" to go along with "will it 
> build"
>
> build-time dependencies:
> Grab the root.log of the package build, and parse it.
> This gets around any hidden and dynamic BuildRequires.
> I've already written code that does this for Content Resolver, and checked it 
> against traditional dnf/libsolve dependency generation.
> It was 98% equal, and those 2% were on packages where it was possible for 
> more than one package to be installed for a dependency, and for that, I'd 
> prefer going with the root.log.
>
> I think I've got everything I need already written, just in three separate 
> projects.
> I really want to pull that code together and make "willit"
>
>>
>> > epel9:
>> >  - Use normal RHEL 9 repos (AppStream, BaseOS, CRB)
>> >
>> > Checks/Tests/Future:  (It's a little fuzzy on the timing of these)
>> >
>> >  - grobisplitter
>> >  -- see if we really need to use grobisplitter
>> >  -- I'm a little fuzzy on how or when we are going to test this
>> >
>>
>> With the retirement of the container-tools default module,
>> grobisplitter will not be required at all unless we want to use it to
>> support non-default modules.
>
>
> That is the theory, yes, that grobisplitter isn't required.
> But nobody was able to say that was for certain.  Thus, it needs to be tested.
>

I've verified this with my internal build infrastructure, so yes, I
know it's not required.

Admittedly, it's not a Koji system, but I'm also not enabling any
modules in my build environment right now. I'm rebuilding content from
Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9
packages to build for work, which is how some of my requests to add
stuff to CRB have come about[1][2][3].

This can also be verified when using something like mock with
mock-core-configs v36 or higher, because I made the necessary
adjustments to test building on CentOS Stream 9 the same way that
Fedora Koji and the CentOS CBS would.

[1]: 
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140
[2]: 
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139
[3]: 
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: To buildroot, or not to buildroot

2021-10-07 Thread Neal Gompa 
On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson  wrote:
>
>
>
> On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa  wrote:
>>
>> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson  wrote:
>> >
>> > *this is worth a discussion in todays EPEL Steering Committee Meeting*
>> >
>> > It sounds like the epel9-next is going to startup by building against the 
>> > CS buildroot.  Changing it at this time would cause a delay.
>> >
>> > Thus we need to write some "verify build deps are released" checker.  I 
>> > have an idea of how to do this, so I'm willing to volunteer to write and 
>> > run something.
>> >
>> > But, it would be good to have some discussion to determine if we want to 
>> > keep using the CS buildroot for epel9-next, always.  Or if we want to use 
>> > it just as a bootstrap mechanism, and then switch to building just off the 
>> > available CentOS Stream repos at some point.
>> >
>> > Thoughts?
>> > Should we always use buildroot?  Or just keep up until we're fairly stable?
>> >
>>
>> We should only use the buildroot repo for as long as we need to. The
>> *sooner* we can switch to the published content, the better.
>
>
> This was discussed at the EPEL Steering Committee meeting.  Here is the 
> summary.
> Someone correct me if I'm wrong.
>
> epel9-next:
>  - starts off building off CS buildroot
>  - I will write a "check if all build packages are in the normal repos" 
> checker, called "will it build" [1]
>

How are we going to know whether all the build-time and run-time
packages are in the normal repos? We need to check generated
dependencies too, especially now that it's possible to have dynamic
BuildRequires!

> epel9:
>  - Use normal RHEL 9 repos (AppStream, BaseOS, CRB)
>
> Checks/Tests/Future:  (It's a little fuzzy on the timing of these)
>
>  - grobisplitter
>  -- see if we really need to use grobisplitter
>  -- I'm a little fuzzy on how or when we are going to test this
>

With the retirement of the container-tools default module,
grobisplitter will not be required at all unless we want to use it to
support non-default modules.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: To buildroot, or not to buildroot

2021-10-06 Thread Neal Gompa 
On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson  wrote:
>
> *this is worth a discussion in todays EPEL Steering Committee Meeting*
>
> It sounds like the epel9-next is going to startup by building against the CS 
> buildroot.  Changing it at this time would cause a delay.
>
> Thus we need to write some "verify build deps are released" checker.  I have 
> an idea of how to do this, so I'm willing to volunteer to write and run 
> something.
>
> But, it would be good to have some discussion to determine if we want to keep 
> using the CS buildroot for epel9-next, always.  Or if we want to use it just 
> as a bootstrap mechanism, and then switch to building just off the available 
> CentOS Stream repos at some point.
>
> Thoughts?
> Should we always use buildroot?  Or just keep up until we're fairly stable?
>

We should only use the buildroot repo for as long as we need to. The
*sooner* we can switch to the published content, the better.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL package and Java 11 requirement.

2021-10-04 Thread Neal Gompa 
On Mon, Oct 4, 2021 at 3:06 PM Stefan Bluhm
 wrote:
>
> Hello,
>
> can you please give me a direction on how to handle a Java 11 package build 
> on RHEL8 for EPEL8?
>
> My issue: I am trying to build jaxb-api. The build works fine:
> https://src.fedoraproject.org/rpms/jaxb-api/blob/rawhide/f/jaxb-api.spec
> In addition to the original file, I added:
>
> BuildRequires:  java-11-openjdk-devel
>
> and
>
> %if 0%{?rhel}
> export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
> %endif
>
> Now the generated rpm adds this requirement line:
>
> Requires: java-headless >= 1:9
>
> This is something that RHEL cannot fulfill as it would be called 
> java-11-headless (adding the next higher available version).
>
> How do I remove/omit the generation of the 1:9 requirement?
>

java-11-openjdk-headless provides "java-headless = 1:11", so it should
work anyway. And that's in RHEL 8.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: To buildroot, or not to buildroot

2021-10-01 Thread Neal Gompa 
On Fri, Oct 1, 2021 at 5:39 PM Miro Hrončok  wrote:
>
> On 01. 10. 21 22:11, Troy Dawson wrote:
> > I'll have to file all those "please move these packages into CRB" bugz after
> > RHEL9 is out.
>
> I wonder whether we should file those before it is out, if at all possible?
>

Ideally, yes because it's an extreme pain to deal with them post-GA.
Red Hat's policies around this stuff is such that after 9.0, they can
only be introduced in 6 month intervals (that is, we have to wait for
9.1 for them to show up in EPEL9). We should *never* use the buildroot
repository for EPEL-Next because it massively complicates discovering
this stuff and getting it straightened out immediately. Unlike CentOS
SIGs that only build for CentOS Stream, EPEL needs to work on RHEL,
and Red Hat will *never* ship the buildroot repo for RHEL, because it
opens up the door for things to depend on that content, which is
highly problematic for them.




--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-gevent and pytest-cov in el9

2021-09-24 Thread Neal Gompa 
On Fri, Sep 24, 2021 at 4:03 PM Josh Boyer  wrote:
>
> On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa  wrote:
> >
> > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer  wrote:
> > >
> > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer  wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> > > > cannot build python-gevent on EPEL 9 easily.
> > >
> > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
> > >
> > > You could request libev-devel in the composes.  I remain confused why
> > > it has to be in the compose though, because libev and it's devel
> > > package are accessible in the CentOS Stream 9 buildroots today.
> > >
> >
> > We can't use them in EPEL if they're not in CRB.
>
> Yes, that's what everyone keeps telling me.  I don't understand why.
>

Well, because outside of RHEL, everyone wants remote and local builds
to have access to the same resources and not crush the servers. Since
buildroot stuff isn't going out on the mirror network (otherwise, why
would it be separate from CRB?), it's obvious we shouldn't rely on it
for packages that people should expect to be able to build and rebuild
for RHEL.

And again, by Red Hat's own sword (policy), RHEL doesn't want to ship
everything needed to build stuff, so if EPEL is intended to provide
the requisite community guarantees (reproducibly buildable), we have
to work with what RHEL gives us.




--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-gevent and pytest-cov in el9

2021-09-24 Thread Neal Gompa 
On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer  wrote:
>
> On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer  wrote:
> >
> > Hi folks,
> >
> > The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> > cannot build python-gevent on EPEL 9 easily.
>
> https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
>
> You could request libev-devel in the composes.  I remain confused why
> it has to be in the compose though, because libev and it's devel
> package are accessible in the CentOS Stream 9 buildroots today.
>

We can't use them in EPEL if they're not in CRB.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Pre-release EPEL

2021-09-16 Thread Neal Gompa 
On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee  wrote:
>
> Hi,
>
> Thanks to people on the CentOS mailing list.
> We managed to get CentOS Stream 9 pre-release with updates working on a VM.
> Is there also a pre-release version of EPEL 9 we can use?
>

Not just yet, I'm hoping that'll be soon...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: is possible rollback Epoch bump on epel ?

2021-09-16 Thread Neal Gompa 
On Thu, Sep 16, 2021 at 7:46 AM Miroslav Suchý  wrote:
>
> Dne 16. 09. 21 v 13:23 Sérgio Basto napsal(a):
> > the question is, can I remove Epoch tag ? or should I put Epoch in
> > every branch, i.e epel 8 ?
> >
> > Thank you .
>
> Once you introduce the epoch, you have to keep it. And only increment it.
>
> There is no way to get it rid of it. At least no way I can recommend :)
>

Epochs can *only* be reset on system upgrades, because you're either
reinstalling or using the distro-sync upgrade method (which does not
necessarily care about EVRs).

Neither case happens within a particular EPEL branch. So you're stuck
with it until the next RHEL major version release.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

2021-08-31 Thread Neal Gompa 
Hey all,

ntfs-3g 2021.8.22 was released yesterday to resolve multiple CVEs[1].
With permission from Tom Callaway (the ntfs-3g maintainer), I am
preparing updates for Fedora and EPEL now for Tom.

As part of this, I'll rebuild all reverse dependencies for this. Based
on a repoquery, that is:

* libguestfs
* ntfs-3g-system-compression
* partclone
* testdisk
* wimlib

Sorry for the inconvenience.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1999788

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

2021-07-27 Thread Neal Gompa 
On Tue, Jul 27, 2021 at 6:50 PM Miro Hrončok  wrote:
>
> On 27. 07. 21 23:03, Neal Gompa wrote:
> > On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava  wrote:
> >>
> >> If I understand what you're describing correctly, this is not a bug.
> >> In the default state, /usr/bin/python should *not* exist, that's correct 
> >> behaviour. If you want it to exist, you need to configure it using 
> >> alternatives [0].
> >>
> >> We considered making /usr/bin/python exist but be a noop, but that breaks 
> >> a lot of automated (build) tools that search for Python executables (they 
> >> often start with python, if not found search for python3, or python2, 
> >> etc.).
> >> And there was no reasonable default for Python in RHEL 8 because it sits 
> >> between the past (Python 2 default in RHEL 7) and the future (Python3 
> >> default in RHEL 9). Either default would cause problems, often hidden and 
> >> hard to debug problems, for some subset of our customers.
> >>
> >> [0] 
> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings
> >>
> >
> > But this won't be a problem in RHEL 9, will it? I don't want to suffer
> > through this when we're not even going to have Python 2 in RHEL 9 at
> > all...
>
> Not at all. We have reviewed all the RHEL 8 differences from Fedora and how
> much painful they were/are and decided to play the "if we would not do this in
> Fedora, we should not do it in RHEL 9 either" card. That includes
> /usr/bin/python (optionally (un)installable but only one), platform-python
> (don't), modularity (don't), and other things.
>
> Some differences are still planned though, albeit hopefully minor:
>
>
> 1) We plan non-modular parallel-installable Python stacks in RHEL 9, but we
> don't want to take care of such stacks in Fedora. However, we intent to fully
> support this case for Fedora's downstreams (not only RHEL: any downstream, 
> e.g.
> even Copr repos):
> https://bugzilla.redhat.com/show_bug.cgi?id=1821489
>

I think if we had some more automation about building whole stacks and
some way to dynamically generate subpackages, this could be something
to bring to Fedora itself. But for now, this makes sense.

I think we discussed this somewhat earlier in the year[1], it's
something we can revisit if the situation improves...

[1]: 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/WNNAZWWHDU7LE4EJBDKREJO5FJQ6SXRX/

>
> 2) We need some upgrade-path compatibility shims from RHEL 8's platform-python
> that are not needed in Fedora and we plan to include them in RHEL 9 only:
> https://bugzilla.redhat.com/show_bug.cgi?id=1891487
>

Unfortunate, but sensible.

>
> 3) In Fedora, various Python interpreters use pip/setuptools/wheel wheels from
> /usr/share/python-wheels or bundle their own wheel when the "general" ones are
> too new to work with old Pythons. Given the differences of life cycle of RHEL
> and Fedora, we plan to use wheels from /usr/share/python3.X-wheels instead 
> (and
> have the possibility to build newer versions of pip/setuptools/wheel wheels 
> for
> each newer Python version we introduce to RHEL 9). RHEL 8 already partially
> does that for Python 3.8+, but in RHEL 9, we want to do this from the
> beginning. I intent to do the rpm-macros-groundwork for this in Fedora, but we
> might need to explicitly not make this change in ELN to preserve Rawhide/ELN
> builds compatibility.
> https://bugzilla.redhat.com/show_bug.cgi?id=1982668
>

Aren't wheels fully versioned themselves? Why do you need the wheel
directory itself to be versioned?

>
> Usual disclaimer applies: Those are our plans as engineers, not promises by 
> Red
> Hat as a company.

Naturally. :)



--
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-unversioned-command for epel8 (provides /usr/bin/python)

2021-07-27 Thread Neal Gompa 
On Tue, Jul 27, 2021 at 5:09 AM Tomas Orsava  wrote:
>
> If I understand what you're describing correctly, this is not a bug.
> In the default state, /usr/bin/python should *not* exist, that's correct 
> behaviour. If you want it to exist, you need to configure it using 
> alternatives [0].
>
> We considered making /usr/bin/python exist but be a noop, but that breaks a 
> lot of automated (build) tools that search for Python executables (they often 
> start with python, if not found search for python3, or python2, etc.).
> And there was no reasonable default for Python in RHEL 8 because it sits 
> between the past (Python 2 default in RHEL 7) and the future (Python3 default 
> in RHEL 9). Either default would cause problems, often hidden and hard to 
> debug problems, for some subset of our customers.
>
> [0] 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/assembly_configuring-the-unversioned-python_configuring-basic-system-settings
>

But this won't be a problem in RHEL 9, will it? I don't want to suffer
through this when we're not even going to have Python 2 in RHEL 9 at
all...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: [CentOS-devel] Updated KDE Plasma Desktop ready for testing on CentOS Stream 8

2021-07-23 Thread Neal Gompa 
On Thu, Jul 22, 2021 at 6:22 PM Troy Dawson  wrote:
>
> An updated qt5 in CentOS Stream 8 allowed us to update KDE Plasma Desktop.
> I believe everything is in place and ready for use and/or testing.
>
> This is for CentOS Stream 8 only, at this time.
>
> ===How to Install [1]
> = Install epel-release
>dnf install 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> = Enable PowerTools
>dnf config-manager --enable powertools
> = Install KDE
>   dnf group install kde-desktop-environment
> or
>   dnf group install kde-desktop
>   (Optional) dnf group install kde-apps
>   (Optional) dnf group install kde-media
>   (Optional) dnf group install kde-education
>   (Optional) dnf install okular
>   (Optional) dnf group install kde-software-development
>   (Optional) dnf group install kf5-software-development
>
> === KNOWN PACKAGE ISSUES
>
> == UNINSTALLABLE PACKAGES
> * kaccounts-providers - no signon-ui
> * kigo - no gnugo
> * lokalize - no translate-toolkit , needs rebuilding on python3
>
> == UNBUILT PACKAGES
> * polkit-qt5 - need branch and build of polkit-qt-1
> * kde-gtk-config - needs sassc
> * digikam - can't find opencv despite it being installed
>
> == UN-UPDATED PACKAGES (but still install and run)
> * kpmcore - would need a newer util-linux than available in RHEL 8
> * kde-partitionmanager - would need a newer kpmcore
>

The KPMCore libblkid bump to 2.33.2[1] comes from an issue with
resizing logical partitions[2] that was fixed in 2.33.2[3].

It may be worth asking if this fix can be backported so that we can
relax the dependency and update kde-partitionmanager.

[1]: 
https://invent.kde.org/system/kpmcore/-/commit/6d272234bbaa98eb580b495392f0c79c01375d66
[2]: https://github.com/karelzak/util-linux/issues/745
[3]: 
https://github.com/karelzak/util-linux/commit/590dc5e919d24e530483af24e877aeb6904d00d2



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2021-07-08 Thread Neal Gompa 
On Thu, Jul 8, 2021 at 9:39 AM Kevin Fenzi  wrote:
>
> On Wed, Jul 07, 2021 at 08:32:27PM -0400, Neal Gompa wrote:
> >
> > 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? We can then remove the EPEL9 next
> > buildroot from the EPEL9 buildroot so that state doesn't persist after
> > everything is done. This also makes it so we can ignore the
> > "noautobuild" file the one time that all the content needs to be
> > properly seeded in EPEL9.
>
> But at the time of RHEL9.0 GA, cs9 may well have already moved on to
> 9.1... so that might result in stuff that doesn't work/install/depsolve
> with 9.0? Or am I missing something there...
>

Based on what goes on now for EPEL8 and EPEL8 next, I think the
likelihood of that being a problem is fairly low. Ones where this is a
problem can be individually handled after the reset, and we'd waste
far less build resources in doing so.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2021-07-08 Thread Neal Gompa 
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. If we don't have this explicitly blocked
in policy yet, we need to make this explicit.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2021-07-07 Thread Neal Gompa 
On Wed, Jul 7, 2021 at 8:28 PM Mohan Boddu  wrote:
>
> Hello all,
>
> 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.
>
> There were couple of ideas thrown around from doing nothing to tagging
> epel9-next builds to epel9, but I think the best way to solve this is,
> mass branching the packages that have epel9-next branch and create
> epel9 branch from it and then running a mass rebuild without any
> changes to spec files. As epel9-next builds will already have a
> .el9.next dist tag, we can simply rebuild whatever there is in epel9
> branch (after branching epel9 branch from epel9-next branch).
>
> Since the builds are done in alphanumerical order and does not
> preserve build order, we might have to run this mass rebuild a few
> times (thinking of 5 times) on the failed builds to get most of the
> builds. This doesn't involve changing the spec files, just
> resubmitting the failed tasks.
>
> 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. The idea here is, if the maintainer wishes
> to support epel9-next, their final goal is to maintain the package for
> epel9. So, we give them a branch, but will not rebuild their package
> as they might have wanted to build their packages in the correct build
> order (cough cough KDE :D).
>
> This gives us a working epel9 with a bunch of working builds in a few
> days after rhel9 GA and also we can create ftbfs bugs for those that
> failed in the mass rebuild which will help maintainers to identify and
> fix the issues.
>
> 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? We can then remove the EPEL9 next
buildroot from the EPEL9 buildroot so that state doesn't persist after
everything is done. This also makes it so we can ignore the
"noautobuild" file the one time that all the content needs to be
properly seeded in EPEL9.

I would also say that mass rebuild should just be directly tagged in.
Doing Bodhi stuff is going to make this incredibly slow and painful,
so I'd say don't bother.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Git-annex missing on Fedora EPEL 8

2021-06-15 Thread Neal Gompa 
On Tue, Jun 15, 2021 at 4:39 PM Odilon Junior  wrote:
>
> Hi Team,
>
> I was looking for git-annex on EPEL 8 and it looks like the package is not 
> present, even though I can see the package on EL7/F34/F35, is there any 
> reason for git-annex to not be present for EL8?
>
> I'm a member of the Foreman[1]/Katello team, we are in the process of moving  
> from EL7 to EL8 in our infra, git-annex is heavily used in our builds. Should 
> we check another place for this package?

Seems like the branch was made but the work wasn't done yet. Do any of
the maintainers know why this hasn't happened yet?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL Steering Committee meeting - find a new time

2021-02-20 Thread Neal Gompa 
On Sat, Feb 20, 2021 at 6:27 AM Pablo Sebastián Greco
 wrote:
>
> Last time we did the voting in UTC, and ended up adapting it to DST in the 
> US. Do you think we'll repeat it this time?
>

Yeah, we will. Most of us attending the meetings are on US timezones
and have to account for DST.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Xfce 4.16 on EPEL-8

2021-02-15 Thread Neal Gompa 
On Mon, Feb 15, 2021 at 5:51 PM Orion Poplawski  wrote:
>
> On 2/7/21 8:56 AM, Mukundan Ragavan wrote:
> >
> > Hi all,
> >
> > I have a COPR containing xfce 4.16 packages for EPEL-8 packages [0]. I
> > would like to get some testing done using this COPR before getting into
> > EPEL-8.
> >
> > Please email if and when you notice problems and I will try to fix it as
> > soon as possible.
> >
> > As a reminder - xfce 4.16 will be available in F34.
>
> Mukundan -
>
>Just a note that as mentioned on the CentOS list here:
> https://lists.centos.org/pipermail/centos/2021-February/353317.html
>
> # dnf group install Xfce
> Last metadata expiration check: 0:02:24 ago on Mon 15 Feb 2021 03:41:53
> PM MST.
> No match for group package "NetworkManager-gnome"
> No match for group package "thunar-archive-plugin"
>
> So perhaps the comps file needs to get cleaned up?
>
>
> And then possibly new with the copr seems to be:
>
>   Problem: cannot install the best candidate for the job
>- nothing provides pulseaudio-daemon needed by
> xfce4-pulseaudio-plugin-0.4.3-5.el8.x86_64
>
> Thanks for working on Xfce for EPEL, much appreciated.
>

It seems that the Provides was guarded out in CentOS 8 by Wim[1]. Wim,
any chance you could put it back?


[1]: 
https://git.centos.org/rpms/pulseaudio/c/e3865dfb21f9e8c13769903cbe4c5d166c4fb9f0



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)

2020-12-15 Thread Neal Gompa 
On Wed, Dec 9, 2020 at 6:15 AM Christopher Engelhard  wrote:
>
> On 09.12.20 11:17, Miro Hrončok wrote:
> > However, since CentOS Linux 8 (and 9!) will be no more, do we have some
> > ideas how to handle this? Do we require all EPEL contributors to obtain
> > the developer RHEL subscription (seems like a huge pain)? Do we switch
> > to Oracle Linux (only half joking)? Do we try to fight this decision
> > (however I am afraid I've exhausted my fight capacity on different
> > decisions)?
>
> Intuitively, I think that requiring RHEL dev subscriptions would pretty
> much kill  EPEL packaging on Copr. Unless you specifically want to
> create EPEL packages, why would you get and keep a RHEL dev subscription
> when you could just not check the EPEL-boxes?
>
> From a purely technical perspective, i.e. pretending it were CentFork
> Community Linux, are there reasons not to use Oracle Linux?

Ignoring that Oracle gives me the heebie-jeebies, at this time, the
only two reasonable options are:

* CloudLinux's Project Lenix:
https://blog.cloudlinux.com/announcing-open-sourced-community-driven-rhel-fork-by-cloudlinux
* Oracle (Unmentionable) Linux: http://public-yum.oracle.com/index.html

Oracle's variant is available now, but... yeah.

The CloudLinux offering is supposed to become available in the next
month or so. They don't seem to be terrible people and a lot of
companies have been using their stuff for a while now, so I'm
reasonably confident in their continual existence. If they're true to
their word on their free RHEL clone offering, we could probably switch
to it as the input for Mock and the Fedora COPR service.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Proposing an EPEL packaging SIG

2020-09-11 Thread Neal Gompa 
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> >   * whether it should be full admin access or whether such access
> > should be scoped to epel* branches can be discussed. Full admin would
> > make it possible to adjust the spec in Rawhide to be more EPEL
> > friendly, for example
>
> Unless I've missed something, we still don't have per-branch ACLs in
> dist-git.
>
> I don't think it's okay to force maintainers to give you admin or commit
> to their packages just because you want them in EPEL.
>
> (I'm also not one of the kind of people who really like having one spec
> file for all versions of the package, but I know others disagree with me
> on this.  Certainly if hypothetically I didn't want to maintain an EPEL
> package I wouldn't want its logic /also/ foisted on me in rawhide.)
>

We have per-branch ACLs in Dist-Git since early August. The
collaborator role in Pagure lets you grant people commit access for
specific branches.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Fedora 33 System-Wide Change proposal: CMake to do out-of-source builds

2020-08-03 Thread Neal Gompa 
On Mon, Aug 3, 2020 at 7:08 PM Orion Poplawski  wrote:
>
> On 7/7/20 12:09 PM, Neal Gompa wrote:
> > On Tue, Jul 7, 2020 at 1:57 PM Orion Poplawski  wrote:
> >>
> >> On 6/15/20 1:47 PM, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds
> >>>
>
> >>> == Upgrade/compatibility impact ==
> >>> Existing packages can (and most likely will) become FTBFS, but
> >>> proposal owners will fix as many Fedora packages as possible. However
> >>> fixing third-party packages is not possible and out of scope.
> >>> Third-party packagers will need to adapt based on the recommendations
> >>> noted in this Change.
> >>
> >> What's the plan for EPEL8/7 compatibility?
> >>
> >
> > I need to talk to EPEL folks about how to handle this. I'm not sure
> > exactly what strategy we should take here. I could override the macros
> > entirely with epel-rpm-macros, which is probably the easiest way to do
> > it.
> >
>
> Any progress here?  This is becoming a large pain point for me.
>

I implemented a hacky solution last week[1][2]. There's a bug to get
RH to update CMake and pull in the proper macros into RHEL 8[3].

[1]: 
https://src.fedoraproject.org/rpms/epel-rpm-macros/c/3d7bea8322f8a7c5bd1b01ec16180c5b036a65a7
[2]: 
https://src.fedoraproject.org/rpms/epel-rpm-macros/c/e93d8e2f0d0b056349a22d5bef8a93116d469516
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1858941


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 repos packaged for Fedora (for repoquery)

2020-06-30 Thread Neal Gompa 
On Tue, Jun 30, 2020 at 2:46 PM Miro Hrončok  wrote:
>
> To scratch my own itch I've packaged EPEL repos for Fedora. I've decided to 
> use the existing epel-release component for this (but I am OK to get a 
> different name, such as epel-repos).
>
> See https://src.fedoraproject.org/rpms/epel-release/pull-request/9
> And https://bugzilla.redhat.com/show_bug.cgi?id=1852583
>
> Package review and any other feedback is appreciated.
>

I'm not sure this is a good idea. Also, queries and figuring out
dependencies still requires having RHEL/CentOS repositories, which
this package would not provide.

Some time ago, I wrote rpmdistro-repoquery wrapper around dnf
repoquery[1] for doing stuff like this. That might help for you too.

[1]: https://pagure.io/rpmdistro-repoquery


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

2020-06-10 Thread Neal Gompa 
On Fri, May 15, 2020 at 10:40 AM Neal Gompa  wrote:
>
> On Fri, May 15, 2020 at 10:37 AM Orion Poplawski  wrote:
> >
> > On 5/15/20 8:32 AM, Alexander Korsunsky wrote:
> > >> Has anyone asked if CMake could be updated in RHEL yet?
> > >
> > > This would be the absolute best option here, but it depends on the 
> > > benevolence of Red Hat.
> > >
> > > I don't have a subscription and I don't know how to ask them for a rebase 
> > > without one. Maybe there's some kind of process for getting stuff into 
> > > CentOS Stream? So far the interaction with upstream seems to be limited 
> > > to "create an issue on Bugzilla".
> >
> > That would be my suggestion:
> >
> > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=cmake
>
> Wrong place. This is the correct one:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208=cmake
>

I've discovered that RHEL is pushing a CMake module for RHEL 8.3:
https://git.centos.org/modules/cmake/blob/c8s-stream-rhel8/f/SOURCES/modulemd.src.txt

However, it would not be useful for most EPEL package builders, and
IMO, is completely unnecessary, given CMake's strong backwards
compatibility guarantees. I've filed a bug asking them to retire the
module and upgrade the base package instead:
https://bugzilla.redhat.com/show_bug.cgi?id=1845910



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

2020-05-15 Thread Neal Gompa 
On Fri, May 15, 2020 at 10:37 AM Orion Poplawski  wrote:
>
> On 5/15/20 8:32 AM, Alexander Korsunsky wrote:
> >> Has anyone asked if CMake could be updated in RHEL yet?
> >
> > This would be the absolute best option here, but it depends on the 
> > benevolence of Red Hat.
> >
> > I don't have a subscription and I don't know how to ask them for a rebase 
> > without one. Maybe there's some kind of process for getting stuff into 
> > CentOS Stream? So far the interaction with upstream seems to be limited to 
> > "create an issue on Bugzilla".
>
> That would be my suggestion:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=cmake

Wrong place. This is the correct one:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208=cmake


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

2020-05-15 Thread Neal Gompa 
On Fri, May 15, 2020 at 4:58 AM 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.
>

Has anyone asked if CMake could be updated in RHEL yet? Unlike in the
CMake 2.x days, CMake 3.x tends to maintain behavioral compatibility
extraordinarily well...




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Co-Maintainers wanted for python-lockfile EPEL branches

2020-04-20 Thread Neal Gompa 
On Mon, Apr 20, 2020 at 9:51 AM Miro Hrončok  wrote:
>
> On 20. 04. 20 13:45, Fabio Valentini wrote:
> > and it seems I
> > can't even figure out how to determine which EPEL packages require
> > python*-lockfile.
>
> Take the attached repo files.
>
> They are good for repoquery, adapted from epel-release.
>
> They don't have -testing repos, but -testingx, so you don't accidentally 
> enable
> them  with dnf --enablerepo=\*-testing.
>
> Usage:
>
> $ repoquery --repo=epel8{,-source} --whatrequires python2-lockfile
> pungi-legacy-0:4.1.38-1.el8.2.noarch
> python2-pungi-0:4.1.38-1.el8.2.noarch
>

I also have a simple little tool I use for querying distributions and
repos with DNF: https://pagure.io/rpmdistro-repoquery

It comes with collections of repo definitions for Fedora, CentOS +
EPEL, Mageia, and openSUSE, and might be useful for things like
this...



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Ansible & Python 3 in EPEL7

2020-03-02 Thread Neal Gompa 
On Mon, Mar 2, 2020 at 12:19 PM Carl George  wrote:
>
> The EL7 python3 stack does not have all the same libraries available.
> Ansible users have already complained about the lack of libselinux
> bindings, but thankfully that should be resolved in 7.8.
>
> https://bugs.centos.org/view.php?id=16389
> https://bugzilla.redhat.com/show_bug.cgi?id=1719978
> https://git.centos.org/rpms/libselinux/blob/c7-beta/f/SPECS/libselinux.spec#_259
>

Missing DNF stack Python 3 modules means that the yum module will be broken
in Python 3 too.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Ansible & Python 3 in EPEL7

2020-03-02 Thread Neal Gompa 
On Mon, Mar 2, 2020 at 5:47 AM Igor Gnatenko  wrote:
>
> Hey folks,
>
> We recently started to use Ansible more and we are using some ansible
> collection which is not compatible with Python 2.
>
> Are there any plans to switch Ansible to Python 3 in EPEL7 or are
> there any recommendations what to do in such cases as we have?

I suspect both versions would need to be shipped in EPEL7 unless
upstream Ansible just switches to Python 3 for EL7 too.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Announcement: EPEL Steering Committee Changes

2020-02-19 Thread Neal Gompa 
On Tue, Feb 18, 2020 at 1:12 PM Troy Dawson  wrote:
>
> On Tue, Feb 18, 2020 at 9:36 AM Stephen John Smoogen  wrote:
> >
> > Hi,
> >
> > It has been a pleasure for me to be a part of and help lead the
> > EPEL steering committee for the last couple of years. It has not
> > always been smooth sailing but I have found it an enjoyable experience.
> >
> > However, as you may know the Fedora project will be moving to a
> > different data-center later this spring (from Phoenix to northern
> > Virginia). Being involved in the planning and implementation of this
> > project, I do not think that I will be able to give EPEL the time
> > investment it deserve for the next 6 to 9 months. With EPEL-8 still
> > ramping up and the various opportunities with modularity, I do
> > not think it is a fair that EPEL suffers from this lack of time.
> >
> > As such, I would like to step down as chair/member of the steering
> > committee and nominate Troy Dawson as my replacement. Troy formerly
> > worked on Scientific Linux and has worked on OpenShift and other
> > projects at Red Hat for the last several years.  It is clear he has a
> > good eye on the concerns and problems enterprise users have. Recently,
> > Troy helped get the initial RHEL-8 and EPEL-8 out the door with
> > multiple builds and updates to various macro files.
> >
> > Once the move is completed and the close down of the old site is done,
> > I look forward to getting involved again in EPEL.
>
> Thank you Stephen for all that you've done for the EPEL community the
> past several years.  I hope the move goes smooth so that you can
> return to us sooner, rather than later.
>
> I will do my best to keep EPEL steering in the right direction.
>

I second the nomination of Troy. He's been a pleasure to work with and
has done fantastic work to bring KDE Plasma to RHEL/CentOS users after
Red Hat ripped it out of RHEL for RHEL 8.

The fact that he's a member of modularity team means that he can
easily take our feedback and have it incorporated into improving the
system, which is a huge boon for us as RHEL 8 leverages that
everywhere.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2020-02-03 Thread Neal Gompa 
On Mon, Feb 3, 2020 at 5:33 PM Kevin Fenzi  wrote:
>
> On Mon, Feb 03, 2020 at 02:15:19PM -0800, Troy Dawson wrote:
> > On Mon, Feb 3, 2020 at 12:29 PM Neal Gompa  wrote:
> > >
> > > On Mon, Feb 3, 2020 at 2:36 PM 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?
> > > >
> > >
> > > Since libssh2 is being dropped from RHEL, I think we should just
> > > permit it as a regular package in EPEL proper. That maximizes its
> > > usefulness to everyone.
> > >
> >
> > I second that.
> > I don't think it matters if it was in a module or not.  If it is no
> > longer in RHEL8, then it should be permitted as a regular EPEL8
> > package.
>
> I agree, but... what about packages that are modules.
>
> What does epel promise not to overlap with? Just bare rpms?
> Any rpm in any modules also?
>
> ie, would it have been ok to make a normal rpm of libssh2 before when it
> was in a module?
>

My understanding is that the only main contract we're maintaining is
with bare RPMs. So technically, yes, it would have been okay to do so
before when it was in a module because we can't use that anyway
without pulling in the module as a dependency anyway, and for a lot of
reasons, it's probably a good idea to avoid that whenever possible to
maintain flexibility for downstream consumers.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

2020-02-03 Thread Neal Gompa 
On Mon, Feb 3, 2020 at 2:36 PM 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?
>

Since libssh2 is being dropped from RHEL, I think we should just
permit it as a regular package in EPEL proper. That maximizes its
usefulness to everyone.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: "python3" vs "python%{python3_pkgversion}"

2019-12-02 Thread Neal Gompa 
On Mon, Dec 2, 2019 at 7:04 PM Miro Hrončok  wrote:
>
> On 03. 12. 19 0:54, Kevin Fenzi wrote:
> > On Tue, Dec 03, 2019 at 12:38:01AM +0100, Miro Hrončok wrote:
> >> On 02. 12. 19 23:09, Ken Dreyer wrote:
> >>> On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa  wrote:
> >>>>
> >>>> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
> >>>>>
> >>>>> Hi folks,
> >>>>>
> >>>>> In EPEL 7 we have some packages with "python34" and "python36"
> >>>>> prefixes in their names. I guess this is a consequence of using the
> >>>>> %{python3_pkgversion} macro over time.
> >>>>>
> >>>>> Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> >>>>> EPEL 7, I'm wondering about this.
> >>>>>
> >>>>> If I'm introducing a Python 3 subpackage in a new build today, should
> >>>>> I name this sub-package "python3-foo" or
> >>>>> "python%{python3_pkgversion}-foo" ?
> >>>>>
> >>>>
> >>>> The subpackage should be "python%{python3_pkgversion}-foo" and you
> >>>> should also make sure you have "%{?python_provide:%python_provide
> >>>> python%{python3_pkgversion}-foo}" in the subpackage declaration too.
> >>>
> >>> This is confusing to me, and it diverges from what Fedora does. Can we
> >>> just reduce this down to "python3-" now that RHEL 7 has python3, and
> >>> we'll probably never put another Python version into EPEL 7?
> >>
> >> We **can** but we **haven't yet**. IMHO doing it in random packages is 
> >> wrong.
> >>
> >> Currently, python36-foo is form EPEL (and if done right, provides 
> >> python3-foo).
> >> OTOH python3-bar is from RHEL (and if done right, provides python36-bar).
> >>
> >> They both provide both names, but from first glance, the origin of the
> >> package is obvious. I kinda like that.
> >>
> >> If we decide to redo this, it will be a lot of boring work for no clear 
> >> benefit.
> >> If we decide to only allow it for new packages, it would be a mess.
> >>
> >> That said, technically:
> >>
> >>   - it works either way
> >>   - there is no real EPEL packaging guideline forcing one way or the other
> >
> > I think we should encourage people to just use python3-foo now, but I
> > agree it would be a lot of work to try and convert everything to do
> > that.
> >
> > The orig reason was so we could move python stacks forward since we were
> > maintaining them in epel. Since python 3.6 is in rhel and rhel7 is past
> > the point where I would expect many changes, I think 3.6 is here to
> > stay, so we dont really need it anymore. It's just extra noise that
> > makes spec files less readable now.
>
> If we want to get rid of it, we might just:
>
> Fix the cases where srpm is called python3-foo and subpackage python36-foo.
> Switch the %{python3_pkgversion} to 3 (= remove the redefinition from EPEL).
>
> Rebuild everything. Profit.
>
> The problem of course, is bootstrapping.
>

We should probably consider rebuilding all the Python 3 packages in
EPEL7 no matter what so that the python3.6dist() Provides get
generated, though. The dependency generator was backported to EL7 and
is used with the Python 3 stack. It just isn't very useful yet because
not all the packages were rebuilt after python3 was introduced in RHEL
7. Though why the --majorver-provides switch was removed from the
attr, I don't know.

After that, we can backport the %python_enable_dependency_generator
macro to EPEL7...



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: "python3" vs "python%{python3_pkgversion}"

2019-12-02 Thread Neal Gompa 
On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer  wrote:
>
> Hi folks,
>
> In EPEL 7 we have some packages with "python34" and "python36"
> prefixes in their names. I guess this is a consequence of using the
> %{python3_pkgversion} macro over time.
>
> Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
> EPEL 7, I'm wondering about this.
>
> If I'm introducing a Python 3 subpackage in a new build today, should
> I name this sub-package "python3-foo" or
> "python%{python3_pkgversion}-foo" ?
>

The subpackage should be "python%{python3_pkgversion}-foo" and you
should also make sure you have "%{?python_provide:%python_provide
python%{python3_pkgversion}-foo}" in the subpackage declaration too.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 Python 3 bindings for C libraries in EL7

2019-11-12 Thread Neal Gompa 
On Tue, Nov 12, 2019 at 1:44 PM Mike DePaulo  wrote:
>
> On Tue, Nov 12, 2019 at 5:05 AM Miro Hrončok  wrote:
> >
> > On 12. 11. 19 7:52, Mike DePaulo wrote:
> > > Hi everyone,
> > >
> > > Background:
> > > The Pulp 3 upstream project is written in Python 3.
> > > Our installer normally uses PyPI for pure python packages, and OS
> > > packages for C libraries & their python bindings.
> > >
> > > Problem:
> > > With RHEL7/CentOS7, we often run into the following thorny situation:
> > > - Package libjuicy, written in C, exists in EL7 (main, optional, or 
> > > extras).
> > > - Subpackage python2-libjuicy with python2 bindings exists in EL7.
> > > - Subpackage python3-libjuicy does not exist at all for EL7.
> > >
> > > Note: libjuicy is a made up name :)
> >
> > If you post the actual libraries, I would bring that up with my team (Python
> > Maint @ Red Hat).
>
> I'm mostly certain this is only this one we strictly "need" right now:
> libcomps
>
> We might need this in the future:
> dnf
>
> This would be helpful, but the current EL7 version is too old for
> Pulp's needs (and we currently have a workaround: a C-compiling
> package on PyPI [1] [2]):
> createrepo_c
>

There are already bugs requesting these things:

* https://bugzilla.redhat.com/show_bug.cgi?id=1672102
* https://bugzilla.redhat.com/show_bug.cgi?id=1719977

They were closed as WONTFIX, but feel free to reopen with your own
justification to add to them to get that changed.



--
真実はいつも一つ！/ Always, there's only one truth!
___
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 Steering Committee Request: Allow minizip-compat

2019-11-04 Thread Neal Gompa 
On Mon, Nov 4, 2019 at 5:26 PM Stephen John Smoogen  wrote:
>
> So I started to review
> https://bugzilla.redhat.com/show_bug.cgi?id=1767883 which is a package
> which is normally in the zlib package but has been commented out from
> shipping on RHEL-8. It is needed for chromium and other items so Tom
> Callaway has made up a package for it. However the naming guidelines
> for packages have deprecated -compat packages even though this seems
> to have been added after that rule was put in place.
>
> In reviewing the package the name was the only thing which came up and
> i would like to give it a pass versus having it renamed to minizip1.2
> (or better yet libminizip since all it is a library) untl the upstream
> zlib package is named that way also.
>

Honestly, it should probably be fixed in Fedora to be minizip1 /
minizip1-devel instead of minizip-compat / minizip-compat-devel...

But I guess that as long as it's not that in Fedora, it's fine to be
not it in EPEL...



--
真実はいつも一つ！/ Always, there's only one truth!
___
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: Mono 5.18 in Epel8 and perhaps in Epel7

2019-09-30 Thread Neal Gompa 
On Mon, Sep 30, 2019 at 4:04 PM Timotheus Pokorra
 wrote:
>
> Hello all,
>
> We currently still have Mono 4.6 in Epel7, and no Mono in Epel8 yet [1].
>
> I suggest that I bootstrap Mono 5.18 for Epel8. [4]
> That is the version that is delivered with Debian 10 "Buster" [2], and I
> guess it will get some kind of long term support.
>
> When that goes well, I would also attempt to upgrade Mono in Epel7 to
> version 5.18.
>
> We need to bootstrap for most minor releases of Mono, because it
> requires newer compiler features. I don't like that too much, but it
> seems to be like that. [3]
>
> I don't know if we should have modules for Mono in Epel, or if that is
> even possible. I have to admit, at the moment I don't have the time to
> maintain multiple versions of Mono.
>
> Please let me know if you have any suggestions or concerns.
>

I'm inclined to suggest we go for the gold here and get Mono 6 into
EPEL8. It's the latest major stable release and I expect that will be
supported for a long time, since it's the base with a brand new
version of the C# standard. I have nothing to suggest that there will
be any kind of maintained stable branches anywhere beyond the major
version maintenance, and that suggests we should move to Mono 6 ASAP.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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?

2019-09-24 Thread Neal Gompa 
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?
>

If we do that, then we should rename `epel8-playground` to `epel8-stream`...

I'd like it to work the same way that epel7 worked. And that means no
more automatic provisioning epel8-playground for epel8 stuff. And
package.cfg should become optional.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: Automatic python dependency generation on EPEL 8

2019-08-18 Thread Neal Gompa 
On Sun, Aug 18, 2019 at 8:50 AM Scott Talbert  wrote:
>
> > On 8/16/19 7:45 PM, Scott Talbert wrote:
> >
> > It seems to be working for me - not sure what the "official" stance is.
>
> Strange, it didn't seem to work here, for example:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1323057

It is not enabled by default for requires, only provides. It's forked
from Fedora 28, which didn't have Requires generation on by default.

In order to enable it, just add the following to the top of your spec:

# Enable Python dependency generation
%{?python_enable_dependency_generator}

See for an example:
https://src.fedoraproject.org/rpms/kiwi/blob/271abe64adf721fb6a27a8d95f0b314c1aa347ad/f/kiwi.spec#_1-2


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: EPEL7: Adapting %python_provide to provide python3- for python36-

2019-04-24 Thread Neal Gompa 
On Wed, Apr 24, 2019 at 6:23 AM Miro Hrončok  wrote:
>
> Hey,
>
> since the plan is to have some python3-... packages in RHEL proper, should we
> adapt the %python_provide macro to provide python3-... when it gets 
> python36-...?
>
> %{python_provide python36-foo} currently does nothing.
> I propose to change it to do: Provides: python3-foo = %{version}-%{release}.
>
> Note: %{python_provide python2-foo} currently adds obsoletes, let's not add 
> them
> for the python36 case (there is nothing to obsolete here, quite the opossite -
> python3-foo from RHEL would in theory obsolete python36-foo from EPEL).
>
> Arguably, this discussion should have happened before we did the mass rebuild
> for 3.4 -> 3.6 transition, however I don't consider such provides essential. 
> The
> idea is to change the macro, but don't mass rebuild - instead start providing
> the provides gradually.
>
> Note that not all EPEL7 Python 3 packages use this macro, but many do.
>

That would actually be great, since it simplifies how people can use it.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] Re: EPEL-ANNOUNCE EPEL: Python34 moving to Python36

2019-03-28 Thread Neal Gompa 
On Thu, Mar 28, 2019 at 8:22 AM Miro Hrončok  wrote:
>
> On 26. 03. 19 1:51, Miro Hrončok wrote:
> > On 25. 03. 19 18:56, Kevin Fenzi wrote:
> >> Just make python36 obsolete the old version of python34 that had
> >> /usr/bin/python3. This causes yum to install the new python34 and pull
> >> in python36 for /usr/bin/python3.
> >
> > If that works, we are good. Does it really behave like that with plain 
> > upgrade?
> > E.g. without specifying what to upgrade?
> >
> > I thought that obsoleting old py34 can do one of the following:
> >
> > A) python34 gets queued for upgrading first, there is no more old python34 
> > to be
> > obsoleted by python36, python36 isn't installed.
> >
> > B) python36 gets queued for obsoleting old python34 first, python34 gets 
> > queued
> > for removing instead of updating, there is more pytho34 to be updated.
> >
> > C) what you said.
> >
> > If C) is the guaranteed behavior, I guess we are good to do this.
> >
> >> It does mean people with 3rd party software are now using python36
> >> instead of 34, but if they only speficied /usr/bin/python3, it should
> >> just run with any python3 version right?
> >
> > As long as they are only using standard library, yes. Otherwise there might 
> > be
> > problems. However that was anticipated.
>
> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>
> I'm still not sure about how it will behave. We should probably test it.
>

Obsoletes means that the old package will get removed as part of the
upgrade. Conflicts means that yum has to figure out a way to keep it.
That's the difference.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] Re: missing libcomps

2019-03-15 Thread Neal Gompa 
On Fri, Mar 15, 2019 at 11:43 AM Stephen John Smoogen  wrote:
>
> On Fri, 15 Mar 2019 at 11:39, Mátyás Selmeci  wrote:
> >
> > On 3/14/19 5:59 PM, Kevin Fenzi wrote:
> > > On 3/14/19 3:22 PM, Mátyás Selmeci wrote:
> > >> Hi,
> > >>
> > >> libcomps
> > >> (https://koji.fedoraproject.org/koji/packageinfo?packageID=16769)
> > >> seems to have been untagged from epel 7?  We can't install koji
> > >> anymore because python-libcomps is a dependency.
> > >
> > > It should be in rhel-extras...
> > >
> > > ah, it's' called python2-libcomps there. So, perhaps we need to rebuild
> > > koji for the different name? Can you file a bug on koji to that effect?
> > >
> > > kevin
> >
> > Bug sent: https://bugzilla.redhat.com/show_bug.cgi?id=1689291
> >
> >
> > Should we assume in general that the rhel-extras or centos-extras or
> > equivalent repos need to be enabled if we want to use EPEL?
> >
>
> EPEL-7 is built against Server, Server-HA, Server-Extras,
> Server-Optional and it is expected that these are available for this
> to be run. We try not to replace or have newer packages than ones in
> those channels.
>
>

CentOS already has Extras enabled by default. And python2-libcomps in
Extras has the `python-libcomps` Provides, so it should just work.

I guess RHEL 7 doesn't have Extras enabled by default?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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] Incoming rebase to Pagure 5.x for EPEL 7 (+ python-celery in EPEL 7 now)

2019-01-30 Thread Neal Gompa 
Hey all,

After the discovery of the lack of python-celery in EPEL 7 when I
first proposed the rebase update for the "pagure" package a few months
ago, I went back to working out how to bring celery into EPEL 7.

I'm pleased to say that a new update has been proposed[1] that updates
"pagure" and includes "python-celery". It awaits testing now.

If you're running an instance of Pagure using the EPEL 7 package,
please backup everything before attempting to follow through the
documentation on upgrading[2]. For clean installations, please consult
the setup documentation[3].

Personally, I would recommend exporting everything out, rebuilding
with the new version, and importing your repositories back in. That is
likely to be less risky, given the substantial delta between 2.x and
5.x.

Going forward, we expect that the "pagure" package will be more
actively maintained, so we will hopefully avoid these problems in the
future.

We're sorry for the inconvenience, but we hope this will be a one-time pain.

[1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-dd9e038712
[2]: https://pagure.io/pagure/blob/master/f/UPGRADING.rst
[3]: https://docs.pagure.org/pagure/install.html

--
真実はいつも一つ！/ Always, there's only one truth!
___
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

  1   2   >