Re: Donate 1 minute of your time to test upgrades from F29 to F30

[Jaroslav Reznik]

On Thu, Feb 28, 2019 at 10:24 AM Miroslav Suchý  wrote:
>
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and 
> try to run:
>
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> --enablerepo=updates-testing distro-sync

(Some are related to missing RPM Fusion).

Error:
Problem 1: package rpmfusion-free-release-29-1.noarch requires
system-release(29), but none of the providers can be installed
 - fedora-release-29-7.noarch does not belong to a distupgrade repository
 - problem with installed package rpmfusion-free-release-29-1.noarch
Problem 2: package vlc-core-1:3.0.6-16.fc29.x86_64 requires
libprotobuf-lite.so.15()(64bit), but none of the providers can be
installed
 - protobuf-lite-3.5.0-8.fc29.x86_64 does not belong to a distupgrade repository
 - problem with installed package vlc-core-1:3.0.6-16.fc29.x86_64
Problem 3: package whois-mkpasswd-5.4.1-1.fc29.x86_64 requires
whois-nls = 5.4.1-1.fc29, but none of the providers can be installed
 - whois-nls-5.4.1-1.fc29.noarch does not belong to a distupgrade repository
 - problem with installed package whois-mkpasswd-5.4.1-1.fc29.x86_64
Problem 4: package blender-1:2.79b-10.fc30.x86_64 requires
libboost_locale.so.1.66.0()(64bit), but none of the providers can be
installed
 - problem with installed package blender-1:2.79b-9.fc29.x86_64
 - boost-locale-1.66.0-14.fc29.x86_64 does not belong to a distupgrade
repository
 - blender-1:2.79b-9.fc29.x86_64 does not belong to a distupgrade repository
Problem 5: package fedora-release-29-7.noarch requires
fedora-repos(29) >= 1, but none of the providers can be installed
 - package rpmfusion-nonfree-release-29-1.noarch requires
system-release(29), but none of the providers can be installed
 - fedora-repos-29-3.noarch does not belong to a distupgrade repository
 - problem with installed package rpmfusion-nonfree-release-29-1.noarch
Problem 6: problem with installed package freecad-1:0.17-2.fc29.x86_64
 - package freecad-1:0.17-2.fc30.x86_64 requires
libboost_atomic.so.1.66.0()(64bit), but none of the providers can be
installed
 - freecad-1:0.17-2.fc29.x86_64 does not belong to a distupgrade repository
 - boost-atomic-1.66.0-14.fc29.x86_64 does not belong to a distupgrade
repository
Problem 7: package freecad-data-1:0.17-2.fc30.noarch requires freecad
= 1:0.17-2.fc30, but none of the providers can be installed
 - problem with installed package freecad-data-1:0.17-2.fc29.noarch
 - package freecad-1:0.17-2.fc30.x86_64 requires
libboost_chrono.so.1.66.0()(64bit), but none of the providers can be
installed
 - freecad-data-1:0.17-2.fc29.noarch does not belong to a distupgrade repository
 - boost-chrono-1.66.0-14.fc29.x86_64 does not belong to a distupgrade
repository

Thanks,
Jaroslav

> If you get this prompt:
>
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
>
> you can answer N and nothing happens, no need to test the real upgrade. 
> Upgrades will be fine for you.
>
> But very likely you get some dependency problem now. In that case please 
> report it against appropriate package.
>
> Thank you
>
> Miroslav
> ___
> 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



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
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

Re: Proposal: Add release announcement post to Go/No-Go criteria

[Jaroslav Reznik]

On Wed, Sep 26, 2018 at 12:38 AM Matthew Miller 
wrote:

> On Tue, Sep 25, 2018 at 04:35:09PM -0400, Ben Cotton wrote:
> > With today's Beta release, the release announcement post for Fedora
> > Magazine was not ready. As a result, the announcement went out a
> > little late and then only due to a drop-everything effort (thanks,
> > stickster!). We have a proposal to add a fourth criterion for the
> > Go/No-Go decision, beginning with F29 Final:
>
> Isn't this supposed to be the point of the release-readiness meeting that
> follows go/no-go?
>

Indeed, it is part of the readiness meeting but even that might not be
sufficient sometimes. This happened to me once that the Beta release
announcement wasn't really ready (and I had to write it then...) even I was
told on the readiness meeting it is ready :). And it's a knowledge that
somehow transferred from Program Manager to Program Manager to always
recheck the status but it gets lost over generations :))) (and you're doing
a great job Ben!). Go/No-Go meeting is really a not a good candidate but
maybe some changes to how the Readiness meeting is done might help. Instead
of status meeting we can change it more to the Readiness Check-list like
thing with predefined tasks that are neccessary for the release. Just one
note - afaik Readiness meeting does not block the release automatically if
something is not ready but I believe it's kind of common sense to block
when something like announcement is not ready (but you always have like 5
days between first possible GA date and Readiness meeting).

Thanks,
Jaroslav


>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://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
>
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
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

Reminder: Fedora 24 End Of Life on 2017-Aug-08

[Jaroslav Reznik]

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

[1] 
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora26#Fedora_24_EOL_Closure

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

F27 Self Contained Change: libpinyin 2.1

[Jaroslav Reznik]

= Proposed Self Contained Change: libpinyin 2.1 =
https://fedoraproject.org/wiki/Changes/libpinyin2.1

Change owner(s):
* Peng Wu 

libpinyin 2.1 will merge libzhuyin code and replace the package

== Detailed Description ==
Actually libzhuyin uses very similar code as libpinyin. After merged
libzhuyin into libpinyin, it will bring some libpinyin features to
libzhuyin.

== Scope ==
* Proposal owners:

merge libzhuyin code into libpinyin.
merge libzhuyin data into ibus-libzhuyin.
retire libzhuyin package for Fedora 27.

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

* Release engineering: [1]
* Policies and guidelines: N/A (not a System Wide Change)

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

[1] https://pagure.io/releng/issue/6912

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

F27 Self Contained Change: Chinese Serif Fonts

[Jaroslav Reznik]

= Proposed Self Contained Change: Chinese Serif Fonts =
https://fedoraproject.org/wiki/Changes/ChineseSerifFonts

Change owner(s):
* Peng Wu 

Fedora already provides default Chinese Sans fonts, now Fedora 27 will
also provide default Chinese Serif fonts.

== Detailed Description ==
Adobe and Google released good quality Chinese Sans and Serif fonts
now. Now Fedora 27 will package the Chinese fonts, and use the fonts
as default Chinese fonts.

== Scope ==
* Proposal owners:

new packages for adobe-source-han-serif-cn-fonts and
adobe-source-han-serif-tw-fonts.
update font packages to use both Chinese Sans and Serif fonts
update fedora-comps to install the Chinese Sans and Serif fonts by default

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

* Release engineering: [1]

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

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

[1] https://pagure.io/releng/issue/6911

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

F27 Self Contained Change: New default cipher in OpenVPN

[Jaroslav Reznik]

= Proposed Self Contained Change: New default cipher in OpenVPN =
https://fedoraproject.org/wiki/Changes/New_default_cipher_in_OpenVPN

Change owner(s):
* David Sommerseth 

Since the discovery of the SWEET32 flaw [1], ciphers using
cipher-blocks smaller than 128-bits are considered vulnerable and
should not be used any more. OpenVPN uses Blowfish (BF-128-CBC) as the
default cipher, which is hit by the SWEET32 flaw. This proposal
changes the default cipher to AES-256-GCM while in parallel allowing
clients to connect using AES-256-CBC, AES-128-CBC or the deprecated
BF-CBC,

This proposal will make use of that possibility by modifying the
openvpn-server@.service unit file slightly.

== Detailed Description ==

There have been two independent security audits of OpenVPN recently,
performed by QuarksLab SAS [2] and Cryptography Engineering [3]. Both
recommends moving away from the default Blowfish cipher (BF/BF-CBC) to
a stronger cipher.

The concept is fairly simple.  In today's openvpn-server@.service
systemd unit file the following command line is used to start OpenVPN:

ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --config %i.conf

By adding --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC before the
--config option, the default cipher will be modified.  The
--ncp-ciphers list allows clients to use any of the listed ciphers as
well.  The new line will look like this:

ExecStart=/usr/sbin/openvpn --status
%t/openvpn-server/status-%i.log --status-version 2
--suppress-timestamps --cipher AES-256-GCM --ncp-ciphers
AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config
%i.conf

This will result in the following:
* OpenVPN 2.4 based clients will automatically upgrade to AES-256-GCM,
regardless if they have --cipher in their configuration file or not.
For OpenVPN v2.4 configurations not wanting this cipher upgrade, the
client configuration needs to deploy --ncp-disable.
* OpenVPN 2.3 based clients and older (and v2.4 clients using
--ncp-disable in the client configuration) can connect to the server
using any of the --ncp-ciphers list; this is what is called "poor
man's cipher negotiation" by the upstream OpenVPN developers.
* Any client not providing --cipher defaults to BF-CBC.  These clients
should still be able to connect to the server as the server allows
BF-CBC through --ncp-ciphers.

If an already configured OpenVPN v2.4  based server configuration
deploys --cipher and/or --ncp-ciphers, the options in the
configuration file will override command line options set before
--config.  This should not break any existing configuration.

The log files will still complain about the use of BF-CBC if a client
uses that.  But the advantage is that OpenVPN v2.3 and older clients
can be updated one-by-one, by adding the recommended --cipher
AES-256-CBC option in the client configurations in their own pace,
independent of the server - or upgrade to OpenVPN v2.4 or newer.

== Scope ==

* Proposal owners: Patch the openvpn-server@.service unit file which
adds the --cipher and --ncp-ciphers options.

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

* Release engineering: [4] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://sweet32.info/
[2] https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf
[3] 
https://www.privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation-summary-report/
[4] https://pagure.io/releng/issue/6908

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

F27 Self Contained Change: Authselect: new tool to replace authconfig

[Jaroslav Reznik]

= Proposed Self Contained Change: Authselect: new tool to replace authconfig =
https://fedoraproject.org/wiki/Changes/Authselect

Change owner(s):
* Pavel Březina 

Authselect is a tool to select system authentication and identity
sources from a list of supported profiles.

It is designed to be a replacement for authconfig but it takes a
different approach to configure the system. Instead of letting the
administrator build the pam stack with a tool (which may potentially
end up with a broken configuration), it would ship several tested
stacks (profiles) that solve a use-case and are well tested and
supported. At the same time, some obsolete features of authconfig
would not be supported by authselect.

This tool aims to be first shipped along and later deprecate and later
replace authconfig in a future Fedora release.

== Detailed Description ==

Authselect will allow the administrator to choose one of the supported
profiles. A profile provides description of how the resulting pam and
nsswitch configuration looks like. The tool will be packaged with a
default profile set that will be fully supported. If an administrator
has different needs they can create a custom profile and make it
accessible by authselect by dropping it in the tool directory.

The authentication and identity configuration is hardcoded within the
profile. However each profile is also allowed to contain some
conditional modules that can be either enabled or disabled to allow
the administrator to enable some optional behaviour such as password
policy or ecryptfs support.

Authselect will not configure daemons that provide the selected
identity and authentication services such as SSSD or winbind, it will
only configure pam and nsswitch. Daemons must be configured manually
or through other system tools like realmd or ipa-client-install.

The default profile set will contain the following profiles:

Local users + SSSD -- local users and remote users are handled by sssd
Local users + SSSD + Fingerprint -- same as above but also pam_fprintd
is enabled
Local users + winbind -- local users are handled by files and remote
users by winbind
Local users + winbind + Fingerprint -- same as above but also
pam_fprintd is enabled

We do not want to support nss-pam-ldapd and pam_krb5 in default
profiles since their use-cases are completely or almost completely
covered by SSSD. SSSD can be used as a complete replacement for
pam_krb5 and there are only few old and rarely used maps for LDAP that
remain unimplemented within SSSD such as hosts and aliases. These maps
will be added in a future SSSD version.

== Scope ==
* Proposal owners: implement the change
* Other developers: N/A (not a System Wide Change)
* Release engineering: [1] (a check of an impact with Release
Engineering is needed)
* 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)

[1] https://pagure.io/releng/issue/6907

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

Re: Schedule for today's FESCo Meeting (2017-07-14)

[Jaroslav Reznik]

On Fri, Jul 14, 2017 at 3:36 PM, Justin Forbes  wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Friday at 16: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 '2017-07-14 16:00 UTC'
>
>
> Links to all issues below can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> There is no new business scheduled at this time.

Hi,
I created quite a few F27 change proposals tickets, could you please
add it to the agenda? Unfortunately I'm not able to tag it with
"meeting" tag (I don't have sufficient permission).

See https://fedoraproject.org/wiki/Category:ChangeReadyForFesco

Thanks,
Jaroslav

>
>
> = 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



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Improved Bay- and Cherry-Trail device support

[Jaroslav Reznik]

= Proposed Self Contained Change: mproved Bay- and Cherry-Trail device support =
https://fedoraproject.org/wiki/Changes/Improved_Bay_Cherry_Trail_Support

Change owner(s):
* Hans de Goede 

Improve support for hardware using Intel Bay Trail and Cherry Trail SoCs.

== Detailed Description ==
There are many affordable x86 laptops / tablets using Intel Bay Trail
and Cherry Trail SoCs this change is about improving support for these
SoCs and the peripherals typically found on devices with these SoCs.
Examples of improvements in progress are fixing battery monitoring,
touchscreen, audio and accelerometers (sometimes) not working.

== Scope ==

* Proposal owners:
Most of the work on this is kernel work and most of this is being done upstream
The Fedora kernel package needs to have the right drivers enabled as
well as some patches backported
Some small userspace changes like adding new entries to hwdb for
accelerometer orientation

* Other developers: The non-upstream kernel and hwdb changes need to
be coordinated with their resp. package owners

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://pagure.io/releng/issue/6881

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: No More i686 Kernels

[Jaroslav Reznik]

= Proposed Self Contained Change: No More i686 Kernels =
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

Change owner(s):
* Justin Forbes 

Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.

== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing, and
issues frequently appear upstream. These tend to go unnoticed for long
periods of time. When issues are found, it is often a long time before
they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel. With this proposal, the i686
kernel will no longer be built. A kernel headers package will still
exist, and all 32bit packages should continue to build as normal. The
main difference is there would no longer be bootable 32bit images.

== Scope ==

* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.

* Other developers: NA

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* 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)

[1] https://pagure.io/releng/issues/6894

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Packaging Rust applications/libraries

[Jaroslav Reznik]

= Proposed Self Contained Change: Packaging Rust applications/libraries =
https://fedoraproject.org/wiki/Changes/Packaging_Rust_applications_and_libraries

Change owner(s):
* Igor Gnatenko  (on behalf of Rust SIG)

Add required tools/instructions for packaging applications/libraries
written in Rust. Rust is a systems programming language that runs
blazingly fast, prevents segfaults, and guarantees thread safety.

== Detailed Description ==

During initial research of SIG about packaging we identified that
inability to specify version range dependencies (1.0 <= foo < 2.0) in
RPM is main blocker. This problem hits almost every other language
ecosystem (esp. NodeJS), but it is not very noticable due to having
not more than 2 versions. While packaging some applications we
discovered need of having 3 or more versions of same crate.

The most of the work already has been done and users can consume
applications without needing to do anything from Rust/Playground COPR
repository [1].

== Scope ==

* Proposal owners: Create tool for automatic creation of rpm-spec-file
from crate on crates.io, create RPM macro for easy packaging, write
packaging guidelines.

* Other developers: RPM developers to add support for expressing
version range dependencies.

* Release engineering: #6889 (a check of an impact with Release
Engineering is needed)

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

* Policies and guidelines: Packaging Guidelines needs to be written
for packaging Rust applications/libraries.

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

