Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Gerald Henriksen 
On Thu, 30 Jun 2016 22:07:24 +0200, you wrote:

>On Thu, 30 Jun 2016 15:59:38 -0400
>Solomon Peachy  wrote:
>
>> On Thu, Jun 30, 2016 at 08:04:57PM +0100, Richard W.M. Jones wrote:
>> > I will just snipe here that the situation would be better if POWER
>> > > 4 hardware was generally available to buy.
>> 
>> The upcoming Raptor Talos POWER8 board [1] looks promising, but at
>> $3700 a pop just for the motherboard and an entry-level [1] CPU, it's
>> out of reach of many otherwise-interested developers.  Assuming it
>> goes into production at all..
>
>unfortunately it does not in foreseeable future (based on official
>update on their IRC channel). It was my hope to get newer workstation
>class HW and be able to lift the ppc64 (BE) support to Power7 and up
>(or so). With the OpenPOWER ecosystem there is still chance someone
>else will try it.

I wouldn't count on it.

To get developers they need to get a CPU/motherboard combination out
for under $1000, likely closer to $500, as these will be purchases as
a secondary system to "play with" because there is no direct way to
make money as a POWER developer (this also applies to Aarch64, which
is also looking rather absent).

At least for POWER8, this would likely mean someone from OpenPOWER
would need to fund the development of a affordable POWER8 chip with no
expectation of directly recouping that cost, which seems unlikely.

Which is a shame, because with more developers/users there might be
more volunteers for Fedora such that a specific POWER8 spin would
become viable, helping to solve the current problem.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Gerald Henriksen 
On Thu, 30 Jun 2016 18:01:38 +0200, you wrote:

>> Realistically, it isn't about either specifically.  Each iteration of
>> POWER tends to require tuning specifically for that generation if you
>> want to get the most performance out of your software.
>
>Latest CPU features get utilized mostly only in inner loops of high
>performance code which should use IFUNC.  So building the whole distro for the
>latest CPU brings only incompatibility with no real performance advantage.

When you spend the type of money that a POWER type system costs, you
expect to get every bit of benefit you can out of that system, and
that means everything from the OS on up will be expected to be
compiled for the version of POWER you are running.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Jason L Tibbitts III 
> "PL" == Petr Lautrbach  writes:

PL> (2) when a generator file was mislabeled it could not be run by
PL> systemd as systemd can't read fedora-relabel unit file now

Isn't it possible to detect that situation and simply force the relabel?

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

[OT] Tim, Gil, et. al. (e-mail address settings)

2016-06-30 Thread Joel Rees 
To keep this off-list as much as possible, the rant is here:

http://reiisi.blogspot.com/2016/07/to-gil-tim-fedora-et-al.html

(The blame lies elsewhere. I wish I had the network and social cred to
get a real movement started, away from the current faceless CA system
and towards a different identity assurance system that depends on
actual, existing day-to-day trust relationships.)
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Lennart Poettering 
On Thu, 30.06.16 22:27, Petr Lautrbach (plaut...@redhat.com) wrote:

> > SELinux is in Permissive mode during this time.
> 
> SELinux policy is loaded in systemd on very beginning so unless it's set
> to be permissive in the config file or on the kernel command line, a
> system is in enforcing mode until something - in this case a generator
> or an service generated by the generator - changes the mode.

As briefly mentioned in the other mail: the policy is loaded only when
the transition from the initrd to the host takes place. Generators are
run in two cases however: when the systemd instance included in the
initrd initializes, and when the systemd instance on the host image
takes over. A generator included in the initrd hence runs with selinux
still off, a generator on the host runs with selinux on.

I'd propose to put together a generator that is included in the initrd
(and also exists on the host). When running in from initrd context it
should check the autorelabel boot flag, and somehow ensure that
selinux stays off even after the transition (not sure if selinux has
some concept for that, but it shouldn't be hard to come up with
something). When running from host context it should check the flags
too, and redirect the boot process.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Lennart Poettering 
On Thu, 30.06.16 21:23, Petr Lautrbach (plaut...@redhat.com) wrote:

> I like the idea that the relabeling will be isolated in a special
> target. And we've recently moved fedora-selinux.service to
> policycoreutils so it could live there.
> 
> However, it won't probably fix the following problems:
> 
> (2) when a generator file was mislabeled it could not be run by systemd
> as systemd can't read fedora-relabel unit file now

All that's necessary is that somehow SELinux is automatically booted
into permissive mode if the autorelabel cmdline option/flag file
exists, and this could be implemented either in libselinux or even in
said generator as long as the generator is also packaged up into the
initrd, and thus can run from there, i.e. *before* the selinux policy
is loaded and put into effect.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Updated hdf5, netcdf, libdap coming to rawhide tomorrow

2016-06-30 Thread Orion Poplawski 
On 06/29/2016 05:08 PM, Orion Poplawski wrote:
> On 06/28/2016 04:59 PM, Orion Poplawski wrote:
>> I'll be updating hdf5, netcdf, and libdap in rawhide tomorrow and doing
>> rebuilds of dependent packages.
>>
> 
> Well, as typical, running into issues with openmpi on arm.  Investigating.
> 

Looks like MPI_Abort() can hang on arm sometimes in certain as yet unknown
conditions.  Disable tests for now and built.  Dependent packages are building
now, many done.  May have an issue with octave on 32-bit as well, we'll see.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Petr Lautrbach 
On 06/30/2016 09:52 PM, Richard W.M. Jones wrote:
> On Thu, Jun 30, 2016 at 09:23:45PM +0200, Petr Lautrbach wrote:
>> On 06/30/2016 06:13 PM, Lennart Poettering wrote:
>>> On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:
>>>
>> Insert your idea here …
>
> Do it the same way `dnf system-upgrade` works. The requirements (having 
> local filesystem read- and writable) are quite similar. Or the way 
> PackageKit's system upgrade works…
> probably the same as (b) though…

 This s something I agree with, the system should have an autorelabel
 target that is one-shot just like the system upgrades, and it should
 bring up really the minimal system required to boot and mount the
 filesystem to be relabeled and nothing else, it should work in
 permissive mode and possibly with auditing enabled.
>>>
>>> Yeah, I agree. My suggestion would be for SELinux to provide a systemd
>>> "Generator" tool (see systemd.generator(7) for details) that checks
>>> for the auorelabel flag file or kernel comand line option and then
>>> diverts the boot into a special relabel target that pulls in
>>> local-fs.target and very little else, then does its relabelling and
>>> reboots again. During all of this selinux should be in permissive
>>> mode, after all the labels are generally borked if you boot into this
>>> mode, and hence not suitable for making security decisions.
>>>
>>> Pretty much all of that should live in some selinux package I figure.
>>>
>>
>> I like the idea that the relabeling will be isolated in a special
>> target. And we've recently moved fedora-selinux.service to
>> policycoreutils so it could live there.
>>
>> However, it won't probably fix the following problems:
>>
>> (2) when a generator file was mislabeled it could not be run by systemd
>> as systemd can't read fedora-relabel unit file now
>>
>> Unless we want to loosen the policy to allow systemd read file with any
>> file context, it will be up to a administrator to set a permissive mode
>> via the kernel command line
> 
> I think Lennart's idea still works because he is suggesting that
> SELinux is in Permissive mode during this time.

SELinux policy is loaded in systemd on very beginning so unless it's set
to be permissive in the config file or on the kernel command line, a
system is in enforcing mode until something - in this case a generator
or an service generated by the generator - changes the mode.


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Problem with exact provides in pre-release version

2016-06-30 Thread Marcin Zajączkowski 
On 2016-06-30 04:27, Ahmad Samir wrote:
> On 30 June 2016 at 01:21, Marcin Zajączkowski  wrote:
>>
>> Hi,
>>
>> I'm a maintainer of NetworkManager-sstp package and before 1.2.0 final
>> will be released I experimenting in my CORP repo with pre-release Git
>> version. I've encountered a situation which - I'm not sure - is a
>> problem with my configuration or some issue with dependencies resolving.
>>
>> $ sudo dnf install NetworkManager-sstp-gnome
>> Error: nothing provides NetworkManager-sstp(x86-64) =
>> 1.2.0-0.20160514git86c2737d.fc24 needed by
>> NetworkManager-sstp-gnome-1:1.2.0-0.20160514git86c2737d.fc24.x86_64
>> (try to add '--allowerasing' to command line to replace conflicting
>> packages)
>>
>> While already installed corresponding NetworkManager-sstp reports:
>> $ rpm -q --provides NetworkManager-sstp
>> NetworkManager-sstp = 1:1.2.0-0.20160514git86c2737d.fc24
>> NetworkManager-sstp(x86-64) = 1:1.2.0-0.20160514git86c2737d.fc24
>> config(NetworkManager-sstp) = 1:1.2.0-0.20160514git86c2737d.fc24
>>
>> I don't know why I have that error - NetworkManager-sstp seems to
>> provide what is needed.
>>
>> In the SPEC file I have (for NetworkManager-sstp-gnome):
>>> Requires: NetworkManager-sstp%{?_isa} = %{version}-%{release}
>>
> 
> You should add the epoch to the requires:
> Requires: NetworkManager-sstp%{?_isa} = %{epoch}:%{version}-%{release}

That was the reason. Thanks for a tip!

Marcin

-- 
http://blog.solidsoft.info/ - Working code is not enough
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Dan Horák 
On Thu, 30 Jun 2016 15:59:38 -0400
Solomon Peachy  wrote:

> On Thu, Jun 30, 2016 at 08:04:57PM +0100, Richard W.M. Jones wrote:
> > I will just snipe here that the situation would be better if POWER
> > > 4 hardware was generally available to buy.
> 
> The upcoming Raptor Talos POWER8 board [1] looks promising, but at
> $3700 a pop just for the motherboard and an entry-level [1] CPU, it's
> out of reach of many otherwise-interested developers.  Assuming it
> goes into production at all..

unfortunately it does not in foreseeable future (based on official
update on their IRC channel). It was my hope to get newer workstation
class HW and be able to lift the ppc64 (BE) support to Power7 and up
(or so). With the OpenPOWER ecosystem there is still chance someone
else will try it.


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

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Solomon Peachy 
On Thu, Jun 30, 2016 at 08:04:57PM +0100, Richard W.M. Jones wrote:
> I will just snipe here that the situation would be better if POWER > 4
> hardware was generally available to buy.

The upcoming Raptor Talos POWER8 board [1] looks promising, but at $3700 
a pop just for the motherboard and an entry-level [1] CPU, it's out of 
reach of many otherwise-interested developers.  Assuming it goes into 
production at all..

  [1] https://www.raptorengineering.com/TALOS/
  [2] Insofar as an 8-core/64-thread CPU can be called entry-level

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
Delray Beach, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Richard W.M. Jones 
On Thu, Jun 30, 2016 at 09:23:45PM +0200, Petr Lautrbach wrote:
> On 06/30/2016 06:13 PM, Lennart Poettering wrote:
> > On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:
> > 
>  Insert your idea here …
> >>>
> >>> Do it the same way `dnf system-upgrade` works. The requirements (having 
> >>> local filesystem read- and writable) are quite similar. Or the way 
> >>> PackageKit's system upgrade works…
> >>> probably the same as (b) though…
> >>
> >> This s something I agree with, the system should have an autorelabel
> >> target that is one-shot just like the system upgrades, and it should
> >> bring up really the minimal system required to boot and mount the
> >> filesystem to be relabeled and nothing else, it should work in
> >> permissive mode and possibly with auditing enabled.
> > 
> > Yeah, I agree. My suggestion would be for SELinux to provide a systemd
> > "Generator" tool (see systemd.generator(7) for details) that checks
> > for the auorelabel flag file or kernel comand line option and then
> > diverts the boot into a special relabel target that pulls in
> > local-fs.target and very little else, then does its relabelling and
> > reboots again. During all of this selinux should be in permissive
> > mode, after all the labels are generally borked if you boot into this
> > mode, and hence not suitable for making security decisions.
> > 
> > Pretty much all of that should live in some selinux package I figure.
> > 
> 
> I like the idea that the relabeling will be isolated in a special
> target. And we've recently moved fedora-selinux.service to
> policycoreutils so it could live there.
> 
> However, it won't probably fix the following problems:
> 
> (2) when a generator file was mislabeled it could not be run by systemd
> as systemd can't read fedora-relabel unit file now
> 
> Unless we want to loosen the policy to allow systemd read file with any
> file context, it will be up to a administrator to set a permissive mode
> via the kernel command line

I think Lennart's idea still works because he is suggesting that
SELinux is in Permissive mode during this time.

> (5) the relabeling service will still need to have StandardInput=tty to
> provide a possibility to relabel a system manually

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://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Petr Lautrbach 
On 06/30/2016 06:13 PM, Lennart Poettering wrote:
> On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:
> 
 Insert your idea here …
>>>
>>> Do it the same way `dnf system-upgrade` works. The requirements (having 
>>> local filesystem read- and writable) are quite similar. Or the way 
>>> PackageKit's system upgrade works…
>>> probably the same as (b) though…
>>
>> This s something I agree with, the system should have an autorelabel
>> target that is one-shot just like the system upgrades, and it should
>> bring up really the minimal system required to boot and mount the
>> filesystem to be relabeled and nothing else, it should work in
>> permissive mode and possibly with auditing enabled.
> 
> Yeah, I agree. My suggestion would be for SELinux to provide a systemd
> "Generator" tool (see systemd.generator(7) for details) that checks
> for the auorelabel flag file or kernel comand line option and then
> diverts the boot into a special relabel target that pulls in
> local-fs.target and very little else, then does its relabelling and
> reboots again. During all of this selinux should be in permissive
> mode, after all the labels are generally borked if you boot into this
> mode, and hence not suitable for making security decisions.
> 
> Pretty much all of that should live in some selinux package I figure.
> 

I like the idea that the relabeling will be isolated in a special
target. And we've recently moved fedora-selinux.service to
policycoreutils so it could live there.

However, it won't probably fix the following problems:

(2) when a generator file was mislabeled it could not be run by systemd
as systemd can't read fedora-relabel unit file now

Unless we want to loosen the policy to allow systemd read file with any
file context, it will be up to a administrator to set a permissive mode
via the kernel command line


(5) the relabeling service will still need to have StandardInput=tty to
provide a possibility to relabel a system manually


Petr
-- 
Petr Lautrbach




signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Richard W.M. Jones 
On Thu, Jun 30, 2016 at 12:12:37PM +0200, Dan Horák wrote:
> For ppc64 (the big endian POWER) the base is set by the toolchain
> default which is Power4/ppc970. When Power7 came we were asked what are
> the options to take the advantage of these CPUs, 3 generations newer
> than the base. The solution was the introduction of ppc64p7 subarch into
> the packaging and release engineering tools. But it showed more as a
> hack than a solution, touching rpm, yum, koji,  The list of packages
> is manually maintained, requires manual updates to the buildsystem for
> new releases, seems new packaging tools (dnf) don't understand it
> correctly. Is there a way to make the subarch mechanism generic and
> integrated with the other tools? So we could have ppc64p8 and ppc64p9
> inside Fedora for POWER ...

I will just snipe here that the situation would be better if POWER > 4
hardware was generally available to buy.

> Now I'm getting to an area where others are the experts :-) Glibc
> allows to build and install multiple per-cpu optimized runtimes that
> are selected based on the CPU. There is the IFUNC mechanism and
> function multi-versioning in GCC (user-friendly IFUNC) [2] to allow
> multiple implementations inside one library/binary.

Be careful with using IFUNC.  It's a very desirable feature,
implemented in a somewhat ill-defined way:

https://bugzilla.redhat.com/show_bug.cgi?id=1312462#c22
https://bugzilla.redhat.com/show_bug.cgi?id=1312462#c27
  etc.

Have you looked at what Debian does with the /lib/ directories?
I think we should follow Debian if appropriate.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Josh Boyer 
On Thu, Jun 30, 2016 at 12:01 PM, Jan Kratochvil
 wrote:
> On Thu, 30 Jun 2016 16:13:59 +0200, Josh Boyer wrote:
>> On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil  
>> wrote:
>> > But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>> >>=Power8 hardware does use ppc64le which is already Power8 optimized.
>> > So isn't this problem (somehow temporarily) solved for now?
>>
>> POWER8 can run in either endian mode.  So no, the problem is not solved.
>
> End-users do not even know what is endianity.  And all application developers
> need to write software BE/LE-independently (such as using ntohl()/htonl()
> etc.) so they also do not care whether the host is BE or LE.  Only <1% of
> developers for high performance core or very low-end libraries (like glibc or
> glib) need to care about BE/LE.
>
> So why to run Power8 in BE?  Power is switching to LE AFAIK which makes it
> also better compatible with buggy software ignoring BE/LE difference which is
> (as all the software) targeting primarily x86* (=LE).

It isn't switching.  It's adding.  I'd maybe agree that LE will become
more prevalent over time, particularly as it is used in cloud
workloads.  However, BE mode isn't going away anytime soon.

>> Realistically, it isn't about either specifically.  Each iteration of
>> POWER tends to require tuning specifically for that generation if you
>> want to get the most performance out of your software.
>
> Latest CPU features get utilized mostly only in inner loops of high
> performance code which should use IFUNC.  So building the whole distro for the
> latest CPU brings only incompatibility with no real performance advantage.
>
>
> At least this is my expectation, the OP misses any real benchmark numbers
> whether the distro build for the latest CPU generation is worth it.
> IIRC for x86* it was not worth it.

You might not be wrong, but you're dismissing the market dynamics of
POWER that I mentioned.  Those same dynamics lead to the distribution
components for ppc64 being built as 64-bit binaries, even though at
the time 32-bit binaries for 99% of packages were actually more than
sufficient.

Comparing performance numbers within POWER is fine, but applying the
"this is how we do it in x86" logic isn't really suitable.  They are
different markets.  I believe the markets will perhaps merge over
time, but they clearly haven't yet today.

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

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

2016-06-30 Thread Jason L Tibbitts III 
> "JR" == Jaroslav Reznik  writes:

JR> * Proposal owners: Prepare a draft for the Fedora Packaging
JR>   Guidelines for Python

Please open a ticket with FPC sooner rather than later, even if the
draft isn't ready/started.

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

Re: Looking for a proven packager

2016-06-30 Thread Christopher 
On Thu, Jun 30, 2016 at 4:35 AM Peter Robinson  wrote:

> On Thu, Jun 30, 2016 at 9:30 AM, Igor Gnatenko 
> wrote:
> > First thing you should do is to send your patch upstream. If upstream
> > will say "it's good patch", I will help you to get it in Fedora before
> > upstream will release new version. Unfortunately it's not possible in
> > other way.
>
> In the hadoop case it might not be valid to do that as the version in
> Fedora is quite out of date compared to upstream.
>
>
Fedora's version may be out of date, but I suspect that this particular
part of Hadoop's code is not fast moving, and would still be relevant to
even their latest versions. At the very least, it's worth an attempt to
contact them upstream first.

I do have an interest in updating Fedora's packaged version of Hadoop, and
if the patch is good, it'd be nice to have it in upstream so we don't have
to keep it around when we move to the newer version. So, even if they
aren't willing to support the patch for our version, if they're willing to
support it in any of their latest supported versions, I'd be fine keeping
the backported patch until we upgrade.

