Re: Policy on supporting old and external software packages and compat RPMS

[Gary Buhrmaster]

On Thu, Dec 8, 2022 at 1:54 AM Alexander Ploumistos
 wrote:

> I think that you are about to miss an important opportunity here.

+3000 (well, I guess I am only allowed a +1).

For non-niche requirements, I mostly find the
primary maintainers are more than willing to
add interested parties to the maintainers list
(and typically embrace the potentially reduced
maintenance burden on themselves by
sharing the work).
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Alexander Ploumistos]

Hello Terry,

On Thu, Dec 8, 2022 at 12:28 AM Terry Barnaby  wrote:
>
> Well I don't want to rock the boat with the maintainer, they are just
> doing what they think is expected.
>
> I will just continue with my own local RPM for our own uses and provide
> it for anyone else that is in the same boat as we are.

I think that you are about to miss an important opportunity here.
Since you are willing to maintain the package, why not do it within
the distribution? This would give you access to the infrastructure and
the people that can help you with problems down the road. Since you
are forced to use tools that employ old bits of software, it is more
than likely that sooner or later you'll be faced with another
deprecation. When that happens, as a package maintainer you will be in
a better position to do something about it, either by adopting a
package that is going to be retired or by becoming a co-maintainer,
plus you can test your own packages.
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/

Best regards,
A.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 06/12/2022 16:37, Kevin Kofler via devel wrote:

Terry Barnaby wrote:

Well in this case I have created a suitable compat lib, all I did was
re-introduce the bits to the SPEC file that removed the building of the
compat lib and we are fine. I haven't separated it out from the main
ncurses SPEC through and have only done this locally as I have no
knowledge of the hoops to create a separate package and that seems like
the wrong way to do this in general. I have made this available to
others who will be in the same boat.

Typically, compatibility libraries should not be subpackages of the main
library. But ncurses is a bit peculiar in that, as I understand it, the
latest code can still be built with the old ABI. So in that case, it at
least makes sense to build both from the same SRPM. But only if they are
going to be maintained by the same maintainer(s), i.e., you should probably
sign up as a comaintainer for ncurses in Fedora if you want to do it that
way. And of course only as long as upstream continues supporting building
for the old ABI. If they drop support, then a separate compatibility package
with an old version that supports the old ABI will be needed.

 Kevin Kofler
___


Well I don't want to rock the boat with the maintainer, they are just 
doing what they think is expected.


I will just continue with my own local RPM for our own uses and provide 
it for anyone else that is in the same boat as we are.


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

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Wed, 7 Dec 2022 at 15:45, Terry Barnaby  wrote:

> On 06/12/2022 20:21, Josh Boyer wrote:
> > On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen 
> wrote:
> >>
> >>
> >>>
> >> I think he would be happy with the policy spelled out in any form.
> Something like:
> >>
> >> While the Fedora Project is the upstream of CentOS Stream and Red Hat
> Enterprise Linux, it does not give any guarantees of its releases being
> compatible with either. Software built in either may not work due to
> missing dependencies, changes in kernel, compile time or library options,
> or similar issues.
> > Ah!  Yes, making that clear would be good.
>
> As a guideline that sound a bit woolly to me and doesn't sound useful to
> maintainers. As an rough idea either:
>
> While the Fedora Project is the upstream of CentOS Stream and Red Hat
> Enterprise Linux it does not attempt to provide any compatibility with any
> major current and past versions of Red Hat Enterprise Linux (currently 7,
> 8, 9) or any other Linux distribution. Software binaries built for these
> generic systems may or may not work.
>
> or
>
> The Fedora project attempts to provide a small degree of binary program
> compatibility by means of compat libraries for the major current and past
> versions of Red Hat Enterprise Linux (currently 7, 8, 9) and the past 2
> releases of Fedora only for reasonably some well used (by means of user
> feed back) external/commercial applications for 2 years after their
> publication date where this is easy of achieve as simple compat shared
> library additions and the maintainers of the required packages are willing
> to provide such packages.
>
>
> That's probably a bit much for some, but some watered down derivative :)
> Having a degree of binary compatibility aids external/commercial producers
> and makes Fedora more useful to more people.
> Just my view.
>
>
The first would be more likely to be accepted over the second. The second
requires packagers to actually test binaries from these other operating
systems, and that is extra work for volunteers.

Fedora is a stone soup project. If people want software to be in the
operating system, they have to bring it and keep it working themselves.
Once it is in, people will try to help out when they can, but time
resources to use stuff outside of what they normally do is usually not
wanted. There are probably 8 people who are paid to work 'full-time' on
Fedora, and most of their work is just keeping the build systems going.
Everyone else is a volunteer or paid to work on it after everything else
they have done is finished.



> Actually is there some mechanism that Fedora could work out how many are
> using compat RPM's ?
> I guess this would require some system used by mirrors that would report
> back number of downloads of each package. Obviously this wouldn't get
> everything (we have a cache of packages that we user across systems to
> reduce downloads across the Internet), but might give some metrics to
> automate such things.
>

No, there is no method to see what software is installed or used on
workstation systems.  The community has been overall very adverse to
wanting that, and when we had some software which did act as a 'this is
what is used' actively filled its database full of crap data. Attempts to
add things like 'popcorn' and such usually end with long legal discussions
and promises to revisit filling out crap data.

