[EPEL-devel] Re: CentOS Stream 8 and 9 - KDE un-updateable for a week

[Stephen John Smoogen]

On Wed, 4 May 2022 at 15:31, Sérgio Basto  wrote:

> On Wed, 2022-05-04 at 20:25 +0100, Sérgio Basto wrote:
>
> dnf --enablerepo=epel-next-testing --whatprovides "libpoppler-qt5.so*"
> nothing  ?!?
>
>
> I missed repoquery word .
>
> dnf --enablerepo=epel-next-testing repoquery --whatprovides
> "libpoppler-qt5.so*"
> nothing  ?!?
>
>
> btw in Fedora 35
>
> dnf repoquery --whatprovides "libpoppler-qt5.so*"
> poppler-qt5-0:21.08.0-1.fc35.i686
> poppler-qt5-0:21.08.0-1.fc35.x86_64
>
>
Looked to see what package owns that in F34.
$ rpm --nosignature --qf='%{SOURCERPM}\n' -qp
poppler-qt5-21.01.0-6.fc34.x86_64.rpm
poppler-21.01.0-6.fc34.src.rpm

I found that package in CRB poppler-qt5-21.01.0-12.el9.x86_64.rpm
/usr/lib64/libpoppler-qt5.so.1
/usr/lib64/libpoppler-qt5.so.1.27.0
-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)

[Stephen John Smoogen]

On Wed, 4 May 2022 at 08:55, Miro Hrončok  wrote:

> Hello EPEL.
>
> I have just found out that the pybind11 component from c9s / RHEL 9 CRB
> has
> been built in EPEL 9 in different version:
>
>
> 


> Do I understand correctly that this is still *not* allowed? If so, what
> can we
> do to prevent it?
>
>
It shouldn't happen, but it doesn't mean it can't happen. It needs to be
fixed but that needs people to have the time and energy to do it over all
the other sh*t-sandwiches they are trying to clean off their plates.

The most common reasons this happens are in the order I have seen them
1. The package was originally put into EPEL because it was for only arches
that aren't shipped in RHEL. It should have remained at the same level as
the ones in RHEL but didn't.
2. The package was put into EPEL before it was put into a channel in RHEL.
This happens a LOT with the Stream method of moving things during the beta
period. Stuff have gone from BuildRoot-only to CRB to AppStream multiple
times.
3. There are timing bugs and general bugs in PDC and other tools which are
meant to help stop this. PDC is dead-ware with no upstream so fixing it is
fun. The other scripts depend on learning what is in Stream and are
fallible. It would take someone running the scripts that releng has to see
why in this case it didn't stop the action.
4. Human mistake somehow allowing this to happen over other things.

1 might be possibly fixed if the compose system knew to lock certain
packages with certain versions. So if pybind11 was meant to be only for
stuff not shipped in s390x/ppc64 then if the version was pushed beyond what
was know the 'compose' would not allow it. [This is a freeform idea and
probably broken in a million ways]
2/3/4 might be possibly fixed with a 'releng toddler' which does what you
did every day and screams if it finds that these conflicts happen on any
arch. Then a report can be made of which arch the conflict happens and what
could be done to fix it. [Again freeform idea and probably broken.]





> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Mon, 2 May 2022 at 04:22, Alex Iribarren  wrote:

> Hi,
>
> On 4/29/22 21:17, Stephen John Smoogen wrote:
> >
> >
> > On Fri, 29 Apr 2022 at 14:28, Germano Massullo
> > mailto:germano.massu...@gmail.com>> 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?
> >
> >
> > This is the current situation of events for dealing with CentOS Stream
> > and EPEL
> > 0. Packages get put into stream at the rate of internal developers doing
> > things and getting stuff put into GIT. There is no communication to know
> > when this will happen so knowing what packages to build before this
> > drops isn't happening.
> > 1. The QT packages in Stream have taken a week to be fixed due to
> > various issues found in them. [Mostly they were built in the wrong order
> > and linked against each other poorly.]
>
> So how could we stop this from happening in the future? The
>

We can't stop it from happening in the future. Pretty much every time I
have seen it is because something changed in the 'way things have been done
previously' and so it looked like a new problem with the same similarities.
I think we can offer solutions to make this better and possibly help
implement prototypes to show that they work or not.


> 50_test_comps[0] test caught some of the problems, but not all because
> not all qt5 packages seem to be listed in a comps group. `dnf install
> qt5-*` is unlikely to work, though I haven't tried.
>
> How could we test that all qt5 packages have been correctly rebuilt? If
> that's done right, the following steps will be a lot less painful.
>
>
I think the primary issue is that the crafting of binary packages is
'fairly' manual. Someone has to put the src.rpm in the meat grinder (koji)
in the right order with the right spices (flags) to make the sausage at the
other end. We rely on the cook to remember how they did it the last 10
times and that the taster (functional and ci) says it works. This normally
works well but then it turns out that something swapped out somewhere and
once 'fully cooked' (composed) that the sausage explodes.

I think we would need to study how the build system really works, and how
the recipe of 'order of builds' is determined. From that we can then
suggest improvements which the CentOS Release Engineering can implement. It
could be that coming up with some tool which makes the order of builds more
automated may help, but without knowing how the workplace actually runs.. I
am just making suggestions from the restaurant table :).



> Cheers,
> Alex
>
> > 2. This means rebuilding packages have to wait until that is fixed as
> > some people found when they jumped on it sooner. Either they could not
> > rebuild anything or when they rebuilt it they needed to do it again when
> > the updated packages with the right library links came out.
> > 3. Packages in EPEL are maintained by a lot of people who may not know
> > that centos-stream have updated rapidly and do not have the spare
> > capacity to update sooner than the weekend spare time they had allotted
> > to do it.
> >
> > What are ways that this could be improved?
> >
> > --
> > Stephen J Smoogen.
> > Let us be kind to one another, for most of us are fighting a hard
> > battle. -- Ian MacClaren
>
> [0]
>
> https://github.com/CentOS/sig-core-t_functional/blob/master/tests/0_common/50_test_comps.sh
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Fri, 29 Apr 2022 at 14:28, 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?
>
>
This is the current situation of events for dealing with CentOS Stream and
EPEL
0. Packages get put into stream at the rate of internal developers doing
things and getting stuff put into GIT. There is no communication to know
when this will happen so knowing what packages to build before this drops
isn't happening.
1. The QT packages in Stream have taken a week to be fixed due to various
issues found in them. [Mostly they were built in the wrong order and linked
against each other poorly.]
2. This means rebuilding packages have to wait until that is fixed as some
people found when they jumped on it sooner. Either they could not rebuild
anything or when they rebuilt it they needed to do it again when the
updated packages with the right library links came out.
3. Packages in EPEL are maintained by a lot of people who may not know that
centos-stream have updated rapidly and do not have the spare capacity to
update sooner than the weekend spare time they had allotted to do it.

What are ways that this could be improved?



> Best regards
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2077742
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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?

[Stephen John Smoogen]

On Fri, 22 Apr 2022 at 14:22, 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:
>
>
> ...


> 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?
>
>
Yes it is expected until RHEL9 comes out and then EPEL9 is moved to using
RHEL9 as its build environment. At some point  a month ago or so, the sync
was stopped from updating CentOS 9 on Fedora's batcave box for using with
koji. That was to make sure that EPEL9 did not start getting packages from
the future which would cause builds not to work after RHEL9 came out.

I think that this was announced earlier but I don't know if it was only at
the Alpha Centauri filing cabinet that I keep track of (aka IRC meeting) or
an email.


> 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.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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 conflicts with Satellite 6 packages

[Stephen John Smoogen]

On Sun, 17 Apr 2022 at 09:54, Amos  wrote:

> > On Wed, 1 Jun 2016 12:31:01 -0600 Erinn Looney-Triggs
>  >
> https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provid...
> 
> > So, thats not a channel that EPEL strives to avoid conflicts with. We
> could consider how to
> > better avoid conflicts with that channel, but I'm not sure there's any
> easy way there. kevin
>
> Apologies for replying to this old thread, but unless I'm mistaken, this
> is still a problem.  More recently, there were two blog posts from Red Hat
> that extolled the virtues of adding the EPEL repository into Satellite:
>
> https://www.redhat.com/sysadmin/epel-8-repo-satellite-6
>
> https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
>
> Apparently, however, at least based on our own experience, this is still a
> problem with RHEL7, 8. Is there anything new on this topic?
>
>
Hi, I realize you are having a problem, but the above email says NOTHING
about what the problem is. What packages are you having and how are you
having them? This is needed before any volunteer here can help.



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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: slowing down the stalled request process

[Stephen John Smoogen]

On Wed, 30 Mar 2022 at 10:55, Troy Dawson  wrote:

>
>
> Current process (two bugzilla pings, two weeks total time):
>> - 1st request
>> - one week goes by
>> - 2nd request
>> - one week goes by
>> - releng ticket to be added as a collaborator
>>
>> Proposal A (three bugzilla pings, three weeks total time):
>> - 1st request
>> - one week goes by
>> - 2nd request
>> - one week goes by
>> - 3rd request
>> - one week goes by
>> - releng ticket to be added as a collaborator
>>
>> Proposal B (two bugzilla pings, four weeks total time):
>> - 1st request
>> - two weeks go by
>> - 2nd request
>> - two weeks go by
>> - releng ticket to be added as a collaborator
>>
>> I also think we can improve the process by having the last bugzilla
>> comment include setting the needsinfo flag.  Please share your
>> thoughts on these alternative process steps.
>>
>> [0]
>> https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests
>> [1]
>> https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/
>>
>
> I prefer Proposal A.
>
> I also like setting the needsinfo flag.  But instead of the "last"
> bugzilla comment, have it be the "2nd" bugzilla comment.
> For both proposals having it be the "2nd" bugzilla comment gives two weeks
> for the needsinfo flag.
>
>
I prefer the current process with adding the needsinfo flag. I think A will
get complaints that we are pinging too much, and B will get complaints that
we didn't ask enough for them to remember (or we were still too fast
because I was on a 6 week vacation, etc etc).


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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Handling packages with missing dependencies provided by HA-RS repos?

[Stephen John Smoogen]

On Fri, 25 Mar 2022 at 00:25, Carl George  wrote:

> On Thu, Mar 24, 2022 at 5:50 PM Kevin Fenzi  wrote:
> >
> > On Wed, Mar 23, 2022 at 09:18:08PM -0500, Carl George wrote:
> > > On Wed, Mar 23, 2022 at 2:54 PM Carl George  wrote:
>
> >
> > Also could we tell if deps changed? Say I have foo-plugin in epel
> > Reccommending foo, and RHEL drops foo. None of our 'will it install' or
> > broken deps type checks will know that it is now not working. ;(
>
> As far as I know RHEL doesn't really drop packages, they stay on the
> CDN for the life of distro.  Even if they do get dropped, this seems
> like an edge case we shouldn't really need to worry too much about.
> If it happens and it results in an EPEL package not working, we'll
> know it should have been a Requires and not a Recommends all along,
> which will lead to either the maintainer adding the necessary
> dependency to EPEL, or retiring the package with the missing
> dependency.
>
>
RHEL doesn't drop any packages from the CDN without a major item. Various
packages which have already gone past their 'Appstream lifecycle' in 8 are
still there. The problem was one of two places.  One, the CentOS rebuild
which only kept the latest in their dot releases. Two, the scripts Fedora
used to reposync from the mirrors usually got only the latest from a dot
branch which would drop certain packages when they were 'removed'. The
second was fixed when we no longer synced from /X.Y/ but only with /X/,
this then keeps the older packages. [I had switched to syncing X.Y so we
would be better able to deal with dot releases breaking CentOS users but
that was seen as breaking koji in other ways so we went back to the X
method.]

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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 support python 3.8 from RHEL 8.2 in EPEL?

[Stephen John Smoogen]

On Wed, 2 Mar 2022 at 17:00, Orion Poplawski  wrote:

> On 3/2/22 14:14, epel-devel@lists.fedoraproject.org wrote:
> > Except that we are going to need python38-pytest, etc. in the EPEL8
> buildroot
> > if we are going to build (most of) the packages in the first place.
> That's
> > the problem I'm running into now trying to build python38-jmespath:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=83570866
> > DEBUG util.py:444:  No matching package to install: 'python38-pytest'
> >
> > So I'm back to my original questions:
> >
> > * Do we just make EPEL python38- packages as modules or try to hack up
> some
> > kind of build system support for it?
> > * If modules, every package a module or one (or a few) modules?
>
> I have been told that the lack of python38-pytest is an issue with the
> buildroot generation and so have filed:
>
> https://pagure.io/releng/issue/10679
>
> Hopefully this will make everything simpler as nothing has to be a module
> or
> special in any way.
>
>
>
So this problem seems to be something with koji and that set of packages in
that sub-directory. I tested this with the following:

1. koji mock-config --tag epel8-next-build --arch x86_64 > e8-next.cfg
2. cp e8-next.cfg e8-next-infra.cfg
3. change `
https://kojipkgs.fedoraproject.org/repos/epel8-next-build/4499598/x86_64`
to `
https://infrastructure-iad.fedoraproject.org/repo/centos/stream8-kojitarget/latest/x86_64/CS-8-001`
in the infra one. This points to the core repo that koji will try to import
as a buildroot.
4. `mock -r e8-next.cfg --enable-network --install dnf; mock -r e8-next.cfg
--enable-network --shell`
```
# dnf list python38-py*
Last metadata expiration check: 0:00:04 ago on Fri Mar  4 09:37:44 2022.
Available Packages
python38-PyMySQL.noarch 0.10.1-1.module_el8.4.0+677+b84873a2   build
python38-pycparser.noarch  2.19-3.module_el8.4.0+647+0ba99ce8
build
python38-pysocks.noarch1.7.1-4.module_el8.4.0+665+abc3a503
build
python38-pytz.noarch  2019.3-3.module_el8.4.0+647+0ba99ce8
build
python38-pyyaml.x86_645.4.1-1.module_el8.6.0+929+89303463
build
```
5. Do the same with the other config so we see what the main is presenting
to koji:
```
# dnf list python38-py*
Last metadata expiration check: 0:00:01 ago on Fri Mar  4 09:39:58 2022.
Available Packages
python38-PyMySQL.noarch 0.10.1-1.module_el8.4.0+677+b84873a2   build
python38-py.noarch  1.8.0-8.module_el8.5.0+742+dbad1979
build
python38-pycparser.noarch  2.19-3.module_el8.4.0+647+0ba99ce8
build
python38-pyparsing.noarch  2.4.5-3.module_el8.5.0+742+dbad1979
build
python38-pysocks.noarch 1.7.1-4.module_el8.4.0+665+abc3a503
build
python38-pytest.noarch4.6.6-3.module_el8.5.0+742+dbad1979
  build
python38-pytz.noarch   2019.3-3.module_el8.4.0+647+0ba99ce8
   build
python38-pyyaml.x86_64 5.4.1-1.module_el8.6.0+929+89303463
build
```

Notice the differing packages. For some reason part of koji is seeing some
problem with the packages in a set of directories and is not allowing
access to them.



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Thu, 3 Mar 2022 at 11:07, Scott Talbert  wrote:

> On Thu, 3 Mar 2022, 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-pytest-forked swt2c 236 weeks ago
> > python-pytest-xdist swt2c 238 weeks ago
>
> These two are used as BRs (at least) of python-wxpython4.  Of course, they
> are used for tests, so we could probably stop running the tests if you
> really need them to be retired.
>
>
I am not needing them retired. I am wanting to make sure they are wanted by
the maintainer to be in EPEL8. If they are then it can stay.



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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Wed, 2 Mar 2022 at 15:56, Stephen John Smoogen  wrote:

>
>
> #
>
> I expect that
>
>
I clearly dropped the ball in that sentence. Let me finish it up:

I expect that we will need to converse in this thread about what should be
done next. In the EPEL meeting Kevin mentioned that I should email the
maintainers of each of the 108 packages and see if they want to maintain it
or remove it from EPEL-8. Then see if we can remove those from the tree
cleanly without affecting packages. Some packages like python-nose should
be removed anyway and if there are any other upstream dead ones those can
go too.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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] EPEL-8 Packages needing care and feeding

[Stephen John Smoogen]

When EPEL-8 was trying to get out the door, I tried to make it 'fully
operational' by having fedpkg in it. It turned out that was a bad idea on
my part as I ended up adding about 130 packages to EPEL-8 which have not
been updated or cared for since.

The problems involved is that I did this with the 'ask for forgiveness vs
ask for permission' approach with the idea that packagers and such would
update as needed over time. This has been highly unfair to the Fedora
packagers who have gotten bugs or requests to update which they had no
interest in. So I would like to start cleaning up and working through which
ones need to be removed.

There are 108 packages which have not been updated since their initial
import. All of them are build dependencies for things like bodhi/koji/mock
which then are required by fedpkg/fedora-packager. [They are in the
included text file]

The list of packages which have been updated since 2019 are shorter and I
will repeat them for sanity sake:
## Updated in 2020
python-bleach
python-fedora
python-gitdb
python-lockfile
python-m2r
python-simplejson
python-smmap
python-twisted
python3-py3dns

## Updated in 2021
GitPython
fedora-packager
kobo
mock
python-django

## Updated in 2022
distribution-gpg-keys
fedora-messaging
fedpkg
koji
mock-core-configs
python-bugzilla
rpkg

#

I expect that

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
# Not updated since initial import
latexmk
pungi
pydot
pyflakes
python-Automat
python-WSGIProxy2
python-alembic
python-apipkg
python-appdirs
python-arrow
python-async-generator
python-backoff
python-bcrypt
python-beautifulsoup4
python-blinker
python-cccolutils
python-chai
python-chameleon
python-colander
python-constantly
python-cornice-sphinx
python-cornice
python-cov-core
python-cpuinfo
python-cryptography-vectors
python-cssselect
python-defusedxml
python-dogpile-cache
python-editor
python-entrypoints
python-enum34
python-execnet
python-feedgen
python-fields
python-filelock
python-flake8
python-flit
python-freezegun
python-gitdb
python-h2
python-hamcrest
python-hpack
python-hupper
python-hyperframe
python-hyperlink
python-incremental
python-isodate
python-kerberos
python-kitchen
python-lockfile
python-mccabe
python-memcached
python-mistune
python-multilib
python-munch
python-nose2
python-openid-cla
python-openid-teams
python-openidc-client
python-parameterized
python-paste-deploy
python-paste
python-pbr
python-pika
python-plaster-pastedeploy
python-plaster
python-pretend
python-priority
python-pycodestyle
python-pylibravatar
python-pyquery
python-pyramid-fas-openid
python-pyramid-mako
python-pyramid
python-pyroute2
python-pytest-benchmark
python-pytest-cov
python-pytest-forked
python-pytest-runner
python-pytest-xdist
python-rdflib
python-requests-kerberos
python-responses
python-selenium
python-service-identity
python-simplemediawiki
python-sphinx-theme-py3doc-enhanced
python-sqlalchemy_schemadisplay
python-sqlparse
python-tempita
python-toml
python-tornado
python-translationstring
python-venusian
python-waitress
python-webob
python-webtest
python-zope-component
python-zope-configuration
python-zope-deprecation
python-zope-event
python-zope-exceptions
python-zope-i18nmessageid
python-zope-interface
python-zope-schema
python-zope-testing
python3-openid
python3-pytest-asyncio

## Updated in 2020
python-bleach
python-fedora
python-gitdb
python-lockfile
python-m2r
python-simplejson
python-smmap
python-twisted
python3-py3dns

## Updated in 2021
GitPython
fedora-packager
kobo
mock
python-django

## Updated in 2022
distribution-gpg-keys
fedora-messaging
fedpkg
koji
mock-core-configs
python-bugzilla
rpkg


___
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

[Stephen John Smoogen]

On Tue, 1 Mar 2022 at 08:19, 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.
>
>
I do not think you will find much disagreement here.. but after 3+ years of
saying it and nothing changing, many of us have made our peace.



> > 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!
>
>
The issue in the past has been that it takes manual matching at times to
make it work. Koji, mock and rpmbuild will all complain in different ways
when package content varies in minute ways. Someone then has to rebuild
that package when that happens, which usually only is found at 2am by some
very cranky engineer who posts a lot of less than polite messages about how
EPEL people are complete crap. Or you find that the internal package is
good enough to have built the RHEL content but still is lacking something
that you expected to be there for anything NOT a RHEL content. Again that
takes inspection and someone to care enough to do it. If we need that, then
we might as well rebuild the content and make sure it is what we wanted in
the first place.



> > 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?
>
>
The way Fedora build system deals with RHEL packages is a bit of 'hack'
compared to how it builds Fedora packages. It sees them as external
packages and (mis)-uses a method which was originally only for
bootstrapping a distro to see packages it did not build itself. This then
requires additional hacks on top of that to keep the facade working.. those
hacks break regularly and have to be manually dealt with. Usually the
breakage then requires some 'we can break the koji database again so do a
full backup and possibly a restore' actions by Fedora release engineering
to delete some entry koji 'thinks' should be there but isn't (or vice
versa). [I believe this happened at least twice when we tried mixing stream
and non-stream.]




> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us 

[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Stephen John Smoogen]

On Tue, 1 Mar 2022 at 03:06, 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?
>
>
This is the same as what was done for RHEL-8 and going back a bit to RHEL-5
also since it was not fully published. Buildroot-only packages will need
extra care and work to make 'epel-only' versions on them. [Experiments of
trying to mix and match CentOS Stream build root and RHEL packages have not
gone well in enough cases to keep that up.] EPEL-only packages will be also
needed as modules are added to RHEL-9 in various future dot releases.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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?

[Stephen John Smoogen]

On Sat, 19 Feb 2022 at 15:55, Neal Gompa  wrote:

> 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.
>
>
We have NEVER enforced this before because EL X-1 -> EL X was only
supported under a tight contract for RHEL with special consultant support
(aka you were probably going to just reinstall anyway). For EL7 to EL8, it
sort of works on the EL side but most side repositories don't mainly
because you are jumping from the packaging formats of Fedora 18 to Fedora
29. For EL8 to EL9 it is more manageable since it is from Fedora 29 to
Fedora 34. That said there are a LOT of side effects which aren't really
even tested from Fedora N to Fedora N+1 at the level that most people use
an 'Enterprise' OS versus a 'Hobby' OS. [Those are mostly unfair
characteristics but what most consumers of EL vs Fedora use in their heads.]

Honestly, if someone pays someone a lot of money to pay for engineers to do
this and yes it could be supported. Otherwise we have to use the copious
(aka non-existant) time from Neal and others to somehow make it happen
because 'it should happen'



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Plea: Take a moment before you branch everything for EPEL 9

[Stephen John Smoogen]

And of course sending emails like this do not help make things better for
either party. My apologies and I am going to cut back on sending email
without a 24 hour "Did you really want to send this timeout?"

On Thu, 17 Feb 2022 at 07:52, Stephen John Smoogen  wrote:

>
>
> Finally. There is NO PROMISE that we are putting these packages in for 10
> years. We have said this over and over again for the last 4 years, but it
> comes up like a bad penny. Packages that are not useful and are not to be
> maintained CAN and WILL be retired. We just need guidance versus pissed off
> emails.
>
>

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Plea: Take a moment before you branch everything for EPEL 9

[Stephen John Smoogen]

On Thu, 17 Feb 2022 at 07:11, Miro Hrončok  wrote:

> Hello EPEL packagers.
>
> I get it that you want as much as possible packages available in EPEL 9,
> but
> before you blindly branch all the dependencies of the packages you care
> about,
> could you maybe take a step back and consider for a few minutes if all the
> dependencies actually make sense?
>
> The dependency might be a leftover from long time ago and might not be
> actually
> needed. Get rid of it in Fedora instead of keeping it that way on EPEL 9.
>
> The dependency might be optional (e.g. it is only BuildRequired to test
> integration with that thing). Do you really need to add a package to EPEL
> 9
> just because your package tests that it can interact with it if it is
> present?
>
>
The working assumption has been that the Fedora package is already cleaned
up and dependencies are there because the main packager thought they were
needed. I and other EPEL packagers have spent enough time 'cleaning up' a
package and then getting yelled at by the main packager that I broke
something important and they wanted me to not touch their package anymore.
[Heck we have caused a couple of people to quit Fedora completely over the
years because of this.]

Due to that, we usually err on if the upstream SIG or packager has put the
package dependency in, they know what they are doing and we are just going
to cause another round of 'EPEL is breaking our distro' threads if we do
otherwise. Heck just getting the package into EPEL from many groups is on
the promise that WE DON'T MAKE CHANGES to their spec file. So while I
understand where you are coming from, we are also not in a position to know
when we can do this and when we can't.

Finally. There is NO PROMISE that we are putting these packages in for 10
years. We have said this over and over again for the last 4 years, but it
comes up like a bad penny. Packages that are not useful and are not to be
maintained CAN and WILL be retired. We just need guidance versus pissed off
emails.



> The package might be deprecated in Fedora and used just because nobody got
> the
> time to do a trivial removal of the dependency. Try removing it or poke
> the
> Fedora maintainer to do it, before you blindly include that tech debt to
> EPEL
> 9. (E.g. I'd be happy to help you remove any python-mock or python-nose
> dependency.)
>
> I realize that analyzing the dependencies is tedious and boring. But
> please do
> us all a favor and invest couple minutes of your time *before* you open
> that
> bugzilla EPEL 9 request or branch that package. If you are not able to
> donate
> couple minutes of your time to the package now, will you be able to take
> care
> of the dozens packages you've just imported in the next ten years?
>
> Thanks for listening, I'll show myself out.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: State of EPEL mock chroots?

[Stephen John Smoogen]

On Fri, 4 Feb 2022 at 12:12, Richard Shaw  wrote:

> On Fri, Feb 4, 2022 at 8:20 AM Stephen John Smoogen 
> wrote:
>
>>
>> On Fri, 4 Feb 2022 at 09:05, Richard Shaw  wrote:
>>
>>> I've gotten frequent requests to support EPEL branches of packages I
>>> maintain for Fedora and I usually don't mind as long as it's "easy",
>>> meaning build dep differences are minor and easy to work around, but mock
>>> seems completely broken for EPEL and I don't like to support packages I
>>> can't easily build.
>>>
>>> I know there's scratch builds, COPR, and stuff but I have a $DAYJOB and
>>> nothing beats being able to test and iterate quickly using mock on my
>>> workstation.
>>>
>>> Out of curiosity I just tried every EL 8 mock config and found the
>>> following results:
>>>
>>> almalinux-8 works
>>> centos-8broken (EOL)
>>> centos-stream-8 works
>>> epel-8-x86_64   broken
>>> epel-next-8-x86_64  works
>>> eurolinux-8-x86_64  works
>>> oraclelinux-8-x86_64works
>>> rhel-8-x86_64   no subscription
>>> rockylinux  works
>>>
>>>
>> Check what /etc/mock/epel-8-x86_64.cfg is linked to on your system. If it
>> is not linked to anything then it is going to be broken and either trying
>> to use the Fedora koji or using data from CentOS mirrors which no longer
>> exist. First step is decide which OS you will use to build EPEL packages
>> against: Rocky, Alma, Oracle, RHEL.
>>
>> $ sudo -i
>> # cd /etc/mock
>> # mv epel-8-x86_64.cfg epel-8-x86_64-old.cfg
>> # ln -s alma+epel-8-x86_64.cfg epel-8-x86_64.cfg
>>
>> Change alma+ to the OS you want to use.
>>
>
> Ok, that's simple enough, but I have to ask the obvious question. :)
>
> Why isn't this fixed in the package?  Though I do remember the thread Gary
> referenced, still I would think it would be a good idea to choose ANY of
> them if for no other reason than to not leave things broken.
>
>
Because any choice was going to look like favoritism and people are rather
particular about which OS they run. The mock people are caught in the
middle and don't really want to be there.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: btrbk-0.31.3-1 missing dependency

[Stephen John Smoogen]

On Thu, 27 Jan 2022 at 07:23, Nick Howitt  wrote:

>
>
> On 27/01/2022 12:20, Stephen John Smoogen wrote:
> >
> >
> > On Thu, 27 Jan 2022 at 04:38, Nick Howitt via epel-devel
> >  > <mailto:epel-devel@lists.fedoraproject.org>> wrote:
> >
> > Hi gents,
> > It looks like btrbk has been updated to version 0.31.3-1 in EPEL7
> from
> > 0.25.1-1 and it has a requires of btrfs-progs >= 4.12. Unfortunately
> > btrfs-progs in Centos 7 is still at 4.9.1-1 so it is blocking yum. Is
> > this a packaging error in EPEL or a problem at Centos? I don't know
> if
> > EL7 have bumped their version.
> >
> >
> > This is an EPEL packaging error. EL7 is basically frozen and will not be
> > getting package updates beyond security updates
>
> Does that mean it is going to be removed from the EPEL repo?
>
>
It is up to the package maintainer. If they do not think that 0.25.1 is
secure to keep in the repo then yes it would be removed. EL7 now has  'a 2
year lifetime' until it is end of lifed, and so this starts happening where
maintainers start finding that the work to keep something 'working' is
higher than not having it. The way to fix this package currently would be
to either go back to the older one or see if the 0.31.3 can work with the
EL7 btrfs-progs OR someone ships a epel-btrfs-progs for EL7.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: btrbk-0.31.3-1 missing dependency

[Stephen John Smoogen]

On Thu, 27 Jan 2022 at 04:38, Nick Howitt via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:

> Hi gents,
> It looks like btrbk has been updated to version 0.31.3-1 in EPEL7 from
> 0.25.1-1 and it has a requires of btrfs-progs >= 4.12. Unfortunately
> btrfs-progs in Centos 7 is still at 4.9.1-1 so it is blocking yum. Is
> this a packaging error in EPEL or a problem at Centos? I don't know if
> EL7 have bumped their version.
>

This is an EPEL packaging error. EL7 is basically frozen and will not be
getting package updates beyond security updates



> Regards,
> Nick
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Sun, 16 Jan 2022 at 07:23, Miro Hrončok  wrote:

> On 16. 01. 22 12:49, Andrew C Aitchison wrote:
> > On Sun, 16 Jan 2022, Miro Hrončok wrote:
> >
> >> On 15. 01. 22 20:22, Andrew C Aitchison wrote:
> >>> On Sat, 15 Jan 2022, Miro Hrončok wrote:
> >>>
>  python-pytest-cov is something I've lobbied has no business in an
>  enterprise distro at all.
> >>>  ......
>  As for EPEL I strongly suggest not to introduce python-pytest-cov
> either.
>  If your package depends on it, please drop the dependency instead,
> see
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_linters
> >>>
> >>> In %check, packages SHOULD NOT run “linters”: code style checkers,
> test
> >>> coverage checkers and other tools that check code quality rather
> than
> >>> functionality.
> >>> Agreed.
> >>>
> >>> Linters do make sense in upstream CI. But not in Fedora.
> >>> Not inside Fedora *packages*, but
> >>> if these tools are not available to those using RHEL, Fedora or EPEL
> >>> is that a suitable platform for CI or for developers ?
> >>>
> >>
> >> Yes, most certainly it is a sustainable *platform* for CI. On such
> platform,
> >> you install your dev-dependendencies from PyPI. Not from the platform
> itself.
> >
> > Hmm.
> > A linter is a tool.
> > I cannot build most packages without a C compiler and I don't see many
> packages
> > with
> >  BuildRequires: gcc
> > yet I expect a dev platform to include a C compiler.
>
> I do expect a dev platform to include a C compiler as well.
> I also expect it includes Python interpreter and a tool to install Python
> packages.
> I *do not* except it to include every dev-usefull Python package however.
>
>
So two different things:
1. Actually
https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/ says
that packages do now require it. I believe this started in Fedora 30-ish so
EPEL-8/EPEL-9 packages will start requiring that.
2. We aren't talking about the OS including every dev-useful Python
package. We are talking about a repository called EPEL including things
which are in Fedora and trying to meet the  needs for Enterprise clients
which can be a mass of bailing wire of software going back to 20 years ago
but also requiring the latest stuff. A good many of them can't just do a
pypi install because they have ITIL or some other change control standard
which says that the software must have been bundled in XYZ format,
reviewed, etc. In the past EPEL was a good fit for python etc but it may
not be with the modularization and fast moving python streams.






-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Fri, 14 Jan 2022 at 10:57, Stephen John Smoogen  wrote:

>
>
> I mirrored the source rpms down and did the following for 8 and 9-stream.
> ```
> $ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i -type f
> -name "*src.rpm" | xargs rpm --nosignature --qf='%{NAME}\n' -qp >
> /tmp/a-$i; sort -o /tmp/a-$i -u /tmp/a-$i; done
> $ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
> $ wc -l /tmp/a* /tmp/b*
>   2652 /tmp/a
>   1740 /tmp/a-AppStream
>536 /tmp/a-BaseOS
>503 /tmp/a-PowerTools
>   2273 /tmp/b
>   1620 /tmp/b-AppStream
>399 /tmp/b-BaseOS
>295 /tmp/b-CRB
> $ comm -1 -2 /tmp/a /tmp/b | wc -l
> 2090
> $ comm -1 -3 /tmp/a /tmp/b | wc -l
> 183
> $ comm -2 -3 /tmp/a /tmp/b | wc -l
> 562
> ```
> So 183 packages were added to 9 that weren't in 8 and 562 packages were
> 'removed'. Some of those are obsolete packages like
>
python2, python36,python38, gcc-toolset-9, gcc-toolset-10, autoconf213.
> Others are module things which aren't shipped already.
>

The following statement was wrong. Some subset of that 500 may be built and
could go into CRB, but that would require mirroring the CentOS Stream koji
which I didn't do.


> That leaves about 500 source packages which aren't even built internally
> so aren't going into CRB.
>
>
>
>
>
> --
> Stephen J Smoogen.
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Fri, 14 Jan 2022 at 10:22, Troy Dawson  wrote:

>
>
> On Thu, Jan 13, 2022 at 8:12 PM Orion Poplawski  wrote:
>
>> While working on EPEL9, it seems that even more packages are missing
>> from RHEL9 than were in RHEL8.  The latest I found was cppunit, which
>> appears to be completely missing from the CS9 repos despite having been
>> built (See
>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
>> presumably in the CS9/RHEL9 buildroot.
>>
>> So I scraped some screens from pkgs.org:
>>
>> Stream 9:
>>
>> CentOS AppStream Official   x86_64 8882
>> CentOS BaseOS Official  x86_64 2357
>> CentOS CRB Official x86_64 1856
>>
>> Stream 8:
>>
>> CentOS AppStream Official   x86_64 15008
>> CentOS BaseOS Official  x86_64 6721
>> CentOS PowerTools Official  x86_64 3771
>>
>>
> Sorry, but those numbers are wrong for a comparison.
> There are not 15,000 unique packages in AppStream, not even close.
> What I believe you, or they, are counting is the total number of packages
> released.
> So, if the kernel has been released 15 times since Stream 8 started, then
> it's counted as 15.
> Because of that, it's natural for the numbers to be bigger, because Stream
> 8 has been out longer.
>
> If you want the numbers, I can get them.
> Last time I checked, RHEL9 was very close to the same number of packages
> as RHEL8.
> It was more, but very close to the same number.
>
>
I mirrored the source rpms down and did the following for 8 and 9-stream.
```
$ for i in AppStream BaseOS PowerTools; do echo $i; find ./$i -type f -name
"*src.rpm" | xargs rpm --nosignature --qf='%{NAME}\n' -qp > /tmp/a-$i; sort
-o /tmp/a-$i -u /tmp/a-$i; done
$ sort -o /tmp/a -u /tmp/a-* ; sort -o /tmp/b -u /tmp/b-*
$ wc -l /tmp/a* /tmp/b*
  2652 /tmp/a
  1740 /tmp/a-AppStream
   536 /tmp/a-BaseOS
   503 /tmp/a-PowerTools
  2273 /tmp/b
  1620 /tmp/b-AppStream
   399 /tmp/b-BaseOS
   295 /tmp/b-CRB
$ comm -1 -2 /tmp/a /tmp/b | wc -l
2090
$ comm -1 -3 /tmp/a /tmp/b | wc -l
183
$ comm -2 -3 /tmp/a /tmp/b | wc -l
562
```
So 183 packages were added to 9 that weren't in 8 and 562 packages were
'removed'. Some of those are obsolete packages like
python2, python36,python38, gcc-toolset-9, gcc-toolset-10, autoconf213.
Others are module things which aren't shipped already. That leaves about
500 source packages which aren't even built internally so aren't going into
CRB.





-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

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.



> Thanks.
>
> --
> Orion Poplawski
> he/him/his - surely the least important thing about me
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
> ___
> 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
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Packages disappearing from the EPEL 9 buildroot

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 06:29, Mattias Ellert 
wrote:

> Hi!
>
> Two packages I built for EPEL 9 are now reported by koschei as having
> missing build dependencies.
>
> https://koschei.fedoraproject.org/package/davix?collection=epel9
>
> https://koschei.fedoraproject.org/package/uglify-js?collection=epel9
>
> The EPEL 9 builds were built using the following build dependencies
> according to the root.log files:
>
> rapidjson-devel-1.1.0-19.el9
>
> web-assets-devel-5-15.el9
> nodejs-packaging-2021.01-5.el9
>
> These can no longer be found in the koji buildroot. There are no
> expired buildroot overrides for these builds, which could explain the
> disappearance.
>
> I can't find these builds in EPEL's koji, so I guess they where
> provided by RHEL, but now are no longer? Did RHEL dop these?
>
>
OK there was a period in the EPEL-9 startup where the buildroot was
pointing to a copy of the CentOS Stream-9 koji build root. This was done to
help kickstart things, but it had the issue that packages that RHEL is not
going to ship to customers were available also. About 2-3 weeks ago, the
EPEL steering committee decided to move the buildroot to the properly
shipped chain of packages in CentOS Stream versus the buildroot. This
removed a bunch of packages that were 'available' but not going to be
shipped. These packages will need to be made into epel-only packages or
some other solution. I am fuzzy on this myself as I am from a different
philosophy school of building and shipping packages.



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


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Stephen John Smoogen]

On Mon, 13 Dec 2021 at 22:20, Matthew Miller  wrote:
>
> On Mon, Dec 13, 2021 at 09:40:19AM -0500, Stephen John Smoogen wrote:
> > It is a fairly manual process where a person volunteers to sit in
> > front of the firehose every day and deal with these requests. The
> > person who has to process them has a checklist of policy items they
> > have to confirm/check to make sure the branch is possible.
>
> Where is that checklist? I found

I don't know myself.

> https://docs.pagure.org/releng/sop_process_dist_git_requests.html, but it
> refers to a tool which is deprecated in favor of another one, at
> https://pagure.io/fedscm-admin/, but none of those places have a clear
> articulation of the policy items.
>
> I get human sanity check of new package requests is good, although really
> ideally I would hope that wouldn't fall to the rel-eng/scm firehose
> volunteers.
>
> 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.

>
> * I'm very sad that this isn't "So, would you like to do it anyway, and then
>   make a module?", but c'est la vie

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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

[Stephen John Smoogen]

On Mon, 13 Dec 2021 at 09:25, Miroslav Suchý  wrote:
>
> Hi.
>
> I have two questions regarding epel9:
>
> 1) I have requested dozen of epe9 branches for my packages. It was 20+ hours 
> ago. E.g.
> https://pagure.io/releng/fedora-scm-requests/issue/39402
> Is it manual process? Or is the automation broken?
>

It is a fairly manual process where a person volunteers to sit in
front of the firehose every day and deal with these requests. The
person who has to process them has a checklist of policy items they
have to confirm/check to make sure the branch is possible.

> 2) It was quite pain to go through all my packages and find which ones 
> actually have EPEL version. And which ones are in
> RHEL9 now. I would actually appreciate if there were mass package request. 
> Closing such BZ as WONTFIX is a) rare b) much
> easier than come up with the list. Does someone plan to do such mass report 
> for EPEL9? Or should I do that? Or is it bad
> idea?
>

No idea on this one.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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

[Stephen John Smoogen]

On Mon, 13 Dec 2021 at 06:21, Neal Gompa  wrote:
>
> 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.



The file is there
```
$ ls -lZ 
/mnt/fedora/app/fi-repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/
total 8
-rw-r--r--. 1 root root system_u:object_r:nfs_t:s0 7065 2021-12-11
22:24 basesystem-11-13.el9.noarch.rpm

```
I see 404's internal and external on Dec 11 but on Dec 13 it looks
like it is working with 200's.
```
 - - [11/Dec/2021:21:58:23 +] "GET
/repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesystem-11-13.el9.noarch.rpm
HTTP/1.1" 404 196 "-" "libdnf (Fedora Linux 35; generic;
Linux.x86_64)"

 - - [13/Dec/2021:11:21:10 +] "GET
/repo/centos/centos-9-stream/x86_64/toplink/packages/basesystem/11/13.el9/noarch/basesystem-11-13.el9.noarch.rpm
HTTP/1.1" 200 7065 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.74
Safari/537.36 Edg/79.0.309.43"
```



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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 anyone still using EPEL8 Playground?

[Stephen John Smoogen]

On Sat, 11 Dec 2021 at 11:03, Richard Shaw  wrote:
>
> On Fri, Dec 10, 2021 at 7:29 AM Troy Dawson  wrote:
>>
>> We (The EPEL Steering Committee) are following up on EPEL issue 136[1] 
>> regarding the status of EPEL8 Playground.
>>
>> Looking through the logs we see that there are still people building against 
>> playground on a regular basis.  But as I look into each of those packages, 
>> the same package is built in both epel8 and epel8-playground, at the same 
>> time.
>>
>> This leads me to believe that the only reason people are still building on 
>> playground is because they feel obligated to, not because they really need 
>> someplace to test things out.
>>
>> So, if anyone is still using epel8-playground for something they can't get 
>> from epel8-next and/or COPR,  please let us know.  Otherwise we will shut it 
>> down and call it an interesting experiment.
>
>
> I really liked the idea when it was first implemented as it allowed me to 
> update some packages with breaking things for other users, but in practice I 
> didn't use it very much.
>
> TBH, $DAYJOB and $LIFE have gotten very busy for me so I have pulled back on 
> my EPEL packaging quite a bit, and now with all the craziness around CentOS 
> and 9 vs 9-next and 8 vs 8 Stream I just can't keep up with all the changes. 
> I read the emails, but I don't have the time to invest to get a clear picture 
> in my head of all the moving pieces.
>
> So 8 is EOL at the end of the year, but 8 Stream is not, correct?

CentOS-8 is EOL. EPEL-8 is not because there is RHEL-8, AlmaLinux-8,
Oracle Linux 8, and Rocky Linux 8.
CentOS-8 Stream should be around until ~2024 when RHEL-8 goes from
doing regular rebases to its 'only doing security updates' til its EOL
CentOS-9 Stream should be around until ~2027 when RHEL-9 goes from ...

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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

[Stephen John Smoogen]

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
> > > 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.
>
> You're correct. With the current setup, it's also relatively simple to
> revert to the "frozen" release, which handles most of the regression
> situations. And Fedora releases are nowhere near so long-lived as RHEL
> and EPEL, so it tends to be less of a long-lived problem.
>
> > RHEL *does* maintain multiple old versions, but their system is
> > completely different and supports that capability.
>
> What would it take to get Fedora, or at least EPEL, to preserve old
> releases in the default published repos? I appreciate that it would
> require thought and expand them noticeably, especially for bulky and
> frequently updating components like chromium. I admit to not having
> numbers on how much churn happens there: does anyone have numbers?

In order to keep older package releases, it would require changes to
the compose tool pungi. It would also have to make it so it worked for
EPEL versus Fedora. [Fedora Linux releases have grown to the point
that many mirrors can barely carry the OS as is.. adding in older
packages is out of the question for 

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

[Stephen John Smoogen]

On Mon, 22 Nov 2021 at 10:15, Neal Gompa  wrote:
>
> 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

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

I would personally like to go this route (Alma+EPEL) myself. Yes I
work for Red Hat and even if I didn't I could get the copies of the
code via the Red Hat Developers program.. but dealing with a
subscription manager while trying to build on Fedora 3X etc has not
been reliable for me. [And saying that I could use a dedicated RHEL8
virtual machine is only going to work for EL8. You would need to have
fedpkg and similar tools in EPEL-9 for the tools to work in EL9.]



--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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?

[Stephen John Smoogen]

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.



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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: DNF replacement in EL 9?

[Stephen John Smoogen]

On Wed, 17 Nov 2021 at 12:57, Neal Gompa  wrote:
>
> On Wed, Nov 17, 2021 at 12:53 PM Richard Shaw  wrote:
> >
> > I was talking to a software vendor about there install instructions using 
> > yum instead of dnf for EL 8 and he took the feedback back to the 
> > development team but the response was that dnf was "going away" in EL 9...
> >
> > Did I miss something?
> >
>
> RHEL product folks hate the name "DNF", so they always call it "YUM
> powered by DNF technology". Consequently, the documentation uses "yum"
> instead of "dnf", even if it's the same thing ("yum" is a symlink to
> "dnf").

I am going to call that an inaccurate and misleading statement which I
have corrected you once before on. The product folk really really
wanted to call it dnf in the run up and to remove yum name in EL8 and
they would have loved to do so in EL9. The main issue is that the
majority of the customer base for Enterprise Linux are on the Late
Majority and later group who complained a lot about the fact that they
had just finished changing all their documentation from up2date to yum
and were not happy about doing it for a tool which used the same
command arguments as 'yum'. These are companies which move large
numbers of systems across multiple releases and want a consolidated
documentation for all the 'supported' releases. As such, yum is
probably going to be around for decades even if RHEL moved to .deb
packages.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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 on RHEL 8.2 broken?

[Stephen John Smoogen]

On Tue, 9 Nov 2021 at 10:47, Richard Shaw  wrote:
>
> I requested a CentOS 8 Stream server from IT at $DAYJOB, but it's not IT 
> approved, so they gave me a RHEL 8.2 instance. Well fine, I don't need their 
> support but whatever...
>
> I went to enable EPEL per the docs[1]:
>
> $ sudo dnf install 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
> $ sudo subscription-manager repos --enable 
> "codeready-builder-for-rhel-8-$(arch)-rpms"
>
> So far so good, now I try a 'sudo dnf --refresh update' and get:
>
> $ sudo dnf --refresh update
> Updating Subscription Management repositories.
> Extra Packages for Enterprise Linux Modular 8.2 - x86_64  
>213 kB/s |  79 kB 00:00
> Errors during downloading metadata for repository 'epel-modular':
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2=x86_64=$infra=$contentdir
>  (IP: 67.219.144.68)
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2=x86_64=$infra=$contentdir
>  (IP: 38.145.60.21)
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2=x86_64=$infra=$contentdir
>  (IP: 38.145.60.20)
> Error: Failed to download metadata for repo 'epel-modular': Cannot prepare 
> internal mirrorlist: Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2=x86_64=$infra=$contentdir
>  (IP: 67.219.144.68)
>
> So I try disabling modular repos:
>
> $ sudo dnf --refresh --disablerepo=epel-modular update
> Updating Subscription Management repositories.
> Extra Packages for Enterprise Linux 8.2 - x86_64  
> 76 kB/s |  79 kB 00:01
> Errors during downloading metadata for repository 'epel':
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-8.2=x86_64=$infra=$contentdir
>  (IP: 152.19.134.198)
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-8.2=x86_64=$infra=$contentdir=1
>  (IP: 140.211.169.206)
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-8.2=x86_64=$infra=$contentdir
>  (IP: 140.211.169.206)
>   - Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-8.2=x86_64=$infra=$contentdir
>  (IP: 152.19.134.142)
> Error: Failed to download metadata for repo 'epel': Cannot prepare internal 
> mirrorlist: Status code: 404 for 
> https://mirrors.fedoraproject.org/metalink?repo=epel-8.2=x86_64=$infra=$contentdir
>  (IP: 152.19.134.198)
>
> What gives?
>

