Re: multi-CPU optimization inside a distribution

[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

[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

[389-devel] Re: Logging performance improvement

[William Brown]

On Thu, 2016-06-30 at 20:53 -0600, Rich Megginson wrote:
> On 06/30/2016 08:14 PM, William Brown wrote:
> > On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:
> >> On 06/30/2016 07:52 PM, William Brown wrote:
> >>> Hi,
> >>>
> >>> I've been thinking about this for a while, so I decided to dump my
> >>> thoughts to a document. I think I won't get to implementing this for a
> >>> while, but it would really help our server performance.
> >>>
> >>> http://www.port389.org/docs/389ds/design/logging-performance-improvement.html
> >> Looks good.  Can we quantify the current log overhead?
> > Sure, I could probably sit down and work out a way to bench mark
> > this .
> >
> > But without the alternative being written, hard to say. I could always
> > patch out logging and drop the lock in a hacked build so we can show
> > what "without logging contention" looks like?
> 
> That's only one part of it - you'd have to figure out some way to get 
> rid of the overhead of the formatting and flushing in the operation 
> threads too.
> 

This change would move the formatting into the thread that does the
write + flush. 

Currently, we format the message in the operation thread, and send it to
the log buffer, and every now and again, an "unlucky" operation thread
has to stall to write the buffer  

However, I'm proposing we send unformatted time struct + unformatted
message to the queue, then the actual thread which is separate does the
dequeue and format. 

> I suppose you could just write it and see what happens.

Well, a hacked up test that has slapi_log_access return 0 immediately
(IE does not take the lock) showed a 6% performance improvement on my
laptop. On a higher cpu count system, this would exceed that number
easily, as more cpus == more cost to acquire the lock. 

I've put the numbers on the design doc page, but I think with this, the
proof would be in the implementation. We also likely wouldn't see the
benefit of this as much until we remove other serialisation points in
the code IE ldbm vs lmdb, plugins that take locks, etc. So it's only a
6% possible gain now, but it may be 10% or more in the future in
combination with other efforts such as nunc-stans.

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

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: Fixing /.autorelabel

[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

[389-devel] Re: Logging performance improvement

[Rich Megginson]

On 06/30/2016 08:14 PM, William Brown wrote:

On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:

On 06/30/2016 07:52 PM, William Brown wrote:

Hi,

I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.

http://www.port389.org/docs/389ds/design/logging-performance-improvement.html

Looks good.  Can we quantify the current log overhead?

Sure, I could probably sit down and work out a way to bench mark
this .

But without the alternative being written, hard to say. I could always
patch out logging and drop the lock in a hacked build so we can show
what "without logging contention" looks like?


That's only one part of it - you'd have to figure out some way to get 
rid of the overhead of the formatting and flushing in the operation 
threads too.


I suppose you could just write it and see what happens.





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


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



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



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

[EPEL-devel] Fedora EPEL 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 750  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-1626   
puppet-2.7.26-1.el5
 599  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 242  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 214  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a17af8c368   
drupal7-7.44-1.el5
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8b221b73a3   
wordpress-4.5.3-1.el5
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-98e2625a6f   
phpMyAdmin4-4.0.10.16-1.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

python-simplevisor-1.2-1.el5

Details about builds:



 python-simplevisor-1.2-1.el5 (FEDORA-EPEL-2016-3feb658662)
 Python simple daemons supervisor

Update Information:

Update to upstream version.

References:

  [ 1 ] Bug #1351066 - python-simplevisor-1.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1351066

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

[389-devel] Re: Logging performance improvement

[William Brown]

On Thu, 2016-06-30 at 20:01 -0600, Rich Megginson wrote:
> On 06/30/2016 07:52 PM, William Brown wrote:
> > Hi,
> >
> > I've been thinking about this for a while, so I decided to dump my
> > thoughts to a document. I think I won't get to implementing this for a
> > while, but it would really help our server performance.
> >
> > http://www.port389.org/docs/389ds/design/logging-performance-improvement.html
> 
> Looks good.  Can we quantify the current log overhead?

Sure, I could probably sit down and work out a way to bench mark
this . 

But without the alternative being written, hard to say. I could always
patch out logging and drop the lock in a hacked build so we can show
what "without logging contention" looks like? 

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

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Re: Replication after full online init

[William Brown]

On Thu, 2016-06-30 at 14:53 -0700, Noriko Hosoi wrote:
> On 06/30/2016 12:45 AM, Ludwig Krispenz wrote:
> > Hi William,
> >
> > the reason that after  a total init the consumer does not have the 
> > latest state of the supplier RUV and is receiving updates based on the 
> > RUV at start of the total init is independent of the modrdn problem. 
> > When a supplier is performing a total init it is still accepting 
> > changes, the total init can take a while and there are scenarios where 
> > an entry which is already sent is updated before total init finishes. 
> > We cannot loose these changes.
> OK...  Then, RUV needs to be created at the time when the supplier 
> starts online init?
> 
> The test case would be something like this?
> 1. run online init on the supplier.
> 2. do some operation like move entries against the supplier while the 
> online init is still running on the consumer.
> 3. do some operation which depends upon the previous operation done in 
> the step 2.
> 4. check the consumer is healthy or not.
> 
> Isn't it a timestamp issue from which operation should be replayed after 
> the total update?  Regardless of the way how to fix 48755, unless the 
> step 2 operation(s) are replayed after the online init is done, the 
> consumer could get broken/inconsistent?
> 

It's not the "post init" operations I'm worried about.

It's that operations that were part of the init to the consumer are
replayed from the changelog. 

Operations that occurred after the init starts, definitely still need to
be replayed, and this makes sense.

Lets say we have:

1 - insert A
2 - insert ou=B
3 - modrdn A under ou=B
4 - insert C
xx <<-- We start to transmit the data here.
5 - modrdn C


Once the online init is complete, the master replays the log from event
1 -> 5 to the consumer, even though it should now be up to date at
position 4.

Previously we could not guarantee this because in the scenario above, A
would have sorted before ou=B, by would not be able to be applied
because the consumer hadn't seen B yet. So after the init, the consumer
would have B and C, but not A, so we had to replay 1 -> 4 to fix this
up.

So I am suggesting that when we begin the online init we set the RUV of
the consumer to match the CSN of the master at the moment we begin the
transmission of data, so that we only need to replay event 5+, rather
than 1->5+

Does that make sense? 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[389-devel] Re: Logging performance improvement

[Rich Megginson]

On 06/30/2016 07:52 PM, William Brown wrote:

Hi,

I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.

http://www.port389.org/docs/389ds/design/logging-performance-improvement.html


Looks good.  Can we quantify the current log overhead?




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



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

[389-devel] Logging performance improvement

[William Brown]

Hi,

I've been thinking about this for a while, so I decided to dump my
thoughts to a document. I think I won't get to implementing this for a
while, but it would really help our server performance.

http://www.port389.org/docs/389ds/design/logging-performance-improvement.html

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

[Bug 1351821] perl-Inline-Python-0.50 is available

[bugzilla]

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



--- Comment #3 from Upstream Release Monitoring 
 ---
Patches were not touched. All were applied properly

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1351821] perl-Inline-Python-0.50 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
Created attachment 1174773
  --> https://bugzilla.redhat.com/attachment.cgi?id=1174773=edit
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1351821] perl-Inline-Python-0.50 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Patching or scratch build for perl-Inline-Python-0.49 failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[Bug 1351821] New: perl-Inline-Python-0.50 is available

[bugzilla]

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

Bug ID: 1351821
   Summary: perl-Inline-Python-0.50 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Inline-Python
  Keywords: FutureFeature, Triaged
  Assignee: j.k.nil...@usit.uio.no
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: j.k.nil...@usit.uio.no,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.50
Current version/release in rawhide: 0.49-5.fc25
URL: http://search.cpan.org/dist/Inline-Python/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6873/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

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

[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

[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

[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

[Bug 1351172] perl.req gets exponentially slow in a certain scenario

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-generators-1.06-2.fc22 has been pushed to the Fedora 22 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-c345d41682

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 479  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 242  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 108  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-785fc9a2ea   
dropbear-2016.72-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-c57f2c7e47   
drupal7-7.44-1.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d3e4c82ed7   
squidGuard-1.4-26.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-3126135a39   
wordpress-4.5.3-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cd7ade5b28   
phpMyAdmin-4.4.15.7-1.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e0c08a1414   
php-PHPMailer-5.2.16-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ce0d3be037   
gsi-openssh-6.6.1p1-4.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a01cdab420   
nodejs-ws-1.1.1-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

BackupPC-3.3.1-4.el7
PyQt4-webkit-4.10.1-2.el7
ReviewBoard-2.5.6.1-1.el7
jabberd-2.4.0-2.el7
nfdump-1.6.15-2.el7
nodejs-ws-1.1.1-1.el7
python-simplevisor-1.2-1.el7
qgit-2.6-2.el7
the_silver_searcher-0.32.0-1.el7

Details about builds:



 BackupPC-3.3.1-4.el7 (FEDORA-EPEL-2016-8e3110a7ad)
 High-performance backup system

Update Information:

Support for systemd and tmpfiles for RHEL >= 7

References:

  [ 1 ] Bug #1337984 - BackupPC expects /var/run/BackupPC to exist which 
doesn't after a reboot
https://bugzilla.redhat.com/show_bug.cgi?id=1337984
  [ 2 ] Bug #1240170 - Unable to start BackupPC due to missing /var/run/BackupPC
https://bugzilla.redhat.com/show_bug.cgi?id=1240170
  [ 3 ] Bug #1342138 - Bernard Johnson, please respond.
https://bugzilla.redhat.com/show_bug.cgi?id=1342138




 PyQt4-webkit-4.10.1-2.el7 (FEDORA-EPEL-2016-b07a6cd1d9)
 Python bindings for Qt4 Webkit

Update Information:

fix rhbz#1294304, pyuic4 generates Python code with broken import

References:

  [ 1 ] Bug #1294304 - Missing files in PyQt4-webkit cause pyuic4 to generate 
Python code with broken import
https://bugzilla.redhat.com/show_bug.cgi?id=1294304




 ReviewBoard-2.5.6.1-1.el7 (FEDORA-EPEL-2016-ecf6492798)
 Web-based code review tool

Update Information:

https://www.reviewboard.org/docs/releasenotes/reviewboard/2.5.6.1/




 jabberd-2.4.0-2.el7 (FEDORA-EPEL-2016-85e0b3ae41)
 OpenSource server implementation of the Jabber protocols

Update Information:

This is LARGE REBASE to the current upstream. PLEASE, do test thoroughly!

References:

  [ 1 ] Bug #647101 - jabberd.spec does not use conditional build support macros
https://bugzilla.redhat.com/show_bug.cgi?id=647101
  [ 2 ] Bug #1319226 - incorrect use of Requires(pre)?
https://bugzilla.redhat.com/show_bug.cgi?id=1319226




 nfdump-1.6.15-2.el7 (FEDORA-EPEL-2016-db0d77c4ce)
 NetFlow collecting and processing tools

Update Information:

Remove superfluous debug output.

References:

  [ 1 ] Bug #1350764 - nfdump built with debug output enabled
https://bugzilla.redhat.com/show_bug.cgi?id=1350764




 nodejs-ws-1.1.1-1.el7 (FEDORA-EPEL-2016-a01cdab420)
 Web socket client, server and 

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

[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

[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

[EPEL-devel] Re: epel7 comps.xml lists wrong package for util-linux

[Kevin Fenzi]

On Thu, 30 Jun 2016 11:09:15 +0300
Tuomo Soini  wrote:

> I noticed a issue in epel7 comps.
> 
> buildsys-build group includes util-linux-ng while on rhel7 package is
> util-linux and util-linux doesn't even provide util-linux-ng - that
> causes packages requiring software from util-linux to fail in mock
> build.
> 
> Could somebody with access fix this issue asap?
> 

Good catch. 

PR filed: 

https://pagure.io/fedora-comps/pull-request/30

kevin


pgp0PDGF4_l7F.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Re: Problem with exact provides in pre-release version

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[389-devel] please review: Ticket48907 - admin server - register-ds-admin.pl fails to find local config DS

[Mark Reynolds]

https://fedorahosted.org/389/ticket/48907

https://fedorahosted.org/389/attachment/ticket/48907/0001-Ticket-48907-register-ds-admin-fails-to-find-local-c.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org

Re: autoconf test for deprecated readdir_r

[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

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

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

[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

[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

rpmgrill in taskotron

[Kamil Paral]

Hey Ralph (ccing qa-devel),

just to let you know, I added some code to Koji directive to download build 
logs. The patch is posted here:
https://phab.qadevel.cloud.fedoraproject.org/D916
(you can use 'arch patch D916' to apply the diff in your libtaskotron checkout)

The corresponding changes for task-rpmgrill are in feature/buildlog branch:
https://bitbucket.org/fedoraqa/task-rpmgrill/branch/feature/buildlog

I could have implemented shuffling the build.log files around in 
run_rpmgrill.py, but it seemed easier to have it in a bash script. I moved all 
the rpmgrill* commands in there as well, and used our new bash directive to 
execute it (it still has rough edges, we're working on that). But having it in 
a bash script is not necessary, if you prefer to do it all in python, we 
definitely don't have to merge the code as it is :)

I also removed your failsafe decorator, but again, it's just a suggestion. The 
first reason was that since I moved most of the setup code and rpmgrill 
execution into the bash directive, the decorator didn't have any affect on it 
anyway. The second reason is that we seem to be of an opinion that ResultsDB 
should only contain real results (passed, failed), and crashes and similar 
execution statuses should be only present in ExecDB [1] (which, however, cannot 
be searched yet). This is all up to discussion, and our current solutions have 
a lot of rough edges, so if you want to continue sending CRASHED to ResultsDB 
in case of errors, we have no problem with it, and we can convert task-rpmgrill 
once we're 100% sure how we want things to look like and have it implemented 
properly. Please note, though, that we currently receive emails for all tests 
that crash hard, so we will be able to spot any task-rpmgrill issues even if 
not wrapped in the failsafe decorator.

If you have any questions or concerns, please ask :)

Cheers,
Kamil

[1] https://taskotron.fedoraproject.org/execdb/
___
qa-devel mailing list
qa-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org

Re: multi-CPU optimization inside a distribution

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

[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

[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

[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

[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

[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

[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

[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

[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

[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 <l...@fedoraproject.org> - 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 <punto...@libero.it> 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 <jama...@fedoraproject.org> - 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 <jskar...@redhat.com> - 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 <hofm...@kbsg.rwth-aachen.de> - 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 <lnyk...@redhat.com> - 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: cm

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.20-2.fc24.x86_64 requires libperl.so.5.22()(64bit)
perl-Data-Alias-1.20-2.fc24.x86_64 requires perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Data-Alias-1.20-2.fc24.i686 requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.i686 requires perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Data-Alias-1.20-2.fc24.armv7hl requires libperl.so.5.22
perl-Data-Alias-1.20-2.fc24.armv7hl requires perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

Broken dependencies: perl-Algorithm-Permute

[buildsys]

perl-Algorithm-Permute has broken dependencies in the rawhide tree:
On x86_64:
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
libperl.so.5.22()(64bit)
perl-Algorithm-Permute-0.12-21.fc24.x86_64 requires 
perl(:MODULE_COMPAT_5.22.1)
On i386:
perl-Algorithm-Permute-0.12-21.fc24.i686 requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.i686 requires 
perl(:MODULE_COMPAT_5.22.1)
On armhfp:
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires libperl.so.5.22
perl-Algorithm-Permute-0.12-21.fc24.armv7hl requires 
perl(:MODULE_COMPAT_5.22.1)
Please resolve this as soon as possible.

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

[Modularity] Modularization wiki moved to "Modularity"

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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

[Bug 1351354] amavisd-new: additional systemd hardening

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
amavisd-new-2.11.0-3.fc24 has been submitted as an update to Fedora 24.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-34df18001a

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

Looking for a proven packager

[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

jorti pushed to amavisd-new (f24). "Mandatory Perl build-requires added "

[notifications]

From 134d56bda25853ef1689b8608715c595237fe377 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Fri, 24 Jun 2016 10:48:20 +0200
Subject: Mandatory Perl build-requires added
 

---
 amavisd-new.spec | 1 +
 1 file changed, 1 insertion(+)

diff --git a/amavisd-new.spec b/amavisd-new.spec
index a265df0..773db38 100644
--- a/amavisd-new.spec
+++ b/amavisd-new.spec
@@ -31,6 +31,7 @@ Patch2: amavisd-condrestart.patch
 Patch3: amavisd-new-2.8.0-init_network.patch
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  perl-generators
 BuildRequires:  systemd
 Recommends: clamav-server-systemd
 Requires:   tmpwatch
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/amavisd-new.git/commit/?h=f24=134d56bda25853ef1689b8608715c595237fe377
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

jorti pushed to amavisd-new (f24). "Additional systemd hardening (RHBZ#1351354)"

[notifications]

From 6d3d0c2d8bb7d82f8e01e945180e45f0f68fef75 Mon Sep 17 00:00:00 2001
From: Juan Orti Alcaine 
Date: Thu, 30 Jun 2016 09:03:24 +0200
Subject: Additional systemd hardening (RHBZ#1351354)

---
 amavis-mc.service| 4 +++-
 amavisd-clean-quarantine.service | 4 +++-
 amavisd-clean-tmp.service| 4 +++-
 amavisd-new.spec | 5 -
 amavisd-snmp-zmq.service | 4 +++-
 amavisd-snmp.service | 4 +++-
 amavisd.service  | 3 +++
 7 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/amavis-mc.service b/amavis-mc.service
index 4dcdc1d..04241b9 100644
--- a/amavis-mc.service
+++ b/amavis-mc.service
@@ -13,7 +13,9 @@ ExecStart=/usr/sbin/amavis-mc -P 
/var/run/amavisd/amavis-mc.pid
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd-clean-quarantine.service b/amavisd-clean-quarantine.service
index 2bb8b3f..10bb01e 100644
--- a/amavisd-clean-quarantine.service
+++ b/amavisd-clean-quarantine.service
@@ -8,5 +8,7 @@ Group=amavis
 PrivateTmp=true
 PrivateDevices=true
 PrivateNetwork=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 ExecStart=/usr/sbin/tmpwatch -d 720 /var/spool/amavisd/quarantine
diff --git a/amavisd-clean-tmp.service b/amavisd-clean-tmp.service
index 70fcffc..9a64b0d 100644
--- a/amavisd-clean-tmp.service
+++ b/amavisd-clean-tmp.service
@@ -8,5 +8,7 @@ Group=amavis
 PrivateTmp=true
 PrivateDevices=true
 PrivateNetwork=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 ExecStart=/usr/sbin/tmpwatch 24 /var/spool/amavisd/tmp
diff --git a/amavisd-new.spec b/amavisd-new.spec
index 773db38..0207fe9 100644
--- a/amavisd-new.spec
+++ b/amavisd-new.spec
@@ -3,7 +3,7 @@
 Summary:Email filter with virus scanner and spamassassin support
 Name:   amavisd-new
 Version:2.11.0
-Release:2%{?prerelease:.%{prerelease}}%{?dist}
+Release:3%{?prerelease:.%{prerelease}}%{?dist}
 # LDAP schema is GFDL, some helpers are BSD, core is GPLv2+
 License:GPLv2+ and BSD and GFDL
 Group:  Applications/System
@@ -313,6 +313,9 @@ systemctl start amavisd-clean-quarantine.timer >/dev/null 
2>&1 || :
 %{_sbindir}/amavisd-snmp-subagent-zmq
 
 %changelog
+* Thu Jun 30 2016 Juan Orti Alcaine  2.11.0-3
+- Additional systemd hardening (RHBZ#1351354)
+
 * Mon Jun 20 2016 Juan Orti Alcaine  2.11.0-2
 - Remove NoNewPrivileges from service unit (RHBZ#1346766)
 
diff --git a/amavisd-snmp-zmq.service b/amavisd-snmp-zmq.service
index d3faae3..5093087 100644
--- a/amavisd-snmp-zmq.service
+++ b/amavisd-snmp-zmq.service
@@ -13,7 +13,9 @@ ExecStart=/usr/sbin/amavisd-snmp-subagent-zmq -P 
/var/run/amavisd/amavisd-snmp-s
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd-snmp.service b/amavisd-snmp.service
index 94b3537..b311ba6 100644
--- a/amavisd-snmp.service
+++ b/amavisd-snmp.service
@@ -11,7 +11,9 @@ ExecStart=/usr/sbin/amavisd-snmp-subagent -D 
/var/spool/amavisd/db -P /var/run/a
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd.service b/amavisd.service
index a8735f9..f39d860 100644
--- a/amavisd.service
+++ b/amavisd.service
@@ -15,6 +15,9 @@ ExecReload=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf 
reload
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/amavisd-new.git/commit/?h=f24=6d3d0c2d8bb7d82f8e01e945180e45f0f68fef75
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org

[EPEL-devel] epel7 comps.xml lists wrong package for util-linux

[Tuomo Soini]

I noticed a issue in epel7 comps.

buildsys-build group includes util-linux-ng while on rhel7 package is
util-linux and util-linux doesn't even provide util-linux-ng - that
causes packages requiring software from util-linux to fail in mock
build.

Could somebody with access fix this issue asap?

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy 
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[389-devel] Re: Replication after full online init

[Ludwig Krispenz]

Hi William,

the reason that after  a total init the consumer does not have the 
latest state of the supplier RUV and is receiving updates based on the 
RUV at start of the total init is independent of the modrdn problem. 
When a supplier is performing a total init it is still accepting 
changes, the total init can take a while and there are scenarios where 
an entry which is already sent is updated before total init finishes. We 
cannot loose these changes.
Therfor the update resolution/ entry state resolution on the consumer 
side has to handle this, ignore changes already applied and apply new 
changes. And it handles it, if there are bugs they have to be fixed.
Now, I am no longer sure if the fix for 48755 handles correctly all 
modrdns received after the id list was prepared, the parentid might 
change while the total init is on progress.
This brings up my origimal suggestion to handle the modrdn problems also 
on the consumer side.


Ludwig

On 06/30/2016 02:34 AM, William Brown wrote:

Hi,

Now that https://fedorahosted.org/389/ticket/48755 is merged, I would
like to discuss the way we handle CSN with relation to this master. As
I'm not an expert on this topic, I want to get the input of everyone
about this.

Following this document:
http://www.port389.org/docs/389ds/design/changelog-processing-in-repl-state-sending-updates.html


As I understand it, after a full online init, the replica that consumed
the changes does not set it's CSN to match the CSN of the master that
sent the changes.

As a result, after the online init, this causes a number of changes to
be replicated from the sending master to the consumer. These are ignored
by the URP, and we continue.

However, in a number of cases these are *not* ignored, and have caused
us some bugs in replication in the past. We also have some failing
changes that are skipped, which could in certain circumstance lead to
inconsistency in replicas. We have gone to a lot of effort to be able to
skip changes, to handle the case above.

The reason was is that if there was a modrdn performed, and the entry ID
of the entry that was moved was less than the new parent ID, this *had*
to be skipped, so that after the online init the modrdn change was
replayed and applied to the consumer.

Since 48755 which sorts based on the parent ID, this seems to no longer
be an issue. So we don't need to have the master replay it's changelog
out to the consumer, because the consumer is now a literal clone of the
data.

So, is there a reason for us to leave the CSN of the consumer low to
allow this replay to occur? Or can we alter the behaviour of the
consumer to set it's CSN to the CSN of the sending master, so that we
don't need to replay these changes?




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


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

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

Re: Fixing /.autorelabel

[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

[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

jorti pushed to amavisd-new (master). "Additional systemd hardening (RHBZ#1351354)"

[notifications]

From 6d3d0c2d8bb7d82f8e01e945180e45f0f68fef75 Mon Sep 17 00:00:00 2001
From: Juan Orti Alcaine 
Date: Thu, 30 Jun 2016 09:03:24 +0200
Subject: Additional systemd hardening (RHBZ#1351354)

---
 amavis-mc.service| 4 +++-
 amavisd-clean-quarantine.service | 4 +++-
 amavisd-clean-tmp.service| 4 +++-
 amavisd-new.spec | 5 -
 amavisd-snmp-zmq.service | 4 +++-
 amavisd-snmp.service | 4 +++-
 amavisd.service  | 3 +++
 7 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/amavis-mc.service b/amavis-mc.service
index 4dcdc1d..04241b9 100644
--- a/amavis-mc.service
+++ b/amavis-mc.service
@@ -13,7 +13,9 @@ ExecStart=/usr/sbin/amavis-mc -P 
/var/run/amavisd/amavis-mc.pid
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd-clean-quarantine.service b/amavisd-clean-quarantine.service
index 2bb8b3f..10bb01e 100644
--- a/amavisd-clean-quarantine.service
+++ b/amavisd-clean-quarantine.service
@@ -8,5 +8,7 @@ Group=amavis
 PrivateTmp=true
 PrivateDevices=true
 PrivateNetwork=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 ExecStart=/usr/sbin/tmpwatch -d 720 /var/spool/amavisd/quarantine
diff --git a/amavisd-clean-tmp.service b/amavisd-clean-tmp.service
index 70fcffc..9a64b0d 100644
--- a/amavisd-clean-tmp.service
+++ b/amavisd-clean-tmp.service
@@ -8,5 +8,7 @@ Group=amavis
 PrivateTmp=true
 PrivateDevices=true
 PrivateNetwork=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 ExecStart=/usr/sbin/tmpwatch 24 /var/spool/amavisd/tmp
diff --git a/amavisd-new.spec b/amavisd-new.spec
index 773db38..0207fe9 100644
--- a/amavisd-new.spec
+++ b/amavisd-new.spec
@@ -3,7 +3,7 @@
 Summary:Email filter with virus scanner and spamassassin support
 Name:   amavisd-new
 Version:2.11.0
-Release:2%{?prerelease:.%{prerelease}}%{?dist}
+Release:3%{?prerelease:.%{prerelease}}%{?dist}
 # LDAP schema is GFDL, some helpers are BSD, core is GPLv2+
 License:GPLv2+ and BSD and GFDL
 Group:  Applications/System
@@ -313,6 +313,9 @@ systemctl start amavisd-clean-quarantine.timer >/dev/null 
2>&1 || :
 %{_sbindir}/amavisd-snmp-subagent-zmq
 
 %changelog
+* Thu Jun 30 2016 Juan Orti Alcaine  2.11.0-3
+- Additional systemd hardening (RHBZ#1351354)
+
 * Mon Jun 20 2016 Juan Orti Alcaine  2.11.0-2
 - Remove NoNewPrivileges from service unit (RHBZ#1346766)
 
diff --git a/amavisd-snmp-zmq.service b/amavisd-snmp-zmq.service
index d3faae3..5093087 100644
--- a/amavisd-snmp-zmq.service
+++ b/amavisd-snmp-zmq.service
@@ -13,7 +13,9 @@ ExecStart=/usr/sbin/amavisd-snmp-subagent-zmq -P 
/var/run/amavisd/amavisd-snmp-s
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd-snmp.service b/amavisd-snmp.service
index 94b3537..b311ba6 100644
--- a/amavisd-snmp.service
+++ b/amavisd-snmp.service
@@ -11,7 +11,9 @@ ExecStart=/usr/sbin/amavisd-snmp-subagent -D 
/var/spool/amavisd/db -P /var/run/a
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
-NoNewPrivileges=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
diff --git a/amavisd.service b/amavisd.service
index a8735f9..f39d860 100644
--- a/amavisd.service
+++ b/amavisd.service
@@ -15,6 +15,9 @@ ExecReload=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf 
reload
 Restart=on-failure
 PrivateTmp=true
 PrivateDevices=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
 
 [Install]
 WantedBy=multi-user.target
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/amavisd-new.git/commit/?h=master=6d3d0c2d8bb7d82f8e01e945180e45f0f68fef75
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org