-- 
Stephen Smoogen, Red Hat Automotive
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 06/12/2022 17:40, Vít Ondruch wrote:


Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):

On 06/12/2022 15:56, Vít Ondruch wrote:


Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be 
depreciated,

or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.
Well, that is still *some* work and someone would have to do it. 
Are you

volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long 
as you

need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did 
was re-introduce the bits to the SPEC file that removed the 
building of the compat lib and we are fine. I haven't separated it 
out from the main ncurses SPEC through and have only done this 
locally as I have no knowledge of the hoops to create a separate 
package and that seems like the wrong way to do this in general. I 
have made this available to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the 
OS is likely to support. If the policy is to just support Fedora 
built binaries within the particular version of Fedora and to 
ignore external and commercial binaries built with say Redhat7 and 
provide no degree of compatibility so be it, but it would be useful 
for everyone to know where the land lies and be on the same page. 
The maintainer of the ncurses package wasn't sure of the policy on 
this.



I wonder what is this claim based upon? Could you provide a link? 
And I wonder if there was such policy, would the maintainer changed 
their mind? I am asking because I don't think that any policy can be 
enforced unless there is somebody to pickup the work. So in this 
case, it should be enough to convince the maintainer to revert the 
changes, shouldn't be?



Vít




Sorry, what claim ?



My question was specifically about the last sentence of the quote, 
e.g. do you have any link to BZ ticket, ML or anywhere else where this 
was discussed? That would help to get complete picture.





I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something 
that is fine. And obviously a Policy may not be enforced, but at 
least it would be a guideline. I understand the maintainer asked a 
question on when to depreciate on this list, but had no replies.



Ah, so there was ML thread you are referring to. Is it this one?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV/#Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV 



And this could also provide more context:

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


He took it that if the compat libs were not in use by any Fedora 
packages for the release in question it should/could be depreciated 
which is one approach.



It seems that Miroslav would consider the change if there was such 
guidelines.


So do you have any specific gudelines draft?

I think this is always the same, if you really want Fedora to do 
something, then it might need to take some action. Sometimes is enough 
to open ticket or send email, other times it means to maintain package 
or draft specific proposal for guidelines. You can even join the 
Fedora governing bodies if you think it will help.


But I still think the best option for you and for the whole Fedora 
community would be if you picked up the compat-ncurses package 
maintenance.


I added some ideas for guidelines in a recent list email. But I suspect 
most would not approve :)


Ok, I can look at that, but in this particular instance its seems to be 
a waste of extra effort, extra packages with extra SPEC's and extra 
build time as it is all there in the original SPEC file and this was 
depreciated as it was considered that this is the policy when a compat 
package was not used by any Fedora pure packages.






Vít


___
devel 

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 06/12/2022 20:21, Josh Boyer wrote:

On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen  wrote:



On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:

On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:

On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:

On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:

On 05/12/2022 16:00, Jarek Prokop wrote:


On 12/5/22 14:57, Peter Robinson wrote:

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
 wrote:

I wouldn't expect them to build for a Fedora version.  I also wouldn't
expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
work on Fedora either.


As a practical matter, I generally *do* expect them to be compatible
at some level. RHEL is a derivative of Fedora. Otherwise it gets very
difficult to use commercial software on a Fedora system. I know plenty
of ISVs that have a similar expectation.

That compatibility degrades over time though.  At this point in time,
with RHEL 7 being almost 9 years old, I would not expect software
built on RHEL 7 to work on any supported Fedora version.  If it does
work, that's fantastic and a testament to Fedora, but people should
not have that expectation.  Terry is politely asking for a policy that
would set that expectation.  I think the intention is good, but I
don't believe it to be realistic.


I think he would be happy with the policy spelled out in any form. Something 
like:

While the Fedora Project is the upstream of CentOS Stream and Red Hat 
Enterprise Linux, it does not give any guarantees of its releases being 
compatible with either. Software built in either may not work due to missing 
dependencies, changes in kernel, compile time or library options, or similar 
issues.

Ah!  Yes, making that clear would be good.


As a guideline that sound a bit woolly to me and doesn't sound useful to 
maintainers. As an rough idea either:


While the Fedora Project is the upstream of CentOS Stream and Red Hat 
Enterprise Linux it does not attempt to provide any compatibility with any 
major current and past versions of Red Hat Enterprise Linux (currently 7, 8, 9) 
or any other Linux distribution. Software binaries built for these generic 
systems may or may not work.

or

The Fedora project attempts to provide a small degree of binary program 
compatibility by means of compat libraries for the major current and past 
versions of Red Hat Enterprise Linux (currently 7, 8, 9) and the past 2 
releases of Fedora only for reasonably some well used (by means of user feed 
back) external/commercial applications for 2 years after their publication date 
where this is easy of achieve as simple compat shared library additions and the 
maintainers of the required packages are willing to provide such packages.


That's probably a bit much for some, but some watered down derivative :)
Having a degree of binary compatibility aids external/commercial producers and 
makes Fedora more useful to more people.
Just my view.

Actually is there some mechanism that Fedora could work out how many are using 
compat RPM's ?
I guess this would require some system used by mirrors that would report back 
number of downloads of each package. Obviously this wouldn't get everything (we 
have a cache of packages that we user across systems to reduce downloads across 
the Internet), but might give some metrics to automate such things.



josh