[1] https://copr.fedorainfracloud.org/coprs/g/rust/playground/
[2] https://pagure.io/releng/issue/6889

Thanks,
Jaroslav
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: Unified database for DNF

[Jaroslav Reznik]

= Proposed Self Contained Change: Unified database for DNF =
https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF

Change owner(s):
* Eduard Čuba 
* Igor Gnatenko 

Replacing obsoleted YUM/DNF databases (yumdb, historydb, groups.json)
with new unified sqlite database adapted to the current needs of DNF.

== Detailed Description ==
Using single unified database with shared interface enhances data
integrity, safety and performance of package managers in Fedora.
Database is easily expandable for new features (Modularity support in
DNF will use SWDB).

== Scope ==

* Proposal owners: Port DNF to SWDB (patches has been already sent),
Port PackageKit to SWDB

* Other developers: PackageKit developers should review proposed
changes in libdnf for logging PackageKit transactions into SWDB
instead of yumdb. In addition PackageKit developers should consider
using SWDB for reading transaction data instead of using its own
backend.

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables: Change affects whole distro rather than some derivable

* Policies and guidelines: Nothing is required

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

[1] https://pagure.io/releng/issue/6886
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Drop 256term.sh

[Jaroslav Reznik]

= System Wide Change: Drop 256term.sh =
https://fedoraproject.org/wiki/Changes/Drop_256term.sh

Change owner(s):
* Zbigniew Jędrzejewski-Szmek 

Do not install /etc/profile.d/256term.sh and /etc/profile.d/256term.csh.

== Detailed Description ==
Currently Fedora installs some scripts to be executed every time a
shell is started which perform some heuristics to set $TERM based on
the terminal emulator being used. This is a work-around and it's
better to for the terminal emulator to set $TERM properly on its own.
Various terminal emulators have been updated to do that.
/etc/profile.d/256term.sh and /etc/profile.d/256term.csh will not be
installed anymore and the $TERM variable set by the terminal emulator
will be used.

[The change is trivial in and of itself. I'm making this a system wide
change, and a change at all, only because those scripts take part in
every shell startup, so it's possible they will have some unforeseen
impact or require adjustments in other components. If FESCo or
Wrangler think this does need a change page, I'm ready to drop it.]

== Scope ==
* Proposal owners: do the change in initscripts package, work with
other developers to fix any identified issues.

* Other developers: fix any identified issues

* Release engineering: [1]

* List of deliverables: N/A

* Policies and guidelines: N/A

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

[1] https://pagure.io/releng/issue/6885

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Switch OpenLDAP from NSS to OpenSSL

[Jaroslav Reznik]

= System Wide Change: Switch OpenLDAP from NSS to OpenSSL =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithOpenSSL

Change owner(s):
* Matus Honek 

Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for
cypto. OpenLDAP is going to be compiled with OpenSSL, instead.

== Detailed Description ==
OpenLDAP in Fedora is has been compiled with NSS for crypto for
several years now. Support layer for NSS was added back in 2008 but
the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons
for keeping OpenLDAP compiled with NSS was to make it work with some
other packages (esp. 389DS) seamlessly. Fixing and keeping downstream
patches has become a burden, thus it was decided to switch to OpenSSL,
instead.

For more detailed description, check out Change page.

== Scope ==
* Proposal owners: write the Interception code.

* Other developers: ensure usage of OpenSSL-like TLS configuration
based on the Schedule.

* Release engineering: [1]

* List of deliverables: Not affected

* Policies and guidelines: none.

* Trademark approval: none.

[1] https://pagure.io/releng/issue/6891

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Reduce Initial Setup Redundancy

[Jaroslav Reznik]

= System Wide Change: Reduce Initial Setup Redundancy =
https://fedoraproject.org/wiki/Changes/ReduceInitialSetupRedundancy

Change owner(s):
* Michael Catanzaro 

Currently there is a high level of redundancy between the Anaconda
installer and gnome-initial-setup. This change aims to eliminate these
redundancies and streamline the initial user experience in Fedora
Workstation.

== Detailed Description ==
Firstly, please note that the effects of this change will be
restricted to Fedora Workstation. We do not propose any changes that
affect alternative Fedora installers (e.g. Calamares) or initial setup
tools (e.g. the initial-setup package, not to be confused with
gnome-initial-setup).

A few years ago, Fedora Workstation developers discussed with Anaconda
developers the redundancy between many Anaconda settings and
gnome-initial-setup. The Anaconda developers responded by added a
configuration file mechanism, /etc/sysconfig/anaconda, which can be
used to suppress Anaconda spokes if written before Anaconda runs. This
file is also written by Anaconda to tell the initial-setup tool which
Anaconda spokes the user has visited, so that the initial-setup tool
can suppress specific spokes. Although this functionality has existed
for some time now, the Workstation developers until now failed to
follow up and begin using it. We now intend to make use of this
functionality to suppress Anaconda spokes that are redundant with
gnome-initial-setup. Meanwhile, our friends at Endless OS have added a
similar configuration file for gnome-initial-setup that allows us to
suppress some configuration that is best handled in Anaconda. Below,
we discuss what we plan to do with specific settings.

Language and Keyboard Layout

Although we do not propose it at this time, language and keyboard
layout selection should be presented to the user *before* entering the
live session, as it is currently too difficult for users to change
these settings unless they are already familiar with Fedora, and --
unless you speak English and use a US keyboard -- these settings must
be changed for the live session to be usable. Both Anaconda and
gnome-initial-setup are too late for configuring these settings. (An
exception would be for netinstalls of Fedora Workstation, where
Anaconda is the best place for this configuration.) In the meantime,
until we have a way to prompt users for these settings earlier than
Anaconda, these panels should be removed from gnome-initial-setup,
because Anaconda is clearly a better place than gnome-initial-setup
for this configuration. (This would affect gnome-initial-setup when
creating the first user account. Additional user accounts created
later would still receive these panels in gnome-initial-setup.)

Time and Date

We want to remove the time and date spoke from Anaconda, since it is
largely redundant with the timezone page in gnome-initial-setup.
However, it might be necessary to remove this page from
gnome-initial-setup instead, as previously there have been technical
concerns raised regarding the necessity of configuring the system
clock before running the installer. This choice will be based on
technical feedback from the Fedora developer community.

Network

We will remove the network configuration spoke from Anaconda.
Currently this spoke only allows configuring the system hostname, but
it places restrictions on the possible characters in the hostname that
do not match the restrictions used by Fedora Workstation. Fedora
Workstation uses systemd-hostnamed to allow "pretty" hostnames with
Unicode characters and spaces, which we expect to be displayed
properly and consistently in the user interface, but the Anaconda
configuration does not follow this pattern. Additionally, exposing the
hostname as network configuration is confusing. We may consider adding
a simpler "Computer Name" setting that allows "pretty" characters and
is not presented as a networking setting in the future, but it does
not seem necessary to prompt the user to set a hostname at all.

Note: this applies only to USB install, obviously not to netinstall.
We will need some way to differentiate between the two when writing
the Anaconda configuration file.

User Account

Currently, users have the option of creating the initial user account
in Anaconda, or not. Anaconda does not require this if the user sets a
root password. Users who do not create a user account in Anaconda are
required to create a user account later, by gnome-initial-setup. This
means we currently have two different ways of creating the first user
account in Workstation, with (potentially) two different sets of bugs.
Since Anaconda allows configuring whether the initial user is added to
the wheel group, it also means some initial users will be in wheel and
others will not. We will remove the user account creation spoke in
Anaconda. All users will create the first user account using
gnome-initial-setup, and all initial users will be added to the wheel
group. Of course, this can be

F27 System Wide Change: RPM 4.14

[Jaroslav Reznik]

= System Wide Change: RPM 4.14 =
https://fedoraproject.org/wiki/Changes/RPM-4.14

Change owner(s):
* Igor Gnatenko 
* Florian Festi 
* Panu Matilainen 

Update RPM to the upcoming 4.14 release.

== Detailed Description ==
RPM 4.14 contains several improvements that needs to get released and
integrated in Fedora:
* Major macro engine bug fix + sanity work:
** Macro scope simplification + enforcing
** Macro arguments expanded
** Nested lua macro scoping fixes
** Improved error reporting
* Major header/package/signature rewrite:
** Unified code path for all header read/import
** Major hardening work on header parsing
** Unified code path for all header/package signature checking
** Signature checking before header imports
** Support for multiple signatures per package
** Support for configurable signature policies
* Major debuginfo rewrite (covered by two other changes and already
applied in F27)
* Signal handling rewrite:
** Custom signal handlers while rpmdb open
** Signals blocked throughout write transactions
* SSD conservation mode
* Improved support for reproducible builds
* RPMCALLBACK_ELEM_PROGRESS now carries index of header
* Support for OpenSSL as a one of crypto libraries used for
digests/signatures (already part of F27)
* Support for rich dependencies coming out from dependency generators
* %include can contain paths with whitespaces
* Dependency generator for pkg-config files doesn't check dependencies
in .pc recursively, but rather print top-level ones (if pkgconf is
used)
* Header digests use SHA256 by default
* Improvements in Python dependency generator
* Improvements and stabilization of "ndb"
* Support for "with" rich-operator:
** Specifying version range dependencies
** Specifying packages which provide special ability

== Scope ==
* Proposal owners:
Rebase RPM

* Other developers:
Test new release, report issues and bugs, fix bugs in packaging (if it
is not bug in RPM, should be detected during Mass Rebuild)

* Release engineering: [1] (a check of an impact with Release
Engineering is needed)

* List of deliverables:
Change affects whole distribution rather than deliverables

* Policies and guidelines:
FPC should look (and possibly approve) "with" rich dependency in
Packaging Guidelines

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

[1] https://pagure.io/releng/issue/6875

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 26 status is GO, release on July 11, 2017

[Jaroslav Reznik]

The Fedora 26 Final 1.5 compose [1] is considered as GOLD and is going
to be shipped live on Tuesday, July 11th, 2017.

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

I'd like to thank everyone for the hard work on this release and great job Jan!

[1] https://kojipkgs.fedoraproject.org/compose/26/Fedora-26-20170705.0/compose/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.log.html

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: NSS signtool deprecation

[Jaroslav Reznik]

= System Wide Change: NSS signtool deprecation =
https://fedoraproject.org/wiki/Changes/NSSSigntoolDeprecation

Change owner(s):
* Kai Engert 

Deprecate the NSS tool named signtool, currently shipped as part of
the nss-tools package, and available in the default search path at
/usr/bin/signtool. Move it to
/usr/lib*/nss/unsupported-tools/signtool.

== Detailed Description ==
The NSS signtool is hardcoded to use SHA1 for signatures, however,
SHA1 is no longer considered secure. Because it seems difficult to
change the signtool default to make use of a more secure hash
algorithm in a backwards and forwards compatible way, and because
signtool might no longer be required for common uses, the suggestion
is to deprecate it.

See also [1] and [2]

== Scope ==
* Proposal owners:

The work required to implement this change is a simple packaging change.

* Other developers:

Users who used signtool for signing Jar/Zip/etc. files must use a
different tool. A possible alternative is the jarsigner tool, which is
shipped as part of the java-*-openjdk-devel package.

* Release engineering: [1]

* List of deliverables:
N/A

* Policies and guidelines:
N/A, no changes should be necessary.

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

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1345528
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1444136
[3] https://pagure.io/releng/issue/6882

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: NSS Default File Format SQL

[Jaroslav Reznik]

= System Wide Change: NSS Default File Format SQL =
https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql

Change owner(s):
* Kai Engert 

Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.

== Detailed Description ==

Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).

Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the
storage.

Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".

As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be
recovered.

By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.

The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.

== Scope ==

* Proposal owners:

A small downstream patch needs to be applied to the NSS library
package, which changes the library default.

* Other developers:

It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.

* Release engineering: [1]

No help should be necessary. No mass rebuild necessary.

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] https://pagure.io/releng/issue/6883

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: Graphical Applications as Flatpaks

[Jaroslav Reznik]

= System Wide Change: Graphical Applications as Flatpaks =
https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Flatpaks

Change owner(s):
* Owen Taylor 

This change is to enable package maintainers to build Flatpaks of
their applications and make those Flatpaks available for installation.

== Detailed Description ==

See Workstation/Flatpaks [1] for the full development plan.

The goal of this change is make Flatpaks available as a distribution
mechanism for software packaged in Fedora.

Multiple Flatpaks on the system can share a runtime of common
libraries. There will be a single Fedora runtime maintained on the
same schedule as the Platform module for Fedora. It will be be defined
as a module that includes libraries that are commonly used for
graphical applications. Some of these will inherit from the Platform
module.

Applications then bundle the code for the application itself and for
additional libraries they depend on beyond the base runtime. Each
application has its own module in which the relevant RPMs are rebuilt
with a special RPM macros (in the flatpak-rpm-macros package) to
relocate the application and bundled libraries into the /app prefix.
(This is necessary, because inside an executing Flatpak, the
application is mounted at /app, and the runtime at /usr)

The packages are then composed into Flatpaks by the layered image
service, sharing as much of the workflow and code as possible with
containers. While the native delivery mechanism for Flatpaks is as an
ostree repository, they can also be distributed as OCI images, and our
goal is to use this format during the build process, and to distribute
them to users via registry.fedoraproject.com.

Automation of rebuilds and integration with Bodhi will also be needed
to make sure that security and bug-fix updates to packages end up
being distributed to users. This part is least specified at the
current time, and full automation may not be achievable for Fedora 27.
If the above plan is followed, most of this work is shared with work
needed for modularity in general and for server-side containers.

== Scope ==
* Proposal owners: (f27)
** Create and maintain a flatpak-runtime module
** Provide tools for application authors to use to create module
descriptions for their flatpaks
** Provide patches for the container build pipeline (atomic reactor
and friends) to build flatpaks as well as containers
** Create some way to get summary information for all flatpaks on
registry.fedoraproject.org; this might be a patch to the codebase, a
look-aside file, or a separate service.
** Modify flatpak and gnome-software so that flatpaks can be installed
from registry.fedoraproject.org.

* Proposal owners: (f28)
** Provide a "SDK" profile of the flatpak-runtime module to create a
Flatpak SDK for third-party non-RPM builds against the SDK using
flatpak-builder