the problem is that the system seems to be RHEL-EUS with 8.2 and EPEL
is rolling with latest RHEL. So mirrormanager does not know what
`repo=epel-8.2` is. You may be able to install packages by either
editing the epel.repo to say `repo=epel-8` OR change the baseurl to
point to the 8.2 snapshot in archives:
https://dl.fedoraproject.org/pub/archive/epel/8.2.2020-11-04/


> Thanks,
> Richard
> ___
> 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



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
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

[Stephen John Smoogen]

On Tue, 19 Oct 2021 at 01:22, Andrew C Aitchison  wrote:
>
> On Thu, 7 Oct 2021, Stephen John Smoogen wrote:
> > Things have probably improved, but the lesson I learned from EPEL-8
> > and afterwords was that koji depsolving is weird no matter how set up.
> > Koji sets up mock environments in a way that will do fine as long as
> > there are NO modules in the repositories it is looking at. Once a
> > module, even a non-default module, is there things start to go wonky
> > because the way that koji depsolves will say that
> > 'foobaz-3.10.1-3+module' is a better solution than
> > 'foobax-3.9.4.' it will then try to pull that in and boom you
> > end up with broken builds. You can change the method that koji chooses
> > packages to be in the buildroot, but the other option ends up trying
> > to insert things like foobax-3.9.4-i386 into an x86_64  or still does
> > the modular change but chooses foobar-2 due to some depsolv quirk.
>
> Is the foobar/foobaz/foobax intended or are they typos ?
> If they are intended, then I think we have a partially ordered set of
> packages, ie it isn't always possible to say whether a > b or a < b.
>
> Without knowing anything about koji, I'd say that whilst
> foobaz and foobax can provide foobar (and perhaps foobar==3)
> they cannot satisfy foobar>=3.9 (unless they are forks or
> reimplementations of foobar-3.9).
>

In the case I was remembering they were forks and say inside them that
they satisfy anything >= 3.9. Normally you would only have one in a
buildroot but you could have alternatives in modules because they each
fixed something specific to that module. If you tried to install both
modules you would get conflicts so only one module was to be installed
at a time.. However, Koji doesn't know that.. one solution method only
knows NEVR, Provides and Requires and another tries to use a bit of
dnf to do resolutions but that seemed to act weirdly also.

In the case where they are all foobar but say foobar-4.0 or foobar4 is
in a non-default module, then koji and dnf might come again to
different conclusions of what is needed to be in the buildroot. The
only mental solution I could come up with was that there would need to
be some tool to put all modules (and bare rpms dependent on them) into
a RHEL-modularity tree and somehow import that into MBS so that it
could deal with them. That would then allow for both EPEL modules to
depend on them, and keep them out of the way for koji regular builds.
The major problems with that was
a) no perl/python/ruby/etc in non-modular builds (all that would be
available is platform-python)
b) it would break Fedora build system in ways because it assumes what
is in its toolkit was built by it and we are faking these.

In any case, it is a conundrum wrapped up in an enigma surrounded by a puzzle.


> --
> Andrew C. Aitchison Kendal, UK
> and...@aitchison.me.uk
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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: why ccache is not available on epel7 ?

[Stephen John Smoogen]

On Fri, 8 Oct 2021 at 11:56, Sérgio Basto  wrote:
>
> On Fri, 2021-10-08 at 10:13 -0400, Stephen John Smoogen wrote:
> > On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
> > >
> > > Hi,
> > >
> > > I see ccache for epel 7 here
> > > https://src.fedoraproject.org/rpms/ccache
> > > , but is not available in repos ... why ?
> > >
> >
> >
> > https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
> > https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm
> >
> > So it is in the repos. I also was able to install it on a fresh
> > CentOS-7 system. Not sure why it is not showing up for you.
> > >
>
> Sorry , I was using  mock -r centos-7-x86_64
>
> is centos-7 that don't have ccache ! epel-7 have it

Ha! No problem. I spent an hour yesterday trying to find out why a set
of builds were failing because I was using `mock -r centos-8-aarch64`
when I meant `mock -r epel-8-aarch64`

>
> Thank you.
>
> > > Thank you,
> > > --
> > > Sérgio M. B.
> > > ___
> > > 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
> >
> >
> >
> > --
> > Stephen J Smoogen.
> > I've seen things you people wouldn't believe. Flame wars in
> > sci.astro.orion. I have seen SPAM filters overload because of
> > Godwin's
> > Law. All those moments will be lost in time... like posts on a BBS...
> > time to shutdown -h now.
> > ___
> > 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
>
> --
> Sérgio M. B.
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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: why ccache is not available on epel7 ?

[Stephen John Smoogen]

On Fri, 8 Oct 2021 at 09:55, Sérgio Basto  wrote:
>
> Hi,
>
> I see ccache for epel 7 here https://src.fedoraproject.org/rpms/ccache
> , but is not available in repos ... why ?
>


https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ccache-3.7.7-1.el7.x86_64.rpm
https://dl.fedoraproject.org/pub/epel/7/ppc64le/Packages/c/ccache-3.7.7-1.el7.ppc64le.rpm

So it is in the repos. I also was able to install it on a fresh
CentOS-7 system. Not sure why it is not showing up for you.



>
> Thank you,
> --
> Sérgio M. B.
> ___
> 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



--
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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

[Stephen John Smoogen]

On Thu, 7 Oct 2021 at 09:52, Neal Gompa  wrote:
>

> >
> > 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].

Things have probably improved, but the lesson I learned from EPEL-8
and afterwords was that koji depsolving is weird no matter how set up.
Koji sets up mock environments in a way that will do fine as long as
there are NO modules in the repositories it is looking at. Once a
module, even a non-default module, is there things start to go wonky
because the way that koji depsolves will say that
'foobaz-3.10.1-3+module' is a better solution than
'foobax-3.9.4.' it will then try to pull that in and boom you
end up with broken builds. You can change the method that koji chooses
packages to be in the buildroot, but the other option ends up trying
to insert things like foobax-3.9.4-i386 into an x86_64  or still does
the modular change but chooses foobar-2 due to some depsolv quirk.

At the moment I think building without grobisplitter will work, but I
am thinking some other solution will need to be made when EL9.x starts
rolling out with modules in it.

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




-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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-release-latest-7.noarch.rpm is broken

[Stephen John Smoogen]

On Mon, 13 Sept 2021 at 02:38, Benjamin Kircher  wrote:
>
> On Mon, 2021-09-13 at 06:20 +, Eduard Ahmatgareev wrote:
> > According to documentation:
> > https://docs.fedoraproject.org/en-US/epel/
> >
> > EPEL repo: https://dl.fedoraproject.org/pub/epel/ should contain  epel-
> > release-latest-7.noarch.rpm
> > But I can't find epel-release-latest-7.noarch.rpm in this repo right
> > now:
> >
> > bash-4.2# wget
> > https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> > --2021-09-13 06:19:03--
> > https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> > Resolving dl.fedoraproject.org (dl.fedoraproject.org)... 38.145.60.22,
> > 38.145.60.23, 38.145.60.24
> > Connecting to dl.fedoraproject.org
> > (dl.fedoraproject.org)|38.145.60.22|:443... connected.
> > HTTP request sent, awaiting response... 403 Forbidden
> > 2021-09-13 06:19:03 ERROR 403: Forbidden.
> >
> >
> > Also I found some thread:
> > https://lists.fedoraproject.org/archives/list/releng-c...@lists.fedoraproject.org/message/RJPH665LWU4EINEK6M2253RDAZODP5E5/
> > looks like something is broken  in pipeline or changed
>

This looks to have been fixed around 09:50 UTC.  I am not sure what
was the cause of the breakage
-rw-r--r--. 1  263 263 15608 2021-09-04 17:49
/srv/web/pub/epel/7/x86_64/Packages/e/epel-release-7-14.noarch.rpm
-rw-r--r--. 1  263 263 23644 2021-09-04 17:34
/srv/web/pub/epel/8/Everything/x86_64/Packages/e/epel-release-8-13.el8.noarch.rpm
lrwxrwxrwx. 1 root 26348 2021-09-13 09:55
/srv/web/pub/epel/epel-release-latest-7.noarch.rpm ->
7/x86_64/Packages/e/epel-release-7-14.noarch.rpm
lrwxrwxrwx. 1 root 26363 2021-09-13 09:52
/srv/web/pub/epel/epel-release-latest-8.noarch.rpm ->
8/Everything/x86_64/Packages/e/epel-release-8-13.el8.noarch.rpm




-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Building EPEL-8 package depending on module

[Stephen John Smoogen]

