Change Checkpoint: Proposals submission deadline is today

[Jan Kurik]

Hi everyone!
Today is the last day/chance to submit your system wide changes for Fedora 23 
[1]! Your proposed change has to be at least in "Ready for Wrangler" state.

For policies, check out [2]. Empty template is available at [3]. All changes 
approved so far are available on the ChangeSet [4] wiki.

The deadline is *final* as we'd like to strictly adhere to schedule and any 
further exception may be rejected. Self contained changes will be considered 
after this deadline but in case of any doubts, may be rejected as well.

Please make sure Contingency Plan section contains all required fields and 
enough details to understand all the potential risks.

Thanks
Jan

[1] https://fedoraproject.org/wiki/Releases/23/Schedule
[2] https://fedoraproject.org/wiki/Changes/Policy
[3] https://fedoraproject.org/wiki/Changes/EmptyTemplate
[4] https://fedoraproject.org/wiki/Releases/23/ChangeSet

-- 
Jan Kuřík
___
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 23 Bugzilla Rawhide rebase

[Jan Kurik]

Greetings,

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

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

Jan

-- 
Jan Kuřík
___
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: F23 Self Contained Change: Cloud Systemd Networkd

[Neal Gompa]

I know this is a little off-topic, but why don't we use systemd-networkd in
Fedora proper as a replacement for the ifcfg scripts when NetworkManager
isn't desired? Or at least provide it as an alternative option to
NetworkManager and ifcfg scripts in general?

On Tue, Jun 23, 2015 at 2:34 AM, Jan Kurik  wrote:

> = Proposed Self Contained Change: Cloud Systemd Networkd =
> https://fedoraproject.org/wiki/Changes/Cloud_Systemd_Networkd
>
> Change owner(s): Kushal Das 
>
> We will use systemd-networkd to configure network in Cloud base image.
>
> == Detailed Description ==
> systemd-networkd is a system daemon that manages network configurations.
> It detects and configures network devices as they appear. Cloud base image
> will use systemd-networkd for its network.
>
> systemd is a default package in Fedora, and we can use its latest feature
> to control the network configurations. We will remove the hacks we have in
> the current kickstart file, and use systemd tools for network configuration.
>
> == Scope ==
> * Proposal owners: The Cloud base image.
> * 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)
> * Trademark approval: N/A (not needed for this Change)
>
> --
> Jan Kuřík
> ___
> 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




-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Jon Kerr Nilsen

[Jon Kerr Nilsen]

Hi all,

As suggested in 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers?rd=PackageMaintainers/Join#Introduce_yourself
 

 I'd like to introduce myself. I'm Jon Kerr Nilsen, and I'm release manager and 
developer of NorduGrid ARC (http://www.nordugrid.org 
), an open source resource connector which I have 
helped develop since 2007. As for other related experience, I've been using 
RedHat based systems on a daily basis ever since I installed RHL 6.0 in 1999. 

My main reason for becoming a package maintainer in the Fedora Project is to be 
able to co-maintain the ARC software in Fedora and EPEL. My first package is 
related to a development project we have in ARC where we need to connect some 
old perl code with some new python code. To accomplish this we're going to use 
the Inline::Python package from CPAN, and since it is not yet packaged for 
Fedora, here's the review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1234791 


cheers,
Jon-- 
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: F23 Self Contained Change: Cloud Systemd Networkd

[Peter Robinson]

On Tue, Jun 23, 2015 at 11:39 AM, Neal Gompa  wrote:
> I know this is a little off-topic, but why don't we use systemd-networkd in
> Fedora proper as a replacement for the ifcfg scripts when NetworkManager
> isn't desired? Or at least provide it as an alternative option to
> NetworkManager and ifcfg scripts in general?

It's there, there's nothing stopping you from using it.

> On Tue, Jun 23, 2015 at 2:34 AM, Jan Kurik  wrote:
>>
>> = Proposed Self Contained Change: Cloud Systemd Networkd =
>> https://fedoraproject.org/wiki/Changes/Cloud_Systemd_Networkd
>>
>> Change owner(s): Kushal Das 
>>
>> We will use systemd-networkd to configure network in Cloud base image.
>>
>> == Detailed Description ==
>> systemd-networkd is a system daemon that manages network configurations.
>> It detects and configures network devices as they appear. Cloud base image
>> will use systemd-networkd for its network.
>>
>> systemd is a default package in Fedora, and we can use its latest feature
>> to control the network configurations. We will remove the hacks we have in
>> the current kickstart file, and use systemd tools for network configuration.
>>
>> == Scope ==
>> * Proposal owners: The Cloud base image.
>> * 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)
>> * Trademark approval: N/A (not needed for this Change)
>>
>> --
>> Jan Kuřík
>> ___
>> 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
>
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> --
> 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

need rpm help (nothing provides /bin/python)

[Neal Becker]

I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.