* Other developers: (f27)
** Provide exports of built modules as repositories (the "On Demand
Compose Service")
** Provide some reasonably self-service way for packagers to create
modules without a lot of overhead. (Does it make sense to allow
''application modules'' where when a package corresponds one-to-one to
a module to allow the modulemd to live in dist-git next to the spec
file?)
** Allow Fedora packagers to submit module builds
** Allow uploading OCI images to registry.fedoraproject.org Upstream
pull request [2]
** Make sure that Bodhi updates can be submitted for Flatpaks/OCI
Images in the same way as for Docker containers (no significant code
changes are expected beyond the current work to enable multiple types
of Bodhi updates.)

* Other developers: (f28)
** Create a unified workflow for package and container/flatpak updates
(detailed plan to be developed, something like:)
*** updates submitted to bodhi for a package should trigger automatic
module and container/flatpak builds
*** Pushing a package to stable should push the updated flatpaks/containers
*** the Bodhi user interface should show modules/containers that
include a package and their status

* Release engineering: [3] (a check of an impact with Release
Engineering is needed)
** List of deliverables: Most likely, runtime and applications would
not be part of the deliverables list. However, we will need to
consider the quality of the runtime and applications as part of the
overall quality of release - if some common application did not run on
upgrade that would seriously affect users. This should, as much as
possible, be addressed through continuous automated testing.

* Policies and guidelines: The people working on this change will need
to work closely in the development of module guidelines, and make sure
that Flatpak specifics are documented as well (for example,
documenting the creation of a 'flatpak.json' with permissions and
other metadata for the Flatpak). It's possible some changes will be
needed to the packaging guidelines to make sure that all relevant
packages relocate to /app properly, but it's expected that most
packa

F27 System Wide Change: The GNU C Library version 2.26

[Jaroslav Reznik]

= System Wide Change: The GNU C Library version 2.26 =
https://fedoraproject.org/wiki/Changes/GLIBC226

Change owner(s):
* Carlos O'Donell 

Switch glibc in Fedora 27 to glibc version 2.26.

== Detailed Description ==
The GNU C Library version 2.26 will be released at the beginning of
August 2017; we have started closely tracking the glibc 2.26
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 27 will branch after the
GLIBC 2.26 upstream release. However, the mass rebuild schedule means
Fedora 27 will mass rebuild just after GLIBC 2.26 upstream freezes ABI
for release, so careful attention must be paid to any last minute ABI
changes.

== Scope ==
* Proposal owners: Update glibc to 2.26 from tested upstream release.

* Other developers: Developers need to ensure that rawhide is stable
and ready for the Fedora 27 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: [1] All Fedora releases must be released using
a released version of glibc. The Fedora glibc 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
glibc 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. The GNU C Library (glibc) does not require a mass
rebuild for this release.

* List of deliverables: all

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

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

[1] https://pagure.io/releng/issue/6890

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 Self Contained Change: VirtualBox Guest Integration

[Jaroslav Reznik]

= Proposed Self Contained Change: VirtualBox Guest Integration =
https://fedoraproject.org/wiki/Changes/VirtualBox_Guest_Integration

Change owner(s):
* Hans de Goede 

VirtualBox is popular, easy to use virtual-machine software. The
purpose of this change is to ship the VirtualBox guest-drivers and
-tools by default in the Fedora workstation product.

== Detailed Description ==
VirtualBox runs on Windows. MacOS and Linux and is used by many users
to try it Linux for the first time. As such it is important for Fedora
to work well in VirtualBox virtual-machines. Like other
virtual-machines VirtualBox virtual-machines can offer an enhanced
user-experience when some VirtualBox specific guest-drivers and
guest-tools are installed. This change is about adding the
guest-drivers to the Fedora kernel package, packaging the
userspace-tools (VirtualBox Guest Additions) and adding the VirtualBox
Guest Additions package to the default package list for the
Workstation product.

== Scope ==
* Proposal owners:

** Adding the VirtualBox guest drivers to the kernel package. To make
this happen work is underway to clean them up and submit them
upstream.
** Package VirtualBox Guest Additions userspace parts
** Add VirtualBox Guest Additions package to the default package list
for the Workstation product

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

* Release engineering: [1]

* 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)

[1] https://pagure.io/releng/issue/6880

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F27 System Wide Change: 32 bit UEFI Support

[Jaroslav Reznik]

= System Wide Change: 32 bit UEFI Support =
https://fedoraproject.org/wiki/Changes/32BitUefiSupport

Change owner(s):
Peter Jones 

Some x86 systems ship with a 64 bit CPU, but 32 bit UEFI firmware. It
is possible to use a 32 bit UEFI grub build to boot a 64 bit kernel
and distribution on these systems. So far this setup has not been
supported in Fedora. This feature is about adding support for
installing and booting Fedora on this hardware.

== Detailed Description ==
To add support for booting Fedora x86_64 on x86 systems with 32 bit
UEFI firmware a number of (small) changes to grub, various EFI related
userspace tools and anaconda are necessary. See Scope for more
details.

== Scope ==
* Proposal owners:
** The x86_64 grub2 packages will need to include an extra grub build,
next to the current classic BIOS and 64 bit UEFI build a new 32 bit
UEFI build will be added to the x86_64 packages.
** This new grub will need to be added to the various x86_64 boot media
** A few EFI userspace utilities need to be updated to work with 32 bit x86 UEFI
** The installer (anaconda) needs some changes to the bootloader
installation code to install the 32 bit UEFI grub binary

* Other developers:

No changes are necessary outside of the affected packages

* Release engineering: [1]
** List of deliverables:
This feature should be enabled on all non cloud/container x86_64 images

* Policies and guidelines: N/A (not needed for this Change)

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

[1] https://pagure.io/releng/issue/6879

Thanks,
Jaroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Change Checkpoint: Proposal submission deadline (System Wide Changes) on Fedora 27 is today

[Jaroslav Reznik]

Hi everyone!

Today (2017-07-04) is the submission deadline for System Wide Changes
of Fedora 27 [1]. Please schedule your upcoming System Wide Changes
for the next (Fedora 28) release.

Self Contained Changes proposals submission deadline is on 2017-07-25
with changes completion (testable state) in the following week
(2017-08-01).

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

Thanks,
Jaroslav

(And happy July 4th!)
-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Unresponsive maintainer: rnovacek

[Jaroslav Reznik]

On Sun, Jan 15, 2017 at 7:16 PM, Kevin Kofler  wrote:
> Hi,
>
> has Radek Nováček left Red Hat? The contact information he has everywhere:
> https://fedoraproject.org/wiki/User:Rnovacek
> points to rnova...@redhat.com, but attempts to write there bounce, with:
> 554 5.7.1 : Recipient address rejected: Access denied
>
> Does anybody know how to contact Radek? Is he still interested in
> maintaining his packages or should they be orphaned?

Yes,
Radek left Red Hat but I'll contact him and I'll ask him if he's still
interested in his packages.

Jaroslav

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



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: Fedora 23 End Of Life on 2016-Dec-20

[Jaroslav Reznik]

Also I have historical data -
http://borntobeopen.blogspot.cz/2014/02/end-of-not-my-life.html till
Fedora 20 (not in this blog post, I can share it) before EOL
resolution was established as I was running the script.

Jaroslav

On Mon, Nov 28, 2016 at 4:46 PM, Matthew Miller
 wrote:
> On Mon, Nov 28, 2016 at 08:57:45AM -0500, Josh Boyer wrote:
>> >> Fedora 23 support is going to be EOL on Tuesday, December 20th, 2016.
>> >> At this day we are going to close all the Fedora 23 bugs which will
>> >> remain open [1].
>> > I'd love to see some statistics on number of bugs closed as EOL (vs
>> > other resolutions) per release (since we started using the EOL
>> > resolution).
>> That should be something anyone with bugzilla access can gather
>
> Yes, and I'll do it if no one else does. :)
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Jaroslav Reznik]

On Wed, Oct 26, 2016 at 12:23 PM, Pavel Raiskup  wrote:
> On Tuesday, October 25, 2016 7:37:32 PM CEST Kevin Fenzi wrote:
>> > 3. AFAIK Fedora has no means by which it can participate in embargoed
>> > updates.  For this to work, I think there ought to be private git
>> > branches, a way to get Koji to make a private build from a private git
>> > branch, and a way to get private karma on a private update.  Then,
>> > when an embargo is lifted, the packager could merge the private branch
>> > in, the various infrastructure bits could notice that the very same
>> > git commit is now public and permit all of the private builds,
>> > updates, and karma to become public and allow an immediate push to
>> > updates.
>>
>> Yep. Thats a gigantic pile of work there for sure.
>
> That's too vague statement, really.  Can you make a better estimation?

We had this discussion in the past and the result from the Board was
that Board won't block hidden private builds (ticket #144, not sure
it's publicly accessible). That time it was me who created the ticket
on behalf of OpenJDK folks. Of course if someone implements it and we
don't have Board but Council and Council can have different opinion on
this. I was told there was some support for private builds in the past
in our tools but it was removed long time ago as there was no use for
that and it complicated the codebase.

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

Re: Bind update (CVE-2016-2776)?

[Jaroslav Reznik]

On Thu, Sep 29, 2016 at 10:36 AM, Igor Gnatenko  wrote:
> On Thu, Sep 29, 2016 at 10:08 AM, Tomas Hozza  wrote:
>> On 09/29/2016 06:19 AM, Bojan Smojver wrote:
>>> Could someone with sufficient access please spin up an update of bind
>>> for F-24 and other flavours of Fedora. That CVE looks like a pretty
>>> serious DoS. This has already been fixed in RHEL.
>>>
>>> Thanks,
>>>
>>
>> Hi.
>>
>> I'll be pushing the updates shortly. The problem with Fedora is that we can 
>> not prepare the update in advance as for RHEL, because everything (git 
>> repos, update system, etc.) is public.
> You mean before CVE has been published? Or what's the problem with being 
> public?

In some cases, the security bugs are embargoed (so everyone has enough
time to get ready for the fix) but it doesn't go very well with how
our infrastructure works. Everything is public, so you can't commit,
you can't build and test ahead of time to get it released when embargo
is lifted. And it can take time. Some time ago OpenJDK guys contacted
me as they were hit by it and I created Board ticket for hidden
private builds. Board was ok with it (although it was difficult to
explain embargo concept ;-) [1] but with the amount of changes needed
in the infrastructure...

[1] 
http://fedoraproject.org/wiki/Meeting:Board_meeting_2012-10-03#.23144:_Hidden_Private_Builds

R.

>>
>> Regards,
>> Tomas
>> --
>> Tomas Hozza
>> Associate Manager, Software Engineering - EMEA ENG Mainstream RHEL
>>
>> PGP: 1D9F3C2D
>> UTC+2 (CEST)
>> Red Hat Inc. http://cz.redhat.com
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
PIN: REZZABBM
Red Hat, Inc.   http://www.redhat.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25 Alpha status is GO, release on August 30, 2016

[Jaroslav Reznik]

At the second Fedora 25 Alpha Go/No-Go Meeting [1][2] that just ended,
it has been agreed by QA, Release Engineering and Development to go live
with the Fedora 25 Alpha.

Fedora 25 Alpha release will be publicly available on August 30, 2016.

Meeting details can be seen here:
[1] Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-08-25/f25-alpha-go_no_go-meeting.2016-08-25-17.04.html
[2] Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-08-25/f25-alpha-go_no_go-meeting.2016-08-25-17.04.log.html

Thanks everyone!
Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

FESCo and Council elections in July 2016

[Jaroslav Reznik]

Greetings,

FESCo and Council elections are now open and we're looking for new
candidates: https://fedoraproject.org/wiki/Elections

For FESCo we have opened four seats:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

For Council we have opened one seat:
https://fedoraproject.org/wiki/Council/Nominations

The Elections schedule is as follows:
* July 05-11: Nomination period open (closes promptly at 23:59 UTC on July 11th)
* July 12-18: Campaign period. Individual blog posts, etc. encouraged.
Will also have an email interview with all answers published
simultaneously on the 19th.
* July 19-25: Voting open (closes promptly at 23:59 UTC on July 25th)
* July 26:Results announcement

Elections Questionnaire needs more questions for email/Community blog
interviews! If you have anything you would like to ask candidates to
FESCo or to Council, please add it to the wiki.
 http://fedoraproject.org/wiki/Elections/Questionnaire

Read more about the FESCo at:
http://fedoraproject.org/wiki/Development/SteeringCommittee
and about the Council at: http://fedoraproject.org/wiki/Council

Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora 25 Bugzilla Rawhide rebase

[Jaroslav Reznik]

Greetings,

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

We will be automatically changing the version for most rawhide bugs to
Fedora 25.
This will result in regular bugs reported against rawhide during the Fedora 25
development cycle being changed to version ‘25' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora 25 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 ‘25‘, 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://fedorahosted.org/fesco/ticket/1096.

Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

REMINDER: Changes submission deadline for Fedora 25 is today

[Jaroslav Reznik]

Hi everyone!
Today we have Fedora 25 Changes submission deadline [1]. No more
System Wide Changes should be submitted for this release (after 23:59
UTC today). Alpha release is currently planned on August, the 23rd
with Alpha Freeze two weeks earlier.

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

Btw. due to public holidays here, I might be a bit slower with
processing submitted changes. Don't worry, conclusive is date of the
submission.

[1] https://fedoraproject.org/wiki/Releases/25/Schedule
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 System Wide Change: Unicode 9.0 support

[Jaroslav Reznik]

= Proposed System Wide Change: Unicode 9.0 support =
https://fedoraproject.org/wiki/Changes/Unicode_9.0

Change owner(s):
* Mike Fabian 
* Pravin Satpute 
* Carlos O'Donell 

Unicode 9.0 [1] got released on 21th June 2016. Version 9.0 adds 7,500 
characters, including six new scripts and 72 new emoji characters. These new 
script provide support for languages Osage, Nepal Bhasa, Fulani and other 
African languages, The Bravanese dialect of Swahili, used in Somalia, The 
Warsh orthography for Arabic and Tangut, a major historic script of China. 

== Detailed Description ==
We are upgrading core libraries in Fedora for Unicode 9.0

* Updating Glibc localedata.
* Updating Lib ICU. (If upstream releases well in time)
* libunistring - This portable C library implements Unicode string types in 
three flavours: (UTF-8, UTF-16, UTF-32), together with functions for character 
processing (names, classifications, properties) and functions for string 
processing (iteration, formatted output, width, word breaks, line breaks, 
normalization, case folding and regular expressions).
* Unicode UCD 

== Scope ==
* Proposal owners: Work with upstream, file bugs and provide patches where 
required. 

* Other developers: This change will impact glibc, ICU and all applications 
that uses these libraries. Other Developers do not need to make any changes 
from their end, but they need to watch how their application behaves with 
improved localedata. We need proper testing to see that it does not break any 
application. 

* Release engineering: No work required from Release engineering.
  - List of deliverables: N/A 

* Policies and guidelines: No, this change does not required any updates to 
Policies or packaging guideline updates. 

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

[1] http://blog.unicode.org/2016/06/announcing-unicode-standard-version-90.html
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 System Wide Change: SSSD fast cache for local users

[Jaroslav Reznik]

= Proposed System Wide Change: SSSD fast cache for local users =
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers

Change owner(s):
* Stephen Gallagher 
* Jakub Hrozek 

Enable resolving all users through the sss NSS modules for better performance. 

== Detailed Description ==
SSSD ships with a very fast memory cache for a couple of releases now. 
However, using this cache conflicts with nscd's caching and nscd has been 
disabled by default. That degrades performance, because every user or group 
lookup must open the local files.

This change proposes leveraging a new "files" provider SSSD will ship in the 
next version in order to resolve also users from the local files. That way, 
the "sss" NSS module can be configured before the files module in 
nsswitch.conf and the system could leverage sss_nss caching for both local and 
remote users.

The upstream design of the files provider can be found at: [1]

Below is a mini-FAQ that lists the most common questions we've received so 
far:

Q: Does SSSD take over /etc/passwd and /etc/files?
A: No. SSSD just monitors them with inotify and copies the records into its 
cache.
 
Q: Does SSSD need to be running all the time now? What if it crashes?
A: SSSD needs to be running in order to benefit from this functionality. 
However, the nss_sss module is built in such a way that even if sssd is not 
running, nss_sss should fail over to nss_files pretty quickly (we'll quantify 
"pretty quickly" in a more scientific fashion soon) 

Q: Do I need to configure SSSD now?
A: No, we'll ship a default configuration. 

== Scope ==
* Proposal owners: Jakub Hrozek and Stephen Gallagher work on the design and 
coding 

* Other developers: The SSSD upstream will participate in code review of the 
change 

* Release engineering: None required 

* Policies and guidelines: None needed 

* Trademark approval: None needed 

[1] https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider

--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 System Wide Change: Ruby on Rails 5.0

[Jaroslav Reznik]

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

Change owner(s):
* Jun Aruga 
* Pavel Valena 
* Vít Ondruch 
* Ruby SIG 

Ruby on Rails 5.0 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 4.2 in 
Fedora 24 to 5.0 (latest version) in Fedora 25. 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

Full list of packages needed by Rails 5.0 to generate basic application and 
list of optional packages, required by the basic Ruby on Rails application are 
availble in the Change page. 

The lists are compiled from the result of "bundle list" and "Gemfile.lock" 
after both installing rails, and creating new Rails app.

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

* Release engineering: Not needed. 

* Policies and guidelines: Not needed 

