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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 888  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 650  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 232  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 130  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 128  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5f9a6163b4   
tnef-1.4.14-1.el7
 127  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7ecb12e378   
python-XStatic-jquery-ui-1.12.0.1-1.el7
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-47be021843   
heimdal-7.4.0-1.el7
  29  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a8886eb42e   
cross-binutils-2.27-9.el7.1 cross-gcc-4.8.5-16.el7.1
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c4e53cc90d   
chicken-4.12.0-3.el7
  17  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b50572c103   
sscep-0.6.1-5.20160525git2052ee1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-017fbc40e8   
supervisor-3.1.4-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-52b6bc17c1   
globus-ftp-client-8.36-1.el7 globus-ftp-control-7.8-1.el7 
globus-gass-cache-program-6.7-1.el7 globus-gass-copy-9.27-1.el7 
globus-gram-client-13.19-1.el7 globus-gram-job-manager-14.36-1.el7 
globus-gram-job-manager-condor-2.6-5.el7 globus-gridftp-server-12.2-1.el7 
globus-gridftp-server-control-5.1-1.el7 globus-gssapi-gsi-12.17-3.el7 
globus-io-11.9-1.el7 globus-net-manager-0.17-1.el7 globus-xio-5.16-1.el7 
globus-xio-gsi-driver-3.11-1.el7 globus-xio-pipe-driver-3.10-1.el7 
globus-xio-udt-driver-1.28-1.el7 myproxy-6.1.28-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-37e736147d   
knot-2.5.3-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-94c168d702   
php-horde-Horde-Core-2.30.0-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-7d6b89ab36   
php-horde-Horde-Form-2.0.18-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-359039e1f1   
php-horde-Horde-Url-2.2.6-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-aebd466ffa   
php-horde-horde-5.2.16-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-531b8ee43e   
php-horde-kronolith-4.2.22-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-055fdcdee7   
php-horde-nag-4.2.15-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-bad0726ae5   
php-horde-turba-4.2.20-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-886e003d48   
gsoap-2.8.16-9.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8683c5e591   
potrace-1.15-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-816da4b59a   
ReviewBoard-2.5.15-1.el7 python-djblets-0.9.9-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b69fde3111   
mingw-libsoup-2.56.1-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-a1d2b25c25   
php-PHPMailer-5.2.24-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-9bf7bf3989   
mingw-gdk-pixbuf-2.36.8-1.el7


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

dcap-2.47.10-9.el7
gnome-shell-extension-freon-25-1.el7
pcsc-cyberjack-3.99.5final.SP11-1.el7

Details about builds:



 dcap-2.47.10-9.el7 (FEDORA-EPEL-2017-9fd8b99f78)
 Client Tools for dCache

Update Information:

Don't use deprecated TLSv1_client_method




 gnome-shell-extension-freon-25-1.el7 (FEDORA-EPEL-2017-0ccf6c15f4)
 GNOME Shell extension to display system temperature, voltage, and fan speed

Update Information:

Bump to upstream version 25, which adds German localization.




 pcsc-cyberjack-3.99.5final.SP11-1.el7 (FEDORA-EPEL-2017-07202f1f0e)
 PC/SC driver for REINER SCT cyberjack USB chip card reader

Update Information:

New upstream release, fixes #1480509.

References:

  [ 1 ] Bug #1480509 - pcsc-cyberjack-3.99.5final.SP11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1480509

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 766  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 760  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 650  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 622  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 232  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 128  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-c0d33ae70f   
tnef-1.4.14-1.el6
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e8124f23c8   
heimdal-7.4.0-1.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-99fb0d61b0   
chicken-4.12.0-3.el6
  21  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-ab5ed7f894   
python-tablib-0.11.5-1.el6
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-b1d8b4aed9   
globus-ftp-client-8.36-1.el6 globus-ftp-control-7.8-1.el6 
globus-gass-cache-program-6.7-1.el6 globus-gass-copy-9.27-1.el6 
globus-gram-client-13.19-1.el6 globus-gram-job-manager-14.36-1.el6 
globus-gram-job-manager-condor-2.6-5.el6 globus-gridftp-server-12.2-1.el6 
globus-gridftp-server-control-5.1-1.el6 globus-gssapi-gsi-12.17-3.el6 
globus-io-11.9-1.el6 globus-net-manager-0.17-1.el6 globus-xio-5.16-1.el6 
globus-xio-gsi-driver-3.11-1.el6 globus-xio-pipe-driver-3.10-1.el6 
globus-xio-udt-driver-1.28-1.el6 myproxy-6.1.28-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-72e0f4a914   
php-horde-Horde-Core-2.30.0-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-2a557f0b9c   
php-horde-Horde-Form-2.0.18-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-3e60244bf3   
php-horde-Horde-Url-2.2.6-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4340a6e0a8   
php-horde-horde-5.2.16-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4654acd4ee   
php-horde-kronolith-4.2.22-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-19c0b8ff89   
php-horde-nag-4.2.15-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-5b8e6e0279   
php-horde-turba-4.2.20-1.el6
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d015ef3016   
gsoap-2.7.16-5.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-87be2d4d20   
potrace-1.15-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-938c876edd   
php-PHPMailer-5.2.24-1.el6


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

dcap-2.47.10-9.el6
pcsc-cyberjack-3.99.5final.SP11-1.el6
python-pyrpmmd-0.1.1-1.el6

Details about builds:



 dcap-2.47.10-9.el6 (FEDORA-EPEL-2017-4140e596c6)
 Client Tools for dCache

Update Information:

Don't use deprecated TLSv1_client_method




 pcsc-cyberjack-3.99.5final.SP11-1.el6 (FEDORA-EPEL-2017-3556d35dc9)
 PC/SC driver for REINER SCT cyberjack USB chip card reader

Update Information:

New upstream release, fixes #1480509.

References:

  [ 1 ] Bug #1480509 - pcsc-cyberjack-3.99.5final.SP11 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1480509




 python-pyrpmmd-0.1.1-1.el6 (FEDORA-EPEL-2017-6f3295ae47)
 Python module for reading rpm-md repo data

Update Information:

Initial packaging for Fedora

References:

  [ 1 ] Bug #1450691 - Review Request: python-pyrpmmd - Python module for 
reading rpm-md repo data
https://bugzilla.redhat.com/show_bug.cgi?id=1450691

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

Re: Unable to bring new package to bodhi

[Andrew Toskin]

If you're talking specifically about the Bodhi web UI, then I think I'm having 
the same problem: After I logged in, I clicked on Create > New Update, tried to 
search for my package, and got the message "unable to find any packages that 
match the current query".

I had to start my updates from the bodhi command line tool instead.

~ Andrew Toskin


> For some odd reasons, I am unable to update via bodhi even though the
> package is already built[1].
> 
> Is it a bug from the infrastructure as the database failed to list new
> package [2]?
> 
> 
> Reference
> 
> --
> 
> [1]
> http://koji.fedoraproject.org/koji/search?type=package=glob;...
> 
> [2] https://src.fedoraproject.org/rpms/gimp-luminosity-masks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1479680] perl-Time-OlsonTZ-Download-0.006 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Time-OlsonTZ-Download-0.006-1.fc26 has been pushed to the Fedora 26
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-2017-8b41380c33

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/ perl5/vendor_perl/File/Tail.pm line 391

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-File-Tail-1.3-7.fc26 has been pushed to the Fedora 26 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-2017-f475d1d0a5

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Orphaned Packages in rawhide (2017-08-13)

[till]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

 Package  (co)maintainersStatus Change 
==
apvlvorphan  1 weeks ago   
frepple  orphan, jdetaeye, salimma   2 weeks ago   
herbstluftwm orphan, cicku   1 weeks ago   
modem-manager-guiorphan, mariobl 5 weeks ago   
python-tlslite   orphan  1 weeks ago   
rubygem-haml-rails   orphan  3 weeks ago   
xsettingsd   orphan, pcarrier1 weeks ago   

The following packages require above mentioned packages:
Depending on: python-tlslite (1), status change: 2017-08-02 (1 weeks ago)
python-jira (maintained by: ralph)
python2-jira-1.0.7-2.fc27.noarch requires python2-tlslite = 
0.4.9-5.fc27
python3-jira-1.0.7-2.fc27.noarch requires python3-tlslite = 
0.4.9-5.fc27

Affected (co)maintainers
cicku: herbstluftwm
jdetaeye: frepple
mariobl: modem-manager-gui
pcarrier: xsettingsd
ralph: python-tlslite
salimma: frepple

Orphans (7): apvlv frepple herbstluftwm modem-manager-gui
python-tlslite rubygem-haml-rails xsettingsd


Orphans (dependend on) (1): python-tlslite


Orphans (rawhide) for at least 6 weeks (dependend on) (0):


Orphans  (rawhide)(not depended on) (6): apvlv frepple herbstluftwm
modem-manager-gui rubygem-haml-rails xsettingsd


Orphans (rawhide) for at least 6 weeks (not dependend on) (0):


Depending packages (rawhide) (1): python-jira


Packages depending on packages orphaned (rawhide) for more than 6
weeks (0):

-- 
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/master/f/scripts/find_unblocked_orphans.py
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Dominik 'Rathann' Mierzejewski]

