[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

Re: Koji notifications arriving days late

[Stephen John Smoogen]

On Fri, 31 Dec 2021 at 10:58, Matthew Miller 
wrote:

> On Fri, Dec 31, 2021 at 12:19:17PM +0100, Fabio Valentini wrote:
> > It seems that there is some kind of bottleneck somewhere, because the
> > delay often gets progressively worse if there are lots of
> > notifications in a short period of time, and then things are only able
> > to catch up to recent notifications multiple days later (or get lost,
> > when something seemingly crashes and needs to be restarted).
>
> I think I remember something about the Libera IRC connection being
> rate-limited?
>
>
There are several different delays occurring.
1. Currently we are generating a lot of  different notifications for EPEL-9
setup and branching. This affects general notifications with delays
2. there is a major delay happening between IRC and Matrix wherever that
pass through happens. Messages are generated in IRC and will take a while
to shift over to the matrix side. [Vice versa does not seem to have a
similar delay which leads to some weird conversations]
3. There are a lot of 'dead-accounts' and 'full-accounts' on Fedora lists
and tools. Ones that go to gmail will cause google to throttle any email
going to all gmail.com accounts for hours if delivered from a mailing list
like the various notifications ones or devel etc. It used to be mailman and
various tools would unsubscribe people but that odes not seem to be
happening for whatever reasons. I have been just having to do manual
unsubscribes from lists when I have time to.

There used to be some problems with notification tools in the past where
they would crash, then ask for a lot of old messages to make sure they were
done, then send a couple and crash again and... but I don't know if that
has been fixed in the last 9 months since I left Fedora IT.



> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Thu, 30 Dec 2021 at 13:58, Chris Murphy  wrote:

> On Thu, Dec 30, 2021 at 1:31 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Dec 30, 2021 at 02:27:04AM -0500, Matthew Miller wrote:
> > > On Wed, Dec 29, 2021 at 03:17:42PM +, Tom Hughes via devel wrote:
> > > > At this point somebody will no doubt argue that /usr changes on a
> > > > package update and that the RPM database is a static definition of
> > > > the currently installed OS files, but evidence says otherwise:
> > > >
> > > > % ls -l /var/lib/rpm
> > > >
> > > > total 378M
> > > >
> > > > -rw-r--r--. 1 root root 378M Dec 28 16:08 rpmdb.sqlite
> > > > -rw-r--r--. 1 root root  32K Dec 29 09:27 rpmdb.sqlite-shm
> > > > -rw-r--r--. 1 root root0 Dec 28 16:08 rpmdb.sqlite-wal
> > > >
> > > >
> > > > While "Dec 28 16:08" is indeed the last time I updated that machine
> > > > it seems one of the files has changed more recently - no idea what
> > > > triggered that but clearly the files are not static between updates.
> > >
> > > That is a sqlite write-ahead log shared memory file used to coordinate
> > > access between concurrent clients. Someone who knows more about the
> depths
> > > of DNF and RPM than me will need to comment, but it looks like `dnf
> list`
> > > touches it -- even though `rpm -qa` doesn't.
> >
> > $ sudo strace -efile dnf list
> > ...
> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-wal",
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
> > openat(AT_FDCWD, "/var/lib/rpm/rpmdb.sqlite-shm",
> O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 5
> > ...
> >
> > What happens if /var/lib is read-only? Changing (fixing?) this would
> > be a pre-requisite to this proposal, we don't want 'dnf list' to break.
>
> Why should it be a prerequisite? In all Fedora editions and spins with
> dnf, /usr and /var are read-write. In the case of rpm-ostree based
> editions and spins, they don't include dnf. I agree dnf should
> tolerate read-only rpmdb files, but I'm not following the logic
> leading to it being a prerequisite (must tolerate rather than should
> tolerate).
>

I think that at least it needs to be ok'd that they can and will work on it
to fix. The dnf team may have other things on their queue that they need to
focus on this release so having to redesign their plumbing to deal with
moved files may not be possible. that leaves F36 shipped with a broken dnf
and no way anyone can update or run anything.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 21:20, Matthew Miller 
wrote:

> On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote:
> > F36 but needs to be worked through the proper channels of 'upstream'. Get
> > the FHS updated and fixed, work out that the change actually is going to
> be
>
>
> Pretty sure that's a non-starter. FHS 3.0 was released in 2015, and the
> whole thing has been effectively dead since.
>
>
I agree that the FHS and LSB are practically dead, but it is heavily used
in our work. FHS compliance is one of the first things package reviews get
dinged on and it doesn't help if we start down the 'Do as I say, not as I
do' route. I would say we either need to drop FHS compliance or use an
amended copy and work with the SuSE people on making that a shared
standard.



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 16:16, Michel Alexandre Salim <
sali...@fedoraproject.org> wrote:

> On Wed, Dec 29, 2021 at 10:51:44AM -0500, Stephen John Smoogen wrote:
> > Also please realise that the community can eat only so many changes per
> > release no matter how much you want to otherwise. You can probably get
> this
> > OR the fs-verity in some future release, but not both in the same release
> > and trying to fight for both is going to mean you get neither. In fact,
> at
> > a certain point too many changes start making it that any CR with certain
> > names attached will get derailed because people are sure there is some
> sort
> > of agenda or conspiracy which they have to fight to stop.
>
> I'm not sure I understand this point. Chris is proposing this change,
> and Neal and I listed because I volunteered to help him implement some of
> the
> changes.
>
> And Chris is not on the fs-verity change, and neither is Neal.
>
>
My apologies.. I lost track of who was on each of these, and I did not
double check before posting. That is my fault 100%.  I should have just
said I have Change Fatigue with all the proposed changes and have left it
at that.


> I do hope everyone give each other the benefit of the doubt and not jump
> to assuming there is a secret agenda or conspiracy afoot -- I see this
> raised against the DIGLIM proposal too, at least once -- but if it helps
> make it clear that there is no agenda being pushed, I'll take my name
> off this change so there is no confusion.
>
>
My main issue is that people are seeing agenda's, and it isn't just the
usual suspects of people who say NO to many changes. After rereading the
changes to make sure I know who is on them, the main problem I am seeing is
that there is nothing to sell why the standard Fedora contributor will want
any of them in their OS. There is not even a 'Hey we did this already for
this rebuild and you can play with it to see if it makes sense for you'.
There does not seem to be any community involvement beforehand and nothing
for people but to 'react against' the change. Add in the number of them and
those reactions become looking for 'hidden' agendas etc.

All that said, this isn't the first time this has happened. It is the
reason why various large changes usually require groups to sort of make a
sample sausage for people to eat before they have to sit through watching
the larger sausage made. Because we are all going to have to do that while
any of these changes are working through the grinder.





> Best regards,
>
> --
> Michel Alexandre Salim
> profile: https://keyoxide.org/mic...@michel-slm.name
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 13:51, Gordon Messmer 
wrote:

> On 12/29/21 09:59, Stephen John Smoogen wrote:
> > The modern day case where /usr is read-only is inside a container and
> > you put an overlay or using some sort of linking to /var which is
> > read-write in case of reboots.
>
>
> Right, that makes sense.
>
>
> > To me this is like saying 'move everything into /usr but because its
> > volitile move it back into /var but in a sub-directory from where it
> > was so you can keep an image running.' In this case, this doesn't
> > sound like any savings and more of a headache of why did it corrupt
> > this time.
>
>
> But this doesn't.  Why would you need to move the rpmdb?  Users probably
> aren't installing rpm packages in containers at run time (particularly
> if /usr is read-only); installation typically happens when building the
> container image, at which point /usr isn't read-only.
>
> Most of the containers I am dealing with are
Grab the base image,
Create a layer, and add the images you want,
Test and deploy the layered image.
Update that image over time.

Theoretically people should build the thing from scratch every time but
instead you get someone downloading the base image which they have gotten
an OK to use, then adding the stuff they need, and then running with that
for YEARS because the person who built the first one left long ago and no
one wants to break the paycheck program again.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 12:49, Gordon Messmer 
wrote:

> On 12/29/21 07:26, Vitaly Zaitsev via devel wrote:
> > On 29/12/2021 16:01, Ben Cotton wrote:
> >> Currently, the RPM databases is located in `/var`. Let's move it to
> >> `/usr`. The move is already under way in rpm-ostree-based
> >> installations, and in (open)SUSE.
> >
> > It will break FHS compatibility. /usr must contain read-only data.
>
>
> If /usr really is read-only, then it probably doesn't matter where the
> rpmdb is, since packages can't be installed (generally).
>
>
The modern day case where /usr is read-only is inside a container and you
put an overlay or using some sort of linking to /var which is read-write in
case of reboots. To me this is like saying 'move everything into /usr but
because its volitile move it back into /var but in a sub-directory from
where it was so you can keep an image running.' In this case, this doesn't
sound like any savings and more of a headache of why did it corrupt this
time.

Looking at my /var/lib in F35, the __db.*** files seems to get written to
regularly but I am not sure why. That would probably be something to track
down and remove from images afterwards.


> Moreover, for systems where /usr is read-only and/or shared (especially
> stateless systems), having the rpmdb on /usr seems like the most
> rational place for it, if one expects to be able to use rpm to query the
> package list.  Otherwise, there is an implicit coupling of /usr and
> /var/lib/rpmdb that requires two mounts rather than one.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 29 Dec 2021 at 10:19, Tom Hughes via devel <
devel@lists.fedoraproject.org> wrote:

> I don't see how this is FHS compliant, which in turn would make
> it non-compliant with Fedora Packaging Guidelines, namely:
>
>

I am in agreement here and think that this is NOT a change to be made in
F36 but needs to be worked through the proper channels of 'upstream'. Get
the FHS updated and fixed, work out that the change actually is going to be
stuck to in SuSE and not rolled back and then push it to Fedora.

Also please realise that the community can eat only so many changes per
release no matter how much you want to otherwise. You can probably get this
OR the fs-verity in some future release, but not both in the same release
and trying to fight for both is going to mean you get neither. In fact, at
a certain point too many changes start making it that any CR with certain
names attached will get derailed because people are sure there is some sort
of agenda or conspiracy which they have to fight to stop.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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

Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?

[Stephen John Smoogen]

On Sun, 26 Dec 2021 at 23:32, Reon Beon via devel <
devel@lists.fedoraproject.org> wrote:

> Update?
> https://pagure.io/fedora-infrastructure/issue/8455



I am going to be overly blunt here. Messages like this do NOT help.
1. Most of the people who are paid to work on this are on break for 1/2 of
December and some are taking off parts of January too. They are also NOT
paid to only work on this, but mainly to help volunteers cover parts that
volunteers run out of time to do. If there are no volunteers then those
people paid are filling out many other jobs. In the many places Fedora has
volunteers, the months of November, December, January, February are usually
a lot of family time activities with various New Year and Soltice and other
regional holidays.
2. Messages without extra contact sound like a Boss demanding status
updates because they don't feel like they are getting enough work out of
people. It instead demotivates the people working on it (whther they are a
volunteer or a paid person) and makes them less inclined to a) give an
update or b) actually finish the project.
3. This is a major project.
a) There are multiple python packages which need to be make into rpms which
no one has done. These are packages which need dedicated volunteers on them
to keep them up to date and working. This is about a month or 2 of work
because packagers aren't a free resource.
b) Once those packages are built, then a staging instance needs to be
deployed and the current databases imported into this. This is going to be
a tricky problem and there will be multiple imports and blow away and
redeploy because very few Databases travel well without some manual
intervention. Once those those tricks are figured out..
c) you take down the live deployment and roll out the new deployment. You
work out all the bugs and go live.