* Trademark approval: N/A (not needed for this Change) 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: HTCondor 8.6

[Jaroslav Reznik]

= Proposed Self Contained Change: HTCondor 8.6 =
https://fedoraproject.org/wiki/Changes/HTCondor86

Change owner(s):
* Ben Cotton 

Upgrade the condor-* packages to the latest stable release series (8.6), due 
to be released near the end of the summer. HTCondor [1] is a job scheduler and 
resource manager for high-throughput computing. 

== Detailed Description ==
Package the HTCondor 8.6 release when it is available. The 8.5 development 
series is winding down, so 8.6 should be available at the end of summer. 
Currently Fedora uses the 8.5.2 release, but since that is part of the 
development series, subsequent point releases contain not only bug fixes but 
potentially-compatibility-breaking changes. The plan here is to get Fedora 
onto the stable series, which will allow for packaging of HTCondor point 
releases within a Fedora release. 

== Scope ==
* Proposal owners: Package version 8.6 when released by upstream.

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

* Release engineering: N/A (not a System Wide Change)
  - 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) 

[1] http://research.cs.wisc.edu/htcondor/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Golang 1.7

[Jaroslav Reznik]

= Proposed Self Contained Change: Golang 1.7 =
https://fedoraproject.org/wiki/Changes/golang1.7

Change owner(s):
* Jakub Čajka 

Rebase of Golang package to upcoming version 1.7 in Fedora 25, including 
rebuild of all dependent packages. 

== Detailed Description ==
Rebase of Golang package to upcoming version 1.7 in Fedora 25. Golang 1.7 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 f25(side tag), bootstrap for 
s390x(+update golang srpm macros), help with resolving possible issues found 
during package rebuilds. 

* Other developers: fix possible issues. 

* Release engineering: Create/merge side tag.
  - List of deliverables: N/A 

* Policies and guidelines: N/A 

* Trademark approval: N/A 
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Erlang 19

[Jaroslav Reznik]

= Proposed Self Contained Change: Erlang 19 =
https://fedoraproject.org/wiki/Changes/Erlang_19

Change owner(s):
* Peter Lemenkov 
* Fedora Erlang SIG 
* Randy Barlow 
* Jeremy Cline 

== Detailed Description ==
Upgrade Erlang to version 19 which brings a lot of good stuff. Just a few 
highlights:

* A new state machine behavior - gen_statem.
* An experimental plugin to mnesia which allows using expernal storage 
solutions (leveldb, for example) - mnesia_ext.
* Cryptographic functions speedups.
* Even better dirty NIF schedulers [1].
* Experimental support for Unix Domain Sockets which opens a door for native 
Journald, systemd-notify, D-Bus implementations.

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

* We should enable so-called dirty NIF scheduler [1] which is still disabled 
currently.
* Every daemon written in Erlang has its own logging solution which doesn't 
use neither syslog nor Journald. We should start switching them to Journald.
* We should add ability to use D-Bus via erlang-dbus library.
* Further improve Erlang Packaging Guidelines [2].

== Scope ==
* Proposal owners:
** Upgrade Erlang to the latest version (19.0.1) [3].
** We must rebuild every package which requires NIF or Driver version (listed 
below in the [[#Dependencies|Dependencies]] section) against Erlang 19.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** Consider allowing EPMD implementation switching. Erlang is about choice!
** We need to fill new review request for erlang-ejournald [4]
*** We have to fill new review request for erlang-lager_journald_backend [5]
** We need to fill new review request for erlang-dbus [6]
** Add another default directory to look for Erlang *.beam files.
** Upgrade outdated packages:
*** Riak [7]
 Riak has has been retired. We have to re-add it back.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines:
** We should promote officially Erlang Packaging Guidelines [2].

[1] https://medium.com/@jlouis666/erlang-dirty-scheduler-overhead-6e1219dcc7
[2] User:Peter/Erlang_Packaging_Guidelines
[3] https://bugzilla.redhat.com/1348957
[4] https://github.com/travelping/ejournald
[5] https://github.com/travelping/lager_journald_backend
[6] https://github.com/lizenn/erlang-dbus
[7] https://apps.fedoraproject.org/packages/riak
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: Zend Framework 3

[Jaroslav Reznik]

= Proposed Self Contained Change: Zend Framework 3 =
https://fedoraproject.org/wiki/Changes/ZF3

Change owner(s):
*  Remi Collet  and PHP SIG 

== Detailed Description ==
See upstream annoucement: Zend Framework 3 Released! [1]

The Zend Framework is a huge set of ~60 components. The framework version 
defines a minimal set of components, and their minimal version.
Version 3 is recommend for PHP 7.0 [2] which is also part of Fedora 25.

Dropped package:

* php-zendframework-zend-version

Updated packages: (12 major versions)

* php-zendframework: 3.0.0
* php-zendframework-zend-code: 3.0.3
* php-zendframework-zend-crypt: 3.0.0
* php-zendframework-zend-eventmanager: 3.0.1
* php-zendframework-zend-hydrator: 2.2.1
* php-zendframework-zend-json: 3.0.0
* php-zendframework-zend-math: 3.0.0
* php-zendframework-zend-mvc: 3.0.1
* php-zendframework-zend-router: 3.0.2
* php-zendframework-zend-servicemanager: 3.1.0
* php-zendframework-zend-stdlib: 3.0.1
* php-zendframework-zend-test: 3.0.1

Updated Dependencies (4 major versions)

* php-di: 5.3.0
* php-ocramius-code-generator-utils: 0.4.0
* php-ocramius-generated-hydrator: 2.0.0
* php-ocramius-proxy-manager: 2.0.0

New packages (12)

* php-zendframework-zend-json-server: 3.0.0 
* php-zendframework-zend-mvc-console: 1.1.0
* php-zendframework-zend-mvc-form: 1.0.0
* php-zendframework-zend-mvc-i18n: 1.0.0
* php-zendframework-zend-mvc-plugins: 1.0.1
* php-zendframework-zend-mvc-plugin-fileprg 1.0.0
* php-zendframework-zend-mvc-plugin-flashmessenger: 1.0.0
* php-zendframework-zend-mvc-plugin-prg 1.0.0
* php-zendframework-zend-mvc-plugin-identity: 1.0.0
* php-zendframework-zend-servicemanager-di: 1.1.0
* php-zendframework-zend-stratigility: 1.2.1 
* php-zendframework-zend-xml2json: 3.0.0

Some additional optional components can be added later (especially the 
expressive new micro framework, another set of ~10 new components).

== Scope ==
* Proposal owners: Update packages and create new for additional components

* Other developers: Test their applications 
* Release engineering: N/A (not a System Wide Change)
 - 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) 

[1] https://framework.zend.com/blog/2016-06-28-zend-framework-3.html
[2] https://fedoraproject.org/wiki/Changes/php70
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 Self Contained Change: IBus Emoji Typing

[Jaroslav Reznik]

= Proposed Self Contained Change: IBus Emoji Typing  =
https://fedoraproject.org/wiki/Changes/IBus_Emoji_Typing

Change owner(s): 
* Takao Fujiwara 

The IBus core will provide the Emoji Unicode typing with the IBus XKB engines. 

== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we 
think the similar implementation for the Emoji typging. With IBus XKB engines, 
Emoji typing will be provided with the Emoji annotations [1] following Ctrl-
Shift-e. 

== Scope ==
* Proposal owners:
 - IBus core provide the dictionary of the Emoji typing.
 - IBus XKB engines load the Emoji dictionary. 

* Other developers: N/A 

* Release engineering: N/A
 - List of deliverables: N/A 

* Policies and guidelines: N/A 

* Trademark approval: N/A 

[1] http://unicode.org/emoji/charts/index.html#col-annotations
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F25 System Wide Change: Automatic Provides for Python RPM Packages

[Jaroslav Reznik]

On Thu, Jun 30, 2016 at 2:20 PM, Jaroslav Reznik  wrote:
> = Proposed System Wide Change: Automatic Provides for Python RPM Packages =
> https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages
>
> Change owner(s):
> * Tomas Orsava <https://fedoraproject.org/wiki/User:Torsava>
> * Miro Hroncok <https://fedoraproject.org/wiki/User:Churchyard>
> * Email: python-ma...@redhat.com
>
> Upon building Python packages containing packaging metadata, RPM will
> automatically detect the standardized name of the software (i.e. dist name,
> name on PyPI) in the canonical format [1] and create a virtual Provides tag
> with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python
> version. RPM may also detect dependencies of the software from the metadata
> and automatically require them using the same syntax.
>
> == Detailed Description ==
> If during the building of a Python package RPM encounters .egg-info, .egg-link
> or .dist-info files (provided in Python Wheels and Eggs), it will read the
> standardized name of the software (i.e. dist name, name on PyPI) in the
> canonical format and create a virtual Provides tag with the value
> pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that
> the canonical format can differ slightly from the name displayed, for example,
> on PyPI.[1]
>
> RPM will also detect dependencies of the software from the aforementioned
> metadata files and automatically require them using the format
> pythonX.Ydist(). However, because these files don't always contain the full
> list of requirements (which are either in setup.py or requirements.txt), the
> dependency generator will not be conclusive.
>
> All Python packages will need to be rebuilt so that the virtual Provides tags
> are generated and can be used by users, scripts and the requires generator.
>
> == Scope ==
> * Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for
> Python
>
> * Maintainers of the RPM package: Backport the functionality from upsteram to
> Fedora. — Already done thanks to Florian Festi [2]
>
> * Release engineering: Targeted rebuild of Python packages. Ticket [3].
>
> * List of deliverables: All Fedora deliverables will be affected, but only in
> a very minor way that in no way jeopardizes their delivery.
>
> * Policies and guidelines: Fedora Packaging Guidelines for Python need to be
> updated after the implementation so users know how to take advantage of the
> change.
>
> * Trademark approval: Not needed for this Change
>
> [1] https://fedoraproject.org/wiki/Changes/
> Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0

And two missing links :)

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1340885
[3] https://fedorahosted.org/rel-eng/ticket/6432

Jaroslav
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

F25 System Wide Change: Automatic Provides for Python RPM Packages

[Jaroslav Reznik]

= Proposed System Wide Change: Automatic Provides for Python RPM Packages =
https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages

Change owner(s):
* Tomas Orsava 
* Miro Hroncok 
* Email: python-ma...@redhat.com

Upon building Python packages containing packaging metadata, RPM will 
automatically detect the standardized name of the software (i.e. dist name, 
name on PyPI) in the canonical format [1] and create a virtual Provides tag 
with the value pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python 
version. RPM may also detect dependencies of the software from the metadata 
and automatically require them using the same syntax. 

== Detailed Description ==
If during the building of a Python package RPM encounters .egg-info, .egg-link 
or .dist-info files (provided in Python Wheels and Eggs), it will read the 
standardized name of the software (i.e. dist name, name on PyPI) in the 
canonical format and create a virtual Provides tag with the value 
pythonX.Ydist(CANONICAL_NAME), where X.Y is the used Python version. Note that 
the canonical format can differ slightly from the name displayed, for example, 
on PyPI.[1]

RPM will also detect dependencies of the software from the aforementioned 
metadata files and automatically require them using the format 
pythonX.Ydist(). However, because these files don't always contain the full 
list of requirements (which are either in setup.py or requirements.txt), the 
dependency generator will not be conclusive.

All Python packages will need to be rebuilt so that the virtual Provides tags 
are generated and can be used by users, scripts and the requires generator. 

== Scope ==
* Proposal owners: Prepare a draft for the Fedora Packaging Guidelines for 
Python

* Maintainers of the RPM package: Backport the functionality from upsteram to 
Fedora. — Already done thanks to Florian Festi [2] 

* Release engineering: Targeted rebuild of Python packages. Ticket [3].

* List of deliverables: All Fedora deliverables will be affected, but only in 
a very minor way that in no way jeopardizes their delivery.

* Policies and guidelines: Fedora Packaging Guidelines for Python need to be 
updated after the implementation so users know how to take advantage of the 
change.

* Trademark approval: Not needed for this Change

[1] https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages#cite_note-canonical-0
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

REMINDER: Submission deadline for System Wide Changes of Fedora 25 next Tuesday!

[Jaroslav Reznik]

Hi everyone!

The submission deadline for System Wide Changes of Fedora 25 [1] is
coming pretty soon - just in one week from today on July 5th. Alpha release of
Fedora 25 is planned on August 23rd with Change Checkpoint: Completion
deadline on July 26th (that means changes are testable)

Please, submit your System Wide Changes by this deadline. As the
deadline applies for System Wide Changes only, it is always good to
have most of Self Contained Changes proposed as well.

In case you'll need any help with your Change proposals, feel free to
contact me. I'm covering for Jan Kurik during his holidays.

Thanks
Jaroslav

[1] https://fedoraproject.org/wiki/Releases/25/Schedule
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel-annou...@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: No mass rebuild in Fedora 25

[Jaroslav Reznik]

On Mon, May 2, 2016 at 3:12 PM, Ralf Corsepius  wrote:

> On 05/02/2016 02:16 PM, Jan Kurik wrote:
>
> The reason for not having mass rebuild during F25 development cycle is
>> very tight schedule for F25 and we would like to avoid slips in F25 as
>> much as possible. That is the main motivation here.
>>
> In other words sacrificing quality for marketing reasons - Utterly poor :(
>

Well, it's not that easy to schedule Fedora release as you have to avoid
real life conflicts - especially autumn release is pretty packed.
Thanksgivings in the US, Christmas holidays etc. and hitting these dates
actually may affect quality more than anything else. You're under pressure
to release but right folks might not available... Releasing right after
Christmas is also pretty hard to achieve and then you put the same pressure
on spring release and you have to cut again... I did it and even I always
tried to be more flexible over strict time based schedules, these were real
red flags what to avoid.

Jaroslav


>
> Ralf
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
PIN: REZZABBM
Red Hat, Inc.   http://www.redhat.com/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Base] Base Design WG agenda meeting September, 7th 2015 14:15 UTC on #fedora-meeting-2

[Jaroslav Reznik]

On Mon, Sep 7, 2015 at 3:04 PM, Harald Hoyer  wrote:
> Agenda:
>
> - Fedora.Base - RHEL.Base - Flock recap  (continued)
> - Ring 1 vs Ring 0  (continued)
> - define the minimal install (continued)
> - define the docker base image (continued)
> - minimal disk image for importing into libvirt (continued)
> - generic installer? (continued)
> - Open Floor

Hi Harald,
there's Labor Day in the US and I can see a lot of meetings canceled
today. So I'm not sure how many folks will join today (and maybe we
have people who prefers to spend Labor Day defining future Fedora ;-).

Jaroslav

> Please add items by replying to this mail.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct



-- 
--
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 645
Mobile: +420 602 797 774
PIN: REZZABBM
Red Hat, Inc.   http://www.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2015-07-29)

[Jaroslav Reznik]

- Original Message -
> Following is the list of topics that will be discussed in the FESCo
> meeting tomorrow at 18:00UTC (1:00pm EST) in #fedora-meeting on
> irc.freenode.net.
> 
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
> 
> = Followups =
> 
> #topic ticket #1427   List of release blocking deliverables
> .fesco 1427
> 
> #topic ticket #1455   F23 System Wide Change: Standardized Passphrase Policy
> .fesco 1455
> 
> #topic ticket #1463   upgrades for F23 and beyond
> .fesco 1463
> 
> #topic ticket #1466   non-responsive maintainer exception process for skottler
> .fesco 1466

One late addition

#topic ticket #1467 F23 Changes - Progress at Change Checkpoint: Completion 
deadline (testable)
.fesco 1467 

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FESCO Elections - June 2015 - Results

[Jaroslav Reznik]

- Original Message -
> On 29 June 2015 at 07:42, Josh Boyer  wrote:
> > On Mon, Jun 29, 2015 at 9:31 AM, Alexander Ploumistos
> >  wrote:
> >> On Mon, Jun 29, 2015 at 4:23 PM, Haïkel  wrote:
> >>>
> >>> Another possibility is that people didn't find any candidate to their
> >>> taste.
> >>> I suggest adding a None option too.
> >>> Though it won't change results, it will give us metrics to measure that.
> >>
> >>
> >> I'd say that a vote of "0" next to each name, pretty much counts as
> >> "none".
> >
> > Yes, but those results are not visible at all because of the method of
> > voting we use.  The suggestion of a None option would be a bit more
> > clear in terms of conveying that voter's opinion.
> >
> 
> We could also change the voting method. The new elections code allows
> for multiple ways to vote.
> 
> In the past the following things are usually done during elections:
> 
> 1) Various blog posts by candidates and various people that an
> election is occurring.
> 2) Emails during the election period reminding people there is an election.
> 
> If these things happened this time, I missed them completely.