As I said in the BZ, I just don't have the expertise to evaluate the patch
myself to know if it's good or if it's going to cause problems. A +1 from
upstream, a proven packager, or the secondary arch team, would be
sufficient for me.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Lennart Poettering 
On Thu, 30.06.16 10:45, Simo Sorce (s...@redhat.com) wrote:

> > > Insert your idea here …
> > 
> > Do it the same way `dnf system-upgrade` works. The requirements (having 
> > local filesystem read- and writable) are quite similar. Or the way 
> > PackageKit's system upgrade works…
> > probably the same as (b) though…
> 
> This s something I agree with, the system should have an autorelabel
> target that is one-shot just like the system upgrades, and it should
> bring up really the minimal system required to boot and mount the
> filesystem to be relabeled and nothing else, it should work in
> permissive mode and possibly with auditing enabled.

Yeah, I agree. My suggestion would be for SELinux to provide a systemd
"Generator" tool (see systemd.generator(7) for details) that checks
for the auorelabel flag file or kernel comand line option and then
diverts the boot into a special relabel target that pulls in
local-fs.target and very little else, then does its relabelling and
reboots again. During all of this selinux should be in permissive
mode, after all the labels are generally borked if you boot into this
mode, and hence not suitable for making security decisions.

Pretty much all of that should live in some selinux package I figure.

Lennart

-- 
Lennart Poettering, Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Peter Robinson 
On Thu, Jun 30, 2016 at 5:01 PM, Jan Kratochvil
 wrote:
> On Thu, 30 Jun 2016 16:13:59 +0200, Josh Boyer wrote:
>> On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil  
>> wrote:
>> > But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>> >>=Power8 hardware does use ppc64le which is already Power8 optimized.
>> > So isn't this problem (somehow temporarily) solved for now?
>>
>> POWER8 can run in either endian mode.  So no, the problem is not solved.
>
> End-users do not even know what is endianity.  And all application developers
> need to write software BE/LE-independently (such as using ntohl()/htonl()
> etc.) so they also do not care whether the host is BE or LE.  Only <1% of
> developers for high performance core or very low-end libraries (like glibc or
> glib) need to care about BE/LE.
>
> So why to run Power8 in BE?  Power is switching to LE AFAIK which makes it
> also better compatible with buggy software ignoring BE/LE difference which is
> (as all the software) targeting primarily x86* (=LE).

Data conversion is expensive, slow and problematic so once it's in one
format it tends to stay that way. There's also legacy/proprietary
tools that run as big endian on the Power64 platform. For a new
deployment there's no reason not to do it as LE from the outset, and
migration from other LE platforms makes sense but if you're in a BE
world (AIX, Solaris, Z-series and friends) it makes sense to run in
BE.

There are some applications where the data comes in in BE format and
it's costly to deal with that in real time, especially in high
throughput scenarios.

>> Realistically, it isn't about either specifically.  Each iteration of
>> POWER tends to require tuning specifically for that generation if you
>> want to get the most performance out of your software.
>
> Latest CPU features get utilized mostly only in inner loops of high
> performance code which should use IFUNC.  So building the whole distro for the
> latest CPU brings only incompatibility with no real performance advantage.

We're looking at IFUNC as one option, Function multi-versioning in GCC
6 [1] is presumably also another option, although wouldn't be useful
for already released enterprise releases, although obviously
irrelevant for the Fedora conversation.

> At least this is my expectation, the OP misses any real benchmark numbers
> whether the distro build for the latest CPU generation is worth it.
> IIRC for x86* it was not worth it.


[1] https://lwn.net/Articles/691932/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Jan Kratochvil 
On Thu, 30 Jun 2016 16:13:59 +0200, Josh Boyer wrote:
> On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil  
> wrote:
> > But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
> >>=Power8 hardware does use ppc64le which is already Power8 optimized.
> > So isn't this problem (somehow temporarily) solved for now?
> 
> POWER8 can run in either endian mode.  So no, the problem is not solved.

End-users do not even know what is endianity.  And all application developers
need to write software BE/LE-independently (such as using ntohl()/htonl()
etc.) so they also do not care whether the host is BE or LE.  Only <1% of
developers for high performance core or very low-end libraries (like glibc or
glib) need to care about BE/LE.

So why to run Power8 in BE?  Power is switching to LE AFAIK which makes it
also better compatible with buggy software ignoring BE/LE difference which is
(as all the software) targeting primarily x86* (=LE).


> Realistically, it isn't about either specifically.  Each iteration of
> POWER tends to require tuning specifically for that generation if you
> want to get the most performance out of your software.

Latest CPU features get utilized mostly only in inner loops of high
performance code which should use IFUNC.  So building the whole distro for the
latest CPU brings only incompatibility with no real performance advantage.


At least this is my expectation, the OP misses any real benchmark numbers
whether the distro build for the latest CPU generation is worth it.
IIRC for x86* it was not worth it.


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

Re: autoconf test for deprecated readdir_r

2016-06-30 Thread Daniel P. Berrange 
On Thu, Jun 30, 2016 at 11:30:38AM -0400, Kaleb KEITHLEY wrote:
> 
> Hi,
> 
> Does anyone have a good/working autoconf test for checking for
> deprecated readdir_r (for Fedora 25) ?
> 
> I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
> things.)
> 
> Alternatively it would be nice if there was a some kind of feature test
> define in dirent.h.

Why bother testing for it at all. There was never any real compelling
reason to want to use readdir_r, given that it was less portable and
normal readdir() is perfectly safe to use if you have one DIR* per
thread. So given that you'll need to adapt the code to use readdir
anyway, there's little point keeping a conditional codepath to use
readdir_r IMHO.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: autoconf test for deprecated readdir_r

2016-06-30 Thread Florian Weimer 

On 06/30/2016 05:38 PM, Zdenek Kabelac wrote:


Cut & paste example code solution from lvm2:

#if !defined(__GLIBC__) || (__GLIBC__ < 2) || ((__GLIBC__ == 2) &&
(__GLIBC_MINOR__ < 23))
/* readdir_r is deprecated with newer GLIBC */
struct dirent entry, *iter = 0;
while ( (errno = readdir_r( d.d, &entry, &iter )) == 0 && iter ) {
std::string ename( entry.d_name );
#else
struct dirent *entry;
errno = 0;
while ( (entry = readdir( d.d )) ) {
std::string ename( entry->d_name );
#endif


Why not use readdir unconditionally?

The point of the deprecation was that readdir is much more portable than 
readir_r.  Stack allocation of struct dirent is not supported; the above 
has a buffer overflow in the d_name field on many systems.


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

Re: autoconf test for deprecated readdir_r

2016-06-30 Thread Zdenek Kabelac 

Dne 30.6.2016 v 17:30 Kaleb KEITHLEY napsal(a):


Hi,

Does anyone have a good/working autoconf test for checking for
deprecated readdir_r (for Fedora 25) ?

I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
things.)

Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.




Cut & paste example code solution from lvm2:

#if !defined(__GLIBC__) || (__GLIBC__ < 2) || ((__GLIBC__ == 2) && 
(__GLIBC_MINOR__ < 23))