On Saturday, 12 August 2017 at 23:30, Richard W.M. Jones wrote:
> On Sat, Aug 12, 2017 at 12:40:18PM +0200, Kevin Kofler wrote:
> > Richard W.M. Jones wrote:
> > > I have no particular affinity for Atlas.  But if we're going to
> > > replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> > > requires no or at least very minimal changes?  In what ways is it better
> > > or worse?
> > 
> > Proper support for runtime CPU feature detection on x86 architectures 
> > (x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
> > distro packages can only be built to the lowest common denominator. 
> > (Anything else can only be in atlas-* subpackages that have to be manually 
> > installed.) OpenBLAS can also do that, but it also has a mode (used in 
> > packaging) where it will check for the available vector instruction sets 
> > (MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
> > implemented for the called function. E.g., it can use SSE3 and newer on 
> > x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
> > (Please note that this is only supported on x86 at this time. For ARM, it 
> > is 
> > like ATLAS, you can only compile for the baseline.) This can make a big 
> > difference in distro packages.
> > 
> > There might also be other performance benefits. OpenBLAS is derived from 
> > GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
> > 2010, so that the community can continue development, which is exactly what 
> > OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
> > reputation of being a really fast implementation.
> 
> Sounds all good.  Are source-level changes needed to dependent
> packages and if so are they simple to make?

Yes, you don't need to add -L%{_libdir}/atlas to LDFLAGS anymore and you
link with -lopenblas.

See scalapack, arpack or elpa packages for example. In fact, I had to
switch elpa to openblas to match scalapack. Otherwise I got test
failures.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: debuginfo/source improvements vs mass rebuild

[Jan Kratochvil]

On Mon, 31 Jul 2017 13:16:29 +0200, Mark Wielaard wrote:
> - Putting extra files under /usr/lib/debug causes:
>   error: Installed (but unpackaged) file(s) found:
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-1.pyc
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-2.pyc
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.pyc
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-1.pyc
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.opt-2.pyc
>
> /usr/lib/debug/usr/lib64/__pycache__/libpython3.6m.so.1.0.debug-gdb.cpython-36.pyc
>/usr/lib/debug/usr/lib64/libpython3.6dm.so.1.0.debug-gdb.py
>/usr/lib/debug/usr/lib64/libpython3.6m.so.1.0.debug-gdb.py
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1476593
> 
> This is caused by split debuginfo checking which file corresponds to
> which main/sub-package. Without split debuginfo anything found
> under /usr/lib/debug is just put into the -debuginfo package, no
> questions asked.
> 
> The immediate workaround is to add the following to your spec file:
> %undefine _debuginfo_subpackages
> 
> This disables split debuginfo packages and just generates one big
> -debuginfo packages with everything under /usr/lib/debug/ included.
> 
> But this might or might not be a packaging bug. In particular if it
> contains generated pyc files those probably really shouldn't be there.

Why not?  For *.py files their *.pyc should be also packaged.


> 
> The basic issue is that we have been trying to make the debuginfo
> packages self-contained and non-conflicting between versions.
> So you can easily install debuginfo for different (bi)arches or
> versions. But some packages assume that if they drop anything
> under /usr/lib/debug it will just magically appear in the debuginfo
> package (which has been historically true). But with the split
> debuginfo we have to make a choice which subpackage it belongs
> to. Best rpm fix would probably be to add such files to the "main"
> debuginfo package.
> 
> But it would probably be better to move these files to the
> python3-devel package. Maybe we should discuss with the gdb
> maintainers how/where they would like to see these gdb python
> extensions installed. I doubt the -debuginfo package really is
> the place for them anyway.

I cannot speak for python3-devel.  But for package "gdb" I get:

error: Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/bin/__pycache__/gdb-gdb.cpython-36.opt-1.pyc
   /usr/lib/debug/usr/bin/__pycache__/gdb-gdb.cpython-36.pyc
   /usr/lib/debug/usr/bin/gdb-gdb.py

And gdb-gdb.py is useful only for debugging /usr/bin/gdb itself.
For that one needs gdb-debuginfo.rpm.  And gdb-devel.rpm even does not exist.


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

Re: glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

[Sérgio Basto]

On Sat, 2017-08-12 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Aug 12, 2017 at 03:28:15PM +0200, Florian Weimer wrote:
> > On 08/12/2017 03:22 PM, Richard Shaw wrote:
> > > During one of the releng rebuilds my package OCE is failing to
> > > build[1]
> > > because it can't find /usr/include/xlocale.h
> > > Was this intentional?
> > 
> > Yes, it used to be installed by accident.  The header itself
> > clearly
> > said that it was an internal-only header.
> > 
> > We removed it without a deprecation warning because most programs
> > had
> > configure checks for  which started to fail after
> > removal,
> > skipping the #include.
> 
> Heh, I just fixed two ftbfs packages with xlocale.h includes, and a
> bunch
> more back when glibc 2.25 came out, incl. systemd. From what I've
> seen,
> people don't test for xlocale.h because it's "part of glibc, so
> always there" ;)
> 
> Zbyszek

Thank you Zbyszek for taking care of mlt.
Richard the mlt fix is here [1].
[1] 
https://src.fedoraproject.org/rpms/mlt/c/7ec11616fd9f88c0e1d6f44ec88a4c
435e36044f?branch=master

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Issue 91 - Fix replication m1h1c1 topology

[Simon Pichugin]

Hi team,
https://pagure.io/lib389/issue/91
https://pagure.io/lib389/issue/raw/files/f9874b05dcab8b6e01517163218c9572b14373b8809cf93a1a38827c3db1873f-0001-Issue-91-Fix-replication-m1h1c1-topology.patch

Thanks,
Simon


signature.asc
Description: PGP signature
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Sat, Aug 12, 2017 at 12:40:18PM +0200, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > I have no particular affinity for Atlas.  But if we're going to
> > replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> > requires no or at least very minimal changes?  In what ways is it better
> > or worse?
> 
> Proper support for runtime CPU feature detection on x86 architectures 
> (x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
> distro packages can only be built to the lowest common denominator. 
> (Anything else can only be in atlas-* subpackages that have to be manually 
> installed.) OpenBLAS can also do that, but it also has a mode (used in 
> packaging) where it will check for the available vector instruction sets 
> (MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
> implemented for the called function. E.g., it can use SSE3 and newer on 
> x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
> (Please note that this is only supported on x86 at this time. For ARM, it is 
> like ATLAS, you can only compile for the baseline.) This can make a big 
> difference in distro packages.
> 
> There might also be other performance benefits. OpenBLAS is derived from 
> GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
> 2010, so that the community can continue development, which is exactly what 
> OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
> reputation of being a really fast implementation.

Sounds all good.  Are source-level changes needed to dependent
packages and if so are they simple to make?

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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170812.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Cloud_base qcow2 x86_64
Atomic qcow2 x86_64
Workstation live i386
Cloud_base raw-xz x86_64
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 41/137 (x86_64), 4/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170811.n.2):

ID: 128737  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/128737
ID: 128749  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/128749
ID: 128751  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/128751

Old failures (same test failed in Rawhide-20170811.n.2):

ID: 128597  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/128597
ID: 128598  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/128598
ID: 128599  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/128599
ID: 128601  Test: x86_64 Server-dvd-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/128601
ID: 128602  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/128602
ID: 128605  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/128605
ID: 128607  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/128607
ID: 128610  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/128610
ID: 128611  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/128611
ID: 128617  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128617
ID: 128618  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128618
ID: 128619  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128619
ID: 128632  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/128632
ID: 128634  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128634
ID: 128636  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128636
ID: 128647  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/128647
ID: 128649  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/128649
ID: 128651  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128651
ID: 128652  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128652
ID: 128653  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128653
ID: 128661  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/128661
ID: 128668  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128668
ID: 128669  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/128669
ID: 128670  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/128670
ID: 128671  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/128671
ID: 128673  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/128673
ID: 128674  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/128674
ID: 128675  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128675
ID: 128676  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/128676
ID: 128677  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/128677
ID: 128678  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/128678
ID: 128679  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/128679
ID: 128683  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/128683
ID: 128684  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/128684
ID: 128685  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/128685
ID: 128701  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/128701
ID: 128725  Test: x86_64 universal install_package_set_kde
URL: 

Unable to bring new package to bodhi

[Luya Tshimbalanga]

For some odd reasons, I am unable to update via bodhi even though the
package is already built[1].

Is it a bug from the infrastructure as the database failed to list new
package [2]?


Reference

--

[1]
http://koji.fedoraproject.org/koji/search?type=package=glob=gimp-luminosity-masks

[2] https://src.fedoraproject.org/rpms/gimp-luminosity-masks

-- 
Luya Tshimbalanga
Graphic & Web Designer
E: l...@fedoraproject.org
W: http://www.coolest-storm.net




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Conflict between amavisd-new and nmh

[Jos Vos]

Hi,

FYI:

I just submitted a bug in Bugzilla, something I actually found on
CentOS 7 with EPEL 7, but is exists on all Fedora releases too,
so I decided to file it on Fedora 26:

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

Cheers,

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Office: +31 20 6938364
--Amsterdam, The Netherlands|   Mobile: +31 6 26216181
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Fwd: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump

[Orion Poplawski]

On 08/10/2017 01:47 PM, Panu Matilainen wrote:


Resending to devel@, some mishap in earlier...

 Forwarded Message 
Subject: Heads-up on rpm 4.14 coming to rawhide, incl. soname bump
Date: Thu, 10 Aug 2017 20:50:30 +0300
From: Panu Matilainen 
To: devel-annou...@lists.fedoraproject.org, Development discussions 
related to Fedora 



Rpm 4.14 alpha is about to hit rawhide as per 
https://fedoraproject.org/wiki/Changes/RPM-4.14. I realize we're a bit 
late to the schedule, and much much later in the cycle than I'd like, 
but lets try to get by. There's a soname bump involved so related 
packages will need to be rebuilt, but Igor Gnatenko kindly promised to 
take care of that.


The other thing is the rpm macro engine which has seen by far its 
biggest in the last 10+ years:
- Macro scoping is simplified, only macros %define'd inside parametric 
macros are local, everything else is in global scope. This isn't as big 
a change as is it may sound, because this is the way scoping only ever 
really worked in previous versions.
- %{lua:} macros are scoped similarly to everything else. Previously 
they could appear to be higher in the callchain than they are, causing 
strange side-effects in already hard to debug complex macro constructs.
- Visibility is enforced per scope for automatic macros (ie %* %1 etc 
that are created for parametric macros). In other words, nested macro 
"calls" are more reliable as arguments from previous calls are not visible.

- Arguments to parametric macros are now expanded before execution.
- Arguments to parametric macros now support quoting (single and double)

For the average trivial macro usage, none of that will make a 
difference. But I'd be almost shocked if nothing at all broke because of 
this - former limitations and bugs might have necessiated tricks and 
kludges that no longer work but also are not required any more etc. So 
owners of complex macros, keep your eyes open.


Okay, so this has hit the octave macro set, probably not unexpectedly. 
I'd appreciate some help with what I'm doing wrong, if anything:


ENTER ['do'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bb --target 
noarch --nodeps /builddir/build/SPECS/octave-statistics.spec'], 
logger=0x3fff945826d8>timeout=172800user='mockbuild'printOutput=Falseenv={'SHELL': 
'/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 'printf 
"\\033]0;\\007"', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 
'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'PS1': ' \\s-\\v\\$ 
', 'HOSTNAME': 
'mock'}gid=425uid=1000shell=FalsechrootPath='/var/lib/mock/f27-build-9511079-776071/root'nspawn_args=[])
Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bb 
--target noarch --nodeps /builddir/build/SPECS/octave-statistics.spec'] 
with env {'SHELL': '/bin/bash', 'HOME': '/builddir', 'PROMPT_COMMAND': 
'printf "\\033]0;\\007"', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 
'PS1': ' \\s-\\v\\$ ', 'HOSTNAME': 'mock'} and shell False

octave_cmd: invalid option -- 'n'
error: Unknown option n in octave_cmd()
error: line 31: %octave_pkg_install

%install
%octave_pkg_install

%octave_pkg_install \
mkdir -p %{buildroot}%{octprefix} \
mkdir -p %{buildroot}%{octarchprefix} \
%octave_cmd 
pkg("prefix","%{buildroot}%{octprefix}","%{buildroot}%{octarchprefix}");pkg("global_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("local_list",fullfile("%{buildroot}%{octshareprefix}","octave_packages"));pkg("install","-nodeps","-verbose","%{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}-%{octave_tar_suffix}.tar.gz");unlink(pkg("local_list"));unlink(pkg("global_list")); 
\

if [ -e %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m ] \
then \
  mv %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m 
%{buildroot}%{octpkgdir}/packinfo/on_uninstall.m.orig \

fi \
echo "function on_uninstall (desc)" > 
%{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \
echo "  error ('Can not uninstall %s installed by the redhat package 
manager', desc.name);" >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \

echo "endfunction" >> %{buildroot}%{octpkgdir}/packinfo/on_uninstall.m \
if [ -e 
%{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml 
] \

then \
  echo "Found octave-%{octpkg}.metainfo.xml" \
  mkdir -p %{buildroot}/%{_datadir}/appdata \
  cp -p 
%{_builddir}/%{buildsubdir}/build/%{octpkg}-%{version}/octave-%{octpkg}.metainfo.xml 
%{buildroot}/%{_datadir}/appdata/ \
  appstream-util validate-relax --nonet 
%{buildroot}/%{_datadir}/appdata/octave-%{octpkg}.metainfo.xml \

fi \
%{nil}


%octave_cmd() octave -H -q --no-window-system --no-site-file --eval '%*';


Somehow I think it's grabbing onto the "-nodeps" as an option.

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, 

[UPDATE] Re: Mass package change (python2- binary package renaming)

[Zbigniew Jędrzejewski-Szmek]

I've done mock rebuilds for all the packages I plan to change (results
below), and I'm prepared to go through with the changes.

dreampie and tiled have been dropped.
(Those two packages are "applications". dreampie installs a python3
module, but no python3 binaries. For tiled the python module seems to
be a minor addition.)

Packages part of https://fedoraproject.org/wiki/Changes/Platform_Python_Stack
are also excluded (to avoid conflicts):
 dbus-python, gpgme, libcomps, libdnf, librepo, pytest,
 python-argcomplete, python-cffi, python-contextlib2, python-coverage,
 python-cryptography, python-decorator, python-extras,
 python-fixtures, python-funcsigs, python-hypothesis, python-idna,
 python-iniparse, python-jinja2, python-jsonschema, python-keyring,
 python-linecache2, python-markupsafe, python-mimeparse, python-mock,
 python-nose, python-pbr, python-pexpect, python-pip, python-ply,
 python-ptyprocess, python-py, python-pyasn1, python-pycparser,
 python-pygpgme, python-pytest-timeout, python-rpm-macros,
 python-SecretStorage, python-setuptools, python-setuptools_scm,
 python-six, python-testtools, python-traceback2, python-unittest2,
 python-wheel, pyxattr, pyxdg, rpm,

Packages that had build issues unrelated to the python2- renaming:

abiword/  ftbfs (empty debugsources list for -docs, looks like 
generator bug.
 I hope to get this fixed before pushing.)
atomic-reactor/   ftbfs (AttributeError: module 'docker' has no 
attribute 'Client')
bro/  ftbfs (error: invalid use of incomplete type 
'EVP_PKEY {aka struct evp_pkey_st}')
cjdns/ftbfs
csound/   ftbfs (also needs update to 6.03 → 6.09)
fts-rest/ ftbfs (AttributeError: 'HTTPForbidden' object has no 
attribute 'exception')
libkdtree++/  ftbfs (C++11 stuff?)
libsvm/   ftbfs (%mvn_add_dep)
libvoikko/fixed and built
mesos/ftbfs
mlt/  fixed and built
python-amqpclt/   ftbfs
python-django-countries/  ftbfs
python-django-mptt/   ftbfs
python-djvulibre/ ftbfs
python-flask-silk/ftbfs
python-gear/  ftbfs
python-gensim/ftbfs
python-hwdata/fixed upstream
python-larch/ fixed and built
python-lettuce/   ftbfs
python-libasyncns/ftbfs
python-mwlib/ ftbfs
python-openstackclient/   ftbfs
python-pyblock/   ftbfs
python-pygal/ ftbfs
python-pylons/ftbfs
python-rhev/  fixed and built
python-urwid/ ftbfs
qgis/ ftbfs (error: conflicting declaration 'PyObject* 
sipExportedExceptions__core [3]')
qpid-proton/  ftbfs (Make Error at 
proton-c/bindings/perl/cmake_install.cmake:44 (file):
 file INSTALL cannot find
 
"/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/libcproton_perl.so".)
vtk/  ftbfs (looks like a local issue with lack of memory, 
might build in koji.
 I hope to get this fixed before pushing.)

(ftbfs: doesn't build for unrelated reasons, I'll push the python2- changes 
because they don't hurt,
fixed upstream: an independent fix in the meantime,
fixed and built: fixed and built in koji w/o the python2- renaming, I'll push 
the python2- changes
at the same time as other packages.)

For some packages I also renamed the python3 subpackage manually,
and/or added %python_provides for it.

Updated patches: https://in.waw.pl/~zbyszek/fedora/pyrename/

Zbyszek


On Tue, Aug 08, 2017 at 10:14:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hello Fedora Python package maintainers!
> 
> This is an announcement of a mass package renaming:
> Python 2 binary packages will be renamed to python2-*.
> 
> This will happen soon after the F27 branching on August 15th.
> 
> 
> Currently ~1330 source packages already generate a binary package with
> the python2- prefix, and 835 remain to be updated. The spec files for
> approximately 740 packages will be renamed, and 95 will be left for
> fixing by maintainers or proven packagers.
> 
> 
> At the end of this e-mail are two lists of maintainers and packages:
> 
> List 1. for those packages which will be taken care of by the mass remaining
>Patches: https://in.waw.pl/~zbyszek/fedora/pyrename/
> 
>Maintainers don't have to do anything.
> 
> List 2. for the remaining packages
> 
>Maintainers are encouraged to update packages manually.
> 
> 
> ### Details of the change ###
> 
> The change is to ensure that as many as possible python packages which
> provide a version for python2 have a python2- subpackage as required by
> the guidelines
> [https://fedoraproject.org/wiki/Packaging:Naming#Python2_binary_package_naming].
> 
> For source packages which do *not* have a python- prefix, but 

[UPDATE] Re: Mass package change (python2- binary package renaming)

[Zbigniew Jędrzejewski-Szmek]

I've done mock rebuilds for all the packages I plan to change (results
below), and I'm prepared to go through with the changes.

dreampie and tiled have been dropped.
(Those two packages are "applications". dreampie installs a python3
module, but no python3 binaries. For tiled the python module seems to
be a minor addition.)

Packages part of https://fedoraproject.org/wiki/Changes/Platform_Python_Stack
are also excluded (to avoid conflicts):
 dbus-python, gpgme, libcomps, libdnf, librepo, pytest,
 python-argcomplete, python-cffi, python-contextlib2, python-coverage,
 python-cryptography, python-decorator, python-extras,
 python-fixtures, python-funcsigs, python-hypothesis, python-idna,
 python-iniparse, python-jinja2, python-jsonschema, python-keyring,
 python-linecache2, python-markupsafe, python-mimeparse, python-mock,
 python-nose, python-pbr, python-pexpect, python-pip, python-ply,
 python-ptyprocess, python-py, python-pyasn1, python-pycparser,
 python-pygpgme, python-pytest-timeout, python-rpm-macros,
 python-SecretStorage, python-setuptools, python-setuptools_scm,
 python-six, python-testtools, python-traceback2, python-unittest2,
 python-wheel, pyxattr, pyxdg, rpm,

Packages that had build issues unrelated to the python2- renaming:

abiword/  ftbfs (empty debugsources list for -docs, looks like 
generator bug.
 I hope to get this fixed before pushing.)
atomic-reactor/   ftbfs (AttributeError: module 'docker' has no 
attribute 'Client')
bro/  ftbfs (error: invalid use of incomplete type 
'EVP_PKEY {aka struct evp_pkey_st}')
cjdns/ftbfs
csound/   ftbfs (also needs update to 6.03 → 6.09)
fts-rest/ ftbfs (AttributeError: 'HTTPForbidden' object has no 
attribute 'exception')
libkdtree++/  ftbfs (C++11 stuff?)
libsvm/   ftbfs (%mvn_add_dep)
libvoikko/fixed and built
mesos/ftbfs
mlt/  fixed and built
python-amqpclt/   ftbfs
python-django-countries/  ftbfs
python-django-mptt/   ftbfs
python-djvulibre/ ftbfs
python-flask-silk/ftbfs
python-gear/  ftbfs
python-gensim/ftbfs
python-hwdata/fixed upstream
python-larch/ fixed and built
python-lettuce/   ftbfs
python-libasyncns/ftbfs
python-mwlib/ ftbfs
python-openstackclient/   ftbfs
python-pyblock/   ftbfs
python-pygal/ ftbfs
python-pylons/ftbfs
python-rhev/  fixed and built
python-urwid/ ftbfs
qgis/ ftbfs (error: conflicting declaration 'PyObject* 
sipExportedExceptions__core [3]')
qpid-proton/  ftbfs (Make Error at 
proton-c/bindings/perl/cmake_install.cmake:44 (file):
 file INSTALL cannot find
 
"/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/libcproton_perl.so".)
vtk/  ftbfs (looks like a local issue with lack of memory, 
might build in koji.
 I hope to get this fixed before pushing.)

(ftbfs: doesn't build for unrelated reasons, I'll push the python2- changes 
because they don't hurt,
fixed upstream: an independent fix in the meantime,
fixed and built: fixed and built in koji w/o the python2- renaming, I'll push 
the python2- changes
at the same time as other packages.)

For some packages I also renamed the python3 subpackage manually,
and/or added %python_provides for it.

Updated patches: https://in.waw.pl/~zbyszek/fedora/pyrename/

Zbyszek


On Tue, Aug 08, 2017 at 10:14:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hello Fedora Python package maintainers!
> 
> This is an announcement of a mass package renaming:
> Python 2 binary packages will be renamed to python2-*.
> 
> This will happen soon after the F27 branching on August 15th.
> 
> 
> Currently ~1330 source packages already generate a binary package with
> the python2- prefix, and 835 remain to be updated. The spec files for
> approximately 740 packages will be renamed, and 95 will be left for
> fixing by maintainers or proven packagers.
> 
> 
> At the end of this e-mail are two lists of maintainers and packages:
> 
> List 1. for those packages which will be taken care of by the mass remaining
>Patches: https://in.waw.pl/~zbyszek/fedora/pyrename/
> 
>Maintainers don't have to do anything.
> 
> List 2. for the remaining packages
> 
>Maintainers are encouraged to update packages manually.
> 
> 
> ### Details of the change ###
> 
> The change is to ensure that as many as possible python packages which
> provide a version for python2 have a python2- subpackage as required by
> the guidelines
> [https://fedoraproject.org/wiki/Packaging:Naming#Python2_binary_package_naming].
> 
> For source packages which do *not* have a python- prefix, but 

Re: glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

[Zbigniew Jędrzejewski-Szmek]

On Sat, Aug 12, 2017 at 03:28:15PM +0200, Florian Weimer wrote:
> On 08/12/2017 03:22 PM, Richard Shaw wrote:
> > During one of the releng rebuilds my package OCE is failing to build[1]
> > because it can't find /usr/include/xlocale.h
> 
> > Was this intentional?
> 
> Yes, it used to be installed by accident.  The header itself clearly
> said that it was an internal-only header.
> 
> We removed it without a deprecation warning because most programs had
> configure checks for  which started to fail after removal,
> skipping the #include.

Heh, I just fixed two ftbfs packages with xlocale.h includes, and a bunch
more back when glibc 2.25 came out, incl. systemd. From what I've seen,
people don't test for xlocale.h because it's "part of glibc, so always there" ;)

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

Fedora Rawhide-20170811.n.2 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 43/137 (x86_64), 3/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170807.n.0):

ID: 128370  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/128370
ID: 128371  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/128371
ID: 128372  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/128372
ID: 128373  Test: x86_64 Server-dvd-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/128373
ID: 128374  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/128374
ID: 128379  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/128379
ID: 128382  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/128382
ID: 128383  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/128383
ID: 128390  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128390
ID: 128424  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128424
ID: 128433  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/128433
ID: 128440  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128440
ID: 128442  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/128442
ID: 128449  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/128449
ID: 128455  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/128455
ID: 128456  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/128456
ID: 128457  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/128457
ID: 128458  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/128458
ID: 128459  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/128459
ID: 128460  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/128460
ID: 128473  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/128473
ID: 128497  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/128497
ID: 128499  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/128499

Old failures (same test failed in Rawhide-20170807.n.0):

ID: 128369  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/128369
ID: 128377  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/128377
ID: 128389  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128389
ID: 128391  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128391
ID: 128404  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/128404
ID: 128406  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128406
ID: 128408  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128408
ID: 128419  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/128419
ID: 128421  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/128421
ID: 128423  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128423
ID: 128425  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128425
ID: 128441  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/128441
ID: 128443  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/128443
ID: 128445  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/128445
ID: 128446  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/128446
ID: 128447  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128447
ID: 128448  Test: x86_64 universal upgrade_2_desktop_64bit
URL: 

Re: glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

[Florian Weimer]

On 08/12/2017 03:22 PM, Richard Shaw wrote:
> During one of the releng rebuilds my package OCE is failing to build[1]
> because it can't find /usr/include/xlocale.h

> Was this intentional?

Yes, it used to be installed by accident.  The header itself clearly
said that it was an internal-only header.

We removed it without a deprecation warning because most programs had
configure checks for  which started to fail after removal,
skipping the #include.

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

glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

[Richard Shaw]

During one of the releng rebuilds my package OCE is failing to build[1]
because it can't find /usr/include/xlocale.h

In both Fedora 24/25 it is provided by the glibc-headers package but it
seems to have been dropped in 2.26 in rawhide.

# dnf repoquery --whatprovides /usr/include/xlocale.h
Fedora 26 - x86_64 - Updates
 5.2 MB/s |  10 MB 00:01
Fedora 26 - x86_64
 6.5 MB/s |  53 MB 00:08
Last metadata expiration check: 0:00:03 ago on Sat Aug 12 13:18:38 2017.
glibc-headers-0:2.25-6.fc26.i686
glibc-headers-0:2.25-6.fc26.x86_64
glibc-headers-0:2.25-7.fc26.i686
glibc-headers-0:2.25-7.fc26.x86_64

(Rawhide)
# dnf repoquery --whatprovides /usr/include/xlocale.h
Last metadata expiration check: 0:14:04 ago on Sat Aug 12 13:05:37 2017.

Was this intentional?

Thanks,
Richard

[1] https://kojipkgs.fedoraproject.org//work/tasks/3501/20973501/build.log
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1480861] New: amavisd default conf conflicts with nmh (scan)

[bugzilla]

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

Bug ID: 1480861
   Summary: amavisd default conf conflicts with nmh (scan)
   Product: Fedora
   Version: 26
 Component: amavisd-new
  Severity: medium
  Assignee: j.orti.alca...@gmail.com
  Reporter: j...@xos.nl
QA Contact: extras...@fedoraproject.org
CC: j.orti.alca...@gmail.com,
perl-devel@lists.fedoraproject.org, st...@silug.org,
vanmeeuwen+fed...@kolabsys.com



Description of problem:

When besides amavisd-new also nmh is installed, the default amavisd.conf rule
for Avast antivirus lets amavisd discard *any* incoming mail with:

Blocked INFECTED () {DiscardedInbound,Quarantined}

This is because /bin/scan is called, which is part of nmh (as /usr/bin/scan).

Version-Release number of selected component (if applicable):

Any I know of.  I found the problem using EPEL 7 on CentOS 7, but the
amavisd-new and nmh packages conflict everywhere the same way.

Solution:

Comment out the this line in /etc/amavisd/amavisd.conf:

['avast! Antivirus', '/bin/scan', '{}', [0], [1], qr/\t(.+)/m ],

Because the use of the Avast virusscanner is probably not very common, it would
IMHO be a good idea to comment out this conflicting rule by default.  It costed
me quite some time to find out why all my mails were discarded.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: ENOTIME

[Antonio Trande]

On 07/21/2017 04:51 PM, Orion Poplawski wrote:
> rpms/suitesparse -- A collection of sparse matrix libraries ( el6 )

Let me update suitesparse on el6 too, please.

-- 
--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: git push fails for new packages

[Samuel Rakitničan]

> for f27: This is a known problem see: 
> https://pagure.io/fedora-infrastructure/issue/6236
> They working on it right now.
> 
> f26 works for me now with:
> $ git checkout -b f26; git push --set-upstream origin f26; fedpkg build 
> --nowait

Used your workaround, I can't build the package now in koji with a message:

BuildError: package hd-idle not in list for tag f26-updates-candidate

Same with other branches other then master.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible atlas is linked wrongly by new binutils?

[Kevin Kofler]

Richard W.M. Jones wrote:
> I have no particular affinity for Atlas.  But if we're going to
> replace it, is OpenBLAS a complete drop-in replacement for Atlas that
> requires no or at least very minimal changes?  In what ways is it better
> or worse?

Proper support for runtime CPU feature detection on x86 architectures 
(x86_64 and i686). ATLAS expects to be tuned to every single machine, and 
distro packages can only be built to the lowest common denominator. 
(Anything else can only be in atlas-* subpackages that have to be manually 
installed.) OpenBLAS can also do that, but it also has a mode (used in 
packaging) where it will check for the available vector instruction sets 
(MMX, SSE*, AVX*) and pick the highest one available on the machine that is 
implemented for the called function. E.g., it can use SSE3 and newer on 
x86_64 when available, without breaking the SSE2-only x86_64 baseline. 
(Please note that this is only supported on x86 at this time. For ARM, it is 
like ATLAS, you can only compile for the baseline.) This can make a big 
difference in distro packages.

There might also be other performance benefits. OpenBLAS is derived from 
GotoBLAS (which was put under a BSD license when Prof. Goto left TACC in 
2010, so that the community can continue development, which is exactly what 
OpenBLAS is doing). GotoBLAS has, since its proprietary times, had a 
reputation of being a really fast implementation.

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

Re: Is it possible atlas is linked wrongly by new binutils?

[Richard W.M. Jones]

On Sat, Aug 12, 2017 at 12:11:00AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 10 August 2017 at 12:29, Richard W.M. Jones wrote:
> > Never mind.  Something in the atlas build segfaults when building
> > on ppc64le:
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=21145734
> > 
> > This is a mess :-(
> 
> Just switch to openblas already. ;)

I have no particular affinity for Atlas.  But if we're going to
replace it, is OpenBLAS a complete drop-in replacement for Atlas that
requires no or at least very minimal changes?  In what ways is it better
or worse?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: seafile-client fails to build on ARM for f26

[Julien Enselme]

I have temporarily disabled armv7 to provide the update to all other
architectures.

On Thu, 2017-08-10 at 22:07 +0200, Julien Enselme wrote:
> Hi,
> 
> I have a strange build failure my package seafile-client on ARM  for
> f26 (rawhide and f25 are fine). From what I understand, this is a ld
> issue related to Qt5. However, I am no expert in these sort of
> things.
> Can someone help me with this?
> 
> Build on koji:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=21153235
> Build.log file:
> https://kojipkgs.fedoraproject.org//work/tasks/3235/21153235/build.lo
> g
> 
> 
> Regards,
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Julien Enselme
http://www.jujens.eu/

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: koji-1.13 cannot be resolved as a dependency in f25

[Michael Schwendt]

On Sat, 12 Aug 2017 10:45:29 +0800, Chenxiong Qi wrote:

> [root@e151b05870c7 pkgs]# dnf repoquery koji
> Last metadata expiration check: 0:01:39 ago on Sat Aug 12 02:25:14 2017.
> koji-0:1.10.1-13.fc25.noarch
> koji-0:1.13.0-2.fc25.noarch
> 
> and koji-1.13 is listed by resolving the dependencies
> 
> [root@e151b05870c7 pkgs]# dnf repoquery --requires --resolve fedpkg
> Last metadata expiration check: 0:04:56 ago on Sat Aug 12 02:25:14 2017.
> bodhi-client-0:0.9.12.2-6.fc25.noarch
> fedora-cert-0:0.6.0.1-1.fc25.noarch
> koji-0:1.13.0-2.fc25.noarch
> packagedb-cli-0:2.14.1-1.fc25.noarch
> pyrpkg-0:1.46-5.fc25.noarch
> python-0:2.7.13-2.fc25.i686
> python-0:2.7.13-2.fc25.x86_64
> python-fedora-0:0.8.0-2.fc25.noarch
> python-libs-0:2.7.13-2.fc25.i686
> python-libs-0:2.7.13-2.fc25.x86_64
> python-pycurl-0:7.43.0-4.fc25.x86_64
> python2-fedora-0:0.9.0-6.fc25.noarch
> python2-pycurl-0:7.43.0-6.fc25.x86_64
> python2-rpkg-0:1.49-6.fc25.noarch
> redhat-rpm-config-0:45-1.fc25.noarch
> 
> The problem is, when start to install fedpkg, koji-1.10 is resolved
> rather than version 1.13
> 
> [root@e151b05870c7 pkgs]# dnf install fedpkg
> Last metadata expiration check: 0:10:38 ago on Sat Aug 12 02:25:14 2017.
> Dependencies resolved.
> 
>  Package   Arch   Version
>Repository   Size
> 
> Installing:
> ...
>  koji  noarch 1.10.1-13.fc25
>fedora  279 k
> ...
> 
> This problem does not affect fedpkg but also other packages, e.g.
> bodhi-client and packagedb-cli, that has "Requires: koji" in SPEC
> file. I created a fake package with only koji in Requires, this
> problem can also be reproduced with it.

Your analysis is incomplete. It's not sufficient to claim there is an
issue. "Requires: koji" is non-versioned, so the depsolver behaviour is
implementation dependent. It may pull in _either_ build of the koji package
to satisfy the dependencies. There is no rule [yet] that would pull in the
latest EVR of a package already when installing it for the first time. Yum
hasn't done it, with its author refusing to change that behaviour, and DNF
probably mimics that behaviour. A subsequent "dnf update" may update koji
immediately. Have you tested that?

Further, it is absolutely normal that some packages exist in the repos
with multiple builds. For example, the initial release in the [fedora]
repo, an update in the [updates] repo, and for several years in the past,
older repository maintenance tools have kept multiple builds in the repos.
That could become the default again in the future.

And finally, it could be that there's a real issue that would require a
detailed look at the packages, which may cause dnf to not choose the
latest koji for the initial transaction set.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org