One thing - I let Jan to run elections this time and I tried to help him as
much as possible but I didn't want to interfere too much with elections as
I was considering to run too (but in the end, I decided to skip this round
as I'm moving to my new responsibilities within Red Hat and it would be just
too much). You all know, how hard is to find volunteers and help them in
the beginning and I think Jan did a good job for the his first time. I was
following announcements, he even consulted some mails with me. I can see an
issue with email sent ahead and not on the opening day. But otherwise I think
elections were covered pretty well - we spammed Fedora Magazine with
interviews and almost crashed it... There were several announcements going
to the lists. To be honest, I'd expect much more from candidates. We always
encouraged them to run campaign (from the time we switched from town halls
to it)...

Unfortunately there were conflicting events that kept people busy and miss
it - Summit, FUDCon, in many places start of the season of summer vacations.

One idea I have is to send a notice to *all* eligible voters based on FAS
account directly that elections are open as it is one of the responsibilities
of having FAS account to care about who represents you. I know, some people
will complain they don't want such emails/spam but it might be better than
less people being informed and missing elections. And again - eligible voters
should vote, it's your project! (In the Czech Republic ballot papers are 
distributed to every single eligible voter, so it is precedence :).

So I'd like to say big thanks to Jan for running elections and covering it
pretty well for the first time even it wasn't perfect. It will be next time
(or you know, every time someone finds something :).

Jaroslav

> 
> --
> Stephen J Smoogen.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: virt-manager - libappindicator-gtk3 - remmina

[Jaroslav Reznik]

- Original Message -
> On 3 June 2015 at 11:28, Pavel Alexeev < pa...@hubbitus.info > wrote:
> 
> 
> 
> Hi,
> Is not it virt-manager problem or libappindicator? Shouldn't it be addressed
> there?
> 
> 
> If I remember correctly there was a time when people were discussing about
> bringing Unity in Fedora. This did not happen, and actually the library is
> pretty useless as there is no libappindicator consumer right now. I'm not
> sure it's worth investigating.

There is consumer - Plasma 5, one of two blocking desktops :).

For more info
https://lists.fedoraproject.org/pipermail/devel/2014-March/196343.html

So it would be nice to have GTK apps that still offers systray built against
it too.

For Unity, a bit OT here. Long time ago I had working Unity 2D (nice
lightweight desktop, a few lines of QML code) for Fedora but then they
merged it with GTK version it was impossible to continue. Now with switch
to QML, it might be possible again.

Jaroslav 

> 
> Regards,
> --Simone
> 
> 
> --
> You cannot discover new oceans unless you have the courage to lose sight of
> the shore (R. W. Emerson).
> 
> http://xkcd.com/229/
> http://negativo17.org/
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora 22 and missing applications

[Jaroslav Reznik]

- Original Message -
> Quite a few people are going to be installing Fedora 22 in the coming
> days, searching for things in the software center and not finding
> their esoteric GUI tool. This is because some applications still don’t
> ship AppData files, which have become compulsory in the workstation
> spin for this release. Luckily, the vast majority of applications that
> don't include AppData are not popular and most have little-to-no
> upstream activity.
>
> 
> If you want to check an application without installing F22 you can use
> this link http://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html
> -- if you fix an application I'll be regenerating that status page
> every 48 hours and shipping new a metadata release in a couple of
> weeks.

I tried to install Midnight Commander using software center, without
success and I don't see it in the matrix you sent.

Is it GUI only or is there any chance to get at least TUI apps? Some
as mc are pretty popular even in the group of GUI only users.

Jaroslav

> 
> Richard
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015

[Jaroslav Reznik]

At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering
and Development.

Fedora 22 Final will be publicly available on Tuesday, May 26, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/1Bh2pH1
Log: http://bit.ly/1HzMI5g

Thank you everyone for a great job, sleepless nights validating TCs,
RCs, fixing bugs, composing stuf and everything else needed for 
smooth releases. Amazing last three years wrangling releases for me! 

Jaroslav
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 22 Final is No-Go but second sign-off try is tomorrow

[Jaroslav Reznik]

Hi!
Today at Fedora 22 Final Go/No-Go meeting it was decided that Fedora 22
Final is No-Go. More details in meeting minutes [1].

As both bugs we accepted as blocker bugs today are already fixed and RC3
compose is requested, we will try to sign-off the final release tomorrow.
If you are willing to help with release validation, follow standard
channels for RC3 announcement. 

The next Go/No-Go meeting is on Friday, May 22 17:00 UTC #fedora-meeting-2
channel.

[1] http://bit.ly/1FFcJ2G

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Final Release Readiness Meeting :: Thursday, May 21, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Final Release Readiness Meeting.

date: 2015-05-21 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST)

This Thursday, May 21, we will meet to make sure we are coordinated
and ready for the Final release of Fedora 22 on Tuesday, May 26, 2015.
Please note that this meeting will occur on May 21 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 I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Final Go/No-Go Meeting, Thursday, May 21 @ 17:00 UTC

[Jaroslav Reznik]

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

Thursday, May 21, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"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."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Final Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/final/buglist

We don't have RC yet but seem like we're very close to it - testing
heroes will be needed to cover all required tests by this meeting.

Jaroslav

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 22 Beta status is Go, release on April 21, 2015

[Jaroslav Reznik]

At the Fedora 22 Beta Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Beta by Fedora QA, Release Engineering
and Development.

Fedora 22 Beta will be publicly available on Tuesday, April 21, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/1HxYmvU
Log: http://bit.ly/1IiY3TU

THX EVRYONE!

Jaroslav

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 22 Beta Go/No-Go Meeting #2, Thursday, April 16 @ 17:00 UTC

[Jaroslav Reznik]

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

Thursday, April 16, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"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."

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Beta Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist

Jaroslav
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Beta to slip by one week

[Jaroslav Reznik]

Today at Go/No-Go meeting it was decided to slip Fedora 22 Beta release
by one week due to unresolved blocker bug [1]. More details in meeting
minutes [2].

As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be
pushed out by one week [3].

The next Go/No-Go meeting is on Thursday, Apr 16, 17:00 UTC at
#fedora-meeting-2 channel on FreeNode.

Jaroslav

[1] http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist
[2] http://bit.ly/1NX92nq
[3] https://fedoraproject.org/wiki/Releases/22/Schedule

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Beta Release Readiness Meeting :: Thursday, April 09, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Beta Release Readiness Meeting.

date: 2015-04-09 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (3 PM EDT, 12 noon PDT, 21:00 CEST)

This Thursday, April 09, we will meet to make sure we are coordinated
and ready for the Beta release of Fedora 22 on Tuesday, April 14, 2015.
Please note that this meeting will occur on April 09 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 I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 22 Beta Go/No-Go Meeting, Thursday, April 09 @ 17:00 UTC

[Jaroslav Reznik]

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

Thursday, April 09, 2015 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST)

"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. We don't have RC yet, the list of blocker bugs
does not look so scary now but there's still quite a lot of work ahead of
us. 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 next.

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Beta Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/beta/buglist

Jaroslav

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2015-03-25)

[Jaroslav Reznik]

- Original Message -
> Following is the list of topics that will be discussed in the FESCo
> meeting Wednesday at 18: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 '2015-03-25 18:00 UTC'
> 
> 
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
> 
> = Followups =
> 
> #topic #1312 F22 System Wide Change: Replace Yum With DNF -
> http://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
> .fesco 1312
> https://fedorahosted.org/fesco/ticket/1312
> 
> #topic #1384 F23 System Wide Change: Harden all packages with
> position-independent code -
> https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-independent_code
> .fesco 1384
> https://fedorahosted.org/fesco/ticket/1384
> 
> #topic #1412 anaconda password change is causing consternation among the user
> community please review this policy decision
> .fesco 1412
> https://fedorahosted.org/fesco/ticket/1412

One more ticket: https://fedorahosted.org/fesco/ticket/1374#comment:16
Disabled repositories change as it was announced for 7+ days.

Jaroslav

> 
> = Open Floor =
> 
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
> 
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/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
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

- Original Message -
> On 03/18/2015 05:46 PM, Rahul Sundaram wrote:
> > Hi
> >
> > On Wed, Mar 18, 2015 at 12:21 PM, Mike Pinkerton  wrote:
> >
> >
> > What I don't understand is the wisdom of an official Fedora
> > "product" endorsing a copr when either the software or packaging (or
> > both) is not of sufficient quality to make it into the official
> > Fedora repo.
> >
> >
> > I don't think of it as a endorsement.
> I see them as a means of discouraging people from packaging for Fedora:
> 
> Ask yourself: "Why should I package a package properly, when I can get
> off 'cheap'?" - msuchy's rationale is along this line.
> 
> > It is making them more easily
> > discoverable but there is going to be a prompt of some sort that warns
> > them of the nature of such software and users get to choose whether they
> > are willing to accept that tradeoff for immediate access.  One might
> > choose to use say, Chromium regardless of the bundling issues for example.
> 
> There are many more ways why a package not to be eligible for Fedora
> than "bundling":
> - Illegal/patent-encumbered in the US, but legal to distribute in other
> countries.
> - Legal to distribute binaries, repackaged for "packager lazyness",
> (e.g. Java) or complexity (foreign arch binaries needed to support
> cross-toolchains).
> - Content-only packages (Videos, Audiofiles).
> - Packages with ethical/political controversial contents.
> ...
> 
> In other words, if you are really serious about this plan, you need some
> authority to continuously review the packages in such "endorsed" repos,
> technically, legally and "politically".

And that's what Council agreed on. The process is not yet set but it may
end up on Council's table.

By the way, for non-good stuff you mentioned above - it's already not
allowed to do it in Coprs - 
https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr

So for Copr, I'm in support of this proposal as it perfectly fits with
the idea of Playground repository I helped to draft. Copr is part of
Fedora project (and I even would like it more integral part as part of
Koji). For repositories outside Fedora Project, I stated on the Council
meeting, that I'd require opt-in/opt-out consent from user before even
search for such disabled repository is allowed. But it would be one
dialog with ack/nack and explanation what does it mean.

Jaroslav

> 
> 
> Ralf
> 
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

- Original Message -
> On 03/18/2015 12:55 PM, Peter Robinson wrote:
> > How are "disabled repositories" going to be approved for inclusion?
> 
> While you likely meant political meaning of "how", I would like share how it
> will be done technically.
> 
> Approximately 6 months ago Env&Stack wanted to have "Playground repository",
> which would be set of Copr repositories.
> Something guaranteed to meet legal requirements, something with sufficient
> quality. Copr already have this attribute for
> every project and admins of Copr can set/unset this flag.
> You can already enable those repositories by:
>   dnf playground enable
> if you have dnf-plugins-core. Unfortunately this set is currently empty :)
> 
> Half a year ago the blocker for Env&Stack was that Copr can not sign
> packages. Copr can do that for few weeks now and I
> notified Env&Stack so they can continue on they work on Playground
> repository.
> 
> This is IMO ideal candidate for disabled repositories with enabled metadata.

Yep, I raised it on the Council meeting and these two proposals work
pretty well together!

Jaroslav

> I am not sure how to deliver those disable repositories though. But that is
> likely for different discussion.
> 
> --
> Miroslav Suchy, RHCE, RHCDS
> Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

- Original Message -
> On Mar 17, 2015 5:18 AM, "Jan Zelený"  wrote:
> >
> > On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote:
> > > = Proposed Self Contained Change: Disabled Repositories Support =
> > > https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
> > >
> > > Change owner(s): Richard Hughes 
> > >
> > > The Software tool and PackageKit now support disabled repositories to
> help
> > > users locate software in additional repositories which are not meant to
> be
> > > enabled by default.
> > >
> > > * This Change is announced after the Change Submission Deadline as an
> > > exception to the process. May not be approved for proposed Fedora
> release. *
> > >
> > > == Detailed Description ==
> > > This feature aims to reduce the technical hurdles for users and
> developers
> > > to locate software packaged for a distribution, but which needs to be
> > > clearly identified as not officially included (or possibly sanctioned)
> by
> > > that distribution.
> > >
> > > When Software (via PackageKit) queries a repo definition that contains
> the
> > > line enabled_metadata=1, even if the repo is disabled, it will download
> > > repodata. This feature allows a user to locate software in response to a
> > > search. If the user wants to install the software, she receives a dialog
> > > with information that the repo must be enabled to satisfy the request,
> and
> > > if relevant, information about the nature of the software (for
> instance, if
> > > it is non- libre).
> > >
> > > N.B. This feature does not currently operate in Fedora, since no such
> repo
> > > definitions are currently shipped. However, the feature could be used by
> > > remixers, and in the future in Fedora in the event of a policy change.
> > >
> > > == Scope ==
> > > * Proposal owners: Include enhancements in gnome-software/PackageKit
> (done)
> > > * Other developers: N/A (not a System Wide Change)
> > > * Release engineering: N/A (not a System Wide Change)
> > > ** Note: For this feature to be used in Fedora requires an additional *-
> > > release-extra package to ship disabled repo definition
> > > * Policies and guidelines: N/A (not a System Wide Change)
> > > ** Note: For this feature to be used in Fedora requires clearer approval
> > > from FESCo and the Council
> >
> > I wonder, are there any implications for dnf in terms of being consistent
> with
> > the new behavior of Gnome Software? I realize that people using dnf have
> more
> > options than people using Gnome Software (--enablerepo for instance) but
> this
> > sounds like the beginning of the end of disabled repositories.
> >
> > Personally, I don't like the semantics of these semi-disabled repos. It
> beats
> > the purpose of disabling the repos in the first place, doesn't it? I mean
> I
> > don't get why user would specify enabled_metadata=1 when he can achieve
> almost
> > the same result with disabled=0 (the only difference I can see is one
> > additional popup dialog). Or is there something I'm missing?
> >
> > Thanks
> > Jan
> > --
> 
> As I understand it, the intent is to provide the user with the experience
> of third party software being included in Fedora, while still complying
> with the third party repository policy and communicating to the user that
> it comes from somewhere else.
> 
> As I understand it, the council stance is that each repo must be a
> self-contained piece of software, and each individual repo must have
> explicit council approval to be included,  with a mandate for furthering
> Fedora's mission and an expectation of permissive licensing.  In that
> context, I guess I'm ok with the compromise.
> 
> jreznik, what about cycling these approvals through the Change process, but
> instead of going to Fesco, the tickets go to the council?  That would allow
> a sufficient amount of community scrutiny and signal, IMO.  The Change
> template would only need to be modified slightly, probably not more than
> current interpretations do.

That's one of future goals to use Change process not only for Changes that
has to go through FESCo but WGs, for this case Council. Actually, the new
process was initially designed this way :). It will require some change in
template but it's doable and it can help coordination with other parts of
Fedora as we do for example for Release Notes.

So, count me in :).

Jaroslav

> 
> --Pete
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Change Checkpoint: 100% Code Complete Deadline in two weeks

[Jaroslav Reznik]