/* readdir_r is deprecated with newer GLIBC */
struct dirent entry, *iter = 0;
while ( (errno = readdir_r( d.d, &entry, &iter )) == 0 && iter ) {
std::string ename( entry.d_name );
#else
struct dirent *entry;
errno = 0;
while ( (entry = readdir( d.d )) ) {
std::string ename( entry->d_name );
#endif


No need for autoconf

Regards

Zdenek

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

Re: fedora-packager installs yum

2016-06-30 Thread Orion Poplawski 
On 06/30/2016 04:34 AM, Dennis Gilmore wrote:
> On Wednesday, June 29, 2016 10:42:36 AM CDT Raphael Groner wrote:
>> There's a controversial ongoing discussion. f-e-k needs a port to Python 3.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1329629
>> https://bugzilla.redhat.com/show_bug.cgi?id=1024796
>> https://bugzilla.redhat.com/show_bug.cgi?id=1270600
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 
> I was not sure what f-e-k is but after reading the bugs you have it 
> backwards. 
> the packaging tools are all python2 currently due to at teh least koji not 
> being ported to python3. fedora-packager does not pull in fedora-easy-karma,  
> but fedora-easy-karma uses parts of fedora-packager.  yum will be required 
> for 
> many years yet due to mock, additionally koji imports yum, that will have to 
> change in order for koji to move to python3.  If people want to help get 
> everything ported and running on python3 the help will be more than welcome. 
> however yum will still get pulled in until epel7 is EOL.
> 
> Dennis

I suppose the dependency on yum could be demoted to a Recommends in Fedora for
those packagers who have no interest in EPEL and really don't want yum
installed on their system for some reason.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

autoconf test for deprecated readdir_r

2016-06-30 Thread Kaleb KEITHLEY 

Hi,

Does anyone have a good/working autoconf test for checking for
deprecated readdir_r (for Fedora 25) ?

I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
things.)

Alternatively it would be nice if there was a some kind of feature test
define in dirent.h.

Thanks,

--

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

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Peter Robinson 
On Thu, Jun 30, 2016 at 2:53 PM, Jan Kratochvil
 wrote:
> On Thu, 30 Jun 2016 12:12:37 +0200, Dan Horák wrote:
>> For ppc64 (the big endian POWER) the base is set by the toolchain
>> default which is Power4/ppc970. When Power7 came we were asked what are
>> the options to take the advantage of these CPUs, 3 generations newer
>> than the base. The solution was the introduction of ppc64p7 subarch
>
> But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>>=Power8 hardware does use ppc64le which is already Power8 optimized.
> So isn't this problem (somehow temporarily) solved for now?
>
> Or are really the Power7 (and not yet Power8) machines the real problem?

No your confusing endian with CPU features. We support both Big Endian
(ppc64) and Little Endian (ppc64le) options for the Power64
architecture. Both can run on Power8 hardware, in fact the builder VMs
run like with with both BE and LE VMs running on the same physical
Power8 host side by. There's shortly going to also be Power9 [1] with
options that need optimisation to make the most of new architectural
enhancements which will be primarily focused towards ppc64le (but will
also work on ppc64) but we don't want to exclude Power8 from ppc64le.

Peter

[1] 
http://www.nextplatform.com/2016/04/18/power9-will-bring-competition-datacenter-compute/
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Modularity] Modularization wiki moved to "Modularity"

2016-06-30 Thread Petr Šabata 
On Thu, Jun 30, 2016 at 07:12:23AM -0400, Stephen Gilson wrote:
> The Modularization wiki formerly found at
> https://fedoraproject.org/wiki/Modularization has been moved to
> "Modularity" as part of an effort to consolidate terminology.
> 
> This includes the subpages:
> https://fedoraproject.org/wiki/Modularity/Infra
> /Modularity/Developer_Notes
> /Modularity/Getting_involved
> /Modularity/FAQ
> 
> https://fedoraproject.org/wiki/Modularity
> 
> Redirects to the new locations are in place for all moved pages. However,
> if you have any links to the old URLs, please update.

Thank you!
P


signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Simo Sorce 
On Thu, 2016-06-30 at 07:34 +, Christian Stadelmann wrote:
> > It should be possible to touch /.autorelabel and have the SELinux
> > labels on the filesystem fixed at next boot.
> 
> […]
> 
> > (a) Configure /etc/selinux/config to set SELinux permissive, and
> > modify the fedora-autorelabel.service so it edits /etc/selinux/config
> > to re-enable SELinux next time.  This editing would have to be
> > conditional, and the details are up in the air.  Maybe there could be
> > a "/.autorelabel-enforce-after-boot" file to do this?
> 
> Setting SELinux to permissive (even for a very short time) seems risky to me. 
> I'd rather not do that.

You may not have an option, if the labeling is broken, starting in
enforcing may mean you never get to relabel the filesystem as the
relabeling tool may fail to start altogether.

> > Insert your idea here …
> 
> Do it the same way `dnf system-upgrade` works. The requirements (having local 
> filesystem read- and writable) are quite similar. Or the way PackageKit's 
> system upgrade works…
> probably the same as (b) though…

This s something I agree with, the system should have an autorelabel
target that is one-shot just like the system upgrades, and it should
bring up really the minimal system required to boot and mount the
filesystem to be relabeled and nothing else, it should work in
permissive mode and possibly with auditing enabled.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Josh Boyer 
On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil
 wrote:
> On Thu, 30 Jun 2016 12:12:37 +0200, Dan Horák wrote:
>> For ppc64 (the big endian POWER) the base is set by the toolchain
>> default which is Power4/ppc970. When Power7 came we were asked what are
>> the options to take the advantage of these CPUs, 3 generations newer
>> than the base. The solution was the introduction of ppc64p7 subarch
>
> But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>>=Power8 hardware does use ppc64le which is already Power8 optimized.
> So isn't this problem (somehow temporarily) solved for now?

POWER8 can run in either endian mode.  So no, the problem is not solved.

> Or are really the Power7 (and not yet Power8) machines the real problem?

Realistically, it isn't about either specifically.  Each iteration of
POWER tends to require tuning specifically for that generation if you
want to get the most performance out of your software.  That tuning is
incompatible with older generations of hardware (endian completely
aside).  So as Dan alludes to, this is fairly cumbersome.  To make it
widely useable, you default to the oldest generation you want to
support.

x86 theoretically has similar problems, but we tend to just not care
as much about tuning at the distro level.  The applications can tune
however they'd like, but given that most datacenters are not
homogeneous among x86 machines, it often means people cannot tune for
one specific x86 generation because they have to run on a wider
variety.

Contrast that with POWER, where people using that tend to buy one or
two very large systems to consolidate their workload on.  They can and
often do want the best performance they can eek out since they're
consolidating, which means they often want the distro components tuned
as well, particularly system libraries.

Going forward, I'd seriously look at dropping anything older than
POWER7 support.  I know we all dearly love our Mac G5 machines
(ppc970), but those are getting very very old at this point.  POWER5
was a non-event for Fedora, POWER6 was a weird generation even for
IBM.  POWER7 and POWER8 are where most of the effort is, and that will
only continue as next generation POWER chips come out.  Given that
Rackspace and others have actually started using the openPOWER stuff
with POWER8, it probably makes sense to focus on where the users are
headed and not where they were 10 years ago.

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

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Jan Kratochvil 
On Thu, 30 Jun 2016 12:12:37 +0200, Dan Horák wrote:
> For ppc64 (the big endian POWER) the base is set by the toolchain
> default which is Power4/ppc970. When Power7 came we were asked what are
> the options to take the advantage of these CPUs, 3 generations newer
> than the base. The solution was the introduction of ppc64p7 subarch

But now there is ppc64le for >=Power8.  So <=Power7 can use ppc64 but newer
>=Power8 hardware does use ppc64le which is already Power8 optimized.
So isn't this problem (somehow temporarily) solved for now?

Or are really the Power7 (and not yet Power8) machines the real problem?


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

Fedora Rawhide-20160630.n.0 compose check report

2016-06-30 Thread Fedora compose checker 
Missing expected images:

Workstation live i386
Cloud_base raw-xz i386
Atomic raw-xz x86_64
Kde raw-xz armhfp
Minimal raw-xz armhfp
Workstation live x86_64

Failed openQA tests: 13/78 (x86_64), 2/16 (i386)

ID: 24230   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/24230
ID: 24233   Test: x86_64 Atomic-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/24233
ID: 24234   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/24234
ID: 24235   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/24235
ID: 24251   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/24251
ID: 24264   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/24264
ID: 24284   Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/24284
ID: 24285   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/24285
ID: 24286   Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/24286
ID: 24287   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/24287
ID: 24296   Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/24296
ID: 24299   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/24299
ID: 24309   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/24309
ID: 24318   Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24318
ID: 24319   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/24319

Passed openQA tests: 58/78 (x86_64), 14/16 (i386)

Skipped openQA tests: 5 of 94
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

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

It's awesome that this is finally going to make it into Fedora.
However, I strongly advise you have the --majorver-provides enabled
along with the default one, because that way, spec files can be
written in such a way that they can have BuildRequires that aren't
specific to a minor version of Python. The dependency generator
*always* uses the pythonX.Ydist(CANONICAL_NAME) format for generated
dependencies. The addition of pythonXdist(CANONICAL_NAME) Provides
just makes it easier to have BuildRequires for them so that mass
changes for spec files aren't required on every Y version bump.


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

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

And two missing links :)

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

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

F25 System Wide Change: Automatic Provides for Python RPM Packages

2016-06-30 Thread Jaroslav Reznik 
= Proposed System Wide Change: Automatic Provides for Python RPM Packages =
https://fedoraproject.org/wiki/Changes/
Automatic_Provides_for_Python_RPM_Packages

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

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

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

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

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

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

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

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

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

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

* Trademark approval: Not needed for this Change

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

Fedora rawhide compose report: 20160630.n.0 changes

2016-06-30 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20160629.n.0
NEW: Fedora-Rawhide-20160630.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  5
Dropped packages:0
Upgraded packages:   77
Downgraded packages: 0

Size of added packages:  8.28 MiB
Size of dropped packages:0.00 B
Size of upgraded packages:   673.38 MiB
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   -9.83 MiB
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =
Image: Docker_Base docker armhfp
Path: Docker/armhfp/images/Fedora-Docker-Base-Rawhide-20160630.n.0.armhfp.tar.xz
Image: Docker_Base docker x86_64
Path: Docker/x86_64/images/Fedora-Docker-Base-Rawhide-20160630.n.0.x86_64.tar.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160630.n.0.iso
Image: SoaS live i386
Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160630.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: geteltorito-0.6-3.fc25
Summary: El Torito boot image extractor
RPMs:geteltorito
Size:17042 bytes

Package: mlt-6.2.0-2.fc25
Summary: Toolkit for broadcasters, video editors, media players, transcoders
RPMs:mlt mlt-devel mlt-python mlt-ruby
Size:8236916 bytes

Package: perl-Module-Install-Copyright-0.009-1.fc25
Summary: Package a COPYRIGHT file with a distribution
RPMs:perl-Module-Install-Copyright
Size:31186 bytes

Package: python-geoip2-2.4.0-1.fc25
Summary: MaxMind GeoIP2 API
RPMs:python-geoip2-doc python2-geoip2 python3-geoip2
Size:319650 bytes

Package: python-qrencode-0-1.git.a58d28a.fc25
Summary: A simple wrapper for the C qrencode
RPMs:python2-qrencode python3-qrencode
Size:77232 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  BackupPC-3.3.1-4.fc25
Old package:  BackupPC-3.3.1-3.fc24
Summary:  High-performance backup system
RPMs: BackupPC
Size: 1274742 bytes
Size change:  -3172 bytes
Changelog:
  * Wed Jun 29 2016 Benjamin Lefoul  - 3.3.1-4
  - Support for systemd and tmpfiles for RHEL >= 7


Package:  activemq-5.6.0-17.fc25
Old package:  activemq-5.6.0-16.fc25
Summary:  Open source messaging and Integration Patterns server
RPMs: activemq activemq-core activemq-jaas activemq-javadoc 
activemq-kahadb
Size: 6046102 bytes
Size change:  -568 bytes
Changelog:
  * Wed Jun 29 2016 gil cattaneo  5.6.0-17
  - add missing build requires


Package:  ansible-lint-3.1.0-1.fc25
Old package:  ansible-lint-3.0.1-2.fc25
Summary:  Best practices checker for Ansible
RPMs: ansible-lint
Size: 42750 bytes
Size change:  1852 bytes
Changelog:
  * Wed Jun 29 2016 Parag Nemade  - 3.1.0-1
  - Fixed typo in previous changelog entry


Package:  armadillo-7.200.2-1.fc25
Old package:  armadillo-7.200.1-1.fc25
Summary:  Fast C++ matrix library with interfaces to LAPACK and ATLAS
RPMs: armadillo armadillo-devel
Size: 3777892 bytes
Size change:  599140 bytes
Changelog:
  * Wed Jun 29 2016 Jos?? Matos  - 7.200.2-1
  - update to 7.200.2


Package:  brltty-5.4-1.fc25
Old package:  brltty-5.3.1-8.fc25
Summary:  Braille display driver for Linux/Unix
RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs 
brltty-espeak brltty-speech-dispatcher brltty-xw ocaml-brlapi python-brlapi 
python3-brlapi tcl-brlapi
Size: 7082718 bytes
Size change:  44060 bytes
Changelog:
  * Wed Jun 29 2016 Jaroslav ??karvada  - 5.4-1
  - New version
Resolves: rhbz#1350990
  - Dropped xw-fonts-fix and async-wait patches (both upstreamed)


Package:  btrfs-sxbackup-0.6.9-1.fc25
Old package:  btrfs-sxbackup-0.6.8-1.fc25
Summary:  Incremental btrfs snapshot backups with push/pull support via SSH
RPMs: btrfs-sxbackup
Size: 62466 bytes
Size change:  196 bytes
Changelog:
  * Tue Jun 28 2016 Till Hofmann  - 0.6.9-1
  - Update to 0.6.9


Package:  chkconfig-1.8-1.fc25
Old package:  chkconfig-1.7-2.fc24
Summary:  A system tool for maintaining the /etc/rc*.d hierarchy
RPMs: chkconfig ntsysv
Size: 670088 bytes
Size change:  -4136 bytes
Changelog:
  * Wed Jun 29 2016 Luk Nykr??n  - 1.8-1
  - alternatives: introduce --keep-missing
  - alternatives: allow family in --set and display it in --config
  - chkconfig: use isXinetdEnabled instead of isOn
  - leveldb: trim leading whitespaces from systemctl
  - leveldb: suppress error messages when selinux is turned off
  - alternatives: always recreate symlinks when the alternative is updated
  - test-alternatives: basic tests for slave links
  - chkconfig: resetpriorities should work on all runlevels


Package:  cmake-3.6.0-0.1.rc4.fc25
Old package:  cmake-3.5.2-3.fc25
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-gui
Size: 28804800 bytes
Size change:  431512 bytes
Changelog:
  * Wed Jun 29 2016 Orion Poplawski  - 3.6.0-0.1.rc4
  - Update to 3.6.0-rc4


Pack

[Modularity] Modularization wiki moved to "Modularity"

2016-06-30 Thread Stephen Gilson 
The Modularization wiki formerly found at
https://fedoraproject.org/wiki/Modularization has been moved to
"Modularity" as part of an effort to consolidate terminology.

This includes the subpages:
https://fedoraproject.org/wiki/Modularity/Infra
/Modularity/Developer_Notes
/Modularity/Getting_involved
/Modularity/FAQ

https://fedoraproject.org/wiki/Modularity

Redirects to the new locations are in place for all moved pages. However,
if you have any links to the old URLs, please update.


-- 

Stephen Gilson, Sr. Content Strategist, Platform documentation
Customer Content Services
Red Hat, Inc.

As a [user role], I want to [goal], so I can [reason]
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: fedora-packager installs yum

2016-06-30 Thread Dennis Gilmore 
On Wednesday, June 29, 2016 10:42:36 AM CDT Raphael Groner wrote:
> There's a controversial ongoing discussion. f-e-k needs a port to Python 3.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1329629
> https://bugzilla.redhat.com/show_bug.cgi?id=1024796
> https://bugzilla.redhat.com/show_bug.cgi?id=1270600
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

I was not sure what f-e-k is but after reading the bugs you have it backwards. 
the packaging tools are all python2 currently due to at teh least koji not 
being ported to python3. fedora-packager does not pull in fedora-easy-karma,  
but fedora-easy-karma uses parts of fedora-packager.  yum will be required for 
many years yet due to mock, additionally koji imports yum, that will have to 
change in order for koji to move to python3.  If people want to help get 
everything ported and running on python3 the help will be more than welcome. 
however yum will still get pulled in until epel7 is EOL.

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

Re: fedora-packager installs yum

2016-06-30 Thread Dennis Gilmore 
On Wednesday, June 29, 2016 1:27:46 AM CDT Christopher wrote:
> Installing fedora-packager pulls in yum as a dependency. Is this expected
> on a system built around dnf and without yum already installed?

yes it is expected and will continue to be the case for years to come,  why? 
mock, we will always use yum to make the epel 5, 6 and 7 chroots.

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

multi-CPU optimization inside a distribution

2016-06-30 Thread Dan Horák 
Hi all,

we were talking about this item for some time, so let's start a thread
for it to have the discussion and hopefully also a solution documented.
This is meant as discussion initiation based on the situation in
Fedora on POWER. I would like to ask the bigger experts than me to fill
the missing details and options.

Currently we set a minimal CPU level for an architecture (or use the
toolchain default) on the distribution level
(/usr/lib/rpm/redhat/rpmpc owned by redhat-rpm-config [1]). It allows
the distro to run on such CPU and any newer evolution of it (omitting
any kernel or hw issues), but it also means it doesn't generally take
advantage of features and improvements in the newer CPUs.

For ppc64 (the big endian POWER) the base is set by the toolchain
default which is Power4/ppc970. When Power7 came we were asked what are
the options to take the advantage of these CPUs, 3 generations newer
than the base. The solution was the introduction of ppc64p7 subarch into
the packaging and release engineering tools. But it showed more as a
hack than a solution, touching rpm, yum, koji,  The list of packages
is manually maintained, requires manual updates to the buildsystem for
new releases, seems new packaging tools (dnf) don't understand it
correctly. Is there a way to make the subarch mechanism generic and
integrated with the other tools? So we could have ppc64p8 and ppc64p9
inside Fedora for POWER ...

Now I'm getting to an area where others are the experts :-) Glibc
allows to build and install multiple per-cpu optimized runtimes that
are selected based on the CPU. There is the IFUNC mechanism and
function multi-versioning in GCC (user-friendly IFUNC) [2] to allow
multiple implementations inside one library/binary.

Some packages do the CPU detection during runtime and select the
optimized functions themselves.

There is also an option to introduce a "tertiary architecture" and
rebuild everything for the new CPU, but keeping the rpm arch the same.
But it has its own costs too.

What do you think? Are there any recommendations for both the distro
and package maintainers and upstream developers? I suppose even primary
architectures are facing the same problem.

[1] http://pkgs.fedoraproject.org/cgit/rpms/redhat-rpm-config.git/tree/rpmrc
[2] https://lwn.net/Articles/691932/


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

Re: Gnome-shell crash with Nvidia drivers (fix available but not in Fedora 24 it seems)

2016-06-30 Thread jack smith 
Thanks !
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Anyone know how to contact maintainer Salimma?

2016-06-30 Thread Haïkel 
2016-06-30 4:59 GMT+02:00 Avram Lubkin :
>
> I've been trying to contact Salimma, Michel Alexandre Salim, for the last
> month. I've been trying to update python-sphinx which hasn't had an update
> since last fall. Worked through all of the issues, but maintainer hasn't
> responded to commit request, email, or bug reports.
>
> Bug report for newest version of Sphinx with needinfo flag.
> https://bugzilla.redhat.com/show_bug.cgi?id=1323202
>
> Anyone have any info?
>

I see builds from him june, 8 in Koji so he shouldn't be far away.
Meanwhile, you can send me your patch or add it in the bugzilla and
I'll apply it in rawhide as provenpackager.


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

Re: Looking for a proven packager

2016-06-30 Thread Peter Robinson 
On Thu, Jun 30, 2016 at 9:14 AM, Mattias Ellert
 wrote:
> Hi!
>
> I submitted a bugzilla report with a patch that implements an
> improvement of the hadoop package in Fedora, extending the current
> incomplete Fedora integration patch that only supports ix86 and x86_64
> to more architectures. The maintainer is unwilling to apply it, but
> says that if a proven packager would apply it he would be extatic.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1328076
>
> Since I am not a proven packager myself, I am looking for one that can
> perform this task.

I've asked the secondary arch team to take a look.

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

Re: Looking for a proven packager

2016-06-30 Thread Peter Robinson 
On Thu, Jun 30, 2016 at 9:30 AM, Igor Gnatenko  wrote:
> First thing you should do is to send your patch upstream. If upstream
> will say "it's good patch", I will help you to get it in Fedora before
> upstream will release new version. Unfortunately it's not possible in
> other way.

In the hadoop case it might not be valid to do that as the version in
Fedora is quite out of date compared to upstream.

> Also there are some comments from random guys about code quality.
>
> On Thu, Jun 30, 2016 at 10:14 AM, Mattias Ellert
>  wrote:
>> Hi!
>>
>> I submitted a bugzilla report with a patch that implements an
>> improvement of the hadoop package in Fedora, extending the current
>> incomplete Fedora integration patch that only supports ix86 and x86_64
>> to more architectures. The maintainer is unwilling to apply it, but
>> says that if a proven packager would apply it he would be extatic.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1328076
>>
>> Since I am not a proven packager myself, I am looking for one that can
>> perform this task.
>>
>> Mattias
>>
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>
>
>
> --
> -Igor Gnatenko
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Looking for a proven packager

2016-06-30 Thread Igor Gnatenko 
First thing you should do is to send your patch upstream. If upstream
will say "it's good patch", I will help you to get it in Fedora before
upstream will release new version. Unfortunately it's not possible in
other way.

Also there are some comments from random guys about code quality.

On Thu, Jun 30, 2016 at 10:14 AM, Mattias Ellert
 wrote:
> Hi!
>
> I submitted a bugzilla report with a patch that implements an
> improvement of the hadoop package in Fedora, extending the current
> incomplete Fedora integration patch that only supports ix86 and x86_64
> to more architectures. The maintainer is unwilling to apply it, but
> says that if a proven packager would apply it he would be extatic.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1328076
>
> Since I am not a proven packager myself, I am looking for one that can
> perform this task.
>
> Mattias
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



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

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-30 Thread Daniel P. Berrange 
On Thu, Jun 30, 2016 at 10:21:18AM +0200, Michal Schmidt wrote:
> On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > The change to introduce a qemu-binfmt package has small upgrade
> > implications since anyone with qemu-user installed today, will loose
> > the binary format rules unless they manually install qemu-binfmt.
> 
> Not if you add "Obsoletes: qemu-user < V-R" (where V-R is the first
> version-release that contains this change) to both qemu-binfmt and qemu-user.

Oh, nice tip, thanks.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

2016-06-30 Thread Michal Schmidt 
On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> The change to introduce a qemu-binfmt package has small upgrade
> implications since anyone with qemu-user installed today, will loose
> the binary format rules unless they manually install qemu-binfmt.

Not if you add "Obsoletes: qemu-user < V-R" (where V-R is the first
version-release that contains this change) to both qemu-binfmt and qemu-user. 

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

Looking for a proven packager

2016-06-30 Thread Mattias Ellert 
Hi!

I submitted a bugzilla report with a patch that implements an
improvement of the hadoop package in Fedora, extending the current
incomplete Fedora integration patch that only supports ix86 and x86_64
to more architectures. The maintainer is unwilling to apply it, but
says that if a proven packager would apply it he would be extatic.

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

Since I am not a proven packager myself, I am looking for one that can
perform this task.

Mattias


smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

2016-06-30 Thread Florian Weimer 

On 06/30/2016 09:34 AM, Christian Stadelmann wrote:

Setting SELinux to permissive (even for a very short time) seems risky to me. 
I'd rather not do that.


Is it really substantially more risky than blindly relabeling the file 
system?


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

Re: Fixing /.autorelabel

2016-06-30 Thread Christian Stadelmann 
> It should be possible to touch /.autorelabel and have the SELinux
> labels on the filesystem fixed at next boot.

[…]

> (a) Configure /etc/selinux/config to set SELinux permissive, and
> modify the fedora-autorelabel.service so it edits /etc/selinux/config
> to re-enable SELinux next time.  This editing would have to be
> conditional, and the details are up in the air.  Maybe there could be
> a "/.autorelabel-enforce-after-boot" file to do this?

Setting SELinux to permissive (even for a very short time) seems risky to me. 
I'd rather not do that.

> Insert your idea here …

Do it the same way `dnf system-upgrade` works. The requirements (having local 
filesystem read- and writable) are quite similar. Or the way PackageKit's 
system upgrade works…
probably the same as (b) though…
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org