On Mon, 6 Sept 2021 at 07:07, Petr Pisar  wrote:
>
> V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> > I am trying to build a package for EPEL-8.
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=75036069)
> >
> > The build fails with
> >
> > No matching package to install: 'glassfish-jaxb-api'
> > No matching package to install: 'jaf'
> > Not all dependencies satisfied
> > Error: Some packages could not be found.
> >
> > "glassfish-jaxb-api" and "jaf" are available in AppStream modules 
> > "pki-deps" and "jmc".
> >
> > 1. Why can't these packages be found? I thought koji auto-resolves/flattens 
> > the modules.
> >
> Koji only flattens default module streams. Those are flagged with "[d]" in
> "dnf module list" output. Those streams are "enabled" by default and therefore
> Koji flattens them. Other streams must be explicitly enabled with "dnf module
> enable module:stream" and Koji does not flatten them.
>
> glassfish-jaxb-api belongs to pki-deps:10.6 stream (as found by "dnf module
> provides glassfish-jaxb-api" command).
>
> pki-deps:10.6 is not a default stream (as reported by "dnf module list
> pki-deps"; compare to "dnf module list php").
>
> Therefore Koji does not flatten pki-deps:10.6 module stream and its packages
> are not available in an EPEL build root.
>
> Why is not the stream default? (Even if it's the only pki-deps stream.)
> Because it's an internal dependency for pki-core:10.6 stream perhaps not
> intended for other use.
>
> > 2. What is the right approach to build the package that depends on modules?
> >
> The right approach for building a package that depends on a non-default stream
> is building it as another module.
>

Sadly that doesn't work either in the Koji system, because MBS does
not see those modules as belonging to anything it has built. So it
seems it can only depend on modules which it has built .. So not only
do we have to build this tool as a module, we also have to build
pki-deps:10.6 locally.


> Please note that due to Fedora policies
>  your new module
> can't be made default one. Hence if you decide for creating "xstream"
> module, your users will have to install xstream with "dnf module install
> xstream" (or "dnf module enable xstream && dnf install xstream").
>
> Another option is to skip all the modular things and repackage
> glassfish-jaxb-api in EPEL as any other missing package. This is explictly
> allowed for packages from RHEL non-default streams
> .
>
> -- Petr
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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: CPE to staff EPEL work

[Stephen John Smoogen]

On Thu, 2 Sept 2021 at 09:29, Troy Dawson  wrote:
>
> We are pleased to announce that Red Hat is establishing a small team
> directly responsible for participating in EPEL activities. Their job
> isn't to displace the EPEL community, but rather to support it
> full-time. We expect many beneficial effects, among those better EPEL
> readiness for a RHEL major release. The EPEL team will be part of the
> wider Community Platform Engineering group, or CPE for short.
>
> As a reminder, CPE is the Red Hat team combining IT and release
> engineering from Fedora and CentOS.
>
> Right now we are staffing up the team and expect to see us begin this
> work from October 2021. Keep an eye on the EPEL mailing list[1] and the
> associated tracker[2] as we begin this exciting journey with the EPEL
> community.
>

Congratulations to all involved. I believe this is something needed
for years and it will help the project greatly.


> [1]
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/
>
> [2] https://pagure.io/epel/issues
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
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: Proposed change to bodhi days to stable for epel

[Stephen John Smoogen]

On Thu, 22 Jul 2021 at 14:42, Troy Dawson  wrote:
>
> Currently the default days to stable for EPEL is 14 days.
> I believe when it was first put in it was set to that time because we wanted 
> things more stable and better tested.  But experience has found that if a 
> package is going to get tested, it usually is in the first few days of when 
> it was built.  Thus 14 days seems to be 4 days of testing, and 10 days of 
> sitting.
>
> I am proposing that we change the "days to stable" for epel to 7 days, 
> matching Fedora's "days to stable".
>
> People have asked that the epel-next "days to stable" be dropped down to 3 
> days, matching Fedora when it is in it's development phase.  The reasoning is 
> that epel-next is built off CentOS Stream, which only has 6 months at the 
> most before it is rolled into the next RHEL release.
>
> If people could give any cases for, or against these, please respond here.  
> The EPEL Steering Committee will have a vote at our next meeting (July 28).
>

I am personally for these. The world has changed.. and the reasons for
EPEL having a wait were when people were active in testing packages.
These days, people just want stuff and having them wait 14 days no
longer matches that. [Personally I even wonder if updates-testing
makes sense from the very small usage of it.]





-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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: Do we need Mock supported on EL7?

[Stephen John Smoogen]

On Fri, 16 Jul 2021 at 17:59, Pavel Raiskup  wrote:
>
> We touched this topic several times before in our team.  Perhaps we should 
> move
> on and do it...  it would simplify a development (the yum/dnf hacks,
> legacy systemd-nspawn hacks, podman requirement for building Fedora, etc.).
>
> I created an issue [1], can you please vote there if you are concerned?  If 
> you
> have a good argument for keeping the support, please write here or there (or
> both).
>
> [1] https://github.com/rpm-software-management/mock/issues/755
>

First off, what does this mean:

1. you can't build EL7 packages anymore with mock? AKA we would need
to stop building EPEL7
2. you can't use "mock" on systems after the XYZ version?

Going from the graphs of growth, most of EL growth has been in EL7
since last year. That said.. I expect that if there is a version which
is 'known' to be the last working version of mock then people needing
it can 'keep' that version on those systems as long as they need.


> Thank you,
> Pavel
>
>
> ___
> 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



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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: intent to retire roundcubemail in epel7

[Stephen John Smoogen]

On Mon, 24 May 2021 at 14:36, Sérgio Basto  wrote:

> On Sat, 2021-05-22 at 11:57 -0700, Kevin Fenzi wrote:
> > On Tue, May 18, 2021 at 06:32:25AM -0700, Troy Dawson wrote:
> > > On Tue, May 18, 2021 at 4:20 AM Stephen John Smoogen <
> > > smo...@gmail.com>
> > > wrote:
> >
> > ...snip...
> >
> > Here's a scratch build of 1.4.11, but I bet it won't work as many of
> > the
> > php-pear packages are too old. ;(
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=68489451
> >
>
> why not use https://www.softwarecollections.org/en/scls/rhscl/rh-php72/
> ?
>
>
>

EPEL packages may rely on Red Hat SCL's for build dependencies but not
run-time dependencies. In this case this would be a run-time dependency
requirement.

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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: intent to retire roundcubemail in epel7

[Stephen John Smoogen]

On Mon, 17 May 2021 at 18:14, Kevin Fenzi  wrote:

> On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
> >
> >
> > On 17/05/2021 19:32, Kevin Fenzi wrote:
> > > roundcubemail in epel7 is very old at this point, and can never be
> > > upgraded because epel7 has too old a php.
> > >
> > > It's got 10 CVEs open against it.
> > >
> > > I'm planning on retiring it later today.
> > >
> > > I can mail epel-announce about it...
> > >
> > > kevin
> > >
> > What is the PHP issue? Roundcube 1.4 requires PHP >= 5.4.1 -
> > https://roundcube.net/about/#features. Current PHP is php-5.4.16-48.
> There
> > is also 1.3.16 and the LTS 1.2.13 = https://roundcube.net/download/.
>
> Currently epel7 has 1.2.12. We could update to 1.2.13, which fixes 2 of
> the CVE's... but that leaves 8 more. I don't really think they are going
> to be doing any more 1.2.x releases now that 1.5 is almost out.
>
> Sorry I wasn't being exact there, it's not php itself, it's various php
> related things. Like php-pear version 1.10.1 is needed and rhel7 has
> 1.9.4 and so on.
>
> If you would like to try and get 1.4.x working on epel7 that would be
> great! Of course the 1.2 -> 1.4 jump would be pretty major for
> users, but such things happen.
>
>
I am wondering if we need a different way to announce reasons for this:

[ ] I no longer use RHEL-7 so can not test
[ ] I found that there are too many package updates needed that I do not
have time for.
[ ] The following RHEL packages are too old for this package to be updated
[ ] The upstream is dead and I can not fix
...


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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: EPEL7 and ARM

[Stephen John Smoogen]

On Wed, 7 Apr 2021 at 13:45, Nick Howitt  wrote:

> What is the current status of EPEL7 packages for ARM? As far as I can
> make out, aarch64 seems to have been frozen in 2019 when RedHad stopped
> the architecture support? I also thing there has never been official
> armhfp support but the Centos7 armhfp people provide packages
> unoficially. Is that correct?
>
>
Yes we tried to extend support by having the aarch64 to use the CentOS
repositories but koji does not like differing src.rpms names to determine
what to pull into a build root. This meant that builds for all platforms
would fail because of aarch64 package names being 'different enough'. At
this point the only way for aarch64 and armhfp for EPEL would be for the
CentOS project to compile those packages.



> Regards,
>
> Nick
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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 KDE in EPEL8

[Stephen John Smoogen]

On Mon, 15 Feb 2021 at 07:49, Troy Dawson  wrote:

> I thought I'd already taken those out of comps.  So yes, I'm ok with this.
> Most of those are either qt4 based, or based on a RHEL8 missing devel,
> so cannot be built at this time.
>
> Maybe this just needs to be rebased, but there are alot of other
> changes in this, dealing with xfce.
> Can those be cleaned up so this is just a KDE change?
>
>
The xfce items are similar in that they are not buildable for similar
reasons and but listed as being there.



> On Mon, Feb 15, 2021 at 4:06 AM Stephen John Smoogen 
> wrote:
> >
> >
> >
> > On Sun, 14 Feb 2021 at 23:36, Orion Poplawski  wrote:
> >>
> >> As noted in the CentOS list:
> >> https://lists.centos.org/pipermail/centos/2021-February/353324.html
> >>
> >> # dnf group install "KDE Plasma Workspaces"
> >> Last metadata expiration check: 3:50:42 ago on Sun 14 Feb 2021 04:52:10
> >> PM MST.
> >> no group '3d-printing' from environment 'kde-desktop-environment'
> >> no group 'cloud-management' from environment 'kde-desktop-environment'
> >> no group 'firefox' from environment 'kde-desktop-environment'
> >> no group 'kde-telepathy' from environment 'kde-desktop-environment'
> >> No match for group package "dnfdragora"
> >> No match for group package "kmail"
> >> No match for group package "korganizer"
> >> No match for group package "kget"
> >> No match for group package "k3b-extras-freeworld"
> >> No match for group package "kaddressbook"
> >> No match for group package "plasma-discover"
> >> No match for group package "akregator"
> >> No match for group package "kontact"
> >> No match for group package "qt-at-spi"
> >> No match for group package "pinentry-qt"
> >> No match for group package "NetworkManager-config-connectivity-fedora"
> >>
> >> This isn't a great look.  I've submitted a pull request for the epel8
> >> comps here:
> >>
> >> https://pagure.io/fedora-comps/pull-request/608
> >>
> >> to remove the missing components.  Perhaps we want to make a push to add
> >> some of these missing items first?  I don't use any of these so I'm not
> >> particularly interested.
> >>
> >
> > I agree they should be removed. I think the above are out-dated or could
> not be built for EL8 for various reasons.
> >
> >
> >
> > --
> > Stephen J Smoogen.
> >
>
>

-- 
Stephen J Smoogen.
___
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 KDE in EPEL8

[Stephen John Smoogen]

On Sun, 14 Feb 2021 at 23:36, Orion Poplawski  wrote:

> As noted in the CentOS list:
> https://lists.centos.org/pipermail/centos/2021-February/353324.html
>
> # dnf group install "KDE Plasma Workspaces"
> Last metadata expiration check: 3:50:42 ago on Sun 14 Feb 2021 04:52:10
> PM MST.
> no group '3d-printing' from environment 'kde-desktop-environment'
> no group 'cloud-management' from environment 'kde-desktop-environment'
> no group 'firefox' from environment 'kde-desktop-environment'
> no group 'kde-telepathy' from environment 'kde-desktop-environment'
> No match for group package "dnfdragora"
> No match for group package "kmail"
> No match for group package "korganizer"
> No match for group package "kget"
> No match for group package "k3b-extras-freeworld"
> No match for group package "kaddressbook"
> No match for group package "plasma-discover"
> No match for group package "akregator"
> No match for group package "kontact"
> No match for group package "qt-at-spi"
> No match for group package "pinentry-qt"
> No match for group package "NetworkManager-config-connectivity-fedora"
>
> This isn't a great look.  I've submitted a pull request for the epel8
> comps here:
>
> https://pagure.io/fedora-comps/pull-request/608
>
> to remove the missing components.  Perhaps we want to make a push to add
> some of these missing items first?  I don't use any of these so I'm not
> particularly interested.
>
>
I agree they should be removed. I think the above are out-dated or could
not be built for EL8 for various reasons.



-- 
Stephen J Smoogen.
___
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: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:48, Miro Hrončok  wrote:

> On 10. 02. 21 20:24, Stephen John Smoogen wrote:
> >
> >
> > On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  > <mailto:mhron...@redhat.com>> wrote:
> >
> > On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> >  > fedpkg-minimal
> >  > epel-release
> >  > epel-rpm-macros
> >
> >
> > Those make perfect sense to me.
> >
> >  > fedpkg
> >  > koji
> >  > bodhi
> >
> > But I don't understand why those are required. What am I missing?
> >
> >
> > A lot of EPEL developers do their development on an EL system and use
> the base
> > tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and
> > a host of other items. In order to get fedpkg to do that you end up
> needing
> > parts of koji and bodhi because of library needs. That requires the yak
> train.
>
> Oh, so this is only needed to make EPEL "self hosting" in a sense. So
> packagers
> can contribute to EPEL 9 from an EL 9 system.
>
> I agree that this is a valuable goal, but should this be an essential part
> of
> the initial "bootstrap"?
>
>
Well it depends on what bootstrap means. Is it 'what is needed to have a
package set to call it EPEL' or 'what are the minimal set of packages
needed for an EPEL packager to be able to work'

In the past it was enough to get enough of the package set together that
others can build and add packages to the distro. Since a LOT of packages
use fedpkg local etc for their testing/porting.. having fedpkg fully
functional was a requirement.  However that does mean extra work for things
like this which no one is working on and no one is paying anyone to work
on. So maybe the group should say it is a requirement that development is
done in Fedora instead.



> I'm asking because I know that yak train has a lot of packages, including
> some
> deprecated that I maintain in Fedora. So I'd rather see a real maintainer
> deciding to package e.g. python-nose or python-mock for EPEL 9, than a SIG
> member who is more likely to import/build it once and move on.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:24, Stephen John Smoogen  wrote:

>
>
> On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:
>
>> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
>> > fedpkg-minimal
>> > epel-release
>> > epel-rpm-macros
>>
>>
>> Those make perfect sense to me.
>>
>> > fedpkg
>> > koji
>> > bodhi
>>
>> But I don't understand why those are required. What am I missing?
>>
>>
> A lot of EPEL developers do their development on an EL system and use the
> base tools to do so. That needs fedpkg to be on that system to talk to
> koji/bodhi and a host of other items. In order to get fedpkg to do that you
> end up needing parts of koji and bodhi because of library needs. That
> requires the yak train.
>
>

All fedpkg-minimal is

#!/bin/bash

baseurl=http://pkgs.fedoraproject.org/repo/pkgs
pkgname=$(pwd| sed -e 's|^/.*/||g')
cat sources | while read line; do
tarball=$(echo  $line| sed -e 's|.* ||g')
md5sum=$(echo $line| sed -e 's| .*||g')
wget $baseurl/$pkgname/$tarball/$md5sum/$tarball
done

it does not do builds, it does not have any of the 'local' tools developers
expect and so the full fedpkg is what is expected for a person to have.





> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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
>>
>
>
> --
> Stephen J Smoogen.
>
>

-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Wed, 10 Feb 2021 at 14:19, Miro Hrončok  wrote:

> On 10. 02. 21 19:53, Stephen John Smoogen wrote:
> > fedpkg-minimal
> > epel-release
> > epel-rpm-macros
>
>
> Those make perfect sense to me.
>
> > fedpkg
> > koji
> > bodhi
>
> But I don't understand why those are required. What am I missing?
>
>
A lot of EPEL developers do their development on an EL system and use the
base tools to do so. That needs fedpkg to be on that system to talk to
koji/bodhi and a host of other items. In order to get fedpkg to do that you
end up needing parts of koji and bodhi because of library needs. That
requires the yak train.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Mon, 8 Feb 2021 at 17:36, Troy Dawson  wrote:

> On Mon, Feb 8, 2021 at 11:50 AM Kevin Fenzi  wrote:
> >
> > On Mon, Feb 08, 2021 at 08:19:24AM -0500, Stephen John Smoogen wrote:
> > > There is a little nuance here. In order to get the repository going,
> we had
> > > to 'mass-branch' about 40 or so packages. fedpkg and some other items
> > > require quite a few packages which all have to be done at once. Without
> > > those you can't build anything else to put into EPEL... so I would say
> that
> > > EPEL is the specific set of packages in order to get a minimal
> repository
> > > working in the Fedora Build System. Everything else is just extras
> people
> > > add to it.
> >
> > That is an excellent point. Perhaps we should try and identify those
> > packages and see if we can just add epel-packagers sig to all of them?
> > Do we have any record of those?
> >
> If they were the packages that I built they were
> fedpkg
> koji
> bodhi
>
> And then all the packages needed to build them, that weren't in RHEL.
> But there might have been others that Smooge did.
>
>
For EL8 it was a larger pile of yaks than what tdawson had originally.  I
found all the src.rpms from that timeframe (and others have been updated
since then so would need to be included also). Looking at the initial EPEL
build dates of 2019-07, there are still about 124 packages which were in
that grouping because some things had dropped out of beta and other things
needed a long line of bootstrapping

That said I can try to replicate on a weekend.

fedpkg-minimal
fedpkg
koji
bodhi
epel-release
epel-rpm-macros


I can re

-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal: EPEL9 timeline

[Stephen John Smoogen]

On Sun, 7 Feb 2021 at 18:26, Kevin Fenzi  wrote:

> Overall this seems fine to me, a few nitpicks inline...
>
> On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote:
> > This is a proposal.  It's mainly writing down what I think most of us
> > agreed on at last weeks EPEL Steering Committee meeting.  Feel free to
> > continue to discuss and/or have ideas.
> > I've been asked by a couple places what the plans were, so I'm writing
> it here.
> >
> > Overall Plan:
> > - epel-next is an epel branch that is built against CentOS Stream.
> epel-next
> > only has the packages that would be incompatible with released RHEL
> > builds, or if an EPEL maintainer is updating a package that will only
> > be released to regular EPEL at the next RHEL release.
> > - We plan on creating epel9-next when CentOS 9 Stream has a public
> > repository.  We plan on using the EPEL Packaging SIG to populate it
> > early with common packages, although any EPEL package maintainers can
> > add their packages whenever they want.
>
> This part I am unsure of. What are 'common packages' ?
> We should make sure and ask maintainers to branch and maintain packages
> they want for this, but I think it would be odd to just do it without
> them being in the loop. We never never 'mass branched' things in the
> past. EPEL isn't a specific set of packages, it's packages maintainers
> want to maintain. That said, if there's packages of interest where the
> maintainers are not interested in epel, the epel sig should definitely
> branch and maintain those.
>
>
There is a little nuance here. In order to get the repository going, we had
to 'mass-branch' about 40 or so packages. fedpkg and some other items
require quite a few packages which all have to be done at once. Without
those you can't build anything else to put into EPEL... so I would say that
EPEL is the specific set of packages in order to get a minimal repository
working in the Fedora Build System. Everything else is just extras people
add to it.



> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


-- 
Stephen J Smoogen.
___
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 whats version of RHEL will follow

[Stephen John Smoogen]

On Mon, 1 Feb 2021 at 11:00, Filip Bartmann  wrote:

> Hello,
> what version of RedHat will EPEL now follow? Centos Stream or oficial
> RedHat and Rocky based on stable RHEL?
>
>

The main EPEL packages have always been compiled against the official Red
Hat Enterprise Linux current package set. There is an initiative to have a
set of packages built against CentOS Stream to deal with .next issues we
see when RHEL updates from say 8.3 to 8.4.



> Thanks,
> Filip Bartmann
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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 8 (and 9) build against what?

[Stephen John Smoogen]

On Tue, 15 Dec 2020 at 05:00, Miroslav Suchý  wrote:

> Regarding the recent announcement of CentOS 8 flipping to CentOS Stream -
> What will be the configs for building EPEL 8?
> I mean mock configs? And I ask as Mock maintainer - because I have no idea.
>
> Are we going to build EPEL 8 against CentOS stream? What will happen when
> CentOS stream flip to RHEL 9 based content
>
> https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F
> ?
>
>
Honestly I don't know how to deal with regular EPEL-8 development after
this. EPEL is going to add an epel-next which they would ask for additional
targets in mock for. However that does not fix building against the regular
EPEL-8 target. I expect it will depend on what programs come up for
development in the coming year and if the new -devel RHEL UBI images can be
used for mock.


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages

[Stephen John Smoogen]

On Sun, 13 Dec 2020 at 13:17, Miro Hrončok  wrote:

> On 12/13/20 7:03 PM, Orion Poplawski wrote:
> > On 12/13/20 10:37 AM, Orion Poplawski wrote:
> >> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> >>> On 12/12/20 12:12 AM, Troy Dawson wrote:
>
> > Seem reasonable?  I was able to install the resulting qpdf-devel fine.
>
> Don't forget to move the following metadata to the main package:
>
>Summary: Development files for QPDF library
>Requires: qpdf-libs%{?_isa} = %{version}-%{release}
>
>
Do you mean the main package as qpdf ? We don't control that package.


> Also, since you might want to bump the release independently in EPEL (e.g.
> if we
> discover something was wrong in the way we have packaged this), I
> recommend doing:
>
>%global rhelrelease 10
>%global baserelease 1
>Release: %{rhelrelease}.%{baserelease}%{?dist}
>...
>Requires: qpdf-libs%{?_isa} = %{version}-%{rhelrelease}%{?dist}
>
> (Assuming qpdf has regular %{dist} and not some modularity artificial
> value.)
>
> Note that I've named the EPEL part of the release "baserelease", so
> rpmdev-bumpspec does the right thing.
>
>
That makes sense.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Proposal for RHEL8 missing -devel packages

[Stephen John Smoogen]

On Sun, 13 Dec 2020 at 12:38, Orion Poplawski  wrote:

> On 12/11/20 5:04 PM, Miro Hrončok wrote:
> > On 12/12/20 12:12 AM, Troy Dawson wrote:
> >> There is also a problem if a missing package has been specifically
> >> blocked by a module.  I think libuv-devel is this way.
> >
> > If that happens, wouldn't it be blocked in both scenarios
> > (module+grobisplitter+tagging and devel-only-component)? Or would
> > grobisplitter put them in an additional repo with module_hotfixes=yes?
> >
> > If that's the case, it might be possible to create a separate repo with
> > such packages only and manually tag them there. E.g. after a build I'd
> > do `koji tag epel8-buildroot-module-hotfixes foo-devel-1.6-5.el8` and
> > the epel8-buildroot-module-hotfixes repo would be available from EPEL 8
> > Koji/mock builds with module_hotfixes=yes. Yes, unlike the rest of this
> > proposal, it requires some work (on infra to set up this extra repo and
> > on packagers to remember to do the tagging, but that still sounds like
> > less work than the grobisplitter proposal for both groups).
>
> Is there any easy way to tell if a package is explicitly blocked vs just
> not being present.
>
>
I thought there was one way by looking at the modules.yaml file and parse
through the yaml for artifacts and filter.. however when I was doing that
for the EPEL-8 bringup in 2019.. it was not always accurate.


> >> We discussed this in the EPEL Steering Committee this week, and your
> >> way has alot less "mess with the server and modules" work.
> >> It would probably get us up to 75% of the missing packages.
> >>
> >> If people who have been waiting for packages want to give this a try
> >> and show what they did for others to follow, that would be great.
> >> I'll probrubly do it for some of the packages I want.  And see what
> >> type of scripts, patches, and other things are needed.
> >
> > Let me know if you have a devel package in mind and I can give it a try.
>
> Can we just jump in and try this out?  I'd like to get qpdf-devel
> available.  If so, I guess I would do:
>
> fedpkg request-repo --exception qpdf-devel
>
> right?
>
>
I don't know so I can't answer this.



> --
> Orion Poplawski
> Manager of NWRA Technical Systems  720-772-5637
> NWRA, Boulder/CoRA Office FAX: 303-415-9702
> 3380 Mitchell Lane   or...@nwra.com
> Boulder, CO 80301 https://www.nwra.com/
>
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Broken EPEL7 builds

[Stephen John Smoogen]

On Sun, 6 Dec 2020 at 10:08, Antonio T. sagitter 
wrote:

> Hi everyone.
>
> EPEL7 builds are not executed due to this error:
>
>
I am guessing  you are talking about building packages in Fedora
Infrastructure? Do you have a koji job we can point developers to?




> DEBUG util.py:634:  Traceback (most recent call last):
>
> DEBUG util.py:634:File "/usr/bin/dnf", line 57, in 
>
> DEBUG util.py:634:  from dnf.cli import main
>
> DEBUG util.py:634:File
> "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in 
>
> DEBUG util.py:634:  import dnf.base
>
> DEBUG util.py:634:File
> "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in 
>
> DEBUG util.py:634:  import libdnf.transaction
>
> DEBUG util.py:634:File
> "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in
> 
>
> DEBUG util.py:634:  from . import conf
>
> DEBUG util.py:634:File
> "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in 
>
> DEBUG util.py:634:  _conf = swig_import_helper()
>
> DEBUG util.py:634:File
> "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in
> swig_import_helper
>
> DEBUG util.py:634:  return importlib.import_module('_conf')
>
> DEBUG util.py:634:File "/usr/lib64/python2.7/importlib/__init__.py",
> line 37, in import_module
>
> DEBUG util.py:634:  __import__(name)
>
> DEBUG util.py:634:  ImportError: No module named _conf
>
> DEBUG util.py:787:  Child return code was: 1
>
> It's happening randomly but often on x86_64
>
> --
> ---
> Antonio Trande
> Fedora Project
> mailto: sagit...@fedoraproject.org
> GPG key: 0x29FBC85D7A51CC2F
> GPG key server: https://keys.gnupg.net/
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: EL7 and 8 latest release rpms 403

[Stephen John Smoogen]

On Tue, 1 Dec 2020 at 12:58, Jon Moroney  wrote:

> Hey all,
>
> Is there a reason both the el7 and 8 repo rpms are returning 403s? Are
> they expected to return or is there a migration occurring?
>
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
>
> Thanks,
> Jon


So the softlinks in /pub/epel/ got updated on a new compose to new releases
and that caused these packages to no longer 'work'. I had put them as
hardlinks to the package previously so that you could get at least a
working version but this caused people complaining about update problems
with latest not being 'latest' until after a yum update.

https://pagure.io/fedora-infrastructure/issue/9507

-- 
Stephen J Smoogen.
___
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] ANNOUNCE: Nov 2020 EPEL6 End of Life

[Stephen John Smoogen]

Hello it is with a fond farewell, we announce the end of life of EPEL-6. No
further builds or promotion of builds will be possible in the Fedora Build
System. The repositories in /pub/epel/6 will be archived to
/pub/archive/epel/6/ and mirror lists will be pointed to this in 2 weeks.

Thank you all for the 10 years of building EL-6 packages.

-- 
Stephen J Smoogen.
___
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: RHEL 8.3

[Stephen John Smoogen]

Thanks for the notice. I am rsyncing /pub/epel/8/ to
/pub/archive/epel/8.2.2020-11-04/ for people who need longer compatibility.

On Wed, 4 Nov 2020 at 00:36, Thomas Stephen Lee  wrote:

> Hi,
>
> RHEL 8.3 got released.
>
> ---
> Lee
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[Stephen John Smoogen]

On Wed, 9 Sep 2020 at 09:58, Ken Dreyer  wrote:

>
>
> On Wed, Sep 9, 2020, 6:50 AM Petr Pisar  wrote:
>
>> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
>> > To solve this problem, I am proposing that we create a new repository
>> called
>> > EPEL 8 Next.
>> >
>> > - built against CentOS 8 Stream
>> > - opt-in for packagers (must request epel8-next dist-git branch)
>> > - opt-in for users (part of epel-release but disabled by default)
>> > - used *with* epel8, not *instead of*
>> >
>> I agree with all of that. I only don't like the name. Why EPEL 8 Next? If
>> it
>> is to be use with Stream, why don't we call it EPEL 8 Stream? I think the
>> meaning of the repository would be easier to understand.
>>
>
> I was thinking the same thing. EPEL stream is so much easier for users to
> understand.
>
>
I can see two big reasons for not using Stream in the name as the starting
point of a proposal:
1. There is always a complaint that Red Hat related projects jump onto a
single name to the point of overuse. Atomic, -Shift, -Stack, and a couple
others have been ones in just recent memory. Participants in the various
communities feel usually railroaded to use a brand even if they don't think
it wise.
2.EPEL has a hard enough time getting Fedora contributions with various
community members seeing it as a useless diversion. Putting Stream in the
title will just add to the 'why isn't EPEL just in CentOS already so I
don't have to look at those ugly named branches in MY package'.


-- 
Stephen J Smoogen.
___
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: Continuing playground discussion

[Stephen John Smoogen]

On Mon, 31 Aug 2020 at 09:43, Troy Dawson  wrote:

> On Sun, Aug 30, 2020 at 11:44 AM kevin  wrote:
> >
>
> > > Thoughts?
> >
> > Well, I think it satisfies all the use cases, but... we barely have
> > enough cycles to try and revamp playground. Do we think we have enough
> > to do that and also make a new -next version?
> >
>
> Very good question.
> Without being a superhero, do you and/or Smooge think we have the
> resources to do this?
> It's sounding like the answer is no.
>
>
Honestly, I don't see us having the resources to keep the playground
around. Kevin's doubts a long time ago about playground stretching
resources too far were correct. The build system is highly complex and just
doing plain EPEL is a strain on the Fedora volunteers. Adding the
playground was an experiment and I would lean towards ending it.



> > Also, if we do make it, perhaps we should think what critera we would
> > use to determine it's successfull? 10 packages using it? more than 1?
> > Perhaps we could gather a 'I would use this' list from maintainers
> > before we implement it?
>
> Also a very good question / idea.
> Any ideas on what would be a good way to ask that?
> Asking on epel-devel would get some.
> Asking on epel-annouce would get more, but if we did that, we'd have
> to have the answers not come back to that list.
> Possibly cross post to fedora-devel and/or centos-devel.
>
> Troy
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Puppet 6 in EPEL 8

[Stephen John Smoogen]

On Tue, 14 Jul 2020 at 19:41, Igor Raits
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2020-07-14 at 10:35 -0400, Breno Brand Fernandes wrote:
> > Hi all,
> >
> > I've just pushed puppet 6 (agent) to EPEL 8 (testing) today [1].
> >
> > If you use puppet 6 and have a moment to test it or want to have a
> > look
> > at/review the spec file [2], that would be nice. I've been testing it
> > for a
> > couple of months, and for my use, it seems all good.
> >
> > Feel free to PM me with any suggestions, questions, fixes, etc.
> > I don't plan to make bigger changes to it, though, since it seems
> > stable.
> >
> > FYI, the next step will be submitting puppetserver 6 to package
> > review.
> >
> > 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e13502b7fa
> > 2 https://src.fedoraproject.org/rpms/puppet/blob/epel8/f/puppet.spec
>
> Any plans for making an update in Fedora Rawhide too?
>

When Breno started on this, he was only running in EL so could not
support Fedora. We said that was ok and someone in Fedora could take
over maintainer-ship of it if they wanted to.


-- 
Stephen J Smoogen.
___
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: gcc-gnat

[Stephen John Smoogen]

On Tue, 14 Jul 2020 at 07:56, Björn Persson  wrote:
>
> Erick Wittman wrote:
> > I am using CentOS 8 and am using various packages in the EPEL
> > repository. I am interested in seeing gcc-gnat added to EPEL.
>
> I would also like to have gcc-gnat in CentOS 8. I maintain some Ada
> packages in Fedora and EPEL 7 that I wish I could add to EPEL 8.
>
> In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage
> of gcc. Adding it to EPEL would make it a separate package. I'm not
> sure what complications might arise from that.
>

Subpackages of gcc usually require the entire gcc tree to be rebuilt
which leads to some problems. First is the spec file able to build
various sub-packages. Some .src.rpms spec files have things removed
which are in Fedora to make it clearer what is 'supported' by Red Hat.
This clears up 'junk' which might not be wanted to ship but also can
clear flags which are needed in say gcc to make gcc-gnat but would
cause 'problems' in gcc-foobar.

Second, the way the Fedora Build System (koji+pdc+mbs+) works is
that the compose tree can only have 1 named src.rpm to be used to
'pull packages' from. This means that you can't rebuild gcc with the
same - as is in the 'buildroot'. It must be greater
and it will then replace that pacakge in future build roots. This
means that the gcc.src.rpm with gnat turned on which is used for this
would need to build all packages and then be used to build all future
EPEL packages. The 'fix' would be either to make a parallel
installable gcc with a different name which did not collide with gcc
on install. Three example ways to do this would be:
1. Make a non-default module which contained all the rebuilt binaries
needed to make gcc-gnat and other tools work (some languages also need
other utilities rebuilt to work).
2. Make an SCL which contains all these.
3. Make a set of rpms which installed gcc in all the same places
as gcc but didn't collide

A fourth way for the private rpm would be to sort of go SCL with a
package that created an approved /opt space with bin,lib etc in it say
/opt/bjornspace/{bin,lib,etc} and had paths set up to that.

> So far I haven't had time to even try. I suspect I won't be able to do
> it alone, but it might be doable if we could assemble a team of
> interested maintainers.
>
> Björn Persson
> ___
> 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



-- 
Stephen J Smoogen.
___
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] EPEL builds are currently broken

[Stephen John Smoogen]

We are in the middle of the datacentre move where various services are
partially in our old site and some are in the new ones. One problem is that
our access to RHEL comes via a server which got moved to allow for us to
build out systems in the new site.. however the builders in the old
datacentre do not have firewall rules to allow access to it.

We are working on what we can make this work but at the moment builds for
any EPEL release will probably fail.

-- 
Stephen J Smoogen.
___
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: Mate desktop environment update

[Stephen John Smoogen]

On Fri, 5 Jun 2020 at 05:21, Menanteau  wrote:

> Hi there,
>
> is there a plan to update Mate in EPEL ?
>
>
EPEL is not a distribution and does not have 'plans' to produce things for
certain releases. Nobody is paid to work on EPEL versus paid to work on
Fedora so the packages here are those that volunteers have the time and
energy to do. Thus EPEL is more of a Stone Soup collection of packages
branched from Fedora. I believe we are currently looking for new
maintainers of the MATE and Cinnamon stacks as the people who were doing
various parts have had other things come up in the last year for a good
portion of their time (I may be confusing this with some other desktops
however).


> There was a demand to update to Mate 1.8 years ago but I didn't see any
> answer.  Mate 1.24 is currently available.
>
> Thanks
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Modules again

[Stephen John Smoogen]

On Tue, 19 May 2020 at 11:05, Paul Howarth  wrote:

> On Tue, 19 May 2020 09:07:30 -0400
> Stephen John Smoogen  wrote:
>
> > On Tue, 19 May 2020 at 06:05, Paul Howarth  wrote:
> >
>
> Yes, I'm using vanilla configs straight from mock-core-configs for
> this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> which has the PowerTools repo defined and not disabled.
>
> (I generally use my own configs and don't touch the original ones, so I
> know that if I try the original ones from upstream then they should
> work as intended)
>
> Note that the error message doesn't say it can't find Judy-devel, it
> says that it (and Judy) is/are excluded. I don't know why that is.
>
>
Ohhh sorry. I missed the obvious. I am going to guess from past problems,
the system is trying to pull in mariadb which filters it out and
mariadb-devel which has it in. So when it sees the filters it says 'nope
can't do this sorry'. I wish there was a 'no I know it might break my
system do it anyway!' flag but I don't see one looking
through /usr/share/doc/mock/site-defaults.cfg . This was one of the reasons
for grobisplitter being used.



> Paul.
> ___
> 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
>


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Modules again

[Stephen John Smoogen]

On Tue, 19 May 2020 at 06:05, Paul Howarth  wrote:

> On Mon, 18 May 2020 22:29:54 -0600
> Orion Poplawski  wrote:
>
> > On 5/17/20 6:34 AM, Paul Howarth wrote:
> > > I'm trying to do a local build of gtkwave for EPEL-8.
> > >
> > > A koji scratch build somehow works:
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
> > >
> > > But a local build does not:
> > >
> > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
> > > ...
> > > Error:
> > >   Problem: conflicting requests
> > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is
> > > excluded
> > >- package Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64
> > > is excluded
> > >
> > > Adding a repo with a local build of Judy doesn't help; that gets
> > > excluded too.
> > >
> > > Any clues?
> > >
> > > Paul.
> >
> > Judy-devel appears to be part of the mariadb-devel module.  Locally I
> > can do:
> >
> > dnf module enable mariadb-devel
> > dnf install Judy-devel
> >
> > This was discovered with:
> >
> > dnf module provides Judy-devel
> >
> > on RHEL 8.2, though that does not appear to work on CentOS 8.1.
> >
> > For mock, this seems to work:
> >
> > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel
> > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm
>
> I tried that and it didn't make any difference for me (building on
> F-31). Maybe I need to wait for CentOS 8.2?
>
>
Hmm do you have the Powertools enabled in that Mock? I see Judy-devel in
the CentOS-8.1 tree in Powertools.





> > koji does some magic to essentially auto-enable some modules that I
> > don't believe mock has.
>
> It writes its own mock configs, that I know. After that, I'm in the
> dark...
>
> Thanks for trying.
>

Koji for EPEL does it by ugly magic (or fantastic if you love Rube Goldberg
devices) ... we strip off all the module data using a program called
grobisplitter and say do your best dnf versus using koji's built in
determinator like we do for EPEL-5/6/7 and most Fedora.


-- 
Stephen J Smoogen.
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Fri, 15 May 2020 at 09:06, Nico Kadel-Garcia  wrote:

> On Fri, May 15, 2020 at 8:02 AM Stephen John Smoogen 
> wrote:
> >
> >
> >
> > On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia 
> wrote:
> >>
> >> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
> >>  wrote:
> >> >
> >> > Hi,
> >> >
> >> > We're working on validating CentOS 8 for some desktop use cases at
> work,
> >> > and noticed that after working fine on a machine that's installed
> >> > several months ago, it's now failing on a freshly-installed machine.
> >>
> >> Do not get me *started* on the ansible version fun and games, or the
> >> confusing state of the python3 for various EPEL, RHEL and CentOS
> >> migrations. The situation is exacerbated when RHEL elects to use a
> >> kind-of-sort-of distinct naming scheme for software previously
> >> published via EPEL.
> >>
> >> It's an ongoing problem. EPEL's decision to show only the most recent
> >> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> >> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> >> internal access to old packages.
> >
> >
> > To be clear here.. the 'decision' is that EPEL is built using the same
> build system that Fedora uses. The Fedora build system does not keep older
> versions of packages in its composes for a space and so EPEL can not keep
> older versions of packages either. We tried several 'hacks' to do this and
> they broke the Fedora side or didn't do what we wanted on the EPEL side
> either.
>
> That is not clear at all. Build systems normally build new versions of
> software and deploy them to some target space. The decision to delete
> older packages is a very distinct one. Review of that workspace and
> expiration of old packages pretty much *must* be a distinct one.
> Deletion of obsolete packages in anticipation of their activation in
> an entirely distinct repository  is a very distinct decision.
>
>
I believe Dennis Gilmore and others have tried to explain this multiple
times in the past, but it seems that it just doesn't get through. Here is
my take on it.. which is not as nice as theirs and probably flawed because
I am tired.

The Fedora build system means everything from pkgs, pdc, bodhi, koji,
pungi, and several other tools. The way that this system is built is to
build a complete operating system with the 'compose' being just like what
is in rawhide or a release. Everything is tagged to be in the compose, a
fresh tree is generated, createrepo and other items are built on that tree,
and that tree then replaces the old one on the download servers. Just like
F32 directories and rawhide do not have older copies of packages.. neither
does EPEL.  So to the system there are no old rpms to keep around.. [and
trying to keep them seems to end up with a good many mirrors carrying new
packages but old repodata (or vice versa.. new repodata but no new rpms) so
can't be used by yum/dnf]

Of course there could be other solutions that would fix this problem.. but
each one takes time and energy that no one seems to have the time to
volunteer to get done. If you have the time to do so, I am sure people will
welcome it.



-- 
Stephen J Smoogen.
___
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: [CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

[Stephen John Smoogen]

On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia  wrote:

> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
>  wrote:
> >
> > Hi,
> >
> > We're working on validating CentOS 8 for some desktop use cases at work,
> > and noticed that after working fine on a machine that's installed
> > several months ago, it's now failing on a freshly-installed machine.
>
> Do not get me *started* on the ansible version fun and games, or the
> confusing state of the python3 for various EPEL, RHEL and CentOS
> migrations. The situation is exacerbated when RHEL elects to use a
> kind-of-sort-of distinct naming scheme for software previously
> published via EPEL.
>
> It's an ongoing problem. EPEL's decision to show only the most recent
> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
> internal access to old packages.
>

To be clear here.. the 'decision' is that EPEL is built using the same
build system that Fedora uses. The Fedora build system does not keep older
versions of packages in its composes for a space and so EPEL can not keep
older versions of packages either. We tried several 'hacks' to do this and
they broke the Fedora side or didn't do what we wanted on the EPEL side
either.

At this point it is either someone finding the time to deep dive into pungi
and other tools to make it work for this 2 different case mode or moving
EPEL to a different build system. Both are giant projects which no one has
had the time to do.


-- 
Stephen J Smoogen.
___
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] EPEL snapshots of releases

[Stephen John Smoogen]

Fedora Infrastructure have added snapshots of various EPEL releases to
/pub/archive/epel. The current format will be
/pub/archive/epel/./ and will
be a hardlink copy of the data that is in /pub/epel/. This
will be done at 'regular' intervals in the future so that people who need
to stick to an old version of epel packages can have a 'reliable' copy of
the archives at that time.

Currently we have:
lrwxrwxrwx. 1 rootroot  12 Apr 21 11:18 7 -> 7.2020-04-20
drwxr-xr-x. 7 ftpsync ftpsync 4096 May 29  2019 7.2019-05-29
drwxr-xr-x. 7 ftpsync ftpsync 4096 Apr 21 11:51 7.2020-04-20
lrwxrwxrwx. 1 rootroot  15 Apr 22 15:31 8 -> 8.1.2020-04-22/
drwxr-xr-x. 4 rootroot4096 Apr 22 15:31 8.1.2020-04-22

-- 
Stephen J Smoogen.
___
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: Python macro backports for EPEL reviews needed

[Stephen John Smoogen]

On Tue, 14 Apr 2020 at 06:08, Miro Hrončok  wrote:

> On 02. 01. 20 15:36, Miro Hrončok wrote:
> > Hey EPEL experts. Could you please have a look at:
> >
> > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13
> > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14
> >
> > Thanks.
>
> Is EPEL interested in Fedora compatibility? Or shall I stop caring and
> close them?
>
>
Miro.

EPEL is interested in Fedora compatibility but has 0 people staffed to it.
I got slammed by the datacentre move and dropped the ball on this. Troy
took over for me last month and has been trying to catch up on all the
things we have outstanding. Thank you for reminding us of this outstanding
work.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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 conflict policy

[Stephen John Smoogen]

On Wed, 8 Apr 2020 at 21:21, Orion Poplawski  wrote:

> There does not appear to be an explicit conflict policy for EPEL8:
>
>
> https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
>
> I got a report against python3-s3transfer and python3-botocore
> conflicting with the CentOS 8 HighAvailability repo.  No idea if this is
> an issue or not: https://bugzilla.redhat.com/show_bug.cgi?id=1821630
>
> It looks like we have avoided conflicts with the "ha" repos in the past,
> and I can enable the rhel-8-for-x86_64-highavailability-rpms repo on my
> RHEL8 developer license machine so it does seem available to everyone
>


When EPEL-8 was getting set up, HA was a paid add-on for EL8 and so not
available in the developer license. EPEL therefore did not conflict against
it or use it as a 'you can't build this in EPEL'. EPEL will end up
conflicting with some RHEL channels.. but since there is no 'Requires:
Conflicts:' in repo land we can't do much about it.



-- 
Stephen J Smoogen.
___
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: Extras not enabled on koji?

[Stephen John Smoogen]

On Sat, 4 Apr 2020 at 14:54, Richard Shaw  wrote:

> I'm trying to build a package that requires swig 3.0.12+. The version in
> EPEL is way too old but swig3 is provided in the extras repo.
>
> I was able to build locally via mock and COPR fine, but when I tried
> official builds it doesn't look like the "extras" repo is enabled.
>
> Is that on purpose?
>
>
Which extras directory and which release of EL are you talking about? The
one in CentOS is not the same as the one in RHEL and they have different
things. EPEL builds against RHEL so that might affect things.



> Thanks,
> Richard
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Default bookmarks under RHEL8

[Stephen John Smoogen]

On Wed, 25 Mar 2020 at 14:10, Dmitry Butskoy  wrote:

> Could anybody answer please which package provides:
> > /usr/share/bookmarks/default-bookmarks.html
> under RHEL8 ?
>
>
I don't see anything providing it in EL8


>
> ~buc
>
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: gnu-free-fonts-20120503-18.el8.0.1 still not tagged into dist-c8-compose

[Stephen John Smoogen]

On Thu, 5 Mar 2020 at 02:17, Mattias Ellert 
wrote:

> Hi.
>
> I was asked to repost a thread from the CentOS forum on this mailing
> list:
>
> Sorry for starting a new thread. But there has not been any activity on
> the old thread for a month (2020-02-05) except for my request for a
> status update a week ago (2020-02-26) for which there was no reply.
>
> Can someone please tag the update so that it can be installed by users.
> The packages available to users are still broken, even though the
> update was built almost two month ago (2020-01-07).
>
> For details please see the previous threads and bug reports:
>
> https://forums.centos.org/viewtopic.php?f=54=73346
> https://forums.centos.org/viewtopic.php?f=54=72682
> https://bugs.centos.org/view.php?id=16759
> https://bugs.centos.org/view.php?id=16523
>
> The bug was first reported 2019-10-03 and the fixed packages were built
> 2020-01-07 but are not yet available for installation/update and the
> bug still affects users.
>
> And before someone replies "should be fixed in RHEL first" before
> reading the references above - this is a CentOS only bug that never
> existed in RHEL.
>
>
This needs to be posted to centos-devel list versus EPEL devel list? That
tag isn't in the Fedora/EPEL build system so I am not sure we can do
anything on this.

-- 
Stephen J Smoogen.
___
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: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable

[Stephen John Smoogen]

On Wed, 26 Feb 2020 at 11:13, Nicolas Kovacs  wrote:

> Le 26/02/2020 à 15:48, Stephen John Smoogen a écrit :
> > I would open a bug on this so that the maintainer knows about it. They
> may not
> > be on this list or may filter it to the 'read once a year' bucket.
> Second, I
> > would check to see what the audit2allow policy came up with and if the
> files it
> > is alerting on have the appropriate labeling. I spent a day doing this
> with
> > Nagios and then realized the file problem was that nrpe wanted to do
> something
> > and hte file was labeled in a 'group' that neither nagios or nrpe had
> selinux
> > perms to do with.
>
> First a question: where's the correct place to file a bug for that? I
> subscribed to that list because I thought this would be the right place
> for
> that kind of thing.
>
>
Ugh. My problem for not saying that. A lot of 'bugs' can be config problems
so starting a discussion on the list is a good place. After that it is go
to

https://bugzilla.redhat.com

https://bugzilla.redhat.com/buglist.cgi?quicksearch=fail2ban_id=10871278


https://bugzilla.redhat.com/show_bug.cgi?id=1766415 may be related



> Anyway.
>
> I reinstalled this server from scratch and took some notes.
>
> The second time I succeeded in making Fail2ban work with SELinux. Go
> figure.
>
> I noticed two things, I don't know if they're relevant.
>
> 1. I had two different suggestions from sealert.
>
> # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver
> # semodule -i my-f2bserver.pp
>
> and then the same thing but 'f2b/sshd'.
>
> 2. To create the SELinux I used the root account on the second attempt. On
> the
> first attempt I used sudo:
>
> $ sudo ausearch -c 'f2b/f.sshd' --raw | sudo audit2allow -M my-f2bfsshd
>  IMPORTANT ***
> To make this policy package active, execute:
> semodule -i my-f2bfsshd.pp
> $ sudo semodule -i my-f2bfsshd.pp
>
> In theory there should be no difference, so correct me if I'm wrong.
>
> Cheers,
>
> Niki
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Fail2ban : SELinux is preventing /usr/bin/python2.7 from read access on the file disable

[Stephen John Smoogen]

On Wed, 26 Feb 2020 at 07:06, Nicolas Kovacs  wrote:

> Hi,
>
> I have an Internet-facing server running CentOS 7. I just installed
> Fail2ban
> using the following packages:
>
>* fail2ban-server
>* fail2ban-firewalld
>
> For the record, IPv6 is disabled on this server.
>
> Here's the SELinux error I get.
>
> 
> SELinux is preventing /usr/bin/python2.7 from read access on the file
> disable.
>
> *  Plugin catchall (100. confidence) suggests   *
>
> If you believe that python2.7 should be allowed read access on the disable
> file
> by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # ausearch -c 'f2b/server' --raw | audit2allow -M my-f2bserver
> # semodule -i my-f2bserver.pp
> 
>
> Weirdly enough, when I follow this suggestion, generate the module and
> then
> empty audit.log and restart my server, I still get the exact same error
> again.
>
> Which makes Fail2ban unusable with SELinux in enforcing mode in the
> current state
>

I would open a bug on this so that the maintainer knows about it. They may
not be on this list or may filter it to the 'read once a year' bucket.
Second, I would check to see what the audit2allow policy came up with and
if the files it is alerting on have the appropriate labeling. I spent a day
doing this with Nagios and then realized the file problem was that nrpe
wanted to do something and hte file was labeled in a 'group' that neither
nagios or nrpe had selinux perms to do with.



> Cheers from the sunny South of France,
>
> Niki Kovacs
>
> --
> Microlinux - Solutions informatiques durables
> 7, place de l'église - 30730 Montpezat
> Site : https://www.microlinux.fr
> Mail : i...@microlinux.fr
> Tél. : 04 66 63 10 32
> Mob. : 06 51 80 12 12
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Haskell on EPEL 8

[Stephen John Smoogen]

On Tue, 25 Feb 2020 at 08:53, Jos Vos  wrote:

> Hi,
>
> Is there a specific reason why the Haskell platform is not available
> anymore in EPEL 8 (it was in EPEL 7)?  Any ongoing work known to
> eventually support it again?
>
>
We do not automatically branch everything from one release to another. We
have found that trying doing so pisses off a lot of the
volunteer maintainers who are doing EPEL in their spare time and don't want
added work they didn't sign up for. Packages are put into a release when a
volunteer maintainer knows that the package is wanted, and they have time
to do so. If you need a set of packages, go to https://bugzilla.redhat.com
and check to see if there are outstanding bug tickets requesting a
maintainer to support it in EPEL-8. If there are add your info to that
ticket, if there are not please open a ticket.



> Thanks,
>
> --
> --Jos Vos 
> --X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
> --Amsterdam, The Netherlands|   Mobile: +31 6 26216181
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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: Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

On Mon, 24 Feb 2020 at 18:31, Eduardo Kienetz  wrote:
>
> It would be my first time maintaining an EPEL package, but if nobody else 
> already experienced is willing, I could probably do it with minimal 
> supervision/hints to get started :)
> What has been the typical work? If they have git repos I can probably get a 
> good understanding from the commits.
>

Hi Eduardo.

I was going to add you to the group, but you are not a packager so I
could not. You can look at the package and its outstanding bugs in
bugzilla and look through the spec file to see if it is something you
can take on later when you become a packager.


-- 
Stephen J Smoogen.
___
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] Looking for new maintainer: nagios, nagios-plugins, nrpe

[Stephen John Smoogen]

I have been maintaining nagios, nagios-plugins, and nrpe for a couple
of years but currently I do not have much time to put towards the
packages and won't until 2021 at my current rate.

Last week, I emailed various people who have co-maintainer rights on
the package, but haven't had anyone reply. So I am asking on these
lists to see if another packager has time to maintain them and if not
I plan to orphan the packages in 2 weeks.

-- 
Stephen J Smoogen.
___
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] Announcement: EPEL Steering Committee Changes

[Stephen John Smoogen]

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.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[Stephen John Smoogen]

On Tue, 18 Feb 2020 at 10:34, Petr Pisar  wrote:

> On Sat, Feb 15, 2020 at 05:12:29PM -0500, Matthew Miller wrote:
> > On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> > > From my also little understanding of modularity, this is so you can
> > > reinstall base perl packages. In some ways ( I am glossing over things
> > > here), modular rpms always beat bare rpms because a module can put in
> rules
> > > to say 'you can install this package but it does not work with these
> rpms
> > > so they need to be removed'. So I think any modules we write which
> would
> > > over-ride non-modular packages, we would also need to write a 'get me
> back
> > > my f'ing defaults' module which stubs in a similar way the perl and
> some
> > > other modules do.
> >
> > No, this is not the case. If the module isn't enabled its packages will
> just
> > be ignored. It's only if you enable the module that you get the RPMs from
> > that module.
> >
> Exactly. If you want to revert back to a non-modular package, just reset
> the module
> (e.g. "dnf module --reset perl"). That will disappear modular packages from
> from the repository and make the non-modular packages available again.
>
> Here is a simple explanation what enabling a module stream means: If you
> enable a module stream ("dnf module --enable perl:5.24"), DNF obtains a
> list
> of binary packages belonging to that stream (e.g. perl-interpreter-5.24.4),
> makes them available (to dnf install, repoquery etc.) and at the same time
> makes the same-named packages (either non-modular or from a different
> stream
> of the same module) unavailable (e.g. perl-interpreter-5.26.3 disappears).
> When you reset the module, you effectively reverts it. This process of
> making
> the packages avaiable/unavailable DNF calles a modular filtering.
>
> The purpose of the stub (without packages) perl:5.26 stream is different
> and
> mostly unrelated . It is there to enable having modules above the perl
> module
> in an easy way. Otherwise the layered module maintainers would have take
> care
> whether they target Perl 5.26 that is non modular or Perl 5.24 that is
> modular. The dummy perl:5.26 stream provides a unified modular interface to
> other modules.
>
>
OK I was clearly confused and not correctly remembering why you had said
perl:5.26 was there. I apologize for the misinformation here.



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


-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

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

[Stephen John Smoogen]

On Fri, 14 Feb 2020 at 18:14, Chris Adams  wrote:

> Once upon a time, Kevin Fenzi  said:
> > Does this mean if there's a package foo that is a rhel package, but not
> > in a module, that it can be overlapped with a foo package thats in a
> > epel non default module? ie, does it only mean the modular case or does
> > it mean any rpm?
>
> As a consumer of EPEL, I'd rather nothing in the base RHEL (or really
> CentOS in my case) ever get replaced, up or downgrade, by something in
> EPEL.
>
> Unless... does RHEL have modules that replace base packages?  I admit, I
> haven't fully got my head wrapped around all the effects of modularity.
>
>
So the way that RHEL did this in el8.0 seems to have been to make a pseudo
module

perl   5.24  common [d], minimal   Practical Extraction and Report
Language
perl   5.26 [d] common [d], minimal   Practical Extraction and Report
Language

The perl-5.24 is a real module built in the modularity system. If you do a
yum module info perl, it gives you every package in it. The perl-5.26
module is a 'stub' where it mentions mainly masks in the base packages
like perl-interpreter-5.26.3-416.el8.x86_64 . So you can replace all the
core perl packages with a module..

>From my also little understanding of modularity, this is so you can
reinstall base perl packages. In some ways ( I am glossing over things
here), modular rpms always beat bare rpms because a module can put in rules
to say 'you can install this package but it does not work with these rpms
so they need to be removed'. So I think any modules we write which would
over-ride non-modular packages, we would also need to write a 'get me back
my f'ing defaults' module which stubs in a similar way the perl and some
other modules do.


