Fedora 31 Beta Release Announcement

[Mohan Boddu]

Fedora 31 Beta Released
----------------------------------

We're excited to announce the release of Fedora 31 Beta.

A short list of highlights:

* GNOME 3.34 (As part of updates)

* Farewell to bootable i686

* AArch64 Xfce Desktop image

* And more...

For more details about the release, read the full announcement at

* https://fedoramagazine.org/announcing-the-release-of-fedora-31-beta/

or look for the prerelease pages in the download sections at

* https://getfedora.org/

Since this is a Beta release, we expect that you may encounter bugs or
missing features. To report issues encountered during testing, contact the
Fedora QA team via the mailing list or in #fedora-qa on Freenode.

Regards,
Mohan Boddu
Fedora Release Engineering.

_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[sixpack13]

just upgraded from F30 to F31 Beta *WITHOUT* any errors !

neat !

thanks Fedora People !!!

[John M. Harris, Jr.]

What architecture are you running?

On September 17, 2019 8:19:03 PM UTC,   sixpack13 <sixpack13(a)online.de&gt; wrote:
> just upgraded from F30 to F31 Beta *WITHOUT* any errors !
>
> neat !
>
> thanks Fedora People !!!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[sixpack13]

x86_64

[John M. Harris, Jr.]

I have 14 systems that failed to update to F31 (predictably so). These are x86 systems,
which previously had no major issues. I have reverted to a previous snapshot using a
recovery disk.

On September 17, 2019 2:04:37 PM UTC, Mohan Boddu <mboddu(a)bhujji.com&gt; wrote:
> Fedora 31 Beta Released
> ----------------------------------
>
> We're excited to announce the release of Fedora 31 Beta.
>
> A short list of highlights:
>
> * GNOME 3.34 (As part of updates)
>
> * Farewell to bootable i686
>
> * AArch64 Xfce Desktop image
>
> * And more...
>
> For more details about the release, read the full announcement at
>
> * https://fedoramagazine.org/announcing-the-release-of-fedora-31-beta/
>
> or look for the prerelease pages in the download sections at
>
> * https://getfedora.org/
>
> Since this is a Beta release, we expect that you may encounter bugs or
> missing features. To report issues encountered during testing, contact
> the
> Fedora QA team via the mailing list or in #fedora-qa on Freenode.
>
> Regards,
> Mohan Boddu
> Fedora Release Engineering. 
-- 
Sent from my mobile device. Please excuse my brevity.

[Samuel Sieb]

On 9/17/19 1:48 PM, John M. Harris, Jr. wrote:
>  I have 14 systems that failed to update to F31 (predictably so).
> These 
>  are x86 systems, which previously had no major issues. I have reverted 
>  to a previous snapshot using a recovery disk. 
Predictably?  Do you have more details than that?  Or by x86 are you 
meaning 32-bit?

[John M. Harris, Jr.]

I do mean 32 bit. Contrary to what is published in the Magazine article, x86 systems are
still produced to this day, and are not unpopular. I have 14 of such systems, 4 produced
within the last year.

On September 17, 2019 8:50:23 PM UTC, Samuel Sieb <samuel(a)sieb.net&gt; wrote:
> On 9/17/19 1:48 PM, John M. Harris, Jr. wrote:
> > I have 14 systems that failed to update to F31 (predictably so).
> These 
> > are x86 systems, which previously had no major issues. I have
> reverted 
> > to a previous snapshot using a recovery disk.
>
> Predictably?  Do you have more details than that?  Or by x86 are you 
> meaning 32-bit?
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Samuel Sieb]

On 9/17/19 1:52 PM, John M. Harris, Jr. wrote:
>  I do mean 32 bit. Contrary to what is published in the Magazine
> article, 
>  x86 systems are still produced to this day, and are not unpopular. I 
>  have 14 of such systems, 4 produced within the last year. 
Do you have a link to one of those?  What do you use them for?

[Stephen John Smoogen]

On Tue, 17 Sep 2019 at 16:53, John M. Harris, Jr. <johnmh(a)splentity.com&gt; wrote:
>  I do mean 32 bit. Contrary to what is published in the Magazine article, x86 systems are
> still produced to this day, and are not unpopular. I have 14 of such systems, 4 produced
> within the last year.
>  
Popularity is a loaded word which can mean whatever one wants
depending on the situation. I say this because it has gotten bandied
about on both sides of this debate for the last year. I really tried
to find an x86_32 box from Dell, Lenovo or other vendors today and
couldn't find any. That doesn't mean they don't exist.. it just means
that whatever google magic I have failed me. It also doesn't mean that
x86_32 isn't being used in some specific field.. but again most
everything I ran into was all the problems that x86_32 boxes have with
memory limitations etc.. You might have other search results or better
words, but unless we both use them, we are in two different worlds.

When you are saying you have systems can you be specific on what they
are and where you got them. Also what you are using them for. One of
the problems with trying to 'solve' the x86_32 problem is that we have
been trying to solve ALL of it, and it might be better aimed at
pointing at a specific subset and getting the people there to join
together. It probably won't be in Fedora since the goals of the
distribution may not match.

>  On September 17, 2019 8:50:23 PM UTC, Samuel Sieb
> <samuel(a)sieb.net&gt; wrote:
> >
> > On 9/17/19 1:48 PM, John M. Harris, Jr. wrote:
> >>
> >> I have 14 systems that failed to update to F31 (predictably so). These
> >> are x86 systems, which previously had no major issues. I have reverted
> >> to a previous snapshot using a recovery disk.
> >
> >
> > Predictably?  Do you have more details than that?  Or by x86 are you
> > meaning 32-bit?
> > ________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>
>
>  --
>  Sent from my mobile device. Please excuse my brevity.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 


-- 
Stephen J Smoogen.

[John M. Harris, Jr.]

These are generic servers. I can provide a link to the vendor's website when I get
home. It is not Dell, Lenovo or similar, those are currently selling mostly x86_64.
Additionally, many users don't want to buy a new computer just because a software
project made the decision to randomly drop support for their architecture. I am certainly
one of those. The hardware is fine, perfect working condition. I don't understand why
we should simply turn these to e-waste because somebody flipped the proverbial switch.

Also, what issues have you run into with x86 other than issues with the memory limit? Most
of my systems do not have more than 4 GiB of memory to begin with. My laptop is, perhaps,
the only exception among my personal hardware, and that's an X200T from 2009.

On September 17, 2019 9:06:49 PM UTC, Stephen John Smoogen <smooge(a)gmail.com&gt;
wrote:
> On Tue, 17 Sep 2019 at 16:53, John M. Harris, Jr.
> <johnmh(a)splentity.com&gt; wrote:
> >
> > I do mean 32 bit. Contrary to what is published in the Magazine
> article, x86 systems are still produced to this day, and are not
> unpopular. I have 14 of such systems, 4 produced within the last year.
> >
>
> Popularity is a loaded word which can mean whatever one wants
> depending on the situation. I say this because it has gotten bandied
> about on both sides of this debate for the last year. I really tried
> to find an x86_32 box from Dell, Lenovo or other vendors today and
> couldn't find any. That doesn't mean they don't exist.. it just means
> that whatever google magic I have failed me. It also doesn't mean that
> x86_32 isn't being used in some specific field.. but again most
> everything I ran into was all the problems that x86_32 boxes have with
> memory limitations etc.. You might have other search results or better
> words, but unless we both use them, we are in two different worlds.
>
> When you are saying you have systems can you be specific on what they
> are and where you got them. Also what you are using them for. One of
> the problems with trying to 'solve' the x86_32 problem is that we have
> been trying to solve ALL of it, and it might be better aimed at
> pointing at a specific subset and getting the people there to join
> together. It probably won't be in Fedora since the goals of the
> distribution may not match.
>
> > On September 17, 2019 8:50:23 PM UTC, Samuel Sieb <samuel(a)sieb.net&gt;
> wrote:
> >>
> >> On 9/17/19 1:48 PM, John M. Harris, Jr. wrote:
> >>>
> >>> I have 14 systems that failed to update to F31 (predictably so).
> These
> >>> are x86 systems, which previously had no major issues. I have
> reverted
> >>> to a previous snapshot using a recovery disk.
> >>
> >>
> >> Predictably?  Do you have more details than that?  Or by x86 are you
> >> meaning 32-bit?
> >> ________________________________
> >> devel mailing list -- devel(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> >> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> >
> >
> > --
> > Sent from my mobile device. Please excuse my brevity.
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>
>
>
> -- 
> Stephen J Smoogen.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Stephen John Smoogen]

On Tue, 17 Sep 2019 at 17:28, John M. Harris, Jr. <johnmh(a)splentity.com&gt; wrote:
>  These are generic servers. I can provide a link to the vendor's website when I get
> home. It is not Dell, Lenovo or similar, those are currently selling mostly x86_64.
> Additionally, many users don't want to buy a new computer just because a software
> project made the decision to randomly drop support for their architecture. I am certainly
> one of those. The hardware is fine, perfect working condition. I don't understand why
> we should simply turn these to e-waste because somebody flipped the proverbial switch.
>  
1. It wasn't randomly dropped. Many of us put in a lot of effort
trying to keep it from being dropped 2 years ago but also laid out
what would cause it to be dropped if things weren't met. Those things
were :
a. Interested people stepping up to fix problems versus waiting for
fixes from people who wanted to work on other things.
b. Key software being able to continue to compile on i686. if it
doesn't then interested people need to work out fixes/workarounds.
c. Regular meetings and other work that sigs do to keep people
interested and recruit new people when old people want to leave.

C was meant as a 'well if they have people who show up and
meet/talk/bring up things then it can make it clear it is important
enough others will likely help out.' It was probably the lowest thing
to meet and also the least likely to ding them if they didn't do it if
A and B were getting met. What happened was 1-2 people worked really
hard, burned out, and decided they had better things to do. No one
stepped in other than to complain that the 1-2 people didn't work on
something they wanted.

2. You don't have to e-waste the equipment. People who say that are
off-base and using blame/shame to get you to do something different.
On the other hand, most of the requests in the last month for i686
have also come across as trying to blame/shame other people to make
i686 work still. It may not be what people think they are saying, but
that is how it has come across.

The end point is that if Fedora no longer meets your needs, don't use
it... fork it and make Memdora for low memory systems. Find people
with the same problem and work with them even if it is switching to
Debian.

>  Also, what issues have you run into with x86 other than issues with
> the memory limit? Most of my systems do not have more than 4 GiB of memory to begin with.
> My laptop is, perhaps, the only exception among my personal hardware, and that's an
> X200T from 2009. 
A lot of 'modern' applications to compile for i686 require more than 4
Gib to compile. While I can remember fondly that visicalc worked fine
in 32k, lots of modern stack/code assume a 64 bit bus and as things
from openoffice/mozilla/etc use those they no longer work in i686. At
a certain point what is being built on 32bit is not matching the rest
of Fedora and is a special case. As a special case it needs people who
are going to focus on it which the arm group has had but the i686
group did not. [Even then it might just be to block something or to
say that i686 is only going to aim at being for X service which means
that 'broken (aka I like bit bytes, I can not lie)' could just be
excluded. ] That takes having people with the problem to take the
time, organize and make decisions and compromises.


-- 
Stephen J Smoogen.

[John M. Harris, Jr.]

The thing is, i686 still works. The kernel still builds as well, without issue. I have no
idea what the issues that have been mentioned are, and I've kept asking. Nobody has
given me an answer. Nobody has pointed me to an issue, or I'd be working on that in my
free time.

LibreOffice and Firefox both build for i686 without issue. Further, I don't know
software that requires more than 4 GiB of memory to compile.

On September 17, 2019 11:15:56 PM UTC, Stephen John Smoogen <smooge(a)gmail.com&gt;
wrote:
> On Tue, 17 Sep 2019 at 17:28, John M. Harris, Jr.
> <johnmh(a)splentity.com&gt; wrote:
> >
> > These are generic servers. I can provide a link to the vendor's
> website when I get home. It is not Dell, Lenovo or similar, those are
> currently selling mostly x86_64. Additionally, many users don't want to
> buy a new computer just because a software project made the decision to
> randomly drop support for their architecture. I am certainly one of
> those. The hardware is fine, perfect working condition. I don't
> understand why we should simply turn these to e-waste because somebody
> flipped the proverbial switch.
> >
>
> 1. It wasn't randomly dropped. Many of us put in a lot of effort
> trying to keep it from being dropped 2 years ago but also laid out
> what would cause it to be dropped if things weren't met. Those things
> were :
> a. Interested people stepping up to fix problems versus waiting for
> fixes from people who wanted to work on other things.
> b. Key software being able to continue to compile on i686. if it
> doesn't then interested people need to work out fixes/workarounds.
> c. Regular meetings and other work that sigs do to keep people
> interested and recruit new people when old people want to leave.
>
> C was meant as a 'well if they have people who show up and
> meet/talk/bring up things then it can make it clear it is important
> enough others will likely help out.' It was probably the lowest thing
> to meet and also the least likely to ding them if they didn't do it if
> A and B were getting met. What happened was 1-2 people worked really
> hard, burned out, and decided they had better things to do. No one
> stepped in other than to complain that the 1-2 people didn't work on
> something they wanted.
>
> 2. You don't have to e-waste the equipment. People who say that are
> off-base and using blame/shame to get you to do something different.
> On the other hand, most of the requests in the last month for i686
> have also come across as trying to blame/shame other people to make
> i686 work still. It may not be what people think they are saying, but
> that is how it has come across.
>
> The end point is that if Fedora no longer meets your needs, don't use
> it... fork it and make Memdora for low memory systems. Find people
> with the same problem and work with them even if it is switching to
> Debian.
>
> > Also, what issues have you run into with x86 other than issues with
> the memory limit? Most of my systems do not have more than 4 GiB of
> memory to begin with. My laptop is, perhaps, the only exception among
> my personal hardware, and that's an X200T from 2009.
>
> A lot of 'modern' applications to compile for i686 require more than 4
> Gib to compile. While I can remember fondly that visicalc worked fine
> in 32k, lots of modern stack/code assume a 64 bit bus and as things
> from openoffice/mozilla/etc use those they no longer work in i686. At
> a certain point what is being built on 32bit is not matching the rest
> of Fedora and is a special case. As a special case it needs people who
> are going to focus on it which the arm group has had but the i686
> group did not. [Even then it might just be to block something or to
> say that i686 is only going to aim at being for X service which means
> that 'broken (aka I like bit bytes, I can not lie)' could just be
> excluded. ] That takes having people with the problem to take the
> time, organize and make decisions and compromises.
>
>
> -- 
> Stephen J Smoogen.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Alexander Ploumistos]

Hi John,

On Wed, Sep 18, 2019 at 2:02 AM John M. Harris, Jr.
<johnmh(a)splentity.com&gt; wrote:
>  The thing is, i686 still works. The kernel still builds as well, without issue. I have no
> idea what the issues that have been mentioned are, and I've kept asking. Nobody has
> given me an answer. Nobody has pointed me to an issue, or I'd be working on that in my
> free time. 
Here you go:
https://bugzilla.redhat.com/show_bug.cgi?id=1489998
https://bugzilla.redhat.com/show_bug.cgi?id=179258

Though from my own experience, I'm pretty sure that there are plenty
more x86_32 issues that have gone unreported.

While I did not have what I thought would be the required amount of
time to commit to the x86 SIG to be a "full member", I am one of the
handful of people that advocated keeping i686 in Fedora and until last
February I actively tried to at least reproduce the issues reported
and help with debugging. Even back then, it was apparent that we could
only try to maintain a subset of packages in Fedora, since many
upstream developers just could not test their software on i686, or
32-bit hardware lacked capabilities that were common among 64-bit
CPUs, e.g. SSE2. Some developers were adamant that they no longer
cared about 32-bit. The kernel team was already spread thin and they
made it pretty clear that should we decide to keep the x86_32 arch, it
would be up to us to resolve any bugs that came up.

The reality of the matter was that only 2 or 3 people had the skills
to actually provide fixes after a problem was identified and
reproduced. Quite often, bugs were found that were hardware-dependent
and not everyone had access to said buggy hardware. On the x86 mailing
list's page it says:
"We are looking for active participants who can help test and debug
Fedora on x86_32 hardware. From this testing, the project will be
better able to access which 32 bit hardware is still supportable."
Nobody else stepped up in the meantime and some of the comments flying
back and forth these last days are very unfair to the people who
actually did the work to keep the arch working.
As for me, I moved to another country almost two years ago and had to
leave all of my beloved relics behind. I could only take an Atom
netbook with me and debugging stuff on that was no fun - when I could
actually reproduce a bug. Eventually I ran out of time to spare.

Like others suggested, you, Victor V. Shkamerda and others who have
complained about the state of things, you do have options. Just be
realistic about the amount of work required.


>  LibreOffice and Firefox both build for i686 without issue. Further, I
> don't know software that requires more than 4 GiB of memory to compile. 
On my Gentoo workstation I had switched to the LibreOffice (or was it
OpenOffice?) binary around 2011 and to the firefox binary in 2014.
Even back then, I had to increase swap size to accommodate the
compilation needs of packages that were usually dependencies of
packages I cared about.

Best regards,
A.

[Michael Cronenworth]

On 9/17/19 7:01 PM, John M. Harris, Jr. wrote:
>  The thing is, i686 still works. The kernel still builds as well,
> without issue. I 
>  have no idea what the issues that have been mentioned are, and I've kept asking. 
>  Nobody has given me an answer. Nobody has pointed me to an issue, or I'd be 
>  working on that in my free time. 
https://bugzilla.redhat.com/show_bug.cgi?id=1489998

[John M. Harris, Jr.]

Thank you for this link, looks like there's not a lot of issues, and most are closed.

On September 18, 2019 4:59:33 PM UTC, Michael Cronenworth <mike(a)cchtml.com&gt; wrote:
> On 9/17/19 7:01 PM, John M. Harris, Jr. wrote:
> > The thing is, i686 still works. The kernel still builds as well,
> without issue. I 
> > have no idea what the issues that have been mentioned are, and I've
> kept asking. 
> > Nobody has given me an answer. Nobody has pointed me to an issue, or
> I'd be 
> > working on that in my free time.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1489998
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Michael Cronenworth]

On 9/18/19 1:38 PM, John M. Harris, Jr. wrote:
>  Thank you for this link, looks like there's not a lot of issues,
> and most are closed. 
Don't assume closed = fixed. You'll see some of them are closed due to lack of
input 
from the reporter and some are closed due to being reported against EOL versions of 
Fedora.

[Randy Barlow]

On Tue, 2019-09-17 at 19:15 -0400, Stephen John Smoogen wrote:
>  fork it and make Memdora for low memory systems. 
If you make Memdora, then you will also need to think of four values
that start with M:

Mriends
Mreedom
Mirst
Meatures

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 18, 2019 at 10:06:21AM -0400, Randy Barlow wrote:
>  On Tue, 2019-09-17 at 19:15 -0400, Stephen John Smoogen wrote:
>  > fork it and make Memdora for low memory systems.
>  
>  If you make Memdora, then you will also need to think of four values
>  that start with M:
>  
>  Mriends
>  Mreedom
>  Mirst
>  Meatures 
Magic
Mobility
Mirth
Maturity

Zbyszek

[Adam Williamson]

On Tue, 2019-09-17 at 21:27 +0000, John M. Harris, Jr. wrote:
>  
>  Also, what issues have you run into with x86 other than issues with
>  the memory limit? Most of my systems do not have more than 4 GiB of
>  memory to begin with. My laptop is, perhaps, the only exception among
>  my personal hardware, and that's an X200T from 2009. 
Can we please just not do this again?

There was really no point to re-litigating this argument in this
thread. You know Fedora 31 does not provide i686 repositories. We know
you don't like this. This has been discussed, endlessly. You are not
making any points you haven't made five times before. If someone didn't
change their mind after reading them the first five times, they are not
going to change their mind when reading them for a sixth time.

Sometimes people make decisions you disagree with. It happens. No-one
is telling you to throw your computers away. Fedora is telling you it
doesn't intend to continue providing software that can run on those
systems. This is a choice Fedora gets to make. There are *lots* of
computers out there which Fedora doesn't work on.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kevin Kofler]

John M. Harris, Jr. wrote:
>  These are generic servers. I can provide a link to the vendor's
> website
>  when I get home. It is not Dell, Lenovo or similar, those are currently
>  selling mostly x86_64. Additionally, many users don't want to buy a new
>  computer just because a software project made the decision to randomly
>  drop support for their architecture. I am certainly one of those. The
>  hardware is fine, perfect working condition. I don't understand why we
>  should simply turn these to e-waste because somebody flipped the
>  proverbial switch. 
Unfortunately, Fedora has lately become mainly about randomly dropping 
support for things:
* dropping, in short succession, of the i686 kernel, the i686 images, and
  then even the i686 repositories even though there are legitimate use cases
  for them on an x86_64 kernel (e.g., building multilib packages),
* the insane proposal to require AVX2 for x86_64, which has thankfully not
  been implemented so far, but against which we will likely have to fight
  again and again during the next few years,
* the reenforcement of the mass-retirement procedures and the resulting
  aggressive mass-retirement of hundreds of FTBFS or orphaned packages, with
  no regards to why (or even if, in the latter case) they fail to build,
  whether they still work, how essential they are, nor what or how many
  other packages (including essential ones) depend on them,
* the unprecedentedly aggressive removal of Python 2 and anything remotely
  related to it, where useful packages can arbitrarily be vetoed by
  committee (see e.g. https://pagure.io/fesco/issue/2223 ).

All these are moves which are leaving, will leave, or would leave thousands 
of users in the cold when and if they have been, are, will be, or would be 
implemented.

I miss the times when Fedora was still an inclusive project, focused on 
adding things rather than on removing them.

Each time you drop an architecture (e.g. i686), a subset of an architecture 
(e.g. pre-AVX2 x86_64), or one or more packages, you are excluding dozens, 
hundreds, thousands, or even millions of users. Removing things is actively 
harmful to Fedora.

        Kevin Kofler

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 18, 2019 at 11:56:49AM +0200, Kevin Kofler wrote:
>  John M. Harris, Jr. wrote:
>  > These are generic servers. I can provide a link to the vendor's website
>  > when I get home. It is not Dell, Lenovo or similar, those are currently
>  > selling mostly x86_64. Additionally, many users don't want to buy a new
>  > computer just because a software project made the decision to randomly
>  > drop support for their architecture. I am certainly one of those. The
>  > hardware is fine, perfect working condition. I don't understand why we
>  > should simply turn these to e-waste because somebody flipped the
>  > proverbial switch. 
Hi Kevin,

you are not being fair in this assessment. Going point by point:

>  * dropping, in short succession, of the i686 kernel, the i686 images,
> and
>    then even the i686 repositories even though there are legitimate use cases
>    for them on an x86_64 kernel (e.g., building multilib packages), 
So... building multilib packages is still very much supported. You cannot
*run* a pure-i686 environment, but you can 32 bit development.

>  * the insane proposal to require AVX2 for x86_64, which has
> thankfully not
>    been implemented so far, but against which we will likely have to fight
>    again and again during the next few years, 
This proposal was rejected very forcefully. fedora-devel was unanimous
with >100 messages, which I have never seen apart from that once case.
If it get's proposed again, you can expect the same result.

>  * the reenforcement of the mass-retirement procedures and the
> resulting
>    aggressive mass-retirement of hundreds of FTBFS or orphaned packages, with
>    no regards to why (or even if, in the latter case) they fail to build,
>    whether they still work, how essential they are, nor what or how many
>    other packages (including essential ones) depend on them, 
Well, yes. Unmaintained packages are retired. Sorry, but it's either that
or development of new things in Fedora stops, because every change is hamstrung
by uninstallable and unbuildable packages. We just can't have packages with
no maintainers.

Those removals are not quick: FTBFS packages are retired after *months*,
orphaning usually only happens when there are long-standing unresolved bugs.
In most cases, the package is bitrotting for multiple releases before any
removal happens.

>  * the unprecedentedly aggressive removal of Python 2 and anything
> remotely
>    related to it, where useful packages can arbitrarily be vetoed by
>    committee (see e.g. https://pagure.io/fesco/issue/2223 ). 
That's very much unfair. The python team has put an _insane_ amount of
work into telling everyone about the transition, planning all the
steps, filing bugs, retiring leaf packages first, asking for feedback,
fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages
were simply dropped after F32 branching.

So sorry, but you can't expect every obsolete hardware technology and
software stack from previous decade gets to hold everyone else hostage.

Zbyszek

[John M. Harris, Jr.]

These "obsolete" stacks you refer to can easily coexist with newer software, or
newer hardware. They currently do, for example. I really don't understand why there is
so much hostility against anything perceived as being old here.

On September 18, 2019 10:24:31 AM UTC, "Zbigniew Jędrzejewski-Szmek"
<zbyszek(a)in.waw.pl&gt; wrote:
> On Wed, Sep 18, 2019 at 11:56:49AM +0200, Kevin Kofler wrote:
> > John M. Harris, Jr. wrote:
> > > These are generic servers. I can provide a link to the vendor's
> website
> > > when I get home. It is not Dell, Lenovo or similar, those are
> currently
> > > selling mostly x86_64. Additionally, many users don't want to buy a
> new
> > > computer just because a software project made the decision to
> randomly
> > > drop support for their architecture. I am certainly one of those.
> The
> > > hardware is fine, perfect working condition. I don't understand why
> we
> > > should simply turn these to e-waste because somebody flipped the
> > > proverbial switch.
>
> Hi Kevin,
>
> you are not being fair in this assessment. Going point by point:
>
> > * dropping, in short succession, of the i686 kernel, the i686 images,
> and
> >   then even the i686 repositories even though there are legitimate
> use cases
> >   for them on an x86_64 kernel (e.g., building multilib packages),
>
> So... building multilib packages is still very much supported. You
> cannot
> *run* a pure-i686 environment, but you can 32 bit development.
>
> > * the insane proposal to require AVX2 for x86_64, which has
> thankfully not
> >   been implemented so far, but against which we will likely have to
> fight
> >   again and again during the next few years,
>
> This proposal was rejected very forcefully. fedora-devel was unanimous
> with >100 messages, which I have never seen apart from that once case.
> If it get's proposed again, you can expect the same result.
>
> > * the reenforcement of the mass-retirement procedures and the
> resulting
> >   aggressive mass-retirement of hundreds of FTBFS or orphaned
> packages, with
> >   no regards to why (or even if, in the latter case) they fail to
> build,
> >   whether they still work, how essential they are, nor what or how
> many
> >   other packages (including essential ones) depend on them,
>
> Well, yes. Unmaintained packages are retired. Sorry, but it's either
> that
> or development of new things in Fedora stops, because every change is
> hamstrung
> by uninstallable and unbuildable packages. We just can't have packages
> with
> no maintainers.
>
> Those removals are not quick: FTBFS packages are retired after
> *months*,
> orphaning usually only happens when there are long-standing unresolved
> bugs.
> In most cases, the package is bitrotting for multiple releases before
> any
> removal happens.
>
> > * the unprecedentedly aggressive removal of Python 2 and anything
> remotely
> >   related to it, where useful packages can arbitrarily be vetoed by
> >   committee (see e.g. https://pagure.io/fesco/issue/2223 ).
>
> That's very much unfair. The python team has put an _insane_ amount of
> work into telling everyone about the transition, planning all the
> steps, filing bugs, retiring leaf packages first, asking for feedback,
> fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages
> were simply dropped after F32 branching.
>
> So sorry, but you can't expect every obsolete hardware technology and
> software stack from previous decade gets to hold everyone else hostage.
>
> Zbyszek
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Stephen John Smoogen]

On Wed, 18 Sep 2019 at 14:32, John M. Harris, Jr. <johnmh(a)splentity.com&gt; wrote:
>  These "obsolete" stacks you refer to can easily coexist with newer software, or
> newer hardware. They currently do, for example. I really don't understand why there is
> so much hostility against anything perceived as being old here.
>  
Because people have different takes on what 'First' means. To the set
of packagers/developers 'who are hostile' it means working on the
cutting edge to bleeding edge software and not having to spend time on
things which are old. If they wanted to work on older stuff they would
do so in CentOS/RHEL/Debian space.

This really isn't a new thing. We have had some version of this
conversation even back when Fedora was Red Hat Linux and people wanted
to know why Red Hat had dropped something which had worked perfectly
well in 4.2 for some newer thing they didn't want.

This is my last email on this because we have pretty much said
everything once again.


-- 
Stephen J Smoogen.

[Kevin Kofler]

Zbigniew Jędrzejewski-Szmek wrote:
>  So... building multilib packages is still very much supported. You
> cannot
>  *run* a pure-i686 environment, but you can 32 bit development. 
You have to configure a slow, non-mirrored repository for that instead of 
just using the same mirrored URL pattern (with $basearch substituted 
automatically) as for the still fully supported architectures. And there is 
no real technical reason to do that, the only goal was to deliberately 
inconvenience users attempting to use the software.

> > * the insane proposal to require AVX2 for x86_64, which has
> thankfully
> >   not been implemented so far, but against which we will likely have to
> >   fight again and again during the next few years,
>  
>  This proposal was rejected very forcefully. fedora-devel was unanimous
>  with >100 messages, which I have never seen apart from that once case.
>  If it get's proposed again, you can expect the same result. 
I have seen several features with similarly overwhelmingly negative
fedora-devel feedback that were waved through by FESCo anyway. (See, e.g., 
Modularity, where from the beginning, I and others had pointed out the 
provably unsolvable flaws in the core design axioms, which, very 
unsurprisingly, materialized exactly as predicted, see
https://communityblog.fedoraproject.org/modularity-vs-libgit/ . All this did 
not prevent the feature from getting approved and implemented.)

>  Well, yes. Unmaintained packages are retired. Sorry, but it's
> either that
>  or development of new things in Fedora stops, because every change is
>  hamstrung by uninstallable and unbuildable packages. We just can't have
>  packages with no maintainers. 
Most packages with no maintainers actually still just work (without even a 
rebuild). Some require a trivial rebuild. Only a handful are actually 
broken, and those are reasonable candidates for a removal. But removing 
working packages only for the lack of a maintainer serves no purpose and is 
a pure disservice to the users of the package.

There is often no reasonable alternative tool for the purpose. So what are 
the users of the removed package supposed to do?

>  Those removals are not quick: FTBFS packages are retired after
> *months*,
>  orphaning usually only happens when there are long-standing unresolved
>  bugs. In most cases, the package is bitrotting for multiple releases
>  before any removal happens. 
Orphaning usually happens because the maintainer explicitly orphans the 
package. The policies then leave only 6 weeks for the package to get adopted 
before it will get retired! That is not "long-standing" at all.

And if an otherwise maintained package FTBFS, if it does not actually need 
any change, I don't see how this is even an issue at all.

>  That's very much unfair. The python team has put an _insane_
> amount of
>  work into telling everyone about the transition, planning all the
>  steps, filing bugs, retiring leaf packages first, asking for feedback,
>  fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages
>  were simply dropped after F32 branching. 
If only they had instead put such an "_insane_ amount of work" into actually 
maintaining, and committing to maintain for at least 5 to 10 more years, the 
python2 compatibility package, which is actually not work-intensive at all 
(just backport security fixes from Python 3 as they happen, which they'll 
likely have to do for RHEL anyway).

Instead, a lot of time was wasted spamming everyone about the impending 
scorched earth "transition", quickly getting an unreasonable "plan"
with a 
totally insufficient transition period rubber-stamped by FESCo, dropping 
random leaf packages they hoped nobody would notice (when actually, those 
leaf packages are the whole reason we need the compatibility stack to begin 
with; the leaf packages are what the users actually use and need!), ignoring 
all feedback (at least all that did not just blindly agree with their 
nonsense "plan"), "fixing" "bugs" (typically just removing
Python 2 support 
from random packages in the hope nobody would notice), etc., etc., etc.

See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility 
should work.

>  So sorry, but you can't expect every obsolete hardware technology
> and
>  software stack from previous decade gets to hold everyone else hostage. 
Compatibility is not "holding" anyone "hostage". Nobody is forced to
use old 
hardware or compatibility libraries. The unilateral removal of such 
"obsolete" technologies is what is holding users hostage.

        Kevin Kofler

[Neal Gompa]

On Wed, Sep 18, 2019 at 5:25 PM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Zbigniew Jędrzejewski-Szmek wrote:
>  > So... building multilib packages is still very much supported. You cannot
>  > *run* a pure-i686 environment, but you can 32 bit development.
>
>  You have to configure a slow, non-mirrored repository for that instead of
>  just using the same mirrored URL pattern (with $basearch substituted
>  automatically) as for the still fully supported architectures. And there is
>  no real technical reason to do that, the only goal was to deliberately
>  inconvenience users attempting to use the software.
>  
This is true for building locally for i686. You cannot do 32-bit
development with multilib x86_64 content.

>  >> * the insane proposal to require AVX2 for x86_64, which has
> thankfully
>  >>   not been implemented so far, but against which we will likely have to
>  >>   fight again and again during the next few years,
>  >
>  > This proposal was rejected very forcefully. fedora-devel was unanimous
>  > with >100 messages, which I have never seen apart from that once case.
>  > If it get's proposed again, you can expect the same result.
>
>  I have seen several features with similarly overwhelmingly negative
>  fedora-devel feedback that were waved through by FESCo anyway. (See, e.g.,
>  Modularity, where from the beginning, I and others had pointed out the
>  provably unsolvable flaws in the core design axioms, which, very
>  unsurprisingly, materialized exactly as predicted, see
>  https://communityblog.fedoraproject.org/modularity-vs-libgit/ . All this did
>  not prevent the feature from getting approved and implemented.)
>  
The difference was the modularity only managed to make it in
originally by being described as a purely add-on concept. It was
individual packagers that started breaking the world by churning core
packages into modules.

Everyone knew up front that the hardware change was bad and there's no
way to sneak that in without breaking people. It's not going in
anytime soon.

>  > Well, yes. Unmaintained packages are retired. Sorry, but
> it's either that
>  > or development of new things in Fedora stops, because every change is
>  > hamstrung by uninstallable and unbuildable packages. We just can't have
>  > packages with no maintainers.
>
>  Most packages with no maintainers actually still just work (without even a
>  rebuild). Some require a trivial rebuild. Only a handful are actually
>  broken, and those are reasonable candidates for a removal. But removing
>  working packages only for the lack of a maintainer serves no purpose and is
>  a pure disservice to the users of the package.
>
>  There is often no reasonable alternative tool for the purpose. So what are
>  the users of the removed package supposed to do?
>  
Become maintainers of the package? This is sort of the point of the
system. Someone needs to take care of it, and if there's a user, they
can become a maintainer. Ideally, most consumers of the package
(dependency-wise) would consider at least being co-maintainers of
their direct dependencies.

>  > Those removals are not quick: FTBFS packages are retired after
> *months*,
>  > orphaning usually only happens when there are long-standing unresolved
>  > bugs. In most cases, the package is bitrotting for multiple releases
>  > before any removal happens.
>
>  Orphaning usually happens because the maintainer explicitly orphans the
>  package. The policies then leave only 6 weeks for the package to get adopted
>  before it will get retired! That is not "long-standing" at all.
>
>  And if an otherwise maintained package FTBFS, if it does not actually need
>  any change, I don't see how this is even an issue at all.
>  
It appears quick because we've have the FTBFS orphaning process be
broken for three years. There's a lot of breakage to catch up on.

Regular orphanings are happening because for some reason we allow
orphaned packages to be used as inputs for modules, so now we have
this giant mess of dead packages that aren't dead. This is a very
broken policy and should be fixed, but I suspect that it won't be,
because that would force module packages to always have a non-modular
counterpart in the distribution, based on how our tools work.

>  > That's very much unfair. The python team has put an _insane_
> amount of
>  > work into telling everyone about the transition, planning all the
>  > steps, filing bugs, retiring leaf packages first, asking for feedback,
>  > fixing bugs, etc, etc, etc. "Agressive" would be all python2 packages
>  > were simply dropped after F32 branching.
>
>  If only they had instead put such an "_insane_ amount of work" into actually
>  maintaining, and committing to maintain for at least 5 to 10 more years, the
>  python2 compatibility package, which is actually not work-intensive at all
>  (just backport security fixes from Python 3 as they happen, which they'll
>  likely have to do for RHEL anyway).
>
>  Instead, a lot of time was wasted spamming everyone about the impending
>  scorched earth "transition", quickly getting an unreasonable "plan"
> with a
>  totally insufficient transition period rubber-stamped by FESCo, dropping
>  random leaf packages they hoped nobody would notice (when actually, those
>  leaf packages are the whole reason we need the compatibility stack to begin
>  with; the leaf packages are what the users actually use and need!), ignoring
>  all feedback (at least all that did not just blindly agree with their
>  nonsense "plan"), "fixing" "bugs" (typically just removing
> Python 2 support
>  from random packages in the hope nobody would notice), etc., etc., etc.
>
>  See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how compatibility
>  should work.
>  
Those transitions had the benefit of the major consumer (KDE) moving
forward relatively quickly after. Python 2 is not in the same state.
In many cases, Fedora is the driver for packages getting ported to
Python 3, and if we hadn't done it, it likely wouldn't have ever
happened. This is one of the major things I consider valuable about
Fedora. If we don't do it, I do not believe anyone else would.

>  > So sorry, but you can't expect every obsolete hardware
> technology and
>  > software stack from previous decade gets to hold everyone else hostage.
>
>  Compatibility is not "holding" anyone "hostage". Nobody is forced to
> use old
>  hardware or compatibility libraries. The unilateral removal of such
>  "obsolete" technologies is what is holding users hostage.
>  
Look, if something is actually declared dead and unmaintained and
there is an upgrade path, then it is on us to help everyone get
through that upgrade path. That is literally the point of a
distribution. We have a set of opinions of how the distribution is put
together, maintained, and evolved. While I disagree with the removal
of i686 content from the mirror network, I do not have the bandwidth
to commit to helping the x86 SIG. This is why I'm not complaining
about it.

The folks that care about i686 should come together and revive the x86
SIG and fix bugs. I personally know that we have issues with Go and
Rust based code on i686 because we keep hitting memory exhaustion
during compilation. It also happens on armv7hl, but the ARM people add
hacks for their platform to work. No one is doing the same for i686.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Kevin Kofler]

Neal Gompa wrote:
>  This is true for building locally for i686. You cannot do 32-bit
>  development with multilib x86_64 content. 
Yes, that is my point. Well, actually, you can do some amount of 32-bit 
development with multilib -devel packages, but mock RPM builds require a 
complete 32-bit chroot. So multilib is not even self-hosting (i.e., the 
removal of the 32-bit repositories makes Fedora no longer a self-hosting 
distribution).

>  The difference was the modularity only managed to make it in
>  originally by being described as a purely add-on concept. It was
>  individual packagers that started breaking the world by churning core
>  packages into modules. 
That could have been prevented by policy, but deliberately was not, because 
the people behind Modularity had exactly this (moving random packages to 
module-only) as their hidden agenda. I had warned about this part, too, and 
asked for policies ensuring that modules remain purely optional. I only got 
excuses (of the kind "it is not planned anyway, but we are strictly against 
actually banning it" – ha ha, guess why) and no such policy, and FESCo 
failed to require the requested policy and took the Modularity people's 
(obviously dishonest – again, why on Earth would they have been against such 
a policy if they truly had no plans to do the exact opposite?) word for it.

>  Everyone knew up front that the hardware change was bad and
> there's no
>  way to sneak that in without breaking people. It's not going in
>  anytime soon. 
Hopefully!

>  Become maintainers of the package? This is sort of the point of the
>  system. Someone needs to take care of it, and if there's a user, they
>  can become a maintainer. Ideally, most consumers of the package
>  (dependency-wise) would consider at least being co-maintainers of
>  their direct dependencies. 
It is absolutely not realistic to expect all end users to become package 
maintainers.

>  It appears quick because we've have the FTBFS orphaning process
> be
>  broken for three years. There's a lot of breakage to catch up on. 
For the orphaned packages, the process is quick by policy, it only allows 
for 6 weeks! And I still do not see why the lack of a maintainer is by 
itself (without actual issues with the package being reported by actual 
users) a reason to remove a package. From a user standpoint, it is better to 
have an unmaintained package of the software I need than none at all!

The FTBFS process has slightly more reasonable time frames, but I disagree 
that FTBFS is by itself an issue worth orphaning or retiring packages for to 
begin with. A failure to build only becomes an issue if I need to change 
something in the package or rebuild it due to some soname bump, and that is 
the point where I will fix it anyway. Otherwise, those FTBFS bugs are only 
an annoyance forcing me to spend time on irrelevant issues rather than on 
real ones.

>  Regular orphanings are happening because for some reason we allow
>  orphaned packages to be used as inputs for modules, so now we have
>  this giant mess of dead packages that aren't dead. This is a very
>  broken policy and should be fixed, but I suspect that it won't be,
>  because that would force module packages to always have a non-modular
>  counterpart in the distribution, based on how our tools work. 
Forcing all packages to have a non-modular version would fix a lot of the 
insanity of Modularity. I would be all in favor of that as well!

> > See qt (4) and kdelibs (4), and qt3 and kdelibs3, for how
> compatibility
> > should work.
>  
>  Those transitions had the benefit of the major consumer (KDE) moving
>  forward relatively quickly after. Python 2 is not in the same state.
>  In many cases, Fedora is the driver for packages getting ported to
>  Python 3, and if we hadn't done it, it likely wouldn't have ever
>  happened. This is one of the major things I consider valuable about
>  Fedora. If we don't do it, I do not believe anyone else would. 
But there is just no way that Fedora can get all upstream software ported to 
Python 3, and so, radically removing Python 2 will deprive users of software 
they need and that has no supported alternative.

There is the FESCo exception process, but it is clearly not working, because 
FESCo can veto any package from being provided, see e.g.:
https://pagure.io/fesco/issue/2223

It should be the call of the maintainer of the package whether they still 
want to provide the package, and if not, they should orphan it and leave 
somebody else the chance to pick it up. But in no way should it require the 
approval of a committee that can (and does, see above) say "no" arbitrarily.

>  Look, if something is actually declared dead and unmaintained and
>  there is an upgrade path, then it is on us to help everyone get
>  through that upgrade path. That is literally the point of a
>  distribution. We have a set of opinions of how the distribution is put
>  together, maintained, and evolved. While I disagree with the removal
>  of i686 content from the mirror network, I do not have the bandwidth
>  to commit to helping the x86 SIG. This is why I'm not complaining
>  about it. 
In the case of hardware, the "upgrade path" actually requires shelling out 
money, unless by "upgrade path", you mean migrating to a distribution not 
practicing the same kind of planned obsolescence.

In the case of software, I really don't see what benefits banning by 
committee some compatibility packages and/or their use brings us. 
Compatibility packages have near zero impact on the people maintaining and 
using the current versions. I do think we should try to get packages to 
agree on one version of a system library (and a programming language 
interpreter is a special case of a "library") where possible, but for major 
changes such as Qt 5 or Python 3, it is just not possible to get everything 
ported and a compatibility package is obviously necessary.

>  The folks that care about i686 should come together and revive the
> x86
>  SIG and fix bugs. I personally know that we have issues with Go and
>  Rust based code on i686 because we keep hitting memory exhaustion
>  during compilation. It also happens on armv7hl, but the ARM people add
>  hacks for their platform to work. No one is doing the same for i686. 
The problem then is really that we have Go and Rust based code to begin 
with. :-) C and C++ forever!

        Kevin Kofler

[Emmanuel Seyman]

* Kevin Kofler [19/09/2019 16:12] :
>  That could have been prevented by policy, but deliberately was not, because 
>  the people behind Modularity had exactly this (moving random packages to 
>  module-only) as their hidden agenda. 
I'm quite certain that forbidding people to move to module-only would mean
that we would not only not have a Java stack in Fedora but also no Java
module too.

You can argue that that's a good thing. Mikolaj wouldn't have gotten half
the abuse he got for being the last remaining member of the Java SIG and
we wouldn't have crazy conspiracies accussing people of moving packages
to module-only because $REASON but having a Java module is better than
not having one.

Emmanuel

[Stephen John Smoogen]

On Thu, 19 Sep 2019 at 16:46, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
>  * Kevin Kofler [19/09/2019 16:12] :
>  >
>  > That could have been prevented by policy, but deliberately was not, because
>  > the people behind Modularity had exactly this (moving random packages to
>  > module-only) as their hidden agenda.
>
>  I'm quite certain that forbidding people to move to module-only would mean
>  that we would not only not have a Java stack in Fedora but also no Java
>  module too.
>
>  You can argue that that's a good thing. Mikolaj wouldn't have gotten half
>  the abuse he got for being the last remaining member of the Java SIG and
>  we wouldn't have crazy conspiracies accussing people of moving packages
>  to module-only because $REASON but having a Java module is better than
>  not having one.
>  
That is not taking all of Kevin's proposal. In his proposal, that
would just mean that whatever last working version of Java would stay
there until the end of time. If it stopped compiling on updates, then
the last version which did stays in Fedora until provably broken.

He might also say that Java is a curse and if it went away.. that
would just mean people would go back to coding in C++ as they should.
However that is speculation on my part.



-- 
Stephen J Smoogen.

[Kevin Kofler]

Stephen John Smoogen wrote:
>  He might also say that Java is a curse and if it went away.. that
>  would just mean people would go back to coding in C++ as they should.
>  However that is speculation on my part. 
I actually need Java for work, but I don't really need anything beyond 
java-1.8.0-openjdk (or maybe a newer version in the future). As an IDE, I 
have to use NetBeans directly from upstream because the Fedora package was 
discontinued years ago, sadly. And for libraries, all the (non-JDK/JRE) JARs 
our projects need are checked in in our repositories anyway, so I don't need 
any Java system libraries.

(Well, currently, I use a system Tomcat package for local testing, but I 
don't even use it as a system service, but with a CATALINA_BASE in my home 
directory, so I'm quite likely to just switch to unpacking the upstream 
Tomcat directly there at some point.)

        Kevin Kofler

[John M. Harris, Jr.]

We had Java in Fedora long before modules, but not having a Java module would certainly be
the case in that scenario, and that'd be fine. We've been able to install multiple
different Java versions on the same Fedora install for some time now, something which is
not possible with modules.

On September 19, 2019 8:45:39 PM UTC, Emmanuel Seyman <emmanuel(a)seyman.fr&gt; wrote:
> * Kevin Kofler [19/09/2019 16:12] :
> >
> > That could have been prevented by policy, but deliberately was not,
> because 
> > the people behind Modularity had exactly this (moving random packages
> to 
> > module-only) as their hidden agenda.
>
> I'm quite certain that forbidding people to move to module-only would
> mean
> that we would not only not have a Java stack in Fedora but also no Java
> module too.
>
> You can argue that that's a good thing. Mikolaj wouldn't have gotten
> half
> the abuse he got for being the last remaining member of the Java SIG
> and
> we wouldn't have crazy conspiracies accussing people of moving packages
> to module-only because $REASON but having a Java module is better than
> not having one.
>
> Emmanuel
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Kevin Kofler]

Emmanuel Seyman wrote:
>  I'm quite certain that forbidding people to move to module-only
> would mean
>  that we would not only not have a Java stack in Fedora but also no Java
>  module too. 
I think that banning module-only packages would actually get Java back to 
non-modular-only, since the goal of going module-only is clearly to only do 
one rather than both. I don't see how maintaining the packages as module-
only is in any way less work than maintaining them as non-modular-only. So 
we need to force the packagers to set the correct priorities for the benefit 
of the project as a whole.

        Kevin Kofler

[Fabio Valentini]

On Thu, Sep 26, 2019 at 12:19 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Emmanuel Seyman wrote:
>  > I'm quite certain that forbidding people to move to module-only would mean
>  > that we would not only not have a Java stack in Fedora but also no Java
>  > module too.
>
>  I think that banning module-only packages would actually get Java back to
>  non-modular-only, since the goal of going module-only is clearly to only do
>  one rather than both. I don't see how maintaining the packages as module-
>  only is in any way less work than maintaining them as non-modular-only. So
>  we need to force the packagers to set the correct priorities for the benefit
>  of the project as a whole. 
To make things even more interesting, the non-modular Java stack has
almost reached parity with what's available from the shiny module
branches, except a handful of packages that require more work than a
simple "bump version and build" (for example, the rebase from maven
3.5 to 3.6 is still pending, but I'm planning to work on that soon).

Fabio

>         Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Kevin Kofler]

Fabio Valentini wrote:
>  To make things even more interesting, the non-modular Java stack has
>  almost reached parity with what's available from the shiny module
>  branches, except a handful of packages that require more work than a
>  simple "bump version and build" (for example, the rebase from maven
>  3.5 to 3.6 is still pending, but I'm planning to work on that soon). 
Does that include Eclipse, where the packagers recently announced that it 
would become module-only?

(That said, all the Java projects I work with are set up for NetBeans, so I 
don't really use Eclipse anyway. I'm just asking for curiosity. Sadly, the 
NetBeans Fedora package was abandoned long ago, long before Modularity has 
become a thing, so that one is a wholly different story.)

        Kevin Kofler

[Fabio Valentini]

On Sun, Sep 29, 2019 at 3:48 AM Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
>  Fabio Valentini wrote:
>  > To make things even more interesting, the non-modular Java stack has
>  > almost reached parity with what's available from the shiny module
>  > branches, except a handful of packages that require more work than a
>  > simple "bump version and build" (for example, the rebase from maven
>  > 3.5 to 3.6 is still pending, but I'm planning to work on that soon).
>
>  Does that include Eclipse, where the packagers recently announced that it
>  would become module-only?
>
>  (That said, all the Java projects I work with are set up for NetBeans, so I
>  don't really use Eclipse anyway. I'm just asking for curiosity. Sadly, the
>  NetBeans Fedora package was abandoned long ago, long before Modularity has
>  become a thing, so that one is a wholly different story.) 
No, it doesn't include eclipse. We aren't interested in maintaining
it, and certainly don't have the manpower to do it.

Fabio

>         Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Gordon Messmer]

On 9/19/19 7:12 AM, Kevin Kofler wrote:
>  It is absolutely not realistic to expect all end users to become
> package
>  maintainers. 

Sure, isn't it also unrealistic to expect to receive a massive library 
of software and contribute nothing in return?  Do you have an inherent 
right to the product of the work that other people do to fulfill their 
own needs?  Free Software requires participation.

You've complained that Fedora has become about dropping things, but 
those "things" don't exist unless someone makes them.

[Adam Williamson]

On Thu, 2019-09-19 at 20:36 -0700, Gordon Messmer wrote:
>  On 9/19/19 7:12 AM, Kevin Kofler wrote:
>  > It is absolutely not realistic to expect all end users to become package
>  > maintainers.
>  
>  Sure, isn't it also unrealistic to expect to receive a massive library 
>  of software and contribute nothing in return?  Do you have an inherent 
>  right to the product of the work that other people do to fulfill their 
>  own needs?  Free Software requires participation.
>  
>  You've complained that Fedora has become about dropping things, but 
>  those "things" don't exist unless someone makes them. 
Please note, I'm not sure if you're aware, but it's certainly not the
case that Kevin "contribute[s] nothing in return". He's worked on
Fedora packaging, especially around KDE, for many years.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Gordon Messmer]

On 9/19/19 9:28 PM, Adam Williamson wrote:
>  Please note, I'm not sure if you're aware, but it's
> certainly not the
>  case that Kevin "contribute[s] nothing in return". He's worked on
>  Fedora packaging, especially around KDE, for many years. 

I was thinking about users in general, in response to Kevin's statement, 
and not about Kevin himself.

But I'll also note that I thought I saved that message to think about a 
while before I sent it.  I'm very tired today, and I know my judgement 
is off.  So, I apologize.

[Adam Williamson]

On Thu, 2019-09-19 at 21:56 -0700, Gordon Messmer wrote:
>  On 9/19/19 9:28 PM, Adam Williamson wrote:
>  > Please note, I'm not sure if you're aware, but it's certainly not the
>  > case that Kevin "contribute[s] nothing in return". He's worked on
>  > Fedora packaging, especially around KDE, for many years.
>  
>  I was thinking about users in general, in response to Kevin's statement, 
>  and not about Kevin himself.
>  
>  But I'll also note that I thought I saved that message to think about a 
>  while before I sent it.  I'm very tired today, and I know my judgement 
>  is off.  So, I apologize. 
No worries, I wasn't sure which way your mail was intended to be read
so I just wanted to make sure you knew :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Randy Barlow]

On Wed, 2019-09-18 at 23:24 +0200, Kevin Kofler wrote:
>  And if an otherwise maintained package FTBFS, if it does not
> actually
>  need 
>  any change, I don't see how this is even an issue at all. 
FTBFS packages can get CVEs filed against them and then they can be
difficult to fix. There are a few problems:

* The FTBFS package often has no maintainer to notice the CVE in the
  first place, which means it is likely to just be vulnerable without
  any other packagers noticing.
* If someone does notice the CVE and wants to fix it, they have to
  first figure out why the package doesn't build. This is at a minimum
  extra work for the maintainer, and in some cases it could be that it
  is impossible to fix the FTBFS (for example, if the package requires
  an older dependency than is in the distribution that was removed or
  upgraded years ago).
* If it is impossible to fix the FTBFS and there is a CVE, we also
  cannot remove the vulnerable package from stable releases.

The current policy does curtail that last problem (but does not
eliminate it entirely) by removing some FTBFS packages before they have
CVEs. Of course, we do have unmaintained software in the distribution
despite this policy, but the policy does lead to *fewer* unmaintained
packages, which means fewer packages with the above problems.

The FTBFS policy essentially is an "are you there?" to the maintainer.
It is a disservice to our users to provide them with unmaintained
packages, and this is one tool we have to find out if packagers are
still around.

[Kevin Kofler]

Randy Barlow wrote:
>  It is a disservice to our users to provide them with unmaintained
>  packages, 
It is a disservice to our users to NOT provide them with unmaintained 
packages. If, as a user, you NEED a package, you would rather have it 
present but unmaintained than not have it at all!

        Kevin Kofler

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
>  Randy Barlow wrote:
>  > It is a disservice to our users to provide them with unmaintained
>  > packages,
>  
>  It is a disservice to our users to NOT provide them with unmaintained 
>  packages. If, as a user, you NEED a package, you would rather have it 
>  present but unmaintained than not have it at all! 
I disagree.  A lot of users don't really understand the nature of free
software, distributions, etc.  If they install Fedora and an
unmaintained package doesn't work for them, they tend to blame Fedora
and look at other distributions (or blame Linux and go back to Windows
or Mac).  Maybe eventually they realize the particular application is
crap and circle back to Fedora, but they often don't.

A distribution is not supposed to be just a big dump of software,
hopefully some of it working (like the early days of Linux where
everybody just uploaded their programs to a few big FTP sites); it's
supposed to be a system of things that are usable.

Even if someone does try to work with Fedora on a broken application,
who is going to get the bug reports?  Who is going to respond?  No
response still looks bad to the average user.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Przemek Klosowski]

On 9/19/19 10:44 PM, Chris Adams wrote:
>  Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
> > Randy Barlow wrote:
> >> It is a disservice to our users to provide them with unmaintained
> >> packages,
> > It is a disservice to our users to NOT provide them with unmaintained
> > packages. If, as a user, you NEED a package, you would rather have it
> > present but unmaintained than not have it at all!
>
>  A distribution is not supposed to be just a big dump of software,
>  hopefully some of it working (like the early days of Linux where
>  everybody just uploaded their programs to a few big FTP sites); it's
>  supposed to be a system of things that are usable. 
I was just going to write something like that, so thank you for saying 
it first.

As a cautionary tale, please see 
https://bugzilla.redhat.com/show_bug.cgi?id=1490074

It is an example of trying an existing but obsolete and unsupported 
application that didn't work; trying to fix it, and realizing that it's 
hopeless after wasting a day or so.

In cases like this, Fedora would be doing users a favor by yanking 
it---not only people wouldn't waste time on broken stuff but hopefully 
it would speed up the uptake of a better replacement.

This even applies to Python2, in a way.   Just rip that bandaid off, 
don't let it fester. RIP WUSTL FTP.

[John M. Harris, Jr.]

Agreed, especially when there is little to no call for such a thing.

For example, Python 2 and Python 3 can and do coexist. i686 builds can coexist with x86_64
builds.

On September 18, 2019 9:56:49 AM UTC, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:
> John M. Harris, Jr. wrote:
> > These are generic servers. I can provide a link to the vendor's
> website
> > when I get home. It is not Dell, Lenovo or similar, those are
> currently
> > selling mostly x86_64. Additionally, many users don't want to buy a
> new
> > computer just because a software project made the decision to
> randomly
> > drop support for their architecture. I am certainly one of those. The
> > hardware is fine, perfect working condition. I don't understand why
> we
> > should simply turn these to e-waste because somebody flipped the
> > proverbial switch.
>
> Unfortunately, Fedora has lately become mainly about randomly dropping 
> support for things:
> * dropping, in short succession, of the i686 kernel, the i686 images,
> and
> then even the i686 repositories even though there are legitimate use
> cases
>   for them on an x86_64 kernel (e.g., building multilib packages),
> * the insane proposal to require AVX2 for x86_64, which has thankfully
> not
> been implemented so far, but against which we will likely have to fight
>   again and again during the next few years,
> * the reenforcement of the mass-retirement procedures and the resulting
> aggressive mass-retirement of hundreds of FTBFS or orphaned packages,
> with
>  no regards to why (or even if, in the latter case) they fail to build,
>   whether they still work, how essential they are, nor what or how many
>   other packages (including essential ones) depend on them,
> * the unprecedentedly aggressive removal of Python 2 and anything
> remotely
>   related to it, where useful packages can arbitrarily be vetoed by
>   committee (see e.g. https://pagure.io/fesco/issue/2223 ).
>
> All these are moves which are leaving, will leave, or would leave
> thousands 
> of users in the cold when and if they have been, are, will be, or would
> be 
> implemented.
>
> I miss the times when Fedora was still an inclusive project, focused on
>
> adding things rather than on removing them.
>
> Each time you drop an architecture (e.g. i686), a subset of an
> architecture 
> (e.g. pre-AVX2 x86_64), or one or more packages, you are excluding
> dozens, 
> hundreds, thousands, or even millions of users. Removing things is
> actively 
> harmful to Fedora.
>
>         Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Emmanuel Seyman]

* John M. Harris, Jr. [17/09/2019 21:27] :
>  I can provide a link to the vendor's website when I get home. 
I'm interested in this.

Emmanuel

[Test-Announce] Fedora 31 Beta Release Announcement

[Ralf Corsepius]

On 9/17/19 4:04 PM, Mohan Boddu wrote:

>  Since this is a Beta release, we expect that you may encounter bugs
> or
>  missing features. To report issues encountered during testing, contact the
>  Fedora QA team via the mailing list or in #fedora-qa on Freenode. 
Some not so pleasant results:

# dnf system-upgrade download --refresh --releasever=31
Before you continue ensure that your system is fully upgraded by running 
"dnf --refresh upgrade". Do you want to continue [y/N]: y
...
Ignoring repositories: rpmfusion-free-updates, rpmfusion-nonfree-updates
Modular dependency problems:

  Problem 1: conflicting requests
   - nothing provides module(platform:f30) needed by module 
eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
  Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 
requires module(eclipse), but none of the providers can be installed
   - conflicting requests
   - nothing provides module(platform:f30) needed by module 
eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
Error:
  Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
libperl.so.5.28()(64bit), but none of the providers can be installed
   - package crypto-utils-2.5-4.fc29.x86_64 requires 
perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed
   - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a distupgrade 
repository
   - problem with installed package crypto-utils-2.5-4.fc29.x86_64
   - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is 
excluded
   - package perl-libs-4:5.28.2-439.module_f31+6050+a462f342.x86_64 is 
excluded
  Problem 2: problem with installed package 
libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64
   - package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires 
libjsoncpp.so.19()(64bit), but none of the providers can be installed
   - libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong 
to a distupgrade repository
   - jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository

Ralf

[Test-Announce] Fedora 31 Beta Release Announcement

[Petr Pisar]

On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  Error:
>    Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
>  libperl.so.5.28()(64bit), but none of the providers can be installed
>     - package crypto-utils-2.5-4.fc29.x86_64 requires 
>  perl(:MODULE_COMPAT_5.28.0), but none of the providers can be installed
>     - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a distupgrade 
>  repository 
crypto-utils has not been rebuilt against Perl 5.30 because the package
fails to build for an unrelated reason and was retired (bug #1674777)
and obsoleted in fedora-obsolete-packages-31-31 that is in
updates-testing now. Enabling updates-testing repository or waiting
a bit for the stabilization should help you.

>     - problem with installed package crypto-utils-2.5-4.fc29.x86_64
>     - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is 
>  excluded 
Funnily DNF finds out that you could actually get that package satisfied
if you enabled a modular Perl. Unfortunatelly DNF does not report what
module stream the modular perl-libs packages comes from. There is indeed
some room for improvement. DNF could start recommending "maybe you wanted
to enable perl:5.28 stream?" :)

-- Petr

[Test-Announce] Fedora 31 Beta Release Announcement

[Kalev Lember]

On 9/18/19 10:29, Petr Pisar wrote:
>  On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >     - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is
> > excluded
>  
>  Funnily DNF finds out that you could actually get that package satisfied
>  if you enabled a modular Perl. Unfortunatelly DNF does not report what
>  module stream the modular perl-libs packages comes from. There is indeed
>  some room for improvement. DNF could start recommending "maybe you wanted
>  to enable perl:5.28 stream?" :) 
Hm, did perl get moved to the modular repo? That sounds like it is going 
to cause more issues than solve as it's not a leaf package. Why can't it 
stay as a regular package?

-- 
Kalev

[Test-Announce] Fedora 31 Beta Release Announcement

[Ralf Corsepius]

On 9/18/19 12:11 PM, Kalev Lember wrote:
>  
>  On 9/18/19 10:29, Petr Pisar wrote:
> > On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >>     - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is
> >> excluded
> >
> > Funnily DNF finds out that you could actually get that package satisfied
> > if you enabled a modular Perl. Unfortunatelly DNF does not report what
> > module stream the modular perl-libs packages comes from. There is indeed
> > some room for improvement. DNF could start recommending "maybe you wanted
> > to enable perl:5.28 stream?" :) 
Openly said, to me, the modules are permanent source of troubles.

>  Hm, did perl get moved to the modular repo? That sounds like it is
> going 
>  to cause more issues than solve as it's not a leaf package. Why can't it 
>  stay as a regular package? 
Featuritis? Actually, do not see any usefulness in any
module.

Ralf

[Test-Announce] Fedora 31 Beta Release Announcement

[Michal Schorm]

>  Featuritis? Actually, do not see any usefulness in any module.
*any* module ?
Maybe you just haven't met the right use case yet.

I maintain packages of MariaDB and MySQL projects. There's no better
way I can imagine, to develop two version of the packages of the DB,
than modules.
Fedora have MariaDB 10.3 in base. 10.4 in modules. I maintain both, I
actively fix both and I try to cooperate with upstream to get it so
stable, that Fedora could switch to 10.4. [1]

Apart from that, I don't want to force useres to do the upgrade
immediatelly. I'm providing both 10.3 and 10.4 as modules (even though
10.3 is also in base), so the user can switch to the desired stream
and stay with it, no matter when I introduce the new version into the
base Fedora. of course, I don't plan to mainatin the 10.3 forever
after the change will be made, but I believe i surely might come handy
to someone, who wants the up-to-date and secure Fedora, but haven't
got time to upgrade 10.3->10.4 yet.

Althought I agree with that many of the modularized packages are not
useffull modularized, and / or creates more issues that way; I
certainly find the modularity usefull.
As per Unix motto "do one thing and do it well" [2], I never expected
modularity to solve all of my problems and use cases. Just some. And
it did. Just fine. For me.
( Disclaimer: modularity will need time to also comply with the part
"do it well" ;) )

[1] https://fedoraproject.org/wiki/Changes/MariaDB_10.4
[2] https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Wed, Sep 18, 2019 at 2:07 PM Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>
> On 9/18/19 12:11 PM, Kalev Lember wrote:
> >
> > On 9/18/19 10:29, Petr Pisar wrote:
> >> On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >>>     - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is
> >>> excluded
> >>
> >> Funnily DNF finds out that you could actually get that package satisfied
> >> if you enabled a modular Perl. Unfortunatelly DNF does not report what
> >> module stream the modular perl-libs packages comes from. There is indeed
> >> some room for improvement. DNF could start recommending "maybe you
wanted
> >> to enable perl:5.28 stream?" :)
>
> Openly said, to me, the modules are permanent source of troubles.
>
> > Hm, did perl get moved to the modular repo? That sounds like it is going
> > to cause more issues than solve as it's not a leaf package. Why can't
it
> > stay as a regular package?
>  Featuritis? Actually, do not see any usefulness in any module.
>
> Ralf
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Test-Announce] Fedora 31 Beta Release Announcement

[Adam Williamson]

On Wed, 2019-09-18 at 12:11 +0200, Kalev Lember wrote:
>  On 9/18/19 10:29, Petr Pisar wrote:
>  > On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > >     - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64 is
>  > > excluded
>  > 
>  > Funnily DNF finds out that you could actually get that package satisfied
>  > if you enabled a modular Perl. Unfortunatelly DNF does not report what
>  > module stream the modular perl-libs packages comes from. There is indeed
>  > some room for improvement. DNF could start recommending "maybe you wanted
>  > to enable perl:5.28 stream?" :)
>  
>  Hm, did perl get moved to the modular repo? That sounds like it is going 
>  to cause more issues than solve as it's not a leaf package. Why can't it 
>  stay as a regular package? 
It didn't get *moved* to a module, no. There are just *alternative
versions* available in a module:

https://src.fedoraproject.org/modules/perl

that module has no default stream, which means that if you just install
Fedora and do 'dnf install perl' (or do anything else which causes a
perl package to get installed) you'll get the non-modular package.
You'll only get a modular package if you explicitly enable the module.

As Petr points out, what's happening here is DNF is noticing that a
package in one of the module streams satisfies the missing dependency,
but that package is 'excluded' (because that module stream is not
enabled). And as he also points out, DNF could stand to explain this
much more clearly.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Test-Announce] Fedora 31 Beta Release Announcement

[Petr Pisar]

On 2019-09-18, Kalev Lember <kalevlember(a)gmail.com&gt; wrote:
>  Hm, did perl get moved to the modular repo? That sounds like it is
> going 
>  to cause more issues than solve as it's not a leaf package. Why can't it 
>  stay as a regular package?
>  
Perl is still a regular package and until Fedora allows modules in
a build root I wan't even start thinking about removing non-modular
perl.

But I provide modulerized perl in addition to the non-modular one. And
there is indeed not much use of it if you don't want to sascrifice all
the other Perl packages. Though, this crypto-tools error showed me one
of the uses I did not realize before. I just found it interesting and
wanted to pointed it out.

I actually filed a feature request against DNF (bug #1753140) to report
the module stream. When modules proliferate Fedora more, the amount of
users who enabled a stream and cannot install a non-modular package will
surge. Giving them a chance to know what module reset back to default is
a handy.

-- Petr

[Test-Announce] Fedora 31 Beta Release Announcement

[Kalev Lember]

On 9/18/19 17:41, Petr Pisar wrote:
>  On 2019-09-18, Kalev Lember <kalevlember(a)gmail.com&gt; wrote:
> > Hm, did perl get moved to the modular repo? That sounds like it is going
> > to cause more issues than solve as it's not a leaf package. Why can't it
> > stay as a regular package?
> >
>  Perl is still a regular package and until Fedora allows modules in
>  a build root I wan't even start thinking about removing non-modular
>  perl.
>  
>  But I provide modulerized perl in addition to the non-modular one. And
>  there is indeed not much use of it if you don't want to sascrifice all
>  the other Perl packages. Though, this crypto-tools error showed me one
>  of the uses I did not realize before. I just found it interesting and
>  wanted to pointed it out. 
Ahh, great :) Thanks, Petr!

-- 
Kalev

[Test-Announce] Fedora 31 Beta Release Announcement

[John M. Harris, Jr.]

Removing modules is a potential solution to this, as it would simplify package
management.

On September 18, 2019 8:29:49 AM UTC, Petr Pisar <ppisar(a)redhat.com&gt; wrote:
> On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > Error:
> >   Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
> > libperl.so.5.28()(64bit), but none of the providers can be installed
> >    - package crypto-utils-2.5-4.fc29.x86_64 requires 
> > perl(:MODULE_COMPAT_5.28.0), but none of the providers can be
> installed
> >    - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a
> distupgrade 
> > repository
>
> crypto-utils has not been rebuilt against Perl 5.30 because the package
> fails to build for an unrelated reason and was retired (bug #1674777)
> and obsoleted in fedora-obsolete-packages-31-31 that is in
> updates-testing now. Enabling updates-testing repository or waiting
> a bit for the stabilization should help you.
>
> >    - problem with installed package crypto-utils-2.5-4.fc29.x86_64
> >    - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64
> is 
> > excluded
>
> Funnily DNF finds out that you could actually get that package
> satisfied
> if you enabled a modular Perl. Unfortunatelly DNF does not report what
> module stream the modular perl-libs packages comes from. There is
> indeed
> some room for improvement. DNF could start recommending "maybe you
> wanted
> to enable perl:5.28 stream?" :)
>
> -- Petr
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[EXT] Re: [Test-Announce] Fedora 31 Beta Release Announcement

[Anderson, Charles R]

So, not only do you want to keep "old" stuff in Fedora (i686), but now you want
to revert/remove "new" stuff (modules) too?  I'm beginning to think that
Fedora just isn't a good fit for you.

On Wed, Sep 18, 2019 at 06:22:52PM +0000, John M. Harris, Jr. wrote:
> Removing modules is a potential solution to this, as it would simplify package
management.
> 
> On September 18, 2019 8:29:49 AM UTC, Petr Pisar <ppisar(a)redhat.com&gt; wrote:
> >On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> >> Error:
> >>   Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
> >> libperl.so.5.28()(64bit), but none of the providers an be installed
> >>    - package crypto-utils-2.5-4.fc29.x86_64 requires 
> >> perl(:MODULE_COMPAT_5.28.0), but none of the providers can be
> >installed
> >>    - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a
> >distupgrade 
> >> repository
> >
> >crypto-utils has not been rebuilt against Perl 5.30 because the package
> >fails to build for an unrelated reason and was retired (bug #1674777)
> >and obsoleted in fedora-obsolete-packages-31-31 that is in
> >updates-testing now. Enabling updates-testing repository or waiting
> >a bit for the stabilization should help you.
> >
> >>    - problem with installed package crypto-utils-2.5-4.fc29.x86_64
> >>    - package perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64
> >is 
> >> excluded
> >
> >Funnily DNF finds out that you could actually get that package
> >satisfied
> >if you enabled a modular Perl. Unfortunatelly DNF does not report what
> >module stream the modular perl-libs packages comes from. There is
> >indeed
> >some room for improvement. DNF could start recommending "maybe you
> >wanted
> >to enable perl:5.28 stream?" :)
> >
> >-- Petr

[EXT] Re: [Test-Announce] Fedora 31 Beta Release Announcement

[John M. Harris, Jr.]

I want to keep "old" stuff in, because there's no reason to drop the support
for systems that we already support, if we can do so without breaking anything.

On September 18, 2019 7:07:30 PM UTC, "Anderson, Charles R" <cra(a)wpi.edu&gt;
wrote:
> So, not only do you want to keep "old" stuff in Fedora
> (i686), but now
> you want to revert/remove "new" stuff (modules) too?  I'm beginning to
> think that Fedora just isn't a good fit for you.
>
> On Wed, Sep 18, 2019 at 06:22:52PM +0000, John M. Harris, Jr. wrote:
> > Removing modules is a potential solution to this, as it would
> simplify package management.
> > 
> > On September 18, 2019 8:29:49 AM UTC, Petr Pisar <ppisar(a)redhat.com&gt;
> wrote:
> > >On 2019-09-18, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
> > >> Error:
> > >>   Problem 1: package crypto-utils-2.5-4.fc29.x86_64 requires 
> > >> libperl.so.5.28()(64bit), but none of the providers an be
> installed
> > >>    - package crypto-utils-2.5-4.fc29.x86_64 requires 
> > >> perl(:MODULE_COMPAT_5.28.0), but none of the providers can be
> > >installed
> > >>    - perl-libs-4:5.28.2-439.fc30.x86_64 does not belong to a
> > >distupgrade 
> > >> repository
> > >
> > >crypto-utils has not been rebuilt against Perl 5.30 because the
> package
> > >fails to build for an unrelated reason and was retired (bug
> #1674777)
> > >and obsoleted in fedora-obsolete-packages-31-31 that is in
> > >updates-testing now. Enabling updates-testing repository or waiting
> > >a bit for the stabilization should help you.
> > >
> > >>    - problem with installed package crypto-utils-2.5-4.fc29.x86_64
> > >>    - package
> perl-libs-4:5.28.2-439.module_f31+6019+b24e098f.x86_64
> > >is 
> > >> excluded
> > >
> > >Funnily DNF finds out that you could actually get that package
> > >satisfied
> > >if you enabled a modular Perl. Unfortunatelly DNF does not report
> what
> > >module stream the modular perl-libs packages comes from. There is
> > >indeed
> > >some room for improvement. DNF could start recommending "maybe you
> > >wanted
> > >to enable perl:5.28 stream?" :)
> > >
> > >-- Petr
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail] 
-- 
Sent from my mobile device. Please excuse my brevity.

[Test-Announce] Fedora 31 Beta Release Announcement

[Adam Williamson]

On Wed, 2019-09-18 at 09:15 +0200, Ralf Corsepius wrote:
>  On 9/17/19 4:04 PM, Mohan Boddu wrote:
>  
>  > Since this is a Beta release, we expect that you may encounter bugs or
>  > missing features. To report issues encountered during testing, contact the
>  > Fedora QA team via the mailing list or in #fedora-qa on Freenode.
>  
>  Some not so pleasant results:
>  
>  # dnf system-upgrade download --refresh --releasever=31
>  Before you continue ensure that your system is fully upgraded by running 
>  "dnf --refresh upgrade". Do you want to continue [y/N]: y
>  ...
>  Ignoring repositories: rpmfusion-free-updates, rpmfusion-nonfree-updates
>  Modular dependency problems:
>  
>    Problem 1: conflicting requests
>     - nothing provides module(platform:f30) needed by module 
>  eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64
>    Problem 2: module jmc:latest:3120190813124555:7188e41a-0.x86_64 
>  requires module(eclipse), but none of the providers can be installed
>     - conflicting requests
>     - nothing provides module(platform:f30) needed by module 
>  eclipse:2019-06:3020190807134759:6ebe2c0f-0.x86_64 
This basically means 'eclipse module has not been rebuilt for F31
platform'. I believe
https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-33a1b20f0a
is the fix for this, so it should be resolved once that gets pushed stable.

>    Problem 2: problem with installed package 
>  libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64
>     - package libopenshot-0.2.3-2.20190406git101f25a.fc31.x86_64 requires 
>  libjsoncpp.so.19()(64bit), but none of the providers can be installed
>     - libopenshot-0.2.3-2.20190406git101f25a.fc30.x86_64 does not belong 
>  to a distupgrade repository
>     - jsoncpp-1.8.4-6.fc30.x86_64 does not belong to a distupgrade repository 
That's not a Fedora package, it's from a third-party repository, so you
need to talk to the third party in question ;) It looks like their
package just needs a rebuild.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net