Now I tried a local build, and tried to locally install, but I got:
 sudo dnf install x86_64/*3.4.1*
[sudo] password for nbecker: 
Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18 
2015.
Error: nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64.
nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64

Anyone see how to fix this?

Also, can someone please confirm that I correctly took care of 
obsoleting the mercurial-emacs{-el} as per:

https://fedoraproject.org/wiki/Packaging:Emacs

-- 
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: need rpm help (nothing provides /bin/python)

[Reindl Harald]

Am 23.06.2015 um 13:21 schrieb Neal Becker:

I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.

Now I tried a local build, and tried to locally install, but I got:
  sudo dnf install x86_64/*3.4.1*
[sudo] password for nbecker:
Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18
2015.
Error: nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64.
nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64

Anyone see how to fix this?

Also, can someone please confirm that I correctly took care of
obsoleting the mercurial-emacs{-el} as per:

https://fedoraproject.org/wiki/Packaging:Emacs


i guess that's because Fedora still did not get the UsrMove right and 
hence i created a metapackage here to get rid of all that troubles 
finally adding every broken package there


[builduser@buildserver:/rpmbuild/SPECS]$ cat lounge-provides.spec
Summary:   metapackage for thelounge.net provides packages
Name:  lounge-provides
Version:   21.0
Release:   2%{?dist}
BuildArch: noarch
Group: System Environment/Libraries
URL:   http://www.thelounge.net/
License:   GPL

Provides:  %{_bindir}/perl
Provides:  %{_sbindir}/ldconfig



signature.asc
Description: OpenPGP digital signature
-- 
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: need rpm help (nothing provides /bin/python)

[Petr Spacek]

On 23.6.2015 13:21, Neal Becker wrote:
> I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.
> 
> Now I tried a local build, and tried to locally install, but I got:
>  sudo dnf install x86_64/*3.4.1*
> [sudo] password for nbecker: 
> Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18 
> 2015.
> Error: nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64.
> nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64
> 
> Anyone see how to fix this?

This happens if your local PATH variable contains /bin before /usr/bin. Try to
change the order and rebuild the package.

Apparently Koji does not have this problem, please do not ask me why :-)

Petr Spacek  @  Red Hat

> Also, can someone please confirm that I correctly took care of 
> obsoleting the mercurial-emacs{-el} as per:
> 
> https://fedoraproject.org/wiki/Packaging:Emacs
-- 
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: need rpm help (nothing provides /bin/python)

[Jonathan Underwood]

On 23 June 2015 at 12:21, Neal Becker  wrote:
> Also, can someone please confirm that I correctly took care of
> obsoleting the mercurial-emacs{-el} as per:
>
> https://fedoraproject.org/wiki/Packaging:Emacs

Thanks for doing this. I checked the spec file, and the
obsoletes/provides look correct. However it looks like you're missing
a Requires for emacs-filesystem. Also, you should ensure your package
owns %{emacs_lispdir}/mercurial/ (rather than just the files beneath).

Also, I wonder why you're rolling your own macros for emacs_lispdir
etc, rather than using those made available from
/usr/lib/rpm/macros.d/macros.emacs (installed by the emacs-common
package, which will be present during package build, as you BR emacs)
? It doesn't break anything of course.

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

libscrypt versions on koji

[Beat Küng]

Hi

I did scratch builds on koji for f21 [1], f22 [2] & f23 [3]. On f22 the
build fails because of an older version of libscrypt. According to the
root.log, the 3 versions are: 1.20-1.fc21, 1.19-3.fc22, 1.20-2.fc23. Is
there a reason why f22 uses an older version?

There is an open bug request [4] that describes the exact build problem.

cheers
Beat

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10190710
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=10190682
[3] http://koji.fedoraproject.org/koji/taskinfo?taskID=10190674
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1193878
-- 
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: Puppet 4

[Nico Kadel-Garcia]

On Mon, Jun 22, 2015 at 10:22 PM, Michael Stahnke
 wrote:
> As a point of moderation, we could probably break out the FHS/stateless
> discussion into its own thread, as at this point this has nearly nothing to
> do with Puppet.

Good point. Let me circle it back around:

It seems reasonable for a management toolkit like Puppet, which may
require somewhat non-system versions of critical libraries and
scripting language modules, to follow the FHS for third-party packages
and live in /opt/puppet. There's a real burden in relying on, and
integrating with, the Fedora system components due to the potential
for incompatible upgrades of those modules in the Fedora operating
system, or for leading edges of those components to be introduced for
Puppet but be incompatible with other, especially older, existing
Fedora systems. So it's sometimes safer, as in this case, to segregate
those components from the base OS.

So while as a recommended practice segregating tools like "Puppet" to
a separate working area can be non-standard for Fedora, it certainly
seems both workable and justified in this case. It helps retain
independent upgradeability across Fedora releases and for the RHEL
environments, the corporate supported OS which provides a great deal
of Fedora support and ingrastructure.

I've been through similar issues recently with chef, chefdk, RT,
cfengine, GForge, and other add-on components. The desire to root the
core of such a package in the operating system's own internal modules
and libraries is understandable, but it can become a maintenance and
integration nightmare  quite quickly and needs to be, occasionally,
rejected.
-- 
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: libscrypt versions on koji

[Dan Horák]

On Tue, 23 Jun 2015 15:34:10 +0300
Beat Küng  wrote:

> Hi
> 
> I did scratch builds on koji for f21 [1], f22 [2] & f23 [3]. On f22
> the build fails because of an older version of libscrypt. According
> to the root.log, the 3 versions are: 1.20-1.fc21, 1.19-3.fc22,
> 1.20-2.fc23. Is there a reason why f22 uses an older version?

looks as the update to 1.20 was not done correctly, any provenpackager
can fix the situation


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

Updating SFML to 2.3

[Pranav Kant]

I unorphaned SFML couple of days back. I plan to update the version to
latest upstream version, SFML 2.3 in f21, f22 and rawhide.

Affected package : marsshooter
$ repoquery --whatrequires SFML SFML-devel
marsshooter

To build marsshooter against latest SFML, a small patch is required.
My sponsor Mamoru, as provenpackager, will take care of fixing
marsshooter build against latest SFML.

-- 
Regards,
Pranav Kant,
http://pranavk.me
-- 
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: need rpm help (nothing provides /bin/python)

[Michael Šimáček]

On 2015-06-23 13:21, Neal Becker wrote:

I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.

Now I tried a local build, and tried to locally install, but I got:
  sudo dnf install x86_64/*3.4.1*
[sudo] password for nbecker:
Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18
2015.
Error: nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64.
nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64

Anyone see how to fix this?

Also, can someone please confirm that I correctly took care of
obsoleting the mercurial-emacs{-el} as per:

https://fedoraproject.org/wiki/Packaging:Emacs



DNF cannot resolve provides that look like file path:
https://bugzilla.redhat.com/show_bug.cgi?id=1223478

Koji still uses Yum, that's why it works there.

Michael Simacek
--
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: need rpm help (nothing provides /bin/python)

[Reindl Harald]

Am 23.06.2015 um 15:58 schrieb Michael Šimáček:

DNF cannot resolve provides that look like file path:
https://bugzilla.redhat.com/show_bug.cgi?id=1223478


Priority "Low" - seriously?



signature.asc
Description: OpenPGP digital signature
-- 
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: need rpm help (nothing provides /bin/python)

[Josh Boyer]

On Tue, Jun 23, 2015 at 10:37 AM, Reindl Harald  wrote:
>
> Am 23.06.2015 um 15:58 schrieb Michael Šimáček:
>>
>> DNF cannot resolve provides that look like file path:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1223478
>
>
> Priority "Low" - seriously?

It is probably worth pointing out that the Priority and Severity
fields are widely ignored and mostly pointless in Fedora.  Anybody can
set them to whatever they want and their value doesn't reflect
reality.

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

Re: need rpm help (nothing provides /bin/python)

[Reindl Harald]

Am 23.06.2015 um 16:42 schrieb Josh Boyer:

On Tue, Jun 23, 2015 at 10:37 AM, Reindl Harald  wrote:


Am 23.06.2015 um 15:58 schrieb Michael Šimáček:


DNF cannot resolve provides that look like file path:
https://bugzilla.redhat.com/show_bug.cgi?id=1223478



Priority "Low" - seriously?


It is probably worth pointing out that the Priority and Severity
fields are widely ignored and mostly pointless in Fedora.  Anybody can
set them to whatever they want and their value doesn't reflect
reality


not if the developer makes the priority change



signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

perl-Flickr-API license change

[Petr Pisar]

With perl-Flickr-API-1.13-1.fc23 build comes new license. It was
Artistic 2.0. It's GPL+ or Artistic now.

-- Petr

-- 
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: need rpm help (nothing provides /bin/python)

[Josh Boyer]

On Tue, Jun 23, 2015 at 10:45 AM, Reindl Harald  wrote:
>
>
> Am 23.06.2015 um 16:42 schrieb Josh Boyer:
>>
>> On Tue, Jun 23, 2015 at 10:37 AM, Reindl Harald 
>> wrote:
>>>
>>>
>>> Am 23.06.2015 um 15:58 schrieb Michael Šimáček:


 DNF cannot resolve provides that look like file path:
 https://bugzilla.redhat.com/show_bug.cgi?id=1223478
>>>
>>>
>>>
>>> Priority "Low" - seriously?
>>
>>
>> It is probably worth pointing out that the Priority and Severity
>> fields are widely ignored and mostly pointless in Fedora.  Anybody can
>> set them to whatever they want and their value doesn't reflect
>> reality
>
>
> not if the developer makes the priority change

You have no insight into what that actually means to the developer
though.  It could mean anything from "I have 6 crashing bugs to fix
before this, but it's on my list" to "I set it to low because my team
requires a priority for every bug but this doesn't really mean
anything."

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

Broken dependencies: perl-PDL-Graphics-PLplot

[buildsys]

perl-PDL-Graphics-PLplot has broken dependencies in the rawhide tree:
On x86_64:
perl-PDL-Graphics-PLplot-0.67-6.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
perl-PDL-Graphics-PLplot-0.67-6.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-PDL-Graphics-PLplot-0.67-6.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
perl-PDL-Graphics-PLplot-0.67-6.fc23.i686 requires libperl.so.5.20
On armhfp:
perl-PDL-Graphics-PLplot-0.67-6.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
perl-PDL-Graphics-PLplot-0.67-6.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Test-AutoBuild

[buildsys]

perl-Test-AutoBuild has broken dependencies in the rawhide tree:
On x86_64:
perl-Test-AutoBuild-1.2.4-15.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
perl-Test-AutoBuild-1.2.4-15.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
perl-Test-AutoBuild-1.2.4-15.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Latest syslinux build breaks Rawhide images: any help figuring out why?

[Adam Williamson]

Hi, folks. We have a serious issue with Rawhide (F23) images at
present: syslinux is broken. This means all the images fail to boot
when syslinux is used as the bootloader (they do boot when grub is
used, i.e. when booting via UEFI).

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

this started happening when the F23 rebuild of syslinux landed - 6.03
-4.fc23. Prior to that, the attempt to rebuild it for the hardening
change - which would have been 6.03-4.fc23 - failed, so the previous
build was 6.02-2.fc22 , the same build that shipped in F22.

If you build 6.03-4 for F21 and sub that into an image, it boots fine,
so the issue is clearly something in the F23 compilation environment,
but I have not yet been able to see what. The obvious candidate is the
hardening stuff itself, but in fact - so far as I can see - none of the
relevant flags is actually different between F21 and F23, it looks like
the build was already 'hardened'. So it may instead be some change of
behaviour in GCC or similar.

It's worth noting that trying to build 6.03-4 for F22 fails entirely:

http://koji.fedoraproject.org/koji/taskinfo?taskID=10184690

If anyone wants to see the logs from the F21 and F23 builds, my scratch
builds are here:

21 - http://koji.fedoraproject.org/koji/taskinfo?taskID=10183978
23 - http://koji.fedoraproject.org/koji/taskinfo?taskID=10183680

and you can find nightly live images at https://koji.fedoraproject.org/
koji/tasks?owner=masher&state=closed&view=flat&method=createLiveCD&orde
r=-id - any current Rawhide live will fail to boot on x86 BIOS systems
due to this problem.

Any help in figuring out the problem would be appreciated! Thanks.
-- 
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

Re: Latest syslinux build breaks Rawhide images: any help figuring out why?

[Adam Williamson]

On Tue, 2015-06-23 at 08:39 -0700, Adam Williamson wrote:
> 
> this started happening when the F23 rebuild of syslinux landed - 6.03
> -4.fc23. Prior to that, the attempt to rebuild it for the hardening
> change - which would have been 6.03-4.fc23 - failed, so the previous
> build was 6.02-2.fc22 , the same build that shipped in F22.

Sorry, s/6.02-2.fc22/6.03-2.fc22/ there.
-- 
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

Schedule for Wednesday's FESCo Meeting (2015-06-24)

[Tomas Hozza]

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-06-24 18:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1450 F23 System Wide Change: Python 3 as the Default Implementation
.fesco 1450
https://fedorahosted.org/fesco/ticket/1450

#topic #1445 F23 Self Contained ChangesImplementation
.fesco 1445
https://fedorahosted.org/fesco/ticket/1445

= New business =

#topic #1451 F23 System Wide Change: SELinux policy store migration
.fesco 1451
https://fedorahosted.org/fesco/ticket/1451

= 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

Re: need rpm help (nothing provides /bin/python)

[Radek Holy]

- Original Message -
> From: "Michael Šimáček" 
> To: "Development discussions related to Fedora" 
> , ndbeck...@gmail.com
> Sent: Tuesday, June 23, 2015 3:58:49 PM
> Subject: Re: need rpm help (nothing provides /bin/python)
> 
> On 2015-06-23 13:21, Neal Becker wrote:
> > I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.
> >
> > Now I tried a local build, and tried to locally install, but I got:
> >   sudo dnf install x86_64/*3.4.1*
> > [sudo] password for nbecker:
> > Last metadata expiration check performed 0:22:21 ago on Tue Jun 23 06:57:18
> > 2015.
> > Error: nothing provides /bin/python needed by
> > mercurial-3.4.1-1.fc23.x86_64.
> > nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64
> >
> > Anyone see how to fix this?
> >
> > Also, can someone please confirm that I correctly took care of
> > obsoleting the mercurial-emacs{-el} as per:
> >
> > https://fedoraproject.org/wiki/Packaging:Emacs
> >
> 
> DNF cannot resolve provides that look like file path:
> https://bugzilla.redhat.com/show_bug.cgi?id=1223478

No, please don't speak for DNF if you don't know it. This is not the same.

Your bug is precisely about the inability to specify virtual file provides on 
command line.

> Koji still uses Yum, that's why it works there.
> 
> Michael Simacek

The problem is that there is no package that "Provides: /bin/python" nor lists 
"/bin/python" in the "%files" section.


# cat >foo.spec < Name: foo
> Version: 1.0.0
> Release: 1
> Summary: foo
> License: BSD
> BuildArch: noarch
>
> Requires: /bin/python
> 
> %description
> foo
> 
> %files
> EOF
# rpmbuild -bb foo.spec
# dnf install ~/rpmbuild/RPMS/foo-1.0.0-1.noarch.rpm
Error: nothing provides /bin/python needed by foo-1.0.0-1.noarch


# cat >foo.spec < Name: foo
> Version: 1.0.0
> Release: 1
> Summary: foo
> License: BSD
> BuildArch: noarch
>
> Requires: /usr/bin/python
> 
> %description
> foo
> 
> %files
> EOF
# rpmbuild -bb foo.spec
# dnf install ~/rpmbuild/RPMS/foo-1.0.0-1.noarch.rpm
Dependencies resolved.

 Package   Arch VersionRepository  Size

Installing:
 foo   noarch   1.0.0-1@commandline   5.4 k

Transaction Summary

Install  1 Package

Total size: 5.4 k
Installed size: 0  
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : foo-1.0.0-1.noarch  1/1 
warning: Unable to get systemd shutdown inhibition lock
  Verifying   : foo-1.0.0-1.noarch  1/1 

Installed:
  foo.noarch 1.0.0-1

Complete!


So, to fix it, the "Requires:" should be e.g. "/usr/bin/python".
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: need rpm help (nothing provides /bin/python)

[Radek Holy]

- Original Message -
> From: "Radek Holy" 
> To: "Development discussions related to Fedora" 
> 
> Cc: ndbeck...@gmail.com
> Sent: Tuesday, June 23, 2015 5:47:10 PM
> Subject: Re: need rpm help (nothing provides /bin/python)
> 
> 
> 
> - Original Message -
> > From: "Michael Šimáček" 
> > To: "Development discussions related to Fedora"
> > , ndbeck...@gmail.com
> > Sent: Tuesday, June 23, 2015 3:58:49 PM
> > Subject: Re: need rpm help (nothing provides /bin/python)
> > 
> > On 2015-06-23 13:21, Neal Becker wrote:
> > > I updated mercurial to mercurial-3.4.1-1 and did a fedpkg push.
> > >
> > > Now I tried a local build, and tried to locally install, but I got:
> > >   sudo dnf install x86_64/*3.4.1*
> > > [sudo] password for nbecker:
> > > Last metadata expiration check performed 0:22:21 ago on Tue Jun 23
> > > 06:57:18
> > > 2015.
> > > Error: nothing provides /bin/python needed by
> > > mercurial-3.4.1-1.fc23.x86_64.
> > > nothing provides /bin/python needed by mercurial-3.4.1-1.fc23.x86_64
> > >
> > > Anyone see how to fix this?
> > >
> > > Also, can someone please confirm that I correctly took care of
> > > obsoleting the mercurial-emacs{-el} as per:
> > >
> > > https://fedoraproject.org/wiki/Packaging:Emacs
> > >
> > 
> > DNF cannot resolve provides that look like file path:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1223478
> 
> No, please don't speak for DNF if you don't know it. This is not the same.
> 
> Your bug is precisely about the inability to specify virtual file provides on
> command line.
> 
> > Koji still uses Yum, that's why it works there.
> > 
> > Michael Simacek
> 
> The problem is that there is no package that "Provides: /bin/python" nor
> lists "/bin/python" in the "%files" section.
> 
> 
> # cat >foo.spec < > Name: foo
> > Version: 1.0.0
> > Release: 1
> > Summary: foo
> > License: BSD
> > BuildArch: noarch
> >
> > Requires: /bin/python
> > 
> > %description
> > foo
> > 
> > %files
> > EOF
> # rpmbuild -bb foo.spec
> # dnf install ~/rpmbuild/RPMS/foo-1.0.0-1.noarch.rpm
> Error: nothing provides /bin/python needed by foo-1.0.0-1.noarch
> 
> 
> # cat >foo.spec < > Name: foo
> > Version: 1.0.0
> > Release: 1
> > Summary: foo
> > License: BSD
> > BuildArch: noarch
> >
> > Requires: /usr/bin/python
> > 
> > %description
> > foo
> > 
> > %files
> > EOF
> # rpmbuild -bb foo.spec
> # dnf install ~/rpmbuild/RPMS/foo-1.0.0-1.noarch.rpm
> Dependencies resolved.
> 
>  Package   Arch VersionRepository
>  Size
> 
> Installing:
>  foo   noarch   1.0.0-1@commandline   5.4
>  k
> 
> Transaction Summary
> 
> Install  1 Package
> 
> Total size: 5.4 k
> Installed size: 0
> Downloading Packages:
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Transaction test succeeded.
> Running transaction
>   Installing  : foo-1.0.0-1.noarch
>   1/1
> warning: Unable to get systemd shutdown inhibition lock
>   Verifying   : foo-1.0.0-1.noarch
>   1/1
> 
> Installed:
>   foo.noarch 1.0.0-1
> 
> Complete!
> 
> 
> So, to fix it, the "Requires:" should be e.g. "/usr/bin/python".

See also 
https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=413629#Effect_of_the_UsrMove_Fedora_Feature
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
-- 
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: Latest syslinux build breaks Rawhide images: any help figuring out why?

[Adam Williamson]

On Tue, 2015-06-23 at 08:40 -0700, Adam Williamson wrote:
> On Tue, 2015-06-23 at 08:39 -0700, Adam Williamson wrote:
> > 
> > this started happening when the F23 rebuild of syslinux landed - 
> > 6.03
> > -4.fc23. Prior to that, the attempt to rebuild it for the hardening
> > change - which would have been 6.03-4.fc23 - failed, so the 
> > previous
> > build was 6.02-2.fc22 , the same build that shipped in F22.
> 
> Sorry, s/6.02-2.fc22/6.03-2.fc22/ there.

Yeesh, and I got the other one wrong too, didn't I? Let me try that
again.

6.03-2.fc22 = previous successful build, was live in Rawhide till this
started happening. Did not have this bug.
6.03-3.fc23 = attempt to rebuild for hardening Change. Failed.
6.03-4.fc23 = latest successful build, since it landed on 06-19 all
nightlies have had this bug.
-- 
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

Re: need rpm help (nothing provides /bin/python)

[Reindl Harald]

Am 23.06.2015 um 17:50 schrieb Radek Holy:

So, to fix it, the "Requires:" should be e.g. "/usr/bin/python".


See also 
https://fedoraproject.org/w/index.php?title=Packaging:Guidelines&oldid=413629#Effect_of_the_UsrMove_Fedora_Feature


that's a nice writing BUT Fedora decided later to make these cleanups 
not mandatory, try it out, use %{_sbindir}/ldconfig in local built RPM 
packages and wait for the first dist-upgrade with YUM/DNF which can't 
solve deps because *core packages* stil provide /sbin/whatever instead 
/usr/sbin/whatever




signature.asc
Description: OpenPGP digital signature
-- 
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: Heads up: OCaml 4.02.2+rc1 coming to Rawhide

[Richard W.M. Jones]

OCaml 4.02.2 (final) has been released, so I will update to this.

This will not require any kind of mass rebuild this time, since it's
basically identical to the release candidate.  So this will go out as
a compatible update to the base 'ocaml' package.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F23 Self Contained Change: Standardized Passphrase Policy

[Jan Kurik]

= Proposed Self Contained Change: Standardized Passphrase Policy =
https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy

Change owner(s):
* Kevin Fenzi 
* David Cantrell 
* Tomas Mraz  

Currently a number of places ask users to set passphrases/passwords. Some of 
them enforce some kind of rules for passphrases/passwords, others different 
rules. This change would create a common base policy for as many of these 
applications as possible, allowing for local users or products to override this 
base in cases they need to do so. 

== Detailed Description ==
We should have a base passphrase/password policy for applications to use. This 
allows them all to be consistent and also provide our users with needed 
security. Additionally, we should make it possible for our users to adjust this 
base policy as they need depending on their use cases.

The applications involved in this change should be at least:
* anaconda - sets initial root and user passphrases/passwords. 
* passwd - command line utility that changes passphrases/passwords. 
* initial-setup - sets up users if they were not setup in anaconda. 
* libpwquality - doesn't set passwords, but should be used in common for 
quality checking in a consistent manner. 

We should provide a way for users or products to adjust this policy, and also a 
way to allow overriding it (if the policy allows). 


== Scope ==
* Proposal owners: Will work with owners of these components to try and come up 
with a generic policy for passphrases/passwords and how to implement it, then 
get FESCo to approve this policy and then implement it. 
* Other developers: Will need to adjust applications and config to use a common 
set of requirements that can be overriden in one place. 
* Release engineering: None 
* Policies and guidelines: Will need to be approved by FESCo and FPC (not a 
System Wide Change) 
* Trademark approval: N/A (not needed for this Change) 

-- 
Jan Kuřík
___
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

rawhide report: 20150623 changes

[Fedora Rawhide Report]

Compose started at Tue Jun 23 05:15:03 UTC 2015
Broken deps for i386
--
[amqp]
1:amqp-devel-1.0-1.20150622svn1686756.fc23.noarch requires amqp = 
0:1.0-1.20150622svn1686756.fc23
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[bluetile]
bluetile-0.6-28.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[bustle]
bustle-0.4.8-3.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[clearsilver]
perl-clearsilver-0.10.5-29.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.1)
perl-clearsilver-0.10.5-29.fc22.i686 requires libperl.so.5.20
[dpm-dsi]
dpm-dsi-1.9.5-4.fc23.i686 requires globus-gridftp-server-progs(x86-32) 
= 0:7.25
[ghc-gtk]
ghc-gtk-0.13.4-1.fc22.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
ghc-gtk-devel-0.13.4-1.fc22.i686 requires 
ghc-devel(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[ghc-hjsmin]
ghc-hjsmin-0.1.4.7-7.fc23.i686 requires 
ghc(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf)
ghc-hjsmin-devel-0.1.4.7-7.fc23.i686 requires 
ghc-devel(language-javascript-0.5.13-0b8335d6a2507ee73f3b41c61a1ea2bf)
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[julia]
julia-0.3.7-2.fc23.i686 requires libspqr.so.1
julia-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
julia-devel-0.3.7-2.fc23.i686 requires libLLVM-3.5.so
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.i686 requires libgtkdataboks.so.0
[ldns]
perl-ldns-1.6.17-14.fc23.i686 requires perl(:MODULE_COMPAT_5.20.2)
perl-ldns-1.6.17-14.fc23.i686 requires libperl.so.5.20
[leksah-server]
leksah-server-0.14.3.1-2.fc23.i686 requires 
ghc(gio-0.13.0.4-589ef11228222f8fdb72e24c64ce9d0a)
[libfli]
libfli-devel-1.7-15.fc23.i686 requires libfli{?_isa} = 0:1.7-15.fc23
[matreshka]
matreshka-servlet-devel-0.7.0-2.fc23.i686 requires 
matreshka-servlet-lib{?_isa} = 0:0.7.0-2.fc23
matreshka-servlet-lib-0.7.0-2.fc23.i686 requires matreshka{?_isa} = 
0:0.7.0-2.fc23
matreshka-spikedog-api-devel-0.7.0-2.fc23.i686 requires 
matreshka-spikedog-api-lib{?_isa} = 0:0.7.0-2.fc23
matreshka-spikedog-api-lib-0.7.0-2.fc23.i686 requires matreshka{?_isa} 
= 0:0.7.0-2.fc23
matreshka-spikedog-api-lib-0.7.0-2.fc23.i686 requires 
matreshka-servlet-api{?_isa} = 0:0.7.0-2.fc23
matreshka-spikedog-core-devel-0.7.0-2.fc23.i686 requires 
matreshka-spikedog-core-lib{?_isa} = 0:0.7.0-2.fc23
matreshka-spikedog-core-lib-0.7.0-2.fc23.i686 requires matreshka{?_isa} 
= 0:0.7.0-2.fc23
matreshka-spikedog-core-lib-0.7.0-2.fc23.i686 requires 
matreshka-servlet-api{?_isa} = 0:0.7.0-2.fc23
[maxima]
maxima-runtime-sbc

Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

Hey all,

Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).

Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
now.

Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast
for my 48TB array).

As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23
.
At this point, I'm personally convinced that it is certainly ready and
doable for F23.

Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.

The question now is: as a distribution, where are we on this? The tools
seem to work, the filesystem appears stable, and I've not been able to
cause the filesystem to corrupt itself with any kind of user error or cause
it to keel over. So, what's left?

-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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: F23 Self Contained Change: Standardized Passphrase Policy

[Josh Boyer]

On Tue, Jun 23, 2015 at 12:21 PM, Jan Kurik  wrote:
> = Proposed Self Contained Change: Standardized Passphrase Policy =
> https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy

Um... how is this Self Contained?  If we're creating a standardized
distro wide policy, it is by definition not self contained.  Even if
the scope is limited only to the packages listed (which seems
pointless), it still isn't self contained.

josh

>
> Change owner(s):
> * Kevin Fenzi 
> * David Cantrell 
> * Tomas Mraz 
>
> Currently a number of places ask users to set passphrases/passwords. Some of 
> them enforce some kind of rules for passphrases/passwords, others different 
> rules. This change would create a common base policy for as many of these 
> applications as possible, allowing for local users or products to override 
> this base in cases they need to do so.
>
> == Detailed Description ==
> We should have a base passphrase/password policy for applications to use. 
> This allows them all to be consistent and also provide our users with needed 
> security. Additionally, we should make it possible for our users to adjust 
> this base policy as they need depending on their use cases.
>
> The applications involved in this change should be at least:
> * anaconda - sets initial root and user passphrases/passwords.
> * passwd - command line utility that changes passphrases/passwords.
> * initial-setup - sets up users if they were not setup in anaconda.
> * libpwquality - doesn't set passwords, but should be used in common for 
> quality checking in a consistent manner.
>
> We should provide a way for users or products to adjust this policy, and also 
> a way to allow overriding it (if the policy allows).
>
>
> == Scope ==
> * Proposal owners: Will work with owners of these components to try and come 
> up with a generic policy for passphrases/passwords and how to implement it, 
> then get FESCo to approve this policy and then implement it.
> * Other developers: Will need to adjust applications and config to use a 
> common set of requirements that can be overriden in one place.
> * Release engineering: None
> * Policies and guidelines: Will need to be approved by FESCo and FPC (not a 
> System Wide Change)
> * Trademark approval: N/A (not needed for this Change)
>
> --
> Jan Kuřík
> ___
> 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

dnssec-trigger + GNOME + NetworkManager integration

[Tomas Hozza]

Hi all.

I would like to start a new fresh discussion where we can hopefully
converge towards successful integration of default DNS resolver with
NetworkManager on Fedora Workstation (GNOME).

I think there are (at least) two major issues that need to be resolved:
- system-wide Captive Portal detection
- proper UI integration


How is dnssec-trigger integrated with NM

I'll start briefly with what dnssec-trigger does and how it is
integrated with NM, so we are on the same boat.

We use Unbound as local DNS resolver that does also DNSSEC validation.
It needs to be configured with proper DNS forwarders in order to do the
validation successfully.

Dnssec-trigger is a daemon and script that reconfigures Unbound
dynamically on every network change (using NetworkManager dispatcher).
In our intended setup, dnssec-trigger handles the content of
/etc/resolv.conf. It gathers all the current configuration from NM using
libnm-glib. This means that we are able to handle any connection that NM
is aware of, including VPNs and split DNS configuration. Our goal is to
do DNSSEC validation whenever possible, therefore we have also public
fallback Fedora infrastructure or DNS resolvers running on port 443.

Since dnssec-trigger handles resolv.conf and reconfigures Unbound, NM's
purpose is to do all the network configuration EXCEPT DNS related
configuration.


Captive Portal
--
Dnssec-trigger also handles Captive Portal detection, since this
situation is most of the times DNS spoofing attack and DNSSEC is exactly
the mechanism that should protect users from such attack.

Now we know that we have at least 3 components on the system, that are
trying to do the same thing - Captive Portal detection:
- dnssec-trigger
- NetworkManager
- GNOME Shell

We don't have a problem with turning the detection off, however we need
to agree on system-wide solution that works properly.

We already know that the Captive Portal detection in NM relies on the
system stub resolver, however after our previous discussion I was under
the impression that there are some plans to rework it. Is this correct Dan?

I hope that GNOME Shell somehow only displays the state provided by NM.
Bastien, please correct me if I'm wrong and please elaborate on the
details of what the functionality does (e.g. if you launch a new browser
or so).

In dnssec-trigger the detection is done by resolving a predefined
hostname using DHCP-provided resolvers, downloading a remote file and
then comparing the actual content with what was expected. This may not
be perfect, but is mostly works. The important point is that DHCP
provided resolvers are queried directly, not via system stub resolver.

On the other hand, if NM dispatcher would be able to notify other
services in case of detected Captive Portal, dnssec-trigger would be
able to add the correct DHCP-provided resolver into the resolv.conf for
the purpose of Logging into the Captive Portal. This is mainly due to
the browser window using system's stub resolver.


UI integration
--
Now the dnssec-trigger comes with not really well integrated UI
(dnssec-trigger panel) [2]. The panel is written in GTK2 and resides in
the already deprecated status panel (on the bottom of the screen). It is
used mainly for the following interaction with the user:

- Inform the user about Captive Portal, in case there is one (to allow
user to switch into so called "hotspot signon mode") by pop-up window
- enable user to switch to "hotspot signon mode" (basically insecure
mode) manually
- enable the user to reprobe DHCP-provided DNS servers if these are
DNSSEC enabled - meaning to test if these are able to provide all the
data needed for DNSSEC validation.
- inform user in case the local network-provided DNS servers don't
support DNSSEC and the local network blocks outgoing DNS communication
on standard DNS ports and also when tunelled - in other words, user much
choose between insecure mode or disconnecting from the network.

This boils down to what we need from some new version of the UI that we
need to be well integrated with GNOME:

1. Be able to inform user about some situations (Captive portal
detected, network blocks all DNS communication, ...) and enable the user
to take an action. (This could be possibly done by the notifications
system in latest GNOME)

-> this may be solved also in GNOME already, and may be OK if done
technically correctly. Please note my note earlier on NM notifying other
services when Captive Portal is detected

2. Possibly have some indicator showing if the system is in "Secure" or
"Insecure" state.

3. Enable the user to switch between those two states manually

4. Additionally enable the user to trigger the reprobe of
connection-provided DNS resolvers and display result of the probe (last
one).

-> this should not be needed for regular use. It is more of a debugging tool

[1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
[2] http://www.nl

Re: libscrypt versions on koji

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 23, 2015 at 03:35:26PM +0200, Dan Horák wrote:
> On Tue, 23 Jun 2015 15:34:10 +0300
> Beat Küng  wrote:
> 
> > Hi
> > 
> > I did scratch builds on koji for f21 [1], f22 [2] & f23 [3]. On f22
> > the build fails because of an older version of libscrypt. According
> > to the root.log, the 3 versions are: 1.20-1.fc21, 1.19-3.fc22,
> > 1.20-2.fc23. Is there a reason why f22 uses an older version?
> 
> looks as the update to 1.20 was not done correctly, any provenpackager
> can fix the situation

Looks like it F22 was forgotten by Joshua. Building now.

Zbyszek
-- 
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: F23 Self Contained Change: Standardized Passphrase Policy

[Kevin Fenzi]

On Tue, 23 Jun 2015 12:25:20 -0400
Josh Boyer  wrote:

> On Tue, Jun 23, 2015 at 12:21 PM, Jan Kurik  wrote:
> > = Proposed Self Contained Change: Standardized Passphrase Policy =
> > https://fedoraproject.org/wiki/Changes/Standardized_passphrase_policy
> 
> Um... how is this Self Contained?  If we're creating a standardized
> distro wide policy, it is by definition not self contained.  Even if
> the scope is limited only to the packages listed (which seems
> pointless), it still isn't self contained.

I did not mean for it to be such. :( 

It's definitely intended to be System wide. 

I will go figure out what I messed up in the template. 

kevin


pgpjQweivPqQh.pgp
Description: OpenPGP digital signature
-- 
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: Btrfs as default filesystem for Fedora 23?

[Andre Robatino]

Neal Gompa  gmail.com> writes:

> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23. At this point, I'm personally convinced that it is
certainly ready and doable for F23.
> 
> Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.

I asked about this recently on #fedora-devel (I was the one who asked
originally on this list) and was told there are no plans to make it the
default yet. It's amazing that it was originally planned to be the default
on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see
data loss, and not knowing much about filesystems, am sticking to the default.



-- 
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: Btrfs as default filesystem for Fedora 23?

[Josh Boyer]

On Tue, Jun 23, 2015 at 1:30 PM, Andre Robatino
 wrote:
> Neal Gompa  gmail.com> writes:
>
>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
> the default in Fedora 23. At this point, I'm personally convinced that it is
> certainly ready and doable for F23.
>>
>> Perhaps other guys with more experience on this stuff could chime in with
> feedback/information/etc, but it feels like we should start the process to
> get everything ready for Btrfs being default in Fedora 23.
>
> I asked about this recently on #fedora-devel (I was the one who asked
> originally on this list) and was told there are no plans to make it the
> default yet. It's amazing that it was originally planned to be the default
> on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see

Someone created a wiki page proposing that.  It was never actually
planned to be the default.

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

Pondering the Emacs add-on packaging situation

[Jonathan Underwood]

Hi,

So, while filing a bunch of bugs against packages not complying with
the Emacs add-on packaging guidelines, I started to think about the
state of add-ons for Emacs [1].

Since those guidelines were put in place, Emacs has grown its own
package manager (package.el, shipped with Emacs[2]), and now users can
install something approaching 3000 packages from repositories like
ELPA[3], MELPA[4] and Marmalade[5].

The Emacs package manager installs these add-on modules in the user's
own directory by default, but it can also install them in a system
wide directory.

My thoughts are currently that:
1) Fedora doesn't have the manpower to package large numbers of
packages from these repositories and keep the Fedora packages
up-to-date

2) It may be possible to write automation tools like elpa2rpm,
melpa2rpm, marmalade2rpm to automate packging for Fedora from those
repositories, but such tools don't yet exist. Even if they did, the
repositories usually aren't the canonical upstream for the packages.

3) Even if we could generate rpm packages directly from the emacs
package repos, package.el doesn't have any notion such as "installed
but inactive" for packages, such that installing rpm packages of emacs
packages would activate them for all system users, which is
undesireable.

So, I am not really sure what a good way forward is at this point.
Certainly package.el could be extended to help us out in some ways,
such as having a notion of "installed and available but not active".
But is it worth the effort?

The whole issue is another case of competition between an application
package managers (package.el) and system package management such as we
have had to solve for perl, python, texlive etc etc. But it's not
clear to me what a good solution would be for Emacs. I'd welcome any
thoughts anyone has (especially Tom Tromey if he still reads this
list).

Cheers,
Jonathan.

[1] https://fedoraproject.org/wiki/Packaging:Emacs
[2] http://ergoemacs.org/emacs/emacs_package_system.html
[3] https://elpa.gnu.org/
[4] http://melpa.org/#/
[5] https://marmalade-repo.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

Re: Btrfs as default filesystem for Fedora 23?

[Gerald B. Cox]

On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:

> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
> becoming the default in Fedora 23
> 
>
> . At this point, I'm personally convinced that it is certainly ready and
> doable for F23.
>

Well actually he said his "plan" was to push for F23.  I've been using
btrfs raid 6 for several years now and have been lucky I haven't
encountered any issues - but if you subscribe to the mailing list you'll
see others haven't been quite as lucky.  I'm sure he'll propose it once he
believes it is ready.  When proposing a default change it is prudent to be
cautious. In the meantime it's there to use for early adopters; and the
more people who test the faster issues will be identified and corrected.
Just be sure you've taken the proper precautions ;-)
-- 
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: Pondering the Emacs add-on packaging situation

[Neal Becker]

The case I just fixed is a bit different - it's not something that comes 
from elpa, melpa, etc., but is an add-on that was just a contributed part 
that ships with mercurial.  Probably many cases of emacs-foo fedora packages 
are like this.

-- 
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: Self-Introduction: Mike Ruckman (roshi)

[Igor Gnatenko]

Yay, Hi Mike ;) I'm ready to help you anytime)

On Tue, Jun 23, 2015, 2:37 AM Mike Ruckman  wrote:

> Hey devel list!
>
> I'm Mike (mostly known as roshi on freenode) and I'd like to become a
> packager. I don't have much experience (outside of local scratch builds
> to test fixes) with packaging, but I'd like to learn more and get
> involved. I've posted my first package for review [0] for a tool called
> testcloud. testcloud makes it easy to locally boot and test cloud images
> and is currently being used for the disposable clients for taskotron.
> Any feedback or patches welcome!
>
> Thanks!
>
> [0] https://bugzilla.redhat.com/show_bug.cgi?id=1234649
>
> --
> // Mike
> --
> Fedora QA
> freenode: roshi
> http://roshi.fedorapeople.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

-- 

-Igor Gnatenko
-- 
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: dnssec-trigger + GNOME + NetworkManager integration

[Michael Catanzaro]

On Tue, 2015-06-23 at 18:43 +0200, Tomas Hozza wrote:
> I hope that GNOME Shell somehow only displays the state provided by 
> NM.
> Bastien, please correct me if I'm wrong and please elaborate on the
> details of what the functionality does (e.g. if you launch a new 
> browser
> or so).

Yes, that's correct. If NetworkManager's ConnectivityState is
NetworkManager.ConnectivityState.PORTAL, then we launch a small (250
lines of code) GTK+ app with a WebKitWebView [1][2].

I expect that as long as NetworkManager's existing connectivity API is
not broken, GNOME should be fine.

[1] https://git.gnome.org/browse/gnome
-shell/tree/js/ui/status/network.js#n1964
[2] 
https://git.gnome.org/browse/gnome-shell/tree/js/portalHelper/main.js
-- 
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: Pondering the Emacs add-on packaging situation

[Jonathan Underwood]

On 23 Jun 2015 20:06, "Neal Becker"  wrote:
>
> The case I just fixed is a bit different - it's not something that comes
> from elpa, melpa, etc., but is an add-on that was just a contributed part
> that ships with mercurial.  Probably many cases of emacs-foo fedora
packages
> are like this.
>

Oh, sure. I wasn't referring at all to that case (which is quite common,
and we'll handled already in the Fedora infrastructure).
-- 
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: Updating SFML to 2.3

[Hans de Goede]

Hi,

On 06/23/2015 03:34 PM, Pranav Kant wrote:

I unorphaned SFML couple of days back. I plan to update the version to
latest upstream version, SFML 2.3 in f21, f22 and rawhide.

Affected package : marsshooter
$ repoquery --whatrequires SFML SFML-devel
marsshooter

To build marsshooter against latest SFML, a small patch is required.
My sponsor Mamoru, as provenpackager, will take care of fixing
marsshooter build against latest SFML.


Sounds good, thanks for your work on this.

Regards,

Hans
--
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: Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:

>
> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
>
>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>> becoming the default in Fedora 23
>> 
>>
>> . At this point, I'm personally convinced that it is certainly ready and
>> doable for F23.
>>
>
> Well actually he said his "plan" was to push for F23.  I've been using
> btrfs raid 6 for several years now and have been lucky I haven't
> encountered any issues - but if you subscribe to the mailing list you'll
> see others haven't been quite as lucky.  I'm sure he'll propose it once he
> believes it is ready.  When proposing a default change it is prudent to be
> cautious. In the meantime it's there to use for early adopters; and the
> more people who test the faster issues will be identified and corrected.
> Just be sure you've taken the proper precautions ;-)
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>

​Certainly, but with none of the features in Btrfs actually emitting scary
"experimental" warnings anymore, and even all features working in btrfs
RAID 5/6 now, I think we should really start pushing it to more people. Or
at least develop some kind of test plan to prove the "worthiness" of using
it as default. We must have something, ne?


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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: Btrfs as default filesystem for Fedora 23?

[Stephen John Smoogen]

On 23 June 2015 at 14:15, Neal Gompa  wrote:
> On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:
>>
>>
>> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
>>>
>>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>>> becoming the default in Fedora 23
>>>
>>> . At this point, I'm personally convinced that it is certainly ready and
>>> doable for F23.
>>
>>
>> Well actually he said his "plan" was to push for F23.  I've been using
>> btrfs raid 6 for several years now and have been lucky I haven't encountered
>> any issues - but if you subscribe to the mailing list you'll see others
>> haven't been quite as lucky.  I'm sure he'll propose it once he believes it
>> is ready.  When proposing a default change it is prudent to be cautious. In
>> the meantime it's there to use for early adopters; and the more people who
>> test the faster issues will be identified and corrected.  Just be sure
>> you've taken the proper precautions ;-)
>>
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs RAID
> 5/6 now, I think we should really start pushing it to more people. Or at
> least develop some kind of test plan to prove the "worthiness" of using it
> as default. We must have something, ne?
>

So if there are problems who is going to deal with the users, diagnose
the issues and fix them? Those are going to be the people who will
need to push for this feature if they think it is ready or not. I
would start by finding out who they are, talking with them and then
looking at what time frame they think the feature would be ready.


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

Re: F23 Self Contained Change: Netizen Spin

[Kevin Fenzi]

On Sun, 21 Jun 2015 18:52:18 -0400
Corey Leong  wrote:

> I refined the the Detailed Description [1] [2] per the questions
> concerning the Fedora Spin development.
> 
> Detailed Description
> -
> 
> Fedora Netizen is an open source operating system for enabling
> internet citizens, also known as netizens, to engage online services
> and communities. Fedora Netizen includes software packages for
> focusing on civic engagement and internet safety features related to
> security and privacy.
> 
> Nonprofit Organizations and public agencies will benefit from Fedora
> Netizen by switching to free open-source software (FOSS) for running
> public services on the Internet. Fedora Netizen empowers netizens
> with their online activism for changing the world with the help of
> open source software.

So this sounds like it might be a server variant instead of a live
media? If NPO's are intended to use it to run services, I would think
basing it off server and perhaps working on some server roles would be
good here... 

Perhaps you meant that this would be good for NPO's users to use as a
workstation to talk to their servers?

If this is a collection of packages, perhaps it would be as well served
by having a group available of these packages? Then anyone could
install those from any other Fedora install. Of course they would need
to have network then... 

> I removed the psychology topics since it seemed to be a bit confusing
> to others which means users would also have been confused about the
> spin. Regarding the listing of the packages, my intent is to simply
> make users aware of what open source software is included in the spin
> by categorizing the packages. I intend to include best practices,
> how-to's, and other related documentation on a spin related website
> for the user to configure and customize on their own after reading
> documentation.

ok. 

 

kevin


pgpksIH3Uk7O2.pgp
Description: OpenPGP digital signature
-- 
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 20 End Of Life

[Dennis Gilmore]

As of 23rd of June 2015, Fedora 20 has reached its end of life for
updates and support. No further updates, including security updates,
will be available for Fedora 20. A previous reminder was sent on
27th of May [0].

Fedora 21 will continue to receive updates until approximately one
month after the release of Fedora 23.  The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [1].  The
Fedora Project wiki also contains instructions [2] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Kevin

[0]
https://lists.fedoraproject.org/pipermail/announce/2015-May/003267.html
[1]
https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2] 
http://fedoraproject.org/wiki/DistributionUpgrades

signature.asc
Description: This is a digitally signed message part.
___
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: F23 Self Contained Change: Netizen Spin

[Corey Leong]

Kevin --

> Detailed Description
> -
>
> Fedora Netizen is an open source operating system for enabling
> internet citizens, also known as netizens, to engage online services
> and communities. Fedora Netizen includes software packages for
> focusing on civic engagement and internet safety features related to
> security and privacy.
>
> Nonprofit Organizations and public agencies will benefit from Fedora
> Netizen by switching to free open-source software (FOSS) for running
> public services on the Internet. Fedora Netizen empowers netizens
> with their online activism for changing the world with the help of
> open source software.

>So this sounds like it might be a server variant instead of a live
>media? If NPO's are intended to use it to run services, I would think
>basing it off server and perhaps working on some server roles would be
>good here...

>Perhaps you meant that this would be good for NPO's users to use as a
>workstation to talk to their servers?

Excellent point. I will remove public services and revise this to focus on
workstations for office workstations and laptops.


>If this is a collection of packages, perhaps it would be as well served
>by having a group available of these packages? Then anyone could
>install those from any other Fedora install. Of course they would need
>to have network then...

Another good point. I am not familiar yet with creating collections of
packages for a spin, but can research this, thanks.



On Tue, Jun 23, 2015 at 4:23 PM, Kevin Fenzi  wrote:

> On Sun, 21 Jun 2015 18:52:18 -0400
> Corey Leong  wrote:
>
> > I refined the the Detailed Description [1] [2] per the questions
> > concerning the Fedora Spin development.
> >
> > Detailed Description
> > -
> >
> > Fedora Netizen is an open source operating system for enabling
> > internet citizens, also known as netizens, to engage online services
> > and communities. Fedora Netizen includes software packages for
> > focusing on civic engagement and internet safety features related to
> > security and privacy.
> >
> > Nonprofit Organizations and public agencies will benefit from Fedora
> > Netizen by switching to free open-source software (FOSS) for running
> > public services on the Internet. Fedora Netizen empowers netizens
> > with their online activism for changing the world with the help of
> > open source software.
>
> So this sounds like it might be a server variant instead of a live
> media? If NPO's are intended to use it to run services, I would think
> basing it off server and perhaps working on some server roles would be
> good here...
>
> Perhaps you meant that this would be good for NPO's users to use as a
> workstation to talk to their servers?
>
> If this is a collection of packages, perhaps it would be as well served
> by having a group available of these packages? Then anyone could
> install those from any other Fedora install. Of course they would need
> to have network then...
>
> > I removed the psychology topics since it seemed to be a bit confusing
> > to others which means users would also have been confused about the
> > spin. Regarding the listing of the packages, my intent is to simply
> > make users aware of what open source software is included in the spin
> > by categorizing the packages. I intend to include best practices,
> > how-to's, and other related documentation on a spin related website
> > for the user to configure and customize on their own after reading
> > documentation.
>
> ok.
>
> 
>
> 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
>



-- 
Corey Leong, M.N.M., M.A.*
PO Box 691871
Orlando, FL 32869

email: cle...@fedoraproject.org 
web: http://coreyleong.org
blog: http://blog.coreyleong.org
tweet: http://twitter.com/coreyleong
phone: (407) 279-1133
skype: coreyleong
-- 
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: F23 Self Contained Change: Netizen Spin

[Corey Leong]

Revised Detailed Description:

Fedora Netizen is an open source operating system for enabling internet
citizens, also known as netizens, to engage online services and
communities. Fedora Netizen includes software packages for focusing on
civic engagement and internet safety features related to cybersecurity and
online privacy.

Nonprofit Organizations and public agencies will benefit from Fedora
Netizen by switching to free open source software (FOSS) for running on
workstations and laptops. Fedora Netizen empowers netizens with their
online activism for changing the world with the help of open source
software.

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

https://fedoraproject.org/wiki/Netizen_Spin


On Tue, Jun 23, 2015 at 6:50 PM, Corey Leong 
wrote:

> Kevin --
>
> > Detailed Description
> > -
> >
> > Fedora Netizen is an open source operating system for enabling
> > internet citizens, also known as netizens, to engage online services
> > and communities. Fedora Netizen includes software packages for
> > focusing on civic engagement and internet safety features related to
> > security and privacy.
> >
> > Nonprofit Organizations and public agencies will benefit from Fedora
> > Netizen by switching to free open-source software (FOSS) for running
> > public services on the Internet. Fedora Netizen empowers netizens
> > with their online activism for changing the world with the help of
> > open source software.
>
> >So this sounds like it might be a server variant instead of a live
> >media? If NPO's are intended to use it to run services, I would think
> >basing it off server and perhaps working on some server roles would be
> >good here...
>
> >Perhaps you meant that this would be good for NPO's users to use as a
> >workstation to talk to their servers?
>
> Excellent point. I will remove public services and revise this to focus on
> workstations for office workstations and laptops.
>
>
> >If this is a collection of packages, perhaps it would be as well served
> >by having a group available of these packages? Then anyone could
> >install those from any other Fedora install. Of course they would need
> >to have network then...
>
> Another good point. I am not familiar yet with creating collections of
> packages for a spin, but can research this, thanks.
>
>
>
> On Tue, Jun 23, 2015 at 4:23 PM, Kevin Fenzi  wrote:
>
>> On Sun, 21 Jun 2015 18:52:18 -0400
>> Corey Leong  wrote:
>>
>> > I refined the the Detailed Description [1] [2] per the questions
>> > concerning the Fedora Spin development.
>> >
>> > Detailed Description
>> > -
>> >
>> > Fedora Netizen is an open source operating system for enabling
>> > internet citizens, also known as netizens, to engage online services
>> > and communities. Fedora Netizen includes software packages for
>> > focusing on civic engagement and internet safety features related to
>> > security and privacy.
>> >
>> > Nonprofit Organizations and public agencies will benefit from Fedora
>> > Netizen by switching to free open-source software (FOSS) for running
>> > public services on the Internet. Fedora Netizen empowers netizens
>> > with their online activism for changing the world with the help of
>> > open source software.
>>
>> So this sounds like it might be a server variant instead of a live
>> media? If NPO's are intended to use it to run services, I would think
>> basing it off server and perhaps working on some server roles would be
>> good here...
>>
>> Perhaps you meant that this would be good for NPO's users to use as a
>> workstation to talk to their servers?
>>
>> If this is a collection of packages, perhaps it would be as well served
>> by having a group available of these packages? Then anyone could
>> install those from any other Fedora install. Of course they would need
>> to have network then...
>>
>> > I removed the psychology topics since it seemed to be a bit confusing
>> > to others which means users would also have been confused about the
>> > spin. Regarding the listing of the packages, my intent is to simply
>> > make users aware of what open source software is included in the spin
>> > by categorizing the packages. I intend to include best practices,
>> > how-to's, and other related documentation on a spin related website
>> > for the user to configure and customize on their own after reading
>> > documentation.
>>
>> ok.
>>
>> 
>>
>> 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
>>
>
>
>
> --
> Corey Leong, M.N.M., M.A.*
> PO Box 691871
> Orlando, FL 32869
>
> email: cle...@fedoraproject.org 
> web: http://coreyleong.org
> blog: http://blog.coreyleong.org
> tweet: http://twitter.com/coreyleong
> phone: (407) 279-1133
> skype: coreyleong
>



-- 
Corey Leong, M.N.M., M.A.*
PO Box 691871
Orlando, FL 32869

email: cle...@fedoraproject.org 
we

F23 Self Contained Change: Local Test Cloud

[Jan Kurik]

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

Change owner(s):
* Mike Ruckman 
* Kushal Das 

testcloud 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:

   testcloud instance create  -u 

It currently supports only the Fedora Cloud Base image, and work is ongoing to 
support the Atomic host image. 

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

-- 
Jan Kuřík
___
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

F23 Self Contained Change: io.js Technology Preview

[Jan Kurik]

= Proposed Self Contained Change: io.js Technology Preview =
https://fedoraproject.org/wiki/Changes/iojs

Change owner(s): T.C. Hollingsworth 

io.js is an npm compatible platform originally based on Node.js™ that supports 
version 6 of the ECMAScript standard and additional features, developed with an 
open governance model. io.js will be offered as an optional replacement for 
`/usr/bin/node` on Fedora systems as a Technology Preview. node.js will remain 
the default implementation of `/usr/bin/node` in Fedora 23. 

== Detailed Description ==
io.js is an npm compatible platform originally based on Node.js™ that supports 
version 6 of the ECMAScript standard and additional features, developed with an 
open governance model. For more information about io.js and the differences 
between node.js, visit the io.js website.

io.js will support the same set of binary modules currently supported by 
node.js on Fedora. It is expected to be obsoleted by a future version of the 
`nodejs` package, as these two projects have announced their intention to merge.

We will support both parallel-installation of the iojs interpreter alongside 
the existing node.js interpreter, and permit replacement of `/usr/bin/node` 
with io.js in an additional package. All existing noarch nodejs-* packages will 
work with both interpreters. (Though obviously you'll have to specify iojs if 
you haven't installed it the /usr/bin/node support package.) Seperate nodejs-* 
and iojs-* will be provided for binary modules. 

== Scope ==
* Proposal owners:
  -- Package and build a special v8 package for io.js only.
  -- Package and build iojs
  -- Update nodejs guidelines for multiple interpreters
  -- Rebuild modules with above changes
  -- Anything that needs updates for Node.js 0.12 will need it for io.js too. 
* Other developers:
  -- Anything that needs updates for Node.js 0.12 will need it for io.js too. 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines:
  -- Updates to the node.js guidelines and packaging infrastructure to permit 
building binary modules for multiple interpreters will be necessary. (These are 
also necessary to allow for a nodejs010/nodejs012 split in EPEL, so will get 
done anyway.) 
* Trademark approval: N/A (not needed for this Change) 
-- 
Jan Kuřík
___
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

F23 Self Contained Change: npm 2

[Jan Kurik]

= Proposed Self Contained Change: npm 2 =
https://fedoraproject.org/wiki/Changes/npm2

Change owner(s): T.C. Hollingsworth 

Fedora 23 features npm 2, the latest version of the package manager for node.js 
and other JavaScript platforms. 

== Detailed Description ==
While npm 2 is a major version number update, it contains little in the way of 
major changes. The version bump was necessitated by an API change permitting 
arguments to be passed to scripts executed by `npm run`. Another major change 
is to the way 0.x.y versions are compared by the semver library used by npm. 
For more information on all the changes, see the upstream release announcement. 
There are few end-user facing changes, beyond the addition of a couple features 
to the CLI. 

== Scope ==
* Proposal owners:
  -- Update all of nodejs-* basically
  -- Update npm of course 
* Other developers:
  -- I might have to ask a couple other maintainers if they're okay with me 
updating their packages. They usually are.  :-) 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines:
  -- Some minor updates to the Node.js guidelines are planned, however they are 
just Nice To Have for the purposes of this specific change. 
* Trademark approval: N/A (not needed for this Change) 
-- 
Jan Kuřík
___
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

F23 System Wide Change: jQuery

[Jan Kurik]

= Proposed System Wide Change: jQuery =
https://fedoraproject.org/wiki/Changes/jQuery

Change owner(s): T.C. Hollingsworth 

jQuery is a fast, small, and feature-rich JavaScript library. It makes things 
like HTML document traversal and manipulation, event handling, animation, and 
Ajax much simpler with an easy-to-use API that works across a multitude of 
browsers. With a combination of versatility and extensibility, jQuery has 
changed the way that millions of people write JavaScript.

Traditionally, a copy of jQuery has been included with every web application 
that requires it. This change will migrate many of those applications to a 
shared system copy of jQuery. Both the 1.x branch of jQuery that supports 
Internet Explorer 6 and the 2.x branch of jQuery that only works with modern 
web browsers will be provided. 

== Detailed Description ==
Traditionally, a copy of jQuery has been included with every web application 
that requires it. This change will migrate many of those applications to a 
shared system copy of jQuery.

The following packages are available in Fedora 21 and later and EPEL 6 and 
later:

* js-jquery - The latest version of the jQuery 2.x branch, suitable for web 
applications that are only compatible with modern web browsers that fully 
support modern web standards.
* js-jquery1 - The latest version of the jQuery 1.x branch, suitable for web 
applications that endeavor to be compatible with older web browsers such as 
Internet Explorer 6.
* js-jquery-migrate - The jQuery migrate plugin, which is a compatibility shim 
that enables web applications that depend on older versions of jQuery to work 
with the latest version, so that they can be ported away from old, unsupported 
jQuery versions that may potentially have security issues. 

Some new packages are already beginning to use the system version of jQuery 
with little trouble, so for Fedora 23 we're going to open the doors to 
converting existing packages. We'll send announcements explaining how to 
unbundle existing packages. We'll also find all the packages we can that are 
bundling jQuery and inform maintainers about them, via e-mail only at this 
time. (We'll save the mass bug filing for F24 to allow maintainers to have a go 
at it voluntarily first.  :-) 

== Scope ==
* Migrating Web Applications
  -- Web applications that depend on modern versions of jQuery will simply be 
ported to use the systemwide version instead,
  -- Web applications that use older versions of jQuery (> 1.6.4 but <1.9) will 
be ported to use jquery-migrate and the systemwide version of jQuery. Packagers 
will be encouraged to work with upstream to migrate to the latest version of 
jQuery without jquery-migrate, since using this plugin re-enables misfeatures 
rightly removed from jQuery core that are XSS holes waiting to happen.
  -- Maintainers of web applications that use extremely old versions of jQuery 
(< 1.6.4) will be strongly encouraged to work with upstream to migrate to the 
latest versions of jQuery and update their packages. However, current Fedora 
policy regarding bundled libraries permits these packages to be grandfathered 
in, so I am unable to force any action here.
  -- Preliminary repoqueries have been performed to identify potentially 
affected packages, see the dependencies section for more details.

* Migrating documentation frameworks
  -- Certain documentation frameworks, such as python-sphinx, ship copies of 
jQuery as well. These frameworks will be modified to use a symlink or other 
means so that they too can use the new systemwide versions.

* Release Engineering
  -- No special attention required. 
-- 
Jan Kuřík
___
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

F23 Self Contained Change: Node.js 0.12

[Jan Kurik]

= Proposed Self Contained Change: Node.js 0.12 =
https://fedoraproject.org/wiki/Changes/NodeJS012

Change owner(s): T.C. Hollingsworth 

Fedora 23 will be updated to Node.js 0.12, the latest release of the platform 
built on Chrome's JavaScript runtime for easily building fast, scalable network 
applications. 

== Detailed Description ==
Node.js has seen many changes between v0.10 and v0.12. There is a listing of 
changes documented on the wiki. Note that this release includes API updates 
that may require dependency updates. Following are some highlights:

* Streams 3
The Streams implementation now works the way you thought it already 
should, without introducing any changes to the API. Basically this means no 
more getting stuck in "old mode", there are only streams that are flowing or 
not.
Streams now support the use of cork and uncork mechanisms to prevent 
flushing writes out to the system if an application is going to be performing 
many writes in a row. There is an implicit uncork performed when you end a 
writable stream. 

* HTTP
maxSockets are no longer limited to 5. The default is now set to 
Infinity with the developer and the operating system given control over how 
many simultaneous connections an application can keep open to a given host.
Proper KeepAlive support means that sockets will stay open until they 
timeout at the configured time, are closed by the remote side, or the process 
exits. Developer's no longer have to make sure requests have been pipelined to 
keep the socket open, or use an alternative module to get that support.
Developers can also now explicitly flushHeaders to ensure time to first 
byte is low and proxied connections are held open. 

* Cluster
Now has two modes of operation, the new default is a round robin 
distribution mechanism where the master accepts new connections and distributes 
them to your workers. If you want you can still opt back into the old method 
where your workers are responsible for acception connections. 

* TLS
We have the new TLSWrap mechanism under the hood, this eliminates quite 
a few of the hops back and forth between JavaScript and our C++ implementations.
Added APIs for asynchronous SNI callbacks, OCSP stapling, and storage 
events. 

* Buffer
We use a more accurate mechanism for allocating memory for buffers now, 
which means you'll see less overhead and impact from holding onto to small 
slices of Buffers. This reduces the amount of memory pressure on the system, 
which means GC runs are quicker, which means Node.js is on CPU less, and thus 
lower latency for your applications. 

* child_process
spawnSync/execSync have been added to facilitate synchronous child 
processes, warning your node process won't make forward progress while waiting 
for the child to exit, caveat emptor! 

* Crypto
Added APIs for loading custom engines for use with compiled in OpenSSL.
More APIs support supplying the pass phrases.
Added APIs for RSA public/private key encryption/decryption. 

* VM
The module is now based on the Contextify module, which shares values 
from the sandbox to avoid missing changes inside the execution from appearing 
in the parent context.
Initial support for ECMAScript Internationalization API 1.0 (ECMA-402)
By default, Node.js v0.12.0 binaries are shipped with ECMA-402 support, 
but only for the English language. In other words, the ECMA-402 API is working 
as you would expect, but only data for the English language is included. You 
can find more info on how to include more languages in the Wiki. 

These are just some of the changes you can find in this release of v0.12, and 
it's thanks to the hard work of the community and the members of team curating 
Node.js.

We are also pleased to report that this release of Node.js has tests passing on 
all of our supported platforms. On the one hand, this seems obvious (what are 
tests for if not to verify before you release it?!), but this is actually the 
first release of Node.js that has operated under this constraint. Requiring 
that all tests pass before releasing Node.js marks an important development for 
the project, and is essential for building a solid path moving forward. 

== Scope ==
* Proposal owners:
  -- Update v8
  -- Update nodejs
  -- Rebuild all binary modules, apply patches as necessary
  -- Update npm 
* Other developers:
  -- Other Node.js packagers' attention may be required if the update causes 
issues for their packages. 
* Release engineering: N/A (not a System Wide Change) 
* Policies and guidelines:
  -- Some minor updates to the Node.js guidelines are planned, however they are 
just Nice To Have for the purposes of this specific change. 
* Trademark approval: N/A (not needed for this Change) 
-- 
Jan Kuřík
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fe

Re: Btrfs as default filesystem for Fedora 23?

[Neal Gompa]

On Tue, Jun 23, 2015 at 4:20 PM, Stephen John Smoogen 
wrote:

> On 23 June 2015 at 14:15, Neal Gompa  wrote:
> > On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:
> >>
> >>
> >> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
> >>>
> >>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
> >>> becoming the default in Fedora 23
> >>>
> >>> . At this point, I'm personally convinced that it is certainly ready
> and
> >>> doable for F23.
> >>
> >>
> >> Well actually he said his "plan" was to push for F23.  I've been using
> >> btrfs raid 6 for several years now and have been lucky I haven't
> encountered
> >> any issues - but if you subscribe to the mailing list you'll see others
> >> haven't been quite as lucky.  I'm sure he'll propose it once he
> believes it
> >> is ready.  When proposing a default change it is prudent to be
> cautious. In
> >> the meantime it's there to use for early adopters; and the more people
> who
> >> test the faster issues will be identified and corrected.  Just be sure
> >> you've taken the proper precautions ;-)
> >>
> >>
> >> --
> >> devel mailing list
> >> devel@lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> > Certainly, but with none of the features in Btrfs actually emitting scary
> > "experimental" warnings anymore, and even all features working in btrfs
> RAID
> > 5/6 now, I think we should really start pushing it to more people. Or at
> > least develop some kind of test plan to prove the "worthiness" of using
> it
> > as default. We must have something, ne?
> >
>
> So if there are problems who is going to deal with the users, diagnose
> the issues and fix them? Those are going to be the people who will
> need to push for this feature if they think it is ready or not. I
> would start by finding out who they are, talking with them and then
> looking at what time frame they think the feature would be ready.
>
>
> --
> 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
>

​That is precisely why I'm asking on this list. I don't know who those
people are, and this is really the best place I know of to start contact
and those discussions.​


-- 
真実はいつも一つ！/ Always, there's only one truth!
-- 
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: Btrfs as default filesystem for Fedora 23?

[Stephen John Smoogen]

On 23 June 2015 at 18:40, Neal Gompa  wrote:
> On Tue, Jun 23, 2015 at 4:20 PM, Stephen John Smoogen 
> wrote:
>>
>> On 23 June 2015 at 14:15, Neal Gompa  wrote:
>> > On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox  wrote:
>> >>
>> >>
>> >> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa  wrote:
>> >>>
>> >>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>> >>> becoming the default in Fedora 23
>> >>>
>> >>> . At this point, I'm personally convinced that it is certainly ready
>> >>> and
>> >>> doable for F23.
>> >>
>> >>
>> >> Well actually he said his "plan" was to push for F23.  I've been using
>> >> btrfs raid 6 for several years now and have been lucky I haven't
>> >> encountered
>> >> any issues - but if you subscribe to the mailing list you'll see others
>> >> haven't been quite as lucky.  I'm sure he'll propose it once he
>> >> believes it
>> >> is ready.  When proposing a default change it is prudent to be
>> >> cautious. In
>> >> the meantime it's there to use for early adopters; and the more people
>> >> who
>> >> test the faster issues will be identified and corrected.  Just be sure
>> >> you've taken the proper precautions ;-)
>> >>
>> >>
>> >> --
>> >> devel mailing list
>> >> devel@lists.fedoraproject.org
>> >> https://admin.fedoraproject.org/mailman/listinfo/devel
>> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>> >
>> >
>> > Certainly, but with none of the features in Btrfs actually emitting
>> > scary
>> > "experimental" warnings anymore, and even all features working in btrfs
>> > RAID
>> > 5/6 now, I think we should really start pushing it to more people. Or at
>> > least develop some kind of test plan to prove the "worthiness" of using
>> > it
>> > as default. We must have something, ne?
>> >
>>
>> So if there are problems who is going to deal with the users, diagnose
>> the issues and fix them? Those are going to be the people who will
>> need to push for this feature if they think it is ready or not. I
>> would start by finding out who they are, talking with them and then
>> looking at what time frame they think the feature would be ready.
>
>
> That is precisely why I'm asking on this list. I don't know who those people
> are, and this is really the best place I know of to start contact and those
> discussions.
>
>

My apologies.. my tone was not helpful. You are correct that asking
here is where to start. I think the groups who would be able to help
answer would be

1. Kernel team
2. QA team
3. Anaconda team
4. Workstation/Server/Cloud or just one if it were to be only on one product.

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

Re: Btrfs as default filesystem for Fedora 23?

[M. Edward (Ed) Borasky]

On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa  wrote:

> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs RAID
> 5/6 now, I think we should really start pushing it to more people. Or at
> least develop some kind of test plan to prove the "worthiness" of using it
> as default. We must have something, ne?

Bingo! We need

a. Pass/fail performance criteria
b. Pass/fail data loss criteria
c. Pass/fail security criteria

and code to drive them all. My area of expertise is strictly
performance. I'd be happy to contribute tests and analysis, although I
suspect Phoronix may have everything needed.

Let's say a three-way bakeoff - btrfs, ext4 and xfs (since IIRC xfs is
a default in some RHEL configurations). Let me know if you want me to
resurrect any of my 2009 stuff on disk performance.
-- 
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-journalists

Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct