Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
> On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
> > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý  wrote:
> > > >
> > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
> > > > > 2. adduser/group/etc. => sysusers files
> > > >
> > > > For anyone willing to do this in advance on his/her package - this is 
> > > > how you can do that:
> > > >
> > > > https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc3cf4eb091d8ebb36020237
> > > >
> > > > Here is relevant FPC ticket:
> > > >   https://pagure.io/packaging-committee/issue/442
> > > >
> > > > Just for the record - this does not make things to run faster. You 
> > > > still have to have %pre scriptlets. It is likely even
> > > > slower as you are running %posttranstrigger as well. The benefit is 
> > > > here only that we move toward declarative specification.
> > > >
> > >
> > > That’s also going to fail, because the %pre script executes before the
> > > file exists. That’s why these guidelines are broken, and why I
> > > suggested we deal with sysusers differently.
> >
> > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
> > %sysusers_create is "deprecated. Use %sysusers_create_package instead".
> >
> 
> And to note, even this change doesn't work:
> https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec2ae18d18d6d090928f9084
>
> 
> The reason it doesn't work is because this scriptlet will fail to
> locate the file needed to actually do this. The macro was written in
> mind for being pointed to the file in the sources directly, rather
> than having a path to assume.

Can you explain what exactly is wrong? It looks OK to me.

Zbyszek

> Macros for this are the wrong way to do it, for pretty much this reason.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Leigh Griffin]

On Sun, Jul 21, 2019, 22:38 Neal Gompa  wrote:

> On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline  wrote:
> >
> > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote:
> > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon <
> pin...@pingoured.fr> wrote:
> > > >
> > > > Good Morning,
> > > >
> > > > We posted this [1] blog today and want to open a mailing thread to
> garner
> > > > feedback, field questions and get some thoughts from the Community on
> > > > the approach that we in Community Platform Engineering (CPE) are
> taking.
> > > >
> > > > [1]
> https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> > > >
> > >
> > > Two things that concern me at this time:
> >
> > 
> >
> > >
> > > > Ipsilon — Ipsilon is our identity provider. It supports multiple
> > > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …)
> > > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system
> accounts…).
> > > > While it was originally shipped as a tech preview in RHEL it no
> longer is and
> > > > the team working on this application has also been refocused on
> other projects.
> > > > We would like to move all our applications to use OpenID Connect or
> SAML 2.0
> > > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS
> with an
> > > > IPA-based solution, which in turn allows us to replace ipsilon by a
> more
> > > > maintained solution, likely Red Hat Single Sign On. The dependencies
> > > > are making this a long term effort. We will need to announce to the
> community
> > > > that this means we will shut down the public OpenID 2.0 endpoints,
> > > > which means that any community services that use this protocol need
> > > > to be moved to OpenID Connect as well.
> > >
> > > There are two issues to unpack here:
> > >
> > > 1. We use a weird custom backend and custom protocol extensions.
> > >
> > > This should definitely be replaced if it makes sense. It’s more urgent
> > > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python
> > > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS
> > > developers died a while ago…
> > >
> > > Naturally, the replacement is equally in a poor state, but may have
> > > some legs someday: https://github.com/fedora-infra/noggin
> > >
> > > 2. Ipsilon development was only considered important as part of being
> > > tech preview in RHEL and now it’s not.
> > >
> > > There are some major problems here. First of all, Ipsilon development
> > > has been gated by a single person. That person also seems to have
> > > trouble making time to review pull requests. There has been interest
> > > from the broader community about using and contributing to Ipsilon,
> > > since unlike Keycloak, it is written in an accessible language
> > > (Python).
> > >
> > > Getting Ipsilon to Python 3 would be enough for me to get started on
> > > bootstrapping some of the other interested parties onto Ipsilon, and
> > > hopefully give us a more sustainable community long-term.
> >
> > I guess my question to all this is... Why? What's the goal? If Keycloak
> > does everything Ipsilon does and more, what's the point of keeping a
> > dead project alive instead of contributing to the active, lively one?
> >
> > If there really, truly is interest from the broader community, why not
> > do a friendly fork, get all the work you want in, and see what the
> > original maintainer thinks?
> >
>
> Keycloak is not generally Fedora contributor friendly. Aside from it
> being written in Java (which is problematic with the Java stack in
> Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
> more tied to aspects of RHEL/Fedora that make it annoying to use in
> other environments.
>
> At least with Ipsilon, the Python codebase makes it easy for a broad
> base of contributors to hack on the code. It's also much easier to set
> up than Keycloak and easier to plug into more environments.
>
> The biggest issue with Ipsilon as a project is the lack of awareness
> of its existence. That has allowed the fact that the maintainer hasn't
> recently been able to focus on it in a while to be unnoticed. Now that
> is changing, and this is a problem, as I outline later...
>
> > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace
> > Pagure, or a generic notification service exists somewhere to replace
> > FMN, or whatever, why spend time on such things we could be spending
> > developing the few unique tools we need to continue building the Fedora
> > distribution? Stopping along the way to build an identity and access
> > management platform isn't going to make the distribution better.
> >
>
> FreeIPA is a perfectly fine solution, since it's broadly available and
> easy to deploy. The non-Java parts (everything but Dogtag) is quite
> easy to understand and hack on. Reproducing the tooling and
> environment is easy as well. I have no problems with it other than
> FAS-specific functions still need i

Re: Discussion around app retirements and categorizations by the CPE team

[Miro Hrončok]

On 16. 07. 19 20:18, Pierre-Yves Chibon wrote:

Good Morning,

We posted this [1] blog today and want to open a mailing thread to garner
feedback, field questions and get some thoughts from the Community on
the approach that we in Community Platform Engineering (CPE) are taking.

[1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/


What happens to Pagure? Specifically the dist-git over Pagure part?

If it stays, the front page of a package st src.fp.o might get more love and 
replace apps.fp.o, the Issues tab could be a page that replaaces bugz.fp.o, etc.


That said, I'm afraid Pagure might get replaced as well, correct?


---


Anyway, I respect your decisions and I understand that maintaining everything 
was not sustainable. However I guess that if we replace Pagure with e.g. GitLab 
and all our customization is gone, if the Wiki explodes and nobody will ever fix 
it, if mailman3 goes away and is replaced by some contracted solution, and when 
Badges die, it will be a sad day for the Fedora contributor community, possibly 
making contributing to Fedora even harder than it become over the past few years.


Personally, I wish we had spent less engineering time in infrastructure on 
Modularity and more on the contributor UX :(


I hope this transition will go as smoothly as possible. Good luck guys!

(And please keep in mind that even if I criticize some things a lot, I still 
consider you Fedora superheros.)


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned packages looking for new maintainers (75 to be retired)

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

See this report online at:
https://churchyard.fedorapeople.org/orphans-2019-07-22.txt

Request package ownership via releng issue tracker:
https://pagure.io/releng/issues


Package  (co)maintainers   Status Change

activeio  orphan   1 weeks ago
activemq  arg, java-sig, orphan,   1 weeks ago
  skottler, tdawson
activemq-protobuf orphan   1 weeks ago
aesh  gil, lef, orphan 6 weeks ago
aries-utillef, orphan  1 weeks ago
cdi-api1  gil, orphan  6 weeks ago
concurrentorphan   6 weeks ago
containersorphan   3 weeks ago
cookccgil, lef, orphan 6 weeks ago
cookxml   orphan   6 weeks ago
csvcatorphan   5 weeks ago
curve25519-java   orphan   1 weeks ago
cxf   lef, orphan  1 weeks ago
cxf-build-utils   gil, lef, orphan 6 weeks ago
cxf-xjc-utils gil, lef, orphan 6 weeks ago
derelict  cicku, kalev, orphan 3 weeks ago
dreampie  cicku, orphan5 weeks ago
dsymbol   orphan   3 weeks ago
dustmite  cicku, kalev, orphan 3 weeks ago
dvb-apps  orphan, pbrobinson   2 weeks ago
earth-and-moon-backgroundsorphan   3 weeks ago
ehcache2  lef, orphan  1 weeks ago
fedocal   infra-sig, orphan6 weeks ago
felix-configadmin orphan   6 weeks ago
felix-fileinstall orphan   1 weeks ago
gcompris  jwrdegoede, limb, orphan 2 weeks ago
generic-jms-ralef, orphan  1 weeks ago
gl3n  cicku, kalev, orphan 3 weeks ago
gnome-shell-extension-simple- orphan   5 weeks ago
dock
goffice08 orphan   1 weeks ago
google-oauth-java-client  orphan   1 weeks ago
hibernate-commons-annotations gil, lef, orphan 6 weeks ago
hibernate-hql gil, lef, orphan 6 weeks ago
hibernate-search  gil, lef, orphan 6 weeks ago
hibernate-validator   gil, lef, orphan 6 weeks ago
hibernate3lef, orphan  1 weeks ago
httpcomponents-asyncclientlef, orphan  1 weeks ago
httpress  orphan   1 weeks ago
idlj-maven-plugin lef, orphan  1 weeks ago
jacorbgil, lef, orphan 6 weeks ago
jandexgil, orphan  6 weeks ago
jarbundlerorphan   1 weeks ago
jasperreports lef, orphan  1 weeks ago
jaxws-jboss-httpserver-httpspilef, orphan  6 weeks ago
jaxws-undertow-httpspigil, lef, orphan 6 weeks ago
jberetgil, lef, orphan 6 weeks ago
jboss-annotations-1.1-api orphan   6 weeks ago
jboss-classfilewriter gil, lef, orphan 6 weeks ago
jboss-common-core gil, lef, orphan 6 weeks ago
jboss-dmr gil, lef, orphan 6 weeks ago
jboss-ejb-3.1-api orphan   6 

Re: Discussion around app retirements and categorizations by the CPE team

[Nicolas Mailhot via devel]

Le 2019-07-22 10:22, Miro Hrončok a écrit :


Personally, I wish we had spent less engineering time in
infrastructure on Modularity and more on the contributor UX :(


It’s not just Modularity. Modularity is just a symptom. There is 
something deeply broken in the Red Hat / Fedora interface.


RHEL made Red Hat fortunes. It’s what justified the billions IBM paid 
for it (RHEL is the only Red Hat product where Red Hat completely 
dominates the market, even the best other offerings, like OpenShift, are 
just one among many).


And Fedora is RHEL’s future.

And yet what do we see ?

Highly-visible Red Hat investments on the desktop, where the focus is on 
creating flatpacks to deprecate Fedora as soon as possible. If you read 
the marketing messages you’d think Silverblue was the only Fedora today 
and rpm packaging a thing of the past. Even though Silverblue is 
incomplete by design, since it does not want to address anything except 
desktop deployments.


Huge Red Hat investments, in the Java ecosystem, that fail to translate 
into an healthy Fedora Java ecosystem. To the point that when IBM wants 
its Java guys to join there is absolutely no one Fedora-side to provide 
an on-boarding path.


Huge Red Hat investments, in the container ecosystem. And yet we get 
told CPE is downsizing its activities, in part because all the new cool 
things happen in the container space, contributors want to work on cool 
things, Fedora/RHEL is absent from this space, packaging the things 
containerized infra need is an afterthought.


As a result of short-term delivery focus, with no work on long term 
packaging and maintenance, we're seeing the same explosion of bundling 
and forking and API incompatibilities container-side we saw Java-side 
before, with the same highly predictible long term outcome.


Red Hat is taking RHEL and Fedora for granted.

There is no business drive to keep Fedora strong and growing, and lots 
of internal incentives to work instead on the next best purported 
value-added thing. There is no business drive to keep code healthy and 
maintenable long term, and lots of incentives to invent band-aids like 
modularity, to contain the rot some more till it’s someone else’s 
problem. There is no business drive, to create solutions, that can be 
deployed and used by joe nobody packager. And without those, there is no 
potential of long-term packaging community and no Fedora (let's cut the 
fluff Fedora is a lot of things but at core it’s a packaging community).


Well all that happened to others before, and one day the golden goose 
will be gone.


And why am writing about this non-Fedora sponsor things? Because Fedora 
has stewardship instances, that are supposed to tell those things to the 
generous sponsor, and keep it informed of the real state of its 
sponsored project. And, they are clearly failing to pass the message.


Regards,

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

google-oauth-java-client / javapackages-tools (was: Re: Orphaned packages looking for new maintainers (75 to be retired))

[Richard W.M. Jones]

On Mon, Jul 22, 2019 at 10:47:10AM +0200, Miro Hrončok wrote:
> See this report online at:
> https://churchyard.fedorapeople.org/orphans-2019-07-22.txt

Since the majority of new failures (394!) are caused by the orphaning
of google-oauth-java-client, I looked at the full report and seems
this is a dependency of javapackages-tools (via gradle), and this
package is used to compile most Java code:

Depending on: google-oauth-java-client (394), status change: 2019-07-11 (1 
weeks ago)
  gradle (maintained by: jjelen, mizdebsk, stewardship-sig)
 gradle-4.4.1-3.fc31.src requires 
mvn(com.google.oauth-client:google-oauth-client) = 1.22.0, mvn(com.sun:tools) = 
SYSTEM
 gradle-4.4.1-3.fc31.noarch requires javapackages-tools = 5.3.0-4.fc30

 javapackages-tools (maintained by: mizdebsk, msrb)
 gradle-local-5.3.0-4.fc30.noarch requires gradle = 4.4.1-3.fc31

I don't know much about Java packages but could this dependency be
dropped?  I can't imagine that an OAuth client can be important for a
compiler tool.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Packages with wrong Python unversioned commands

[Miro Hrončok]

Hello Bcc'ed maintainers.

According to the https://fedoraproject.org/wiki/Changes/Python_means_Python3 
change, the unversioned Python commands shell be Python 3.


The following packages have Python 3 marked commands (executables in /usr/bin/) 
but miss the not marked files.


The format is:

: [python2-package]:

Please, make the normal unversioned command Python 3 and move it to the python3 
subpackage.

Add proper conflicts when moving files from one package to another.

Note that if the user shall not care whether the tool is executed by Python 2 or 
Python 3, drop the Python 2 command completely.


Do this in rawhide (Fedora 31+) only.

Thanks...


gprof2dot-python3:/usr/bin/gprof2dot-py3 python2-gprof2dot:/usr/bin/gprof2dot

python3-ProDy:/usr/bin/evol-3 :/usr/bin/evol
python3-ProDy:/usr/bin/evol-3.7 :/usr/bin/evol
python3-ProDy:/usr/bin/prody-3 :/usr/bin/prody
python3-ProDy:/usr/bin/prody-3.7 :/usr/bin/prody
python3-ProDy:/usr/bin/python3.7-evol :/usr/bin/python-evol
python3-ProDy:/usr/bin/python3.7-prody :/usr/bin/python-prody

python3-alembic:/usr/bin/alembic-3 python2-alembic:/usr/bin/alembic
python3-alembic:/usr/bin/alembic-3.7 python2-alembic:/usr/bin/alembic

python3-autopep8:/usr/bin/autopep8-3 :/usr/bin/autopep8
python3-autopep8:/usr/bin/autopep8-3.7 :/usr/bin/autopep8
python3-autopep8:/usr/bin/python3-autopep8 :/usr/bin/autopep8

python3-autowrap:/usr/bin/autowrap-3 :/usr/bin/autowrap
python3-autowrap:/usr/bin/autowrap-3.7 :/usr/bin/autowrap
python3-autowrap:/usr/bin/autowrap-v0.19.0-3.7 :/usr/bin/autowrap-v0.19.0
python3-autowrap:/usr/bin/python3.7-autowrap :/usr/bin/python-autowrap

python3-catkin_pkg:/usr/bin/python3-catkin_create_pkg 
python2-catkin_pkg:/usr/bin/catkin_create_pkg
python3-catkin_pkg:/usr/bin/python3-catkin_find_pkg 
python2-catkin_pkg:/usr/bin/catkin_find_pkg
python3-catkin_pkg:/usr/bin/python3-catkin_generate_changelog 
python2-catkin_pkg:/usr/bin/catkin_generate_changelog
python3-catkin_pkg:/usr/bin/python3-catkin_package_version 
python2-catkin_pkg:/usr/bin/catkin_package_version
python3-catkin_pkg:/usr/bin/python3-catkin_prepare_release 
python2-catkin_pkg:/usr/bin/catkin_prepare_release
python3-catkin_pkg:/usr/bin/python3-catkin_tag_changelog 
python2-catkin_pkg:/usr/bin/catkin_tag_changelog
python3-catkin_pkg:/usr/bin/python3-catkin_test_changelog 
python2-catkin_pkg:/usr/bin/catkin_test_changelog


python3-cherrypy:/usr/bin/python3-cherryd python2-cherrypy:/usr/bin/cherryd
python3-cherrypy:/usr/bin/python3.7-cherryd python2-cherrypy:/usr/bin/cherryd

python3-clustershell:/usr/bin/clubak-3.7 python2-clustershell:/usr/bin/clubak
python3-clustershell:/usr/bin/cluset-3.7 python2-clustershell:/usr/bin/cluset
python3-clustershell:/usr/bin/clush-3.7 python2-clustershell:/usr/bin/clush
python3-clustershell:/usr/bin/nodeset-3.7 python2-clustershell:/usr/bin/nodeset

python3-coverage:/usr/bin/coverage-3.7 python2-coverage:/usr/bin/coverage
python3-coverage:/usr/bin/coverage3 python2-coverage:/usr/bin/coverage
python3-coverage:/usr/bin/python3-coverage python2-coverage:/usr/bin/coverage

python3-cpuinfo:/usr/bin/cpuinfo-3 :/usr/bin/cpuinfo

python3-demjson:/usr/bin/jsonlint-3 python2-demjson:/usr/bin/jsonlint
python3-demjson:/usr/bin/jsonlint-3.7 python2-demjson:/usr/bin/jsonlint

python3-epdb:/usr/bin/epdb-3 python2-epdb:/usr/bin/epdb
python3-epdb:/usr/bin/epdb-3.7 python2-epdb:/usr/bin/epdb

python3-fedmsg:/usr/bin/fedmsg-announce-3 
python2-fedmsg:/usr/bin/fedmsg-announce
python3-fedmsg:/usr/bin/fedmsg-announce-3.7 
python2-fedmsg:/usr/bin/fedmsg-announce
python3-fedmsg:/usr/bin/fedmsg-check-3 python2-fedmsg:/usr/bin/fedmsg-check
python3-fedmsg:/usr/bin/fedmsg-check-3.7 python2-fedmsg:/usr/bin/fedmsg-check
python3-fedmsg:/usr/bin/fedmsg-collectd-3 
python2-fedmsg:/usr/bin/fedmsg-collectd
python3-fedmsg:/usr/bin/fedmsg-collectd-3.7 
python2-fedmsg:/usr/bin/fedmsg-collectd
python3-fedmsg:/usr/bin/fedmsg-config-3 python2-fedmsg:/usr/bin/fedmsg-config
python3-fedmsg:/usr/bin/fedmsg-config-3.7 python2-fedmsg:/usr/bin/fedmsg-config
python3-fedmsg:/usr/bin/fedmsg-dg-replay-3 
python2-fedmsg:/usr/bin/fedmsg-dg-replay
python3-fedmsg:/usr/bin/fedmsg-dg-replay-3.7 
python2-fedmsg:/usr/bin/fedmsg-dg-replay

python3-fedmsg:/usr/bin/fedmsg-gateway-3 python2-fedmsg:/usr/bin/fedmsg-gateway
python3-fedmsg:/usr/bin/fedmsg-gateway-3.7 
python2-fedmsg:/usr/bin/fedmsg-gateway
python3-fedmsg:/usr/bin/fedmsg-hub-3 python2-fedmsg:/usr/bin/fedmsg-hub
python3-fedmsg:/usr/bin/fedmsg-hub-3.7 python2-fedmsg:/usr/bin/fedmsg-hub
python3-fedmsg:/usr/bin/fedmsg-irc-3 python2-fedmsg:/usr/bin/fedmsg-irc
python3-fedmsg:/usr/bin/fedmsg-irc-3.7 python2-fedmsg:/usr/bin/fedmsg-irc
python3-fedmsg:/usr/bin/fedmsg-logger-3 python2-fedmsg:/usr/bin/fedmsg-logger
python3-fedmsg:/usr/bin/fedmsg-logger-3.7 python2-fedmsg:/usr/bin/fedmsg-logger
python3-fedmsg:/usr/bin/fedmsg-relay-3 python2-fedmsg:/usr/bin/fedmsg-relay
python3-fedmsg:/usr/bin/fedmsg-relay-3.7 python2-fedmsg:/usr/bin/fedmsg-relay
python3-fedmsg:/usr/b

Re: google-oauth-java-client / javapackages-tools

[Miro Hrončok]

On 22. 07. 19 11:39, Richard W.M. Jones wrote:

On Mon, Jul 22, 2019 at 10:47:10AM +0200, Miro Hrončok wrote:

See this report online at:
https://churchyard.fedorapeople.org/orphans-2019-07-22.txt


Since the majority of new failures (394!) are caused by the orphaning
of google-oauth-java-client, I looked at the full report and seems
this is a dependency of javapackages-tools (via gradle), and this
package is used to compile most Java code:

Depending on: google-oauth-java-client (394), status change: 2019-07-11 (1 
weeks ago)
   gradle (maintained by: jjelen, mizdebsk, stewardship-sig)
 gradle-4.4.1-3.fc31.src requires 
mvn(com.google.oauth-client:google-oauth-client) = 1.22.0, mvn(com.sun:tools) = 
SYSTEM
 gradle-4.4.1-3.fc31.noarch requires javapackages-tools = 5.3.0-4.fc30

  javapackages-tools (maintained by: mizdebsk, msrb)
  gradle-local-5.3.0-4.fc30.noarch requires gradle = 4.4.1-3.fc31

I don't know much about Java packages but could this dependency be
dropped?  I can't imagine that an OAuth client can be important for a
compiler tool.


Makes perfect sense: https://www.pagure.io/stewardship-sig/issue/39

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned python-rpyc, python-WSGIProxy2, python-http-parser, python-lockfile, python-plumbum, python-socketpool, python-webtest, python-flask-script

[Miro Hrončok]

On 19. 07. 19 10:52, Miro Hrončok wrote:
Hello, I've just orphaned python-CacheControl and python-django-countries by the 
request of the previous maintainer.


Orphaned:

python-rpyc
python-WSGIProxy2
python-http-parser
python-lockfile
python-plumbum
python-socketpool
python-webtest
python-flask-script

For the same reason.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Beginner SPECfile Guide

[Miroslav Suchý]

Dne 19. 07. 19 v 11:53 Lukas Javorsky napsal(a):
> Hello, I was wondering if there is some kind of video guide from some 
> conference or lecture about SPECfiles. I am a
> beginner in SPECfiles and I've read a lot stuff about them, but it is too 
> much text. I would really appreciate some
> video tutorial, it would help me a lot.


https://xsuchy.github.io/rpm-spec-wizard/
The front page is ugly, but just click on the button in upper-left corner and 
then it is nice, full of pointers.

And bunch of materials are linked from here
  
https://docs.pagure.org/copr.copr/user_documentation.html#how-can-i-package-software-as-rpm
including some video recordings.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: google-oauth-java-client / javapackages-tools (was: Re: Orphaned packages looking for new maintainers (75 to be retired))

[Fabio Valentini]

On Mon, Jul 22, 2019 at 12:33 PM Richard W.M. Jones  wrote:
>
> On Mon, Jul 22, 2019 at 10:47:10AM +0200, Miro Hrončok wrote:
> > See this report online at:
> > https://churchyard.fedorapeople.org/orphans-2019-07-22.txt
>
> Since the majority of new failures (394!) are caused by the orphaning
> of google-oauth-java-client, I looked at the full report and seems
> this is a dependency of javapackages-tools (via gradle), and this
> package is used to compile most Java code:
>
> Depending on: google-oauth-java-client (394), status change: 2019-07-11 (1 
> weeks ago)
>   gradle (maintained by: jjelen, mizdebsk, stewardship-sig)
>  gradle-4.4.1-3.fc31.src requires 
> mvn(com.google.oauth-client:google-oauth-client) = 1.22.0, mvn(com.sun:tools) 
> = SYSTEM
>  gradle-4.4.1-3.fc31.noarch requires javapackages-tools = 5.3.0-4.fc30
>
>  javapackages-tools (maintained by: mizdebsk, msrb)
>  gradle-local-5.3.0-4.fc30.noarch requires gradle = 4.4.1-3.fc31
>
> I don't know much about Java packages but could this dependency be
> dropped?  I can't imagine that an OAuth client can be important for a
> compiler tool.
>
> Rich.

I've been looking into gradle for the Stewardship SIG, but things
don't look good.

- The current version of gradle in rawhide and fedora 30 FTBFS because
it cannot build itself.
- The fedora package is 23 (!) stable releases behind the latest upstream.
- It doesn't even install on 32bit architectures, because eclipse-jgit
dropped support for these.

gradle itself is actually only used for building a very small
percentage of Java packages, the majority is built with maven or ant.

This is why we've been discussing if we should drop gradle from the
SIG packages (or altogether) -- because we simply don't have the
manpower and know-how to get it into shape again.

Additionally, tt's already not supported by the
javapackages-tools-201901 module anymore, where support for gradle
builds was disabled in all relevant packages.

Fabio

> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: First experience with building a module: newbie queries

[Petr Pisar]

On 2019-07-20, Ankur Sinha  wrote:
> 1. Why did that create 4 module build jobs for each stream?
>
> (ins)[asinha@ankur-pc  nest(2.18.0=3D)]$ fedpkg module-build
> Submitting the module build...
> The builds 5109, 5110, 5111 and 5112 were submitted to the MBS
> Build URLs:
> https://mbs.fedoraproject.org/module-build-service/2/module-builds/5109
> https://mbs.fedoraproject.org/module-build-service/2/module-builds/5110
> https://mbs.fedoraproject.org/module-build-service/2/module-builds/5111
> https://mbs.fedoraproject.org/module-build-service/2/module-builds/5112
>
Because your modulemd file contains:

dependencies:
  - buildrequires:
platform: [] # <- Build for all Fedora releases
requires:
platform: [] # <- Run on all Fedora releases

That means a Moduile Build Service (MBS) will spawn build for each
supported Fedora release (31, 30, etc.). 

> 2. 1/4 build failed for each stream. How would I debug this?
> https://release-engineering.github.io/mbs-ui/module/5116
> https://release-engineering.github.io/mbs-ui/module/5109
>
I recomend you using MBS API directly. E.g.

shows a module build for Fedora 28 ("platform" build-dependency stream
is "f28"). And shows that a Koji task #36370696 for
a module-build-macros package failed. In Koji
 you can
see waitrepo subtask failed with:

GenericError: Unsuccessfully waited 120:24 for a new
module-nest-2.16.0-2820190720172353-9c690d0e-build repo

The reason is that Fedora 28 is not supported Fedora release anymore and
Koji does not create repositories for them anymore. Thus the just
built module-build-macros for Fedora 28 will never appear in Fedora 28
build repository and thus the waitrepo task times out.

MBS should not schedule builds for Fedora 28. This is a bug in Product
Definition Center datatabase probably. I requested fixing that
 a month ago, but so for nobody
responded.

> 3. And finally: version 2.18.0 is already available in the repos (the
> platform?). So, did I mess up by requesting a stream for this version
> too? How do I make this the "default" module? File a FESCo ticket and so
> on?
>
I believe that it's not allowed to override a non-modular package by
a modular one in Fedora. I also believe that Fedora still does not
support having modules in non-modular build root repository.

If these assumptions are correct, you have two choices:

(1) Retire nest package in non-modular Fedora and make the 2.18.0 stream
of the module a default one by submitting a pull request with the
definition to .
A drawback is that anybody who wanted to use nest for building his
packages will have to modularize them first.

(2) Just don't create any default stream of the nest module. People will
stil use the non-modular one. Those who needs a different version
can enable a particular stream themselves on their systems. You also
don't have to submit the 2.18.0 modular build to Bodhi if you do not
want to maintain it in addition to the non-modular nest package.

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

Re: Orphaned packages looking for new maintainers (75 to be retired)

[Michael J Gruber]

Note that javapackages-tools provides jpackage-utils, so apparantly some of 
these reports are wrong. But it might be a good idea to update the requires 
instead of considering this a virtual (feature) provide.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Neal Gompa]

On Mon, Jul 22, 2019 at 4:00 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
> > On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
> > > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý  
> > > > wrote:
> > > > >
> > > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
> > > > > > 2. adduser/group/etc. => sysusers files
> > > > >
> > > > > For anyone willing to do this in advance on his/her package - this is 
> > > > > how you can do that:
> > > > >
> > > > > https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc3cf4eb091d8ebb36020237
> > > > >
> > > > > Here is relevant FPC ticket:
> > > > >   https://pagure.io/packaging-committee/issue/442
> > > > >
> > > > > Just for the record - this does not make things to run faster. You 
> > > > > still have to have %pre scriptlets. It is likely even
> > > > > slower as you are running %posttranstrigger as well. The benefit is 
> > > > > here only that we move toward declarative specification.
> > > > >
> > > >
> > > > That’s also going to fail, because the %pre script executes before the
> > > > file exists. That’s why these guidelines are broken, and why I
> > > > suggested we deal with sysusers differently.
> > >
> > > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
> > > %sysusers_create is "deprecated. Use %sysusers_create_package instead".
> > >
> >
> > And to note, even this change doesn't work:
> > https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec2ae18d18d6d090928f9084
> >
> >
> > The reason it doesn't work is because this scriptlet will fail to
> > locate the file needed to actually do this. The macro was written in
> > mind for being pointed to the file in the sources directly, rather
> > than having a path to assume.
>
> Can you explain what exactly is wrong? It looks OK to me.
>

How is it supposed to find the mock.conf sysusers file?
%sysusers_create_package expects you to tell it where the file is so
that it can be parsed and expanded at package build time. That's not
being done here...



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

Re: Fedora 31 Self-Contained Change proposal: Limit Scriptlet Usage of core packages

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 22, 2019 at 07:25:50AM -0400, Neal Gompa wrote:
> On Mon, Jul 22, 2019 at 4:00 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sun, Jul 21, 2019 at 01:03:59PM -0400, Neal Gompa wrote:
> > > On Mon, Jul 15, 2019 at 11:52 AM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > On Mon, Jul 15, 2019 at 10:13:21AM -0400, Neal Gompa wrote:
> > > > > On Mon, Jul 15, 2019 at 10:04 AM Miroslav Suchý  
> > > > > wrote:
> > > > > >
> > > > > > Dne 10. 07. 19 v 9:19 James Antill napsal(a):
> > > > > > > 2. adduser/group/etc. => sysusers files
> > > > > >
> > > > > > For anyone willing to do this in advance on his/her package - this 
> > > > > > is how you can do that:
> > > > > >
> > > > > > https://github.com/rpm-software-management/mock/commit/cf4c8f076637755acc3cf4eb091d8ebb36020237
> > > > > >
> > > > > > Here is relevant FPC ticket:
> > > > > >   https://pagure.io/packaging-committee/issue/442
> > > > > >
> > > > > > Just for the record - this does not make things to run faster. You 
> > > > > > still have to have %pre scriptlets. It is likely even
> > > > > > slower as you are running %posttranstrigger as well. The benefit is 
> > > > > > here only that we move toward declarative specification.
> > > > > >
> > > > >
> > > > > That’s also going to fail, because the %pre script executes before the
> > > > > file exists. That’s why these guidelines are broken, and why I
> > > > > suggested we deal with sysusers differently.
> > > >
> > > > Oops, you're right. As /usr/lib/rpm/macros.d/macros.systemd says,
> > > > %sysusers_create is "deprecated. Use %sysusers_create_package instead".
> > > >
> > >
> > > And to note, even this change doesn't work:
> > > https://github.com/rpm-software-management/mock/commit/6bb017f7a5a62bcdec2ae18d18d6d090928f9084
> > >
> > >
> > > The reason it doesn't work is because this scriptlet will fail to
> > > locate the file needed to actually do this. The macro was written in
> > > mind for being pointed to the file in the sources directly, rather
> > > than having a path to assume.
> >
> > Can you explain what exactly is wrong? It looks OK to me.
> >
> 
> How is it supposed to find the mock.conf sysusers file?
> %sysusers_create_package expects you to tell it where the file is so
> that it can be parsed and expanded at package build time. That's not
> being done here...

Well, the file in this case is given as "mock.conf", and I see a file
with this name in the same directory as the spec file, so everything
seems to be in order.

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

Re: nettle: heads up soname bump

[Nikos Mavrogiannopoulos]

On Tue, 2019-07-16 at 06:37 -0400, Nico Kadel-Garcia wrote:
> On Tue, Jul 16, 2019 at 5:34 AM Björn 'besser82' Esser
>  wrote:
> > Am Dienstag, den 16.07.2019, 00:20 +0200 schrieb Kevin Kofler:
> > > Miro Hrončok wrote:
> > > > gnutls now cannot be rebuilt:
> > > > 
> > > > nothing provides libnettle.so.6 needed by gnutls-3.6.8-
> > > > 1.fc31.armv7hl
> > > 
> > > Don't you love circular dependencies?
> > > 
> > > This is really the biggest issue that we have: There are more and
> > > more
> > > circular dependencies. Each of them is a major PITA when trying
> > > to
> > > upgrade a
> > > library.
> 
> The common workaround is to provide a compatibility library for a
> limited period, with very careful handling of "Provides" and
> "Obsoletes" and "Conlicts" until the discrepancy is resolved. This
> has
> happened with gcc multiple times.

That makes sense when one needs to keep the old version because (1) the
new API is incompatible and applications need time to update, or (2)
the ABI compatibility must be retained across releases. We didn't care
about either in this update (we have API-compatibile release), so
indeed, if the tooling could handle such issues as it was suggested it
would save lots of work. Kudos to Daiki who handled the issues that
arised.

regards,
Nikos

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

Re: Orphaned python-rpyc, python-WSGIProxy2, python-http-parser, python-lockfile, python-plumbum, python-socketpool, python-webtest, python-flask-script

[Greg Hellings]

Can I adopt python-plumbum?

On Mon, Jul 22, 2019 at 5:27 AM Miro Hrončok  wrote:

> On 19. 07. 19 10:52, Miro Hrončok wrote:
> > Hello, I've just orphaned python-CacheControl and
> python-django-countries by the
> > request of the previous maintainer.
>
> Orphaned:
>
> python-rpyc
> python-WSGIProxy2
> python-http-parser
> python-lockfile
> python-plumbum
> python-socketpool
> python-webtest
> python-flask-script
>
> For the same reason.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Jeremy Cline]

On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
> On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline  wrote:
> >
> > On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote:
> > > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon  
> > > wrote:
> > > >
> > > > Good Morning,
> > > >
> > > > We posted this [1] blog today and want to open a mailing thread to 
> > > > garner
> > > > feedback, field questions and get some thoughts from the Community on
> > > > the approach that we in Community Platform Engineering (CPE) are taking.
> > > >
> > > > [1] 
> > > > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> > > >
> > >
> > > Two things that concern me at this time:
> >
> > 
> >
> > >
> > > > Ipsilon — Ipsilon is our identity provider. It supports multiple
> > > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …)
> > > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…).
> > > > While it was originally shipped as a tech preview in RHEL it no longer 
> > > > is and
> > > > the team working on this application has also been refocused on other 
> > > > projects.
> > > > We would like to move all our applications to use OpenID Connect or 
> > > > SAML 2.0
> > > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an
> > > > IPA-based solution, which in turn allows us to replace ipsilon by a more
> > > > maintained solution, likely Red Hat Single Sign On. The dependencies
> > > > are making this a long term effort. We will need to announce to the 
> > > > community
> > > > that this means we will shut down the public OpenID 2.0 endpoints,
> > > > which means that any community services that use this protocol need
> > > > to be moved to OpenID Connect as well.
> > >
> > > There are two issues to unpack here:
> > >
> > > 1. We use a weird custom backend and custom protocol extensions.
> > >
> > > This should definitely be replaced if it makes sense. It’s more urgent
> > > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python
> > > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS
> > > developers died a while ago…
> > >
> > > Naturally, the replacement is equally in a poor state, but may have
> > > some legs someday: https://github.com/fedora-infra/noggin
> > >
> > > 2. Ipsilon development was only considered important as part of being
> > > tech preview in RHEL and now it’s not.
> > >
> > > There are some major problems here. First of all, Ipsilon development
> > > has been gated by a single person. That person also seems to have
> > > trouble making time to review pull requests. There has been interest
> > > from the broader community about using and contributing to Ipsilon,
> > > since unlike Keycloak, it is written in an accessible language
> > > (Python).
> > >
> > > Getting Ipsilon to Python 3 would be enough for me to get started on
> > > bootstrapping some of the other interested parties onto Ipsilon, and
> > > hopefully give us a more sustainable community long-term.
> >
> > I guess my question to all this is... Why? What's the goal? If Keycloak
> > does everything Ipsilon does and more, what's the point of keeping a
> > dead project alive instead of contributing to the active, lively one?
> >
> > If there really, truly is interest from the broader community, why not
> > do a friendly fork, get all the work you want in, and see what the
> > original maintainer thinks?
> >
> 
> Keycloak is not generally Fedora contributor friendly. Aside from it
> being written in Java (which is problematic with the Java stack in
> Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
> more tied to aspects of RHEL/Fedora that make it annoying to use in
> other environments.

This sounds more like an issue with Fedora's Java stack. I don't love
Java anymore than anyone else (I think), but I really don't understand
why a language plays such a huge role.

> 
> At least with Ipsilon, the Python codebase makes it easy for a broad
> base of contributors to hack on the code. It's also much easier to set
> up than Keycloak and easier to plug into more environments.

I imagine Keycloak wouldn't be against making their project easier to
set up and plug into other environments, but maybe I'm wrong.

> 
> The biggest issue with Ipsilon as a project is the lack of awareness
> of its existence. That has allowed the fact that the maintainer hasn't
> recently been able to focus on it in a while to be unnoticed. Now that
> is changing, and this is a problem, as I outline later...
> 
> > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace
> > Pagure, or a generic notification service exists somewhere to replace
> > FMN, or whatever, why spend time on such things we could be spending
> > developing the few unique tools we need to continue building the Fedora
> > distribution? Stopping along the way to build an identity and access
> > management platform isn't going t

REMINDER: Fedora 31 Self-Contained Change proposals due Tuesday 23 July

[Ben Cotton]

Self-Contained Change proposals for Fedora 31 must be submitted (i.e.
placed into the ChangeReadyForWrangler category) by the end of
tomorrow (23 July).

I was on PTO last week, so if you were anticipating action on a Change
proposal and it hasn't happened yet, I'll work through that backlog
today.

For more development milestones in the F31 schedule, see:
https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Kevin Fenzi]

On 7/22/19 1:22 AM, Miro Hrončok wrote:
> On 16. 07. 19 20:18, Pierre-Yves Chibon wrote:
>> Good Morning,
>>
>> We posted this [1] blog today and want to open a mailing thread to garner
>> feedback, field questions and get some thoughts from the Community on
>> the approach that we in Community Platform Engineering (CPE) are taking.
>>
>> [1]
>> https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
>>
> 
> What happens to Pagure? Specifically the dist-git over Pagure part?
> 
> If it stays, the front page of a package st src.fp.o might get more love
> and replace apps.fp.o, the Issues tab could be a page that replaaces
> bugz.fp.o, etc.
> 
> That said, I'm afraid Pagure might get replaced as well, correct?

Anything is possible. Personally, I think the customization we have with
pagure over dist git makes it a better frontend for our packages that
any other solutions out there, but I am just one voice. ;)

> Anyway, I respect your decisions and I understand that maintaining
> everything was not sustainable. However I guess that if we replace
> Pagure with e.g. GitLab and all our customization is gone, 

Yeah, that would be a fair pile of work to get things into a shape we
can find usable I think. It's definitely not something that will happen
overnight.

if the Wiki
> explodes and nobody will ever fix it, 

The wiki is fully supported, at least as long as QA uses it for their
TCMS. :)


if mailman3 goes away and is
> replaced by some contracted solution, 

...which could be mailman3, just run by people who do that full time...

> and when Badges die, it will be a

Hopefully we can get enough interest to move badges to a more community
supported application.

> sad day for the Fedora contributor community, possibly making
> contributing to Fedora even harder than it become over the past few years.
> 
> Personally, I wish we had spent less engineering time in infrastructure
> on Modularity and more on the contributor UX :(
> 
> I hope this transition will go as smoothly as possible. Good luck guys!
> 
> (And please keep in mind that even if I criticize some things a lot, I
> still consider you Fedora superheros.)

Thanks. None of this is easy for us, I assure you.

kevin



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

Re: REMINDER: Fedora 31 Self-Contained Change proposals due Tuesday 23 July

[jkonecny]

Hi everyone,

In what timezone is this deadline? :)

Regards,
Jirka

On Mon, 2019-07-22 at 10:01 -0400, Ben Cotton wrote:
> Self-Contained Change proposals for Fedora 31 must be submitted (i.e.
> placed into the ChangeReadyForWrangler category) by the end of
> tomorrow (23 July).
> 
> I was on PTO last week, so if you were anticipating action on a
> Change
> proposal and it hasn't happened yet, I'll work through that backlog
> today.
> 
> For more development milestones in the F31 schedule, see:
> https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating puppet in rawhide

[Kevin Fenzi]

On 7/19/19 7:30 AM, Alfredo Moralejo Alonso wrote:
> Hi,
> 
> I created https://bugzilla.redhat.com/show_bug.cgi?id=1728768 to ask for
> puppet update in rawhide some days ago but didn't get any feedback from
> maintainers.
>
> 
> Also a PR was posted to
> https://src.fedoraproject.org/rpms/puppet/pull-request/6 with no response
> for long time.
> 
> I'm interested in getting feedback from puppet maintainers about this
> update during f31 cycle.

You could try a direct email to puppet-maintain...@fedoraproject.org

Failing that, you could try and look at starting the non responsive
maintainer policy:

https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

kevin



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

Re: REMINDER: Fedora 31 Self-Contained Change proposals due Tuesday 23 July

[Ben Cotton]

On Mon, Jul 22, 2019 at 10:29 AM  wrote:

> In what timezone is this deadline? :)
>
Deadlines are in UTC unless otherwise specified.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Fabio Valentini]

On Mon, Jul 22, 2019 at 4:59 PM Kevin Fenzi  wrote:
>
> On 7/22/19 1:22 AM, Miro Hrončok wrote:
> > On 16. 07. 19 20:18, Pierre-Yves Chibon wrote:
> >> Good Morning,
> >>
> >> We posted this [1] blog today and want to open a mailing thread to garner
> >> feedback, field questions and get some thoughts from the Community on
> >> the approach that we in Community Platform Engineering (CPE) are taking.
> >>
> >> [1]
> >> https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> >>
> >
> > What happens to Pagure? Specifically the dist-git over Pagure part?
> >
> > If it stays, the front page of a package st src.fp.o might get more love
> > and replace apps.fp.o, the Issues tab could be a page that replaaces
> > bugz.fp.o, etc.
> >
> > That said, I'm afraid Pagure might get replaced as well, correct?
>
> Anything is possible. Personally, I think the customization we have with
> pagure over dist git makes it a better frontend for our packages that
> any other solutions out there, but I am just one voice. ;)

I agree. pagure has matured quite a bit in the last year or so. For
example, the Stewardship SIG uses pagure (and pagure-over-dist-git)
for 90% of all out activities, including PRs, PR reviews, ticketing
system, ... and it works really well for that. I'd have no idea what
to replace it with should either of the pagure instances ever be shut
down (or replaced with something inferior again).

Fabio

> > Anyway, I respect your decisions and I understand that maintaining
> > everything was not sustainable. However I guess that if we replace
> > Pagure with e.g. GitLab and all our customization is gone,
>
> Yeah, that would be a fair pile of work to get things into a shape we
> can find usable I think. It's definitely not something that will happen
> overnight.
>
> if the Wiki
> > explodes and nobody will ever fix it,
>
> The wiki is fully supported, at least as long as QA uses it for their
> TCMS. :)
>
>
> if mailman3 goes away and is
> > replaced by some contracted solution,
>
> ...which could be mailman3, just run by people who do that full time...
>
> > and when Badges die, it will be a
>
> Hopefully we can get enough interest to move badges to a more community
> supported application.
>
> > sad day for the Fedora contributor community, possibly making
> > contributing to Fedora even harder than it become over the past few years.
> >
> > Personally, I wish we had spent less engineering time in infrastructure
> > on Modularity and more on the contributor UX :(
> >
> > I hope this transition will go as smoothly as possible. Good luck guys!
> >
> > (And please keep in mind that even if I criticize some things a lot, I
> > still consider you Fedora superheros.)
>
> Thanks. None of this is easy for us, I assure you.
>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Pierre-Yves Chibon]

On Mon, Jul 22, 2019 at 11:19:17AM +0200, Nicolas Mailhot via devel wrote:
> Le 2019-07-22 10:22, Miro Hrončok a écrit :
> 
> > Personally, I wish we had spent less engineering time in
> > infrastructure on Modularity and more on the contributor UX :(
> 
> It’s not just Modularity. Modularity is just a symptom. There is something
> deeply broken in the Red Hat / Fedora interface.
> 
> RHEL made Red Hat fortunes. It’s what justified the billions IBM paid for it
> (RHEL is the only Red Hat product where Red Hat completely dominates the
> market, even the best other offerings, like OpenShift, are just one among
> many).
> 
> And Fedora is RHEL’s future.
> 
> And yet what do we see ?

A team that is over-committed and try to scale down to narrow its focus and be
in a position to help more the project?
And to reinforce, I am speaking about *a team*, not in anyway the whole of Red
Hat.

[...]

> Huge Red Hat investments, in the container ecosystem. And yet we get told
> CPE is downsizing its activities, in part because all the new cool things
> happen in the container space, contributors want to work on cool things,
> Fedora/RHEL is absent from this space, packaging the things containerized
> infra need is an afterthought.

Could you expend what you mean here? I really do not follow how you go from that
first sentence to the second.
To me the relation is as obvious as "The sky is blue. And yet we are told that
ants can carry 10 to 50 times their body weight", I really do not see the
relation nor causality your use of "And yet" seems to imply :)


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

Re: Discussion around app retirements and categorizations by the CPE team

[Alexander Bokovoy]

On ma, 22 heinä 2019, Jeremy Cline wrote:

On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:

On Wed, Jul 17, 2019 at 4:31 PM Jeremy Cline  wrote:
>
> On Wed, Jul 17, 2019 at 08:33:02AM -0400, Neal Gompa wrote:
> > On Wed, Jul 17, 2019 at 6:46 AM Pierre-Yves Chibon  
wrote:
> > >
> > > Good Morning,
> > >
> > > We posted this [1] blog today and want to open a mailing thread to garner
> > > feedback, field questions and get some thoughts from the Community on
> > > the approach that we in Community Platform Engineering (CPE) are taking.
> > >
> > > [1] 
https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/
> > >
> >
> > Two things that concern me at this time:
>
> 
>
> >
> > > Ipsilon — Ipsilon is our identity provider. It supports multiple
> > > authentication protocol (OpenID 2.0, OpenID Connect, SAML 2.0, …)
> > > and multiple backends (FAS, LDAP/FreeIPA, htpasswd, system accounts…).
> > > While it was originally shipped as a tech preview in RHEL it no longer is 
and
> > > the team working on this application has also been refocused on other 
projects.
> > > We would like to move all our applications to use OpenID Connect or SAML 
2.0
> > > (instead of OpenID 2.0 with (custom) extensions) and replace FAS with an
> > > IPA-based solution, which in turn allows us to replace ipsilon by a more
> > > maintained solution, likely Red Hat Single Sign On. The dependencies
> > > are making this a long term effort. We will need to announce to the 
community
> > > that this means we will shut down the public OpenID 2.0 endpoints,
> > > which means that any community services that use this protocol need
> > > to be moved to OpenID Connect as well.
> >
> > There are two issues to unpack here:
> >
> > 1. We use a weird custom backend and custom protocol extensions.
> >
> > This should definitely be replaced if it makes sense. It’s more urgent
> > now that RHEL 6 is going EOL next year, and FAS 2 is still a Python
> > 2.6 application. FAS 3 *would* have fixed it, but interest by the FAS
> > developers died a while ago…
> >
> > Naturally, the replacement is equally in a poor state, but may have
> > some legs someday: https://github.com/fedora-infra/noggin
> >
> > 2. Ipsilon development was only considered important as part of being
> > tech preview in RHEL and now it’s not.
> >
> > There are some major problems here. First of all, Ipsilon development
> > has been gated by a single person. That person also seems to have
> > trouble making time to review pull requests. There has been interest
> > from the broader community about using and contributing to Ipsilon,
> > since unlike Keycloak, it is written in an accessible language
> > (Python).
> >
> > Getting Ipsilon to Python 3 would be enough for me to get started on
> > bootstrapping some of the other interested parties onto Ipsilon, and
> > hopefully give us a more sustainable community long-term.
>
> I guess my question to all this is... Why? What's the goal? If Keycloak
> does everything Ipsilon does and more, what's the point of keeping a
> dead project alive instead of contributing to the active, lively one?
>
> If there really, truly is interest from the broader community, why not
> do a friendly fork, get all the work you want in, and see what the
> original maintainer thinks?
>

Keycloak is not generally Fedora contributor friendly. Aside from it
being written in Java (which is problematic with the Java stack in
Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
more tied to aspects of RHEL/Fedora that make it annoying to use in
other environments.


This sounds more like an issue with Fedora's Java stack. I don't love
Java anymore than anyone else (I think), but I really don't understand
why a language plays such a huge role.


It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maintaining them grows a lot. In 2019 Fedora Java packages got dropped
by one of maintainers and that created a havoc as many packages depend
on few important ones that were suddenly not supported anymore and were
going to be orphaned.

Keycloak is actually quite more flexible in terms what it provides and
how it could be integrated than Ipsilon but it is oriented to be
integrated within applications so that both user experience and visual
experience are integrated end-to-end. In most cases that means use of
the same ecosystem (Java-based) which doesn't play well with
semi-isolated non-Java Fedora project applications we are talking about
here.


At least with Ipsilon, the Python codebase makes it easy for a broad
base of contributors to hack on the code. It's also much easier to set
up than Keycloak and easier to plug into more environments.


I imagine Keycloak wouldn't be against making their project easier to
set up and plug into other environments, but maybe I'm wrong.


It is relatively easy to set up by itself. However, here we a

Re: Discussion around app retirements and categorizations by the CPE team

[Adam Williamson]

On Mon, 2019-07-22 at 07:23 -0700, Kevin Fenzi wrote:
> 
> if the Wiki
> > explodes and nobody will ever fix it, 
> 
> The wiki is fully supported, at least as long as QA uses it for their
> TCMS. :)

...and that's likely to remain the case until someone manages to find
or write a better one :/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Nicolas Mailhot via devel]

Le 2019-07-22 17:29, Pierre-Yves Chibon a écrit :
On Mon, Jul 22, 2019 at 11:19:17AM +0200, Nicolas Mailhot via devel 
wrote:

Le 2019-07-22 10:22, Miro Hrončok a écrit :

> Personally, I wish we had spent less engineering time in
> infrastructure on Modularity and more on the contributor UX :(

It’s not just Modularity. Modularity is just a symptom. There is 
something

deeply broken in the Red Hat / Fedora interface.

RHEL made Red Hat fortunes. It’s what justified the billions IBM paid 
for it
(RHEL is the only Red Hat product where Red Hat completely dominates 
the
market, even the best other offerings, like OpenShift, are just one 
among

many).

And Fedora is RHEL’s future.

And yet what do we see ?


A team that is over-committed and try to scale down to narrow its focus 
and be

in a position to help more the project?
And to reinforce, I am speaking about *a team*, not in anyway the whole 
of Red

Hat.


Yes, sure, and it’s way better to scale down in a planned way than 
explode in flight like happened Java SIG. But, in the end, it’s the same 
root cause: inadequate level of resources just to keep going, because 
the problem space became more rich and complex, but the level of 
investment didn’t follow.


And I realize it’s a lot easier to write for someone not working @rh, 
and I’m probably making a lot of persons on the list uncomfortable, but 
how many Fedora activities need to scale down or close before someone 
tells the @rh higher ups there is a problem?




[...]

Huge Red Hat investments, in the container ecosystem. And yet we get 
told
CPE is downsizing its activities, in part because all the new cool 
things
happen in the container space, contributors want to work on cool 
things,
Fedora/RHEL is absent from this space, packaging the things 
containerized

infra need is an afterthought.


Could you expend what you mean here? I really do not follow how you go 
from that

first sentence to the second.


That was given as one of the reasons in the thread: CPE is downsizing, 
in part because there are less outsiders willing to work, because the 
cool stuff is container-side, and CPE does not do it. So we’ve slowly 
gotten to the point, where non-Fedora @rh initiatives, are vacuuming the 
cool factor space, that Fedora needs to survive and grow.


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

Summary/Minutes for today's FESCo meeting (2019-07-22)>

[Igor Gnatenko]

=
#fedora-meeting-1: FESCO (2019-07-22)
=


Meeting started by ignatenkobrain at 15:00:27 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-07-22/fesco.2019-07-22-15.00.log.html
.



Meeting summary
---
* init process  (ignatenkobrain, 15:00:31)

* #2165 F31 System-Wide Change: Golang 1.13  (ignatenkobrain, 15:04:44)
  * AGREED: APPROVED (+7, 2, -0)  (ignatenkobrain, 15:10:52)

* #2172 F31 Self-Contained Change: Limit Scriptlet Usage of core
  packages  (ignatenkobrain, 15:11:10)
  * AGREED: Change must be upgraded to System-Wide. Scriptlet types,
their replacements and approximate numbers of affected packages
should be added. (+9, 0, -0)  (ignatenkobrain, 15:24:40)

* #2168 F31 Self-Contained Change: DNF Make Best Mode the Default
  (ignatenkobrain, 15:24:46)
  * AGREED: REJECTED (+2, 0, -7)  (ignatenkobrain, 15:41:21)

* Next week's chair  (ignatenkobrain, 15:41:40)
  * ACTION: ignatenkobrain will chair next meeting  (ignatenkobrain,
15:43:41)

* Open Floor  (ignatenkobrain, 15:43:49)
  * LINK: https://pagure.io/fesco/issue/2146#comment-584080
(ignatenkobrain_, 15:44:38)

Meeting ended at 15:57:17 UTC.




Action Items

* ignatenkobrain will chair next meeting




Action Items, by person
---
* ignatenkobrain
  * ignatenkobrain will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (50)
* ignatenkobrain (34)
* contyk (32)
* mhroncok (29)
* nirik (27)
* bookwar (27)
* ignatenkobrain_ (25)
* zodbot (17)
* jforbes (17)
* zbyszek (15)
* otaylor (12)
* bcotton (1)




Generated by `MeetBot`_ 0.1.4

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

Tips to add optional arguments on dnf using plugin

[Fellipe Henrique]

Hello,

First of all, thanks for accept me on these mail list.. my first mail it's
about a issue I facing here on my job...

I need to add some optional arguments on dnf,  not a command, just a
"global" args.. eg:  $ dnf repolist --my_arg=abcd

How can I do these? Can I use plugin with these approach?

I already try to override OptionParser from cli inside Plugin class, no
success... I try just parse cli args, but dnf still says my argument if not
recognized..

Anyone, have any tips how to do that?

Best regards,

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
*Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
*
*Blog: *http:www.fellipeh.eti.br
*GitHub: https://github.com/fellipeh *
*Twitter: @fh_bash*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora-Rawhide-20190720.n.1 compose check report

[Adam Williamson]

On Sun, 2019-07-21 at 03:41 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Compose FAILS proposed Rawhide gating check!
> 24 of 47 required tests failed, 19 results missing
> openQA tests matching unsatisfied gating requirements shown with **GATING** 
> below
> Unsatisfied gating requirements that could not be mapped to openQA tests:
> MISSING: fedora.universal.i386.64bit - 
> compose.install_repository_http_graphical
> MISSING: fedora.universal.i386.64bit - compose.install_scsi_updates_img
> 
> Failed openQA tests: 93/147 (x86_64), 1/2 (arm)

There seems to be a bug in the kernel that appeared in this compose
which causes problems when booting to runlevel 3, or switching from a
graphical desktop to a VT, in VMs with the 'std' graphics driver. Which
is what openQA uses.

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

That's why almost all tests fail in this and 0721.n.0 composes. I will
try re-running the tests with a different graphics driver, in staging
and then in production if results in staging are positive.

Note that I just tested the rc1 kernel and that flat-out fails to boot
in my test VM at all, so the next compose may fail everything even if
we change the graphics card. There's an LKML thread about a similar
issue which I've tacked onto for now, will file an RH bug if it seems
necessary.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 Self-Contained Change proposal: Variable Noto Fonts

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/VariableNotoFonts

== Summary ==
This Change aims to change the priority in Google Noto to make
Variable Fonts higher than non-Variable Fonts.

== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email: ta...@redhat.com

== Detailed Description ==
The font selection to match better fonts mostly depends on the order
of the configuration files for fontconfig which is available at
/etc/fonts/conf.d as long as it is written along the templates in our
guidelines. so if we want to change that behavior for certain
languages, we usually change the priority of it.

This proposal is to give the variable fonts version of Google Noto
families higher priority than non-variable fonts in Google Noto
families, to enable the variable fonts in Google Noto.

== Benefit to Fedora ==
The variable fonts of Google Noto families supports some axes for
variations into one OpenType font file. no need to have multiple files
per variations. this saves disk spaces and give us more better
experience.

We have already enabled Google Noto as default fonts for Sinhala which
affects by this change. it may be good to have the comparison table
how it saves.

{| class="wikitable"
|-
! Language !! non-VF !! VF
|-
| Sinhala || 10.94MiB || 1.02MiB
|}

There are also the variable fonts available for other languages too
but not default fonts for them. this will gives similar benefits for
them as well if one install them instead of non-VF version of Noto:
* sans-serif
** Latin
** Arabic
** Armenian
** Bengali
** Canadian Aboriginal
** Cham
** Cherokee
** Devanagari
** Ethiopic
** Georgian
** Hebrew
** Kannada
** khmer
** Lao
** Malayalam
** Myanmar
** Tamil
** Thaana
** Thai
* serif
** Latin
** Armenian
** Ethiopic
** Georgian
** Gujarati
** Gurmukhi
** Hebrew
** Kannada
** Khmer
** Lao
** Myanmar
** Tamil
** Thai
** Tibetan
* monospace
** Latin

== Scope ==
* Proposal owners:
** Update google-noto-fonts package to change the priority of
fontconfig configuration files
** Update langpacks to replace non-VF to VF version of packages
** Update comps.xml to replace non-VF to VF version of packages
* Other developers: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)


== How To Test ==
To check if you use the variable fonts:


$ fc-match -f '%{file}' sans-serif:lang=si
/usr/share/fonts/google-noto-vf/NotoSansSinhala-VF.ttf


The filename should be obvious for the variable fonts.

== User Experience ==
Users can see more variations of fonts if applications supports.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) We can simply
revert the relevant changes to what we had before this change
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No

== Documentation ==
N/A (not a System Wide Change)



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 Self-Contained Change proposal: GHC 8.6 and Stackage LTS 13

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/GHC_8.6

== Summary ==
Update Haskell packages from GHC 8.4 to 8.6 and from Stackage LTS 12
to 13 package versions.

== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: 
* Name: [[Haskell_SIG|Haskell SIG]]
* Email: 

== Detailed Description ==
The Haskell ghc compiler will be updated to 8.6.5 (rebase from the
ghc:8.6 module stream) and package version will be updated to current
Stackage LTS 13 versions.  There will also be some packaging
improvements (doc and profiling subpackages).

== Benefit to Fedora ==

Fedora 31 will have the current stable GHC version (8.6.1 was
originally released last Sept),
and packages will be updated to more recent version from the Stackage
LTS 13 set.
The new subpackaging will allow smaller footprint Haskell development
installations without being forced to install docs and profiling
library that take up a lot of space and downloading.

== Scope ==
* Proposal owners:
** rebase ghc to 8.6.5
** update ghc-rpm-macros and cabal-rpm to allows doc and prof subpackaging
** refresh packaging to latest cabal-rpm
** update packages to latest Stackage LTS 13 versions
** build everything in a Koji f31-ghc sidetag repo
** When finished all builds will be pushed by releng to Rawhide before branching

* Other developers: N/A

* Release engineering: [https://pagure.io/releng/issue/8549 #8549]

* Policies and guidelines:
** There may be a minor revision later to update the Haskell Packaging
Guidelines

* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Upgrades of Haskell packages should work fine.
Users will then recompile their code with the latest compiler and libraries.

== How To Test ==
* dnf install ghc
* dnf install ghc ghc-doc
* dnf install ghc ghc-prof
* install ghc and cabal-install
* install pandoc, ShellCheck, git-annex
* install ghc-*-devel or ghc-*-prof or ghc-*-doc
* cabal-rpm builddep ; cabal install 

== User Experience ==
Users will be happy to have the latest stable major version of GHC and
Haskell packages available to them, and benefit from the improvements
and new compiler features it provides.

== Dependencies ==
Non really: hedgewars rebuild will be tested.

== Contingency Plan ==
* Contingency mechanism: revert and ship the same package versions as F30
* Contingency deadline: Beta freeze
* Blocks release? N/A
* Blocks product? no

== Documentation ==
* 
https://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.1-notes.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 Self-Contained Change proposal: Erlang 22

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Erlang_22

== Summary ==
Update Erlang/OTP to version 22.

== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org

== Detailed Description ==
Upgrade Erlang to version 22 which brings a lot of changes. Just a few
highlights:

* Better and faster compiler. Faster string operations which Elixir
users will benefit.
* A new experimental low-level socket API.
* Even faster SSL/TLS operations.
* Improved [http://erlang.org/doc/apps/erts/erl_dist_protocol.html
Erlang Distribution Protocol] handling when it comes to a huge
messages (splitting into smaller ones, no longer blocking).


Aside from this, we plan to improve quality of Erlang and related
packages. These are shortcomings we want to address:

* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to Journald.
* We should add ability to use D-Bus via
[https://github.com/lizenn/erlang-dbus erlang-dbus] library.
* Further improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang
Packaging Guidelines]] and promote it as the official guideline.
* Switch to rebar3 as a main build tool.

== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:

* Improved logging, better unified with the rest of system.

== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/1683660 Upgrade Erlang to the latest
version (22.0)].
** We must rebuild every package which requires NIF version (listed
below in the [[#Dependencies|Dependencies]] section) against Erlang
22.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** We need to fill new review request for
[https://github.com/travelping/ejournald erlang-ejournald]
*** We have to fill new review request for
[https://github.com/travelping/lager_journald_backend
erlang-lager_journald_backend]
** We need to fill new review request for
[https://github.com/lizenn/erlang-dbus erlang-dbus]
** Upgrade outdated packages:
*** {{package|riak|Riak}}
 {{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
** Enable Kerberos authentication in {{package|ejabberd|Ejabberd}} (finally).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Every Erlang upgrade requires the rebuilding of modules which
contains [http://www.erlang.org/doc/reference_manual/ports.html ports]
or [http://www.erlang.org/doc/tutorial/nif.html NIFs], and we will
rebuild all such modules in Fedora. However if a user has some
additional modules not available in a Fedora repository, then these
modules must be rebuilt manually.
* So-called [http://erlang.org/doc/man/HiPE_app.html HiPE] continues
to deteriorate. In this version it's barely functional and likely is
going to be removed in the next one.

== How To Test ==

* Ensure that high-grade Erlang applications are still working:
{| border="1"
|-
| '''Name''' || '''Tested'''
|-
| {{package|couchdb}}  || {{no}}
|-
| {{package|ejabberd}} || {{no}}
|-
| {{package|elixir}} || {{no}}
|-
| {{package|mochiweb}} || {{no}}
|-
| {{package|rabbitmq-server}} || {{no}}
|-
| {{package|riak}} || {{no}} (package was retired :( )
|-
| {{package|wings}} || {{no}}
|}

* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version

== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.

== Dependencies ==

The following packages must be rebuilt:

{| border="1"
|-
| '''Name''' || '''Rebuilt'''
|-
| {{package|couchdb}}  || {{no}}
|-
| {{package|erlang-basho_metrics}}  || {{no}}
|-
| {{package|erlang-bitcask}}  || {{no}}
|-
| {{package|erlang-cache_tab}}  || {{no}}
|-
| {{package|erlang-cl}}  || {{no}}
|-
| {{package|erlang-ebloom}}  || {{no}}
|-
| {{package|erlang-eleveldb}}  || {{no}}
|-
| {{package|erlang-emmap}}  || {{no}}
|-
| {{package|erlang-erlsyslog}}  || {{no}}
|-
| {{package|erlang-esasl}}  || {{no}}
|-
| {{package|erlang-esdl}}  || {{no}}
|-
| {{package|erlang-esip}}  || {{no}}
|-
| {{package|erlang-fast_tls}}  || {{no}}
|-
| {{package|erlang-fast_xml}}  || {{no}}
|-
| {{package|erlang-fast_yaml}}  || {{no}}
|-
| {{package|erlang-hyper}}  || {{no}}
|-
| {{package|erlang-iconv}}  || {{no}}
|-
| {{p

Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update

== Summary ==
Fedora currently uses the original K8 micro-architecture (without
3DNow! and other AMD-specific parts) as the baseline for its
x86_64 architecture.  This baseline dates back to 2003
and has not been updated since.  As a result, performance of Fedora is
not as good as it could be on current CPUs.

This change to update the micro-architecture level for the
architecture to something more recent.

== Owner ==
* Name: [[User:fweimer| Florian Weimer]]
* Email: [mailto:fwei...@redhat.com fwei...@redhat.com]

== Detailed Description ==

After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].

Along with AVX2, it makes sense to enable certain other CPU features
which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
earlier vector extensions such as SSE 4.2.  Details are still being
worked out.

A test rebuild of a distribution largely based on Fedora 28 showed
that there is only a small number of build failures due to the
baseline switch. Very few packages are confused about the availability
of the CMPXCHG16B instruction, leading to linking failures related to
-latomic, and there are some hard-coded floating point
results that could change due to vectorization.  (The latter is within
bounds of the usual cross-architecture variation for such tests.)

== Benefit to Fedora ==

Fedora will use current CPUs more efficiently, increasing performance
and reducing power consumption.

Moreover, when Fedora is advertised as a distribution by a compute
service provider, users can be certain that their AVX2-optimized
software will run in this environment.

== Scope ==
* Proposal owners: Update the gcc and
redhat-rpm-config package to implement the new compiler
flags.  It is expected that the new baseline will be implemented in a
new GCC -march= option for convenience.

* Other developers: Other developers may have to adjust test suites
which expect exact floating point results, and correct linking with
libatomic. They will also have to upgrade their x86-64
machines to something that can execute AVX2 instructions.

* Release engineering: [https://pagure.io/releng/issue/8513 #8513]
** All Fedora builders need to be AVX2-capable.
** Infrastructure ticket:
[https://pagure.io/fedora-infrastructure/issue/7968 #7968]
* Policies and guidelines: No guidelines need to be changed.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
Fedora installations on systems with CPUs which are not able to
execute AVX2 instructions will not be able to upgrade.

== How To Test ==
General system testing will provide test coverage for this change.

== User Experience ==
User should observe improved performance and, likely, battery life.
Developers will benefit from the knowledge that code with AVX2
optimizations will run wherever Fedora runs.

== Dependencies ==
There are no direct dependencies on this change at this time.

== Contingency Plan ==
It is possible to not implement this change, or implement a smaller
subset of it (adopting the CMPXCHG16B instruction only, for example).

* Contingency mechanism: Mass rebuild with different/previous compiler glags.
* Contingency deadline: Final mass rebuild.
* Blocks release? No.
* Blocks product? No.

== Documentation ==
The new micro-architecture baseline and the resulting requirements
need to be documented.

== Release Notes ==
Release notes must mention how users can determine whether their
system supports AVX2 prior to upgrading, for example by running
grep avx2 /proc/cpuinfo.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Jeremy Cline]

On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:
> On ma, 22 heinä 2019, Jeremy Cline wrote:
> > On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
> > > Keycloak is not generally Fedora contributor friendly. Aside from it
> > > being written in Java (which is problematic with the Java stack in
> > > Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
> > > more tied to aspects of RHEL/Fedora that make it annoying to use in
> > > other environments.
> > 
> > This sounds more like an issue with Fedora's Java stack. I don't love
> > Java anymore than anyone else (I think), but I really don't understand
> > why a language plays such a huge role.
> 
> It is mostly due to supportability of the packages in Fedora. Java
> products tend to be split into smaller packages and an overhead for
> maintaining them grows a lot. In 2019 Fedora Java packages got dropped
> by one of maintainers and that created a havoc as many packages depend
> on few important ones that were suddenly not supported anymore and were
> going to be orphaned.

The same is, I think, true of many other languages. I think it's a sign
that our approach to packaging is going to have to change. Just looking
at the package stats by language at https://libraries.io/ and comparing
it to the size of the Fedora repositories is telling.

> 
> Keycloak is actually quite more flexible in terms what it provides and
> how it could be integrated than Ipsilon but it is oriented to be
> integrated within applications so that both user experience and visual
> experience are integrated end-to-end. In most cases that means use of
> the same ecosystem (Java-based) which doesn't play well with
> semi-isolated non-Java Fedora project applications we are talking about
> here.

That's unfortunate, but I wonder how hard it would be to work with
Keycloak to make our use-case easier. Would it really be harder than
maintaining our own application for the rest of time?

> 
> > > At least with Ipsilon, the Python codebase makes it easy for a broad
> > > base of contributors to hack on the code. It's also much easier to set
> > > up than Keycloak and easier to plug into more environments.
> > 
> > I imagine Keycloak wouldn't be against making their project easier to
> > set up and plug into other environments, but maybe I'm wrong.
> 
> It is relatively easy to set up by itself. However, here we are coming
> to a traditional dichotomy on what is easy for RPM-based environment and
> what is easy for Java-based deployments. These two environments aren't
> necessarily at conflict but traditions in both camps are widely
> different.
> 
> > 
> > > 
> > > The biggest issue with Ipsilon as a project is the lack of awareness
> > > of its existence. That has allowed the fact that the maintainer hasn't
> > > recently been able to focus on it in a while to be unnoticed. Now that
> > > is changing, and this is a problem, as I outline later...
> > > 
> > > > For Fedora, though, if FreeIPA can replace FAS, or GitLab can replace
> > > > Pagure, or a generic notification service exists somewhere to replace
> > > > FMN, or whatever, why spend time on such things we could be spending
> > > > developing the few unique tools we need to continue building the Fedora
> > > > distribution? Stopping along the way to build an identity and access
> > > > management platform isn't going to make the distribution better.
> > > >
> > > 
> > > FreeIPA is a perfectly fine solution, since it's broadly available and
> > > easy to deploy. The non-Java parts (everything but Dogtag) is quite
> > > easy to understand and hack on. Reproducing the tooling and
> > > environment is easy as well. I have no problems with it other than
> > > FAS-specific functions still need implementing on top of FreeIPA
> > > (which in theory, Noggin will do). It's more complicated than I'd like
> > > in some ways, but at least setup is replicable, making it easy to do
> > > development and contribute.
> > > 
> > > As for GitLab vs Pagure, my reasoning is more or less than same as
> > > mine with Keycloak vs Ipsilon. And there *are* users other than us for
> > > both Pagure and Ipsilon.
> > 
> > Ruby is just Python without () and a lot of question marks in function
> > names. Making a code review tool + issue tracker + story board + CI
> > pipeline is an insanely difficult, complicated task. Far harder than
> > learning Ruby properly.
> > 
> > I don't mean this as an attack on any of the maintainers or contributors
> > to Pagure, just feedback. It is not pleasant to use. Not for code
> > review, not for issue tracking, not for CI. Other platforms (several of
> > them open source) are far, far better in every area and at this time I
> > wouldn't ever choose to put a project on Pagure.
> > 
> > The opportunity cost of spending developer time trying to get Pagure
> > functional is enormous. The cost of system administrator time is huge.
> > Perhaps most importantly, it sucks up huge amounts of us

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Tom Hughes]

On 22/07/2019 19:51, Ben Cotton wrote:


After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].


Going all the way to AVX2 seems like it would be, in the words
of Sir Humphrey, a very bold idea.

I just checked the five machines I run Fedora 30 on at home and
exactly one of them is AVX2 capable, namely my laptop.

My desktop is about six years old, and doesn't have it, though
that is likely to be updated soon.

My PVR machine is a similar age and I had no particular plans
to upgrade that currently.

My firewall is brand new, built a few months ago to replace
a 32 bit machine because Fedora was deprecating that! Yet it
is a low end Celeron CPU and has no AVX2 support.

The final one is a VM from a cloud provider and even updating
to their latest hardware profile doesn't get me an AVX2 capable
system.

I will need to check but I suspect there will be a fair few
production systems at work that are missing support as well.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Jason L Tibbitts III]

> "BC" == Ben Cotton  writes:

BC> * Other developers: Other developers may have to adjust test suites
BC> which expect exact floating point results, and correct linking with
BC> libatomic. They will also have to upgrade their x86-64
BC> machines to something that can execute AVX2 instructions.

[...]

BC> == Upgrade/compatibility impact ==

BC> Fedora installations on systems with CPUs which are not able to
BC> execute AVX2 instructions will not be able to upgrade.

Wow.  I understand progress, but I have to say that it's not really cool
to toss this bomb out there without some more detailed breakdown of the
impact.

For my part, I try to keep my equipment relatively up to date but I
don't want to throw something away if it's still perfectly useful.  And,
let's see, I'd have to toss out five desktops (which isn't too bad, I
guess) and probably forty perfectly functional servers, some of which
aren't really even all that old.  Heck, a dozen computational servers
would be on the block.  Even requiring avx would force me to toss a
pretty big pile of stuff.

Basically, this would force me to use something other than Fedora.  I'd
have no choice, since it wouldn't work.  I don't want to be that guy
with the 20mhz 386 that still wants others to make sure his stuff works,
but still, this seems like it's going more than just a bit too far.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Jason L Tibbitts III]

> "JLT" == Jason L Tibbitts  writes:

JLT> And, let's see, I'd have to toss out five desktops (which isn't too
JLT> bad, I guess)

I was wrong.  It would be 36 desktops.  Being charitable requires me to
assume this was proposed without adequate consideration of just how much
hardware is involved here.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Leigh Scott]

> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
> 

Time for me to switch to LinuxMint as I'm not going to be forced into hardware 
updates I can't afford.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Tom Hughes]

On 22/07/2019 20:20, Tom Hughes wrote:


My firewall is brand new, built a few months ago to replace
a 32 bit machine because Fedora was deprecating that! Yet it
is a low end Celeron CPU and has no AVX2 support.

The final one is a VM from a cloud provider and even updating
to their latest hardware profile doesn't get me an AVX2 capable
system.


By the way these two don't even have AVX never mind AVX2.


I will need to check but I suspect there will be a fair few
production systems at work that are missing support as well.


Out of 31 machines running F29 or F30 at work there are
only 9 with AVX2 support and only 18 with any AVX support.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].

While one can make a reasonable argument to bump the baseline to 
something newer than the very first K8 implmentation, jumping all the 
way up to AVX2 is insane, because it will render Fedora useless on all 
but the most recent generations of CPUs.

Because _introduced_ is long, long way from _deployed_.

Even today Intel continues to sell modern-but-non-AVX-capable CPUs under 
their Pentium and Celeron brands.  Are we going to exclude all of those 
too?

As an example, of the what, dozen or so systems I have Fedora installed 
on today, only one supports AVX2.  Three of them don't even support AVX1 
(AMD 10h and 14h).  This means that come Fedora 32, I'll be faced with 
the choice of replacing nearly every bit of kit I own.

But since anectdote != data, are there any sort of deployment numbers 
out there that show how many Fedora deployments are on AVX[2]-capable 
hardware?

> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.

I think we need to see some actual benchmarks demonstrating this.  For 
the core kernel and system libraries rather than microbenchmarks or 
specific applications that already sport AVX[2] codepaths.

BTW, it wasn't until mid-late-2018 that AAA games started to require 
AVX1.

> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.

So.. hosting providers and their users are now the sole Fedora audience?

> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.

Yeah, "they just have to upgrade their systems".  

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[David Airlie]

On Tue, Jul 23, 2019 at 5:46 AM Solomon Peachy  wrote:
>
> On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline.  AVX2 support was introduced into CPUs from 2013 to
> > 2015. See 
> > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > CPUs with AVX2].
>

Can we just kill this and pretend it was never suggested.

From a desktop point of view this would be a really bad idea, I think
you should expand your preliminary discussions to CPU vendors who
aren't Intel server chips.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Ben Cotton]

On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy  wrote:
>
> But since anectdote != data, are there any sort of deployment numbers
> out there that show how many Fedora deployments are on AVX[2]-capable
> hardware?
>
There are no stats available that could be considered defensible. At
best, we could come up with some estimates based on the stats from
other sources that we might assume have a similar profile as Fedora.
I'm not sure if that data exists anywhere, though.

My main personal machine also lacks AVX2-capable hardware, so from a
personal perspective, I'm not super keen on this change. I'm
privileged enough to be able to upgrade my hardware if required, but I
recognize that it's not a reasonable request for others.

> > Fedora will use current CPUs more efficiently, increasing performance
> > and reducing power consumption.
>
> I think we need to see some actual benchmarks demonstrating this.  For
> the core kernel and system libraries rather than microbenchmarks or
> specific applications that already sport AVX[2] codepaths.
>
I agree. It would be good to see some more specifics about what the
benefit will be. That's the only way we can decide if it's worth the
cost.

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Dominik 'Rathann' Mierzejewski]

On Monday, 22 July 2019 at 20:51, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
[...]
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.

And that's a lot of hardware. Half of my machines don't support AVX2.
If you dropped back to SSSE3 then I wouldn't complain as that would
just scrap my 32-bit only machines, but requiring AVX2 is definitely
going too far.

Anyone who wants to build a library with AVX can already do so even
if the library doesn't support runtime detection. You just build
twice, once with and once without and put the AVX-enabled version
in %{_libdir}/haswell.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Josh Boyer]

On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
>
> == Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].

Would it be possible to include some basic instructions or a script
for people to run on their systems to see if they are AVX2 compliant?
That would help them assess the impact.

josh

> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
> A test rebuild of a distribution largely based on Fedora 28 showed
> that there is only a small number of build failures due to the
> baseline switch. Very few packages are confused about the availability
> of the CMPXCHG16B instruction, leading to linking failures related to
> -latomic, and there are some hard-coded floating point
> results that could change due to vectorization.  (The latter is within
> bounds of the usual cross-architecture variation for such tests.)
>
> == Benefit to Fedora ==
>
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
>
> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.
>
> == Scope ==
> * Proposal owners: Update the gcc and
> redhat-rpm-config package to implement the new compiler
> flags.  It is expected that the new baseline will be implemented in a
> new GCC -march= option for convenience.
>
> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.
>
> * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> ** All Fedora builders need to be AVX2-capable.
> ** Infrastructure ticket:
> [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> * Policies and guidelines: No guidelines need to be changed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
> == How To Test ==
> General system testing will provide test coverage for this change.
>
> == User Experience ==
> User should observe improved performance and, likely, battery life.
> Developers will benefit from the knowledge that code with AVX2
> optimizations will run wherever Fedora runs.
>
> == Dependencies ==
> There are no direct dependencies on this change at this time.
>
> == Contingency Plan ==
> It is possible to not implement this change, or implement a smaller
> subset of it (adopting the CMPXCHG16B instruction only, for example).
>
> * Contingency mechanism: Mass rebuild with different/previous compiler glags.
> * Contingency deadline: Final mass rebuild.
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> The new micro-architecture baseline and the resulting requirements
> need to be documented.
>
> == Release Notes ==
> Release notes must mention how users can determine whether their
> system supports AVX2 prior to upgrading, for example by running
> grep avx2 /proc/cpuinfo.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedora

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[David Airlie]

On Tue, Jul 23, 2019 at 5:58 AM Ben Cotton  wrote:
>
> On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy  wrote:
> >
> > But since anectdote != data, are there any sort of deployment numbers
> > out there that show how many Fedora deployments are on AVX[2]-capable
> > hardware?
> >
> There are no stats available that could be considered defensible. At
> best, we could come up with some estimates based on the stats from
> other sources that we might assume have a similar profile as Fedora.
> I'm not sure if that data exists anywhere, though.
>
> My main personal machine also lacks AVX2-capable hardware, so from a
> personal perspective, I'm not super keen on this change. I'm
> privileged enough to be able to upgrade my hardware if required, but I
> recognize that it's not a reasonable request for others.
>
> > > Fedora will use current CPUs more efficiently, increasing performance
> > > and reducing power consumption.
> >
> > I think we need to see some actual benchmarks demonstrating this.  For
> > the core kernel and system libraries rather than microbenchmarks or
> > specific applications that already sport AVX[2] codepaths.
> >
> I agree. It would be good to see some more specifics about what the
> benefit will be. That's the only way we can decide if it's worth the
> cost.

I think we don't need to bother, there is way too much hardware still
being sold by CPU vendors that don't meet this baseline.

We aren't Apple. If you want to add avx2 optimised binaries to the
system work out how to do that, create fat binary support for Linux,
add a second set of packages for cases that it might matter etc.

Just unilaterally removing a whole chunk of the x86 architecture
support isn't a plan, benchmarks or stats won't help.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Ron Olson]

My entire involvement around Fedora is based on the fact that I was able 
to use machines that had been thrown away because they were deemed 
‘too old’. I have several servers and multiple laptops that run 
Fedora perfectly and none of them would meet this requirement, 
effectively ending any chance of using Fedora going forward.


Perhaps as a compromise there could be a ‘regular’ 64-bit and a 
64-bit-optimized-for-machines-made-after-2013 version?


Ron

On 22 Jul 2019, at 14:23, Jason L Tibbitts III wrote:


"BC" == Ben Cotton  writes:


BC> * Other developers: Other developers may have to adjust test 
suites
BC> which expect exact floating point results, and correct linking 
with
BC> libatomic. They will also have to upgrade their 
x86-64

BC> machines to something that can execute AVX2 instructions.

[...]

BC> == Upgrade/compatibility impact ==

BC> Fedora installations on systems with CPUs which are not able to
BC> execute AVX2 instructions will not be able to upgrade.

Wow.  I understand progress, but I have to say that it's not really 
cool
to toss this bomb out there without some more detailed breakdown of 
the

impact.

For my part, I try to keep my equipment relatively up to date but I
don't want to throw something away if it's still perfectly useful.  
And,

let's see, I'd have to toss out five desktops (which isn't too bad, I
guess) and probably forty perfectly functional servers, some of which
aren't really even all that old.  Heck, a dozen computational servers
would be on the block.  Even requiring avx would force me to toss a
pretty big pile of stuff.

Basically, this would force me to use something other than Fedora.  
I'd

have no choice, since it wouldn't work.  I don't want to be that guy
with the 20mhz 386 that still wants others to make sure his stuff 
works,

but still, this seems like it's going more than just a bit too far.

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

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Andre Robatino]

> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.

I hope the energy usage involved in having to buy new hardware (including 
manufacturing and shipping) is taken into account. This proposed change is 
incompatible with all 3 of my 64-bit machines (which are all refurbished, isn't 
that supposed to be good for the environment?), including one I bought just 
last year.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[David Airlie]

On Tue, Jul 23, 2019 at 6:03 AM Josh Boyer  wrote:
>
> On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other AMD-specific parts) as the baseline for its
> > x86_64 architecture.  This baseline dates back to 2003
> > and has not been updated since.  As a result, performance of Fedora is
> > not as good as it could be on current CPUs.
> >
> > This change to update the micro-architecture level for the
> > architecture to something more recent.
> >
> > == Owner ==
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> >
> > == Detailed Description ==
> >
> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline.  AVX2 support was introduced into CPUs from 2013 to
> > 2015. See 
> > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > CPUs with AVX2].
>
> Would it be possible to include some basic instructions or a script
> for people to run on their systems to see if they are AVX2 compliant?
> That would help them assess the impact.

They did below, grep avx2 /proc/cpuinfo.

But don't bother, this will just get embarrassing and turn into a pile
on. I think this should be retracted before it ends up being a
phoronix article making the project look bad.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Emmanuel Seyman]

* Josh Boyer [22/07/2019 15:56] :
>
> Would it be possible to include some basic instructions or a script
> for people to run on their systems to see if they are AVX2 compliant?
> That would help them assess the impact.

you can find your cpu model by running the command:

$ grep 'model name' /proc/cpuinfo

From there, it's a simple lookup on http://www.cpu-world.com to see
what features it has.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Tom Hughes]

On 22/07/2019 20:42, Tom Hughes wrote:

On 22/07/2019 20:20, Tom Hughes wrote:


I will need to check but I suspect there will be a fair few
production systems at work that are missing support as well.


Out of 31 machines running F29 or F30 at work there are
only 9 with AVX2 support and only 18 with any AVX support.


Out of interest I checked the OpenStreetMap servers - they
are actually running Ubuntu not Fedora but I figured it's an
interesting set of randomish production machines.

We have 85 servers enrolled in chef of which 34 have the
basic AVX and only 19 have AVX2 support.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Stephen Gallagher]

On Mon, Jul 22, 2019 at 2:52 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
...

> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.


I think it's clear just from the initial replies to this thread that
even the most involved Fedorans (AKA the ones most likely to have
access to newer hardware) would be unable to run a sizeable percentage
of their systems if the minimum requirement became AVX2+

With my FESCo hat on, I can't support this action as currently stated.
I think I'd be more inclined to consider it if the Change was proposed
as a new architecture bring-up. Effectively, this would be a whole new
architecture that would just happen to be largely compatible with
x86_64.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Felix Kaechele via devel]

On 2019-07-22 2:51 p.m., Ben Cotton wrote:


After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
CPUs with AVX2].


Here's a JSON file of all Intel CPUs that do not have any AVX extension 
support that were released after January 1, 2013:

https://odata.intel.com/API/v1_0/Products/Processors()?&$filter=not%20substringof(%27AVX%27,InstructionSetExtensions)%20and%20LaunchDate%20gt%20DateTime%272013-01-01T00:00:00.00Z%27&$format=json


There are Pentium and Celeron CPUs being released today that don't even 
support AVX.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Felix Schwarz]

Am 22.07.19 um 21:52 schrieb David Airlie:
>> On Mon, Jul 22, 2019 at 02:51:27PM -0400, Ben Cotton wrote:
>>> After preliminary discussions with CPU vendors, we propose AVX2 as the
>>> new baseline.  AVX2 support was introduced into CPUs from 2013 to
>>> 2015. See 
>>> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
>>> CPUs with AVX2].
> 
> Can we just kill this and pretend it was never suggested.

Yes, please.

Besides low-end Intel machines there are also virtual machines which might not
have AVX2.

I think the voiced opposition here should suffice to burry that proposal right
now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Neal Gompa]

On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>


I have only two computers at home with AVX2, all the rest don't have it.

Why are we considering this vs just making it so we have AVX2 run-code
that is used when the instruction is available? This seems
unnecessarily bloody...




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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Mon, Jul 22, 2019 at 03:05:15PM -0500, Ron Olson wrote:
> Perhaps as a compromise there could be a ‘regular’ 64-bit and a
> 64-bit-optimized-for-machines-made-after-2013 version?

It's not as simple as a "CPU newer than date X" cutoff -- Intel limits 
AVX support to their Xeon and Core brands only.  Their current-gen 
lower-end stuff (sold as Pentium, Celeron and Atom) doesn't support 
AVX of any flavor.  And they sell a _lot_ of those.

I think AMD's situation is a bit better, with all of their current 
processors supporting AVX, and only one (Family 16h) lacking AVX2.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Mon, Jul 22, 2019 at 04:11:32PM -0400, Stephen Gallagher wrote:
> With my FESCo hat on, I can't support this action as currently stated.
> I think I'd be more inclined to consider it if the Change was proposed
> as a new architecture bring-up. Effectively, this would be a whole new
> architecture that would just happen to be largely compatible with
> x86_64.

Now that approach makes a lot more sense!

And we could easily do some apples-to-apples system benchmarks to see if 
there's any meaningful improvements to be had.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Mon, Jul 22, 2019 at 03:54:41PM -0400, Ben Cotton wrote:
> There are no stats available that could be considered defensible. At
> best, we could come up with some estimates based on the stats from
> other sources that we might assume have a similar profile as Fedora.
> I'm not sure if that data exists anywhere, though.

But without that data, as you put it, it's hard to come up with a 
cost-benefit analysis.

One sorce of data is Steam's hardware survey.  Unfortunately they don't 
include AVX2, but their most recent stats show that 88.6% of their 
overall userbase has a CPU supporting AVX1.  Limiting that to Linux 
users the number drops to 87.2%.

  
https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam
 
> My main personal machine also lacks AVX2-capable hardware, so from a
> personal perspective, I'm not super keen on this change. I'm
> privileged enough to be able to upgrade my hardware if required, but I
> recognize that it's not a reasonable request for others.

If it was just a matter of one machine, that would be manageable, but 
pretty much everyone who's spoken up here would be faced with having to 
replace multiple systems all at once, or stop using Fedora altogether.

> I agree. It would be good to see some more specifics about what the
> benefit will be. That's the only way we can decide if it's worth the
> cost.

Honestly the proposal should have come with these benchmarks already, 
especially since they'd already rebuilt Fedora with the new 
flags...

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Josh Boyer]

On Mon, Jul 22, 2019 at 4:43 PM David Airlie  wrote:
>
> On Tue, Jul 23, 2019 at 6:03 AM Josh Boyer  wrote:
> >
> > On Mon, Jul 22, 2019 at 3:27 PM Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> > >
> > > == Summary ==
> > > Fedora currently uses the original K8 micro-architecture (without
> > > 3DNow! and other AMD-specific parts) as the baseline for its
> > > x86_64 architecture.  This baseline dates back to 2003
> > > and has not been updated since.  As a result, performance of Fedora is
> > > not as good as it could be on current CPUs.
> > >
> > > This change to update the micro-architecture level for the
> > > architecture to something more recent.
> > >
> > > == Owner ==
> > > * Name: [[User:fweimer| Florian Weimer]]
> > > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> > >
> > > == Detailed Description ==
> > >
> > > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > > new baseline.  AVX2 support was introduced into CPUs from 2013 to
> > > 2015. See 
> > > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > > CPUs with AVX2].
> >
> > Would it be possible to include some basic instructions or a script
> > for people to run on their systems to see if they are AVX2 compliant?
> > That would help them assess the impact.
>
> They did below, grep avx2 /proc/cpuinfo.

Ah, I completely glossed over that.  My apologies.

> But don't bother, this will just get embarrassing and turn into a pile
> on. I think this should be retracted before it ends up being a
> phoronix article making the project look bad.

Hm.  I don't think it needs to turn into that.  Perhaps it can lead to
a productive conversation in another way.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Adam Jackson]

On Mon, 2019-07-22 at 14:51 -0400, Ben Cotton wrote:

> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].

This is not what I'd call a good idea. I've had to shoot it down
several times on internal mailing lists for RHEL, I think it's even
less a good idea for Fedora.

Skylake Pentium and Celeron models - dating from 2015 - don't have AVX
at all. Why do we want to break them? Has Intel promised they're not
going to pull a trick like that again?

If we really want to chase after Clear Linux benchmarks then fix ld.so
to know that avx2 is a capability (like we could for i686 + sse2).
Moving the baseline like this is far, far too aggressive.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Josh Boyer]

On Mon, Jul 22, 2019 at 4:47 PM Stephen Gallagher  wrote:
>
> On Mon, Jul 22, 2019 at 2:52 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other AMD-specific parts) as the baseline for its
> > x86_64 architecture.  This baseline dates back to 2003
> > and has not been updated since.  As a result, performance of Fedora is
> > not as good as it could be on current CPUs.
> >
> > This change to update the micro-architecture level for the
> > architecture to something more recent.
> >
> ...
>
> > * Other developers: Other developers may have to adjust test suites
> > which expect exact floating point results, and correct linking with
> > libatomic. They will also have to upgrade their x86-64
> > machines to something that can execute AVX2 instructions.
>
>
> I think it's clear just from the initial replies to this thread that
> even the most involved Fedorans (AKA the ones most likely to have
> access to newer hardware) would be unable to run a sizeable percentage
> of their systems if the minimum requirement became AVX2+
>
> With my FESCo hat on, I can't support this action as currently stated.
> I think I'd be more inclined to consider it if the Change was proposed
> as a new architecture bring-up. Effectively, this would be a whole new
> architecture that would just happen to be largely compatible with
> x86_64.

That is one way.  I think there might be others.

Depending on exactly what the target usecase is, we might be able to
accommodate this under the Fedora project umbrella in a way that
doesn't require moving the entire distro immediately here.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Ron Olson]

Right, I was making a ha-ha-only-serious thought that perhaps there 
could be a spin that is specifically highly optimized for 
latest-n-greatest architectures, and if packagers want to maintain two 
different versions of x64, that’d be their choice, otherwise fallback 
to the ‘regular’ one. It certainly wouldn’t be the most popular, 
but for the folks who could stand to benefit from it, they’d know 
where to find this particular spin.


On 22 Jul 2019, at 15:19, Solomon Peachy wrote:


On Mon, Jul 22, 2019 at 03:05:15PM -0500, Ron Olson wrote:

Perhaps as a compromise there could be a ‘regular’ 64-bit and a
64-bit-optimized-for-machines-made-after-2013 version?


It's not as simple as a "CPU newer than date X" cutoff -- Intel limits
AVX support to their Xeon and Core brands only.  Their current-gen
lower-end stuff (sold as Pentium, Celeron and Atom) doesn't support
AVX of any flavor.  And they sell a _lot_ of those.

I think AMD's situation is a bit better, with all of their current
processors supporting AVX, and only one (Family 16h) lacking AVX2.

 - Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

Disabling Fedora 28 chroots in Copr

[Jakub Kadlcik]

Hello,

we have just disabled Fedora 28 chroots in Copr.

According to the Fedora wiki [1], Fedora 28 reached the end of its life
on 2019-05-28 and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-28-x86_64
- fedora-28-i386
- fedora-28-ppc64le

Additionally, according to Outdated chroots removal policy [2], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects. Read more about this
feature in the  Copr - Removing outdated chroots blog post [3].


[1] https://fedoraproject.org/wiki/End_of_life
[2] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Ben Cotton wrote:
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.

This is the price of compatibility.

> This change to update the micro-architecture level for the
> architecture to something more recent.

I don't see a practical benefit to requiring anything more recent than SSE2 
(what we currently assume) as long as upstreams still support that baseline. 
Surely a few percent of gained performance are not worth tossing out entire 
generations of hardware!

> we propose AVX2 as the new baseline.  AVX2 support was introduced into
> CPUs from 2013 to 2015. See
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].

This is absolutely unacceptable and would force me to look for a new 
distribution. Not even my Sandy Bridge Core i7 supports AVX2, not to mention 
my Core 2 Duo notebook that still runs Fedora perfectly fine right now. 
Sure, the notebook is 11 years old and the desktop 8 years, but those 
machines work perfectly fine and the desktop doesn't even perform that 
badly. If I have to choose between replacing the computers or replacing the 
distribution, my choice will be made fairly quickly.

My desktop's CPU only supports AVX 1, my notebook's CPU only up to SSSE3 (no 
SSE4 nor AVX).

> After preliminary discussions with CPU vendors,

And that pretty much says it all! Planned obsolescence anyone? No thanks!

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Adam Williamson]

On Tue, 2019-07-23 at 06:01 +1000, David Airlie wrote:
> On Tue, Jul 23, 2019 at 5:58 AM Ben Cotton  wrote:
> > On Mon, Jul 22, 2019 at 3:45 PM Solomon Peachy  wrote:
> > > But since anectdote != data, are there any sort of deployment numbers
> > > out there that show how many Fedora deployments are on AVX[2]-capable
> > > hardware?
> > > 
> > There are no stats available that could be considered defensible. At
> > best, we could come up with some estimates based on the stats from
> > other sources that we might assume have a similar profile as Fedora.
> > I'm not sure if that data exists anywhere, though.
> > 
> > My main personal machine also lacks AVX2-capable hardware, so from a
> > personal perspective, I'm not super keen on this change. I'm
> > privileged enough to be able to upgrade my hardware if required, but I
> > recognize that it's not a reasonable request for others.
> > 
> > > > Fedora will use current CPUs more efficiently, increasing performance
> > > > and reducing power consumption.
> > > 
> > > I think we need to see some actual benchmarks demonstrating this.  For
> > > the core kernel and system libraries rather than microbenchmarks or
> > > specific applications that already sport AVX[2] codepaths.
> > > 
> > I agree. It would be good to see some more specifics about what the
> > benefit will be. That's the only way we can decide if it's worth the
> > cost.
> 
> I think we don't need to bother, there is way too much hardware still
> being sold by CPU vendors that don't meet this baseline.

+1. As I wrote on the talk page for this Change I see it as a complete
non-starter. I don't think we need detailed data to just say that a
change which means Fedora won't work on all CPUs made prior to 2013
(and apparently quite a lot made since then) is a complete non-starter.

Dropping i686 is a Change I can get behind, but this one is being
proposed about a decade too early.

(For anyone collecting anecdata, though: of the 5 PCs running Fedora in
this room, I think only one would be AVX2-capable).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Jerry James]

On Mon, Jul 22, 2019 at 2:35 PM Dominik 'Rathann' Mierzejewski
 wrote:
> Anyone who wants to build a library with AVX can already do so even
> if the library doesn't support runtime detection. You just build
> twice, once with and once without and put the AVX-enabled version
> in %{_libdir}/haswell.

This possibility has been mentioned before, but nothing in Fedora owns
%{_libdir}/haswell.  Should the filesystem package own it?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Joseph D. Wagner]

On 2019-07-22 13:12, Felix Kaechele via devel wrote:


On 2019-07-22 2:51 p.m., Ben Cotton wrote:


After preliminary discussions with CPU vendors, we propose AVX2 as the
new baseline.  AVX2 support was introduced into CPUs from 2013 to
2015. See 
[https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2

CPUs with AVX2].


Here's a JSON file of all Intel CPUs that do not have any AVX extension 
support that were released after January 1, 2013:

https://odata.intel.com/API/v1_0/Products/Processors()?&$filter=not%20substringof(%27AVX%27,InstructionSetExtensions)%20and%20LaunchDate%20gt%20DateTime%272013-01-01T00:00:00.00Z%27&$format=json

There are Pentium and Celeron CPUs being released today that don't even 
support AVX.


I may have to turn in my nerd card for not being able to pull this 
myself, but what would this list look like if the baseline was SSSE3?  
Just curious.


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

Re: Discussion around app retirements and categorizations by the CPE team

[Kevin Kofler]

Jeremy Cline wrote:
> In my opinion Fedora is spinning its wheels here, and the vehicle isn't
> even pointed in the right direction. Gnome is on GitLab.  Debian and the
> graphics stack is moving to GitLab AFAIK.

KDE is also moving from Phabricator to GitLab.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Andrew Lutomirski]

> On Jul 22, 2019, at 1:21 PM, Solomon Peachy  wrote:
>
>> On Mon, Jul 22, 2019 at 04:11:32PM -0400, Stephen Gallagher wrote:
>> With my FESCo hat on, I can't support this action as currently stated.
>> I think I'd be more inclined to consider it if the Change was proposed
>> as a new architecture bring-up. Effectively, this would be a whole new
>> architecture that would just happen to be largely compatible with
>> x86_64.
>
> Now that approach makes a lot more sense!
>
> And we could easily do some apples-to-apples system benchmarks to see if
> there's any meaningful improvements to be had.
>

IMO this approach is wrong. There’s nothing special about AVX1.  There
are plenty of packages that can be built with various CPU extensions
on or off but that don’t have runtime detection. and Fedora should
have the ability to straightforwardly build multiple variants. Sure,
this might involve some rpm and dnf fiddling, but that’s nothing
compared to creating a whole new architecture.

I can imagine this working in multiple ways.  There could be something
akin to modules or maybe sub-architectures, where there are multiple
non-parallel-installable versions of various packages along with
tooling to say "optimize for this machine" or "optimize for the
following baseline".  There could also be good tooling to build
dynamically-selected libraries (/lib/hw/avx2/libfoo.so).  Fat binaries
for actual executables or some equivalent (multiple binaries with
/usr/bin/foo choosing which one to exec) could work.  Some combination
could make sense.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Robert-André Mauchin]

On Monday, 22 July 2019 20:51:27 CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> 
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
> 
> This change to update the micro-architecture level for the
> architecture to something more recent.
> 
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> 
> == Detailed Description ==
> 
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
> 

I'm in the minority here as I have only one computer which supports AVX2, so I 
would benefit from it, but even then, I wouldn't want people not being able to 
update anymore because their hardware is too old. Maybe dial the proposal back 
a bit, for example, target instructions supported by Celerons and Pentiums?

Best regards,

Robert-André

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Björn Persson]

> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.

So it looks like Fedora would no longer work on my laptop from 2013. I
could probably switch the laptop over to CentOS, but that would
restrict my ability to work on Fedora stuff. A significant part of my
Fedora work over the years has been done on that laptop. With this
change I would only be able to do Fedora work at home on my new
workstation. When a good Internet connection is available I suppose I
could SSH home and perform some tasks, but that would be more
cumbersome, which would reduce the likelihood that I'd get the work
done.

And no, I'm not going to dump a perfectly serviceable laptop in a
landfill just to accommodate Fedora.

Björn Persson


pgpIk8JLCuoQ6.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Solomon Peachy]

On Mon, Jul 22, 2019 at 02:40:29PM -0700, Joseph D. Wagner wrote:
> I may have to turn in my nerd card for not being able to pull this myself,
> but what would this list look like if the baseline was SSSE3?  Just curious.

Steam claims 97.8% of their userbase has a processor supporting SSSE3 
(vs 88.6% for AVX..)

On the AMD side, requiring SSSE3 is nearly equivalent to requiring AVX, 
in other words, post-2011 CPUs only.

Now *SS*E3 is another matter, as only the 1st-gen single-core K8 parts 
lack support, and every Intel x86_64-capable CPU supports it.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Kevin Kofler]

Dominik 'Rathann' Mierzejewski wrote:
> And that's a lot of hardware. Half of my machines don't support AVX2.
> If you dropped back to SSSE3 then I wouldn't complain as that would
> just scrap my 32-bit only machines, but requiring AVX2 is definitely
> going too far.

Requiring SSSE3 would also work for me personally, though I am not convinced 
at all that the performance win over SSE2 would be worth dropping 2 
generations of CPUs (SSE2, SSE3).

Requiring anything newer would exclude half (SSE4, AVX1) or all (AVX2) my 
computers.

> Anyone who wants to build a library with AVX can already do so even
> if the library doesn't support runtime detection. You just build
> twice, once with and once without and put the AVX-enabled version
> in %{_libdir}/haswell.

To be precise, Haswell is actually AVX2.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Björn Persson]

Solomon Peachy wrote:
> One sorce of data is Steam's hardware survey.  Unfortunately they don't 
> include AVX2, but their most recent stats show that 88.6% of their 
> overall userbase has a CPU supporting AVX1.  Limiting that to Linux 
> users the number drops to 87.2%.

A survey among Steam's customers is presumably heavily biased towards
beefy gaming machines with brand-new high-end processors. If as many as
11% lack even AVX1 in that dataset, then there must be a much higher
percentage without the newer AVX2 among non-gaming desktops and laptops.

Björn Persson


pgpBWGU0mg35z.pgp
Description: OpenPGP digital signatur
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Chris Adams]

Once upon a time, Ben Cotton  said:
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].

There are still new systems being sold that don't support AVX, much less
AVX2.  I installed an Intel Atom C3758 system today, and it doesn't
support AVX.  With the end of i686 (which I think is reasonable), this
would kill Fedora on a significant amount of hardware.

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

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Patrick Monnerat]

> After preliminary discussions with CPU vendors...

CPU vendors want to sell CPUs, while there are still plenty of running 
Sandy/Ivy bridge expensive high-end machines running that would not be 
upgradable.
Not supporting machines that are 16 years old is ok, but restricting to < 6 
years (7 years when Fedora 32 will be released) is crazy.
Requiring AVX would be more reasonable, as it will extend the maximum machine 
age to 9 years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Frank R Dana Jr.]

Plenty has already been said here about why we should not do this (and OMFG we 
should NOT do this), and I am in complete agreement. 

(I have 0 machines, of 3 in my personal network, with AVX2 support. My current 
desktop I only bought a year and a half ago, and it's not AVX2 capable! My 
laptop and fileserver are 5 and 12 years old, respectively, so good luck with 
that.)

But even if we WERE to do this, then this:

> == Release Notes ==
> Release notes must mention how users can determine whether their
> system supports AVX2 prior to upgrading, for example by running
> grep avx2 /proc/cpuinfo.

...is not an acceptable WAY to do this. 

grep /proc/cpuinfo!? Are you kidding me?

Unless it includes mechanisms in the install and upgrade process that would 
automatically prevent existing Fedora 31 users from upgrading their machines to 
a release that won't run on them, this proposal is doubly outrageous.

(I assume the F32 installer wouldn't even boot, in this proposed scenario, so 
at least new (non-)users would be covered. "...Yay.")
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Sam Varshavchik]

A brief survey of my hardware and less than half of it supports avx2.

I can't find a single enthusiastic endorsement for this proposal in this  
thread, so far; but if this proposal ends up being adopted, I hope that this  
gets announced well in advance, including a big fat banner on  
https://www.fedoraproject.org, to give everyone in the community plenty of  
time to make their own arrangements, in liue of that decision.




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

[Test-Announce] Fedora 31 Rawhide 20190722.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190722.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20190711.n.1: anaconda-31.19-1.fc31.src, 20190722.n.1: 
anaconda-31.20-1.fc31.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/31

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190722.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Igor Gnatenko]

Hi Florian,

On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
>
> == Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.

It seems that Intel is still manufacturing CPUs without AVX support
(not even talking about AVX2) in 2019. So this is clearly no-go for
me.

But I do want to see some refreshments in this area! There are
multiple options how to proceed I think:

1. Lower requirement to something like SSE4 and select other CPU
features which are available in most of CPUs for last decade.
2. Build every package on x86_64 twice (one for compatible set and one
for this new-features set), possibly by introducting sub-architecture
in koji or using koji-shadow (that's just implementation detail.
Produce an official spin which is built from these packages.
3. Invent some mechanism for selecting appropriate feature set in
runtime (somebody mentioned fat binaries in this thread).

These options can be combined.

>
> A test rebuild of a distribution largely based on Fedora 28 showed
> that there is only a small number of build failures due to the
> baseline switch. Very few packages are confused about the availability
> of the CMPXCHG16B instruction, leading to linking failures related to
> -latomic, and there are some hard-coded floating point
> results that could change due to vectorization.  (The latter is within
> bounds of the usual cross-architecture variation for such tests.)
>
> == Benefit to Fedora ==
>
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
>
> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.
>
> == Scope ==
> * Proposal owners: Update the gcc and
> redhat-rpm-config package to implement the new compiler
> flags.  It is expected that the new baseline will be implemented in a
> new GCC -march= option for convenience.
>
> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.
>
> * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> ** All Fedora builders need to be AVX2-capable.
> ** Infrastructure ticket:
> [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> * Policies and guidelines: No guidelines need to be changed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
> == How To Test ==
> General system testing will provide test coverage for this change.
>
> == User Experience ==
> User should observe improved performance and, likely, battery life.
> Developers will benefit from the knowledge that code with AVX2
> optimizations will run wherever Fedora runs.
>
> == Dependencies ==
> There are no direct dependencies on this change at this time.
>
> == Contingency Plan ==
> It is possible to not implement this change, or implement a smaller
> subset of it (adopting the CMPXCHG16B instruction only, for example).
>
> * Contingency mechanism: Mass rebuild with different/previous compiler glags.
> * Contingency deadline: Final mass rebuild.
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> The new micro-architecture baseline and the resulting requirements
> need to be documented.
>
> == Release Notes ==
> Release notes must mention how users can determine whether their
> system supports AVX2 prior to upgrading, for example by running
> grep avx2 /proc/cpuinfo.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-07-23 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

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

Fedora rawhide compose report: 20190722.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190721.n.0
NEW: Fedora-Rawhide-20190722.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  9
Dropped packages:2
Upgraded packages:   119
Downgraded packages: 0

Size of added packages:  360.84 MiB
Size of dropped packages:88.91 KiB
Size of upgraded packages:   5.47 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -258.78 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20190722.n.1.iso

= DROPPED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20190721.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: R-rpm-macros-1.0.0-1.fc31~bootstrap
Summary: Macros to help produce R packages
RPMs:R-rpm-macros
Size:9.96 KiB

Package: calcium-calculator-7.9.5-1.fc31
Summary: The Calcium Calculator
RPMs:calcium-calculator
Size:1001.77 KiB

Package: frr-7.1-1.fc31
Summary: Routing daemon
RPMs:frr
Size:15.35 MiB

Package: ghc-http-directory-0.1.5-1.fc31
Summary: Http directory listing library
RPMs:ghc-http-directory ghc-http-directory-devel
Size:651.67 KiB

Package: ghc-vty-5.21-1.fc31
Summary: A simple terminal UI library
RPMs:ghc-vty ghc-vty-devel
Size:36.76 MiB

Package: python-airspeed-0.5.11-1.fc31
Summary: A lightweight template engine compatible with Velocity
RPMs:python3-airspeed
Size:34.23 KiB

Package: python-pyelectro-0.1.9-20190720git7a64bc7.fc31
Summary: A library for analysis of electrophysiological data
RPMs:python-pyelectro-doc python3-pyelectro
Size:205.24 KiB

Package: python-vistir-0.4.3-1.fc31
Summary: Python library full of utility functions
RPMs:python3-vistir
Size:89.75 KiB

Package: tesseract-tessdata-4.0.0-5.fc31
Summary: Trained models for the Tesseract Open Source OCR Engine
RPMs:tesseract-langpack-afr tesseract-langpack-amh tesseract-langpack-ara 
tesseract-langpack-asm tesseract-langpack-aze tesseract-langpack-aze_cyrl 
tesseract-langpack-bel tesseract-langpack-ben tesseract-langpack-bod 
tesseract-langpack-bos tesseract-langpack-bre tesseract-langpack-bul 
tesseract-langpack-cat tesseract-langpack-ceb tesseract-langpack-ces 
tesseract-langpack-chi_sim tesseract-langpack-chi_sim_vert 
tesseract-langpack-chi_tra tesseract-langpack-chi_tra_vert 
tesseract-langpack-chr tesseract-langpack-cos tesseract-langpack-cym 
tesseract-langpack-dan tesseract-langpack-deu tesseract-langpack-div 
tesseract-langpack-dzo tesseract-langpack-ell tesseract-langpack-eng 
tesseract-langpack-enm tesseract-langpack-epo tesseract-langpack-est 
tesseract-langpack-eus tesseract-langpack-fao tesseract-langpack-fas 
tesseract-langpack-fil tesseract-langpack-fin tesseract-langpack-fra 
tesseract-langpack-frk tesseract-langpack-frm tesseract-langpack-fry 
tesseract-langpack-gla tesseract-langpack-gle tesseract-langpack-glg 
tesseract-langpack-grc tesseract-langpack-guj tesseract-langpack-hat 
tesseract-langpack-heb tesseract-langpack-hin tesseract-langpack-hrv 
tesseract-langpack-hun tesseract-langpack-hye tesseract-langpack-iku 
tesseract-langpack-ind tesseract-langpack-isl tesseract-langpack-ita 
tesseract-langpack-ita_old tesseract-langpack-jav tesseract-langpack-jpn 
tesseract-langpack-jpn_vert tesseract-langpack-kan tesseract-langpack-kat 
tesseract-langpack-kat_old tesseract-langpack-kaz tesseract-langpack-khm 
tesseract-langpack-kir tesseract-langpack-kmr tesseract-langpack-kor 
tesseract-langpack-kor_vert tesseract-langpack-lao tesseract-langpack-lat 
tesseract-langpack-lav tesseract-langpack-lit tesseract-langpack-ltz 
tesseract-langpack-mal tesseract-langpack-mar tesseract-langpack-mkd 
tesseract-langpack-mlt tesseract-langpack-mon tesseract-langpack-mri 
tesseract-langpack-msa tesseract-langpack-mya tesseract-langpack-nep 
tesseract-langpack-nld tesseract-langpack-nor tesseract-langpack-oci 
tesseract-langpack-ori tesseract-langpack-pan tesseract-langpack-pol 
tesseract-langpack-por tesseract-langpack-pus tesseract-langpack-que 
tesseract-langpack-ron tesseract-langpack-rus tesseract-langpack-san 
tesseract-langpack-sin tesseract-langpack-slk tesseract-langpack-slv 
tesseract-langpack-snd tesseract-langpack-spa tesseract-langpack-spa_old 
tesseract-langpack-sqi tesseract-langpack-srp tesseract-langpack-srp_latn 
tesseract-langpack-sun tesseract-langpack-swa tesseract-langpack-swe 
tesseract-langpack-syr tesseract-langpack-tam tesseract-langpack-tat 
tesseract-langpack-tel tesseract-langpack-tgk tesseract-langpack-tha 
tesseract-langpack-tir tesseract-langpack-ton tesseract-langpack-tur 
tesseract-langpack-uig tesseract-langpack-ukr tesseract-langpack-urd 
tesseract-langpack-uzb tesseract-langpack-uzb_cyrl tesseract-langpack-vie 
tesseract-langpack-yid tesseract-langpack-yor tesseract-osd 
tesseract-script-arabic tesseract-script-armenian tesseract-script-bengali 
tesseract-script-canadian_aboriginal

Fedora-Rawhide-20190722.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
24 of 47 required tests failed, 19 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.universal.i386.64bit - compose.install_repository_http_graphical
MISSING: fedora.universal.i386.64bit - compose.install_scsi_updates_img

Failed openQA tests: 78/147 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20190721.n.0):

ID: 424911  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424911
ID: 424912  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/424912
ID: 424913  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/424913
ID: 424914  Test: x86_64 Server-dvd-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424914
ID: 424920  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/424920
ID: 424923  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/424923
ID: 424924  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/424924
ID: 424925  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/424925
ID: 424926  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/424926
ID: 424940  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/424940
ID: 424944  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424944
ID: 424945  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/424945
ID: 424960  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/424960
ID: 424961  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/424961
ID: 424963  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/424963
ID: 424964  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424964
ID: 424987  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/424987
ID: 424989  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/424989
ID: 424990  Test: x86_64 universal install_repository_http_variation 
**GATING**
URL: https://openqa.fedoraproject.org/tests/424990
ID: 424991  Test: x86_64 universal install_repository_http_graphical 
**GATING**
URL: https://openqa.fedoraproject.org/tests/424991
ID: 424992  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/424992
ID: 424993  Test: x86_64 universal install_delete_pata **GATING**
URL: https://openqa.fedoraproject.org/tests/424993
ID: 424994  Test: x86_64 universal install_delete_pata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424994
ID: 424995  Test: x86_64 universal install_sata **GATING**
URL: https://openqa.fedoraproject.org/tests/424995
ID: 424996  Test: x86_64 universal install_sata@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/424996
ID: 424998  Test: x86_64 universal install_scsi_updates_img **GATING**
URL: https://openqa.fedoraproject.org/tests/424998
ID: 424999  Test: x86_64 universal install_multi **GATING**
URL: https://openqa.fedoraproject.org/tests/424999
ID: 425000  Test: x86_64 universal install_multi@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/425000
ID: 425001  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/425001
ID: 425002  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/425002
ID: 425003  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/425003
ID: 425004  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/425004
ID: 425005  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/425005
ID: 425007  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/425007
ID: 425008  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/425008
ID: 425009  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/425009
ID: 425010  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproje

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[drago01]

On Monday, July 22, 2019, Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
>
> == Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See [https://en.wikipedia.org/wiki/Advanced_Vector_
> Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
> A test rebuild of a distribution largely based on Fedora 28 showed
> that there is only a small number of build failures due to the
> baseline switch. Very few packages are confused about the availability
> of the CMPXCHG16B instruction, leading to linking failures related to
> -latomic, and there are some hard-coded floating point
> results that could change due to vectorization.  (The latter is within
> bounds of the usual cross-architecture variation for such tests.)
>
> == Benefit to Fedora ==
>
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
>
> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.
>
> == Scope ==
> * Proposal owners: Update the gcc and
> redhat-rpm-config package to implement the new compiler
> flags.  It is expected that the new baseline will be implemented in a
> new GCC -march= option for convenience.
>
> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.
>
> * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> ** All Fedora builders need to be AVX2-capable.
> ** Infrastructure ticket:
> [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> * Policies and guidelines: No guidelines need to be changed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
> == How To Test ==
> General system testing will provide test coverage for this change.
>
> == User Experience ==
> User should observe improved performance and, likely, battery life.
> Developers will benefit from the knowledge that code with AVX2
> optimizations will run wherever Fedora runs.
>
> == Dependencies ==
> There are no direct dependencies on this change at this time.
>
> == Contingency Plan ==
> It is possible to not implement this change, or implement a smaller
> subset of it (adopting the CMPXCHG16B instruction only, for example).
>
> * Contingency mechanism: Mass rebuild with different/previous compiler
> glags.
> * Contingency deadline: Final mass rebuild.
> * Blocks release? No.
> * Blocks product? No.
>
> == Documentation ==
> The new micro-architecture baseline and the resulting requirements
> need to be documented.
>
> == Release Notes ==
> Release notes must mention how users can determine whether their
> system supports AVX2 prior to upgrading, for example by running
> grep avx2 /proc/cpuinfo.
>
>
>
Please just take back this change and come back at April first if it was
supposed to be a joke - if not then submit again in about 10 years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Zamir Sun]

This sounds like 'You should stop using and contributing to Fedora for
x86_64' to me.

Technically, I don't have any concern.

Practically, as a user, I only have one machine that supports AVX2
which is my laptop.
As a packager, the main machines that I use for building and testing
my packages locally is an Intel Core 2 Duo and I expect it to serve me
another 5 years.
All my virtual machines run on i7-3770 at home which is also not AVX2
compatible.

I'd like to share some info of my other machines as well, so you
probably can have a better understanding of a lifetime of computers.
I only retired my Pentium 4 1.4GHz machine in early 2018. And I still
have an AMD Sempron 2800+ working at home without any problems,
although it is not running Fedora.
Besides that, my old ThinkPad with Pentium T4200 is serving as my NAS
running with Fedora 29.

People probably suggest me to replace some of the old machines. Sure,
but it is much more costly than switching to another operating system
such as CentOS, unless some affordable yet upstream-friendly SBSA
compliant aarch64 machine available, which is not x86_64 of course.

I believe I'm not the only one with such a long computer lifetime,
especially here in China.

So I don't think it's a good idea for this to happen within the near
future, for example, 3 years.

On Tue, Jul 23, 2019 at 3:27 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
> Fedora currently uses the original K8 micro-architecture (without
> 3DNow! and other AMD-specific parts) as the baseline for its
> x86_64 architecture.  This baseline dates back to 2003
> and has not been updated since.  As a result, performance of Fedora is
> not as good as it could be on current CPUs.
>
> This change to update the micro-architecture level for the
> architecture to something more recent.
>
> == Owner ==
> * Name: [[User:fweimer| Florian Weimer]]
> * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
>
> == Detailed Description ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See 
> [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
> A test rebuild of a distribution largely based on Fedora 28 showed
> that there is only a small number of build failures due to the
> baseline switch. Very few packages are confused about the availability
> of the CMPXCHG16B instruction, leading to linking failures related to
> -latomic, and there are some hard-coded floating point
> results that could change due to vectorization.  (The latter is within
> bounds of the usual cross-architecture variation for such tests.)
>
> == Benefit to Fedora ==
>
> Fedora will use current CPUs more efficiently, increasing performance
> and reducing power consumption.
>
> Moreover, when Fedora is advertised as a distribution by a compute
> service provider, users can be certain that their AVX2-optimized
> software will run in this environment.
>
> == Scope ==
> * Proposal owners: Update the gcc and
> redhat-rpm-config package to implement the new compiler
> flags.  It is expected that the new baseline will be implemented in a
> new GCC -march= option for convenience.
>
> * Other developers: Other developers may have to adjust test suites
> which expect exact floating point results, and correct linking with
> libatomic. They will also have to upgrade their x86-64
> machines to something that can execute AVX2 instructions.
>
> * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> ** All Fedora builders need to be AVX2-capable.
> ** Infrastructure ticket:
> [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> * Policies and guidelines: No guidelines need to be changed.
> * Trademark approval: N/A (not needed for this Change)
>
> == Upgrade/compatibility impact ==
> Fedora installations on systems with CPUs which are not able to
> execute AVX2 instructions will not be able to upgrade.
>
> == How To Test ==
> General system testing will provide test coverage for this change.
>
> == User Experience ==
> User should observe improved performance and, likely, battery life.
> Developers will benefit from the knowledge that code with AVX2
> optimizations will run wherever Fedora runs.
>
> == Dependencies ==
> There are no direct dependencies on this change at this time.
>
> == Contingency Plan ==
> It is possible to not implement this change, or implement a smaller
> subset of it (adopting the CMPXCHG16B instruction only, for example).
>
> * Contingency mechanism: Mass rebuild with different/previous compiler glags.
> * Contingency deadline: Final mass rebuild.
> * Blocks release? No.
> * Blocks produ

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Igor Gnatenko]

On Tue, Jul 23, 2019 at 4:31 AM Igor Gnatenko
 wrote:
>
> Hi Florian,
>
> On Mon, Jul 22, 2019 at 9:28 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
> >
> > == Summary ==
> > Fedora currently uses the original K8 micro-architecture (without
> > 3DNow! and other AMD-specific parts) as the baseline for its
> > x86_64 architecture.  This baseline dates back to 2003
> > and has not been updated since.  As a result, performance of Fedora is
> > not as good as it could be on current CPUs.
> >
> > This change to update the micro-architecture level for the
> > architecture to something more recent.
> >
> > == Owner ==
> > * Name: [[User:fweimer| Florian Weimer]]
> > * Email: [mailto:fwei...@redhat.com fwei...@redhat.com]
> >
> > == Detailed Description ==
> >
> > After preliminary discussions with CPU vendors, we propose AVX2 as the
> > new baseline.  AVX2 support was introduced into CPUs from 2013 to
> > 2015. See 
> > [https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> > CPUs with AVX2].
> >
> > Along with AVX2, it makes sense to enable certain other CPU features
> > which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> > earlier vector extensions such as SSE 4.2.  Details are still being
> > worked out.
>
> It seems that Intel is still manufacturing CPUs without AVX support
> (not even talking about AVX2) in 2019. So this is clearly no-go for
> me.
>
> But I do want to see some refreshments in this area! There are
> multiple options how to proceed I think:
>
> 1. Lower requirement to something like SSE4 and select other CPU
> features which are available in most of CPUs for last decade.
> 2. Build every package on x86_64 twice (one for compatible set and one
> for this new-features set), possibly by introducting sub-architecture
> in koji or using koji-shadow (that's just implementation detail.
> Produce an official spin which is built from these packages.

Thinking about this even more, it should not be very hard thing to do:

* Define new architecture in RPM/libsolv (let's call it "haswell" or
"x86_64modern")
* Define set of capabilities it should have, write appropriate check
in RPM/libdnf
* Add new architecture in Fedora Koji
* Once bootstrapped, create composes
* At some point in future, merge this arch back to x86_64 and move forward

What do you think?

> 3. Invent some mechanism for selecting appropriate feature set in
> runtime (somebody mentioned fat binaries in this thread).
>
> These options can be combined.
>
> >
> > A test rebuild of a distribution largely based on Fedora 28 showed
> > that there is only a small number of build failures due to the
> > baseline switch. Very few packages are confused about the availability
> > of the CMPXCHG16B instruction, leading to linking failures related to
> > -latomic, and there are some hard-coded floating point
> > results that could change due to vectorization.  (The latter is within
> > bounds of the usual cross-architecture variation for such tests.)
> >
> > == Benefit to Fedora ==
> >
> > Fedora will use current CPUs more efficiently, increasing performance
> > and reducing power consumption.
> >
> > Moreover, when Fedora is advertised as a distribution by a compute
> > service provider, users can be certain that their AVX2-optimized
> > software will run in this environment.
> >
> > == Scope ==
> > * Proposal owners: Update the gcc and
> > redhat-rpm-config package to implement the new compiler
> > flags.  It is expected that the new baseline will be implemented in a
> > new GCC -march= option for convenience.
> >
> > * Other developers: Other developers may have to adjust test suites
> > which expect exact floating point results, and correct linking with
> > libatomic. They will also have to upgrade their x86-64
> > machines to something that can execute AVX2 instructions.
> >
> > * Release engineering: [https://pagure.io/releng/issue/8513 #8513]
> > ** All Fedora builders need to be AVX2-capable.
> > ** Infrastructure ticket:
> > [https://pagure.io/fedora-infrastructure/issue/7968 #7968]
> > * Policies and guidelines: No guidelines need to be changed.
> > * Trademark approval: N/A (not needed for this Change)
> >
> > == Upgrade/compatibility impact ==
> > Fedora installations on systems with CPUs which are not able to
> > execute AVX2 instructions will not be able to upgrade.
> >
> > == How To Test ==
> > General system testing will provide test coverage for this change.
> >
> > == User Experience ==
> > User should observe improved performance and, likely, battery life.
> > Developers will benefit from the knowledge that code with AVX2
> > optimizations will run wherever Fedora runs.
> >
> > == Dependencies ==
> > There are no direct dependencies on this change at this time.
> >
> > == Contingency Plan ==
> > It is possible to not implement this change, or implement a smaller
> > subset of it (adopting the CMPXCHG16B instruction only, for example).
> >
> 

Re: Tips to add optional arguments on dnf using plugin

[Marek Blaha]

Each DNF command could have static method set_argparser (here is the
example from reposync plugin:
https://github.com/rpm-software-management/dnf-plugins-core/blob/master/plugins/reposync.py#L60)
which can be used for adding command specific arguments. However there
is no such method for adding global arguments.
May I ask you to elaborate your use case in more details? What are you
trying to achieve?

Regards,

Marek

--
Marek Blaha 

Red Hat Czech s.r.o.
Software Engineer

On Mon, Jul 22, 2019 at 7:59 PM Fellipe Henrique  wrote:
>
> Hello,
>
> First of all, thanks for accept me on these mail list.. my first mail it's 
> about a issue I facing here on my job...
>
> I need to add some optional arguments on dnf,  not a command, just a "global" 
> args.. eg:  $ dnf repolist --my_arg=abcd
>
> How can I do these? Can I use plugin with these approach?
>
> I already try to override OptionParser from cli inside Plugin class, no 
> success... I try just parse cli args, but dnf still says my argument if not 
> recognized..
>
> Anyone, have any tips how to do that?
>
> Best regards,
>
> T.·.F.·.A.·. S+F
> Fellipe Henrique P. Soares
>
> e-mail: > echo "lkrrovknFmsgor4ius" | perl -pe \ 's/(.)/chr(ord($1)-2*3)/ge'
> Fedora Ambassador: https://fedoraproject.org/wiki/User:Fellipeh
> Blog: http:www.fellipeh.eti.br
> GitHub: https://github.com/fellipeh
> Twitter: @fh_bash
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Discussion around app retirements and categorizations by the CPE team

[Alexander Bokovoy]

On ma, 22 heinä 2019, Jeremy Cline wrote:

On Mon, Jul 22, 2019 at 06:59:04PM +0300, Alexander Bokovoy wrote:

On ma, 22 heinä 2019, Jeremy Cline wrote:
> On Sun, Jul 21, 2019 at 05:37:10PM -0400, Neal Gompa wrote:
> > Keycloak is not generally Fedora contributor friendly. Aside from it
> > being written in Java (which is problematic with the Java stack in
> > Fedora slowly imploding...), Keycloak is a lot less flexible and a lot
> > more tied to aspects of RHEL/Fedora that make it annoying to use in
> > other environments.
>
> This sounds more like an issue with Fedora's Java stack. I don't love
> Java anymore than anyone else (I think), but I really don't understand
> why a language plays such a huge role.

It is mostly due to supportability of the packages in Fedora. Java
products tend to be split into smaller packages and an overhead for
maintaining them grows a lot. In 2019 Fedora Java packages got dropped
by one of maintainers and that created a havoc as many packages depend
on few important ones that were suddenly not supported anymore and were
going to be orphaned.


The same is, I think, true of many other languages. I think it's a sign
that our approach to packaging is going to have to change. Just looking
at the package stats by language at https://libraries.io/ and comparing
it to the size of the Fedora repositories is telling.

That or those language libraries' repositories would need to evolve too.
After all, not all of them have strong authenticity guarantees and
ability to account for changes on a local installation.


Keycloak is actually quite more flexible in terms what it provides and
how it could be integrated than Ipsilon but it is oriented to be
integrated within applications so that both user experience and visual
experience are integrated end-to-end. In most cases that means use of
the same ecosystem (Java-based) which doesn't play well with
semi-isolated non-Java Fedora project applications we are talking about
here.


That's unfortunate, but I wonder how hard it would be to work with
Keycloak to make our use-case easier. Would it really be harder than
maintaining our own application for the rest of time?

I don't think it would be hard. However, it needs coordination between
people from both problem domains. Here we exactly getting the issue CPE
tries to address: lack of resources to coordinate such kind of work.

I'm more interested in seeing how Keycloak and other Java-based
applications and libraries can be turned into more optimal payloads with
the help of Quarkus.io. This should eliminate majority of
performance/memory consumption discussions that were limiting reuse of
them outside Java ecosystem.


It all depends on what are you using it for. I'm not satisfied with
GitLab performance we see with Samba Team merge requests workflow.
GitLab UI is very slow there, for example, literally hanging up very
recent Firefox if you need to look at results of executed pipelines.


Sure, I don't think GitLab is perfect and it has its pain-points.
Working with upstream to make it better for all the communities using it
seems like a much better way to spend our collective time, though.


Probably. My practical worry here is that Fedora Project needs might
come at clash with Open Core approach of GitLab where we would be
working on something that is in the non-free core of GitLab. Many
enterprise features are fitting there.


My experience with those other tools, like GitLab, is that as soon as
you are going to solve the problems Fedora infra is facing, with those
tools, you are going to find issues everywhere and will have to
contribute to fixes to projects that might not be willing to accept
them. For various reasons, but would you have a plan how to handle that?


Yes, this is always a problem and it was not my intention to imply that
we'll just install upstream and use it for src.fedoraproject.org. It's
inevitable that there will be patches and upstream will be reluctant to
take some of them.

I'd suggest we do what we do all over the place: carry patches as
necessary. It sucks, and rebasing is non-trivial work, but I would argue
it's not nearly as much work as rebuilding everything from scratch.
That's like forking a project, but deleting all the code you forked
before you begin.


I think there is a logical mistake in the above statement because we
aren't starting from scratch here. We have pagure.io and ipsilon and a
lot of other applications already. They have a lot of deployments that
proved themselves.

What we faced with is a bit where adding new features to them means a
need to find new contributors to share the load. But I see this
happening with all 'old' technologies and code bases. As someone who
witnessed first-hand how Samba TNG fork went twenty years ago, I don't
hold any hopes for success by forking of a complex project. Instead, it
has to be a careful work on nurturing new contributors, with a mix of an
investment and opening up collaboration.


--
/ Alexander Bokovoy