This is probably a 4 month project at best with a lot of time taken up with
'thinking about how to do this and stop pinging me so I can think'. If you
want updates, ask for them to be put in the CPE weekly letter. The Project
Managers who are working out what are priorities can then let you know
where things are and if this is getting attention or if the 9000 other
pieces of infrastructure that break regularly took over.


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

Re: Unable to login as root with a recent Rawhide Fedora Cloud image

[Stephen John Smoogen]

On Mon, 20 Dec 2021 at 10:31, Ondrej Mosnacek  wrote:
>
> Hi,
>
> When I set up a rawhide cloud image
> (Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
> download.fedoraproject.org) with a root password using virt-sysprep:
>
> virt-sysprep -a  --root-password password:123456
> --selinux-relabel [...]
>

I believe this is intentional. Please see emails with subjects:

F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
F36 Change: Users are administrators by default in the installer GUI.
(Self-Contained Change proposal)

there may be some others. Basically root login is no longer allowed
via PAM and possibly other tools. My understanding is that you need to
login as a user, and then become root.


> ...I am unable to login as root on the console once I boot it. When I
> enter "root" in the login prompt, I immediately get "Login incorrect"
> (it doesn't even ask for password). With the F35 Cloud image I can
> login just fine with the same procedure.
>
> Anyone know if this is an intentional change or a bug? If it's
> intentional, what do I need to do to make root login work again? If
> it's a bug, any idea which component to report it against?
>
> Thanks,
> --
> Ondrej Mosnacek
> Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: About how Go is updated in Fedora

[Stephen John Smoogen]

On Mon, 20 Dec 2021 at 10:16, Colin Walters  wrote:
>
>
>
> On Sat, Dec 18, 2021, at 5:06 PM, Fabio Valentini wrote:
> >
> > Sure, I saw that ticket. But I fail to see how this is this a "new problem".
> > If you use, for example, some shiny, new features that are only going
> > to be in GCC 12 or LLVM 14,
>
> There's a *big* difference between Go and C/C++/Rust though, which is that 
> the version of the Go compiler you use at build time becomes the version of 
> the Go *runtime* statically linked into your binary, with implications for 
> things like GC performance.
>
> Go's 6-month cadence is also much faster than C/C++ (though also much slower 
> than Rust's, but the Rust 6 week releases are also smaller, and anyways 
> generally the ecosystem is OK with "older" Rust compilers).  Also relating to 
> the release cycle, Go releases tend to add new features that parts of the 
> ecosystem adapt relatively quickly.  That seems likely to continue with 1.18 
> and the early generics.
>
> > you'd be out of luck on stable Fedora
> > branches, as well.
>
> Not quite; one doesn't need to use the single Go compiler version in RPM form 
> from Fedora except currently when shipping software built as Fedora RPMs.  (I 
> know this was implicit in this discussion, but it's worth noting because 
> people can and do get the Go compiler from e.g. upstream on Fedora systems 
> too to build and ship software outside of the Fedora package collection 
> itself)
>
> That said, I don't quite understand why it's so complex to use modularity as 
> part of building non-modular RPMs.  (But I know this was extensively 
> discussed, I didn't follow it really)
> It seems like it's more about maintaining multiple builds of the 
> compiler/runtime.
>

The following is based on the lessons learned from EPEL-8.
Koji does not really know much about modules or even RPMs beyond a
src.rpm. So when koji is putting together a build root it will pull in
things which best satisfy a spec files requires.

Case 1:
Module A:
- golang-17
- golang-foo-3.4-

Module B:
- golang-18
- golang-foo-3.4

In this case, you could define a spec which requires golang-17 but
koji's dep resolver pulls in golang-foo- from Module B for non-modular
packages. This breaks the build.

Case 2:
Module A
:
- golang-17
- golang-foo-3.4-

Module B:
- golang-18
- golang-foo-3.4
or
- golang-foo-3.3 

Koji's dep resolver in this case will then pull in Module A's
golang-foo for any 'non-modular' package which required golang-foo.

You can configure koji to do a slightly different depsolving using dnf
versus the koji algorithms, which fix things in that only default
modules may get enabled in mock. [However may is a strong word.. it
sometimes does not.]

The fixes to this are:
a) use a tool like grobisplitter which breaks out all modules into
separate repositories versus 'virtual repositories'. This allows koji
and mock better ability to sort out what is the right package to put
into the buildroot.
b) use a script program like ursa major which basically hardwires in
MBS determinations. This works for EL8/EL9 because the changes in
modules has to go through a lot of internal checklists and such to
make sure the script is updated and doesn't break in builds. It
doesn't work that well in Fedora unless we put in similar 'please mark
this package as to be used for this and get a PR signoff' [or someone
writes and maintains a tool to do this which they did in MBS...]
c) everything which uses a module, requires to be a module. Then MBS
does all this determination and tells koji -> I don't care what you
think, tag in Module-B's golang-foobar for this build.
d) someone replaces koji with a build system which knows about MBS and
other meta-tools.

> It's interesting to note that in CentOS Stream 8, go-toolset is modularized, 
> but that's not true in CentOS Stream 9.
>
> Also related to this, it's worth looking at what others do; e.g. NixOS seems 
> to maintain a few versions of Go: 
> https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/go
> But they only have one Rust version.  Although there are a ton of derivations 
> for gcc and llvm, I suspect only a few are used.
>
> It looks like Debian ships package+versions, e.g. `golang` is 1.17, and 
> there's `golang-1.15` in unstable.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing 

Re: The great Mailman 3 / Hyperkitty upgrade: bumping flufl-lock and mistune?

[Stephen John Smoogen]

On Wed, 15 Dec 2021 at 05:51, Miro Hrončok  wrote:
>
> On 14. 12. 21 23:29, Michel Alexandre Salim wrote:
> > Hi all,

> > - epel-packagers-sig (collaborator, epel* branches) for helping to
> >bootstrap on new EL releases
>
> Fine by me, although I prefer actual maintainers to be responsible for EPEL
> branches.

Speaking of which. I am guilty of branching a bunch of python packages
in 2019 for EPEL-8 which the python team did not plan to maintain. I
need to take responsibility and be made the maintainer of those or
have them removed from EPEL-8.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Stephen John Smoogen]

On Thu, 2 Dec 2021 at 14:37, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/FsVerityRPM
>
> == Summary ==
>
> Enable the use of fsverity for installed RPM files validation.
>
> == Owners ==
>
> * Name: [[User:Dcavalca|Davide Cavalca]], [[User:Borisb|Boris
> Burkov]], [[User:Filbranden|Filipe Brandenburger]],
> [[User:Salimma|Michel Alexandre Salim]], [[User:Malmond|Matthew
> Almond]]
> * Email: dcava...@fb.com, bor...@fb.com, filbran...@fb.com,
> mic...@fb.com, malm...@fb.com


> ** koji integration: koji will need to add the fs-verity metadata to
> packages when signing them

I am going to say that this is a bigger sticking point than people are
realising and this is not a F36 but a F37 change.

The changes to koji, signing infrastructure and testing have to be put
in place before January 19 2022 (2022-01-19) for the mass rebuild[1].
They need to have been in staging and testing before then so that bugs
could be worked out and various groups could work things out.  Due to
various end of year holidays and 'use your PTO before its lost'
schedules, many of the developers who could sign off on the changes to
koji/bodhi/whatever-testing/sigul/etc depending on the changes needed
are not going to be available. Even if the changes are trivial ones,
this is a very short window to land things.

At best for F36, I could see the changes getting put into Fedora
before the beta and some packages signed.

If you want this for F37, then all that work needs to be ready and
done by (2022-07-20)[2].

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html
[2] https://fedorapeople.org/groups/schedule/f-37/f-37-key-tasks.html

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora EPEL 9 test instance?

[Stephen John Smoogen]

On Sun, 5 Dec 2021 at 14:05, Richard Shaw  wrote:
>
> Any plans to add EL 9 to the list of test instances?
>
> https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers
>

Could you please put in a ticket to
https://pagure.io/fedora-infrastructure/new_issue so it can be worked
on?


> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Stephen John Smoogen]

On Fri, 3 Dec 2021 at 17:09, Richard W.M. Jones  wrote:
>
> On Fri, Dec 03, 2021 at 06:08:49PM +, Davide Cavalca via devel wrote:
> > Broadly speaking, fs-verity makes it possible to ensure that files that
> > were installed via an RPM have not been modified. It is useful in
> > environments where an attacker might be able to modify system files
> > (say, replace /bin/ls with a compromised version) and you want to
> > protect against that. For example, consider an appliance-like system
> > placed in an untrusted location where you may not be able to control
> > who has physical access (this could be a server, but it could also be a
> > kiosk in an internet point or a school). In this scenario, fs-verity
> > can be one of the building blocks to ensure and maintain system trust.
>
> I'm unclear about the threat model - this is an attacker who is
> someone able to overwrite single files (eg. /bin/ls) but cannot turn
> off the fs-verity system as a whole?
>
> Also if RPM can update /bin/ls then surely an attacker who can widely
> compromise system files must also be able to update /bin/ls in the
> same way?
>

Or just pad /usr/bin/rpm with some null characters at the end to break
its signature and also stop updates from happening. [Or the fs-verity
daemon which will report that these problems are occuring. ]





-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Question for election candidates: do you support allowing Fedora src-git repositories to be hosted on a proprietary software git forge?

[Stephen John Smoogen]

On Mon, 29 Nov 2021 at 16:26, Michael Catanzaro  wrote:
>

>  > Could we set up open-source Gitlab and run that? Well, history has
> shown that the answer is "probably not, actually".
>
> I don't believe it. If GNOME and KDE and freedesktop.org and Debian and
> Purism can all do it, I'm pretty sure Fedora can too. GNOME has two
> sysadmins handling all of GNOME infrastructure, one of whom is
> part-time, but GNOME GitLab never seems to lag too far behind upstream.
>

The main problems with trying to get a test Gitlab working in the past
was usually dealing with the copious amounts of shared disk space and
systems needed to run the all the items listed in the
https://docs.gitlab.com/ee/administration/reference_architectures/5k_users.html
diagram (we tend to fall at this level though certain times a year
would be at 20k). Because of how the Fedora buildsystem works, all of
this needs to be located in our main datacentre or you rapidly find
koji/mbs/bodhi/pdc/etc/etc breaking somewhere.

The second issue has been the general rule that Fedora systems run by
infrastructure use Fedora Linux or RHEL. Packaging up all the ruby
gems and various services needed is a large task and usually falls on
someone like Neal Gompa to try a stab at it.

The third issue is round-tuits. There are a lot of things we need to
get round to it, if there is ever time. Every release, some new plate
(or plates) gets added to the Fedora Infrastructure spinning contest.
Yes Fedora has 3 full-time sysadmins and several volunteers but it has
generally a backlog of things, broken existing things, and limited
timelines (want to put in new infrastructure? you can do it in 2-3
week stretches every 4 months. Miss those and you have to wait until
the next window.. try to do it outside those little windows and watch
100+ developers complain to upper management that their package broke
for some reason. Then spend time in meetings explaining that X group
needed Y and sorry it broke Z.) Things have improved on this front in
the last 2 years but it is still problematic.

Getting past the first one is finding the appropriate infrastructure
and building it out with all the other parts of a build system which
would tie to it. The second one needs either running a different OS or
people doing a lot of packaging work on top of their existing
packages. The third one requires volunteer time or having different
objectives decided on.

Getting an open source gitlab is not impossible. It just takes a lot
of free time, systems and work done somewhere to make it happen.

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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 

Re: [EPEL-devel] 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

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

Re: A way to request/vote for packages to add next to Fedora Linux?

[Stephen John Smoogen]

On Fri, 19 Nov 2021 at 07:12, Neal Gompa  wrote:
>
> On Fri, Nov 19, 2021 at 7:05 AM Ahmed Almeleh
>  wrote:
> >
> > I do think voting for packages to be included in the next Fedora release is 
> > an amazing idea maybe we could create a survey through Google forms or make 
> > a  custom website for Fedora. I.e. Telling users select all packages you 
> > would like to see in Fedora 36.
> >
>
> It's a horrible idea, because it will just lead to disappointed users.
> Nothing compels anyone to do anything about that, so people who fill
> them out and see no results would just get angry at us.
>

To clarify. Packages in Fedora are there because of volunteers.
Outside of a small subset of glibc/kernel and some other items, all
the packages maintained by a Red Hat employee are there on that
person's volunteer time. The project has no power to compel a packager
to pick up a package and the project has no power to compel a packager
to keep a package when they want to let it go.

In the end, these sorts of lists are only useful when a project is
starting out and people can say 'Oh i really want this' enough that a
packager with free time takes it up. When a project is fully going and
most packagers have reached their limit.. these lists have multiple
negative effects:
1. People don't see the package getting added and are disappointed
2. Packagers can feel extra put upon as most of them are already overburdened.
3. New packagers usually see these packages, and find themselves
drowning in trying to take these on. First the packages are never easy
to package up. Second even when they are, there are a lot of rules and
nuances to rules which need to be mastered to deal with
updates/upgrades and not stomping on someone else's package.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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

Re: F37 Change: RetireARMv7 (System-Wide Change proposal)

[Stephen John Smoogen]

On Tue, Nov 16, 2021 at 15:10 Peter Boy  wrote:

>
>
> > Am 16.11.2021 um 20:37 schrieb Miro Hrončok :
> >
> > On 15. 11. 21 20:15, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/RetireARMv7
> >> == Owner ==
> >> * Name: [[User:pbrobinson| Peter Robinson]]
> >> * Email: 
> >
> > May I suggest to include
> https://lists.fedoraproject.org/archives/list/a...@lists.fedoraproject.org/thread/YC2LYBJSFKDAVBUJAIFQCCBS5VLW5TUB/
> in the feedback section (which is entirely missing from this proposal)?
>
> I've only been dealing with Arm SBC boards for a short time and therefore
> only with aarch64 and certainly don't know many details yet.
>
> A big advantage of Linux is that older hardware is supported for a long
> time and is still usable. This is almost a "trademark“.
>
> Therefore my question, would it reduce the effort already noticeably, if
> you reduce armv7 to "server" (and evtl IoT), i.e. without all the graphical
> interfaces? And without new, additional functionality, just security fixes?
> A kind of „maintenance mode“?
>
> This could (hopefully) solve a number of problems raised by various
> contributors to the discussion (and preserve the „trademark").



The main problem is that armv7 is currently built on a set of AARCh64 dual
instruction CPU systems from AMPERE. These boxes can run VM’s of armv7
instructions and allow us to do builds for Fedora. They are also the way
that what few QA tests can be done are done. These systems are also no
longer built, and the newer systems are AARCH64 only.

While it is possible to run ARM via QEMU emulation, this is mainly ‘for
demonstration purposes’ only. The QEMU emulation is about 4 times to 20
times slower than native running and can lock and crash on non-reproducible
faults regularly. Because failed servers cause ALL koji architectures to
fail a build.. it would mean a lot of crashed builds for an architecture we
can’t regularly debug.

Fedora does not do cross compilation so that is not a way out of this
either.

These are the major reasons for retiring the armv7 architecture with the
hope they are retired before we end up with no builders in the middle of a
release.



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

Re: Planned Outage - build systems ( koji, osbs, mbs, src, pdc, kojipkgs, odcs, registriy) - 2021-11-09 17:00 UTC

[Stephen John Smoogen]

For full details on the problems please see
https://pagure.io/fedora-infrastructure/issue/10302
synopsis: z15 move failed, we are still on z13?/z14? until next week
or so when this will be tried again.

On Wed, 10 Nov 2021 at 06:55, Alexander Ploumistos
 wrote:
>
> Now they're back up and running again. I think that when I started the
> builds before, s390x did not appear in the output of "koji list-tasks
> --mine".
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Tue, 9 Nov 2021 at 04:39, Rajeesh K V  wrote:
>
> > > I remember seeing 60-70% reduction really often, and 90+ periodically.  
> > > I've
> > > read Kevin's explanation of why it's not working as well now, but I wonder
> > > what changed between the early implementation when results were very good
> > > and now, when they really aren't.
> >
> > I think it's because you only see deltas from N to N+1 now and before
> > you saw deltas from N to N+X before. So, I think if we made it somehow
> > create older deltas, you would again see better savings. The issue
> > doesn't just cause there to be fewer deltas, but it also causes those
> > few be be against very recent changes, so less effective.
>
> Would it make sense (and possible to implement fairly easily) to
> generate deltas weekly instead of daily? That may already be a good
> start; as I’d imagine bandwidth constrained users would generally try
> to update on a weekly or monthly basis.

Not easily for 2 reasons:

1. deltas are package to package and many packages rev 4-6 times a
week (I am looking at you, kernel). So a once a week delta update
would have to make deltas against each of those packages for both
people who are resource constrained and those who are not.
2. Each 'compose' of Fedora is like a manufacturing line where if you
turn off some part, the rest after that point break because something
they expect is not there. If we turn off deltas altogether, we can
clean up various bits that were expected afterwards but someone would
need to do that work while doing all the usual work.

So you would need to set up a seperate compose pipeline which would do
this once a week and put those in a tree which is distinct from the
regular daily Fedora. That requires doubling the number of servers and
increasing disk space. Both of which are limited resources on the part
of Fedora Infrastructure.


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 no USB after today's updates

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 08:16, Sergio Pascual  wrote:
>
>
> El lun, 8 nov 2021 a las 13:39, Stephen John Smoogen () 
> escribió:
>>
>> On Mon, 8 Nov 2021 at 06:53, Sergio Pascual  wrote:
>> >
>> > Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf 
>> > updated' and rebooted. After the reboot, all my USBs are disabled. No 
>> > mouse, no keyword.
>> > I know my hardware works because the keyboard works in grub, and the light 
>> > of my optical mouse in on until some errors appear in the kernel during 
>> > boot.
>> >
>> > I have tried:
>> > kernel-5.14.15-200.fc34.x86_64
>> > kernel-5.14.15-300.fc35.x86_64
>> > kernel-5.14.16-301.fc35.x86_64
>> >
>>
>> The developers will need to know what the exact motherboard/laptop
>> version and manufacturer you have in order to diagnose this issue. My
>> initial guess is that since the f34 kernel also fails, that the
>> problem is with a firmware module and whatever the motherboard is
>> expecting to use. [The fact that it is only finding USB2 says that
>> either the system is really old or that it is trying to fail to its
>> lowest working value.]
>>
>>
>
>
> My workstation is a Dell Precision Tower 7910.
>
> lscpi says I have the following serial bus controllers
>
> 00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI 
> Host Controller (rev 05)
> 00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> Enhanced Host Controller #2 (rev 05)
> 00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB 
> Enhanced Host Controller #1 (rev 05)
>

Can you try downgrading to the F34 linux-firmware and see if the f34
kernel sees the chipset again?



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 no USB after today's updates

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 06:53, Sergio Pascual  wrote:
>
> Hi, I upgraded my workstation to F35 last Friday, and today I 'dnf updated' 
> and rebooted. After the reboot, all my USBs are disabled. No mouse, no 
> keyword.
> I know my hardware works because the keyboard works in grub, and the light of 
> my optical mouse in on until some errors appear in the kernel during boot.
>
> I have tried:
> kernel-5.14.15-200.fc34.x86_64
> kernel-5.14.15-300.fc35.x86_64
> kernel-5.14.16-301.fc35.x86_64
>

The developers will need to know what the exact motherboard/laptop
version and manufacturer you have in order to diagnose this issue. My
initial guess is that since the f34 kernel also fails, that the
problem is with a firmware module and whatever the motherboard is
expecting to use. [The fact that it is only finding USB2 says that
either the system is really old or that it is trying to fail to its
lowest working value.]


> without success.
> I'm getting messages like these:
>
> [   23.722355] usb 3-10: new high-speed USB device number 7 using xhci_hcd
> [   23.857746] usb 3-10: New USB device found, idVendor=0bda, idProduct=0184, 
> bcdDevice=84.13
> [   23.857755] usb 3-10: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [   23.857759] usb 3-10: Product: USB2.0-CRW
> [   23.857762] usb 3-10: Manufacturer: Generic
> [   23.857764] usb 3-10: SerialNumber: 2010081884130
> [   24.016363] usb 3-7.1: new high-speed USB device number 8 using xhci_hcd
> [   29.648377] usb 3-7.1: device descriptor read/64, error -110
> [   45.520400] usb 3-7.1: device descriptor read/64, error -110
> [   45.624451] usb 3-7-port1: attempt power cycle
> [   45.738358] usb 3-13: new high-speed USB device number 9 using xhci_hcd
> [   45.865929] usb 3-13: New USB device found, idVendor=05e3, idProduct=0608, 
> bcdDevice=32.98
> [   45.865939] usb 3-13: New USB device strings: Mfr=0, Product=1, 
> SerialNumber=0
> [   45.865942] usb 3-13: Product: USB2.0 Hub
> [   45.866653] hub 3-13:1.0: USB hub found
> [   45.866992] hub 3-13:1.0: 4 ports detected
> [   46.304365] usb 3-7.1: new high-speed USB device number 10 using xhci_hcd
> [   56.160384] xhci_hcd :00:14.0: Abort failed to stop command ring: -110
> [   56.160384] xhci_hcd :00:14.0: xHCI host controller not responding, 
> assume dead
> [   56.160384] xhci_hcd :00:14.0: HC died; cleaning up
> [   56.488455] xhci_hcd :00:14.0: Timeout while waiting for setup device 
> command
> [   56.488480] usb 4-2: USB disconnect, device number 2
> [   56.904366] usb 3-7.1: device not accepting address 10, error -108
> [   56.904412] usb 3-7-port1: couldn't allocate usb_device
> [   56.904464] usb usb3-port2: couldn't allocate usb_device
> [   56.904502] usb 3-13-port1: couldn't allocate usb_device
> [   56.904603] usb 3-3: USB disconnect, device number 2
> [   56.927819] usb 3-6: USB disconnect, device number 3
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 04:32, Michael Schroeder  wrote:
>
> On Sat, Nov 06, 2021 at 07:43:02AM -, Daniel Alley wrote:
> > Another issue - which is not per-se a security issue but it's still a 
> > problem - is that deltarpm uses md5 checksums pervasively.  They're 
> > everywhere.  And it uses its own implementation of md5 which doesn't 
> > respect FIPS, so even when the user has *explicitly* configured their 
> > system to not use md5 for anything security-relevant, libdeltarpm won't 
> > know or care.
>
> They are used as a consistency check, it might as well use crc32.
> So I don't see why FIPS is a concern for you.
>

In order to get the overall system to be FIPS (and equivalent EU/RU/CN
ones) certified all the implementations of various functions have to
be audited and reviewed. Some must be able to be turned off no matter
what. It doesn't matter if 99 of the 100 versions of md5um are only
for consistency, they must be able to be turned off/not used and not
affect the system.
[ The reason why we can't have nice things is that various
super-programmers who see that 99 versions of md5sum are gone, but
find that one call in say librpm which still exists, so they make a
wrapper to it and then tie the bank code to it. Next thing you know,
you find yourself not just on the Register as a story about code gone
wrong but on the front page of various financial newspapers due to
bank losses.]


> Cheers,
>   Michael.
>
> --
> Michael Schroeder  SUSE Software Solutions Germany GmbH
> m...@suse.de  GF: Felix Imendoerffer HRB 36809, AG Nuernberg
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Sun, 7 Nov 2021 at 13:44, Gordon Messmer  wrote:
>
> On 11/7/21 01:14, Rajeesh K V wrote:
> > Deltarpm did
> > reduce a lot of update download size for many years since 2007
>
>
> I remember seeing 60-70% reduction really often, and 90+ periodically.
> I've read Kevin's explanation of why it's not working as well now, but I
> wonder what changed between the early implementation when results were
> very good and now, when they really aren't.
>

My guess is that we hit a sweet spot at a certain time, and we would
need to constantly tune deltarpm to find it. Compiler changes, link
tool changes, different options in a compile, etc can cause code to
look different enough that the diff is larger at times (even if the
underlying machine code is the same, just put in different places in
the executable.)


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Mon, 8 Nov 2021 at 05:17, Samuel Sieb  wrote:
>
> On 11/8/21 01:23, Demi Marie Obenour wrote:
> > On 11/7/21 12:15 AM, Sumit Bhardwaj wrote:
> >> It is not always about speed. There are still plenty of places in the world
> >> where people are on limited data plans and to them using delta rpms makes a
> >> lot of sense. They can work with slow speeds but not with high data
> >> expenses. So i feel turning it on by default and having a setting to turn
> >> it off is still a sane choice. Just my 2 cents.
> >>
> >>
> >> Regards,
> >> Sumit Bhardwaj
> >
> > I recommend that deltarpms be disabled by default as they increase attack
> > surface.  Users who need deltarpms to be enabled can turn them on manually.
> > In the future, deltarpms should be cryptographically signed, which would
> > mitigate these concerns.
>
> This has been discussed before.  The deltarpms don't need to be signed,
> it's irrelevant.  The resulting rpm is signed and the signature is
> checked before installing.

It isn't always irrelevant. The case which worries me is where the
attacks are on the tool which tries to make the RPM from the contents
on the disk and the deltarpm. In this case the tool has to have root
level access to reconstruct the original rpm and then apply the
deltarpm to it. Currently it must assume that the deltarpm is valid
until proven otherwise and so is going through untrustable data. This
is a place where anyone wanting to attack people who use Qubes are
most likely to focus on. [And yes that is a downstream but these sorts
of attackers are going to shotgun their attack in a way which hits
upstream also.]


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Stephen John Smoogen]

On Sun, 7 Nov 2021 at 00:16, Sumit Bhardwaj  wrote:
>
> It is not always about speed. There are still plenty of places in the world 
> where people are on limited data plans and to them using delta rpms makes a 
> lot of sense. They can work with slow speeds but not with high data expenses. 
> So i feel turning it on by default and having a setting to turn it off is 
> still a sane choice. Just my 2 cents.
>

To me this entire conversation is a tradeoff argument

Project issues
1. Having delta rpms allows for groups of people who could not work
with Fedora to have some ability to do so on limited data lines.
2. Each broken delta causes frustration and various 'why does this
tech suck' emails/irc pings/discussion threads which eats energy from
volunteers.

Infrastructure issues
1. The build infrastructure is a limited resource with limited disk
space, cpu, and a goal of composing updated artifacts for consumption
at least once a day.
2. Each delta takes disk space on our download and mirror system which
is also a limited resource. Infrastructure can only do deltas between
N package deltas
3. Each delta uses a large amount of compression which takes a long
time/energy on the servers to generate. This slows down the ability to
produce artifacts.

Consumer issues
1. Each delta can save the consumer download times on their limited resource
2. Each delta uses a large amount of compression which means that
applying on low power devices can be much slower than just downloading
the entire package.
3. Because Fedora composes at least once a day, consumers require
constant downloads to Fedora so that they can get 'working' deltas.
Only download once a week, and find that the downloaded deltas aren't
useful.

Does having to download deltas every day outweigh the savings of the
deltas? How does one measure that? How does one know what packages
deltas make sense for and how many of them need to be generated?

-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rawhide kernel crash

[Stephen John Smoogen]

On Sat, 6 Nov 2021 at 09:42, edmond pilon  wrote:
>
> Thanks for your  reply.
>
> I have a GTX 1080 and  495.44 drivers.
> The crash   happens  just after the same warning as you.
> I'm running the  5.15 rc6 kernel  without issue.
> The boot problems started since  5.15 rc7 upgrade , and  the only differences 
> between this versions are :
>
> - Enable CONFIG_FAIL_SUNRPC for debug builds (Justin M. Forbes)
> - fedora: Disable fbdev drivers and use simpledrm instead (Javier Martinez 
> Canillas).
>

I would be careful to say that those are the only two differences.
Those are the only changes that the Fedora kernel maintainers did on
top of the other changes that the upstream kernel has in it:
https://fossies.org/diffs/linux/5.15-rc6_vs_5.15-rc7/

It lists multiple changes in the drm drivers which could be causing that.

> So i will try to build the kernel without the second patch and make a try.
> Thanks again.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Possibly off topic: Slack will discontinue packaging for Fedora

[Stephen John Smoogen]

On Fri, 5 Nov 2021 at 13:25, Gordon Messmer  wrote:
>
> On 11/4/21 17:23, Gordon Messmer wrote:
> > I don't know if that's of interest to Fedora, as an organization, but
> > on the off-chance that it is: Is anyone in a position to ask someone
> > at Slack about that decision?  And whether there's anything that
> > Fedora can do to make publishing that package more feasible?
>
>
> To put a finer point on this: I'm not asking how I can run Slack, or how
> other people run or use Slack.  Those are questions I would ask on the
> user list.
>
> What I'm asking is whether Fedora, as an organization, is interested in
> working with prominent vendors to determine whether there are barriers
> to publishing software for Fedora, or whether they perceive insufficient
> value in doing so.  And, beyond those questions, is there anything we
> can do as an organization to help change that situation?
>

I believe those need to be tied into a couple of other questions
1. How does any organization work with these various prominent vendors?
2. What are the interests of said vendors and what are they focusing
on for customer growth?

Once those questions have been answered, then we can ask
3. Why did these prominent vendors decide to focus on OS A and B
versus A and B and C and ...
4. What barriers are there for making it work for OS C/D/E/F

Slack is now owned by Salesforce which will have specific monetary
goals for what they want the sub company to focus on. In the past
there was a large focus on getting everyone possible to use the
product and there is now going to be more focus on paying customers.
If we want a port focused for our OS, there need to be significant
paying customers who are using Fedora.

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

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

[Stephen John Smoogen]

On Fri, 29 Oct 2021 at 01:53, Ian Kent  wrote:
>
> On Thu, 2021-10-28 at 10:41 -0400, Simo Sorce wrote:
> > On Thu, 2021-10-28 at 10:28 -0400, Frank Ch. Eigler wrote:
> > > Stephen John Smoogen  writes:
> > >
> > > > Mainly because it is the authentication service equivalent of
> > > > telnet**. Very simple to set up, very simple to use, and very
> > > > easy to
> > > > steal all the information about logins, users, and setups. [...]
> > >
> > > ... well, compared to what?  LDAP commonly distributes crypttext
> > > passwords and databases with about the same amount of discernment
> > > and
> > > theft-enablement as ypserv.  Plaintext as in telnet makes an
> > > appearance
> > > nowhere but with yppasswd, AFAIK, which is nonessential.
> >
> > LDAP is normally deployed on a secure channel (TLS or GSSAPI), that
> > the
> > client can cryptographically check.
> >
> > NIS is a clear text protocol that can be trivially MitMed to provide
> > arbitrary information to the target system.
> >
> > Also generally LDAP *does not* in fact distribute passwords, most
> > systems use the LDAP Bind operation to test a password and the LDAP
> > server does *not* provide access to password hashes.
> >
> >
> > I thin k it is legitimate to question whether it is yet time to drop
> > this obsolete protocol (NIS) on backwards compatibility grounds.
> > But on security grounds it is indefensible, don't go there.
>
> There's no question NIS has poor security, as bad a using a local
> password plus shadow file anyway. People that use it must know

As bad as using a local password and shadow file with file permissions
of 0644 (or even 0666 depending on how badly it has been set up).

> that. The valid use is company internal only, on systems whose
> data is freely available to company personnel and where accounts
> and groups info. isn't security critical.
>

Company internal only is a rarity these days with cloud deployments
and people putting Alexa's and similar devices on the company
internet. That 'smart fridge' in the company workroom or 'smart tv' in
the executive lounge is both an internal and external device. That
'smart speaker' someone stuck on the wireless to play their music is
just as likely to be able to send all that company data out as it is
able to get Conway Twitty into the workplace.



> It's been that way for many, many years ... it's no secret.
>
> It's a pity NIS+ was such a pain to setup and use ... a bridge
> to far IMHO ...
>
> Ian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Stephen John Smoogen]

On Thu, 28 Oct 2021 at 10:03, Kevin Kofler via devel
 wrote:
>
> Stephen John Smoogen wrote:
> > a) Not have Lennart's name tied to a request. That just pulls in all
> > kinds of over-the-top statements where people will say 99.99% of the
> > people won't use it without any evidence.
>
> What does Lennart's name have to do with this? I would have objected the
> same way to this change no matter whose name(s) are on it. (And for what it
> is worth, I actually considered this to be mainly Zbyszek's change proposal.
> But it does not matter anyway. I have nothing against Zbyszek and I have
> seen a lot of good ideas from him. This change just happens to be a bad
> idea.)
>
> > b) Don't mention disk space growth. You will get nothing about how you
> > are bloating the operating system. **
>
> Nonsense. It is blatantly obvious to me that adding annotations to
> executables will bloat the operating system, even if you attempt to swipe
> that issue under the carpet. Do not take me for dumb!
>
> > c) Don't mention anything about making debugging or security easier.
> > Anyone who has a workflow will see that as a challenge to their own
> > choices.
>
> That is also a nonsensical assertion. The issue here is that there is a
> tradeoff between provable global bloat to the entire distribution and a very
> questionable gain in functionality.
>
> > This change has all three and so is going to be yelled at over and
> > over again. Instead you should make a change request which will give
> > you all those but has some other item tied to it.
>
> So you are advocating deliberately using a dishonest and misleading
> political tactic that politicians are rightfully criticized for, namely
> hiding unwanted changes in a larger change proposal?
>

I should have dropped my sarcasm and stated the following:

These threads end up with people emailing dozens or more times about
the growth of kilobytes or megabytes while not giving the same amount
of comment to growth 10x that much. Developers just want to get their
work and changes done efficiently, and what we have taught them is
that 'ask for forgiveness rather than permission' is the most
efficient path. Any current or future complaints that developers are
acting like politicians are moot, when we have made the best way to
get a change done is to act like one.

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

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

[Stephen John Smoogen]

On Thu, 28 Oct 2021 at 08:51, Michael Catanzaro  wrote:
>
>
> What I just don't understand is why so much argument over a minuscule
> disk space increase. We can argue over the best way to create
> backtraces. But trying to step on the toes of other people who are
> working on this problem just because their work requires a tiny
> annotation in each binary seems weird.
>

My take from these conversations is that it is best to
a) Not have Lennart's name tied to a request. That just pulls in all
kinds of over-the-top statements where people will say 99.99% of the
people won't use it without any evidence.
b) Don't mention disk space growth. You will get nothing about how you
are bloating the operating system. **
c) Don't mention anything about making debugging or security easier.
Anyone who has a workflow will see that as a challenge to their own
choices.

This change has all three and so is going to be yelled at over and
over again. Instead you should make a change request which will give
you all those but has some other item tied to it.

** We do not have these conversations that the linux-firmware over
time has eaten more disk space or that other compiler choices have
done even worse. It only comes up when people ask for permission
versus just doing 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 a BBS...
time to shutdown -h now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

[Stephen John Smoogen]

On Wed, 27 Oct 2021 at 23:47, Ian Kent  wrote:
>
> On Wed, 2021-10-27 at 13:40 -0400, Matthew Miller wrote:
> > On Thu, Oct 21, 2021 at 04:37:18PM -0400, Ben Cotton wrote:
> > > == User Experience ==
> > > For some users this change may be a bit disruptive and it may
> > > require
> > > some learning curve for switching to alternative solutions.
> >
> > I've spoken with some of my sysadmin friends and universities, and
> > they
> > suggest that the above is enough of an understatement to feel
> > insulting.
> >
> > They would like, at least, more time than F36 to adjust to this, and
> > broader
> > communication that we plan to drop it.
>
> Remind me, why is NIS support being dropped?
>
> Personally I thought it was a bad idea from the first I heard of it
> and never saw any actual valid reasons to do so. I was simply told
> to drop it from my package which I did.
>
> Ian

Mainly because it is the authentication service equivalent of
telnet**. Very simple to set up, very simple to use, and very easy to
steal all the information about logins, users, and setups. You can
secure it up to a point, but many of its faults like unencrypted text
are designed into its 35 year old structure. It is a service which
gets flagged on many security scans as a 'incredibly' high and is
beginning to be flagged as a 'this should not even be shipped to us'
by various sites (mainly because they have had major security breakins
and their insurance company will no longer cover them unless they get
serious.).

** And like telnet, it will only be dragged out of various
infrastructures on the retirement of a generation of sysadmins.



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

Re: Fedora minimum hardware requirements

[Stephen John Smoogen]

On Mon, 18 Oct 2021 at 02:20, drago01  wrote:
>
>
>
> On Monday, October 18, 2021, Nico Kadel-Garcia  wrote:
>>
>> Is it worth paying hundreds of MBytes of installer space, and the new
>> 2 GB minimum RAM to simply install Fedora? I'm not saying "discard
>> anaconda". I'm saying "be aware of some very real reasons the
>> installer has gotten so huge". And keep it in mind for your own
>> projects.
>
>
> Yes today's hardware is not the same we had at that time.
> Saving disk space and memory for the sake of saving disk space and memory is 
> to use your words "not worth it".
>

This conversation is one that seems to happen to computer people as
they age. I remember in the early 1990's that the Sun 4.1 installer
was incredibly bloated and required too much memory/cpu to anyone who
had installed a PDP, IBM 360x, etc. And the arguments we had when the
Fedora Core 1 being so bloated to the Red Hat Linux 4 installer. etc
etc. The standard ending of these conversations is "coders these days
just don't care about memory/cpu/disk space like we had to".
[Completely forgetting that was what they were told when they were 20
years younger.]

Of course, if memory/cpu/disk was really important... you could still
use that Fedora Core 1 as your daily driver. It would just take some
work.

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

Re: OCaml packages failing in ELN

[Stephen John Smoogen]

On Thu, 14 Oct 2021 at 07:44, Richard W.M. Jones  wrote:
>
> On Mon, Oct 11, 2021 at 03:53:09PM -0600, Jerry James wrote:
> > The ELN package builds for the recent OCaml 4.13 update have mostly
> > been failing, over and over.  I finally took a look at some today;
> > they're going to keep failing until a human intervenes.  Rebuilding
> > against Rawhide packages was supposed to fix this issue, but it
> > doesn't fix the problem we're having this time: package builds that
> > succeeded when they should have failed.
>
> I'm not sure I follow exactly what the problem is.
>
> > The problem is that some packages low in the OCaml dependency tree
> > were built successfully, but against packages that hadn't been rebuilt
> > yet.  The builds succeeded, so now those builds are sitting in the ELN
> > repository, preventing the corresponding Rawhide builds from being
> > used, but they have unresolvable dependencies.
>
> So say there's this (real) dependency chain:
>
> ocaml -> ocaml-labltk -> ocaml-findlib -> ocaml-dune
>
> We set off building (eg) ocaml-findlib.ELN before ocaml-labtk.ELN.
> However it's being built against the Rawhide version of ocaml-labtk,
> so it should both build and the dependencies of it should be OK.
>
> Unless of course we're hitting the unstable ocamlx(Dynlink) problem
> again?
>

Could it be that the building out of order even when using F36 as a
backstop repository might have caused issues?


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

Re: Onboarding package

[Stephen John Smoogen]

On Tue, 5 Oct 2021 at 11:28, Matthew Miller  wrote:
>
> On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> > >Is this really necessary?
> >
> > Yes. Because anyone can add something like this:
> > %post
> > rm -rf /
> >
> > And it will destroy the installed system or even the hardware.
>
> Yeah, but... that's not going get through the PR process? In fact, that
> specific thing should fail in CI before a human gets to it even.
>
> Overall, we put a lot of trust in maintainers. I don't see this _particular_
> route as a likely one for violating that trust.
>

I think part of the problem is that I don't think the proposal has
enough flesh on its bones for people not to see it causing all kinds
of problems somewhere. Or vice versa seeing not enough to see it being
worthwhile for a beginner. [For many a developer, PR's aren't that
interesting to most developers and not what they think about when
looking at packaging. Running fedpkg and making a spec file work on my
system and through the complicated koji+bodhi+mbs+.. stack is real
packaging.] So we need a real proposal with an end to end idea of what
is being done, what is to be learned, and how it is to be 'watched' by
real developers to make sure people are learning things.




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

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Tue, 5 Oct 2021 at 07:26, Peter Boy  wrote:
>
>
>
> > Am 04.10.2021 um 15:29 schrieb Mikolaj Izdebski :
> >
> > On Mon, Oct 4, 2021 at 2:08 PM Peter Boy  wrote:
> >> However, we lack concepts on how to proceed after removing java-maint-sig. 
> >> What consequences do we draw from the analyses?
> >
> > … If you want
> > to improve docs, just do it. And so on. ...
> > ... or to plan editing the wiki. Whoever wants to clean up some wiki
> > pages can simply do so, without asking.
>
> It’s not as easy as you think of. That way you will end with the docs as 
> Stephen Smoogen described 4 posts back, just chaos and misinformation. You 
> need  collaboration and agreement (shared plan) from participants in all 
> affected areas - including you as the (main) developer of a core package (not 
> writing text, but e.g check the concept, check technical correctness and 
> completeness). It simply doesn’t work the way you are proposing.

You also need people who are good at documentation which frankly many
developers are not. Be it a history of 'the only true documentation is
the code' to 'look its simple why didn't you just . It's the most obvious choice?'

It isn't that the developer is trying to be obtuse, I think it is how
the brain works for a lot of people. My autism makes it very hard for
me to communicate about code. I can think it, see it, dream it, but
once I get into 'word' mode I can't access it easily. And vice versa,
when I am in code mode, I am almost non-verbal and my emails get very
short and succinct (at least to me..).. Switch me over to word mode
and it takes me hours to be productive in code again. [I have to set
my emails and meetings in a block without working in much code.] My
social skills are also myopic.. I can work with people when I am in
word mode but I can not if I am in code mode beyond 'share code, get
reviewed, fix bugs, point out problems'.

It takes a lot of work to document what I do, and when I am under
water with too many tasks/packages it can be a lot easier to just make
it work versus doing that. I would like to say 'this is just me' but
when I have explained my problem to a lot of other developers there
are the nods of 'yep that is what it's like'. Getting a truly working
SIG together is a lot of emotional work that a lot of people don't
have the energy to deal with while also doing whatever they are
currently doing.

Getting documentation is a full time job usually with someone who has
to have patience and persistence to get the information they need out
of the developers in code mode and also get the words down into a way
that someone who isn't a developer in code mode can read.



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

Re: Onboarding package

[Stephen John Smoogen]

On Mon, 4 Oct 2021 at 13:25, Josh Boyer  wrote:
>
> On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi  wrote:
> >
> > On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> > > Thoughts?
> >
> > I like the idea!
>
> It's indeed a good idea.
>
> > We can block such a package from ever appearing in a compose in pungi.
>
> You'd need to block it from ever appearing in the buildroots.  You
> wouldn't want someone adding something to it that injected code that
> impacted the builds of other packages.
>

Would it be better if this happened in stg.fedoraproject.org
environment to triply make sure it didn't affect production?



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

Re: Slow download speed of RPMs updates

[Stephen John Smoogen]

On Sat, 2 Oct 2021 at 03:48, Mattia Verga via devel
 wrote:
>
> Recently I've started seen a strange behavior of dnf while downloading
> RPMs updates: some packages are downloaded at the usual speed of my
> connection (ca. 10MBps), while other packages, in the same transaction,
> shows really slow download speed (<100KBps).
>
> Does dnf uses different mirrors to download package updates in the same
> transaction? Is there a way to show the mirror dnf downloads the updates
> from? Running dnf in verbose mode doesn't show any clue.
>

dnf uses the same mirror until there is a complete timeout or a not
found. It will then switch to another mirror

Check the file /var/log/dnf.librepo.log to see if it is capturing the
mirror. On mine it records info like:

http://mirror.math.princeton.edu/pub/fedora/linux//updates/33/Modular/x86_64/repodata/f58e2b59bf551113cf566c6ef119900a3160de712ae1943f67fca42f05c23
0e9-updateinfo.xml.zck
...
2021-10-02T09:31:38-0400 INFO Downloading:
http://packages.oit.ncsu.edu/fedora/linux//updates/33/Everything/x86_64/drpms/appstream-data-33-3.fc33_33-4.fc33.noarch.drpm

> Mattia
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [RFC] Remove supoort for NIS(+) from PAM

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:51, Tomasz Torcz  wrote:
>
> On Fri, Oct 01, 2021 at 12:28:38PM -0400, Stephen John Smoogen wrote:
> > On Fri, 1 Oct 2021 at 12:21, Frank Ch. Eigler  wrote:
> > >
> > > Stephen John Smoogen  writes:
> > >
> > > > The places I have seen it still being used are in Universities run by
> > > > people who learned sysadmin in the 1990's and early 2000's. It is a
> > > > light weight system which is simple to set up [...]
> > >
> > > For those people who like simple to set up and working systems but are
> > > willing to consider upgrading if it's also simple and will keep working,
> > > is there a NIS->$whatever migration document in fedora someplace?
> >
> > I don't think anyone has come up with an agreed upon $whatever that a
> > majority of people like. There is LDAP but that isn't light. There are
> > kerberos but that isn't easy.
>
>   There's FreeIPA, which makes both of them easy. And we even ship is a
> Fedora feature.
>

As much as I love FreeIPA.. it is not as simple as going into a
directory, typing make and having your central systems
passwords,hosts, groups, uids now available to everyone else on your
network. And yes all that power is available in plaintext without any
confirmation that it is valid or correct :).. but it is done in 2-5
minutes and probably extended by scripts written over a 35 year
timeframe. Most of the site admins running NIS I know would change
their text editor to $that_other_one before they would turn off NIS.

My own opinion is that it is way past time to stop using it and
supporting it. I understand its allure, but I also understand the
allure of .rhosts files with * in them.

> > And honestly the cool kids only want web
> > logins these days as servers are a pain and why not just login into
> > Google/Facebook/Microsoft and let them deal with all that setup.
>
> --
> Tomasz Torcz Morality must always be based on practicality.
> to...@pipebreaker.pl — Baron Vladimir Harkonnen
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [RFC] Remove supoort for NIS(+) from PAM

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:42, Frank Ch. Eigler  wrote:
>
> Stephen John Smoogen  writes:
>
> >> > The places I have seen it still being used are in Universities run by
> >> > people who learned sysadmin in the 1990's and early 2000's. It is a
> >> > light weight system which is simple to set up [...]
> >>
> >> For those people who like simple to set up and working systems but are
> >> willing to consider upgrading if it's also simple and will keep working,
> >> is there a NIS->$whatever migration document in fedora someplace?
> >
> > I don't think anyone has come up with an agreed upon $whatever that a
> > majority of people like. There is LDAP but that isn't light. There are
> > kerberos but that isn't easy.
>
> "light" in terms of CPU/network, who cares.  "light" in terms of
> simplicity and maintenance, you have my attention.  If there is no such
> gadget available, then please let's keep NIS around.
>

The issue is that no one has written anything as simple as ypserv's
Makefile in the 35+ years yp has been around. Most of the replacements
start looking at all the problems yp brings with it from sending
things in plain text, ability to spoof services and controllers,
ability to spoof user/hosts, and a flood of other things.. and 'fixes
them'. Those fixes add in complexity and it goes back to 'this is
stupid, keep yp'.

The reason I brought up OpenID is that it is the only thing simpler
than YP.. You don't have to deal with any of the hassles of id because
you don't own it anymore.


> > And honestly the cool kids only want web logins these days as servers
> > are a pain and why not just login into Google/Facebook/Microsoft and
> > let them deal with all that setup.
>
> (OK but seriously that's not a fedora matter.  Well, or rather, I'd love
> to have a passwd/nss backed openid gadget.  Is that ipsilon?)



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

Re: [RFC] Remove supoort for NIS(+) from PAM

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 12:21, Frank Ch. Eigler  wrote:
>
> Stephen John Smoogen  writes:
>
> > The places I have seen it still being used are in Universities run by
> > people who learned sysadmin in the 1990's and early 2000's. It is a
> > light weight system which is simple to set up [...]
>
> For those people who like simple to set up and working systems but are
> willing to consider upgrading if it's also simple and will keep working,
> is there a NIS->$whatever migration document in fedora someplace?

I don't think anyone has come up with an agreed upon $whatever that a
majority of people like. There is LDAP but that isn't light. There are
kerberos but that isn't easy. And honestly the cool kids only want web
logins these days as servers are a pain and why not just login into
Google/Facebook/Microsoft and let them deal with all that setup.



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

Re: [RFC] Remove supoort for NIS(+) from PAM

[Stephen John Smoogen]

On Fri, 1 Oct 2021 at 06:14, Björn 'besser82' Esser
 wrote:
>
> Hello,
>
> I'm currently doing some experiments with replacing the - upstream
> mostly unmaintained - pam_unix module (authentication with user passwd)
> with something using less bloated and cleaner code.  This topic is
> currently also discussed with the upstream maintainer of pam_unix.
>
> Replacing parts of a software for the sake of less complexity usually
> comes with a cut-down of features; in this particular case it would be
> dropping support for NIS(+), which has already been abandoned by its
> initial developer SUN / Oracle for about 10 years [1].
>
> Before starting some more concrete plans, I'd like to get some feedback
> from the Fedora community how they feel about removing NIS(+) support in
> PAM.  Is it even still actively used anywhere and/or by anyone in the
> Fedora universe?
>

The places I have seen it still being used are in Universities run by
people who learned sysadmin in the 1990's and early 2000's. It is a
light weight system which is simple to set up and tends to be the
goto-stick for a lot of 'we put this together in 1999 with RHL6 and
upgraded ever since' places.

That said, NIS in most setups causes all kinds of security problems
and audit failures that those areas are probably rapidly going away.
[And the ones I know have been moving to Debian because it keeps
various other technologies we jettisoned long ago.]

If we drop this from pam_unix, should we look to dropping ypbind and
similar tools?

> Thanks,
> Björn
>
>
> [1]
> https://www.oracle.com/solaris/technologies/end-of-feature-notices-solaris11.html
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Wed, 29 Sept 2021 at 18:49, Emmanuel Seyman  wrote:
>

> As an aside, I'm somewhat surprised that the only commit on the Java
> SIG's main wiki page in nearly 4 years is one that simply fixes a
> spelling mistake.  This doesn't jive with the amount of discussion we've
> had on this list nor does it match the amount of work that people claim
> to have done on the stack in recent times.

Honestly I don't think checking the wiki for a SIGs work is any sign
of its work. The one thing I have seen taught to people in Fedora over
and over again is 'YOU NEVER TOUCH THE WIKI'. You change one thing and
you get someone yelling you broke all the translations, or that you
are an idiot for that word choice or quite a few other things, or you
play a game of ghost reversions where someone changes it back to what
was different and tell you 'its a wiki, I can do that.'  Or you spend
8 hours making a set of changes and then get a long 'well can you make
the layout a bit different, that hurts my eyes' from the other people
in the SIG. And finally, you are the new person so you are told by
every person who has had a bad experience or seen someone have a bad
experience to go make all these edits we have lined up but never done.
[Then get told, well that isn't what I would have done..]

Yes not all groups in Fedora are like this, but I have seen it happen
enough time to enough people to not judge wiki work as something
anyone does anymore.


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

Re: Fedora ? Java: The Death of Two SIGs

[Stephen John Smoogen]

On Tue, 28 Sept 2021 at 08:20, Richard W.M. Jones  wrote:
>
> On Tue, Sep 28, 2021 at 02:06:58PM +0200, Kevin Kofler via devel wrote:
> > Richard W.M. Jones wrote:
> > > OCaml library code can in principle be dynamically linked, eg:
> > >
> > > $ rpm -ql ocaml-extlib | grep cmxs
> > > /usr/lib64/ocaml/extlib/extLib.cmxs
> > > $ file /usr/lib64/ocaml/extlib/extLib.cmxs
> > > /usr/lib64/ocaml/extlib/extLib.cmxs: ELF 64-bit LSB shared object, x86-64,
> > > version 1 (SYSV), dynamically linked,
> > > BuildID[sha1]=5647dd0137ce0a5302c8040301b26a109d771948, with debug_info,
> > > not stripped
> > >
> > > but upstream doesn't make it possible to ship OCaml binaries this way,
> > > (they would still require rebuilding on every library update) and so
> > > we only ship the DLLs not fully dynamically linked OCaml binaries
> > > (except for the C code).
> >
> > Ah?
> >
> > So what sits in the main packages of libraries (e.g., in ocaml-facile as
> > opposed to ocaml-facile-devel) then? Don't only shared libraries belong in
> > the main package?
>
> The original split of ocaml-FOO / ocaml-FOO-devel doesn't make a lot
> of sense these days.  Ideally we'd put them all in one package.
>
> > So I take back my comment that the OCaml stack is properly packaged. ;-)
> > That sounds like almost as much of a mess as Go and Rust then.
>
> I'd hardly say OCaml packging is a mess.  It's much closer to the
> spirit of C packaging than those others.  If you have *specific,
> actionable* objections I will listen to them.
>
>

I think Kevin's comment is meant more towards the way the language
packages itself versus the rpm packaging of the language. Going from
Kevin's comments on languages over the years, a 'good' language should
not require such sort of rebuilding.


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

Re: Using YubiKey for accounts.fedoraproject.org OTP?

[Stephen John Smoogen]

On Mon, 27 Sept 2021 at 09:28, Miro Hrončok  wrote:
>
> Hello,
>
> I've been trying to add the OPT token from accounts.fedoraproject.org to my
> yubikey. I get a QR code and a otpauth://totp/username?secret=xxx URI.
>
> I copypasted the xxx secret (56 characters: digits and uppercase letters) and
> tried to add it via YubiKey Manager GUI via Applications/OTP as OATH-HOTP (6
> digits).
>
> I get "Failed to configure Long Touch (Slot 2). undefined" error.
>
> When I tried to use the CLI:
>
>  $ ykman otp hotp -d 6 -c 0 2 xxx
>
> I get "Error: key lengths >20 bytes not supported".
>
> Is there a way to use YubiKey for accounts.fedoraproject.org OTP, or is the
> device not compatible?
>

OK let's back up a bit, since I am looking at a working yubikey for
Fedora OTP at the moment. The first thing we need to see is if the key
you are using is compatible. There are multiple generations and they
use different commands to program them :/. The ones I know which work
are the older 'black' yubikeys. The newer blue ones, do not seem to
work with the Fedora commands shipped. If I run


I am looking at my yubikeys and they all work. I know that every
sysadmin in Fedora has been using yubikeys for years. So I am guessing
something else is going on here for this device. Here is what I get
from my two Fedora ones

```
$ # This is my oldest key which works for Fedora
$ ykinfo -t -i -p -I -1 -2
touch_level: 1793
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 10

$ # This is my 2nd gen black key and was keyed to Fedora during testing.
$ ykinfo -t -i -p -I -1 -2
touch_level: 1285
programming_sequence: 1
slot1_status: 1
slot2_status: 0
vendor_id: 1050
product_id: 110

$ # This is a blue key which I use for other websites because Fedora
commands give me
$ ykinfo -t -i -p -I -1 -2
Yubikey core error: no yubikey present
```






> Thanks,
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Mon, 27 Sept 2021 at 08:45, Peter Boy  wrote:
>
>
>
> > Am 27.09.2021 um 12:30 schrieb Fabio Valentini :
> >
> > On Mon, Sep 27, 2021 at 12:19 PM Peter Boy  wrote:
> >>
> >>
> >>
> >>> Am 27.09.2021 um 11:13 schrieb Pierre-Yves Chibon :
> >>>
> >>> On Mon, Sep 27, 2021 at 10:57:12AM +0200, Peter Boy wrote:
> 
> >>>
>  What do you want to gain from it? What is the goal to be?
> >>>
> >>> I believe the original email from Fabio answers both of these questions.
> >>
> >> I don’t find a plan or a goal. Please, provide me with a hint.
> >
> > All I wanted to say is that the current state is disingenuous at best,
> > and misleading at first.
>
> Unfortunately yes, indeed.
>
> > By having @java-maint-sig as one of the admins of a package (and for
> > most of them, also the default bugzilla assignee), while that group
> > doesn't really function any longer, a false expectation of "there's a
> > whole group of people maintaining this package", while the reality is
> > closer to "zero or maybe one person might be looking at this package
> > once a year".
>
> I think you characterize the situation very pessimistically. Obviously the 
> constructions work to a certain extent. For example, we have 3 different 
> versions of the JDK available in parallel, which also receive regular 
> updates. We have important applications as tomcat. So we have something to 
> build on.
>

Personally I think I found the characterization as being optimistic to
almost realistic.

There have been 3 to 5 reboots since 2008 each time with smaller
groups of people. The issue is that Java is not a 'hot-new-thing'
language that gets all the programmers running to the field. It is now
seen as the same as Pascal/COBOL was in the 1990's.. that thing you
learn in Freshman CS and then avoided unless you want to be an
accounting-programmer (aka COBOL).

There is nothing wrong with 'accounting-programmer' languages, and
they are rarely just used for accounting, but it is a simple label
people use on it. Java and languages like it are utility languages
where after spending a week getting some report or other application
to work, volunteering time to fix it for someone else is the last
thing you want to do. [As several Java programmers have put it, you
don't see plumbers volunteering to fix their neighbors pipes on
weekends.]

In the end, we have never been able to keep a pool of people
interested in making Java work. We aren't the only ones as this
problem occurs in Debian also (and it occurs in other languages like
Ruby, JS, Python also). The people who want to volunteer time on the
language are more likely to work in an area where others interested in
the language are already there. Dealing with the vaguries of 40
different slightly different disk layouts, file permissions, and other
tools  from every distribution are grit in the shoe when you already
have a 'working layout' and have people who speak your language and
problems elsewhere.





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

Re: Fedora  Java: The Death of Two SIGs

[Stephen John Smoogen]

On Sun, 26 Sept 2021 at 16:35, Christopher  wrote:
>
> I think part of the problem is that Java is too big. There are too
> many libraries to fit into a single community. I think there's
> probably willing volunteers to maintain some libraries and application
> packages, but these are not necessarily the same people willing to do
> all the work of maintaining OpenJDK packages or the whole Eclipse
> stack.
>
> When modularity took out the whole Java stack, it did a lot of lasting
> damage that is going to be hard to recover from. In order for the vast
> majority of Java packagers to return, there needs to be a reliable

I am going to disagree here greatly. The Java stack was in exactly the
same mode it is in now before then. There was 1 person 'maintaining'
hundreds of packages for a long time. There were other 'maintainers'
listed but they were not around or ignoring things from burnout.
People had brought this up year after year and all that would happen
is everyone would say "we can't ever let things down" and pitch in to
fix things (or make the 1 person who was over-committed feel guilty
for asking to lighten the load).

Then when the defacto Java maintainer moved stuff into modules to make
his life easier.. there was a 'well we can find new people to do this
instead' and various initiatives were tried to make it. Those have all
failed because

1. Java and Fedora have a long back history of ugly fighting which
makes it hard for 'older' Java people want to work with Fedora. Like
old feuds, there are landmines which flare up fights no one remembers
exactly but they come up.
2. That ugly fighting is sort of written into the packaging guidelines
because it is a long 'compromise' between how Java wants packages done
and how Fedora wants it done. This makes it hard for 'new' Java people
because they are whiplashed between different world views. And vice
versa, if you aren't a Java person and try to make it fix a Java
package it can be a brain hurt as you try to do things like in other
packages and it all fails.
3. Most Fedora consumers just want the tools to work and pile onto the
smaller pool of developers about 'why is X always broken?' This has
caused continual burnout when new teams came up. It was also what was
burning out the previous people.

Basically Java has been 'broken' for as long as I have been part of
Fedora. The 'good' times are usually just after the last time Java was
going to be pulled out in the next release, and finally everyone drops
the things they really care for and works on it. Then everyone goes
back to their real pleasures and it falls apart again. Later, rinse,
repeat.


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

Re: Copr for ppc64le "No space left on device"

[Stephen John Smoogen]

On Wed, 22 Sept 2021 at 10:20, Steven A. Falco  wrote:
>
> The KiCAD project builds "nightly" images via copr.  Lately, I'm seeing many 
> failures for the ppc64le architecture.  In some cases [1] I get "Error: 
> Failed to download metadata for repo 'fedora'".  In other cases [2] I get 
> "pigz: abort: write error on  (No space left on device)".
>
> Is there anything I can do as a copr user to work around this, or can someone 
> supporting the copr infrastructure take a look?
>

I would say as a copr user, the first thing to do is to open a ticket
in https://pagure.io/copr/copr/issues where the COPR admins can take
care of it.

> Steve
>
> [1] 
> https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-rawhide-ppc64le/02832014-kicad-nightly-doc/root.log.gz
> [2] 
> https://copr-be.cloud.fedoraproject.org/results/@kicad/kicad/fedora-34-ppc64le/02832012-kicad-nightly/root.log.gz
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Koji too busy?

[Stephen John Smoogen]

On Mon, 20 Sept 2021 at 04:21, Vitaly Zaitsev via devel
 wrote:
>
> On 20/09/2021 09:41, Евгений Пивнев wrote:
> > What happened with koji?
>
> I can confirm. Koji is too unstable since Thursday.
>

Could you and others help the Fedora admins with more info on what you
mean by unstable? Currently koji and other utilities in Fedora
infrastructure are under a freeze and have been since beta started.
The packages I see which have been updated on systems since 2021-09-17
is xen-licenses on some builders and vim was updated on 2021-09-10
(openssl was updated on 2021-09-02). The only changes I see in configs
site-wide since 2021-09-15 are to the non-production datanommer so
should  have no effect on koji.

