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

2017-08-13 Thread Chenxiong Qi 
On Sat, 2017-08-12 at 10:10 +0200, Michael Schwendt wrote:
> 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

Tested `dnf install fedpkg' in Fedora 26, koji-1.13 can be resolved
from updates repository. Why does dnf behave differently?

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

I haven't tested it yet, because it make no sense as `dnf install
fedpkg' fails due to the conflict between python2-koji and koji-1.10.

In Fedora 25, koji-1.13 can be resolved when `dnf install koji'. So,
there is a workaround that is to install koji in advance, then fedpkg.

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

2017-08-13 Thread Kevin Kofler 
Dominik 'Rathann' Mierzejewski wrote:
> It also needs some patching, because each library has a different
> SONAME.

Symlinking
libblas.so.3 → libopenblas.so.0
liblapack.so.3 → libopenblas.so.0
is enough to get things linked against BLAS and/or LAPACK to pick up 
OpenBLAS instead. A similar symlinking should work for the -devel package. 
If the symlinks confuse ldconfig or cause some other issues, linker scripts 
can be used instead.

> I think atlas used to provide a drop-in replacement, but it was abandoned

Ouch! Indeed, the current ATLAS packages provide only libsatlas and 
libtatlas, no libblas or liblapack. This is a regression and should never 
have been packaged that way. Now all the packages end up with the 
unoptimized reference BLAS. (In fact, I think I already noticed that when it 
happened and complained loudly about it, but was ignored, as it seems. 
Sigh!)

That said, ATLAS should really go away, unless they add support for runtime 
CPU detection and the result matches or exceeds OpenBLAS performance. In its 
current state (which has been the state since its inception), ATLAS is 
really unsuitable for distribution packaging. They just do not care about 
binary packages, at all.

> on the premise that scientific codes are compiled specifically for their
> target clusters anyway

… which is of course not true for distribution packages!

> and Intel's math library (MKL) doesn't provide a drop-in replacement.

… which is entirely irrelevant.

It is the job of the distribution to ensure that software uses the most 
efficient BLAS/LAPACK implementation available. Other distributions ship 
symlinks ensuring that. The current packaging in Fedora is horrible.

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?

2017-08-13 Thread Dominik 'Rathann' Mierzejewski 
On Sunday, 13 August 2017 at 14:58, Matthew Miller wrote:
> On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
> > Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
> > i.e., having symlinks or linker scripts pointing at least libblas.so and 
> > liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
> > liblapack.so.3 so that no rebuilds are necessary and so that things using 
> > dlopen and third-party binary blobs also use OpenBLAS?
> > 
> > The current situation where we have 3 different BLAS implementations and 
> > where for most programs, depending on your setup, you get either the worst 
> > one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
> > architecture), but never the best one (OpenBLAS with runtime CPU 
> > detection), 
> > is a mess.
> 
> This sounds like a good idea (and worthy of a Change). I hate to
> suggest Alternatives but maybe it's appropriate here? 

It also needs some patching, because each library has a different
SONAME. I think atlas used to provide a drop-in replacement, but
it was abandoned on the premise that scientific codes are compiled
specifically for their target clusters anyway and Intel's math library
(MKL) doesn't provide a drop-in replacement.

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: glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

2017-08-13 Thread Kevin Kofler 
Florian Weimer wrote:
> It's not there if you don't use glibc.

FreeBSD also has an xlocale.h, and the manpage claims Darwin has one too:
https://www.freebsd.org/cgi/man.cgi?query=xlocale=3

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

Re: Unable to bring new package to bodhi

2017-08-13 Thread Randy Barlow 
On 08/13/2017 11:02 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Aug 13, 2017 at 04:45:57AM -, Andrew Toskin wrote:
>> 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.
> There's a bug open for that, I saw the link posted recently.
> You can paste the full nevr string into the "candidate builds" field, and
> that works.

Indeed: https://github.com/fedora-infra/bodhi/issues/1731

This is planned to be fixed in the upcoming 2.10.0 release.



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: Unable to push update

2017-08-13 Thread Randy Barlow 
On 08/10/2017 06:46 PM, Ravindra Kumar wrote:
> I forgot to mention that Bodhi web interface did not offer any
> suggestions when I typed 'open-vm-tools' package name. This was bit
> surprising and I could not use Bodhi web interface as a workaround.

This is a known issue and is planned to be fixed with Bodhi 2.10.0:

https://github.com/fedora-infra/bodhi/issues/1731

The workaround is that you can manually type nvrs and bug numbers.



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: glibc-headers no longer provides xlocale.h in 2.26 (rawhide)?

2017-08-13 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Aug 13, 2017 at 09:21:35PM +0200, Florian Weimer wrote:
> On 08/12/2017 04:00 PM, 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" ;)
> 
> It's not there if you don't use glibc.
gcc has Requires: glibc-devel...

> Anyway, I was really surprised to learn that systemd sprouted an
> #include .  Looks like that it was introduced in this commit:
> 
> commit 11c3a36649e5e5e77db499c92f3cdcbd619efd3a
> Author: Thomas Hindoe Paaboel Andersen 
> Date:   Mon Nov 30 21:43:37 2015 +0100
> 
> basic: include only what we use
> 
> This is a cleaned up result of running iwyu but without forward
> declarations on src/basic.
> 
> iwyu (“include what you use”,
> )
> apparently produced misleading/incorrect results in this case.  That's
> annoying. I wonder if we can do anything about it.  It doesn't look like
> it can automatically ignore bits/ headers in its edits. 8-(

Sure, it was easy enough to fix when the issue was discovered.
But this is a good example why the issue happens in many packages:
a seemingly-harmless import from a package which is known for
stability and which was already required to be present suddenly
stopped working. No warning was emitted before, and most people don't
look into system header files unless there have some good reason.

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

Fedora Rawhide-20170813.n.0 compose check report

2017-08-13 Thread 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: 49/137 (x86_64), 3/18 (i386), 1/2 (arm)

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

ID: 128831  Test: x86_64 Server-dvd-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/128831
ID: 128859  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/128859
ID: 128861  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/128861
ID: 128864  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128864
ID: 128913  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/128913
ID: 128917  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/128917
ID: 128918  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/128918
ID: 128927  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/128927
ID: 128928  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/128928

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

ID: 128828  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/128828
ID: 128829  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/128829
ID: 128830  Test: x86_64 Server-dvd-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/128830
ID: 128832  Test: x86_64 Server-dvd-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/128832
ID: 128833  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/128833
ID: 128836  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/128836
ID: 128838  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/128838
ID: 128841  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/128841
ID: 128842  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/128842
ID: 128848  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128848
ID: 128849  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128849
ID: 128850  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128850
ID: 128863  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/128863
ID: 128865  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128865
ID: 128867  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128867
ID: 128878  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/128878
ID: 128880  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/128880
ID: 128882  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/128882
ID: 128883  Test: x86_64 Workstation-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/128883
ID: 128884  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/128884
ID: 128892  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/128892
ID: 128899  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128899
ID: 128900  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/128900
ID: 128901  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/128901
ID: 128902  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/128902
ID: 128904  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/128904
ID: 128905  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/128905
ID: 128906  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/128906
ID: 128907  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/128907
ID: 128908  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/128908
ID: 128909  Test: x86_64 universal upgrade_2_kde_64bit
URL:

[389-devel] Please review: [lib389] Issue 92 - display_attr() should return str not bytes in py3

2017-08-13 Thread Ilias Stamatis 
https://pagure.io/lib389/issue/92

https://pagure.io/lib389/issue/raw/files/fbf7fd8ed7bac76150bd05232868bfcc78faad19638b6b7954150e710e7be9a5-0001-Issue-92-display_attr-should-return-str-not-bytes-in.patch
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

2017-08-13 Thread Miro Hrončok 



On 12.8.2017 17:15, Zbigniew Jędrzejewski-Szmek wrote:

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,


Note that we have reduced the list of the packages on Friday quite a 
lot. Could you please update the blacklist?




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

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

2017-08-13 Thread Florian Weimer 
On 08/12/2017 04:00 PM, 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" 
> ;)

It's not there if you don't use glibc.

Anyway, I was really surprised to learn that systemd sprouted an
#include .  Looks like that it was introduced in this commit:

commit 11c3a36649e5e5e77db499c92f3cdcbd619efd3a
Author: Thomas Hindoe Paaboel Andersen 
Date:   Mon Nov 30 21:43:37 2015 +0100

basic: include only what we use

This is a cleaned up result of running iwyu but without forward
declarations on src/basic.

iwyu (“include what you use”,
)
apparently produced misleading/incorrect results in this case.  That's
annoying. I wonder if we can do anything about it.  It doesn't look like
it can automatically ignore bits/ headers in its edits. 8-(

Thanks,
Florian
___
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

2017-08-13 Thread Christoph Junghans 
2017-08-13 11:16 GMT-06:00 Pierre-Yves Chibon :
> On Fri, Aug 11, 2017 at 03:52:59PM -0500, Wart wrote:
>> On 08/11/2017 09:57 AM, Pierre-Yves Chibon wrote:
>> > On Fri, Aug 11, 2017 at 10:17:59AM -, Martin Gansser wrote:
>> >> 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
>> >>
>> >> on f25 branch: I don't know what happens.
>> >>
>> >> $ git push --set-upstream origin f25
>> >> Total 0 (delta 0), reused 0 (delta 0)
>> >> remote: FATAL: C refs/heads/f25 rpms/nuvola-app-mixcloud martinkg DENIED 
>> >> by refs/heads/f[0-9][0-9]
>> >> remote: error: hook declined to update refs/heads/f25
>> >> To ssh://pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud
>> >>  ! [remote rejected] f25 -> f25 (hook declined)
>> >> error: failed to push some refs to 
>> >> 'ssh://marti...@pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud'
>> >
>> > Basically, in order to prevent people from creating an epel8 branches we 
>> > only
>> > apply the same restrictions as before (no fXX or elXX or epelXX or olpcXX
>> > branches that are not whitelisted.
>> > But the script that whitelist these branches but putting them into PDC 
>> > doesn't
>> > ask pagure to refresh its config, so PDC is up to date but not pagure, 
>> > until
>> > that project's config gets updated.
>> >
>> > We're working on allowing the script run by the admin to trigger a refresh 
>> > of
>> > the config of a certain project so that right after creating the branch in 
>> > pdc
>> > it can ask pagure to refresh the corresponding config.
>> > In the mean time admins have a way to manually ask that a projet be 
>> > refreshed so
>> > feel free to reach out if needed.
>>
>> I'm getting a similar error when trying to create the epel7 branch for
>> tcl-tclnagios:
>
> Refresh in progress, sorry for the delay.
Worked! Thank for working on the weekend.

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



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 27 Rawhide 20170811.n.2 nightly compose nominated for testing

2017-08-13 Thread rawhide 
Announcing the creation of a new nightly release validation test event
for Fedora 27 Rawhide 20170811.n.2. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
pungi - 20170804.n.1: pungi-4.1.17-3.fc27.src, 20170811.n.2: 
pungi-4.1.17-4.fc27.src
pyparted - 20170804.n.1: pyparted-3.11.0-2.fc27.src, 20170811.n.2: 
pyparted-3.11.0-5.fc27.src
anaconda - 20170804.n.1: anaconda-27.19-2.fc27.src, 20170811.n.2: 
anaconda-27.19-6.fc27.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/27

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_User:Adamwill/NoMoreAlpha/Server
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_27_Rawhide_20170811.n.2_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] 2017-08-14 @ 15:00 UTC - Fedora QA Meeting

2017-08-13 Thread Adam Williamson 
# Fedora Quality Assurance Meeting
# Date: 2017-08-14
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's time for another meeting! Let's see where we stand for F27 and
so on.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 27 status
3. Test Day status
4. Onboarding status
5. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
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

2017-08-13 Thread Pierre-Yves Chibon 
On Fri, Aug 11, 2017 at 03:52:59PM -0500, Wart wrote:
> On 08/11/2017 09:57 AM, Pierre-Yves Chibon wrote:
> > On Fri, Aug 11, 2017 at 10:17:59AM -, Martin Gansser wrote:
> >> 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
> >>
> >> on f25 branch: I don't know what happens.
> >>
> >> $ git push --set-upstream origin f25
> >> Total 0 (delta 0), reused 0 (delta 0)
> >> remote: FATAL: C refs/heads/f25 rpms/nuvola-app-mixcloud martinkg DENIED 
> >> by refs/heads/f[0-9][0-9]
> >> remote: error: hook declined to update refs/heads/f25
> >> To ssh://pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud
> >>  ! [remote rejected] f25 -> f25 (hook declined)
> >> error: failed to push some refs to 
> >> 'ssh://marti...@pkgs.fedoraproject.org/rpms/nuvola-app-mixcloud'
> > 
> > Basically, in order to prevent people from creating an epel8 branches we 
> > only
> > apply the same restrictions as before (no fXX or elXX or epelXX or olpcXX
> > branches that are not whitelisted.
> > But the script that whitelist these branches but putting them into PDC 
> > doesn't
> > ask pagure to refresh its config, so PDC is up to date but not pagure, until
> > that project's config gets updated.
> > 
> > We're working on allowing the script run by the admin to trigger a refresh 
> > of
> > the config of a certain project so that right after creating the branch in 
> > pdc
> > it can ask pagure to refresh the corresponding config.
> > In the mean time admins have a way to manually ask that a projet be 
> > refreshed so
> > feel free to reach out if needed.
> 
> I'm getting a similar error when trying to create the epel7 branch for
> tcl-tclnagios:

Refresh in progress, sorry for the delay.


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

Re: Self-introduction

2017-08-13 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Aug 11, 2017 at 02:13:16PM +0200, Miro Hrončok wrote:
> On 11.8.2017 08:25, Elliott Sales de Andrade wrote:
> >Hello,
> >
> >My name is Elliott, but you may know me as QuLogic on
> >IRC/FAS/GitHub/etc. I am interested in Python 3 porting,
> >scientific libraries, Jupyter, etc., some of which you can find in
> >my coprs [1]. I am also an upstream developer on libraries such as
> >Matplotlib and Cartopy.
> >
> >I have opened a few review requests for such things:
> >* python-click-plugins: https://bugzilla.redhat.com/show_bug.cgi?id=1468873
> >* python-descartes: https://bugzilla.redhat.com/show_bug.cgi?id=1468872
> >* python-fiona: https://bugzilla.redhat.com/show_bug.cgi?id=1468877
> >* python-geopandas: https://bugzilla.redhat.com/show_bug.cgi?id=1468995
> >
> >Any reviews on these packages would be greatly appreciated. I am
> >also looking for a sponsor. I have left a comment referencing some
> >informal review work I've done on all the above bugs.
> 
> Hi Elliott,
> I may be able to sponsor you, but I'm busy with Fedora 27 change
> deadlines for now. Ping me in a week if you cannot find a sponsor by
> then.

Hi Elliott and Miro,

I looked over QuLogic's review requests and reviews, and sponsored him.

Elliott, welcome to Fedora. Have fun and use your powers for good ;)
If you have any questions or issues feel free to write to bug me, I'll
do my best to help.

I approved three of your packages. I don't know if you have been
following #fedora-devel and the mailing list closely, but we are in
the process of switching to pagure as the frontend for spec files, and
various issues with have been reported with the process of creating
new packages. You probably should install the latest built fedrepo-req
and ask on #fedora-devel if you encounter any issues.

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

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

2017-08-13 Thread Orion Poplawski 

On 08/13/2017 04:09 AM, Panu Matilainen wrote:

On 08/12/2017 06:29 PM, Orion Poplawski wrote:

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.



Right, based on a quick look it seems to be caused by the recently added

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

2017-08-13 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Aug 13, 2017 at 07:07:31AM -0500, Richard Shaw wrote:
> On Sun, Aug 13, 2017 at 3:52 AM, Antonio Trande 
> wrote:
> 
> >
> > Will 'xlocale.h' be provided newly in 'glibc'?
> > To fix this problem, i set 'xlocale.h' from 'libcxx-devel' package:
> > https://src.fedoraproject.org/rpms/icecat/c/153d3b4c3df56eb1330c0530220fd3
> > 882501028a?branch=master
> 
> 
> I saw that libcxx-devel provided the file as well but I didn't investigate
> further to see if was appropriate to use...
> 
> Looking at the case of OCE is assumes it's available on OSX and Linux,
> doesn't look like it's absolutely required so I'm patching around it for
> now.

Did you try to:
1. just remove the xlocale.h include (usually this just works)
2. replace it with locale.h include
?

xlocale.h is usually included for locale_t, and locale.h provides that.

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

Re: Unable to bring new package to bodhi

2017-08-13 Thread Zbigniew Jędrzejewski-Szmek 
On Sun, Aug 13, 2017 at 04:45:57AM -, Andrew Toskin wrote:
> 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.

There's a bug open for that, I saw the link posted recently.
You can paste the full nevr string into the "candidate builds" field, and
that works.

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

2017-08-13 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1283764



--- Comment #10 from Harald Reindl  ---
it's not

[root@testserver:~]$ cat messages
Aug 13 14:32:35 testserver systemd: Starting Cleanup of Temporary
Directories...
Aug 13 14:32:36 testserver systemd: Started Cleanup of Temporary Directories.
Aug 13 14:39:25 testserver perl: Use of uninitialized value in numeric eq (==)
at /usr/share/perl5/vendor_perl/File/Tail.pm line 392.

[root@testserver:~]$ rpm -qa | grep -i perl | grep -i tail
perl-File-Tail-1.3-7.fc25.noarch

[root@testserver:~]$ rpm -q --info perl-File-Tail-1.3-7.fc25.noarch
Name: perl-File-Tail
Version : 1.3
Release : 7.fc25
Architecture: noarch
Install Date: Sat Aug 12 19:12:15 2017
Group   : Development/Libraries
Size: 39612
License : GPL+ or Artistic
Signature   : RSA/SHA256, Wed Aug  9 03:29:54 2017, Key ID 4089d8f2fdb19c98
Source RPM  : perl-File-Tail-1.3-7.fc25.src.rpm
Build Date  : Tue Aug  8 19:51:35 2017
Build Host  : buildvm-armv7-05.arm.fedoraproject.org
Relocations : (not relocatable)
Packager: Fedora Project
Vendor  : Fedora Project
URL : http://search.cpan.org/dist/File-Tail/
Summary : Perl extension for reading from continously updated files

-- 
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: Is it possible atlas is linked wrongly by new binutils?

2017-08-13 Thread Matthew Miller 
On Sun, Aug 13, 2017 at 11:01:04AM +0200, Kevin Kofler wrote:
> Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
> i.e., having symlinks or linker scripts pointing at least libblas.so and 
> liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
> liblapack.so.3 so that no rebuilds are necessary and so that things using 
> dlopen and third-party binary blobs also use OpenBLAS?
> 
> The current situation where we have 3 different BLAS implementations and 
> where for most programs, depending on your setup, you get either the worst 
> one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
> architecture), but never the best one (OpenBLAS with runtime CPU detection), 
> is a mess.

This sounds like a good idea (and worthy of a Change). I hate to
suggest Alternatives but maybe it's appropriate here? 

-- 
Matthew Miller

Fedora Project Leader
___
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)?

2017-08-13 Thread Richard Shaw 
On Sun, Aug 13, 2017 at 3:52 AM, Antonio Trande 
wrote:

>
> Will 'xlocale.h' be provided newly in 'glibc'?
> To fix this problem, i set 'xlocale.h' from 'libcxx-devel' package:
> https://src.fedoraproject.org/rpms/icecat/c/153d3b4c3df56eb1330c0530220fd3
> 882501028a?branch=master


I saw that libcxx-devel provided the file as well but I didn't investigate
further to see if was appropriate to use...

Looking at the case of OCE is assumes it's available on OSX and Linux,
doesn't look like it's absolutely required so I'm patching around it for
now.

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

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

2017-08-13 Thread Panu Matilainen 

On 08/12/2017 06:29 PM, Orion Poplawski wrote:

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.



Right, based on a quick look it seems to be caused by the recently added 
single/double quoting support for macro arguments.


IIRC

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

2017-08-13 Thread Kevin Kofler 
Dominik 'Rathann' Mierzejewski wrote:
> Yes, you don't need to add -L%{_libdir}/atlas to LDFLAGS anymore and you
> link with -lopenblas.

Can't we make it a drop-in replacement for reference BLAS/LAPACK and ATLAS, 
i.e., having symlinks or linker scripts pointing at least libblas.so and 
liblapack.so to libopenblas.so.*, ideally also libblas.so.3 and 
liblapack.so.3 so that no rebuilds are necessary and so that things using 
dlopen and third-party binary blobs also use OpenBLAS?

The current situation where we have 3 different BLAS implementations and 
where for most programs, depending on your setup, you get either the worst 
one (reference BLAS) or a suboptimal one (ATLAS compiled for the baseline 
architecture), but never the best one (OpenBLAS with runtime CPU detection), 
is a mess.

Kevin Kofler
___
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)?

2017-08-13 Thread Antonio Trande 
On 08/13/2017 01:20 AM, Sérgio Basto wrote:
> 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
> 

Will 'xlocale.h' be provided newly in 'glibc'?
To fix this problem, i set 'xlocale.h' from 'libcxx-devel' package:
https://src.fedoraproject.org/rpms/icecat/c/153d3b4c3df56eb1330c0530220fd3882501028a?branch=master

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

[Bug 1480568] Upgrade perl-libintl-perl to 1.27

2017-08-13 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=1480568

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-libintl-perl-1.27-1.fc
   ||27
 Resolution|--- |RAWHIDE
Last Closed||2017-08-13 04:31:46



--- Comment #1 from Emmanuel Seyman  ---
Done in rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=954713

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

eseyman pushed to perl-libintl-perl (master). "Update to 1.27"

2017-08-13 Thread notifications 
From f846f5dbc4cab42b31b62665806d0251c672757b Mon Sep 17 00:00:00 2001
From: Emmanuel Seyman 
Date: Aug 13 2017 07:58:29 +
Subject: Update to 1.27


---

diff --git a/.gitignore b/.gitignore
index 1d5bb18..eca551c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /libintl-perl-1.25.tar.gz
 /libintl-perl-1.26.tar.gz
+/libintl-perl-1.27.tar.gz
diff --git a/libintl-perl-1.26-Fix-building-on-Perl-without-.-in-INC.patch 
b/libintl-perl-1.26-Fix-building-on-Perl-without-.-in-INC.patch
deleted file mode 100644
index c74e7f2..000
--- a/libintl-perl-1.26-Fix-building-on-Perl-without-.-in-INC.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 70ca3b6f3e6b02bec419e944a937fd1b19b0decc Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
-Date: Mon, 15 May 2017 14:26:38 +0200
-Subject: [PATCH] Fix building on Perl without "." in @INC
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-CPAN RT#120446
-
-Signed-off-by: Petr Písař 

- Makefile.PL | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/Makefile.PL b/Makefile.PL
-index 898040d..5b25425 100644
 a/Makefile.PL
-+++ b/Makefile.PL
-@@ -182,7 +182,7 @@ sub tools_other
-   my $fragment = $self->SUPER::tools_other (@_);
- 
-   $fragment =~ s/^MOD_INSTALL\s*=\s*(.*?)-MExtUtils::Install
--  /MOD_INSTALL =$1-MMyInstall/msx;
-+  /MOD_INSTALL =$1-I. -MMyInstall/msx;
- 
-   return $fragment;
- }
--- 
-2.9.4
-
diff --git a/perl-libintl-perl.spec b/perl-libintl-perl.spec
index a263560..8e8bd53 100644
--- a/perl-libintl-perl.spec
+++ b/perl-libintl-perl.spec
@@ -1,7 +1,7 @@
 Summary:Internationalization library for Perl, compatible with gettext
 Name:   perl-libintl-perl
-Version:1.26
-Release:6%{?dist}
+Version:1.27
+Release:1%{?dist}
 # gettext_xs/gettext_xs.pm: GPLv3+
 # gettext_xs/Makefile.PL:   LGPLv2+
 # lib/Locale/gettext_xs.pod:LGPLv2+
@@ -11,8 +11,6 @@ Release:6%{?dist}
 License:GPLv3+ and LGPLv2+
 URL:http://search.cpan.org/dist/libintl-perl/
 Source: 
http://search.cpan.org/CPAN/authors/id/G/GU/GUIDO/libintl-perl-%{version}.tar.gz
-# Fix building on Perl without "." in @INC, CPAN RT#120446
-Patch0: libintl-perl-1.26-Fix-building-on-Perl-without-.-in-INC.patch
 # this module was renamed in the f25 dev cycle
 Provides:   perl-libintl = %{version}-%{release}
 Obsoletes:  perl-libintl < 1.25
@@ -71,7 +69,6 @@ implemented for example in GNU gettext.
 
 %prep
 %setup -q -n libintl-perl-%{version}
-%patch0 -p1
 find -type f -exec chmod -x {} \;
 find lib/Locale gettext_xs \( -name '*.pm' -o -name '*.pod' \) \
 -exec sed -i -e '/^#! \/bin\/false/d' {} \;
@@ -106,6 +103,10 @@ make test
 %{_mandir}/man?/*
 
 %changelog
+* Sun Aug 13 2017 Emmanuel Seyman  - 1.27-1
+- Update to 1.27
+- Drop upstreamed patch
+
 * Thu Aug 03 2017 Fedora Release Engineering  - 
1.26-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
 
diff --git a/sources b/sources
index b0be71b..a42fc4f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d355998f5f33a6f4202cd7ded7bf052a  libintl-perl-1.26.tar.gz
+SHA512 (libintl-perl-1.27.tar.gz) = 
538673a66a2fbe50c7571c558d64dc20f16ca4663174ab6551c76fa3923962432762eeda3fee8f17d9632941587239b06bb5b351222d4e7bfaffdc74740ece4c



https://src.fedoraproject.org/rpms/perl-libintl-perl/c/f846f5dbc4cab42b31b62665806d0251c672757b?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

eseyman uploaded libintl-perl-1.27.tar.gz for perl-libintl-perl

2017-08-13 Thread notifications 
538673a66a2fbe50c7571c558d64dc20f16ca4663174ab6551c76fa3923962432762eeda3fee8f17d9632941587239b06bb5b351222d4e7bfaffdc74740ece4c
  libintl-perl-1.27.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-libintl-perl/libintl-perl-1.27.tar.gz/sha512/538673a66a2fbe50c7571c558d64dc20f16ca4663174ab6551c76fa3923962432762eeda3fee8f17d9632941587239b06bb5b351222d4e7bfaffdc74740ece4c/libintl-perl-1.27.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org