-- 
Stephen J Smoogen.
___
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: Retiring mingw-* packages from EPEL 7

[Stephen John Smoogen]

On Thu, 13 Feb 2020 at 06:29, Richard W.M. Jones  wrote:

>
> This has been done now.  In total 107 EPEL 7 mingw-* packages
> were retired, and 307 bugs closed.
>

Thanks Richard.

-- 
Stephen J Smoogen.
___
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: Added arches but no automatic rebuild?

[Stephen John Smoogen]

On Wed, 12 Feb 2020 at 09:46, Richard Shaw  wrote:

> I'm sure it was announced but I've been very busy lately but while trying
> to build a package for EPEL 8 I noticed that two builds (arches) failed for
> missing dependencies but two did not.
>
> I see that there are a number of arches not originally part of RHEL 8,
> which is fine, but when the arches were added shouldn't all of the affected
> packages been rebuilt to add the new arches?
>
>
I don't know what you are seeing to say this. The arches which were
initially there were x86_64, ppc64le, s390x and aarch64. I don't know of
any arches added after that and those have been in el8 since day 1.


> Thanks,
> Richard
> ___
> 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
>


-- 
Stephen J Smoogen.
___
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] Removing baseurl= from default repo files

[Stephen John Smoogen]

For the longest time, the Fedora Project has included a baseurl= line in
its configs as an alternative to the basic metalink= line. EPEL has
followed along, and I expect a lot of users have some sort of sed/awk/ed
script which looks for a #baseurl and does something with it.

The upstream configs in Fedora's repo files are changing to only have the
metalink= line in them, and a couple of Pull Requests to make the changes
to the EPEL config files have been placed.

https://src.fedoraproject.org/rpms/epel-release/pull-request/6
https://src.fedoraproject.org/rpms/epel-release/pull-request/7

I am announcing the change here so that people can be aware before this
starts to show up in EPEL in the next month or so.

-- 
Stephen J Smoogen.
___
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] Need to get Steering Committee consensus: packages in old modules

[Stephen John Smoogen]

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?

-- 
Stephen J Smoogen.
___
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] RFC: Remove opensmtpd from EPEL releases

[Stephen John Smoogen]

Currently opensmtpd has a high level remote CVE and several others from the
release listed. I have tried to compile the updated version but

1. It is a major upgrade with a different config syntax than what is in
EPEL.
2. It requires libressl to compile which we do not ship.
3. It might be possible to fix that one known CVE but there seem to have
been others but I do not have any knowledge what is needed to fix all of
them.

I would like to remove opensmtpd from EPEL. If someone wants to fix/patch
it that would be great also but it might become a long war of attrition.

-- 
Stephen J Smoogen.
___
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: Removal of mingw-* packages from EPEL 7

[Stephen John Smoogen]

On Thu, 30 Jan 2020 at 09:36, Troy Dawson  wrote:
>
> On Thu, Jan 30, 2020 at 6:21 AM Richard W.M. Jones  wrote:
> >
> > MinGW is a Windows cross compiler for Fedora.  There is a base
> > toolchain like mingw-filesystem and mingw-gcc, and many cross-compiled
> > libraries like mingw-glib2 which you can link with your programs to
> > make Windows binaries, all without needing to interact with Windows
> > itself.
> >
> > The mingw-* packages are primarily developed in Fedora.  We added them
> > to EPEL 7 a long time ago, but they have been effectively unmaintained
> > for a really long time.  I don't know how to find out exactly when
> > they were branched, but a random sample of packages I looked at
> > haven't been updated in epel7/ since 2014(!), only shortly after RHEL
> > 7 was released.  They therefore remain at very old versions with the
> > attendant problems that brings.
> >
> > Therefore we would like to remove them from EPEL 7.
> >
> > If this is going to cause a problem, then honestly the only way you'll
> > be able to save them is to step up to do the maintenance on them right
> > now.
> >
> > I'm not very clear on the exact removal method, whether that is going
> > to be retirement, orphaning or even blocking them at the RCM level
> > from EPEL, but expect they'll go away unless someone very soon starts
> > to maintain them actively.
> >
> > Note that some of these packages are in RHEL 8 CRB where they are used
> > to build various Windows programs that Red Hat ships, but none of them
> > are branched for EPEL 8 that I'm aware of.
> >
> > More information in this thread:
> >
> > https://pagure.io/fesco/issue/2333
> >
> > Rich.
>
> Adding to that, a couple of the packages are un-installable from EPEL7.
> It's only two, but on that bugzilla it was suggested that the packages
> be removed.
> https://bugzilla.redhat.com/show_bug.cgi?id=1760979
>
> Judging from the number of CVE's listed in the fesco issue, I suggest
> archival and removal.
> Troy

Agreed



-- 
Stephen J Smoogen.
___
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: [Fedocal] Reminder meeting : EPEL Steering Co

[Stephen John Smoogen]

On Tue, 21 Jan 2020 at 13:00,  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>EPEL Steering Co on 2020-01-22 from 18:00:00 to 19:00:00 GMT
>At freenode@fedora-meeting
>
>

Sorry I thought I cancelled this meeting. In any case, many people are
on travel to BRNO for DevConf.cz so I am cancelling this meeting.



-- 
Stephen J Smoogen.
___
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: Following update policy for dnscrypt-proxy

[Stephen John Smoogen]

On Mon, 20 Jan 2020 at 10:20, Robert-André Mauchin  wrote:
>
> Hello
>
> Some user requested an update from  dnscrypt-proxy 1 to  dnscrypt-proxy 2,
> which is totally incompatible and not even programmed in the same language.
> As far as I understand, such update is frowned upon as it would break existinq
> installations. Shall I then create a dnscrypt-proxy2 package specifically for
> EPEL7?
>

I would do that if they are incompatible in configuration.


> Best regards,
>
> Robert-André
>
> ___
> 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



-- 
Stephen J Smoogen.
___
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: Software Collection packages for EPEL

[Stephen John Smoogen]

On Sat, 11 Jan 2020 at 12:13, Dmitry Butskoy  wrote:
>
> Kevin Fenzi wrote:
> >>> OK we are now syncing to rhel-7-server-devtools-rpms and those have
> >>> the needed rust-toolset, llvm-toolset and other tools which someone
> >>> needing to rebuild chromium or seamonkey. Please test and let me know
> >>> what you run into.
> >>>
> >> Seems nothing changed yet,
> >>> DEBUG util.py:596:  No matching package to install: 
> >>> 'rust-toolset-1.35-rust'
> >>> DEBUG util.py:596:  No matching package to install: 
> >>> 'rust-toolset-1.35-cargo'
> >>> DEBUG util.py:596:  No matching package to install: 'llvm-toolset-7.0'
> >>> DEBUG util.py:596:  No matching package to install: 
> >>> 'llvm-toolset-7.0-llvm-devel'
> >> See https://koji.fedoraproject.org/koji/taskinfo?taskID=40377953
> > I did a repo regen, can you try again when:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=40393080
> >
> > is done?
>
> Now it cannot find devtoolset-8 :
> > DEBUG util.py:596:  No matching package to install: 'devtoolset-8-gcc'
> > DEBUG util.py:596:  No matching package to install: 'devtoolset-8-gcc-c++'
> > DEBUG util.py:596:  No matching package to install: 
> > 'devtoolset-8-libatomic-devel'
> See https://koji.fedoraproject.org/koji/taskinfo?taskID=40411197
>

OK this is just messed up. The newer version only has the older
devtoolset, and the what I thought was the older version only has the
newer devtoolset but not the other libraries you need. I am guessing I
will need to add both the buildroot as separate secondary channels but
I have no idea if things will work. This is what I get for putting in
work on a Friday to production.

My apologies for the broken set.

-- 
Stephen J Smoogen.
___
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: Software Collection packages for EPEL

[Stephen John Smoogen]

On Wed, 8 Jan 2020 at 16:13, Stephen John Smoogen  wrote:
>
> On Wed, 8 Jan 2020 at 16:07, Stephen John Smoogen  wrote:
> >
> > On Wed, 8 Jan 2020 at 15:53, Dmitry Butskoy  wrote:
> > >
> > > Considering how Firefox is built, I see it uses:
> > > devtoolset-8
> > > rust-toolset-1.35
> > > llvm-toolset-7.0
> > >
> > > I try to build new SeaMonkey-2.53 (formerly Mozilla, Netscape), it has
> > > code based on Firefox and requires the same toolsets under EPEL7.
> > >
> > > Unfortunately, it seems EPEL7 build has no "rust-toolset-1.35" and
> > > "llvm-toolset-7.0".
> > >
> > > Even worse is that "rust-toolset-1.35" is not provided by whell-known
> > > CentOS repo, and seems to be available to RHEL subscribers only...
> > >
> > > Are there any chances in the near future that:
> > > 1) More (or all) toolsets will be allowed for EPEL builds;
> > > 2) EPEL builds will use "official" packages from the correspond RHEL
> > > channel?
> > >
> >
> > So we have access to the /rhel-7-rhscl-for-x86_64-server-rpms channel
> > which does have devtoolset-8 in it. It does not seem to have the
> > rust-toolset or llvm-toolset and I don't see any channel we have
> > access to which does. As such we are stuck at the moment :(.
> >
>
> OK I have found the channel which has these:
> rhel-7-server-devtools-rpms which is different from the one we were
> using before. I will see if we can get this sync'd in the next 48
> hours.
>

OK we are now syncing to rhel-7-server-devtools-rpms and those have
the needed rust-toolset, llvm-toolset and other tools which someone
needing to rebuild chromium or seamonkey. Please test and let me know
what you run into.


-- 
Stephen J Smoogen.
___
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: Pound in EPEL 8

[Stephen John Smoogen]

On Thu, 9 Jan 2020 at 04:06, Felix Schwarz  wrote:
>
>
> Am 09.01.20 um 00:03 schrieb Breno Brand Fernandes:
> > It seems that the package was retired on 2019-02-11[1].
>
> I think you need to follow the general un-retirement procedure:
> https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
>

If someone could help Breno work on this I would greatly greatly
appreciate it. Breno has been working with me on getting various
things back into EPEL, but my time for EPEL is back to nil and null.
This means i have been letting them down and I would really appreciate
if someone could help them through what exactly claiming ownership and
other actions are.

Thank you.


> Felix
>
> PS: Thanks for working on pound. I used it in the past and found it pretty 
> useful.
> ___
> 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



-- 
Stephen J Smoogen.
___
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: Software Collection packages for EPEL

[Stephen John Smoogen]

On Wed, 8 Jan 2020 at 16:07, Stephen John Smoogen  wrote:
>
> On Wed, 8 Jan 2020 at 15:53, Dmitry Butskoy  wrote:
> >
> > Considering how Firefox is built, I see it uses:
> > devtoolset-8
> > rust-toolset-1.35
> > llvm-toolset-7.0
> >
> > I try to build new SeaMonkey-2.53 (formerly Mozilla, Netscape), it has
> > code based on Firefox and requires the same toolsets under EPEL7.
> >
> > Unfortunately, it seems EPEL7 build has no "rust-toolset-1.35" and
> > "llvm-toolset-7.0".
> >
> > Even worse is that "rust-toolset-1.35" is not provided by whell-known
> > CentOS repo, and seems to be available to RHEL subscribers only...
> >
> > Are there any chances in the near future that:
> > 1) More (or all) toolsets will be allowed for EPEL builds;
> > 2) EPEL builds will use "official" packages from the correspond RHEL
> > channel?
> >
>
> So we have access to the /rhel-7-rhscl-for-x86_64-server-rpms channel
> which does have devtoolset-8 in it. It does not seem to have the
> rust-toolset or llvm-toolset and I don't see any channel we have
> access to which does. As such we are stuck at the moment :(.
>

OK I have found the channel which has these:
rhel-7-server-devtools-rpms which is different from the one we were
using before. I will see if we can get this sync'd in the next 48
hours.


> Stephen J Smoogen.



-- 
Stephen J Smoogen.
___
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: Software Collection packages for EPEL

[Stephen John Smoogen]

On Wed, 8 Jan 2020 at 15:53, Dmitry Butskoy  wrote:
>
> Considering how Firefox is built, I see it uses:
> devtoolset-8
> rust-toolset-1.35
> llvm-toolset-7.0
>
> I try to build new SeaMonkey-2.53 (formerly Mozilla, Netscape), it has
> code based on Firefox and requires the same toolsets under EPEL7.
>
> Unfortunately, it seems EPEL7 build has no "rust-toolset-1.35" and
> "llvm-toolset-7.0".
>
> Even worse is that "rust-toolset-1.35" is not provided by whell-known
> CentOS repo, and seems to be available to RHEL subscribers only...
>
> Are there any chances in the near future that:
> 1) More (or all) toolsets will be allowed for EPEL builds;
> 2) EPEL builds will use "official" packages from the correspond RHEL
> channel?
>

So we have access to the /rhel-7-rhscl-for-x86_64-server-rpms channel
which does have devtoolset-8 in it. It does not seem to have the
rust-toolset or llvm-toolset and I don't see any channel we have
access to which does. As such we are stuck at the moment :(.


>
> Regards,
> Dmitry Butskoy
> https://fedoraproject.org/wiki/User:Buc
>
> P.S. I know EPEL7 provides rust-1.40, but the code I try to compile is
> ready for rust <= 1.37 only :/
> P.P.S. I know about "bundling and pre-compile", but certainly hope to
> avoid it.
> ___
> 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



-- 
Stephen J Smoogen.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: How to deal with dependencies from Power Tools repo

[Stephen John Smoogen]

On Wed, 8 Jan 2020 at 11:14, Richard Shaw  wrote:
>
> I have build BackupPC for EPEL 8 and got a few of the dependencies in EPEL as 
> well that aren't provided by the base repo.
>
> One of the dependencies is provided by the Power Tools repo, but when trying 
> to install of course it just gives the default error that a dependency cannot 
> be met.
>
> How can I make this more intuitive for the end user?
>
> Is there a proper way to add a requires on the Power Tools repo?
>

Not really... for a user of RHEL they would be wanting Code Ready
Builder and for Oracle or Euler they probably need some other repo
name.


> Thanks,
> Richard
> ___
> 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



-- 
Stephen J Smoogen.
___
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: Self Introduction: Michal Bocek

[Stephen John Smoogen]

Welcome. I think everyone is on the usual Red Hat 2 week break at the
end of the year.. but I will try to look at this when I get back.

On Fri, 20 Dec 2019 at 14:44, mbocek  wrote:
>
> Hi, I've been working at Red Hat mainly on tools dealing with upgrades
> of major versions of RHEL. I've also developed a tool called
> convert2rhel which automates the conversion of CentOS and Oracle Linux
> to RHEL.
>
> I've recently open sourced the conver2rhel code and my goal now is to
> get it to EPEL (only, not Fedora). I would greatly appreciate a review
> of the package:
> https://bugzilla.redhat.com/show_bug.cgi?id=1785735
>
> Thank you,
> --
> Michal Bocek
> OS and Application Modernization
> Senior Software Engineer
> Red Hat Czech s.r.o.
> ___
> 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



-- 
Stephen J Smoogen.
___
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