On the builder mentioned in this I see errors starting on 2021-09-19
but nothing before then and I am not finding anything on a quick audit
of other builders. Some specific build problems would be useful for
when the Fedora admins get in later today to look at things.


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

Re: [Fedora-packaging] Re: Self Introduction: Eric Curtin

[Stephen John Smoogen]

Mea-culpa to everyone.

On Fri, 17 Sept 2021 at 10:29, Eric Curtin  wrote:
>
> Hi Guys,
>
> When I write to IRC I get:
>
> "Cannot send to nick/channel"
>
> How can I solve this?
>
> I would like to get added to the following groups, if possible:
>
> cla_redhat [OBSOLETE] Red Hat Employees CLA Group member
> fedora-contributor Fedora contributors member
> fedorabugs Group for granting Bugzilla editing privileges member
> packager Fedora Packager GIT Commit Group member
>
> Could somebody add me to some of these? I would like to get
> inotify-tools package updated and contribute elsewhere in future.
>

Whoops, my apologies to Eric and everyone else. I am supposed to be
Eric's mentor on getting into various communities and dropped the ball
here. I will explain the items on this above and get him integrated.


> Is mise le meas/Regards,
>
> Eric Curtin
> On Thu, 16 Sept 2021 at 20:04, Eric Curtin  wrote:
> >
> > Hi Guys,
> >
> > As per:
> >
> > https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> >
> > here is my introduction. I am the upstream maintainer of inotify-tools
> > and recent hire at Red Hat. I would like to join the Fedora Package
> > Maintainers.
> >
> > Is mise le meas/Regards,
> >
> > Eric Curtin
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/packag...@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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/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

Re: FF builds

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 14:05, Ken Dreyer  wrote:
>
> On Fri, Sep 10, 2021 at 9:33 AM Miroslav Suchý  wrote:
> > We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra 
> > to change it :)
>
> Is there more documentation about how Copr uses ccache? I was grepping
> around https://pagure.io/copr/copr for "ccache" and I see the
> "ccache_enable" plugin config is set to "False".
>

Small correction. Miroslav didn't say COPR uses ccache. He said COPR
uses ramdisk for mock.

Using ccache in mock is  exploitable so that a bad build can interfere
with other packages and items.

> The reason I'm asking is that I'm considering testing mock's ccache
> plugin within Koji for Ceph.
>
> I'm wondering about management, specifically whether we must track and
> maintain per-ceph-version ccaches.
>
> Do you have utilities for examining the caches, clearing them, etc? Do
> you distribute caches across builders? Anything else we should think
> about?
>
> - Ken
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 12:50, Marius Schwarz  wrote:
>
> Hi,
>
> since a few days, loading the enter_bug.cgi for "Product=Fedora" on RH
> BZ takes very long.
> It's quite possible, that it's happening for any other product too ;)
>
> It's over a minute ATM.
>
> Can someone take a look at this, or do i need to contact rh's adminteam?
>

It is best to contact the RH bugzilla admins for several reasons:
1. they will need information about when, where, how you are
connecting, and probably other items
2. no one in Fedora has login, debug or any other access to bugzilla
so we will have to go talk to them, they will ask us all of the items
and we will then have to find you to answer them.


> best regards,
> Marius Schwarz
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FF builds

[Stephen John Smoogen]

On Fri, 10 Sept 2021 at 09:33, Miroslav Suchý  wrote:
>
> Dne 09. 09. 21 v 18:54 Demi Marie Obenour napsal(a):
> > Can the Firefox build be distributed among multiple machines?
>
> I would love to see a benchmark how much it speed up big packages and how it 
> slow downs smaller packages. Whole rpmbuild
> part.
>
>
> FYI
>
> Mock has CCache plugin, which speeds the thing a bit, but can be easily 
> exploited. So on build systems it is switched off.
>
> Years ago I wrote blogpost about building in memory using tmpfs. That can 
> give you up to 70% gain.
>
> http://miroslav.suchy.cz/blog/archives/2015/05/28/increase_mock_performance_-_build_packages_in_memory/index.html
>
> We use this in Copr. AFAIK Koji does not use it. You can join Fedora infra to 
> change it :)
>

Uhm, let us not set up unreal expectations on what Fedora Infrastructure can do.
1. Koji needs to be able to support it and Fedora Infrastructure
doesn't/maintain work on that code.
2. Fedora Infrastructure would need either newer hardware or cut down
the number of builders to allow for more memory per system to do the
builds in ramdisk.
3. There are a long list of 'higher' priority items which the koji
developers have on their list to do all the time. This needs to be
weighed against the other needs of trying to make builds reproducible,
trying to make koji work better in a cloud evironment, etc.
4. If all of that would make it look like Fedora Infrastructure should
move to a different build system... then it isn't going to happen
soon.


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

Re: FF builds

[Stephen John Smoogen]

On Thu, 9 Sept 2021 at 13:01, Neal Gompa  wrote:
>
> On Thu, Sep 9, 2021 at 12:55 PM Demi Marie Obenour
>  wrote:

> > Also, could the Fedora project itself perform at least
> > basic QA for critical security patches?
> >
>
> Who do you think is the "Fedora Project"? It's us in the community!
>
> > > Two days for builds is not great, but it's not the end of the world.
> > > Would it be nice if we had more powerful builders? Sure. But it still
> > > would take a minimum of 2 days for something to go out since it needs
> > > to get pushed, pass tests, and get karma to autopush to stable
> > > releases.
> >
> > Can the Firefox build be distributed among multiple machines?
> >
>
> We'd need icecream[1] support enabled in Koji. I am not even sure Mock
> (the build engine) supports icecream right now.
>
> [1]: https://github.com/icecc/icecream
>
>

It would require more than that. It would require having our
networking and build systems able to talk to other systems when they
are building. For security reasons we turn off networking inside the
mock so that we don't get packages pulling in crap during the build. A
distributed build by definition is pulling in 'crap' from other
systems so you have to not just have networking turned on, you have to
have tools to make sure the 'crap' is really the stuff you wanted.

I don't see that happening anytime soon. The issue with builds being
stuck is a problem but it needs a systematic fix across the board
versus just for 'Firefox'.




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

Re: F35 3x slower boot than F34

[Stephen John Smoogen]

On Sun, 5 Sept 2021 at 07:12, Peter Boy  wrote:
>
>
>
> > Am 05.09.2021 um 09:32 schrieb Samuel Sieb :
> >
> > On 2021-09-05 12:19 a.m., Peter Boy wrote:
> >> Much to my chagrin, you describe the biggest problem in Fedora for years 
> >> and the one why Fedora is falling further and further behind among 
> >> distributions. The problem overshadows all that many positive features 
> >> that otherwise distinguish Fedora.
> >
> > How is Fedora falling behind?
>
> I watch Distrowatch in an occasional way. It is certainly not the most 
> reliable indicator, unquestioningly. But is is one among others. Currently 
> Fedora ranks 10th, one place ahead of Suse, a distro that has long been 
> considered nearly "dead" and has suffered greatly under Novell. And if you 
> look at sites like stackexchange or serverfault, it's very rarely about 
> Fedora.

Distrowatch allows whoever has the current bot army to be the number
one distro. The number one distro is usually a flash in the pan which
lasts until the core developers burn out from the amount of work of
trying to keep up with Debian or Fedora. (Or as soon as it drops from
number 1, finding that all the people who were 'helping' have moved to
the new number one.) The fact that CentOS/Rocky/Alma/etc has 1000x the
deployment size as Fedora but has 1/10th the votes 10x lower on the
counts says that it is really not a useful counter on what is really
popular. [And the fact that count numbers on distrowatch per distro
are much smaller than 10 years ago says that distribution building is
like email. There was a time when it was something everyone assumed
was the thing, but turned into a popular thing for people of a certain
'generation'. Now we are in a place where the current generations see
distros as something their 'dad' did versus something they are
interested in similar percentages as 20 years ago.]

The same goes about arguing about selinux. Most of this thread is
litigating things from 20 years ago versus now.


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

Re: Wine MinGW system libraries

[Stephen John Smoogen]

On Thu, 2 Sept 2021 at 12:42, Zebediah Figura  wrote:
>
> Hello all,
>
> I'm a contributor to the Wine project. To summarize the following mail,
> Wine needs special versions of some of its normal dependencies, such as
> libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
> sending out a mail to major distributions in order to get some feedback
> from our packagers on how these should be built and packaged.
>
> For a long time Wine has built all of its Win32 libraries (DLLs and
> EXEs) as ELF binaries. For various reasons related to application
> compatibility, we have started building our binaries as PE instead,
> using the MinGW cross-compiler. It is our intent to expand this to some
> of our dependencies as well. The list of dependencies that we intend to
> build using MinGW is not quite fixed yet, but we expect it to include
> and be mostly limited to the following:
>

At that point, would it make more sense to make Wine a Flatpak or
Snap? This is a really complex setup and could break in most build
systems for any of the operating systems in different ways. Since you
are needing to control all the sources in your own bucket, it would be
better if you ran the whole kit and kaboodle.



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

Re: Where has the kernel-doc package gone?

[Stephen John Smoogen]

On Mon, 30 Aug 2021 at 13:07, Nils K  wrote:
>
> I recently had to perform a bit of development/research where I often had to 
> take a look in the kernel documentation.
>
> Most of the time was spend offline so I wanted to download the `kernel-doc` 
> package however it does not seem to exist.
> Some old fedora documentations still refer to it however somewhere in the 2x 
> iteration of fedora it seems to have gone missing.
> CentOS 8 also still has it.
> Would it be possible to add this back to the repos?

It isn't that we aren't shipping it, it is that the Kernel spec file
does not generate any documentation anymore. It looks like Fedora 20
made this change but I don't know why beyond
https://bugzilla.redhat.com/show_bug.cgi?id=1223200 .  While EL-8 is
based on Fedora-28, the kernel team for RHEL uses a different spec
file. It also did not start shipping with the kernel-doc but looks to
have been added with
https://bugzilla.redhat.com/show_bug.cgi?id=1659636

At this point I suggest you file a bug against the kernel and cite
those two bugs. The current kernel team can work out what work it
would be needed and if it could be added.


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

Re: are s390x builders overloaded? Or have they been reconfigured?

[Stephen John Smoogen]

On Fri, 27 Aug 2021 at 10:27, Kaleb Keithley  wrote:
>
>
> Hi,
>
> My two most recent ceph builds on s390x have been oom killed.
>
> As recently as four days ago they were building fine.
>
> Any ideas?

No idea without links to actual koji build logs to see which of the
systems it might be.





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