Hi!
This is a reminder, that Fedora 22 Change Checkpoint: 100% Code
Complete Deadline is coming in two weeks. It's important milestone
as for this release, we'd like to strictly adhere to schedule and 
contingency plan may be put into effect for Changes that miss
this deadline. As always, the list will be shared with FESCo. 

2015-03-31 Change Checkpoint: 100% Code Complete Deadline
2015-03-31 Fedora 22 Beta Freeze

Expected bug state is ON_QA - Change has to be code complete and
can be tested in the Beta release (optionally by Fedora QA).

Please make sure to update state of yours Change(s) bug(s) on time.
In case of any problems, let me know, we will try to find working
solution.

http://fedoraproject.org/wiki/Releases/22/Schedule

Expect more nagging in Change bug(s) between now and Beta Freeze ;-).

Thanks
Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Disabled Repositories Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Disabled Repositories Support =
https://fedoraproject.org/wiki/Changes/DisabledRepoSupport

Change owner(s): Richard Hughes 

The Software tool and PackageKit now support disabled repositories to help 
users locate software in additional repositories which are not meant to be 
enabled by default. 

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This feature aims to reduce the technical hurdles for users and developers to 
locate software packaged for a distribution, but which needs to be clearly 
identified as not officially included (or possibly sanctioned) by that 
distribution.

When Software (via PackageKit) queries a repo definition that contains the line 
enabled_metadata=1, even if the repo is disabled, it will download repodata. 
This feature allows a user to locate software in response to a search. If the 
user wants to install the software, she receives a dialog with information 
that the repo must be enabled to satisfy the request, and if relevant, 
information about the nature of the software (for instance, if it is non-
libre).

N.B. This feature does not currently operate in Fedora, since no such repo 
definitions are currently shipped. However, the feature could be used by 
remixers, and in the future in Fedora in the event of a policy change. 

== Scope ==
* Proposal owners: Include enhancements in gnome-software/PackageKit (done)
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires an additional *-
release-extra package to ship disabled repo definition 
* Policies and guidelines: N/A (not a System Wide Change)
** Note: For this feature to be used in Fedora requires clearer approval from 
FESCo and the Council 

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Alpha status is Go, release on March 10, 2015

[Jaroslav Reznik]

At the Fedora 22 Alpha Go/No-Go Meeting #2 that just occurred, it was
agreed to Go with the Fedora 22 Alpha by Fedora QA, Release Engineering
and Development.

Fedora 22 Alpha will be publicly available on Tuesday, March 10, 2015.

Meeting details can be seen here:
Minutes: http://bit.ly/17Y8Je5
Log: http://bit.ly/1Em9JXo

Thanks everyone! It's pretty solid Alpha release and on time :).
Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Alpha is No-Go but second sign-off try is tomorrow

[Jaroslav Reznik]

Hi!
Today at Fedora 22 Alpha Go/No-Go meeting it was decided that Fedora 22
Alpha is No-Go as no release candidate is available. More details in
meeting minutes [1].

But as we're looking pretty good and RC1 compose is undergoing right
now (estimate delivery is 3:00 UTC on Friday), we decided to try the
seconnd Go/No-Go meeting tomorrow. Earlier to give rel-eng chance to
prepare the content for mirroring.

The next Go/No-Go meeting is on Friday, Mar 06 8:30 AM CST/14:30 UTC
#fedora-meeting-2 channel.

[1] http://bit.ly/1H0LMmC
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Xfce412

[Jaroslav Reznik]

= Proposed Self Contained Change: Xfce412 =
https://fedoraproject.org/wiki/Changes/Xfce412

Change owner(s): Kevin Fenzi , Mukundan Ragavan 
, Christoph Wickert 

Update Xfce to the new 4.12 release with a number of bugfixes and improvements. 

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
Upstream Release Date: 2015-02-28

This release will have a number of bugfixes and improvements, but no radical 
changes. 

== Scope ==
* Proposal owners: Update Xfce packages. Update Xfce spin with any needed 
adjustments. 
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Alpha Release Readiness Meeting :: Thursday, March. 05, 19:00 UTC

[Jaroslav Reznik]

Fedora 22 Alpha Release Readiness Meeting.

date: 2015-03-05 place: irc.freenode.net in #fedora-meeting-2
time: 19:00 UTC (2 PM EST, 11 AM PST, 20:00 CET)

This Thursday, March 05, we will meet to make sure we are coordinated
and ready for the Alpha release of Fedora 22 on Tuesday, March 10, 2015.
Please note that this meeting will occur on March 05 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 I was asked to open this
meeting to the teams and I'll also hope this will raise awareness and more
team representatives will come to this meeting. This meeting works best
when we have representatives from all of the teams. We also have a badge!

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo meeting (2015-03-04)

[Jaroslav Reznik]

- Original Message -
> On Wed, 4 Mar 2015 07:05:09 -0500 (EST)
> Jaroslav Reznik  wrote:
> 
> > - Original Message -
> > > Following is the list of topics that will be discussed in the FESCo
> > > meeting Wednesday at 18: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 '2015-03-04 18:00 UTC'
> > > 
> > > 
> > > Links to all tickets below can be found at:
> > > https://fedorahosted.org/fesco/report/9
> > > 
> > > = Followups =
> > > 
> > > #topic #615 Strategy for services that do not have systemd native
> > > unit files .fesco 615
> > > https://fedorahosted.org/fesco/ticket/615
> > > 
> > > #topic #1412 anaconda password change is causing consternation
> > > among the user community please review this policy decision
> > > .fesco 1412
> > > https://fedorahosted.org/fesco/ticket/1412
> > 
> > Just one item to add - quick one, LxQt Self Contained change
> 
> Would it be possible also to discuss the Xfce 4.12 self contained
> change, and/or send it out for comment asap?
> 
> https://fedoraproject.org/wiki/Changes/Xfce412
> 
> FE: https://bugzilla.redhat.com/show_bug.cgi?id=1197958
> 
> We would love to get it in alpha if at all possible.

I can send the announcement and in this case of Self Contained 
Change, I think it can go straight to FESCo as an exception.

Jaroslav

> 
> kevin
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo meeting (2015-03-04)

[Jaroslav Reznik]

- Original Message -
> - Original Message -
> > Following is the list of topics that will be discussed in the FESCo
> > meeting Wednesday at 18: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 '2015-03-04 18:00 UTC'
> > 
> > 
> > Links to all tickets below can be found at:
> > https://fedorahosted.org/fesco/report/9
> > 
> > = Followups =
> > 
> > #topic #615 Strategy for services that do not have systemd native unit
> > files
> > .fesco 615
> > https://fedorahosted.org/fesco/ticket/615
> > 
> > #topic #1412 anaconda password change is causing consternation among the
> > user
> > community please review this policy decision
> > .fesco 1412
> > https://fedorahosted.org/fesco/ticket/1412
> 
> Just one item to add - quick one, LxQt Self Contained change

https://fedorahosted.org/fesco/ticket/1374#comment:12

(Sorry, I sent it by mistake before attaching the link)

For Legacy Java change, change owner decided not to send it to FESCo.

Jaroslav

> 
> > = New business =
> > 
> > #topic #1418 FESCo Decision: Revert Tomcat to version 7 for Fedora 22
> > .fesco 1418
> > https://fedorahosted.org/fesco/ticket/1418
> > 
> > = Open Floor =
> > 
> > For more complete details, please visit each individual ticket.  The
> > report of the agenda items can be found at
> > https://fedorahosted.org/fesco/report/9
> > 
> > If you would like to add something to this agenda, you can reply to
> > this e-mail, file a new ticket at https://fedorahosted.org/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.
> > 
> > - ajax
> > 
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo meeting (2015-03-04)

[Jaroslav Reznik]

- Original Message -
> Following is the list of topics that will be discussed in the FESCo
> meeting Wednesday at 18: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 '2015-03-04 18:00 UTC'
> 
> 
> Links to all tickets below can be found at:
> https://fedorahosted.org/fesco/report/9
> 
> = Followups =
> 
> #topic #615 Strategy for services that do not have systemd native unit files
> .fesco 615
> https://fedorahosted.org/fesco/ticket/615
> 
> #topic #1412 anaconda password change is causing consternation among the user
> community please review this policy decision
> .fesco 1412
> https://fedorahosted.org/fesco/ticket/1412

Just one item to add - quick one, LxQt Self Contained change


> = New business =
> 
> #topic #1418 FESCo Decision: Revert Tomcat to version 7 for Fedora 22
> .fesco 1418
> https://fedorahosted.org/fesco/ticket/1418
> 
> = Open Floor =
> 
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
> 
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/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.
> 
> - ajax
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Alpha Go/No-Go Meeting, Thursday, March 05 @ 17:00 UTC

[Jaroslav Reznik]

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

Thursday, March 05, 2015 17:00 UTC (12 noon EST, 9 AM PST, 18:00 CET)

"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. We don't have RC yet as the list of accepted
blockers is still pretty long. If you have any bug on the list, please
help us with Alpha release. If we won't be ready by Thursday, we will
use this meeting to review blockers and decide what to do.

For more details about this meeting see:
https://fedoraproject.org/wiki/Go_No_Go_Meeting

In the meantime, keep an eye on the Fedora 22 Alpha Blocker list:
http://qa.fedoraproject.org/blockerbugs/milestone/22/alpha/buglist

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Bugzilla Rawhide rebase

[Jaroslav Reznik]

Greetings,
This e-mail is intended to inform you about the upcoming Bugzilla changes 
happening March 3, 2015 (Rawhide bug rebase) and what you need to do, if 
anything.

We will be automatically changing the version for most rawhide bugs to Fedora 
22.
This will result in regular bugs reported against rawhide during the Fedora 22
development cycle being changed to version ‘22' instead of their current
assignment, ‘rawhide’.  This is to align with the branching of Fedora 22 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’ component 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 ‘22‘, 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://fedorahosted.org/fesco/ticket/1096. 

Jaroslav

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: LXQt

[Jaroslav Reznik]

= Proposed Self Contained Change: LXQt =
https://fedoraproject.org/wiki/Changes/LXQt

Change owner(s):  Helio Chissini de Castro , 
Christoph Wickert 

Package the LXQt desktop Environment for Fedora.

* This Change is announced after the Change Submission Deadline as an
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
LXQt [1] is the Qt port and the upcoming version of LXDE [2], the Lightweight 
Desktop Environment. It is the product of the merge between the LXDE-Qt and 
the Razor-qt projects: A lightweight, modular, blazing-fast and user-friendly 
desktop environment. 

== Scope ==
* Proposal owners: LXQt packages already approved and in the system.
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://lxqt.org/
[2] https://fedoraproject.org/wiki/LXDE
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Jaroslav Reznik]

= Proposed System Wide Change: Legacy implementations of the Java platform in 
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

Change owner(s): Jiri Vanek 

Currently Fedora supports one main Java runtime and Java Development Kit (JDK) 
and from time to time one future JDK as a tech preview. This change should be 
set of rules, which will enable community to maintain legacy JDKs. Please 
note, people are bugging main JDK maintainers pretty often with this, and to 
allow them to maintain legacy JDKs is a step in right direction.

* This Change is announced after the Change Submission Deadline as an 
exception to the process. May not be approved for proposed Fedora release. *

== Detailed Description ==
This is no real work proposal. The result of this proposal is set of rules, 
which will allow community maintainers to pack any legacy jdk and will be 
ensuring that this JDKs will not conflict by any other JDK and will smoothly 
integrate to system. The results are summarized here, and pledged for 
discussion until final resolution is done.

=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. 
This must remain clear'''

 option one - introducing new packages - preferred 
1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived 
as new package prviousName-legacy
 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
openjdk-legacy
 2. next main jdk do Obsolete previous one as usually
2. new package '''must''' not do any virtual provides (aka java,java-devel)... 
(protection against random pull by as dependence)
 1. it provides only itself by name
3 its priority '''must''' be kept on less digits (right now it would be 5) 
then main jdk (protection against winning in alternatives after update)
 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 
are '''mandatory'''
4. at least one of the main-jdk's members '''must''' be set as comaintainer 
(to watch the commits and save the world if necessary)
5. new  package '''should''' to follow both original jdk (ideally not change 
at all (except source updates and necessary)) and current main jdk as close as 
possibly
 1. here it requires some common sense and a lot of testing if integration 
with system is as expected
6. as it is generally not new package, the review process '''should''' be only 
formal - to know maintainer and to create cvs repo 
 1. this is quite important, otherwise the new maintainer can become really 
frustrated, and we are forcing the "dead" package over"orpahned" so the full 
review (especially in alignment with rule 5) really should not be forced.
 2. on the contrary, rules agreed here '''must''' be checked.  (even the 
number 5)
7. all depending packages '''must''' keep requiring java-headless or java (and 
BuildRequires java-devel). Requirements on any exact jdk - or even worse on 
any exact legacy jdk are forbidden and needs FESCO exception. 

This option is forcing maintainers to fight with the name x current setup of 
alternatives. However, the work should be minimal. But it makes the update 
path pretty clear and it keeps users well protected against legacy jdk.

 option two - orphaning legacy jdks and ensure update path 
1. main JDK is only orphaned when new main JDK landed
 1. it do '''not''' Obsolate previous jdk
2. other rules (2-7) are same

This is making life of legacy JDK maintainers a bit simpler. But I don't know, 
how to ensure proper "obsolete" implementation in this case.

== Scope ==
* Proposal owners: are responsible for initial setup of those guidelines. 
The FESCO, the owners and pssible legacy JDKs maintainers have to agree on 
those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
* Other developers: no developers
* Release engineering: in ideal case, no release engineer needed  
* Policies and guidelines: The proposal may split to proposal and "Legacy JDKs 
in Fedora guidelines" pages 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 22 Changes Completion deadline in one week - 2015-02-24

[Jaroslav Reznik]

Greetings!
Fedora 22 Change Checkpoint: Completion deadline (testable) is in
one week - 2015-02-24 [1] and we're getting closer to this date.

Other important milestones are scheduled for this date:
* Alpha Freeze
* Software String Freeze
* Bodhi activation point

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

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

Fedora 22 is strictly time based release and we want to adhere to the
schedule. Incomplete and non testable Changes will be reported to 
FESCo for 2015-02-25 meeting.  Contingency plan for System Wide Changes,
if planned for Alpha (or in case of serious doubts regarding Change
completion), will be activated.

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

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Migration to Zanata

[Jaroslav Reznik]

- Original Message -
> Hi Fedora developers
> 
> I have not heard yet from the maintainers of the following packages.
> Fedora Localization Project would like to have them migrated in Zanata
> asap for good kickstart of F22.
> We all are much appreciated your immediate attention.

>  system-config-bind

Let's consider this as EOL, time to kill it officially...

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

FESCo Elections results

[Jaroslav Reznik]

Greetings, all!

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

A total of 283 ballots were cast, meaning a candidate could accumulate
up to 1981 votes (283 * 7).

The results for the elections are as follows:

  # votes |  name
- +--
1427  | Kevin Fenzi
1247  | Adam Jackson
 919  | Tomas Hozza
 818  | Parag Nemade
 617  | Debarshi Ray
- +--
 540  | Alberto Ruiz
 441  | David King

Number of voters283
Number of votes 1204
Maximum of votes1981

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

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Cast your vote - FESCo elections closes today!

[Jaroslav Reznik]

Hi everyone,
this is a friendly reminder that today is the last chance to vote
in the FESCo elections - great opportunity for everyone to steer 
future Fedora's development. Voting closes promptly at 2015-02-03
23:59 UTC.

Go to https://admin.fedoraproject.org/voting/ and cast your vote!

If you're still undecided, we have two new interviews available:
* Alberto Ruiz http://bit.ly/18JS1zZ
* Adam Jackson http://bit.ly/1DsyqgK

(And it's worth reading even you already voted)

The other Fedora Magazine interviews:
* Kevin Fenzi http://bit.ly/16r7NPl
* Tomas Hozza http://bit.ly/1Cspprd
* Debarshi Ray http://bit.ly/1z7IasJ
* Parag Nemade http://bit.ly/1HRSI9T
* David King http://bit.ly/1K6ZshQ

Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: FESCo elections are open

[Jaroslav Reznik]

- Original Message -
> Stephen Gallagher wrote:
> > At the same time, until fairly recently (Kalev), the Workstation WG (and
> > formerly Desktop team) hasn't had a great deal of representation on
> > FESCo. It's good to see more faces from that side of the Fedora Project
> > running for FESCo.
> 
> As if FESCo weren't already biased enough towards GNOME… :-( Sigh!

Well, FESCo elections are open for everyone and for last few years we're
happy to have at least enough number of candidates to start elections...

Jaroslav

> Kevin Kofler
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Python 3 Migration Improvements

[Jaroslav Reznik]

= Proposed System Wide Change: Python 3 Migration Improvements =
https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements

Change owner(s): Slavek Kabrda , Matej Stuchlik 
, Miro Hroncok 

Since Changes/Python_3_as_Default was retargeted for F23 mostly due to 
uncertainty about DNF and Anaconda porting status, this change aims to reflect 
current progress of Python 3 readiness in Fedora and sum up goals for Fedora 
22. 

== Detailed Description ==
Python 3 is the next generation of Python programming language. It is 
currently mature and stable, since it has been under active development for 
more than six years - version 3.0 was released in December 2008, current 
latest stable version is 3.4.2 released in October 2014. The main reason to 
switch to Python 3 as the default implementation is that Python 2 is in 
maintenance mode, thus only bugfixes and security fixes are accepted upstream. 
Further reasons are mentioned in the Benefit to Fedora section [1].

Originally, Fedora 22 was supposed to be shipped with Python 3 as Default [2]. 
There was however rising concern about Python 3 readiness of some key 
components - mostly Anaconda and DNF. Due to this fact FESCo decided to 
retarget Python 3 as Default for Fedora 23, hence also stopping mass bug filing 
for rebuilds with Python 3 for Fedora 22. As a result, most packages in Fedora 
22 will still use Python 2 and at this state it's not desirable to pronounce 
Python 3 "the default Python".

Since a massive amount of work has been done towards Python 3 migration, it 
still makes sense to use as much of this effort for Fedora 22 as possible. See 
Scope for overview of changes proposed for Fedora 22 by this Change. 

== Scope ==
Goals of this change are:
* to switch as many packages present on Fedora Workstation LiveCD to Python 3 
(the Workstation LiveCD already ships both Python interpreters, so switching 
more packages to Python 3 won't increase size)
* to make minimal cloud image Python 2 free
* to make Fedora atomic host Python 2 free
Note: this Change intentionally doesn't talk about switching or not switching 
Anaconda and DNF to Python 3. These are left up to broader community consensus 
and don't prevent this change from happening.

There are basically two types of packages that need to undergo the conversion:
* "libraries" - Python extension modules and libraries that provide Python 
bindings - assuming that there is upstream support, these can receive python3- 
subpackage anytime without any damage to Fedora; we can then just utilize this 
subpackage when switching to Python 3 (instead of using current python- 
subpackage).
* "applications" - Packages that build with some sort of embedded Python 
support, like gdb, or Rhythmbox with its plugins. In these cases, it makes no 
sense to do a python3- subpackage, since the whole package would need to be 
duplicated (e.g. python3-gdb). These packages should be built with Python 3 in 
Fedora 22 rawhide as soon as possible.

The packages that should be rebuilt with Python 3 are:
* abrt 
* authconfig https://bugzilla.redhat.com/show_bug.cgi?id=984907
* bind https://bugzilla.redhat.com/show_bug.cgi?id=1186791
* caribou https://bugzilla.redhat.com/show_bug.cgi?id=1186792
* cloud-init https://bugzilla.redhat.com/show_bug.cgi?id=1024357
* environment-modules https://bugzilla.redhat.com/show_bug.cgi?id=1184979
* gdb https://bugzilla.redhat.com/show_bug.cgi?id=1014549
* gettext
* gnome-abrt
* heat-cfntools https://bugzilla.redhat.com/show_bug.cgi?id=1024368
* hplip
* gupnp
* nfs-utils
* pcp
* pidgin
* setroubleshoot https://bugzilla.redhat.com/show_bug.cgi?id=1125209
* sos https://bugzilla.redhat.com/show_bug.cgi?id=1014595
* telepathy-gabble
* totem

This list is provided here because the tracking bug of Python 3 as Default 
contains also packages needed for DNF and Anaconda, which are not essential to 
this effort. These BZs will be attached to a new tracker bug once it's created.

Note that Python packaging guidelines have already been [3] to prefer Python 3 
over Python 2 for newly introduced applications since Fedora 22.

== Contingency Plan ==
* Contingency mechanism: None needed. Packages that will be ready will be 
built with Python 3, the rest will be ported in next release.
* Contingency deadline: Software string freeze
* Blocks release? No

[1] 
https://fedoraproject.org/wiki/Changes/Python_3_Migration_Improvements#Benefit_to_Fedora
[2] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[3] 
https://fedoraproject.org/w/index.php?title=Packaging%3APython&diff=402016&oldid=400811
 
changed
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF replacing yum: fedup?

[Jaroslav Reznik]

- Original Message -
> On Mon, 2015-01-26 at 14:37 -0700, Chris Murphy wrote:
> > On Mon, Jan 26, 2015 at 2:36 PM, Chris Murphy <
> > li...@colorremedies.com> wrote:
> > > On Mon, Jan 26, 2015 at 2:26 PM, Adam Williamson <
> > > adamw...@fedoraproject.org> wrote:
> > > > I note the ReplaceYumWithDnf Change page:
> > > > 
> > > > https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF
> > > > 
> > > > says nothing about fedup. However, fedup uses yum:
> > > > 
> > > 
> > > Seems like fedup is only used on Fedora 21 and older to upgrade to
> > > Fedora 22. So dnf support would be needed to get Fedora 22 to
> > > fedup to Fedora 23. No?
> > 
> > I guess right after Fedora 22 branch, it would break the ability to
> > use fedup to upgrade from Fedora 22 to Rawhide...
> > 
> 
> There is in fact no strict *technical* requirement for anything to
> move from yum to dnf in F22. yum will remain in the F22 package set,
> it is not being removed.
> 
> However, the Change seems to me to have been written with the basic
> idea that yum shouldn't be installed by default any more and nothing
> that's a core part of Fedora should use it any more - for e.g., the
> Change incorporates moving anaconda to dnf, even though technically
> speaking there's no *need* for this, we could if we wanted to ship F22
> with anaconda using yum but the installed system using dnf.

This has implications on another Change - moving to Python 3. See 
Scope section - http://fedoraproject.org//wiki/Changes/Python_3_as_Default

Yum means moving both DNF and Python 3 to Fedora 23.

Jaroslav

> So given that, I wanted to clarify the status of fedup.
> 
> If F22's fedup depends on yum, then people with 'clean' dnf-only
> systems are going to get yum installed when they want to upgrade to
> F23. Of course, we could ship F22 on release day with a yum-based
> fedup then provide a dnf-based one as an update, but that seems a bit
> messy.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

FESCo elections are open

[Jaroslav Reznik]

Greetings,
FESCo elections are now open and we're looking for five new
committee members. Elections closes promptly at 23:59 UTC
on February 3rd. Don't forget to vote!

To cast your vote, go to:
https://admin.fedoraproject.org/voting

Read more about Fedora elections at

  https://fedoraproject.org/wiki/Elections

and about the new FESCo at

  http://fedoraproject.org/wiki/Development/SteeringCommittee

We use range voting in this process — vote for as many or as
few candidates as you like on a sliding scale.

Note: we were planning Env and Stacks WG elections too but
as number of candidates was the same as open seats, Env and
Stacks group decided not to run elections this time and
accept all candidates as committee members. See the announce-
ment from Honza Horak.

The Fedora Magazine interviews got delayed as we were waiting
for more questions being asked from the community. If you
need it to make your decision, please check magazine later. 

Jaroslav 

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

FESCo Elections Questionnaire - questions needed

[Jaroslav Reznik]

Hi everyone,
Elections Questionnaire needs more questions for Fedora Magazine
interviews! If you have anything you'd like to ask candidates to
FESCo, add it to the wiki today.

http://fedoraproject.org/wiki/Elections/Questionnaire 

Thanks
Jaroslav
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Vagrant

[Jaroslav Reznik]

= Proposed Self Contained Change: Vagrant =
https://fedoraproject.org/wiki/Changes/Vagrant

Change owner(s): Josef Stribny 

Provide Vagrant http://www.vagrantup.com/ with the libvirt provider
as a default. 

== Detailed Description ==
Vagrant is an automation tool used to manage development environments
using virtualization and configuration management tools. It allows
developers and teams to work on their projects and test them in an
environment similar to production. Historically, Vagrant had a 
dependency on VirtualBox, but the newer versions have a plugin system 
allowing it to work with other virtualization technologies, including 
libvirt. The plan is to package Vagrant with the support for libvirt 
(coming as vagrant-libvirt plugin) replacing VirtualBox as a default 
provider. 

== Scope ==
* Proposal Owners: Initial work has been done in for Vagrant on F20 
in a Copr repository. Patches and quick fixes should be cleaned up 
or revisited. Also we need to depend on newer version of libvirt 
through rubygem-fog. Some commits for that are already in upstream 
repositories for vagrant-libvirt and fog. See upstream issue for 
details. 

* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: qtile

[Jaroslav Reznik]

= Proposed Self Contained Change: qtile =
https://fedoraproject.org/wiki/Changes/qtile

Change owner(s): John Dulaney  

qtile is a tiling window manager written in python. More can be
found at the project's website [1].

== Detailed Description ==
Once qtile 0.9 is released upstream, package it for Fedora.
All of the dependencies are already in Rawhide as of this writing. 

== Scope ==
* Proposal owners: Work with upstream to get releae out and then package for 
Fedora
* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://www.qtile.org/
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Tunir

[Jaroslav Reznik]

= Proposed Self Contained Change: Tunir =
https://fedoraproject.org/wiki/Changes/tunir

Change owner(s): Kushal Das 

Tunir is a self contained CI Continuous Integration [1] which will be used to 
test Fedora Cloud images nightly. This tool can be used separately by any 
developer in their Fedora 21 system to run/test their local tests/jobs. 

== Detailed Description ==
Tunir is a very simple CI system written keeping Fedora Cloud images at mind. 
At the same time it is generic enough to be used by anyone to configure and run 
jobs/tests in their local system. We will be able to track the status of 
nightly cloud builds, we can also keep track other changes like, the 
dependencies pulled in, or the overall size of the images. The same tool can 
used as a self contained CI system by any Fedora user to run their own tests 
locally. The tool has a minimal dependency and very simple to configure and 
maintain.

This tool right now can create vm(s) based on cloud images (without needing an 
actual cloud), or can run the tests in a bare metal box, or it can even create 
jobs inside Docker containers.

Example:

  $ sudo tunir --job dockerjob --stateless

The above command will run a stateless job named "dockerjob", it will not save 
the result into any database as it is a stateless run. 

== Scope ==
* Proposal owners: kushal...@gmail.com to work on tunir 
* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] http://en.wikipedia.org/wiki/Continuous_integration
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Local Test Cloud

[Jaroslav Reznik]

= Proposed Self Contained Change: Local Test Cloud =
https://fedoraproject.org/wiki/Changes/Local_Test_Cloud

Change owner(s): Mike Ruckman 

testCloud [1] is a small tool to download and boot cloud images locally. 

== Detailed Description ==
testCloud was created because manually booting a cloud image locally can be a 
pain. It handles downloading the image, spoofing cloud-init metadata as well as 
providing an ssh_config to easily connect to the booted instance. What was 
usually several different steps to get an image to boot locally is now just 
one:

 python testCloud.py 

It currently supports both the Fedora Cloud Base as well as the Atomic host 
image.

Note: testCloud will likely change names in the near future. 

== Scope ==
* Proposal owners: Mike Ruckman, Kushal Das to implement proposed change 
* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] https://github.com/Rorosha/testCloud
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud

[Jaroslav Reznik]

= Proposed System Wide Change: Vagrant Box for Fedora Atomic and Fedora Cloud 
=
https://fedoraproject.org/wiki/Changes/Vagrant_Box_Atomic

Change owner(s): Joe Brockmeier , Ian McLeod 
, Langdon White 

To produce Vagrant boxes based on the Fedora Atomic Host and Fedora Cloud 
flavors so that users can easily work with Fedora in the Vagrant environment. 

== Detailed Description ==
Vagrant is a tool for building and distributing development environments. 
Vagrant boxes can easily be used on a number of local virtualization platforms 
such as VirtualBox, VMware, via AWS or OpenStack, or with other platforms. 
Vagrant is used on Linux, Mac OS X, and Microsoft Windows and would present 
Fedora with an opportunity to reach a larger developer audience than it 
currently does.

Many developers prefer to work with Vagrant [1] for their development work, 
using Vagrant to lower their development setup time, increase productivity, 
and avoid having to specifically install an OS each time they wish to use it 
for development.

A number of people have produced unofficial Vagrant boxes, but the Fedora 
project does not currently produce an "official" Vagrant box for consumption. 
We 
would like to close the gap here and offer Vagrant users easy-to-consume Fedora 
22 Atomic and Cloud flavored Vagrant boxes. 

== Scope ==
* Proposal owners:
** Provide a kickstart file and additional definition for the Vagrant Boxes.
** Provide scripts and patches for Koji to generate Vagrant Boxes.
** Encourage testing of the new Vagrant Boxes by the rest of the Cloud Working 
Group.

* Other developers:
** Encourage other Fedora developers to make use of the Fedora Vagrant Boxes 
for their own development work.
** Ensure that Vagrant is packaged for Fedora 22.

* Release engineering:
** Would need to work with owners of this proposal to add needed features to 
Koji, and add Vagrant Boxes to list of output formats required for release.

* Policies and Guidelines:
** No known impact.

== Contingency Plan ==
If feature is incomplete by Fedora 22 beta, it would be pulled from the 
release. No contingency necessary for fallback as this does not exist in 
Fedora 21.

* Contingency deadline: Beta
* Blocks release? No
* Blocks product? No 

[1] https://www.vagrantup.com/
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: amending the new package process

[Jaroslav Reznik]

- Original Message -
> On Wed, Jan 21, 2015 at 7:16 AM, Nikos Mavrogiannopoulos
>  wrote:
> > On Wed, 2015-01-21 at 12:10 +0100, Vít Ondruch wrote:
> >> > I'd like to propose an amendment to allow
> >> > bringing packages even if no reviewers are available (the typical case).
> >> >
> >> > Step 6: ... If the proposed package is not reviewed for 2 months, the
> >> > package must be reviewed by the submitter, and a git module with the
> >> > master branch will be approved.
> >> The self review doesn't make sense, since I expect you did the package
> >> to your best knowledge already and you really want second pair of eyes
> >> to find any issues which slipped through your hands.
> >> At least myself, I always looking for reviewer who cares to find every
> >> issues I missed, challenge my knowledge and I'd be quite unhappy to
> >> discover later that something slipped through review unnoticed.
> >
> > That's wishful thinking. I proposed that rule in order to make apparent
> > the fact that there are not enough reviewers and new packages are
> > blocked in the queue. Ignoring the fact isn't going to make it go away.
> 
> I've often thought having a "staging" repository for packages in this
> state would be nice.  They could be worked on there, and then promoted
> to the full repo when they passed review.

This was one of the main ideas behind Playground repository [1]. And one
thing we had hard times to agree on (is it staging or repository for 
something that will never go to Fedora proper?).

Maybe it's really time to revive it. On the other hand, Copr itself 
helped a lot (And Copr would backup the whole Playground repo). 

Jaroslav

[1] http://fedoraproject.org/wiki/Changes/Playground_repository 

> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Bare Metal Installer for Fedora Atomic Host

[Jaroslav Reznik]

= Proposed System Wide Change: Bare Metal Installer for Fedora Atomic Host =
https://fedoraproject.org/wiki/Changes/Bare_Metal_Atomic

Change owner(s): Joe Brockmeier , Ian McLeod 


To produce a bare metal installer suitable for installing Fedora Atomic Host 
22 on "bare metal" (e.g., directly on a server rather than running on top of 
some kind of cloud or virtualization). 

== Detailed Description ==
In Fedora 21 we shipped Fedora Atomic Host as an AMI for use in Amazon EC2, 
and as a qcow2 suitable for use with OpenStack, KVM, etc.

For Fedora 22 we wish to expand the coverage of Fedora Atomic Host to make it 
installable on "bare metal" so users are able to run Atomic Host directly on a 
server, workstation, etc. without the need for a cloud or virtualzation layer 
underneath the host. 

== Scope ==
* Proposal owners: Work with rel-eng to add bare metal support. The patches 
should be in Anaconda already, it should mostly be a matter of producing the 
builds via Koji. 

* Other developers: May require some coordination with Anaconda folks. 

* Release engineering: Work with Cloud Working Group to turn on support for 
bare metal builds, add bare metal to regularly produced builds. 

* Policies and guidelines: No obvious impact.

== Contingency Plan ==
* Contingency mechanism: If not ready, will not ship for Fedora 22. 
* Contingency deadline: Beta freeze. 
* Blocks release? No. 
* Blocks product? No.  
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: GNOME 3.16

[Jaroslav Reznik]

= Proposed System Wide Change: GNOME 3.16 =
https://fedoraproject.org/wiki/Changes/GNOME3.16

Change owner(s): Kalev Lember 

Update GNOME to the latest upstream release, 3.16.

== Detailed Description ==
The new features for 3.16 include:

* Notification redesign in gnome-shell [1]
* Improvements in nautilus UI [2]
* New games: gnome-2048 and gnome-taquin
* Improved GTK+ and gnome-shell themes
* The codec, font, mime handler installation support is moving from gnome-
packagekit to gnome-software, with a new UI

== Scope ==
* Proposal owners:
** Keep existing GNOME packages updated
** Follow upstream module changes
** Package new applications and new dependencies of existing GNOME packages 
for GNOME 3.16:
*** gnome-taquin
*** gnome-2048

* Other developers: N/A 
* Release engineering: N/A
* Policies and guidelines: N/A 

== Contingency Plan ==
GNOME 3.16 will be released in March 2015 and fits well into Fedora 22 
schedule. In case of issues with individual modules that aren't either 
released in time or aren't deemed suitable for Fedora 22, we'll continue using 
the GNOME 3.14 versions of these modules.

* Contingency mechanism: The Workstation WG evaluates the GNOME 3.16 
prerelease before beta freeze and reverts individual changes as needed.
* Contingency deadline: beta freeze
* Blocks release? No 

[1] https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications
[2] https://fedoraproject.org/wiki/Changes/Nautilus_Improvements
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Systemd Package Split

[Jaroslav Reznik]

= Proposed System Wide Change: Systemd Package Split =
https://fedoraproject.org/wiki/Changes/SystemdPackageSplit

Change owner(s): Zbigniew Jędrzejewski-Szmek 

Split systemd-units out of the main systemd package 

== Detailed Description ==
Systemd contains many binaries and depends on a fairly large number of 
libraries. Packages which carry systemd units currently have to depend on 
systemd (through %post, %preun, %postun macros used to install and uninstall 
systemd units), which grows the dependency tree and increases the size of 
minimal installs.

With this proposal systemd-units subpackages will be split out again:
systemd-units

This subpackage will contain the directories and binaries necessary to satisfy 
%post, %preun, %postun macros for packages containing systemd units 
(systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config 
information (pkg-config files).

The main systemd package would require this package so it will be pulled in on 
all existing systems. All packages which have BuildRequires:systemd will also 
pull it in transitively.

Systemd previously had a -units subpackage and ~150 packages still depend on 
it. Those packages would start using the reduced subpackage immediately. Other 
packages wishing to use the reduced dependency, would have to change the 
BuildRequires and Requires to systemd-units. 

== Scope ==
* Proposal owners: Create the subpackage, test that macros work as expected. 

* Other developers: Change the BuildRequires and Requires to systemd-units if 
wanted. 

* Release engineering: None 
* Policies and guidelines: s/systemd/systemd-units/ in the appropriate places. 

== Contingency Plan ==
* Revert the packaging change and rebuild systemd. Main systemd package would 
provide systemd-units, as it does now, so no other changes should be 
necessary.
* Contingency deadline: should be possible at any time.
* Blocks release? No.
* Blocks product? No. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: python-dateutil 2.x

[Jaroslav Reznik]

= Proposed System Wide Change: python-dateutil 2.x =
https://fedoraproject.org/wiki/Changes/python-dateutil_2.x

Change owner(s): Pete Travis ,  Stephen 
Gallagher 

The package providing `dateutil` python libraries is currently on version 1.5. 
Early releases in the 2.x series of python-dateutil would work only for 
python3, so the package was not updated in Fedora. Now, python-dateutil is at 
version 2.4 and does work with python2. Fedora packages can be updated to use 
the newer version. 

== Detailed Description ==
Many newer python packages require the newer version of python-dateutil, but 
some still need python-dateutil 1.5 to function properly. Maintainers will 
assess affected packages, and can use the parallel installable python-
dateutil15 package, which already exists in the distribution, if they cannot 
migrate. 

== Scope ==
* Proposal owners: 
Coordinate update efforts and assist maintainers in assessing, testing, and 
updating their packages.

* Other developers: 
Maintainers of packages that depend on python-dateutils should test with 
version 2.4, or the current release at freeze. If their package is not 
compatible with this version, they should change the packages Requires: to use 
python-dateutil15 and ensure that it works with the parallel-installable egg 
that it provides.

* Release engineering: As each package should be assessed individually, a mass 
rebuild is not appropriate and release engineering has no requirements for 
this change. 

* Policies and guidelines: 
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions is 
relevant. 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Ipsilon

[Jaroslav Reznik]

= Proposed Self Contained Change: Ipsilon =
https://fedoraproject.org/wiki/Changes/Ipsilon

Change owner(s): Patrick Uiterwijk , Simo Sorce 


Inclusion of Ipsilon in the Fedora repositories. 

== Detailed Description ==
The goal is to include the Ipsilon identity provider [1] into Fedora.

Ipsilon is a server and a toolkit to configure Apache-based Service Providers. 
The server is a pluggable selfcontained mod_wsgi application that provides 
federated SSO to web applications. User authentication is always performed 
against a separate Identity Management system (for example a FreeIPA server), 
and communication with application is done using a federation protocol like 
SAML, OpenID, etc.. 

== Scope ==
* Proposal owners: work on Ipsilon inclusion into Fedora 
* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 

[1] https://fedorahosted.org/ipsilon
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Atomic Host

[Jaroslav Reznik]

= Proposed System Wide Change: Atomic Host =
https://fedoraproject.org/wiki/Changes/AtomicHost

Change owner(s): Cloud SIG / Joe Brockmeier  and Colin 
Walters 

New Fedora product: Fedora Atomic Host, an implementation of the Project 
Atomic [1] pattern.

This is a continuation and expansion of Changes/Atomic_Cloud_Image [2].

== Detailed Description ==
The original Changes/Atomic_Cloud_Image was a host system delivered just as a 
cloud image. This Change for Fedora 22 expands it to a multitude of delivery 
vehicles:

* Bare metal support via Anaconda
* Cloud providers
** OpenStack/KVM qcow2
** EC2 AMI
** Google Compute Engine 
* Vagrant boxes (OS X and vagrant-libvirt)
* Ultra-minimal LiveOS image designed for PXE booting diskless servers 

== Scope ==
* Proposal owners: Maintain kickstart and tree configuration, integration with 
Anaconda and other tools, maintain packages in Fedora
* Other developers: Unknown.
* Release engineering: Will need to generate trees during the general Fedora 
compose process, and generate install media and cloud image based on trees.
* Policies and guidelines: May need updates for RpmOstree. 

== Contingency Plan ==
* Blocks product? Yes, Atomic Host 

If something fails and this product can't ship, some upgrade mechanism for 
Fedora 21 Atomic Cloud Image users would need to be evaluated. The simplest 
fallback is to tell those users to reinstall with a traditional Fedora 22 
Cloud image. 

[1] http://www.projectatomic.io/
[2] https://fedoraproject.org/wiki/Changes/Atomic_Cloud_Image
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Plasma 5

[Jaroslav Reznik]

= Proposed System Wide Change: Plasma 5 =
https://fedoraproject.org/wiki/Changes/Plasma_5

Change owner(s): KDE SIG & Daniel Vrátil , Lukáš Tinkl 
, Jan Grulich , Rex Dieter 
, Than Ngo , Kevin Kofler 


Plasma 5 is successor to KDE Plasma 4 created by the KDE Community. It is 
based on Qt 5 and KDE Frameworks 5 and brings many changes and improvements 
over previous versions, including new look & feel as well as important changes 
under the hood. 

== Detailed Description ==
Plasma 5 is a new major version of KDE's workspaces. It has a new theme called 
Breeze, which has cleaner visuals and better readability, improves certain 
work-flows and provides overall more consistent and polished interface.

Changes under the hood include switch to Qt 5 and KDE Frameworks 5 and 
migration to fully hardware-accelerated graphics stack based on OpenGL(ES).

Note that Plasma 5 only includes the actual shell, decorations, icons and a 
few applications coupled with workspace (e.g. KWin, System Settings, 
KSysGuard). It does not include "regular" applications like Dolphin, Okular, 
Konqueror, etc. which are part of KDE Applications product and released 
independently of Plasma 5.

Plasma 5 gets a new feature release every three months, and each feature 
release has monthly bugfix releases. Plasma 5.2 is scheduled to be released on 
January 27. KDE SIG intends to ship Plasma 5.2.2 or Plasma 5.3, depending on 
the final schedules. 

== Scope ==
* Proposal owners:
** Submit, review and import new packages for Plasma 5 to rawhide/F22
** Modify existing KDE 4 packages to ensure smooth upgrade path to Plasma 5
** Retire KDE 4 packages not compatible with Plasma 5, or available in Plasma 
5 under different names/components

* Other developers:
Optionally, maintainers of 3rd party KDE Workspace 4 packages such as Plasma 
applets or KCMs may want to consult upstream regarding Qt 5/Frameworks 
versions of their packages, and eventually update them to Frameworks version, 
so that they are available in Plasma 5.

* Release engineering: 
No, this change requires no coordination with rel-eng.

* Policies and guidelines:
No, this change requires no update to packaging guidelines or policies.

== Contingency Plan ==
* Contingency mechanism: Rolling back to KDE 4 and shipping KDE Workspace 
4.11.X. As rawhide would already have packages with version 5.x.y, we would 
have to increase the epoch number of all affected KDE 4 packages, and making 
them Obsolete their Plasma 5 equivalents (since some Plasma 5 packages have 
been renamed or split from larger KDE 4 packages)
* Contingency deadline: Before F22 beta freeze
* Blocks release? No
* Blocks product? No 

___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Database Server Role

[Jaroslav Reznik]

- Original Message -
> Once upon a time, Stephen Gallagher  said:
> > One of the core focuses of Fedora Server is to simplify things. It's
> > meant to help less-experienced users of Linux get up and running with
> > common activities more quickly. Providing the "PostgreSQL" role and the
> > "MariaDB" role means that we've forced the user to do additional
> > research to figure out what they want. However, if we name one "Database
> > Server", we are implicitly telling the user: "use this one, unless you
> > have a specific need".
> 
> Well, but a user will still have to do that research.  A database isn't
> like a browser or word processor; it doesn't exist in a vacuum and one
> database engine can't just replace another at will.  Some programs
> support a wide variety of database engines, and some don't.  For
> example, for good or bad, many PHP-based things assume MySQL; some can
> be configured otherwise, but most default to MySQL (and that may be all
> the developers actually test).

Maybe this could be a very nice LAMP role. Or in our case FAMP :).

> Database engines are probably one of the least interchangeable pieces,
> so choosing _any_ (I'd say the same thing if this was a proposal to use
> MariaDB) as "THE database engine" is poor IM(very)HO.  It isn't about
> promoting one engine over another, it is just that none are really the
> one engine to rule them all.  Given that, I don't see a reason to
> declare any engine as the one true Database Server.  I think any role
> for a database should have the engine name in the Role.

I understand what you mean but also - if someone is going to deploy 
application that depends on specific DB, it would probably mean own
installation based on app requirements.

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 Self Contained Change: Minglish - New input method for Marathi Language

[Jaroslav Reznik]

= Proposed Self Contained Change: Minglish - New input method for Marathi 
Language =
https://fedoraproject.org/wiki/Changes/minglish

Change owner(s): anish 

New input method for Marathi language users. 

== Detailed Description ==
Minglish input method is to type Marathi using Latin alpha-bates.However there 
are existing mim layouts are available though each layout has few problems. 
e.g to type word "anish" in Marathi using phonetic input method one has to 
type sequence as "FniS" while with itrans input method one has to type 
"anisha". In given example user often expects "अनिश" to be appear with 
keystrokes "anish". In India, people who have familiar with English language 
tend to type Marathi letters upon English letter pronunciation, that is why we 
have new term http://en.wikipedia.org/wiki/Hinglish. 

== Scope ==
* Proposal owner: Initial plan is to send this patch to upstream and otherwise 
patch it into Fedora 

* Other developers: N/A (not a System Wide Change) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines: N/A (not a System Wide Change) 
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Jaroslav Reznik]

= Proposed System Wide Change: Enable Polyinstantiated /tmp and /var/tmp 
directories by default =
https://fedoraproject.org/wiki/Changes/Polyinstantiated_tmp_by_Default

Change owner(s): Huzaifa Sidhpurwala 

Polyinstantiation of temperary directories is a pro-active security measure, 
which reduced chances of attacks caused due to the /tmp and /var/tmp 
directories being world-writable. These include flaws caused by predictive 
temp. file names, race conditions due to symbolic links etc. 

== Detailed Description ==
The basic idea is to provide better security to Fedora installs. Though 
Polyinstantiated /tmp has worked since Fedora 19, its not a single step 
process to configure it. Secondly people don't really understand its benefits. 
Because of this having it on by default makes more sense. It is completely 
transparent to the user, they wont even realize that it has been enabled.

The Red Hat Product Security Team assigns CWE ids to severe flaws (CVSSv2 > 7). 
Here is a list of severe flaws caused by insecure tmp files [1].

== Scope ==
* Proposal owners: No work required to be done by proposal owner.

* Other developers:
** Add /tmp-inst and /var/tmp/tmp-inst to filesystem. (packagename: filesystem)
** Enable namespaces in /etc/security/namespace.conf (packagename: PAM)
** Enable proper selinux context and polyinstantiation_enabled boolean to be 
set (packagename: selinux-policy-targeted or selinux-policy)

* Release engineering: N/A
* Policies and guidelines: N/A

== Contingency Plan ==
* Contingency mechanism: Poly tmp can be rolled back quite easily, by using 
the previous versions of packages which provides the old directory structures 
and old versions of the configuration files (poly tmp is just configuration and 
a 
few new directories). In releases earlier gnome-shell had issues with poly 
tmp, which now seems to be resolved. In any case, by Beta deadline if any 
blockers exists, we can easily remove this feature, by tagging previous 
versions of the affected packages, before the final spin.

* Contingency deadline: Beta freeze
* Blocks release? No 

[1] http://red.ht/1EkZ1gT
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct