F29 System Wide Change: ZRAM support for ARM images

[Jan Kurik]

= Proposed System Wide Change: ZRAM support for ARM images =
https://fedoraproject.org/wiki/Changes/ZRAMforARMimages


Owner(s):
  * Peter Robinson 


Enable ZRAM for swap on ARMv7 and aarch64 pre generated images to
improve performance and reliability on ARM Single Board Computers such
a the Raspberry Pi.


== Detailed description ==
Current Fedora release artifacts for ARM platforms enable a small
amount of swap by default. While this has generally works OK in the
past it can cause a number of issues primarily wearing out SD cards
due to excess use of wear leveling. ZRAM can mitigate this and provide
more memory for ARM SBCs by compressing part of memory and using it as
a swap space. This provides better performance and improved
reliability across this class of device which overall provides a
better end user experience.


== Scope ==

* Proposal owners:
Package and include zram config and systemd units.

* Other developers:
N/A (does not affect developers)

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

** List of deliverables:
N/A

* Policies and guidelines:
N/A (No updates to policies and guidelines required)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PTSUMYOI2U4TNJF5JPV25L74OLINX2BX/

F29 System Wide Change: uEFI for ARMv7

[Jan Kurik]

= Proposed System Wide Change: uEFI for ARMv7 =
https://fedoraproject.org/wiki/Changes/uEFIforARMv7


Owner(s):
  * Peter Robinson 


Move to uEFI as the default boot mechanism for ARMv7 devices.


== Detailed description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
aarch64.



== Scope ==
* Proposal owners:
Patches, updates to the process, testing

* Other developers:
System component owners will need to review and merge patches for
certain components.

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

** List of deliverables:
N/A

* Policies and guidelines:
N/A I don't believe this changes any policies or guidelines

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUOPRT5BYNWHYUASZGPWNSJCLZA6L55G/

Fedora 29 Change Checkpoint: Proposal submission deadline (System Wide Changes) has been reached today

[Jan Kurik]

The submission deadline for System Wide Change Proposals of Fedora 29
[1] has been reached today (on July 3rd).

From July 4th, please schedule your System Wide Changes for a next
release (Fedora 30).
The deadline for Self Contained Change Proposals is planned on July 24th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/354UVAC57KUTE46FWPUWF6UZS2CZPCYD/

F29 System Wide Change: OpenLDAP without Non-threaded Libraries

[Jan Kurik]

= Proposed System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries


Owner(s):
  * Matus Honek 


OpenLDAP will not ship non-threaded version of libldap. Instead,
libldap will be built with the same threading support as libldap_r.



== Detailed description ==
After this change the non-threaded version of libldap will not be
shipped any more. Instead, this library will rather be built the same
way as the threaded libldap_r. This has been previously discussed in
Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065] and
other distributions where this change already happened. Upstream still
supports non-threaded version of their library as it might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla) symbol names overlap which may result in
unpredictable behaviour. Immediate solution would be to symlink
libldap to libldap_r, however SONAME of the library would be the same,
hence breaking dependencies of other packages. For that reason the
solution hereby proposed should be the most convenient one.


== Scope ==
* Proposal owners:
update SPEC file so that non-threaded libldap is replaced with threaded one.

* Other developers:
None. Issues should not occur.

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

** List of deliverables:
N/A

* Policies and guidelines:
None.

* Trademark approval:
(not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LFKEVSXVGIC5RRFAJ4ECV3QBRB3X5TGA/

F29 System Wide Change: Remove Excessive Linking

[Jan Kurik]

Note from Change Wrangler: This Change Proposal requires mass rebuild.
However, two weeks ago (June 19th), we have already passed the
deadline for Change proposals requiring mass rebuild. I will leave the
decision whether this Change proposal is accepted or not to RelEng and
FESCo teams.

= Proposed System Wide Change: Remove Excessive Linking =
https://fedoraproject.org/wiki/Changes/RemoveExcessiveLinking


Owner(s):
  * Igor Gnatenko 
  * Neal Gompa 


Pass "--as-needed" flag the linker through default system-wide LDFLAGS.


== Detailed description ==
The flag ("--as-needed") tells the linker to link in the produced
binary only the libraries containing symbols actually used by the
binary itself. This binary can be either a final executale or another
library.
The use of the "--as-needed" flag allows the linker to avoid linking
extra libraries in a binary. This not only improves startup times (as
the loader does not have to load all the libraries for every step) but
might avoid the full initialization of big frameworks.


== Scope ==
* Proposal owners:
Add "-Wl,--as-needed" into RPM_LD_FLAGS (in redhat-rpm-config).

* Other developers:
Nothing should break, but immediate work-around would be to disable
this flag (will be provided in redhat-rpm-config) and fix real issue
later.

* Release engineering:
#7604 [https://pagure.io/releng/issue/7604] (mass rebuild is desired
after this change).

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
Add information how to turn it off (TODO link to FPC ticket).

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TAKTZLIWNFMVA6FAMU4QCOPF4ZV54A6G/

F29 System Wide Change: Discontinue PPC64 as Alternative Architecture

[Jan Kurik]

= Proposed System Wide Change: Discontinue PPC64 as Alternative Architecture =
https://fedoraproject.org/wiki/Changes/DiscontinuePPC64


Owner(s):
  * Dan Horák 


After a number of projects dropped support for the big endian ppc64
architecture and our move of ppc64 to "maintenance-only" mode few
releases back, now a vital dependency, the Eclipse project, stops
supporting ppc64. As a consequence we need to discontinue producing
any ppc64 content. This is a long time anticipated step as the
upstream focus on the little endian variant (ppc64le) on Linux is well
known. My email
[https://lists.fedoraproject.org/archives/list/p...@lists.fedoraproject.org/message/D6G5RQUTRYGZ5Y4XIPMADMUSH2PTZDO4/]
sent to the Fedora PPC mailing list has few more details.


== Detailed description ==
Fedora will stop producing ppc64 content - binary rpms or composes.


== Scope ==
* Proposal owners:
synchronize with rel-engs

* Other developers:
none

* Release engineering:
#7602 [https://pagure.io/releng/issues/7602]  changes in koji, bodhi
and pungi configurations are expected

** List of deliverables:
N/A

* Policies and guidelines:
none

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CBZBCLPPZE732X4O6SX53WC5L7QBB4A7/

F29 System Wide Change: Fedora 29 Boost 1.67 upgrade

[Jan Kurik]

= Proposed System Wide Change: Fedora 29 Boost 1.67 upgrade =
https://fedoraproject.org/wiki/Changes/F29Boost167


Owner(s):
  * Jonathan Wakely 


This change brings Boost 1.67.0 to Fedora 29. This will mean F29 ships
with a recent upstream Boost release.


== Detailed description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.
The equivalent changes for previous releases were Fedora 22 Change
[https://fedoraproject.org/wiki/Changes/F22Boost158] and Fedora 23
Change [https://fedoraproject.org/wiki/Changes/F23Boost159] and Fedora
24 Change [https://fedoraproject.org/wiki/Changes/F24Boost160] and
Fedora 26 Change [https://fedoraproject.org/wiki/Changes/F26Boost163]
and Fedora 27 Change
[https://fedoraproject.org/wiki/Changes/F27Boost164] and Fedora 28
Change [https://fedoraproject.org/wiki/Changes/F28Boost166].


== Scope ==
* Proposal owners:
** Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
** Request a "f29-boost" build system tag (discussion
[http://lists.fedoraproject.org/pipermail/devel/2011-November/159908.html]):
7278 (similar ticket for F28: https://pagure.io/releng/issue/7278)
** Build boost into that tag (take a look at the build #606493
[http://koji.fedoraproject.org/koji/buildinfo?buildID=606493] for
inspiration)
** Post a request for rebuilds to fedora-devel
** Work on rebuilding dependent packages in the tag.
** When most is done, re-tag all the packages to rawhide
** Watch fedora-devel and assist in rebuilding broken Boost clients
(by fixing the client, or Boost).

* Other developers:
** Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.

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

** List of deliverables:
All deliverables will include updated Boost packages.

* Policies and guidelines:
** Apart from scope, this is business as usual, so no policies, no guidelines.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6BYCYIIA4SLVN2FICAQBI6XEYK5PF7HN/

F29 System Wide Change: Zchunk Metadata

[Jan Kurik]

= Proposed System Wide Change: Zchunk Metadata =
https://fedoraproject.org/wiki/Changes/Zchunk_Metadata


Owner(s):
  * Jonathan Dieter 
  * Neal Gompa 


All dnf repository metadata will be compressed with the zchunk format
rather than xz or gzip.


== Detailed description ==
Currently Fedora's repository metadata is compressed using the xz and gzip
formats.  Zchunk is a new compression format designed to allow for highly
efficient deltas.  When Fedora's metadata is compressed using zchunk, dnf
will download only the differences between any earlier copies of the
metadata and the current version.


== Scope ==
* Proposal owners:
** Package zchunk for Fedora
** Get the pull requests to enable zchunk in dnf, libdnf, librepo, libsolv
and createrepo_c merged upstream
*** https://github.com/rpm-software-management/librepo/pull/127
*** https://github.com/openSUSE/libsolv/pull/270
*** https://github.com/rpm-software-management/dnf/pull/1107
*** https://github.com/rpm-software-management/libdnf/pull/478
*** https://github.com/rpm-software-management/createrepo_c/pull/92
** Create a new package for Fedora's zchunk dictionaries.

* Other developers:
Fedora Infrastructure needs to start creating zchunked metadata

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

** List of deliverables:
Zchunk repository metadata

* Policies and guidelines:
Packaging guidelines are not affected by this change.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4OUNZD3T3GB5H553C6INZKJ3EPAQVYVB/

F29 System Wide Change: CJK Default Fonts To Noto

[Jan Kurik]

= Proposed System Wide Change: CJK Default Fonts To Noto =
https://fedoraproject.org/wiki/Changes/CJKDefaultFontsToNoto


Owner(s):
  * Akira TAGOH 
  * Peng Wu 


Changes the default fonts for Chinese, Japanese, and Korean (CJK)
languages to Google Noto.


== Detailed description ==
This proposal is to change the default fonts for CJK languages to
Google Noto and adopts OpenType Collection format to suppress disk
space increase as far as possible. Typefaces mapping will change as
described on the Change Proposal wiki page (Change wrangler note: the
description contains tables which are not easily convertible to text,
so please follow this link to check it:
https://fedoraproject.org/wiki/Changes/CJKDefaultFontsToNoto#Detailed_Description
):


== Scope ==
* Proposal owners:
** Update CJK fonts packages with the proper priority of fontconfig config files
** Update fonts group in comps [done]

* Other developers:
** For application package maintainers:
*** Any GUI applications that don't support TTC or OTC, would need to be fixed.

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

** List of deliverables:
All of the installable images should be affected

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4HOZ5PUZXMNRACCM5QHAO5P2QTN2L2TS/

F29 Self Contained Change: Deprecate YUM 3

[Jan Kurik]

= Proposed Self Contained Change: Deprecate YUM 3 =
https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3


Owner(s):
  * Daniel Mach 


Remove yum (v3) and all related packages from Fedora.


== Detailed description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils,
* yum-metadata-parser
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.


== Scope ==
* Proposal owners:
Remove packages from the distribution: createrepo, yum, yum-langpacks,
yum-utils, yum-metadata-parser, python-urlgrabber

* Other developers:
Either remove packages from the distribution or switch them to DNF

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

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A

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

-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/S47CRUAYUAWBTMAYW2ZBKMIRVSCI7QCE/

REMINDER: Fedora 29 Change Checkpoint: Proposal submission deadline (System Wide Changes) in one week

[Jan Kurik]

Hi everyone!

The submission deadline for System Wide Change Proposals of Fedora 29
[1] is coming pretty soon - in one weeks on July 3rd.

Please, submit your System Wide Changes by this deadline, earlier
better. As the deadline applies for System Wide Changes it is always
good to have most of Self Contained Changes proposed as well. The
deadline for Self Contained Change Proposals is planned on July 24th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7ZZLJL7FHOSML6XII7SHFRHQQP32H5GO/

F29 Self Contained Change: Minishift Spin

[Jan Kurik]

= Proposed Self Contained Change: Minishift Spin  =
https://fedoraproject.org/wiki/Changes/Minishift_Spin


Owner(s):
  * Praveen Kumar 
  * Gerard Braad 


A Fedora Spin providing an easy way for minishift users to consume
fedora as an ISO.


== Detailed description ==
Minishift [https://github.com/MiniShift/minishift] provides an easy
way to create a single node Openshift cluster for developers and as of
now, we have only CentOS and b2d ISO support. It would be great if we
can have Fedora ISO support for this project so developers can have
latest and greatest container related packages.


== Scope ==
* Proposal owners:
Implement this Change.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
- Add spin to spin-kickstarts, ensure spin has been tested, and
release with rest of spins
- Ticket: #7584 [https://pagure.io/releng/issue/7584]

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IMX3STKPRYBG5B6UQJEMKTXG6KSYMIKM/

F29 System Wide Change: IBus 1.5.19

[Jan Kurik]

= Proposed System Wide Change: IBus 1.5.19 =
https://fedoraproject.org/wiki/Changes/IBus_1.5.19


Owner(s):
  * Takao Fujiwara 


IBus 1.5.19 will have two features.

# Move the input entry on IBus emoji dialog to the input entry on each
application using IBus pre-edit text so that the focus event is not
changed when the emoji typing is enabled# Ctrl-Shift-u feature of
typing Unicode code points is separated from Ctrl-Shift-e feature so
that neither an additional dialog or popup window is needed.

# Typing compose keys will have a pre-edit text



== Detailed description ==
Currently Ctrl-Shift-e launches an IBus emoji dialog and users type
emoji annotations in an input entry on the dialog and the input entry
can convert the muti-byte annotation to an emoji character, besides
ASCII annotation. However the dialog takes the current input focus in
any desktop environments and also the dialog position cannot
determined in Wayland because the dialog has no parent windows.
IBus 1.5.19 will move the input entry on the emoji dialog to the
current input context on each applications using IBus pre-edit
feature. Users type emoji annotations on the pre-edit text after they
type Ctrl-Shift-e and typing space key launches a lookup window to
show emoji candidates.
Currently Ctrl-Shift-u feature of typing Unicode code point is
consolidated in the emoji dialog because one shortcut key of
Ctrl-Shift-e can cover the feature but the code point feature would
not need to launch the dialog because the candidate character is only
one so IBus 1.5.19 will separate the Ctrl-Shift-u feature from
Ctrl-Shift-e one and both keybindings can be customizable with
ibus-setup.
Currently IBus compose feature does not show anything until the output
character is determined. IBus 1.5.9 will shows the pre-edit text
during users compose a sequence.
E.g. Multi_key-apostrophe-e outputs 'é' and shows the apostrophe as a
character on the pre-edit until 'e' is typed.


== Scope ==

* Proposal owners:
IBusEngine class will be changed in ibus-libs package to handle
Ctrl-Shift-e and Ctrl-Shift-u and it will effects all IBus engines.

* Other developers:
N/A

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

** List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IHIKAUYGSUUA6FXE5DM5KKOX7MM3INHM/

F29 System Wide Change: Modules for Everyone

[Jan Kurik]

= Proposed System Wide Change: Modules for Everyone =
https://fedoraproject.org/wiki/Changes/ModulesForEveryone


Owner(s):
  * Stephen Gallagher 
  * Langdon White 


All Fedora installations will have modular repositories enabled by default,
previously available, by default, only to Server Edition.


== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality,
allowing end-users access to alternative versions of popular software. Due
to technical limitations with package-management software, it was not
available for non-Server deployments of Fedora. Beginning with Fedora 29,
all installations of Fedora will have modules available for installation
and update. This will be done by merging the `fedora-repos-modular`
sub-package back into the `fedora-repos` package.


== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and
release-engineering to make sure that the repo subpackage merge only
happens once the libdnf enhancements are stable. We will also need to
prepare and run a Fedora Test Day with the QA team.

* Other developers:
The DNF team is already committed to providing the necessary changes for
libdnf in Fedora 29.

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

** List of deliverables:
All Fedora installations

* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this
change

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NBD45XW5275VWVTLEYH5IHAJBK5T35ZF/

F29 Self Contained Change: Origin 3.10

[Jan Kurik]

= Proposed Self Contained Change: Origin 3.10 =
https://fedoraproject.org/wiki/Changes/origin3.10


Owner(s):
  * Jakub Čajka 


Rebase of the Openshift Origin package to the latest upstream version,
along with introduction of necessary infrastructure container images.


== Detailed description ==
Rebase of the Origin package to the latest upstream release. To note
upgrade path from previous version (3.9) will not be covered by this
change(dnf update origin, will most certainly be unable to cleanly
update Origin cluster), any one interested in helping out with the
supportable update path please reach out to the change owner or any
origin maintainer. Upstream provided update ansible playbooks are
located at 
https://github.com/openshift/openshift-ansible/tree/master/playbooks/byo/openshift-cluster/upgrades


== Scope ==
* Proposal owners:
rebase of the package, creation of the missing infrastructure container images

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
None
https://pagure.io/releng/issue/7581

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
None (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JWVK5CLUDKH43PMQIGPDCNCPX6BIOWHJ/

F29 System Wide Change: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE

[Jan Kurik]

= Proposed System Wide Change: New 128-bit IEEE long double ABI for
IBM 64-bit POWER LE =
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition


Owner(s):
  * Carlos O'Donell 


Transition IBM 64-bit POWER LE systems to the new 128-bit IEEE long double ABI.


== Detailed description ==
IBM has designed a new long double ABI that adheres to the 128-bit
IEEE format. This format is more standard than the existing AIX
double-double or IBM long double (2 grouped 64-bit doubles) which has
discontinuous mantissas and is difficult for developers to use. In
Fedora 29 the plan is to switch to the new ABI for long double, while
still supporting old applications via compatibility symbols. Newly
compiled applications use either the old or new ABI but not a mix of
both. Changes are required in the core C libraries, and the compiler
and the compiler runtimes including the C++ standard libraries.
Therefore there is coordination required across the core toolchain
componenents e.g. gcc, binutils, glibc, gdb (to debug the new types).


== Scope ==
The change is relatively limited in that not many packages use the
long double floating point ABI. The double floating point ABI is much
more used, but not long double. It is estimated that few packages use
long double directly, and those packages will need to be rebuilt in
order to use the new ABI. This rebuilding can be targetted by
analyzing which packages have long double usage in their debug
information and rebuilding just those packages. However, we plan to
just use the existing mass rebuild for glibc 2.28 to handle this
issue.

* Proposal owners:
Transition glibc to float128 format for long double for IBM ppc64le.
Transition gcc to the default for long double. Ensure gdb can handle
the new types.

* Other developers:
Developers need to ensure that rawhide is stable and ready for the
Fedora 29 branch.

* Release engineering:
A mass rebuild request has been filed for the parent system-wide
change to upgrade glibc to 2.28
#7475 [https://pagure.io/releng/issue/7475]
** List of deliverables
[https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora29]:

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
Not needed for this change
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/D6OUSOCG3T7TTGIF2NLAGZZJ6YXFLW7Q/

F29 System Wide Change: The GNU C Library version 2.28

[Jan Kurik]

= Proposed System Wide Change: The GNU C Library version 2.28 =
https://fedoraproject.org/wiki/Changes/GLIBC228


Owner(s):
  * Carlos O'Donell 


Switch glibc in Fedora 29 to glibc version 2.28.


== Detailed description ==
The GNU C Library version 2.28 will be released at the beginning of
August 2018; we have started closely tracking the glibc 2.28
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 29 will branch after the
GLIBC 2.28 upstream release. However, the mass rebuild schedule means
Fedora 29 will mass rebuild (if required) just after GLIBC 2.28
upstream freezes ABI for release, so careful attention must be paid to
any last minute ABI changes.
This change also includes the following changes:
* IBM POWER LE transition to Float128 for long double.
[https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition]


== Scope ==

* Proposal owners:
Update glibc to 2.28 from tested upstream release.

* Other developers:
Developers need to ensure that rawhide is stable and ready for the
Fedora 29 branch. Given that glibc is backwards compatible and we have
been testing the new glibc in rawhide it should make very little
impact when updated.

* Release engineering:
#7475 [https://pagure.io/releng/issue/7475]: The Fedora Toolchain team
is responsible for ensuring that Fedora Rawhide stabilizes ABI before
a Fedora release, or that after the branch that the Fedora release is
rebased (a very small rebase) to the final released version. This is a
requirement for Fedora to inherit the ABI and API guarantees provided
by upstream. If a mass rebuild is required by glibc or other
components, the Fedora Toolcahin team will ensure coordination with
release engineering such that a mass rebuild uses the released version
of glibc to fix any last minute ABI changes. A mass rebuild is not
required and this is communicated to release engineering.
** List of deliverables:

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
Not needed for this change
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XOFGJVTX3RSJALZ7HYATRIPPWCQQWLGA/

Re: New FESCo Meeting Time and Ticket Policy

[Jan Kurik]

On Tue, Jun 19, 2018 at 12:37 PM, Josh Boyer  wrote:
> On Tue, Jun 19, 2018 at 3:48 AM Vít Ondruch  wrote:
>>
>>
>>
>> Dne 19.6.2018 v 04:28 Kevin Kofler napsal(a):
>> > Stephen Gallagher wrote:
>> >> * Most FESCo votes will be performed in the tickets. FESCo members will
>> >> have one week[1] from the creation of the ticket to vote. So long as at
>> >> least three members have voted, the majority of votes at the end of that
>> >> week will be counted as the result. If three votes are not received in the
>> >> first week, voting will be extended by one additional week and the minimum
>> >> required responses reduced to a single vote. If by the end of that second
>> >> week no votes have been counted, it will be treated as a vote *against*
>> >> any change requested by the reporter, thus preserving the current status
>> >> however it stands. We do not expect this clause to ever be invoked.
>> > Ouch!
>> >
>> > With the previous policy, any issues for FESCo would be tabled for a 
>> > meeting
>> > and announced on this list before the actual meeting.
>>
>> I think this ^^ is very valid point. I was used to review the tickets
>> once they were announced they will be discussed on the meeting.
>
> Out of curiosity, why did you wait?  There have been tickets in the
> past that were already dealt with in this manner and never brought to
> a meeting.
>
>> > That gave a chance to
>> > the community to comment on the ticket and/or attend the meeting to join 
>> > the
>> > discussion. Thus, the community had a chance to point out any issues with
>> > the submitted proposal before FESCo started voting.
>> >
>> > With the new policy, the voting starts immediately with the creation of the
>> > ticket (of which FESCo members get notified by mail, whereas the community
>> > at large does not) and has a short deadline of 1 week, encouraging voting
>> > sooner rather than later. As a result, FESCo members will now almost always
>> > vote based on only the submitter's biased writeup (the submitter of a
>> > proposal will rarely point out, or even be aware of, all of its drawbacks)
>> > before anybody from the community even gets a chance to see the ticket, let
>> > alone reply.
>
> Perhaps we could simply configure the FESCo queue to send email to the
> devel list.  That would give everyone the same notification and
> opportunity to comment.

Anyone who is interested in receiving notifications from the FESCo
queue can just start to watch the FESCo Pagure repo [1] (the button
with an eye in top right corner). IMO there is no need to increase the
traffic on devel@ mailing list.

[1] https://pagure.io/fesco

Jan
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/V6B4IU6AMV5B4PXOGGIWQDELQRDCQFLI/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NJISDCGZVDR7G772KFIMNPNO3N6UC22L/

REMINDER: Fedora 29 Change Checkpoint: Proposal submission deadline (System Wide Changes) in two weeks

[Jan Kurik]

Hi everyone!

The submission deadline for System Wide Change Proposals of Fedora 29
[1] is coming pretty soon - in two weeks on July 3rd.

Please, submit your System Wide Changes by this deadline, earlier
better. As the deadline applies for System Wide Changes it is always
good to have most of Self Contained Changes proposed as well. The
deadline for Self Contained Change Proposals is planned on July 24th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W5K2POXCPSJMFKCQXE27CQRDB6MZ7QZ6/

Today we have reached the Submission deadline for Change proposals of Fedora 29 requiring mass rebuild

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect today (on June 19th). All the Changes requiring
mass rebuild sent for review are going to be moved to Fedora 30
release.
The mass rebuild it self is planned on July 11th.

In case you'll need any help with your Change proposals, feel free to
contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LXU7WQNZYHKHHT4AZEU7FUDQ24Z3CLV2/

F29 System Wide Change: Rename Atomic Workstation to Silverblue

[Jan Kurik]

= Proposed System Wide Change: Rename Atomic Workstation to Silverblue =
https://fedoraproject.org/wiki/Changes/Silverblue


Owner(s):
  * Matthias Clasen 


The Atomic Workstation variant is being renamed to Fedora Silverblue.


== Detailed description ==
The Atomic Workstation is being rebranded as Fedora Silverblue, to
give this project more visibility and realize its full potential for
bringing new users to Fedora. There is new website,
www.teamsilverblue.org, which is gathering information and resources
around this effort.


== Scope ==
Concrete suggested changes:
** Change ostree repo branch name to fedora/29/x86_64/silverblue
** Change /etc/os-release to say Silverblue in the appropriate places
** Provide branding in fedora-logos package that says Silverblue
** Change install media name to Fedora-Silverblue-ostree-...

* Proposal owners:
** Provide patches for /etc/os-release and fedora-logos

* Other developers:
** Change lorax templates to refer to new branch name
** Change anaconda install media:
https://github.com/rhinstaller/anaconda/issues/1504
** Create a Silverblue install class in anaconda:
https://github.com/rhinstaller/anaconda/issues/1505
** Make necessary changes in pungi: https://pagure.io/pungi/issue/982

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

** List of deliverables:
*** The Fedora Atomic Workstation iso will be renamed to
Fedora-Silverblue-x86_64...
*** The getfedora.org webpage will need corresponding adjustments

* Policies and guidelines:
No changes

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G45DZJ52GKJU727PKAVRSIXIZR35YCSV/

F29 Self Contained Change: glibc 32 Build Adjustments

[Jan Kurik]

= Proposed Self Contained Change: glibc 32 Build Adjustments =
https://fedoraproject.org/wiki/Changes/glibc32_Build_Adjustments


Owner(s):
  * Florian Weimer 


The glibc32 package is a special package used by gcc and a few other
packages to work around the lack of RPM multilib repository support in
Koji [https://pagure.io/koji/issue/273]. It is difficult to maintain,
and the current approach raises questions regarding (L)GPL compliance.


== Detailed description ==
Some packages build non-64-bit code on 64-bit architectures, using GCC
switches such as "-m32" and "-m31".  Those that do not use "-nostdlib"
at the same time need a non-64-bit glibc as well. However, Koji cannot
currently provide such multilib RPMs; all RPM packages are either of
the build architecture or noarch packages.
In particular, GCC has a dependency on the non-64-bit (32-bit or
31-bit) glibc library.
The current hack to support GCC's need (and a few other packages) is
that a separate package, glibc32, contains pre-built 32-bit/31-bit
binaries extracted from RPMs built in Fedora some time in the past.
Since these binaries are pre-built, they can be built (actually copied
around) on any architecture, including the relevant 64-bit
architectures.
This primarily affects the x86_64 architecture and its i686 multilib
RPMs.  Historically, the same problem occurred on ppc64 (with ppc as
the multilib architecture) and s390x (with s390). However, Fedora no
longer builds non-64-bit RPM packages on these architectures.  This
also means that the ppc and s390 binaries in the glibc32 package can
no longer be recreated within Fedora, which is not sustainable.  At
the very least, these two sets of binaries would have to be removed,
effectively making the glibc32 package specific to the x86_64
architecture.
It appears that on ppc64 we still need to build GCC in such a way that
the "-m32" option is supported.  This means that some cross-package
coordination is necessary.  (A first check showed that the s390x boot
loader support is built as 64-bit binary, so "-m31" support in glibc
does not seem to be necessary for bootloader purposes.)
There are two ways to address these problems:
* Continue the current copy-based approach.  It is simplified somewhat
due to the switch to libxcrypt.  Modify the (fully manual) extraction
procedure so that the source RPM of the binary files is included as
well, to provide airtight LGPL compliance.
* Build glibc32 and libgcc32 subpackages from the glibc and gcc
packages, which are then filtered by pungi from all composes
[https://pagure.io/releng/issue/7576].  (Currently, the buildroot-only
nature of glibc32 is achieved by tagging builds appropriately in Koji,
which is rather fragile.)  The big advantage of this approach is that
the glibc32 package will always be in sync with the actual 64-bit
library.


== Scope ==
* Proposal owners:
** Drop ppc and s390 RPM contents from glibc32.  Adapt the build
procedure as agreed.

* Other developers:
** Fedora GCC developers will need to drop the build dependency on
`/usr/lib/libc.so` on ppc64 and s390x.  It may be necessary to
configure GCC with "--enable-targets=all", to support "-m32" for
building boot loaders and other freestanding code.
** The compat-gcc-* and ghdl packages may need similar adjustments.
** Other packages with a "/usr/lib/libc.so.6" build dependency
(chromium, systemtap, valgrind) appear to restricted to x86_64
already.
** If the filtered subpackage approach is chosen for Fedora 29, the
gcc package will need to be updated to build a new subpackage,
libgcc32, that contains the multilib libraries.  These will be
required for building glibc32 as a subpackage.

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

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SBGG4BZDJ4N2J33U5QCFNDS2NN4K2HQB/

F29 System Wide Change: Build non-RELRO ELF binaries with .plt.got isolation

[Jan Kurik]

= Proposed System Wide Change: Build non-RELRO ELF binaries with
.plt.got isolation =
https://fedoraproject.org/wiki/Changes/.plt.got_Isolation


Owner(s):
  * Florian Weimer 


Fedora 23 enabled  hardening for all packages. However, some ELF
binaries still use lazy binding. This change proposes additional
hardening for them.



== Detailed description ==
With the RELRO and BIND_NOW dynamic linker features, it is possible to
make the array of function pointers which is used to implement dynamic
linking (the GOT) read-only at run time. This makes it harder for
exploit writers to overwrite these function pointers and redirect
execution.
However, some ELF binaries are still built and linked without these
hardening features. Sometimes, this is due to package maintainer
preferences. Sometimes, there are technical reasons which preclude the
use of BIND_NOW because the way the application is written, it relies
on lazy binding.
This change proposes to link ELF binaries in such a way that the
.plt.got section is loaded as a separated page at run
time. As a result, it is possible to use a kernel feature called
[http://man7.org/linux/man-pages/man7/pkeys.7.html memory protection
keys] to make the GOT with its function pointer array read-only most
of the time. When the dynamic linker needs to perform a function
symbol binding, it can make the GOT temporarily writable, for the
current thread only.
Memory protection keys are currently available with the POWER
architecture (starting with POWER7), and on select Intel server CPUs.
At this time, only a subset of Fedora systems will benefit from this
hardening, so the recommendation to link with RELRO/BIND_NOW remains.

== Scope ==
* Proposal owners:
** We will work with the binutils maintainer to implement this change
in the linker, and enable it by default. (RELRO/BIND_NOW will
automatically disable it because it is not needed there.)
** The glibc dynamic linker will be updated to use this new feature.
This feature will likely arrive after the glibc 2.28 upstream release,
but it can be backported to Fedora because there is no ABI impact.

* Other developers:
In the unlikely case that an application relies on GOT patching, it
will have to specify a linker flag to disable this security hardening.

* Release engineering:
https://pagure.io/releng/issue/7575 #7575
(no release engineering impact is expected)

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
The packaging guidelines regarding build flags will not be updated.
RELRO/BIND_NOW remains the recommended approach.

* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T2MQGAMHWEMYTN6JHCAD3YTXB5S4ZVJM/

F29 System Wide Change: Binutils 2.31

[Jan Kurik]

= Proposed System Wide Change: Binutils 2.31 =
https://fedoraproject.org/wiki/Changes/BINUTILS231


Owner(s):
  * Nick Clifton 


Rebase the binutils package from version 2.30 to version 2.31.



== Detailed description ==
Switch the binutils package from being based on the 2.30 release of
the FSF binutils to being based on the 2.31 release.  This release
will bring in numerous bug fixes, as well as the following new
features:

The linker can now put all code and read-only data sections into a
separate segment with only READ and EXECUTE permissions.  All writable
data can be placed into a separate segment with READ and WRITE
permissions.  This makes programs larger, but safer.  The linker's
behaviour can be controlled via a command line option, and the default
set by a configure option.

The assembler can generate build notes for any input files which do
not contain their own notes.  Again this is controlled via a command
line option whose default is set by a configure option.

The x86 assembler supports a new -O[2|s] command-line option to enable
alternate, shorter instruction encoding.  It also supports a ,nop
pseudo-op to simplify the insertion of NOP instruction sequences.

The AArch64 assembler will now warn a combintation of an instruction
and a register name are invalid.  The AArch64 disassembler will now
also flag inconsistent instruction encodings.

The "ar" program will now accept an "O" modifier to its command line,
which causes the offsets of members within the archive to be displayed
alongside the other information.


== Scope ==
* Proposal owners:
Change the source parameter in the binutils.spec rpm and adjust the
local patches to take account of the bugs that are now already
fixed.This should be followed by a mass rebuild in order for the
changes to be noticed across the system.

* Other developers:
No other work should be necessary.  Once the rebase is in place and
the buildroot contains the new binutils its use should be automatic.It
is possible that the new linker feature might prove to be problematic
forsome packages, although no such problems are anticipated.  If this
doeshappen however the package maintainers can add a command line
optionto disable the new linker feature.

* Release engineering:
https://pagure.io/releng/issue/7573

** List of deliverables:
Just the binutils package.

* Policies and guidelines:
No updates needed.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AOIRUAYXRAH46EHTQGXAORKQDPTGTCN3/

F29 System Wide Change: Make BootLoaderSpec the default

[Jan Kurik]

= Proposed System Wide Change: Make BootLoaderSpec the default =
https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault


Owner(s):
  * Javier Martinez Canillas 
  * Peter Jones 


Use BootLoaderSpec fragment files by default to populate the
bootloaders boot menu entries.



== Detailed description ==
The [https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
Boot Loader Specification (BLS)] defines a scheme and file format to
manage boot loader configuration for each boot option in a drop-in
directory, without the need to manipulate bootloader configuration
files. These drop-in directories are the standard on Linux nowadays,
so the goal is to also extend this concept for boot menu entries.
This is especially important in Fedora because the same bootloader is
not used in all architectures. GRUB 2 is used in most of them, but
there are others such as zipl for s390x and Petitboot for ppc64le. Not
all bootloaders have the same configuration file format, so there is a
need for an indirection level and per bootloader specific logic to
edit these configuration files, when adding or removing a boot entry.
The current component that does this work is grubby, that has support
for all the different bootloader configuration file formats and
manipulates them on kernel installation or uninstallation. Besides
manipulating the bootloader configuration files, grubby also does
other things like running dracut to create an initial ramdisk image.
Fedora already has a lot of infrastructure in place to not require
modifying bootloader configuration files for boot menu entries. The
BootLoaderSpec and drop-in BLS fragments can be used instead, and the
kernel-install script can do any additional task that is currently
done by grubby. The kernel-install script has a pluggable design that
uses a drop-in directory for scripts to extend its functionality. So
if needed, any bootloader specific logic can be implemented as
kernel-install scripts.
With this setup the bootloader configuration could be static and not
modified after installation.
The missing piece was the lack of BLS support on all the supported
bootloaders, but all of them have support to parse BLS fragments now.
So we can default to install BLS files on kernel installation and drop
grubby.



== Scope ==
* Proposal owners:
** Generate BLS snippets at kernel build time and ship in the kernel packages.
** Make kernel-install scripts to copy the BLS, kernel and initramfs
images and do any architecture specific task.
** Make GRUB 2, zipl and Petitboot bootloaders to populate their boot
menu entries from the information in BLS files.
** Have a grubby wrapper for backward compatbility that manipulates BLS files.
** Modify packages that use grubby to instead install BLS fragments
(memtest86+, tuned).
** Make sure this is all properly documented in release-notes, etc.

* Other developers:
** The anaconda developers will need to review and merge the patches
to change the default to BLS.
** Test and watch for regressions.

* Release engineering:
RelEng review ticket: https://pagure.io/releng/issue/7572

** List of deliverables:
N/A

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
No changes needed.
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CTKJBECHWEVF5IN6FO5TV7SIYWIMKYRT/

Re: Schedule for Friday's FESCo Meeting (2018-06-15)

[Jan Kurik]

I would like to ask FESCo to also take care of this ticket:
https://pagure.io/fesco/issue/1912
It does not need a discussion (IMO), but it is an important one. Some
of the steps in the ticket need to be done by current FESCo members as
non-FESCo people do not have the permissions to do so.

Thanks,
Jan

On Thu, Jun 14, 2018 at 12:39 AM, Randy Barlow
 wrote:
> The following is the list of topics that will be discussed in the
> FESCo meeting Friday at 15:00UTC in #fedora-meeting on
> irc.freenode.net.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2018-06-15 15:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> = Followups =
>
> #topic #1820 Adjust/Drop/Document batched updates policy
> .fesco 1820
> https://pagure.io/fesco/issue/1820
>
>
> = New business =
>
> #topic #1900 Stop building freeipa server packages on i686
> .fesco 1900
> https://pagure.io/fesco/issue/1900
>
> #topic #1902 F29 Self Contained Change: java-11-openjdk - next LTS
> OpenJDK release and future main JDK in Fedora
> .fesco 1902
> https://pagure.io/fesco/issue/1902
>
> #topic #1903 F29 System Wide Change: Node.js 10.x as default Node.js
> interpreter
> .fesco 1903
> https://pagure.io/fesco/issue/1903
>
> #topic #1905 F29 System Wide Change: Hide the grub menu
> .fesco 1905
> https://pagure.io/fesco/issue/1905
>
> #topic #1906 F29 System Wide Change: Strong crypto settings: phase 2
> .fesco 1906
> https://pagure.io/fesco/issue/1906
>
> #topic #1907 F29 System Wide Change: i686 Is For x86-64
> .fesco 1907
> https://pagure.io/fesco/issue/1907
>
> #topic #1908 F29 System Wide Change: NSS load p11-kit modules by default
> .fesco 1908
> https://pagure.io/fesco/issue/1908
>
> #topic #1909 Allow to have %{?suse_version} condition in spec file
> .fesco 1909
> https://pagure.io/fesco/issue/1909
>
> #topic #1910 F29 Self Contained Change: Changes/Update festival to 2.5
> .fesco 1910
> https://pagure.io/fesco/issue/1910
>
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
>
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VUDXFDITKIWUYHB2RZENAQQ4QSYZ6M27/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G56PJAWVVK7ZFYN2PLRKY6ZMXQANKETB/

FESCo Elections - May 2018 : Results announcement

[Jan Kurik]

Greetings, all!

The elections for FESCo - May 2018  have concluded, and the results
are shown below.

FESCo is electing 4 seats this time. A total of 86 ballots were cast,
meaning a candidate could accumulate up to 430 votes (86 * 5).

The results for the elections are as follows:

  # votes |  name
- +--
 290  | Till Maas (till/tyll)
 286  | Stephen Gallagher (sgallagh)
 254  | Randy Barlow (bowlofeggs)
 234  | Petr Šabata (contyk/psabata)
- +--
 231  | Justin Forbes (jforbes)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

For more information please check the Voting App:
https://admin.fedoraproject.org/voting/about/fesco-may-2018
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PLIZR72VT4S4TZ33DYBDLRSEFTECZECR/

Fedora Elections May 2018 - Voting period of FESCo elections will be closed today at 23:59

[Jan Kurik]

The voting period is open till today's midnight [UTC]. It will be closed at
23:59 [UTC] on Wednesday, June 13th, 2018.
Do not forget to vote [1] for your favourite nominees [2] to FESCo.

[1] https://admin.fedoraproject.org/voting/about/fesco-may-2018
[2] https://communityblog.fedoraproject.org/2018-may-elections-fesco
-interviews/

Jan

On Thu, Jun 7, 2018 at 4:17 AM, Jan Kurik  wrote:
>
> Hi,
>
> the Voting period of the currently running Fedora Elections [0] has
> just started. Please vote for your candidates to FESCo [1].
> You can vote till June 13th, 2018 when the voting ends at 23:59:59 UTC.
>
> On Community blog [2] you can also find interviews with all the
> candidates. Please have a look at it.
>
> [0] https://fedoraproject.org/wiki/Elections
> [1] https://admin.fedoraproject.org/voting/vote/fesco-may-2018
> [2] https://communityblog.fedoraproject.org/tag/may-2018-elections-fesco/
> [2.1] Justin Forbes:
> https://communityblog.fedoraproject.org/fesco-election-interview-justin-
forbes-jforbes/
> [2.2] Stephen Gallagher:
> https://communityblog.fedoraproject.org/fesco-election-interview-stephen-
gallagher-sgallagh/
> [2.3] Till Maas:
> https://communityblog.fedoraproject.org/fesco-election
-interview-till-maas-till/
> [2.4] Randy Barlow:
> https://communityblog.fedoraproject.org/fesco-election-interview-randy-
barlow-bowlofeggs/
> [2.5] Petr Šabata:
> https://communityblog.fedoraproject.org/fesco-election-interview-petr-
sabata-psabata-contyk/
>
> Thanks for your support.
> Regards,
> Jan

-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P3JQXBTTIRBSCOWAWX55BM2XMLQ5TOLI/

F29 System Wide Change: Golang 1.11

[Jan Kurik]

= Proposed System Wide Change: Golang 1.11 =
https://fedoraproject.org/wiki/Changes/golang1.11


Owner(s):
  * Jakub Čajka 


Rebase of Golang package to upcoming version 1.11 in Fedora 29,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time).



== Detailed description ==
Rebase of Golang package to upcoming version 1.11 in Fedora 29. Golang
1.11 is schedule to be released in Aug.
Due to current nature of Go packages, rebuild of dependent package
will be required to pick up the changes.


== Scope ==
* Proposal owners:
Rebase golang package in f29, help with resolving possible issues
found during package rebuilds.

* Other developers:
fix possible issues with help from golang maintainers

* Release engineering:
Rebuild of dependent packages in side tag.
RelEng tracking issue https://pagure.io/releng/issue/7569

** List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3JWLZ2UKQ37MGWYVSASB6H4VM7RBXUXX/

REMINDER: Submission deadline for Changes of Fedora 29 requiring mass rebuild takes effect in one week

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect in one week on June 19th. All the Changes
requiring mass rebuild sent for review after this deadline are going
to be moved to Fedora 30 release.
The mass rebuild it self is planned on July 11th.

The deadline for System Wide Changes which do not need the mass
rebuild is planned on July 3rd.

If your Change proposal needs mass rebuild, please submit it by the
deadline, earlier better. In case you'll need any help with your
Change proposals, feel free to contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B25U3IVRNCXUTPLGPZCJQJ2MKXRDOF42/

Fedora Elections May 2018 - Voting period of FESCo elections is open

[Jan Kurik]

The voting period is still open till Wednesday, June 13th, 2018.
Do not forget to vote [1] for your favourite nominees [2] to FESCo.

[1] https://admin.fedoraproject.org/voting/about/fesco-may-2018
[2] https://communityblog.fedoraproject.org/2018-may-elections-fesco-interviews/

Jan

On Thu, Jun 7, 2018 at 4:17 AM, Jan Kurik  wrote:
>
> Hi,
>
> the Voting period of the currently running Fedora Elections [0] has
> just started. Please vote for your candidates to FESCo [1].
> You can vote till June 13th, 2018 when the voting ends at 23:59:59 UTC.
>
> On Community blog [2] you can also find interviews with all the
> candidates. Please have a look at it.
>
> [0] https://fedoraproject.org/wiki/Elections
> [1] https://admin.fedoraproject.org/voting/vote/fesco-may-2018
> [2] https://communityblog.fedoraproject.org/tag/may-2018-elections-fesco/
> [2.1] Justin Forbes:
> https://communityblog.fedoraproject.org/fesco-election-interview-justin-forbes-jforbes/
> [2.2] Stephen Gallagher:
> https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gallagher-sgallagh/
> [2.3] Till Maas:
> https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-till/
> [2.4] Randy Barlow:
> https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlow-bowlofeggs/
> [2.5] Petr Šabata:
> https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata-psabata-contyk/
>
> Thanks for your support.
> Regards,
> Jan
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic




-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GWPHLXBE63LQAVF5GP73BALLCQO7A3PT/

F29 Self Contained Change: User PATH Prioritization

[Jan Kurik]

= Proposed Self Contained Change: User PATH Prioritization =
https://fedoraproject.org/wiki/Changes/UserPathPrioritization


Owner(s):
  * Sorin Sbarnea 
  * Till Maas 
  * Miro Hrončok 


Changing user PATH '''~/.local/bin''' to be moved to the top of the
PATH list instead of the end. This will bring Fedora in sync with
other distributions which already fixed this issues (Debian/Ubuntu)
and will allow users to install and use their own command line tools,
also fixing multiple bugs where user installed tools cannot be
accessed because the system installed ones took precedence.



== Detailed description ==
Currently if user is installing his own tools with installers like
(pip), they will be installed inside ~/.local/bin but if the same CLI
tools are installed at system level the user would not be able to use
his own tools because the system one would be picked instead. This
happens because .bashrc file adds user PATH to the end instead of the
top of PATH list variable.
Same problem was happening with other distributions but they fixed it
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839155 Debian bug)
Example: "pip install --user virtualenv" would install virtualenv at
user level, adding ~/.local/bin/virtualenv executable. Still, if
virtualenv happens to be installed at system level, this would
currently be used instead of user installed one. On the other hand,
python itself already knows to prefer user installed modules which
means that "python -m virtualenv" will call user installed module
instead of the system one.
This may result in undefined behavior, where user installs foo, than
run foo, but /usr/bin/foo is run and that import from Python modules
in home. Those modules might have different API.
If we change the order and to assure the user folders do take
precedence, we would assure that python modules and shell scripts
would use the same modules, avoiding weird bugs where what you call is
not what you installed.
The issue is not unique to pip installed and applies to any tools that
are installed in de facto default XDG folder locations.
There should be '''no security concerns''' due to this change because
any user is already able to add executables and to alter its own PATH,
which means that if someone wants to trick a user to use another
executable, they are already able to do that. This has already been
proved several times in the
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/
initial discussions about this change.
The change itself technically is in /etc/skel/.bash_profile from bash.
Currently:
PATH=$PATH:$HOME/.local/bin:$HOME/bin
After the change:
PATH=$HOME/.local/bin:$HOME/bin:$PATH
(Note that whether we move $HOME/bin or not has not yet been decided.)
Note that this change will only affect new user accounts, we cannot
change PATH for already existing accounts without crazy and undesired
hacks.



== Scope ==
* Proposal owners:
change /etc/skel/.bash_profile to have local folders before the system
ones in default PATH

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7554 #7554

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/C3FCEWZR42MWLZQWFKDRS75F3OSOBB3K/

Elections for Mindshare - May 2018 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for Mindshare - May 2018 [1] have concluded, and the
results are shown below.

Mindshare committee is electing 1 seat this time.
A total of 107 ballots were cast, meaning a candidate could accumulate
up to 321 votes (107 * 3).

The results for the elections are as follows:

  # votes |  name
- +--
 205  | Sumantro Mukherjee (sumantrom)
- +--
 188  | Nick Bebout (nb)
 114  | Itamar Peixoto (itamarjp)


Congratulations to the winning candidate, and thank you all candidates
for running this elections!

[1] https://admin.fedoraproject.org/voting/about/mindshare-may-2018
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/Z4YY35EGQ4TTJ6TL5EUBJKE4RYGWWLTB/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z4YY35EGQ4TTJ6TL5EUBJKE4RYGWWLTB/

Elections for Council - May 2018 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for Council - May 2018 [1] have concluded, and the
results are shown below.

Fedora  Council is electing 1 seat this time.
A total of 110 ballots were cast, meaning a candidate could accumulate
up to 220 votes (110 * 2).

The results for the elections are as follows:

  # votes |  name
- +--
 164  | Till Maas (till)
- +--
 115  | Nick Bebout (nb)


Congratulations to the winning candidate, and thank you all candidates
for running this elections!

[1] https://admin.fedoraproject.org/voting/about/council-may-2018
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7Q3RJYCCGHMH4UTZOVYS5POPF653YMJG/

Elections for Mindshare - May 2018 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for Mindshare - May 2018 [1] have concluded, and the
results are shown below.

Mindshare committee is electing 1 seat this time.
A total of 107 ballots were cast, meaning a candidate could accumulate
up to 321 votes (107 * 3).

The results for the elections are as follows:

  # votes |  name
- +--
 205  | Sumantro Mukherjee (sumantrom)
- +--
 188  | Nick Bebout (nb)
 114  | Itamar Peixoto (itamarjp)


Congratulations to the winning candidate, and thank you all candidates
for running this elections!

[1] https://admin.fedoraproject.org/voting/about/mindshare-may-2018
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RYLODVRF4BOIHERQD6IR6GMD5QKMX2ZX/

Fedora Elections May 2018 - Voting period of FESCo elections has started

[Jan Kurik]

Hi,

the Voting period of the currently running Fedora Elections [0] has
just started. Please vote for your candidates to FESCo [1].
You can vote till June 13th, 2018 when the voting ends at 23:59:59 UTC.

On Community blog [2] you can also find interviews with all the
candidates. Please have a look at it.

[0] https://fedoraproject.org/wiki/Elections
[1] https://admin.fedoraproject.org/voting/vote/fesco-may-2018
[2] https://communityblog.fedoraproject.org/tag/may-2018-elections-fesco/
[2.1] Justin Forbes:
https://communityblog.fedoraproject.org/fesco-election-interview-justin-forbes-jforbes/
[2.2] Stephen Gallagher:
https://communityblog.fedoraproject.org/fesco-election-interview-stephen-gallagher-sgallagh/
[2.3] Till Maas:
https://communityblog.fedoraproject.org/fesco-election-interview-till-maas-till/
[2.4] Randy Barlow:
https://communityblog.fedoraproject.org/fesco-election-interview-randy-barlow-bowlofeggs/
[2.5] Petr Šabata:
https://communityblog.fedoraproject.org/fesco-election-interview-petr-sabata-psabata-contyk/

Thanks for your support.
Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FCCOUMKUKTQMQYM4IE56TNBJUIU5QTUO/

Re: Fedora Elections May 2018 - The last day of Voting period for Council and Mindshare elections

[Jan Kurik]

Please let me remind that today (June 6th, 2018) is the last day of
the Voting period to Fedora Council [1] and Mindshare Committee [2].
You can vote till 23:59:59 UTC.

Interviews can be found on Community blog [3].

[1] https://admin.fedoraproject.org/voting/vote/council-may-2018
[2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
[3] 
https://communityblog.fedoraproject.org/2018-may-elections-council-mindshare-interviews

Thanks for your support.
Regards,
Jan

On Thu, May 31, 2018 at 2:19 AM, Jan Kurik  wrote:
> Hi,
>
> the Voting period of the currently running Fedora Elections [0] has
> just started. Please vote for your candidates to Council [1] and
> Mindshare [2].
> You can vote till June 6th, 2018 when the voting ends at 23:59:59 UTC.
>
> On Community blog [3] you can also find interviews with all the
> candidates. Please have a look at it.
>
> [0] https://fedoraproject.org/wiki/Elections
> [1] https://admin.fedoraproject.org/voting/vote/council-may-2018
> [2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
> [3] https://communityblog.fedoraproject.org/tag/elections/
>
> Thanks for your support.
> Regards,
> Jan

-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FCV6TR537WGIOKFIBPSRFDVNZPWNPHFF/

F29 Self Contained Change: Changes/Update festival to 2.5

[Jan Kurik]

= Proposed Self Contained Change: Changes/Update festival to 2.5 =
https://fedoraproject.org/wiki/Changes/Update_festival_to_2.5


Owner(s):
  * Lukáš Tyrychtr 


Update the packaged festival speech synthesis system to the latest
upstream version. And just as a bonus make it actually work.



== Detailed description ==
Festival provides capabilities for speech synthesis and a framework
for synthetic voice creation. It generally provides higher quality
voices than Espeak.


== Scope ==
* Proposal owners:
Actually do the package updates (almost done) and get them in to Fedora.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7551 #7551

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FNFK7QVGFUKXCI7AUIEZKO6HFKHAI64C/

Re: Fedora Elections May 2018 - Voting period in progress for Council and Mindshare elections

[Jan Kurik]

Please let me remind we have opened Voting to Fedora Council [1] and
Mindshare Committee [2]. You can vote till June 6th, 2018 when the
voting ends at 23:59:59 UTC.

On Community blog [3] you can also find interviews with all the
candidates. Please have a look at it.

[1] https://admin.fedoraproject.org/voting/vote/council-may-2018
[2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
[3] 
https://communityblog.fedoraproject.org/2018-may-elections-council-mindshare-interviews/#more-5738

Thanks for your support.
Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YB3QBZVCAGWIWOGH3S4ATWLOWIYBP2GS/

F29 System Wide Change: NSS load p11-kit modules by default

[Jan Kurik]

= Proposed System Wide Change: NSS load p11-kit modules by default =
https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules


Owner(s):
  * Daiki Ueno 


When NSS database is created, PKCS#11 modules configured in the
system's p11-kit will be automatically registered and visible to NSS
applications.



== Detailed description ==
Fedora provides a mechanism to configure PKCS#11 modules system wide,
allowing the crypto libraries (GnuTLS and OpenSSL) to use PKCS#11
modules in a consistent manner. Until now NSS applications haven't
benefit from it as NSS uses a different configuration mechanism which
requires users to register PKCS#11 modules in NSS databases. This
change makes the manual procedure unnecessary, by registering the
p11-kit-proxy module (the aggregator of the system PKCS#11 modules) in
NSS databases with the default configuration.
See also:
* https://bugzilla.redhat.com/show_bug.cgi?id=1173577


== Scope ==
* Proposal owners:
** Enable p11-kit-proxy in the newly created NSS database, through the
crypto-policies package.
** Modify the opensc package not to register itself to the NSS
database upon installation.

* Other developers:
** Make sure that this change doesn't cause any regression with the
existing applications.

* Release engineering:
[https://pagure.io/releng/issue/7548 #7548]
** List of deliverables: N/A

* Policies and guidelines:
PackageMaintainers/PKCS11 needs changes basically to eliminate NSS
specific stuff

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5J5SRVBJR5PDE6G6ZKOFWQG5AJ6WCFR3/

F29 System Wide Change: i686 Is For x86-64

[Jan Kurik]

= Proposed System Wide Change: i686 Is For x86-64 =
https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64


Owner(s):
  * Florian Weimer 


Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.



== Detailed description ==
Currently, the i686 RPM packages are built in such a way that they are
compatible with very old i686 systems, such as the Pentium III.  The
only addition over the i686/Pentium Pro baseline is a requirement to
support long NOPs, for Intel CET.  However, the majority of
installations of i686 packages is for use on x86_64 systems, as
multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
does not run stable on old hardware which is not x86-64-capable (
https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
).
This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


== Scope ==
* Proposal owners:
Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
new compiler flags. Except for mstackrealign, there is substantial
experience with this configuration downstream.

* Other developers:
Other developers can enable SSE2 optimization in their packages if
they want, where this has been a compile-time option only.

* Release engineering:
https://pagure.io/releng/issues/7543 #7543

** List of deliverables: TBD

* Policies and guidelines:
i686 is no longer a primary architecture. The Packaging Guidelines do
not currently require support for non-SSE2 x86 systems, so no change
is required there.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CC22ZTFDB5L3BFSQG7M3TUZUVYKFUSKP/

F29 System Wide Change: Strong crypto settings: phase 2

[Jan Kurik]

= Proposed System Wide Change: Strong crypto settings: phase 2 =
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2


Owner(s):
  * Tomáš Mráz 


We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak
Diffie-Hellman key exchange sizes (1024 bit)



== Detailed description ==
Fedora includes several cryptographic components who's security
doesn't remain constant over time. Algorithms such as (cryptographic)
hashing and encryption typically have a lifetime after which they are
considered either too risky to use or plain insecure. That would mean
we need to phase out such algorithms from the default settings, or
completely disable if they could cause irreparable issue.
While in the past we did not disable algorithms in a consistent way
(different applications utilized different policies), today we have a
system-wide policy followed by a large part of Fedora components. That
allows us to move consistently and deprecate algorithms system-wide.
For rationale see RFC 7457 for a more complete list of attacks taking
advantage of legacy crypto algorithms.

The changes for default policy are:
* Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols
and move the TLS 1.x, x<=1 to legacy level.
* Require finite field parameters (RSA, Diffie-Hellman) of 2048 and
more in the default settings
That is a policy of:

LEGACY
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: SHA-1 hash or better (not RIPEMD)
Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES)
key exchange: ECDHE, RSA, DHE
DH params size: >=1023
RSA params size: >=1023
TLS protocols: TLS >= 1.0

DEFAULT
MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 255 bits (including bernstein curves)
Signature algorithms: with SHA-1 hash or better (not DSA)
Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20,
including aes-cbc)
key exchange: ECDHE, RSA, DHE
DH params size: >= 2048
RSA params size: >= 2048
TLS protocols: TLS >= 1.2

FUTURE
MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc)
Curves: all prime >= 384 bits (including bernstein curves)
Signature algorithms: SHA-384 hash or better (not DSA)
Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated
Encryption (AE) ciphers
key exchange: ECDHE, DHE
DH params size: >= 3072
RSA params size: >= 3072
TLS protocols: TLS >= 1.2



== Scope ==
* Proposal owners:
The policies include in crypto-policies package need to be updated.

* Other developers:
  * Crypto policies are updated to the settings above
  * https://bugzilla.redhat.com/show_bug.cgi?id=1487607 OpenSSL is
updated to allow setting policies for TLS versions

* Release engineering:
Copied from F28 change - no impact
https://pagure.io/releng/issue/7235 #7235

** List of deliverables:
  * Crypto policies are updated to the settings above
  * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora
Crypto Policies follow the new crypto settings.

* Policies and guidelines:
No changes to packaging or other guidelines is needed.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B4YAC3KZOJUT4V6B3EVYZIDKHELU5NRA/

Re: Fedora Elections May 2018 - Voting period has started for Council and Mindshare elections

[Jan Kurik]

On Thu, May 31, 2018 at 12:20 PM, Till Maas  wrote:
> Hi,
>
> On Thu, May 31, 2018 at 02:19:48AM +0200, Jan Kurik wrote:
>
>> the Voting period of the currently running Fedora Elections [0] has
>> just started. Please vote for your candidates to Council [1] and
>> Mindshare [2].
>> You can vote till June 6th, 2018 when the voting ends at 23:59:59 UTC.
>>
>> On Community blog [3] you can also find interviews with all the
>> candidates. Please have a look at it.
>
> Could you maybe add links to the interviews to the nomination pages?

Added.

> They are linked in the voting app as more information about the vote,
> therefore it would be great to find the interviews there. It seems that
> that candidate's names also link to the interviews but this is not
> clearly visible. I guess a text "Interview" with a link would be more
> obvious.

This is a change request to the Voting App. Thanks for opening the
tickets in https://pagure.io/elections/issues .

Jan

> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z45EJR3AVIYOUDV3VNNLDPCTX2MOA3F2/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DWKDLKM5O447NUJR5TGHO5XHXRTBDD2Z/

Re: Fedora Elections May 2018 - Voting period in progress for Council and Mindshare elections

[Jan Kurik]

Please let me remind we have opened Voting to Fedora Council [1] and
Mindshare Committee [2]. You can vote till June 6th, 2018 when the
voting ends at 23:59:59 UTC.

On Community blog [3] you can also find interviews with all the
candidates. Please have a look at it.

[1] https://admin.fedoraproject.org/voting/vote/council-may-2018
[2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
[3] 
https://communityblog.fedoraproject.org/2018-may-elections-council-mindshare-interviews/#more-5738

Thanks for your support.
Regards,
Jan

On Thu, May 31, 2018 at 2:19 AM, Jan Kurik  wrote:
> Hi,
>
> the Voting period of the currently running Fedora Elections [0] has
> just started. Please vote for your candidates to Council [1] and
> Mindshare [2].
> You can vote till June 6th, 2018 when the voting ends at 23:59:59 UTC.
>
> On Community blog [3] you can also find interviews with all the
> candidates. Please have a look at it.
>
> [0] https://fedoraproject.org/wiki/Elections
> [1] https://admin.fedoraproject.org/voting/vote/council-may-2018
> [2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
> [3] https://communityblog.fedoraproject.org/tag/elections/
>
> Thanks for your support.
> Regards,
> Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JVSJBEYKVGP7UREQZDIJDBDKYU2ANA6X/

Re: F29 System Wide Change: Hide the grub menu

[Jan Kurik]

Forwarding reply from Ken:

-- Forwarded message --
From: Ken Coar 
To: devel@lists.fedoraproject.org
Cc:
Bcc:
Date: Thu, 31 May 2018 12:20:32 -0400
Subject: Re: F29 System Wide Change: Hide the grub menu
On 05/31/2018 06:43 AM, Jan Kurik wrote:
> = Proposed System Wide Change: Hide the grub menu =
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
>
> On systems with only a single OS installed, the grub menu does not
> offer any useful functionality, so we should hide it by default.

I'm not [yet] in any of the groups which would allow me to
comment on the wiki, so I'll do it here.

I fundamentally disagree with the 'no useful functionality'
reasoning.  It provides access to the kernel line, even if
there's only one kernel, and that is *definitely* useful
functionality.

I'm opposed to this change.  For one thing, it violates the
Principle of Least Astonishment.  For another, with SSD drives
becoming more and more common, and CPUs faster and faster, the
time window for successfully whanging away at the F8/ESC/F12/whatever
key in order to bring up the menu is getting harder to hit.
Glance away for an instant and you've missed it -- so either let
it come up so you can reboot, or (possibly more common) power it
down (because you can't get in) and try again.

FWIW.
--
#kenB-|}

Ken, Baron Coar
RHCA, RHCVA, Sanagendamgagwedweinini
Red Hat IT Infrastructure

On Thu, May 31, 2018 at 7:14 PM, Chris Adams  wrote:
> Once upon a time, Jason L Tibbitts III  said:
>> If we're going to patch grub to expand the set of keys it will watch
>> for, is it possible to just expand the set to encompass all keys?  We
>> don't really need to make it that hard to find the grub menu, do we?
>
> To add: printing a message to the screen for only a few seconds can be
> almost useless, as many times monitors take those same seconds to sync
> to the output of the GRUB screen (it seems to always be in a different
> mode from the BIOS/UEFI boot screen).  So IMHO, taking any key would be
> good because not only do I not have to remember a specific one or few
> keys, I don't have to read a message that is only actually visible for
> 0.2 seconds.
>
> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ARXFTQA5GMS3XKTCTK46ARROS7C6JUNE/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JVBNUB2NC4P4JHWIHATI2547VXG3PWFV/

F29 System Wide Change: Hide the grub menu

[Jan Kurik]

= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu


Owner(s):
  * Hans de Goede 


On systems with only a single OS installed, the grub menu does not
offer any useful functionality, so we should hide it by default.



== Detailed description ==
On systems with only a single OS installed, the grub menu's only
function is to allow booting older kernels, which is only necessary as
a rescue option in case of a severe kernel bug and as such not
something which is directly useful for normal use.
Fedora already has a lot of work done to not show too technical boot
messages to end users during bootup, e.g. we pass quiet to the kernel
and we've plymouth to show a bootsplash instead of a bunch of
"Starting service-foo: OK" messages.
The grub menu with its kernel versions is another example of showing
too technical info to end-users and on non multi-boot systems it
normally is not necessary, so it is better to hide it.
The implementation of this consists of the following changes:
1. Currently if the menu is hidden the user needs to press ESC to show
it, modify grub to also except F8 as show-menu key, there are 2
reasons for this:
1.1 F8 is (was) the key to bring up the boot/rescue menu in Windows
1.2 On some machines ESC brings up the firmware-setup menu
2. On non multi-boot systems set GRUB_HIDDEN_TIMEOUT=1 and
GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub


== Scope ==
* Proposal owners:
1. Add patches to grub to also make pressing F8 show the menu
2. Make sure this is all properly documented in release-notes, etc.
3. Write patches for anaconda to set GRUB_HIDDEN_TIMEOUT=1 and
GRUB_HIDDEN_TIMEOUT_QUIET="true" in /etc/default/grub on non
multi-boot systems

* Other developers:
The anaconda developers will need to review and merge the
/etc/default/grub related patches

* Release engineering:
https://pagure.io/releng/issue/7539

** List of deliverables: all

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
Not needed for this Change.
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2IOSOHGS2RA6HFDSNXBXQCFJ3UXHC2KJ/

Re: NEEDINFO denial of service attack

[Jan Kurik]

On Thu, May 31, 2018 at 12:28 PM, Peter Robinson  wrote:
> On Thu, May 31, 2018 at 11:25 AM, Jan Kurik  wrote:
>> This issue was caused by me as part of post-F26 EOL housekeeping,
>> following the https://pagure.io/fesco/issue/1736#comment-455818 FESCo
>> decision. If this approach is causing issues we can skip the step
>> setting "needinfo" flag and leave just a comment in the bug.
>>
>> I am sorry for any inconvenience this might caused.
>
> There for some reason was also bugs from f23 moved forward to f27, no
> idea why the scripts are touching f23 but they should be closed EOL
> rather than moved.

As far as I can tell, all the bugs having version set to value less
than 26 were already closed as EOL and reopened. As these bugs were
re-opened, I requested a review instead of closing these again. In
case these bugs will be left untouched, the post-F27 EOL housekeeping
should close these again.

Jan

>> On Thu, May 31, 2018 at 12:11 PM, Till Maas  wrote:
>>> Hi,
>>>
>>> On Thu, May 31, 2018 at 10:28:42AM +0100, Richard W.M. Jones wrote:
>>>>
>>>> https://pagure.io/fesco/issue/1736
>>>>
>>>> I've had about 100 bugs set to NEEDINFO of me to check if some obscure
>>>> Fedora package is vulnerable to some 1 or 2 year old bug.
>>>>
>>>> Is this a useful use of anyone's time?
>>>
>>> it is hard to tell without examples. Are the packages properly
>>> maintained and up to date? Are the obscure packages your packages? If
>>> not, by were you the target of the NEEDINFO?
>>>
>>> Kind regards
>>> Till
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5KNY22CYUUEPO73HPUTEWUPFMBUWSPV4/
>>
>>
>>
>> --
>> Jan Kuřík
>> JBoss EAP Program Manager
>> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AEH7VHBHV4ZNT66BW6Z6GSOU3YNMBQDD/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X27DGS2K3D4ET6CMV7RSJR3RFKWRJLRC/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YUWR6X32NJZ2CFB4C25VE6ZGLHH7OOM4/

Re: NEEDINFO denial of service attack

[Jan Kurik]

This issue was caused by me as part of post-F26 EOL housekeeping,
following the https://pagure.io/fesco/issue/1736#comment-455818 FESCo
decision. If this approach is causing issues we can skip the step
setting "needinfo" flag and leave just a comment in the bug.

I am sorry for any inconvenience this might caused.
Jan

On Thu, May 31, 2018 at 12:11 PM, Till Maas  wrote:
> Hi,
>
> On Thu, May 31, 2018 at 10:28:42AM +0100, Richard W.M. Jones wrote:
>>
>> https://pagure.io/fesco/issue/1736
>>
>> I've had about 100 bugs set to NEEDINFO of me to check if some obscure
>> Fedora package is vulnerable to some 1 or 2 year old bug.
>>
>> Is this a useful use of anyone's time?
>
> it is hard to tell without examples. Are the packages properly
> maintained and up to date? Are the obscure packages your packages? If
> not, by were you the target of the NEEDINFO?
>
> Kind regards
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5KNY22CYUUEPO73HPUTEWUPFMBUWSPV4/



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AEH7VHBHV4ZNT66BW6Z6GSOU3YNMBQDD/

Fedora Elections May 2018 - Voting period has started for Council and Mindshare elections

[Jan Kurik]

Hi,

the Voting period of the currently running Fedora Elections [0] has
just started. Please vote for your candidates to Council [1] and
Mindshare [2].
You can vote till June 6th, 2018 when the voting ends at 23:59:59 UTC.

On Community blog [3] you can also find interviews with all the
candidates. Please have a look at it.

[0] https://fedoraproject.org/wiki/Elections
[1] https://admin.fedoraproject.org/voting/vote/council-may-2018
[2] https://admin.fedoraproject.org/voting/vote/mindshare-may-2018
[3] https://communityblog.fedoraproject.org/tag/elections/

Thanks for your support.
Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UXTPYIFEHVV63ELF3OEM27UC46GTZRMI/

F29 System Wide Change: Node.js 10.x as default Node.js interpreter

[Jan Kurik]

= Proposed System Wide Change: Node.js 10.x as default Node.js interpreter =
https://fedoraproject.org/wiki/Changes/Nodejs10


Owner(s):
  * Stephen Gallagher 


A major upgrade to the newest LTS release of Node.js for Fedora 29.



== Detailed description ==
Node.js releases a new LTS version each year and will support it for
around 18 months, which makes it the ideal candidate for use with
Fedora. Node.js 10.x was released recently and is already available as
a module for Fedora 28 and Fedora 29. This Change proposal is to make
10.x the default version shipped with Fedora 29.


== Scope ==
* Proposal owners:
Node.js SIG will need to upgrade the `nodejs` package in Fedora 29 to
10.x (the same package as is available in modules for F28)Node.js SIG
will need to update any `nodejs-*` packages in Fedora 29 if they
require changes to run on Node.js 10.x, or else retire those that no
longer function.

* Other developers:
As this is a major update to a language interpreter, packagers of
Node.js modules will need to test that their software remains
compatible.

* Release engineering:
The upgrade *may* require a side-tag while updating the `nodejs-*`
packages. This is not yet certain.
RelEng ticket: https://pagure.io/releng/issue/7537

** List of deliverables:
Does not ship on default media.

* Policies and guidelines:
No changes expected

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NOBZRCLSIXJXZXKZ7LVVHAUHRCDR72WQ/

F29 Self Contained Change: java-11-openjdk - next LTS OpenJDK release and future main JDK in Fedora

[Jan Kurik]

= Proposed Self Contained Change: java-11-openjdk - next LTS OpenJDK
release and future main JDK in Fedora =
https://fedoraproject.org/wiki/Changes/java-11-openjdk-TechPreview


Owner(s):
  * Jiri Vanek 


OpenJDK have LTS release  cadence of 2 years. JDK11, next LTS is to be
released September 2018.  Next LTS is JDK15, expected in 2020.  This
proposal, is proposing new package - java-11-openjdk, based on this
LTS OpenJDK 11, which will be tech preview of next Main JDK for fedora
(30?).
See same process with JDK8, current main JDK, and JDK7 before.
JDK8 tehc preview: https://fedoraproject.org/wiki/Features/Java8TechPreview
JDK8 made main JDK: https://fedoraproject.org/wiki/Changes/Java8
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf



== Detailed description ==
JDK11 is next major, LTS, release of Java platform.  It is bringing
many cool improvements - http://openjdk.java.net/projects/jdk/11/ and
is landing to your Fedora.  Where it will be maintained for f27 and
newer.
To understand JAva release process, See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
and See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
.  So this is package, containing exact LTS version of OpenJDK
You will always be allowed to install  Used LTS in fedora build root,
alongside with latest  STS via alternatives. Also JDK8 will be with us
for some time
The fate of JDK10 is about to be decided -  it can be updated to JDK11
or obsoleted by java-11-openjdk.  In all cases, it will be later
updated to JDK12. Also in all cases separate package will be created
for any LTS JDK - next is java-11-openjdk,
All those packages java-1.8.0-oepnjdk,  java-openjdk and
java-11-openjdk  will be installable in parallel. You can also have
installed several versiosn of java-openjdk  installed next to each
other. They are in your /usr/lib/jvm/java-X-openjdk-v-r.a directory.
Where X is major - like 1.8.0, 9, 10, 11 or  12.


== Scope ==
* Proposal owners:
This is isolated change. The maintainers of OpenJDK in Fedora must
build the binaries, and keep them working.  To keep jdk8 and jd10
installable in parallel.

* Other developers:
Should start to check theirs packages against JDK11,  as it will
replace JDK8 sooner or later. This is still nothing official, and you
can get troubles when trying it with rpmbuild, as your dependencies
may (more likely will) pull JDK8 into build root. But you can try to
compile your sources against JDK10 to see how your upstream get
adapted to modules, and possibly start to upstream patches.

* Release engineering:
https://pagure.io/releng/issue/7527

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/63QYJG36Y5SDA32OGOKM6UPQ6GBJQKH3/

F29 System Wide Change: Perl Move to MetaCPAN

[Jan Kurik]

= Proposed System Wide Change: Perl Move to MetaCPAN =
https://fedoraproject.org/wiki/Changes/Perl_Move_to_MetaCPAN


Owner(s):
  * Petr Písař 


http://search.cpan.org/ search.cpan.org web frontend for
'https://www.cpan.org/ CPAN is being replaced by https://metacpan.org/
metacpan.org. Many Perl RPM packages refer to search.cpan.org. This
Fedora change aims to mass-update URL and Source RPM tags in affected
Perl packages.



== Detailed description ==
Fedora packages store URL to the upstream web page and URL to the
source archive location in their metadata. Most of the Perl packages
uses search.cpan.org for this purpose. However,
https://log.perl.org/2018/05/goodbye-search-dot-cpan-dot-org.html
''search.cpan.org'' won't be the canonical source anymore. We should
update the metadata to point to the new location.
Specification for all Perl packages will be updated like this:
-URL:http://search.cpan.org/dist/CPANPLUS/
+URL:https://metacpan.org/release/CPANPLUS
-Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/CPANPLUS-%{cpan_version}.tar.gz
+Source0:
https://cpan.metacpan.org/authors/id/B/BI/BINGOS/CPANPLUS-%{cpan_version}.tar.gz
This change will be pushed as one commit into each affected Perl
package without increasing its release number. We will try to do this
change before Perl 5.28 mass rebuild in order to have it visible in
Fedora 29 binary repositories.


== Scope ==
* Proposal owners:
Rewrite URL and Source addresses in Perl package specification files.

* Other developers:
Make sure the new addresses are correct.

* Release engineering:
Review ticket: https://pagure.io/releng/issue/7515

** List of deliverables:
Does not block any deliverables.

* Policies and guidelines:
https://fedoraproject.org/wiki/Packaging:Perl#URL_tag Perl packaging
guidelines will be updated.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/353QSBFTO4ZX7CMGPWWNGUZXZ342TRND/

May 2018 Elections: Nomination period for FESCo has been prolonged till May 31st @ 23:59:59 UTC

[Jan Kurik]

Hi Fellowship of Fedora,

as we have not reach the minimal number of nominees to FESCo required
by FESCo election policy [1], to get ready for voting, FESCo has
decided to prolong the nomination period for one week.
As such, the Nomination period has been re-opened until May 31st @
23:59:59 UTC. Till this deadline you can nominate your self or you can
nominate someone else, who might be, from your perspective, a valuable
member of FESCo. If you nominate someone else, please consult with
that person ahead of time.
Please use the FESCo Nomination page [2] to apply.

[1] https://fedoraproject.org/wiki/FESCo_election_policy
[2] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Thanks for your support,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HZOWKDOEFCDWIGE5K4CEHLF3FAIOQYBS/

F29 System Wide Change: Move /usr/bin/python into a separate package

[Jan Kurik]

= Proposed System Wide Change: Move /usr/bin/python into a separate package =
https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package


Owner(s):
  * Petr Viktorin 
  * Miro Hrončok 


Reflecting the recent changes of
https://www.python.org/dev/peps/pep-0394/ PEP 394 -- ''The "python"
Command on Unix-Like Systems'', we are moving /usr/bin/python from the
python2 package into a separate package called
python-unversioned-command.
python2 will recommend this package.
This means Fedora users will get it automatically with python2, but
they might opt-out and remove it. In Fedora's build system, only
packages explicitly buildrequiring /usr/bin/python will get it.
This change obsoletes "Avoid /usr/bin/python in RPM build" change.

== Detailed description ==

=== Motivation ===

The meaning of the python command is ambiguous: it might mean either
Python 2 or Python 3, depending on context. The upstream
recommendation (PEP 394), which we try to follow in Fedora, is that
users -- not distros, and not sysadmins -- should be in control of the
python command.

Specifically, this means distro-packaged software should use python2
or python3 explicitly. Fedora's Python packaging guidelines have
suggested this since February 2015, and demand it since August 2017.
However, enforcing this guideline (which we will need to actually
allow users to safely change their python command) is problematic.
"Avoid /usr/bin/python in RPM_Build" change didn't work: most of the
packagers didn't change anything and too many packages still use the
python command.

Instead of developing custom hacks, we are now utilizing a more
systematic solution: If your package still needs /usr/bin/python to
build, explicitly BuildRequire it. If your package needs
/usr/bin/python to run, explicitly Require it. (In both cases, try to
use /usr/bin/python2 or /usr/bin/python3 instead if possible.)

We are also expecting some buildsystems (autools, cmake, etc.) to
automatically use /usr/bin/python2 if /usr/bin/python is unavailable,
so the problem might go away more naturally.

=== PEP 394 and how it is mapped to this change ===

Upstream PEP 394 -- The "python" Command on Unix-Like Systems
describes how the python command should behave. In Fedora, that's
/usr/bin/python. The PEP was recently updated to reflect upstream's
evolving views on the situation. Notable new information from the PEP
is:

In controlled environments aimed at expert users, where being explicit
is valued over user experience (for example, in test environments and
package build systems), distributions may choose to not provide the
python command even if python2 is available. (All software in such a
controlled environment must use python3 or python2 rather than python,
which means scripts that deliberately use python need to be modified
for such environments.)

We consider Fedora's build machinery a controlled environments aimed
at expert users.

=== What's changing ===

"Avoid /usr/bin/python in RPM_Build" change is reverted. Packages that
follow its Quick Opt-Out section (i.e. set
PYTHON_DISALLOW_AMBIGUOUS_VERSION) will be fixed by the owners of this
change.

/usr/bin/python remains a symbolic link to /usr/bin/python2. However,
it is moved to a new python-unversioned-command package (technically a
subpackage of python2). python2 package will only recommend
/usr/bin/python.

Packages that need /usr/bin/python to build will need to BuildRequire
it. Packages that need /usr/bin/python to be used by users will need
to Require it. In both cases, the packager should avoid the need and
only fallback to (Build)Requiring /usr/bin/python as a temporary
workaround.

The new package will virtually provide python, ensuring that dnf
install python will make the python command available.

=== Effect on automatic bytecompilation ===

When "No more automagic Python bytecompilation" change is done,
packages that byte-compile files outside of Python directories should
switch to the new behavior described in that change, and should not be
impacted by this change. However, if that change is delayed or
reverted, packagers that rely on the old behavior when byte compiling
files will need to set %__python to python2 or python3 explicitly.

=== Effect on %__python and other ambiguous RPM macros ===

Using ambiguous Python macros (%{__python}, %{python_sitelib}...) is
forbidden and your package will fail to build if you still use those
without redefining %__python. Either switch to explicitly versioned
macros (%{__python2}, %{python2_sitelib}, %{__python3}...) or set
__python to an explicit Python version.


== Scope ==
* Proposal owners:
** Split the packages as described in ''Detailed Description''.
** Fix packages that use PYTHON_DISALLOW_AMBIGUOUS_VERSION to
BuildRequire /usr/bin/python instead.

* Other developers:
** Maintainers of packages that use /usr/bin/python need to switch to
using /usr/bin/python3 or /usr/bin/python2 explicitly (with help from
''Proposal owners'' if needed).
**

F29 System Wide Change: The tzdata transition to 'vanguard' format

[Jan Kurik]

= Proposed System Wide Change: The tzdata transition to 'vanguard' format =
https://fedoraproject.org/wiki/Changes/TZDATA-VANGUARD


Owner(s):
  * Patsy Franklin 


As of tzdata-2018e, the upstream will now default to using the
'vanguard' data format including negative DST offsets.  As a
fall-back, the 'rearguard' data format is still available on F28, F27
and F26.



== Detailed description ==
tzdata-2018e defaults to the 'vanguard' data format.  This format
includes the POSIX compliant implementations of negative DST offsets
which have been an issue for both Java and ICU parsers. We plan to
transition to this default format in F29.


== Scope ==
* Proposal owners:
Implement the proposal.

* Other developers:
Developers need to ensure that their packages are able to correctly
parse and/or build with the new tzdata 'vanguard' format.

* Release engineering:
The tzdata maintainer will ensure that the package builds and passes
all tests on F29.
RelEng ticket: https://pagure.io/releng/issue/7510 #7510

* Policies and guidelines:
The policies and guidelines do not need to be updated.

* Trademark approval:
Not needed for this change
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X22UCJO3XYQZE7QRIDPSF3NLWEAQSS7P/

F29 System Wide Change: Perl 5.28

[Jan Kurik]

= Proposed System Wide Change: Perl 5.28 =
https://fedoraproject.org/wiki/Changes/perl5.28


Owner(s):
  * Jitka Plesníková 
  * Petr Písař 


A new ''perl 5.28'' version brings a lot of changes done over a year
of development. Perl 5.28 will be released 5/28/2018. See
http://search.cpan.org/dist/perl-5.28.0-RC1/pod/perldelta.pod 5.28.0
perldelta for more details about preparing release.



== Detailed description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.28.0 version is stable release
this year.



== Scope ==
Every Perl package will be rebuilt in a dedicated ''f29-perl''
build-root against perl 5.28.0 and then if no major problem emerges
the packages will be merged back to ''f29'' build-root.

* Proposal owners:
New perl and all packages requiring perl or a Perl module will be
rebuilt into f29-perl build-root.

* Other developers:
N/A (not a System Wide Change)Owners of packages that fail to rebuild,
mainly perl-sig users, will be asked using Bugzilla to fix or remove
their packages from the distribution.

* Release engineering:
https://pagure.io/releng/issue/7509 #7509
Release engineers will be asked for new f29-perl build-root inheriting
from f29 build-root. After successful finishing the rebuild, they will
be asked to merge f29-perl packages back to f29 build-root.

* Policies and guidelines:
No policies have to be modified to complete this change.
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HXF32SEXZDT4U35SUQAS4R44A3R6IZTQ/

May 2018 Elections: Nomination & Campaign period is open

[Jan Kurik]

This is the last reminder that today, on 2018-May-22, at 23:59:59 UTC
we will close the Nomination window of May-2018 Elections.
Please check the nomination pages [1][2][3] and apply, if you are
interested to work in FESCo, Council or Mindshare teams.

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations

Regards,
Jan

On Wed, May 16, 2018 at 2:05 AM, Jan Kurik  wrote:
> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (4 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2018-May-22 at 23:59:59 UTC.
>
> The nominees can already start preparing their answers for questions
> in the Election Questionnaire. The questions can be found in the
> template files[4].
>
> Nominees submit their questionnaire answers via a private Pagure
> issue[5].  The Election Wrangler or their backup will publish the
> interviews to the Community Blog [6] a day before the start of the
> Voting period (2018-May-30).
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2018-May-29) will be disqualified and removed from the election.
> Nominees may submit their interview answers immediately and may edit
> them until the end of the interview period.
>
> Nominees are encouraged to begin their interview answers as soon as
> they accept their nomination.
>
> As part of the Campaign people might also ask questions to specific
> candidates on @devel mailing list, if they want.
>
> The full schedule of the May 2018 Elections is available on the
> Elections wiki page [8].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-May
> [5] https://pagure.io/fedora-project-schedule/issues
> [6] http://communityblog.fedoraproject.org/
> [8] https://fedoraproject.org/wiki/Elections
>
> Regards,
> Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/33SN3W2APJFMS6TDPAF72VGBUNWHMKKB/

May 2018 Elections: Nomination & Campaign period is open

[Jan Kurik]

This is just a reminder that on 2018-May-22 at 23:59:59 UTC we will
close the Nomination window of May-2018 Elections.
Please check the nomination pages [1][2][3] and apply, if you are
interested to work in FESCo, Council or Mindshare teams.

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations

Regards,
Jan

On Wed, May 16, 2018 at 2:05 AM, Jan Kurik  wrote:
>
> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (4 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2018-May-22 at 23:59:59 UTC.
>
> The nominees can already start preparing their answers for questions
> in the Election Questionnaire. The questions can be found in the
> template files[4].
>
> Nominees submit their questionnaire answers via a private Pagure
> issue[5].  The Election Wrangler or their backup will publish the
> interviews to the Community Blog [6] a day before the start of the
> Voting period (2018-May-30).
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2018-May-29) will be disqualified and removed from the election.
> Nominees may submit their interview answers immediately and may edit
> them until the end of the interview period.
>
> Nominees are encouraged to begin their interview answers as soon as
> they accept their nomination.
>
> As part of the Campaign people might also ask questions to specific
> candidates on @devel mailing list, if they want.
>
> The full schedule of the May 2018 Elections is available on the
> Elections wiki page [8].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-May
> [5] https://pagure.io/fedora-project-schedule/issues
> [6] http://communityblog.fedoraproject.org/
> [8] https://fedoraproject.org/wiki/Elections
>
> Regards,
> Jan
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic




-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/52HAMTPNAV4O7DXGR2UN7TWAFGEQ25LX/

Re: May 2018 Elections: Nomination & Campaign period is open

[Jan Kurik]

This is just a reminder that on 2018-May-22 at 23:59:59 UTC we will close
the Nomination window of May-2018 Elections.
Please check the nomination pages [1][2][3] and apply, if you are
interested to work in FESCo, Council or Mindshare teams.

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations

Regards,
Jan

On Wed, May 16, 2018 at 2:05 AM, Jan Kurik  wrote:

> Today we are starting the Nomination & Campaign period during which we
> accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (4 seats) [1]
> * Fedora Council (1 seat) [2]
> * Mindshare (1 seat) [3]
>
> This period is open until 2018-May-22 at 23:59:59 UTC.
>
> The nominees can already start preparing their answers for questions
> in the Election Questionnaire. The questions can be found in the
> template files[4].
>
> Nominees submit their questionnaire answers via a private Pagure
> issue[5].  The Election Wrangler or their backup will publish the
> interviews to the Community Blog [6] a day before the start of the
> Voting period (2018-May-30).
>
> Please note that the interview is mandatory for all nominees. Nominees
> not having their interview ready by end of the Interview period
> (2018-May-29) will be disqualified and removed from the election.
> Nominees may submit their interview answers immediately and may edit
> them until the end of the interview period.
>
> Nominees are encouraged to begin their interview answers as soon as
> they accept their nomination.
>
> As part of the Campaign people might also ask questions to specific
> candidates on @devel mailing list, if they want.
>
> The full schedule of the May 2018 Elections is available on the
> Elections wiki page [8].
>
> [1] https://fedoraproject.org/wiki/Development/
> SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] https://pagure.io/fedora-project-schedule/blob/master/
> f/elections/2018-May
> [5] https://pagure.io/fedora-project-schedule/issues
> [6] http://communityblog.fedoraproject.org/
> [8] https://fedoraproject.org/wiki/Elections
>
> Regards,
> Jan
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
>



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2OC3CVZEDXNYHE742CUTV4O6PCD6X7NR/

May 2018 Elections: Nomination & Campaign period is open

[Jan Kurik]

Today we are starting the Nomination & Campaign period during which we
accept nominations to the "steering bodies" of the following teams:

* FESCo (Engineering) (4 seats) [1]
* Fedora Council (1 seat) [2]
* Mindshare (1 seat) [3]

This period is open until 2018-May-22 at 23:59:59 UTC.

The nominees can already start preparing their answers for questions
in the Election Questionnaire. The questions can be found in the
template files[4].

Nominees submit their questionnaire answers via a private Pagure
issue[5].  The Election Wrangler or their backup will publish the
interviews to the Community Blog [6] a day before the start of the
Voting period (2018-May-30).

Please note that the interview is mandatory for all nominees. Nominees
not having their interview ready by end of the Interview period
(2018-May-29) will be disqualified and removed from the election.
Nominees may submit their interview answers immediately and may edit
them until the end of the interview period.

Nominees are encouraged to begin their interview answers as soon as
they accept their nomination.

As part of the Campaign people might also ask questions to specific
candidates on @devel mailing list, if they want.

The full schedule of the May 2018 Elections is available on the
Elections wiki page [8].

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations
[4] https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-May
[5] https://pagure.io/fedora-project-schedule/issues
[6] http://communityblog.fedoraproject.org/
[8] https://fedoraproject.org/wiki/Elections

Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Let's Label Our Variants!

[Jan Kurik]

= Proposed System Wide Change: Let's Label Our Variants! =
https://fedoraproject.org/wiki/Changes/Label_Our_Variants


Owner(s):
  * Matthew Miller 
  * Mohan Boddu 


Start using the VARIANT and VARIANT_ID fields in /etc/os-release for
Spins, Labs and the base container image rather than just the main
Fedora Editions.



== Detailed description ==
Right now, we use the VARIANT field (and machine-readable VARIANT_ID)
in /etc/os-release) only for the main Fedora Editions (and Fedora
Cloud Base, because of its history as an edition previously). This
means we can't tell the difference between a KDE desktop spin, a
container image, or just a generic netinstall constructed into a
custom system unlike any of our various flavors. Let's start using it
widely.


== Scope ==
* Proposal owners:
Update the fedora-release package with subpackages for the various
non-edition outputs. The "convert-to-edition" script may also be
extended to handle non-editions, but this is not a required part of
this change proposal.

* Other developers:
Maintainers of spins and labs will need to add the appropriate
fedora-release-… subpackage to the appropriate kickstart file or comps
group.

* Release engineering:
Release Engineering owns the fedora-release package.

* List of deliverables:
Workstation and Server deliverables already contain this, and so are
not affected. The KDE Plasma Desktop Spin will be changed. There is no
overall change to the list of deliverables itself.

* Policies and guidelines:
There was a previous decision to only do this for Editions. This
change would update that. We would also update the Spins documentation
to add this as a new step in that pricess.

* Trademark approval:
not needed for this Change


-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: MySQL 8

[Jan Kurik]

= Proposed Self Contained Change: MySQL 8 =
https://fedoraproject.org/wiki/Changes/MySQL_8


Owner(s):
  * Michal Schorm 


Update of MySQL ( community-mysql package) in Fedora from 5.7  to 8.0 version.



== Detailed description ==
Update of MySQL package in Fedora from 5.7 version to 8.0 version.


== Scope ==
* Proposal owners:
**Release MySQL 8.0.11 to Rawhide (done)
**Check software that requires community-mysql package (done, only
mysql-connector-odbc)
**Gather user input on the changes between mysql 5.7 and 8.0

* Other developers: N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7486

** List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines: N/A (not a System Wide Change)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: Fedora 26 End Of Life on 2018-May-29

[Jan Kurik]

Fedora 26 support is going to be EOL on Tuesday, May 29th, 2018. At
this day we are going to close all the Fedora 26 bugs which will
remain open [1].
You have last few weeks to submit  your updates to the Fedora 26, if
you have any, before the Fedora 26 release becomes unsupported.

[1] 
https://fedoraproject.org/wiki/Releases/28/HouseKeeping#Fedora_26_EOL_Closure

Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Request to populate Questionaire for community elections to FESCo, Mindshare, Council

[Jan Kurik]

Hi,

as part of the preparation for community elections in May 2018, I
would like to ask people to populate Election Questionnaire [1] with
questions people might have for nominees. The Questionnaire already
contains questions from the last elections, however you might add your
own, if you have any. In May 2018 we are going to elect members for
these teams:

* FESCo (4 seats)
* Fedora Council (1 seat)
* Mindshare (1 seat)

You have a time till 2018-May-07 23:59:59 UTC [2] to populate the
Questionnaire with your questions. Then collected questions will go to
the teams when 3 top questions will be selected and will be given to
each candidate to answer before voting period begins as part of
campaign.

[1] https://fedoraproject.org/wiki/Elections/Questionnaire
[2] https://fedoraproject.org/wiki/Elections#Elections_Schedule

Thanks in advance for you contribution,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 28 Final Release Readiness Meeting on Thursday, April 26 @ 19:00 UTC

[Jan Kurik]

TL;DR: We are ready for the release.
More information is available in the meeting minutes:
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-26/f28-final-readiness-meeting.2018-04-26-19.00.html

Jan

On Thu, Apr 19, 2018 at 2:17 PM, Jan Kurik  wrote:
> Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 28
> Final Release Readiness Meeting meeting.
>
> The meeting is going to be held on Thursday, April 26, 2018 at 19:00
> UTC. Please check the [1] link for your time zone.
>
> We will meet to make sure we are coordinated and ready for the Final
> release of Fedora 28. Please note that this meeting is going to be
> held even if the release is delayed at the Go/No-Go meeting on the
> same day two hours earlier.
>
> You may received this message several times, but it is by purpose to
> open this meeting to the teams and to raise awareness, so hopefully
> more team representatives will come to this meeting. This meeting
> works best when we have representatives from all of the teams.
>
> For more information please check the [2] link.
>
> [1] https://apps.fedoraproject.org/calendar/meeting/9024/
> [2] https://fedoraproject.org/wiki/Release_Readiness_Meetings
>
> Thank you for your support,
> Regards, Jan
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic



-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Final status is GO

[Jan Kurik]

The Fedora_28_RC_1.1 compose [1] is considered as GOLD and it is going
to be shipped on 2018-May-01 as Fedora 28 Final release.

For more information please check the meeting minutes [2] from the
Go/No-Go meeting.

[1] http://dl.fedoraproject.org/pub/alt/stage/28_RC-1.1/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-04-26/f28-final-go-no-go-meeting.2018-04-26-17.02.html

Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Final Release Readiness Meeting on Thursday, April 26 @ 19:00 UTC

[Jan Kurik]

Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 28
Final Release Readiness Meeting meeting.

The meeting is going to be held on Thursday, April 26, 2018 at 19:00
UTC. Please check the [1] link for your time zone.

We will meet to make sure we are coordinated and ready for the Final
release of Fedora 28. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.

You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.

For more information please check the [2] link.

[1] https://apps.fedoraproject.org/calendar/meeting/9024/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings

Thank you for your support,
Regards, Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Final release Go/No-Go Meeting on Thursday, April 26 @ 17:00 UTC

[Jan Kurik]

Join us on irc.freenode.net in #fedora-meeting-1 for this important
meeting, wherein we shall determine the readiness of the Fedora 28
Final.

The meeting is going to be held on Thursday, April 26, 2018 at 17:00
UTC. Please check the [1] link for your time zone.

Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting. Verifying that
the Release criteria are met is the responsibility of the QA Team.

Release Candidate (RC) availability and good QA coverage are
prerequisites for the Go/No-Go meeting. If you have any bug on the
list, please help us with Beta release. If we won't be ready by
Thursday, we will use this meeting to review blockers and decide what
to do.

In the meantime, please keep also an eye on the Fedora 28 Final
Blocker list [2].

For more details about this meeting please follow the [3] link.

[1] https://apps.fedoraproject.org/calendar/meeting/9025/
[2] http://qa.fedoraproject.org/blockerbugs/milestone/28/final/buglist
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting

Thank you in advance for your support.
Regards, Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: java-openjdk 10 - rolling release for Short Term Support releases of OpenJDK

[Jan Kurik]

This is a late proposal for F28 release, mostly to spread awareness of the
availability of java-openjdk 10 in Fedora. It is not closely tied to the
F28 release however it would be good to have this in the formal F28 scope.
That is the reason, why after a discussion with the Change owner, this is
announced as a Self Contained Change Proposal.

= Proposed Self Contained Change: java-openjdk 10 - rolling release for
Short Term Support  releases of OpenJDK =
https://fedoraproject.org/wiki/Changes/java-openjdk-10


Owner(s):
  * Jiri Vanek 


OpenJDK have release  cadence of 6 months. but 3/4 of them are Short Term
Supported for 6 months only.  This package is designed to harbore them.
Currently it is build on openJDK 10. LTSs (next is 11) will go as separate
packages.
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf



== Detailed description ==
JDK10 is next major release of Java platform.  It is bringing many cool
improvements - http://openjdk.java.net/projects/jdk/10/ and is landing to
your Fedora.  Where it will be maintained for f27 and newer.  Unluckily, it
is STS (short term support) version. Between individual LTS will be always
several STS. Again, please
See announcement:
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
and See java SIG plans:
https://jvanek.fedorapeople.org/devconf/2018/changesInjavaReleaseProcess.pdf
.  So this is rolling release of all STSs to come. Its fate during the
release of fresh LTS is yet to be decided.
You will always be allowed to install  Used LTS in fedora build root,
alongside with latest  STS via alternatives.


== Scope ==
* Proposal owners:
This is isolated change. The maintainers of OpenJDK in Fedora must build
the binaries, and keep them working.  Still, to keep this rolling release
will be soem packaging challenge. Lets see this when JDK12  (or maybe
already 11) come out.

* Other developers:
Should slowly start to check theirs packages against JDK10

* Release engineering:
#7433 - https://pagure.io/releng/issue/7433

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Beta status is GO, release on April 03, 2018

[Jan Kurik]

The Fedora 28 Beta RC3 compose [1] is considered as GOLD and is going to be
shipped live on Tuesday, April 3rd, 2018.

For more information please check the Go/No-Go meeting minutes [2] or logs
[3].

I would like to thank all the people who were and are still working on this
release.

[1] http://dl.fedoraproject.org/pub/alt/stage/28_Beta-1.3/
[2]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.html

[3]
https://meetbot.fedoraproject.org/fedora-meeting/2018-03-29/f28-beta-go-no-go-meeting.2018-03-29-16.04.log.html


Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: Ansible python3 default

[Jan Kurik]

= Proposed Self Contained Change: Ansible python3 default  =
https://fedoraproject.org/wiki/Changes/Ansible_python3_default


Owner(s):
  * Kevin Fenzi 


Ansible started out as a python2 only application, but in recent years
a large amount of work has gone into porting things to python3. Last
year, the Fedora ansible package started shipping a ansible-python3
allowing users to switch to python3 on the control host easily if they
wished, but left the default as python2. Now in Fedora 29, the default
will be switched and the python3 version will be the only version
shipped.



== Detailed description ==
The Fedora ansible package will be changed to default to python3 with
the 'ansible' package. Note that this change is on the control host,
you can control what python is used on target hosts via your
inventory. You may continue to use python2 there, or use python3 as
your target hosts require.


== Scope ==
* Proposal owners:
Modify ansible package (already done)

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
#releng-7414 https://pagure.io/releng/7414

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: Stop building 389-ds-base on i686

[Jan Kurik]

= Proposed Self Contained Change: Stop building 389-ds-base on i686 =
https://fedoraproject.org/wiki/Changes/389-ds-base-remove-686


Owner(s):
  * Mark Reynolds 


389-ds-base does not work properly on i686 hardware in regards to atomic types.



== Detailed description ==
389-ds project have found an issue which causes system instability on
all versions of 1.4.x of the server on i686 platform. This is a
hardware limitation of the platform related to how we consume atomic
types. This may lead to thread unsafety and other issues.
- FreeIPA server will not be available on i686 due to this
- slapi-nis set of plugins will not be available on i686 due to this
- Upgrade of i686 instance of Fedora with FreeIPA server will not be
possible without fully uninstalling FreeIPA replica



== Scope ==
* Proposal owners:
This only requires a change to spec file to exclude i686

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
#6894: https://pagure.io/releng/issues/6894

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Ruby on Rails 5.2

[Jan Kurik]

= Proposed System Wide Change: Ruby on Rails 5.2 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.2


Owner(s):
  * Pavel Valena 
  * Vít Ondruch 
  * Jun Aruga 


Ruby on Rails 5.2 is the latest version of well known web framework
written in Ruby.



== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it. Therefore the whole Ruby on Rails stack should be
updated from 5.1 in Fedora 28 to 5.2 (latest version) in Fedora 29.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.


== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated
** Some dependencies of the Rails stack will need update
=== Packages need to be created/updated ===
- rubygem-activestorage - Create package
- rubygem-actioncable - Update to 5.2.x
- rubygem-actionmailer - Update to 5.2.x
- rubygem-actionpack - Update to 5.2.x
- rubygem-actionview - Update to 5.2.x
- rubygem-activejob - Update to 5.2.x
- rubygem-activemodel - Update to 5.2.x
- rubygem-activerecord - Update to 5.2.x
- rubygem-activesupport - Update to 5.2.x
- rubygem-rails - Update to 5.2.x
- rubygem-railties - Update to 5.2.x
- rubygem-arel - Update to 9.0.x

* Other developers:
Update Rails dependent packages to be working with Ruby on Rails 5.2

* Release engineering:
#7410 https://pagure.io/releng/issue/7410

**List of deliverables:
None

* Policies and guidelines:
Not needed

* Trademark approval:
Not needed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Beta status is NO-GO

[Jan Kurik]

Release status of the Fedora 28 Beta is NO-GO.

Due to missing RC for the F28 Beta release and presence of blocker
bugs, the decision is “No Go”. The Beta release slips for one week to
“Target #1” date (April 3rd). We are not going to slip the Final GA
yet.

For more information please check the minutes from the F28 Beta
Go/No-Go meeting [1][2].

[1] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-22/f28-beta-go-no-go-meeting.2018-03-22-17.00.html
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-03-22/f28-beta-go-no-go-meeting.2018-03-22-17.00.log.html

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Python 3.7

[Jan Kurik]

= Proposed System Wide Change: Python 3.7 =
https://fedoraproject.org/wiki/Changes/Python3.7


Owner(s):
  * Charalampos Stratakis 
  * Miro Hrončok 
  * Tomáš Orsava 
  * Petr Viktorin 


Update the Python 3 stack in Fedora from Python 3.6 to Python 3.7.



== Detailed description ==
Python 3.7 adds numerous features and optimizations. See the upstream
notes at https://www.python.org/dev/peps/pep-0537/#features-for-3-7
and https://docs.python.org/3.7/whatsnew/3.7.html .

=== Important dates ===
* 2018-05-21 Python 3.7.0 candidate 1
* 2018-06-04 Python 3.7.0 candidate 2 (if necessary)
* 2018-06-15 Python 3.7.0 final
* 2018-07-11Fedora 29 Mass Rebuild
* 2018-08-14Fedora 29 Change Checkpoint: Completion deadline (testable)
(From https://www.python.org/dev/peps/pep-0537/#schedule and
https://fedoraproject.org/wiki/Releases/29/Schedule .)

=== PEP 552 – Deterministic pycs ===
One change is notable from the packaging viewpoint:
https://www.python.org/dev/peps/pep-0552/ – “Deterministic pycs”. We
may decide to use the new UNCHECKED_HASH mode, which would mean that
bytecode cache is not validated on import, i.e. changing a
RPM-installed *.py file manually will have no effect (unless the
corresponding __pycache__/*.pyc is updated or removed).


== Scope ==
We will coordinate the work in a side tag and merge when ready.

* Proposal owners:
*# Retire python37 from F29+
*# Update python3 to what was in python37
*#* Mass rebuild all the packages that BR python3/python3-devel...
(~2300 listed in [http://fedora.portingdb.xyz/ Python 3 Porting
Database for Fedora])
*# Reintroduce python36 from Fedora 25. Update it to have all fixes
and enhancements from python3 in Fedora 28 (or 29 before this change)

* Other developers:
Maintainers of packages that fail to rebuild during the mass rebuild
will be asked, using bugzilla, to fix or remove their packages from
the distribution. If any issues appear, they should be solvable either
by communicating with upstreams first and/or applying downstream
patches. Also the package maintainers should have a look at:
https://docs.python.org/3.7/whatsnew/3.7.html#porting-to-python-3-7 .
And python-maint team will be available to help with fixing issues.

* Fedora QA:
Based on some troubles with the
https://fedoraproject.org/wiki/Changes/Python3.6 , we'd like to have
an ack from QA before we merge the side tag.

* Release engineering:
https://pagure.io/releng/issue/7390
A targeted rebuild for all python packages will be required, before
the mass rebuild.

** List of deliverables:
nope

* Policies and guidelines:
nope

* Trademark approval:
nope
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Beta Go/No-Go Meeting on Thursday, March 22 @ 17:00 UTC

[Jan Kurik]

Join us on irc.freenode.net in #fedora-meeting-1 for this important
meeting, wherein we shall determine the readiness of the Fedora 28
Beta.

The meeting is going to be held on Thursday, March 22, 2018 at 17:00
UTC. Please check the [1] link for your time zone.

Before each public release Development, QA and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is called the Go/No-Go Meeting. Verifying that
the Release criteria are met is the responsibility of the QA Team.

Release Candidate (RC) availability and good QA coverage are
prerequisites for the Go/No-Go meeting. If you have any bug on the
list, please help us with Beta release. If we won't be ready by
Thursday, we will use this meeting to review blockers and decide what
to do.

In the meantime, please keep also an eye on the Fedora 28 Beta Blocker list [2].

For more details about this meeting please follow the [3] link.

[1] https://apps.fedoraproject.org/calendar/meeting/8824/
[2] http://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist
[3] https://fedoraproject.org/wiki/Go_No_Go_Meeting

Thank you in advance for your support.
Regards, Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Beta Release Readiness Meeting on Thursday, March 22 @ 19:00 UTC

[Jan Kurik]

Join us on irc.freenode.net in #fedora-meeting-1 for the Fedora 28
Beta Release Readiness Meeting meeting.

The meeting is going to be held on Thursday, March 22, 2017 at 19:00
UTC. Please check the [1] link for your time zone.

We will meet to make sure we are coordinated and ready for the Beta
release of Fedora 28. Please note that this meeting is going to be
held even if the release is delayed at the Go/No-Go meeting on the
same day two hours earlier.

You may received this message several times, but it is by purpose to
open this meeting to the teams and to raise awareness, so hopefully
more team representatives will come to this meeting. This meeting
works best when we have representatives from all of the teams.

For more information please check the [2] link.


[1] https://apps.fedoraproject.org/calendar/meeting/8823/
[2] https://fedoraproject.org/wiki/Release_Readiness_Meetings

Thank you for your support,
Regards, Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Make dbus-broker the default DBus implementation

[Jan Kurik]

= Proposed System Wide Change: Make dbus-broker the default DBus
implementation =
https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation


Owner(s):
  * David Herrmann 
  * Tom Gundersen 


Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.


== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial announcement of dbus-broker. An
excerpt:

* Accounting: dbus-broker maintains per-user accounting, including
inter-user quotas. This guarantees that no single user can cause
irregularly high memory consumption in the daemon. Unlike dbus-broker,
dbus-daemon accounts memory in a multi-tier system, based on plain
resource counters on users, connections, and other resources. The
multi-tier system suffers from resource-chaining-exhaustion, where
clients effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The single-tier accounting scheme of dbus-broker avoids this,
while at the same time adding inter-user quotas to prevent misuse even
across clients.

* Reliability: While D-Bus is used on reliable transports, dbus-daemon
might still silently drop messages and given circumstances. This is
the only possible solution dbus-daemon has, given several of its
runtime guarantees. The dbus-broker project changed the architecture
of the bus daemon to a degree, that it can provide many guarantees,
including that no message will be silently, or unexpectedly, dropped.

* Scalability: The message bus broker is a crucial infrastructure on
modern linux system, which is a hot-path for almost all IPC going on.
Hence, the broker should perform fast and be scalable to its users.
dbus-daemon has several **global** data-structures that affect the
overall scalability of independent message transactions. dbus-broker
does not employ any global data-structures (unless required by the
spec), as such any message transaction is only affected by the data
provided by the involved peers. Moreover, even for spec-defined global
behavior, dbus-broker avoids global data-structures, unless clients
actually make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.

* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.


== Scope ==
* Proposal owners:
** Fix regressions.
** Enable dbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.

* Other developers:
** Watch for regressions

* Release engineering: #7262 https://pagure.io/releng/issues/7262

* List of deliverables:
N/A

* Policies and guidelines:
No changes needed.

* Trademark approval:
No changes needed.
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer

[Jan Kurik]

= Proposed Self Contained Change: OpenLDAP: Drop MozNSS Compatibility Layer =
https://fedoraproject.org/wiki/Changes/OpenLDAPdropMozNSSCompatibilityLayer


Owner(s):
  * Matus Honek 


Since Fedora 28, OpenLDAP is compiled with OpenSSL instead of NSS and
includes MozNSS Compatiblity Layer (i.e. TLSMC) to assure backwards
compatiblity. After this change the TLSMC will be removed.



== Detailed description ==
This change drops support for NSS-like configuration style for TLS in
OpenLDAP. Only PEM files will be supported. This is the expected
follow-up to the Changes/OpenLDAPwithOpenSSL [1].
The change will be accomplished by dropping a downstream patch that
brings the feature and removing all the related statements from the
SPEC file, including --enable-moznss-compatiblity=yes configure
option.

[1] https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL


== Scope ==
* Proposal owners:
Drop downstream patching as described in #Detailed Description

* Other developers:
N/A (not a System Wide Change)

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

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Jan Kurik]

On Tue, Mar 6, 2018 at 10:34 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Mar 06, 2018 at 09:25:16AM +0100, Jan Kurik wrote:
>> Today, on 2018-Mar-06, we reach two important milestones of the Fedora
>> 28 release [1]:
>>
>> == Change Checkpoint: 100% Code Complete Deadline [2] ==
>> * New accepted changes must be code complete, meaning all the code
>> required to enable a new Change is finished.
>> * The level of code completeness is reflected in tracker bug as state
>> "ON_QA". The change does not have to be fully tested by this deadline.
>>
>> == Beta Freeze [3] ==
>> Only packages fixing a bug approved as Accepted Blocker or Freeze
>> Exception [4] will be marked as 'stable' and included in Beta
>> composes. Other builds will remain in updates-testing until the Beta
>> release is approved, at which point the Beta Freeze is lifted and
>> packages can move to 'stable' as usual until the Final Freeze.
>
> To clarify: "today we reach" means "today at midnight UTC we reached"?
> I think it'd be clarify the text of this mail, because it's not
> immediately obvious if the freeze is already in effect or not yet.

Yes, the freeze is already in effect. Please see the following text in
the F28 Schedule [1]:

" Beta and Final freezes are in effect from 00:00 UTC of the freeze day."

[1] https://fedoraproject.org/wiki/Releases/28/Schedule

Jan

> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Software Translation Deadline has been reached

[Jan Kurik]

Today on 2018-Mar-06 [1] we have reached the Software Translation
Deadline [2]. At this time all the strings translations should be
substantially finished.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/L10N_Freezes#Translation_Deadline

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze

[Jan Kurik]

Today, on 2018-Mar-06, we reach two important milestones of the Fedora
28 release [1]:

== Change Checkpoint: 100% Code Complete Deadline [2] ==
* New accepted changes must be code complete, meaning all the code
required to enable a new Change is finished.
* The level of code completeness is reflected in tracker bug as state
"ON_QA". The change does not have to be fully tested by this deadline.

== Beta Freeze [3] ==
Only packages fixing a bug approved as Accepted Blocker or Freeze
Exception [4] will be marked as 'stable' and included in Beta
composes. Other builds will remain in updates-testing until the Beta
release is approved, at which point the Beta Freeze is lifted and
packages can move to 'stable' as usual until the Final Freeze.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Milestone_freezes
[4] https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: Software Translation Deadline in 1 week

[Jan Kurik]

In one week on 2018-Mar-06 [1] we will reach the Software Translation
Deadline [2]. At the time of the deadline all the strings translations
should be substantially finished.

Any help with the translations is welcomed.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/L10N_Freezes#Translation_Deadline

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Software String Freeze is today

[Jan Kurik]

Today (2018-Feb-27) we have reached the "Software String Freeze"
deadline. Beyond this deadline there should not be any changes in
strings, ideally.

If you want to help with translations then, please check the packages
that follow Fedora release cycle (Main projects):
https://fedora.zanata.org/version-group/view/main

The time limit for the translations is according to the schedule [1]
planned on 2018-Mar-06 (Software Translation Deadline).

[1] https://fedorapeople.org/groups/schedule/f-28/f-28-trans-tasks.html

Thanks for all translated strings and Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: Fedora 28 Change Checkpoint: 100% Code Complete Deadline & Beta Freeze in 1 week

[Jan Kurik]

The next Tuesday, on 2018-Mar-06, we will reach two important
milestones of the Fedora 28 release [1]:

== Change Checkpoint: 100% Code Complete Deadline [2] ==
* New accepted changes must be code complete, meaning all the code
required to enable to the new change is finished.
* The level of code completeness is reflected as tracker bug state
ON_QA. The change does not have to be fully tested by this deadline.

== Beta Freeze [3] ==
Only packages which fix accepted blocker or freeze exception bugs [4]
will be marked as 'stable' and included in the Beta composes. Other
builds will remain in updates-testing until the Beta release is
approved, at which point the Beta freeze is lifted and packages can
move to 'stable' as usual until the Final freeze.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Milestone_freezes
[4] https://qa.fedoraproject.org/blockerbugs/milestone/28/beta/buglist

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: F28 Software String Freeze in one week

[Jan Kurik]

According to the Fedora 28 schedule [1] we are going to reach the
"Software String Freeze" deadline in one week on 2018-Feb-27. Beyond
this deadline there should not be any changes in strings, ideally.

If you want to help with translations then, please check the packages
that follow Fedora release cycle (Main projects):
https://fedora.zanata.org/version-group/view/main

The time limit for the translations is according to the schedule [1]
planned on 2018-Mar-06 (Software Translation Deadline).


[1] https://fedorapeople.org/groups/schedule/f-28/f-28-trans-tasks.html


Thanks for all translated strings and Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Change Checkpoint: Completion deadline (testable)

[Jan Kurik]

Greetings!

Today, on 2018-Feb-20, we have reached Fedora 28 Change
Checkpoint:Completion deadline (testable) [1].

At this point, all accepted changes [2] should be substantially
complete, and testable. Additionally, if a change is to be enabled by
default, it must be enabled at Change Completion deadline as well.

Change tracking bug should be set to the MODIFIED state to indicate it
achieved completeness.

Incomplete and non testable Changes [3] will be reported to FESCo on
2018-Feb-23 meeting. Contingency plan for System Wide Changes in case
of serious doubts regarding Change completion, will be activated.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule
[2] https://fedoraproject.org/wiki/Releases/28/ChangeSet
[3] http://red.ht/2BEyQt0
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: FedoraScientific VagrantBox

[Jan Kurik]

= Proposed Self Contained Change: FedoraScientific VagrantBox =
https://fedoraproject.org/wiki/Changes/FedoraScientific_VagrantBox


Owner(s):
  * Amit Saha 


Fedora Scientific is currently delivered as ISOs. Shipping vagrant
boxes will give potential users a friendlier option to try out Fedora
Scientific while keeping their current operating system.



== Detailed description ==
Vagrant boxes for Fedora Scientific will allow users to easily run
Fedora Scientific in a virtual machine. This can be useful for users
who are using another operating system as their host operating system
and not have to manually download the ISO, and go through the
installation process which can be unfamiliar or unnecessary hassle for
users who may be new to Fedora or Linux.


== Scope ==
* Proposal owners:
This will require creating pungi configuration as well as new
kickstarts to be able to build the vagrant boxes for Fedora
Scientific.

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
https://pagure.io/releng/issue/7324

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Remove GCC from BuildRoot

[Jan Kurik]

Proposed System Wide Change: Remove GCC from BuildRoot
https://fedoraproject.org/wiki/Changes/Remove_GCC_from_BuildRoot


Owner(s):
  * Igor Gnatenko 


Removing gcc and gcc-c++ from default buildroot in Koji and mock.



== Detailed description ==
Since beginning of Fedora, gcc (and gcc-c++) are installed in every
buildroot. Times have changed and nowadays many of packages are not
written in C/C++, they are written in Python, Ruby, Node.js, Go, Rust,
OCaml, Perl and so on so they don't need to have C/C++ compiler.
Installing gcc and gcc-c++ takes time so if we remove it, we can
improve build times for many of the packages.


== Scope ==
* Proposal owners:
Remove gcc, gcc-c++ from build group in Koji and from buildsys-build
group in comps.

* Other developers:
Maintainers should follow guidelines and add BuildRequires: gcc if
they need it during build (this guideline exists for long time).

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

** List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
Nothing needed, guidelines already have paragraph about listing all
required BuildRequires.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: Drop Legacy GTK+ GUI in wireshark

[Jan Kurik]

Proposed Self Contained Change: Drop Legacy GTK+ GUI in wireshark
https://fedoraproject.org/wiki/Changes/Drop_Legacy_GTK+_GUI_in_wireshark

Owner(s):
  * Michal Ruprich 



== Detailed description ==
Since wireshark-2.0 there are two GUIs availble for use. One is based
on GTK+ and the other on Qt. The upstream focuses on the development
of the Qt-based GUI and the GTK-based GUI has been marked as legacy.
Since wireshark 2.4.0 the GTK-based GUI is not supported anymore and
it is disabled by default. We should drop the GTK-based wireshark in
Fedora 29.


== Scope ==
* Proposal owners:
This is an isolated change. The new GUI is more or less the same as
the new one. It does not affect any functionality of wireshark
package. This will be a very easy change from developer point of view.

* Other developers:
N/A (not a System Wide Change)

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

**List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: True Noarch Erlang Packages

[Jan Kurik]

Proposed Self Contained Change: True Noarch Erlang Packages
https://fedoraproject.org/wiki/Changes/TrueNoarchErlangPackages


Owner(s):
  * Randy Barlow 


Erlang packages are currently all installed into
%{_libdir}/erlang/lib, despite most of them being noarch packages.
This proposal is to modify Erlang to search %{_datadir}/erlang/lib in
addition to %{_libdir}/erlang/lib when searching for dependencies.



== Detailed description ==
The Erlang VM is currently hardcoded to search for dependencies in
%{_libdir}/erlang/lib (on x86_64 this is /usr/lib64/erlang/lib). Due
to this, all Erlang packages are currently compiled "archful", despite
most of them being pure Erlang and thus truly noarch. This leads to
longer build times for Erlang packages, and more storage used in Koji
and on the mirrors.
This change proposes to add an additional path to be searched by the
Erlang VM when finding dependencies at %{_datadir}/erlang/lib (on
x86_64 this is /usr/share/erlang/lib). Additionally, the build macros
will be udpated to automatically use this new path for installation
for noarch packages. "Archful" packages will continue to store their
files where they do today.


== Scope ==
* Proposal owners:
** Write a small patch for the Erlang VM to search two paths instead
of one when loading dependencies. We will attempt to get this patch
accepted upstream first, but we will then carry the patch downstream
until accepted by upstream.
** Modify the Erlang RPM macros to use the new path for noarch packages.

* Other developers:
** Any developers who are not using the Erlang install RPM macro
should modify their spec file to either use the macro, or to install
their noarch packages to the new location.

* Release engineering:
[https://pagure.io/releng/issue/6685 #6685]
** We could mass-rebuild Erlang packages, but everything should keep
working without doing a mass rebuild so it is probably not necessary
or worthwhile, unless we want to more immediately clear up a little
disk space. The recommendation is to wait until the next mass rebuild
since there will be no interruptions for existing packages, i.e., no
effort required from Releng.
** Any erlang packages that switch from being archful to being noarch
will need all their dependent packages to be rebuilt, since they will
no longer provide archful versions of themselves. However, this can be
done at the time each package switches to being noarch. This change
will not switch any particular packages to noarch.

**List of deliverables: N/A (not a System Wide Change)

* Policies and guidelines:
** Erlang packages do not have formal packaging guidelines yet, though
this document does exist:
https://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines
*** We should update the WIP guidelines.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: No more automagic Python bytecompilation

[Jan Kurik]

Proposed Self Contained Change: No more automagic Python bytecompilation
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation


Owner(s):
  * Miro Hrončok 
  * Petr Viktorin 


The current way of automatic Python byte-compiling of files outside
Python-specific directories is too magical and error-prone. It is
built on heuristics that are increasingly wrong.
We will provide a way to opt-out of it and adjust the guidelines to
prefer explicit bytecompilation of such files. Later, the old behavior
will be opt-in only or will cease to exist.
Note that bytecompilation in Python-specific directories (e.g.
/usr/lib/python3.6/) is not affected.



== Detailed description ==
[Change wrangler note]: As the detailed description of this Change
proposal is quite extensive I am just referring to the Change Proposal
wiki page: 
https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompilation#Detailed_Description
. Please review the proposal following the link.


== Scope ==
* Proposal owners:
Make it work technically, propose the new guidelines, file pull
requests for python3 modules that follow the current guidelines.

* Other developers:
Maintainers of python3 packages that redefine %__python should merge
provided pull requests. Others may opt-in for the new behavior or
explicitly stick with the old one (not a System Wide Change, they
don't have to do anything).

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

* Policies and guidelines:
will be changed as described in description

* Trademark approval:
not needed
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 System Wide Change: Enable dbus-broker

[Jan Kurik]

Proposed System Wide Change: Enable dbus-broker
https://fedoraproject.org/wiki/Changes/EnableDbusBroker


Owner(s):
  * David Herrmann 
  * Tom Gundersen 


Enable dbus-broker.service to use dbus-broker as system and session
message bus backend.



== Detailed description ==
The dbus-broker project is an implementation of a message bus as
defined by the D-Bus specification. Its aim is to provide high
performance and reliability, while keeping compatibility to the D-Bus
reference implementation. It is exclusively written for linux systems,
and makes use of many modern features provided by recent linux kernel
releases.
The main focus points of dbus-broker are reliability, scalability and
security. The dbus-broker project tries to improve on these points
over dbus-daemon, and thus provide a better alternative. And in-depth
analysis can be found in the initial
[https://dvdhrm.github.io/rethinking-the-dbus-message-bus/
announcement] of dbus-broker. An excerpt:
* [https://github.com/bus1/dbus-broker/wiki/Accounting Accounting]:
dbus-broker maintains per-user accounting, including inter-user
quotas. This guarantees that no single user can cause irregularly high
memory consumption in the daemon. Unlike dbus-broker, dbus-daemon
accounts memory in a multi-tier system, based on plain resource
counters on users, connections, and other resources. The multi-tier
system suffers from resource-chaining-exhaustion, where clients
effectively circumvent the accounting by creating multiple
connections/objects, which themselves grant them each a new set of
quotas. The [https://github.com/bus1/dbus-broker/wiki/Accounting
single-tier accounting] scheme of dbus-broker avoids this, while at
the same time adding inter-user quotas to prevent misuse even across
clients.
* [https://github.com/bus1/dbus-broker/wiki/Reliability Reliability]:
While D-Bus is used on reliable transports, dbus-daemon might still
silently drop messages and given circumstances. This is the only
possible solution dbus-daemon has, given several of its runtime
guarantees. The dbus-broker project changed the architecture of the
bus daemon to a degree, that it can provide many
[https://github.com/bus1/dbus-broker/wiki/Reliability guarantees],
including that no message will be silently, or unexpectedly, dropped.
* [https://github.com/bus1/dbus-broker/wiki/Scalability Scalability]:
The message bus broker is a crucial infrastructure on modern linux
system, which is a hot-path for almost all IPC going on. Hence, the
broker should perform fast and be scalable to its users. dbus-daemon
has several **global** data-structures that affect the overall
scalability of independent message transactions. dbus-broker does not
employ any global data-structures (unless required by the spec), as
such any message transaction is only affected by the data provided by
the involved peers. Moreover, even for spec-defined global behavior,
dbus-broker avoids global data-structures, unless clients actually
make use of these obscure features. In several other cases,
dbus-daemon scales O(n) time looking up message targets and related
data. dbus-broker runs all these in O(log(n)) time.
* Linux-specific: The dbus-broker project was explicitly designed for
linux system, making use of many linux-specific APIs and behavior.
This allows mitigation of several possible DoS attacks.


== Scope ==
* Proposal owners:
** Fix regressions.
** Enabledbus-broker.service in system and user-global context of
systemd (via systemd presets).
** Pull in dbus-broker package from dbus package.

* Other developers:
** Watch for regressions

* Release engineering:
[https://pagure.io/releng/issues/7262 #7262]

** List of deliverables:
N/A

* Policies and guidelines:
No changes needed.

* Trademark approval:
No changes needed.
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F29 Self Contained Change: BINUTILS 2.30

[Jan Kurik]

Proposed Self Contained Change: BINUTILS 2.30
https://fedoraproject.org/wiki/Changes/BINUTILS230


Owner(s):
  * Nick Clifton 


Rebase the binutils package from version 2.29 .1 to version 2.30. This
will bring in bug-fixes and some new features.



== Detailed description ==
Switch the binutils package from being based on the 2.29.1 release of
the FSF binutils to being based on the 2.30 release. This release
includes bug-fixes and new features.


== Scope ==
* Proposal owners:
Replace the 2.29.1 source tarball with the 2.30 source tarball and
update the Fedora specific patches.  (This work has already been
completed locally and is ready for comitting).

* Other developers:
None.

* Release engineering:
https://pagure.io/releng/issue/7282 - A mass rebuild is required.

** List of deliverables:
Just the binutils packages.

* Policies and guidelines:
No updates needed.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Rawhide Rebase Warning to Package Maintainers

[Jan Kurik]

Greetings,

This e-mail is intended to inform you about the upcoming Bugzilla changes
happening on 2018-02-20 (Rawhide bug rebase) and what you need to do, if
anything.

We will be automatically changing the version for most rawhide bugs to
Fedora 28.
This will result in regular bugs reported against rawhide during the Fedora
28
development cycle being changed to version ‘28' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora 28
from
rawhide and to more accurately tell where in the lineage of releases the
bug was
last reported.

Note that this procedure does not apply to bugs that are open for the
‘Package
Review’ or 'kernel' components or bugs that have the ''FutureFeature'' or
''Tracking'' keywords
set. These will stay open as rawhide bugs indefinitely.

If you do not want your bugs changed to version ‘28‘, add the
''FutureFeature''
keyword. If you need help changing a large amount of bugs manually, we’d be
glad
to help.

The process was re-approved by FESCo https://pagure.io/fesco/issue/1096 .

Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: Atomic, Cloud and Docker images for s390x

[Jan Kurik]

= Proposed Self Contained Change: Atomic, Cloud and Docker images for s390x =
https://fedoraproject.org/wiki/Changes/Atomic_Cloud_and_Docker_images_for_s390x

Change owner(s):
* Sinny Kumari 


This change is to bring s390x architecture closer to other Fedora
architectures by adding widely used Fedora variants. This includes
docker images, Atomic Host (iso, qcow2 and raw format) and regular
Cloud Images (qcow2 and raw format).


== Detailed Description ==
We already ship Atomic, Cloud and Docker images on other 64-bit Fedora
supported architectures- aarch64, x86_64 and ppc64le. With Fedora 27,
s390x is part of primary koji build system. Currently, we only ship
Server and Everything variants for s390x. So, our next steps should be
to have missing Fedora variants on s390x architecture which users will
find useful. This brings in shipping Atomic, Cloud and Docker images
in Fedora for s390x as well.


== Scope ==
* Proposal owners:
These are isolated changes which doesn't impact existing Fedora 28
release plan on s390x. To have these changes ready to ship in Fedora
28, we mainly require s390x koji builders configured to run these
composes, changes in pungi configuration [
https://pagure.io/pungi-fedora/pull-request/496 ] to enable the
additional compose and fixing s390x specific issues encountered when
compose fails to run.

* Other developers:
Changes in Fedora infrastructure configs/scripts will be required to
have s390x builders configured to run additional composes. Fedora
Infrastructure issue [
https://pagure.io/fedora-infrastructure/issue/6659 ] has been filed to
keep track of required changes to be done.

* Release engineering:
#Releng 7286: https://pagure.io/releng/issue/7286

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Change Checkpoint: Proposal submission deadline (Self contained Changes) on Fedora 28 is today

[Jan Kurik]

Hi everyone!

Today is the submission deadline for Self contained Changes of Fedora
28 [1]. Please schedule your upcoming Changes (Self contained as well
as System wide) for the next (Fedora 29) release.
Branch of Fedora 28 from Rawhide is then planned on 2018-Fed-20.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: VA-API 1.0.0

[Jan Kurik]

= Proposed Self Contained Change: VA-API 1.0.0 =
https://fedoraproject.org/wiki/Changes/VA-API_1.0.0

Change owner(s):
* Nicolas Chauvet 

This change is about upgrading libva and others to version 2.0. This
change affects several multimedia players as there are both API and
ABI changes. This will allow some VA-API backends to be updated,
improving support for recent hardware.

== Detailed Description ==

Updating to VA-API 1.0.0 will allow to fix and clean-up issues with
the API as sum-up in this upstream topic VA-API 1.0.0:
https://github.com/intel/libva/issues/72

* fix errors in API/data structure definition, e.g. 01org#32
* add new features, e.g. 01org#69,
* deprecate some useless API/data structures, e.g. libva-tpi, libva-egl.
* provide other improvement, e.g. use portable type to define data structure.

All packages using libva will be rebuilt to take into account the new
API/ABI. Futhermore, the intel backend will be updated along (not
provided by Fedora). Others VA-API backend such the AMD and NVIDIA
backend provided by Fedora within mesa-dri-drivers will work as
appropriate. Bridges between VA-API and VDPAU will continue to be
supported , this is:

* libva-vdpau-driver which allows to use the VA-API enabled players
with VDPAU backend (such as NVIDIA binary driver).
* libvdpau-va-gl which allows to use the VDPAU API enabled players
with VA-API backends (such as intel driver).


== Scope ==
* Proposal owners:
- Update and rebuild packages that depend on libva. DONE
- Verify that everything is working as appropriate or report issue
upstream. TESTING IN PROGRESS.

* Other developers:
N/A

* Release engineering:
#7285 : https://pagure.io/releng/issue/7285

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 Self Contained Change: Removing ldconfig scriptlets

[Jan Kurik]

= Proposed Self Contained Change: Removing ldconfig scriptlets =
https://fedoraproject.org/wiki/Changes/Removing_ldconfig_scriptlets

Change owner(s):
* Igor Gnatenko 
* Neal Gompa 

For many years, package maintainers were required to write scriptlets
which call ldconfig in %post/%postun if they package shared libraries.

== Detailed Description ==
Since time immemorial, Red Hat/Fedora packagers have been required to
add a stanza to spec files for packages containing libraries to update
the ldconfig cache.

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

To say this is annoying is to put it mildly. However, there was no
standard mechanism to make this boilerplate go away. Now with RPM
4.13+, we should change this to file triggers and make all of that go
away.

With this change, these scriptlets can be removed and ldconfig would
be run just once per transaction.

If your package places shared libraries in special locations
referenced by ld.so.conf, you still need to run ldconfig manually.

For those who concerned about whether this is self-contained or
system-wide change: there is no overhead if packagers don't remove
ldconfig scriptlets in time, so completion doesn't depend whether
packagers remove them or not. We are just making it possible.


== Scope ==
* Proposal owners:
Make sure that DSO symlinks are being packagedcommit, add transaction
filetriggers to glibccommit + commit.

* Other developers:
Package maintainers are advised to remove ldconfig scriptlets in order
to achieve benefits specified above.

* Release engineering:
#7284: https://pagure.io/releng/issue/7284

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
Packaging guidelines need to be updated to reflect reality.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

FESCo Elections - January 2018 - Result announcement

[Jan Kurik]

Greetings, all!

The elections for FESCo - January 2018 have concluded, and
the results are shown below.

FESCo is electing 5 seats this time.
A total of 143 ballots were cast, meaning a candidate
could accumulate up to 1001 votes (143 * 7).

The results for the elections are as follows:

  # votes |  name
- +--
 703  | Kevin Fenzi (nirik)
 579  | Adam Miller (maxamillion)
 512  | Jared Smith (jsmith)
 503  |  Josh Boyer ( jwboyer/jwb )
 483  | Zbigniew Jędrzejewski-Szmek (zbyszek)
- +--
 469  | Justin Forbes (jforbes)
 420  | Dominik Mierzejewski (rathann)


Congratulations to the winning candidates, and thank you all
candidates for running this elections!

[1] https://admin.fedoraproject.org/voting/about/fesco-january-2018
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org