To perhaps illustrate the point further, Red Hat Enterprise Linux does
not support applications built on version X-1 running on X unless it
is constrained to using a very very small set of dependencies (glibc,
libgcc/libstdc++, and a few smaller libraries).  Again, it may work
fine but the expectation and support policies set for RHEL are
(simplified) build on X, run on X where X is within a major version.
Our full documentation on this is available in the Application
Compatibility Guides.

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



--
Stephen Smoogen, Red Hat Automotive
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, report it: 

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen  wrote:
>
>
>
> On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:
>>
>> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>> >
>> > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  
>> > wrote:
>> > >
>> > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>> > > >
>> > > > On 05/12/2022 16:00, Jarek Prokop wrote:
>> > > >
>> > > >
>> > > > On 12/5/22 14:57, Peter Robinson wrote:
>> > > >
>> > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>> > > >  wrote:
>>
>> > > I wouldn't expect them to build for a Fedora version.  I also wouldn't
>> > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
>> > > work on Fedora either.
>> > >
>> >
>> > As a practical matter, I generally *do* expect them to be compatible
>> > at some level. RHEL is a derivative of Fedora. Otherwise it gets very
>> > difficult to use commercial software on a Fedora system. I know plenty
>> > of ISVs that have a similar expectation.
>>
>> That compatibility degrades over time though.  At this point in time,
>> with RHEL 7 being almost 9 years old, I would not expect software
>> built on RHEL 7 to work on any supported Fedora version.  If it does
>> work, that's fantastic and a testament to Fedora, but people should
>> not have that expectation.  Terry is politely asking for a policy that
>> would set that expectation.  I think the intention is good, but I
>> don't believe it to be realistic.
>>
>
> I think he would be happy with the policy spelled out in any form. Something 
> like:
>
> While the Fedora Project is the upstream of CentOS Stream and Red Hat 
> Enterprise Linux, it does not give any guarantees of its releases being 
> compatible with either. Software built in either may not work due to missing 
> dependencies, changes in kernel, compile time or library options, or similar 
> issues.

Ah!  Yes, making that clear would be good.

josh

>> To perhaps illustrate the point further, Red Hat Enterprise Linux does
>> not support applications built on version X-1 running on X unless it
>> is constrained to using a very very small set of dependencies (glibc,
>> libgcc/libstdc++, and a few smaller libraries).  Again, it may work
>> fine but the expectation and support policies set for RHEL are
>> (simplified) build on X, run on X where X is within a major version.
>> Our full documentation on this is available in the Application
>> Compatibility Guides.
>>
>> josh
>> ___
>> 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, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:

> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
> >
> > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer 
> wrote:
> > >
> > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby 
> wrote:
> > > >
> > > > On 05/12/2022 16:00, Jarek Prokop wrote:
> > > >
> > > >
> > > > On 12/5/22 14:57, Peter Robinson wrote:
> > > >
> > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> > > >  wrote:
>
> > > I wouldn't expect them to build for a Fedora version.  I also wouldn't
> > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> > > work on Fedora either.
> > >
> >
> > As a practical matter, I generally *do* expect them to be compatible
> > at some level. RHEL is a derivative of Fedora. Otherwise it gets very
> > difficult to use commercial software on a Fedora system. I know plenty
> > of ISVs that have a similar expectation.
>
> That compatibility degrades over time though.  At this point in time,
> with RHEL 7 being almost 9 years old, I would not expect software
> built on RHEL 7 to work on any supported Fedora version.  If it does
> work, that's fantastic and a testament to Fedora, but people should
> not have that expectation.  Terry is politely asking for a policy that
> would set that expectation.  I think the intention is good, but I
> don't believe it to be realistic.
>
>
I think he would be happy with the policy spelled out in any form.
Something like:

While the Fedora Project is the upstream of CentOS Stream and Red Hat
Enterprise Linux, it does not give any guarantees of its releases being
compatible with either. Software built in either may not work due to
missing dependencies, changes in kernel, compile time or library options,
or similar issues.



> To perhaps illustrate the point further, Red Hat Enterprise Linux does
> not support applications built on version X-1 running on X unless it
> is constrained to using a very very small set of dependencies (glibc,
> libgcc/libstdc++, and a few smaller libraries).  Again, it may work
> fine but the expectation and support policies set for RHEL are
> (simplified) build on X, run on X where X is within a major version.
> Our full documentation on this is available in the Application
> Compatibility Guides.
>
> josh
> ___
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Vít Ondruch]

Dne 06. 12. 22 v 17:09 Terry Barnaby napsal(a):

On 06/12/2022 15:56, Vít Ondruch wrote:


Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be 
depreciated,

or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.
Well, that is still *some* work and someone would have to do it. 
Are you

volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long 
as you

need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did 
was re-introduce the bits to the SPEC file that removed the building 
of the compat lib and we are fine. I haven't separated it out from 
the main ncurses SPEC through and have only done this locally as I 
have no knowledge of the hoops to create a separate package and that 
seems like the wrong way to do this in general. I have made this 
available to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the 
OS is likely to support. If the policy is to just support Fedora 
built binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide 
no degree of compatibility so be it, but it would be useful for 
everyone to know where the land lies and be on the same page. The 
maintainer of the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And 
I wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be 
enforced unless there is somebody to pickup the work. So in this 
case, it should be enough to convince the maintainer to revert the 
changes, shouldn't be?



Vít




Sorry, what claim ?



My question was specifically about the last sentence of the quote, e.g. 
do you have any link to BZ ticket, ML or anywhere else where this was 
discussed? That would help to get complete picture.





I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something 
that is fine. And obviously a Policy may not be enforced, but at least 
it would be a guideline. I understand the maintainer asked a question 
on when to depreciate on this list, but had no replies.



Ah, so there was ML thread you are referring to. Is it this one?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV/#Z3U6CAM4YVI2Y62QNQIHHHLPD7QEXBBV

And this could also provide more context:

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


He took it that if the compat libs were not in use by any Fedora 
packages for the release in question it should/could be depreciated 
which is one approach.



It seems that Miroslav would consider the change if there was such 
guidelines.


So do you have any specific gudelines draft?

I think this is always the same, if you really want Fedora to do 
something, then it might need to take some action. Sometimes is enough 
to open ticket or send email, other times it means to maintain package 
or draft specific proposal for guidelines. You can even join the Fedora 
governing bodies if you think it will help.


But I still think the best option for you and for the whole Fedora 
community would be if you picked up the compat-ncurses package maintenance.



Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
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, report it: 

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>
> On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:
> >
> > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
> > >
> > > On 05/12/2022 16:00, Jarek Prokop wrote:
> > >
> > >
> > > On 12/5/22 14:57, Peter Robinson wrote:
> > >
> > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> > >  wrote:
> > >
> > > On 05/12/2022 12:39, Terry Barnaby wrote:
> > >
> > > I am wondering what Fedora's policy is on depreciated old shared
> > > libraries and particularly compat RPM's ?
> > >
> > > Fedora is a bleeding edge distribution. If you need old versions, you
> > > should try CentOS or RHEL.
> > >
> > > Being leading edge doesn't mean those usecases aren't relevant, one is
> > > not mutually exclusive to the other, especially when it comes to
> > > things like FPGAs etc.
> > >
> > > We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> > > gnome-boxes, and probably others I forgot).
> > > There shouldn't be a problem spinning up a graphical environment of 
> > > CentOS 7, getting EPEL and then using the tool.
> > >
> > > Maybe the tool would work using the `toolbox` utility using last known 
> > > good Fedora version for the tool.
> > > That is just my wild guess however.
> > >
> > > This is sometimes the tax for being "too" modern.
> > > If the vendor does not want to support Fedora, we can't be held 
> > > accountable to fully support their solution.
> > > Does the software work? Yes? That is great! If not, well… we can't do 
> > > much without the source code under nice FOSS license, can we.
> > >
> > > Regards,
> > > Jarek
> > >
> > > Although yes, there are things like VM's, containers etc. which we use 
> > > for old development environments all of these are, IMO, clumsy and 
> > > awkward to use and difficult to manage especially within automated build 
> > > environments that build the complete code for an embedded system with 
> > > various CPU's, FPGA's, other tools etc.
> > >
> > > I know Fedora is fairly bleeding edge (really too bleeding edge for our 
> > > uses, but others are too far behind), but there is obviously going to be 
> > > a balance here so that Fedora is still useful to as many people as 
> > > reasonably possible, hence the question on a policy.
> > >
> > > In the particular case I am talking about, libncurses*5.so, this is a 
> > > fairly common shared library used by quite a few command line tools. A 
> > > lot of external/commercial programs are built on/for Redhat7 as it is a 
> > > de-facto base Linux platform and programs built on it will likely work on 
> > > many other Linux systems. These companies are not going to build for a 
> > > version of Fedora, it changes far to fast and would require large amounts 
> > > or development/support work because of this. Some of the tools I am using 
> > > were built/shipped in Feburary 2022, so we are not talking about old 
> > > tools here.
> >
> > I wouldn't expect them to build for a Fedora version.  I also wouldn't
> > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> > work on Fedora either.
> >
>
> As a practical matter, I generally *do* expect them to be compatible
> at some level. RHEL is a derivative of Fedora. Otherwise it gets very
> difficult to use commercial software on a Fedora system. I know plenty
> of ISVs that have a similar expectation.

That compatibility degrades over time though.  At this point in time,
with RHEL 7 being almost 9 years old, I would not expect software
built on RHEL 7 to work on any supported Fedora version.  If it does
work, that's fantastic and a testament to Fedora, but people should
not have that expectation.  Terry is politely asking for a policy that
would set that expectation.  I think the intention is good, but I
don't believe it to be realistic.

To perhaps illustrate the point further, Red Hat Enterprise Linux does
not support applications built on version X-1 running on X unless it
is constrained to using a very very small set of dependencies (glibc,
libgcc/libstdc++, and a few smaller libraries).  Again, it may work
fine but the expectation and support policies set for RHEL are
(simplified) build on X, run on X where X is within a major version.
Our full documentation on this is available in the Application
Compatibility Guides.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Kevin Kofler via devel]

Terry Barnaby wrote:
> Well in this case I have created a suitable compat lib, all I did was
> re-introduce the bits to the SPEC file that removed the building of the
> compat lib and we are fine. I haven't separated it out from the main
> ncurses SPEC through and have only done this locally as I have no
> knowledge of the hoops to create a separate package and that seems like
> the wrong way to do this in general. I have made this available to
> others who will be in the same boat.

Typically, compatibility libraries should not be subpackages of the main 
library. But ncurses is a bit peculiar in that, as I understand it, the 
latest code can still be built with the old ABI. So in that case, it at 
least makes sense to build both from the same SRPM. But only if they are 
going to be maintained by the same maintainer(s), i.e., you should probably 
sign up as a comaintainer for ncurses in Fedora if you want to do it that 
way. And of course only as long as upstream continues supporting building 
for the old ABI. If they drop support, then a separate compatibility package 
with an old version that supports the old ABI will be needed.

Kevin Kofler
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Michael Cronenworth]

On 12/5/22 5:39 AM, Terry Barnaby wrote:
With the latest release of Fedora37 we were hit with an issue where the 
ncurses-compat-libs RPM had been depreciated. Due to this some of the tools we use 
would no longer install from their respective RPM's or their tar based installs 
would not run as they needed the libncurses*5.so shared libraries.


If anyone has a support contact with the following hardware vendors could you tell 
them this?


- Canon
   Their 'ufr2' driver for CUPS depends on ncurses-compat-libs. They push updated 
versions as of February 2022 that still depend on it.


- Western Digital / HGST
   Their 'hugo' tool depends on libtinfo.so.5 and the tool is currently maintained 
and shipped to customers today. The latest version I have from 2021 still depends on it.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Neal Gompa]

On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:
>
> On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
> >
> > On 05/12/2022 16:00, Jarek Prokop wrote:
> >
> >
> > On 12/5/22 14:57, Peter Robinson wrote:
> >
> > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> >  wrote:
> >
> > On 05/12/2022 12:39, Terry Barnaby wrote:
> >
> > I am wondering what Fedora's policy is on depreciated old shared
> > libraries and particularly compat RPM's ?
> >
> > Fedora is a bleeding edge distribution. If you need old versions, you
> > should try CentOS or RHEL.
> >
> > Being leading edge doesn't mean those usecases aren't relevant, one is
> > not mutually exclusive to the other, especially when it comes to
> > things like FPGAs etc.
> >
> > We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> > gnome-boxes, and probably others I forgot).
> > There shouldn't be a problem spinning up a graphical environment of CentOS 
> > 7, getting EPEL and then using the tool.
> >
> > Maybe the tool would work using the `toolbox` utility using last known good 
> > Fedora version for the tool.
> > That is just my wild guess however.
> >
> > This is sometimes the tax for being "too" modern.
> > If the vendor does not want to support Fedora, we can't be held accountable 
> > to fully support their solution.
> > Does the software work? Yes? That is great! If not, well… we can't do much 
> > without the source code under nice FOSS license, can we.
> >
> > Regards,
> > Jarek
> >
> > Although yes, there are things like VM's, containers etc. which we use for 
> > old development environments all of these are, IMO, clumsy and awkward to 
> > use and difficult to manage especially within automated build environments 
> > that build the complete code for an embedded system with various CPU's, 
> > FPGA's, other tools etc.
> >
> > I know Fedora is fairly bleeding edge (really too bleeding edge for our 
> > uses, but others are too far behind), but there is obviously going to be a 
> > balance here so that Fedora is still useful to as many people as reasonably 
> > possible, hence the question on a policy.
> >
> > In the particular case I am talking about, libncurses*5.so, this is a 
> > fairly common shared library used by quite a few command line tools. A lot 
> > of external/commercial programs are built on/for Redhat7 as it is a 
> > de-facto base Linux platform and programs built on it will likely work on 
> > many other Linux systems. These companies are not going to build for a 
> > version of Fedora, it changes far to fast and would require large amounts 
> > or development/support work because of this. Some of the tools I am using 
> > were built/shipped in Feburary 2022, so we are not talking about old tools 
> > here.
>
> I wouldn't expect them to build for a Fedora version.  I also wouldn't
> expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> work on Fedora either.
>

As a practical matter, I generally *do* expect them to be compatible
at some level. RHEL is a derivative of Fedora. Otherwise it gets very
difficult to use commercial software on a Fedora system. I know plenty
of ISVs that have a similar expectation.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Ewoud Kohl van Wijngaarden]

On Tue, Dec 06, 2022 at 03:44:37PM +, Terry Barnaby wrote:

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide no 
degree of compatibility so be it, but it would be useful for everyone 
to know where the land lies and be on the same page. The maintainer of 
the ncurses package wasn't sure of the policy on this. In my case, a 
lack of being able to easily run particular external/commercial 
programs built for Redhat7 will likely move me further away from 
working with Fedora (using, reporting bugs, promoting it etc.) as it 
will be a less useful system for our usage.


I'm not in charge of policy, but I always assumed it was based on 
technical possibilities (within reason) and people wanting to invest 
time in it.


Open source is for me all based on fixing your own issues and doing it 
in such a way that it others can benefit from it too. If you have a use 
case for something and are willing to spend the time to keep it alive 
while not limiting others, Fedora can support it.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 06/12/2022 15:56, Vít Ondruch wrote:


Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.
Well, that is still *some* work and someone would have to do it. Are 
you

volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as 
you

need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have 
no knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide 
no degree of compatibility so be it, but it would be useful for 
everyone to know where the land lies and be on the same page. The 
maintainer of the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And 
I wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be 
enforced unless there is somebody to pickup the work. So in this case, 
it should be enough to convince the maintainer to revert the changes, 
shouldn't be?



Vít




Sorry, what claim ?

I have no issue with the maintainer in this particular instance, as 
people have said if a maintainer doesn't want to support something that 
is fine. And obviously a Policy may not be enforced, but at least it 
would be a guideline. I understand the maintainer asked a question on 
when to depreciate on this list, but had no replies. He took it that if 
the compat libs were not in use by any Fedora packages for the release 
in question it should/could be depreciated which is one approach.


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

Re: Policy on supporting old and external software packages and compat RPMS

[Vít Ondruch]

Dne 06. 12. 22 v 16:44 Terry Barnaby napsal(a):

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of 
the compat lib and we are fine. I haven't separated it out from the 
main ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems 
like the wrong way to do this in general. I have made this available 
to others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS 
is likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore 
external and commercial binaries built with say Redhat7 and provide no 
degree of compatibility so be it, but it would be useful for everyone 
to know where the land lies and be on the same page. The maintainer of 
the ncurses package wasn't sure of the policy on this.



I wonder what is this claim based upon? Could you provide a link? And I 
wonder if there was such policy, would the maintainer changed their 
mind? I am asking because I don't think that any policy can be enforced 
unless there is somebody to pickup the work. So in this case, it should 
be enough to convince the maintainer to revert the changes, shouldn't be?



Vít


In my case, a lack of being able to easily run particular 
external/commercial programs built for Redhat7 will likely move me 
further away from working with Fedora (using, reporting bugs, 
promoting it etc.) as it will be a less useful system for our usage.

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


OpenPGP_signature
Description: OpenPGP digital signature
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 06/12/2022 10:40, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]

My view is that compat versions of the commonly used shared libraries
for programs that are used on Redhat7 should be kept available until
most people are not producing programs for that system at least
+nyears and then I guess Redhat8 once that really becomes a core base
platform that external people use. A core list of these (there are
only a few) could be kept somewhere and when one is to be depreciated,
or users see problems when Fedora is updated,  a decision on this can
be then made with that info. This would keep the Fedora system
relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?


In the case of ncurses, it is really just putting back into the SPEC
file that which was removed for F37 plus the extra storage on mirrors
for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik


Well in this case I have created a suitable compat lib, all I did was 
re-introduce the bits to the SPEC file that removed the building of the 
compat lib and we are fine. I haven't separated it out from the main 
ncurses SPEC through and have only done this locally as I have no 
knowledge of the hoops to create a separate package and that seems like 
the wrong way to do this in general. I have made this available to 
others who will be in the same boat.


But the purpose of my thread here is a more general Fedora policy 
question as it affects users of Fedora as to what applications the OS is 
likely to support. If the policy is to just support Fedora built 
binaries within the particular version of Fedora and to ignore external 
and commercial binaries built with say Redhat7 and provide no degree of 
compatibility so be it, but it would be useful for everyone to know 
where the land lies and be on the same page. The maintainer of the 
ncurses package wasn't sure of the policy on this. In my case, a lack of 
being able to easily run particular external/commercial programs built 
for Redhat7 will likely move me further away from working with Fedora 
(using, reporting bugs, promoting it etc.) as it will be a less useful 
system for our usage.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>
> On 05/12/2022 16:00, Jarek Prokop wrote:
>
>
> On 12/5/22 14:57, Peter Robinson wrote:
>
> On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>  wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
>
> I am wondering what Fedora's policy is on depreciated old shared
> libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.
>
> Being leading edge doesn't mean those usecases aren't relevant, one is
> not mutually exclusive to the other, especially when it comes to
> things like FPGAs etc.
>
> We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> gnome-boxes, and probably others I forgot).
> There shouldn't be a problem spinning up a graphical environment of CentOS 7, 
> getting EPEL and then using the tool.
>
> Maybe the tool would work using the `toolbox` utility using last known good 
> Fedora version for the tool.
> That is just my wild guess however.
>
> This is sometimes the tax for being "too" modern.
> If the vendor does not want to support Fedora, we can't be held accountable 
> to fully support their solution.
> Does the software work? Yes? That is great! If not, well… we can't do much 
> without the source code under nice FOSS license, can we.
>
> Regards,
> Jarek
>
> Although yes, there are things like VM's, containers etc. which we use for 
> old development environments all of these are, IMO, clumsy and awkward to use 
> and difficult to manage especially within automated build environments that 
> build the complete code for an embedded system with various CPU's, FPGA's, 
> other tools etc.
>
> I know Fedora is fairly bleeding edge (really too bleeding edge for our uses, 
> but others are too far behind), but there is obviously going to be a balance 
> here so that Fedora is still useful to as many people as reasonably possible, 
> hence the question on a policy.
>
> In the particular case I am talking about, libncurses*5.so, this is a fairly 
> common shared library used by quite a few command line tools. A lot of 
> external/commercial programs are built on/for Redhat7 as it is a de-facto 
> base Linux platform and programs built on it will likely work on many other 
> Linux systems. These companies are not going to build for a version of 
> Fedora, it changes far to fast and would require large amounts or 
> development/support work because of this. Some of the tools I am using were 
> built/shipped in Feburary 2022, so we are not talking about old tools here.

I wouldn't expect them to build for a Fedora version.  I also wouldn't
expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
work on Fedora either.

> My view is that compat versions of the commonly used shared libraries for 
> programs that are used on Redhat7 should be kept available until most people 
> are not producing programs for that system at least +nyears and then I guess 
> Redhat8 once that really becomes a core base platform that external people 
> use. A core list of these (there are only a few) could be kept somewhere and 
> when one is to be depreciated, or users see problems when Fedora is updated,  
> a decision on this can be then made with that info. This would keep the 
> Fedora system relevant for more users needs without too much work. In the 
> case of ncurses, it is really just putting back into the SPEC file that which 
> was removed for F37 plus the extra storage on mirrors for the compat RPM's.

As a data point, Red Hat Enterprise Linux 9 does not provide
ncurses-compat-libs.  If you can, it would be good to ask your ISVs to
provide a timeline when they will migrate off of a very old version of
ncurses.

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

Re: Policy on supporting old and external software packages and compat RPMS

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 06 December 2022 at 07:43, Terry Barnaby wrote:
[...]
> My view is that compat versions of the commonly used shared libraries
> for programs that are used on Redhat7 should be kept available until
> most people are not producing programs for that system at least
> +nyears and then I guess Redhat8 once that really becomes a core base
> platform that external people use. A core list of these (there are
> only a few) could be kept somewhere and when one is to be depreciated,
> or users see problems when Fedora is updated,  a decision on this can
> be then made with that info. This would keep the Fedora system
> relevant for more users needs without too much work.

Well, that is still *some* work and someone would have to do it. Are you
volunteering?

> In the case of ncurses, it is really just putting back into the SPEC
> file that which was removed for F37 plus the extra storage on mirrors
> for the compat RPM's.

If it's "just" that, why don't you do it yourself? Obviously, the
current ncurses maintainer decided it was time to drop the old v5 ABI
compat libs from the package. However, nothing is stopping you from
picking that up and maintaining an "ncurses5" package for as long as you
need it.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

On 05/12/2022 16:00, Jarek Prokop wrote:



On 12/5/22 14:57, Peter Robinson wrote:

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
  wrote:

On 05/12/2022 12:39, Terry Barnaby wrote:

I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly compat RPM's ?

Fedora is a bleeding edge distribution. If you need old versions, you
should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
gnome-boxes, and probably others I forgot).
There shouldn't be a problem spinning up a graphical environment of 
CentOS 7, getting EPEL and then using the tool.


Maybe the tool would work using the `toolbox` utility using last known 
good Fedora version for the tool.

That is just my wild guess however.

This is sometimes the tax for being "too" modern.
If the vendor does not want to support Fedora, we can't be held 
accountable to fully support their solution.
Does the software work? Yes? That is great! If not, well… we can't do 
much without the source code under nice FOSS license, can we.


Regards,
Jarek

Although yes, there are things like VM's, containers etc. which we use 
for old development environments all of these are, IMO, clumsy and 
awkward to use and difficult to manage especially within automated build 
environments that build the complete code for an embedded system with 
various CPU's, FPGA's, other tools etc.


I know Fedora is fairly bleeding edge (really too bleeding edge for our 
uses, but others are too far behind), but there is obviously going to be 
a balance here so that Fedora is still useful to as many people as 
reasonably possible, hence the question on a policy.


In the particular case I am talking about, libncurses*5.so, this is a 
fairly common shared library used by quite a few command line tools. A 
lot of external/commercial programs are built on/for Redhat7 as it is a 
de-facto base Linux platform and programs built on it will likely work 
on many other Linux systems. These companies are not going to build for 
a version of Fedora, it changes far to fast and would require large 
amounts or development/support work because of this. Some of the tools I 
am using were built/shipped in Feburary 2022, so we are not talking 
about old tools here.


My view is that compat versions of the commonly used shared libraries 
for programs that are used on Redhat7 should be kept available until 
most people are not producing programs for that system at least +nyears 
and then I guess Redhat8 once that really becomes a core base platform 
that external people use. A core list of these (there are only a few) 
could be kept somewhere and when one is to be depreciated, or users see 
problems when Fedora is updated,  a decision on this can be then made 
with that info. This would keep the Fedora system relevant for more 
users needs without too much work. In the case of ncurses, it is really 
just putting back into the SPEC file that which was removed for F37 plus 
the extra storage on mirrors for the compat RPM's.





___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.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, report 
it:https://pagure.io/fedora-infrastructure/new_issue


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

Re: Policy on supporting old and external software packages and compat RPMS

[Kevin Kofler via devel]

Vitaly Zaitsev via devel wrote:

> On 05/12/2022 12:39, Terry Barnaby wrote:
>> I am wondering what Fedora's policy is on depreciated old shared
>> libraries and particularly compat RPM's ?
> 
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Or you can just build the compat package you need in a Copr, see, e.g.:
https://copr.fedorainfracloud.org/coprs/kkofler/compat-libgfortran-48/
(which I do not really use anymore, but I have kept the Copr up in case it 
is useful for other people).

Kevin Kofler
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Jarek Prokop]

On 12/5/22 14:57, Peter Robinson wrote:

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
  wrote:

On 05/12/2022 12:39, Terry Barnaby wrote:

I am wondering what Fedora's policy is on depreciated old shared
libraries and particularly compat RPM's ?

Fedora is a bleeding edge distribution. If you need old versions, you
should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
gnome-boxes, and probably others I forgot).
There shouldn't be a problem spinning up a graphical environment of 
CentOS 7, getting EPEL and then using the tool.


Maybe the tool would work using the `toolbox` utility using last known 
good Fedora version for the tool.

That is just my wild guess however.

This is sometimes the tax for being "too" modern.
If the vendor does not want to support Fedora, we can't be held 
accountable to fully support their solution.
Does the software work? Yes? That is great! If not, well… we can't do 
much without the source code under nice FOSS license, can we.


Regards,
Jarek
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 08:56, Florian Weimer  wrote:

> * Stephen Smoogen:
>
> > Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
> > weeks. Getting code to compile for it on newer OS's is harder and
> > packagers volunteer time is limited.
>
> For official information on support life-cycles, please consider this
> official resource:
>
>   Red Hat Enterprise Linux Life Cycle
>   
>
> In particular the “Life-cycle Dates” page.
>
>
I was going from

Maintenance SupportRed Hat Enterprise Linux
VersionGeneral availabilityFull support endsMaintenance Support 1
endsMaintenance
Support or Maintenance Support 2 endsExtended life cycle support (ELS)
add-on endsExtended life phase endsFinal minor release
7 June 10, 2014 August 6, 2019 August 6, 2020 June 30, 2024 June 30, 2026
Ongoing 7.9

While there is ELS going to 2026, that is an additional contract outside of
general service.


> Thanks,
> Florian
>
>

-- 
Stephen Smoogen, Red Hat Automotive
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Peter Robinson]

On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
 wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
> > I am wondering what Fedora's policy is on depreciated old shared
> > libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.

Being leading edge doesn't mean those usecases aren't relevant, one is
not mutually exclusive to the other, especially when it comes to
things like FPGAs etc.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Florian Weimer]

* Stephen Smoogen:

> Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29
> weeks. Getting code to compile for it on newer OS's is harder and
> packagers volunteer time is limited.

For official information on support life-cycles, please consider this
official resource:

  Red Hat Enterprise Linux Life Cycle
  

In particular the “Life-cycle Dates” page.

Thanks,
Florian
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Vitaly Zaitsev via devel]

On 05/12/2022 12:39, Terry Barnaby wrote:
I am wondering what Fedora's policy is on depreciated old shared 
libraries and particularly compat RPM's ?


Fedora is a bleeding edge distribution. If you need old versions, you 
should try CentOS or RHEL.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Stephen Smoogen]

On Mon, 5 Dec 2022 at 06:45, Terry Barnaby  wrote:

> Hi,
>
> With the latest release of Fedora37 we were hit with an issue where the 
> ncurses-compat-libs
> RPM had been depreciated. Due to this some of the tools we use would no
> longer install from their respective RPM's or their tar based installs
> would not run as they needed the libncurses*5.so shared libraries.
>
> We use a number of software packages for Electronics and Software
> development, some of which are developed by organisations and companies
> outside of Fedora. This includes things like ARM GCC compilers, FPGA
> compilers, PCB tools, manufacturers utilities etc. Many of these are built
> for Redhat7, being a good general and stable base Linux system for these
> companies/organisations to target. There are a few shared libraries that
> are commonly used and ncurses is one of these.
>
> I am wondering what Fedora's policy is on depreciated old shared libraries
> and particularly compat RPM's ?
>
>
The policy is that if there are packagers who are actively going to be able
to maintain the code, AND the code can be built with the current tools in
the build system, it is kept. If the packagers want it but the code can't
be built, then it is removed. If the packagers don't want it but the code
could still be built, it is still removed.

Sometimes the packager isn't willing anymore because they don't need it
anymore in their work. Other times it is because they asked on a list and
no one answered. Or a dozen other reasons.

Red Hat Enterprise Linux 7 is reaching its EOL in 1 year and 29 weeks.
Getting code to compile for it on newer OS's is harder and packagers
volunteer time is limited.



> If there isn't one, for the benefit of users and making Fedora OS more
> generally useful, can I suggest that relatively often used compat RPMS are
> kept available at least while a major base system such as Redhat7 is still
> widely used as a build platform for external companies/organisations and/or
> perhaps for at least 15? years (or some defined time) after they become
> compat RPM's ?
>
> Terry
> ___
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Policy on supporting old and external software packages and compat RPMS

[Terry Barnaby]

Hi,

With the latest release of Fedora37 we were hit with an issue where the 
ncurses-compat-libs RPM had been depreciated. Due to this some of the 
tools we use would no longer install from their respective RPM's or 
their tar based installs would not run as they needed the 
libncurses*5.so shared libraries.


We use a number of software packages for Electronics and Software 
development, some of which are developed by organisations and companies 
outside of Fedora. This includes things like ARM GCC compilers, FPGA 
compilers, PCB tools, manufacturers utilities etc. Many of these are 
built for Redhat7, being a good general and stable base Linux system for 
these companies/organisations to target. There are a few shared 
libraries that are commonly used and ncurses is one of these.


I am wondering what Fedora's policy is on depreciated old shared 
libraries and particularly compat RPM's ?


If there isn't one, for the benefit of users and making Fedora OS more 
generally useful, can I suggest that relatively often used compat RPMS 
are kept available at least while a major base system such as Redhat7 is 
still widely used as a build platform for external 
companies/organisations and/or perhaps for at least 15? years (or some 
defined time) after they become compat RPM's ?


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