date:20170214

On Tue, 2017-02-14 at 15:55 -0800, Adam Williamson wrote:
> I'm trying to clean up all the appropriate bits in Pagure, READMEs,
> wiki, ansible tasks etc. this afternoon. If it doesn't all look to be
> in line tomorrow AM, please do let me know (or just go ahead and fix
> anything straightforward you find that I've overlooked). Yes, I know
> that right now the fedora_openqa README references a 'Fedora openQA
> wiki page' that doesn't exist, I'm planning to write it soon, and move
> the 'how to install openQA' content from openqa_fedora_tools into it.

Here it is: https://fedoraproject.org/wiki/openQA
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

[Bug 1421884] ctstream-26 is available

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



--- Comment #7 from Fedora Update System  ---
ctstream-26-1.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2017-87acdfeb34

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

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

2017-02-14 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 709  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 471  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 190  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
 173  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-cf95057959   
viewvc-1.1.26-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-0f3297a19b   
nagios-4.2.4-2.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e2cea1c22d   
python-cjson-1.1.0-9.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-920059d2ed   
mingw-wavpack-5.1.0-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d5fe44714a   
cacti-1.0.2-1.el7


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

caja-actions-1.8.2-1.el7
cargo-0.16.0-2.el7
ctstream-26-1.el7
devscripts-2.17.1-3.el7
dh-autoreconf-13-2.el7
irda-utils-0.9.18-18.el7
janino-2.7.8-8.el7
ocserv-0.11.7-2.el7
pbuilder-0.228.3-2.el7
pcre2-10.21-13.el7
perl-Git-Wrapper-0.047-3.el7
perl-Parse-DebControl-2.005-10.el7
python-ase-3.13.0-1.el7
python-msrest-0.4.5-1.el7
rust-1.15.1-2.el7
texlive-extension-2012-51.el7
wkhtmltopdf-0.12.4-1.el7

Details about builds:



 caja-actions-1.8.2-1.el7 (FEDORA-EPEL-2017-fd0f1984d0)
 Caja extension for customizing the context menu

Update Information:

- update to 1.8.2




 cargo-0.16.0-2.el7 (FEDORA-EPEL-2017-f9554c9ddb)
 Rust's package manager and build tool

Update Information:

New versions of Rust and Cargo -- see the release notes for [1.15](https://blog
.rust-lang.org/2017/02/02/Rust-1.15.html) and [1.15.1](https://blog.rust-
lang.org/2017/02/09/Rust-1.15.1.html).  This update also adds builds for ppc64
and ppc64le.




 ctstream-26-1.el7 (FEDORA-EPEL-2017-87acdfeb34)
 Get URLs of Czech Television video streams

Update Information:

This release adapts to changes in the server.

References:

  [ 1 ] Bug #1421884 - ctstream-26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1421884




 devscripts-2.17.1-3.el7 (FEDORA-EPEL-2017-c837a68c52)
 Scripts for Debian Package maintainers

Update Information:

Add pbuilder to epel7, devscripts and dependencies.




 dh-autoreconf-13-2.el7 (FEDORA-EPEL-2017-43496f6ce3)
 debhelper add-on to call autoreconf and clean up after the build

Update Information:

Add dh-autoreconf to epel7




 irda-utils-0.9.18-18.el7 (FEDORA-EPEL-2017-916fd6c9d5)
 Utilities for infrared communication between devices

Update Information:

re-enable smcinit (#1421387)

References:

  [ 1 ] Bug #1421387 - cannot connect a MCS7780 USB IR adapter
https://bugzilla.redhat.com/show_bug.cgi?id=1421387




 janino-2.7.8-8.el7 (FEDORA-EPEL-2017-ba208b8711)
 An embedded Java compiler

Update Information:

Package janino 2.7.8 for EPEL7

Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users

2017-02-14 Thread Mamoru TASAKA



- 元のメッセージ -
> 差出人: "Neal Gompa" 
> 宛先: "Development discussions related to Fedora" 
> 
> 送信済み: 2017年2月15日, 水曜日 12:10:13
> 件名: Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users
> 
> On Tue, Feb 14, 2017 at 8:20 PM, Adam Williamson
>  wrote:
> > On Tue, 2017-02-14 at 22:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> >> On Tue, Feb 14, 2017 at 02:56:28PM -0500, Mohan Boddu wrote:
> >> > Hi all,
> >> >
> >> > Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
> >> > on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:
> >>
> >> systemd failed to rebuild. There were a couple of issues, but it's the
> >> last one that's interesting. gnutls and µhttpd dependencies are not
> >> detected properly:
> >>
> >> $ rpm -q gnutls-devel
> >> gnutls-devel-3.5.9-1.fc26.x86_64
> >> $ "/usr/bin/pkg-config" "--cflags" "gnutls" || echo "NOT OK"
> >> Package libidn2 was not found in the pkg-config search path.
> >> ...
> >> NOT OK
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1422256
> >>
> >> I assume that might impact any package which uses pkg-config
> >> to detect gnutls or libµhttpd.
> >
> > This is quite likely to be due to
> > https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
> 
> No. I *just* grabbed systemd-232-14.fc26 and rebuilt it locally using
> the koji repos for rawhide, and it detected everything fine and ran. I
> do not know why it failed during the mass rebuild, but it works fine
> now, even with gnutls-devel-3.5.9-1.fc26.
> 
> pkgconf is not the one that caused the issue.

This is because systemd added the workaround for this, see:
http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?id=6353553a5766c8144dfe82e6dc6b49c61fbf8522

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

Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users

2017-02-14 Thread Neal Gompa

On Tue, Feb 14, 2017 at 8:20 PM, Adam Williamson
 wrote:
> On Tue, 2017-02-14 at 22:22 +, Zbigniew Jędrzejewski-Szmek wrote:
>> On Tue, Feb 14, 2017 at 02:56:28PM -0500, Mohan Boddu wrote:
>> > Hi all,
>> >
>> > Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
>> > on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:
>>
>> systemd failed to rebuild. There were a couple of issues, but it's the
>> last one that's interesting. gnutls and µhttpd dependencies are not
>> detected properly:
>>
>> $ rpm -q gnutls-devel
>> gnutls-devel-3.5.9-1.fc26.x86_64
>> $ "/usr/bin/pkg-config" "--cflags" "gnutls" || echo "NOT OK"
>> Package libidn2 was not found in the pkg-config search path.
>> ...
>> NOT OK
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1422256
>>
>> I assume that might impact any package which uses pkg-config
>> to detect gnutls or libµhttpd.
>
> This is quite likely to be due to
> https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation

No. I *just* grabbed systemd-232-14.fc26 and rebuilt it locally using
the koji repos for rawhide, and it detected everything fine and ran. I
do not know why it failed during the mass rebuild, but it works fine
now, even with gnutls-devel-3.5.9-1.fc26.

pkgconf is not the one that caused the issue.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 26 Mass Rebuild

2017-02-14 Thread Kevin Fenzi

On Wed, 15 Feb 2017 01:42:58 +
Sérgio Basto  wrote:

> JFTR , after receive from koschei messages like opencv's builds are
> back to normal in Fedora Rawhide
> 
> I did git checkout master; git pull; fedpkg build and resend to
> build frei0r-plugins, mlt, opencv , php-facedetect , which builds
> without any modifications 
> 
> All builds failed with : 
> DEBUG util.py:435:  Error: nothing provides libgfortran.so.3()(64bit)
> needed by openblas-openmp-0.2.19-4.fc26.x86_64 [1] .
> 
> 2 ideas, first before begin these kind of mass rebuild, we should
> avoid broken deps somehow, second resubmit builds that failed by this
> broken dep also is not a bad ideia . 

Sadly not practical. 

If we wanted until there were no broken deps to fire off a mass
rebuild, we would basically never do them. 

Resubmitting wouldn't help any until openblas was successfully rebuilt,
which only happened yesterday. :( Additionally the mass rebuild is in a
side tag that doesn't update the buildroot, so it wouldn't help to
rebuild anything again as the buildroot would be the same as before. 

kevin

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

Re: Fedora mass rebuild 2017

2017-02-14 Thread Orcan Ogetbil

On 7 February 2017 at 16:32, Marek Polacek  wrote:
> libffado-2.3.0-1.fc26.src.rpm
> sflphone-1.4.1-20.fc26.src.rpm
> error: no matching function for call to ...
> Invalid code.

I am 99% sure that these 2 errors are due to a bug in dbus-c++. Is the
new compiler attempting to compile (or verify) code in template
classes even if they are not initialized? I suspect that there is
broken code in the Threading class.

log:
-
usr/include/dbus-c++-1/dbus-c++/dispatcher.h:262:5: error: no matching
function for call to '_init_threading(DBus::Mutex* (&)(), void
(&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*),
DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*,
DBus::Mutex*, int), void (&)(DBus::CondVar*), void
(&)(DBus::CondVar*))'
 );
 ^
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note: candidate:
void DBus::_init_threading()
 void DXXAPI _init_threading();
 ^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:247:13: note:
candidate expects 0 arguments, 10 provided
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note: candidate:
void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn,
DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn,
DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn,
DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) 
 void DXXAPI _init_threading(
 ^~~
/usr/include/dbus-c++-1/dbus-c++/dispatcher.h:249:13: note:
conversion of argument 3 would be ill-formed:
-

see:
http://dbus-cplusplus.sourceforge.net/dispatcher_8h_source.html

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

Re: Fedora 26 Mass Rebuild

2017-02-14 Thread Sérgio Basto

On Ter, 2017-02-14 at 14:56 -0500, Mohan Boddu wrote:
> 
> Hi all,
> 
> Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
> on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:
> 
> https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_i
> mplementation
> https://fedoraproject.org/wiki/Changes/GCC7
> https://fedoraproject.org/wiki/Changes/Fedora26CFlags
> https://fedoraproject.org/wiki/Changes/golang1.8
> https://fedoraproject.org/wiki/Changes/golang-buildmode-pie.
> 
> Mass rebuild was done in a side tag (f26-rebuild) and moved over to
> f26.
> 
> Failures can be seen
> http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-failures.html
> 
> Things still needing rebuilt
> http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-need-rebuild.htm
> l
> 
> 16160 builds have been tagged into f26, there s currently 1299 failed
> builds that need to be addressed by the package maintainers.

JFTR , after receive from koschei messages like opencv's builds are
back to normal in Fedora Rawhide

I did git checkout master; git pull; fedpkg build and resend to
build frei0r-plugins, mlt, opencv , php-facedetect , which builds
without any modifications 

All builds failed with : 
DEBUG util.py:435:  Error: nothing provides libgfortran.so.3()(64bit)
needed by openblas-openmp-0.2.19-4.fc26.x86_64 [1] .

2 ideas, first before begin these kind of mass rebuild, we should avoid
broken deps somehow, second resubmit builds that failed by this broken
dep also is not a bad ideia . 

Best regards,

[1] 
https://kojipkgs.fedoraproject.org//work/tasks/5349/17785349/root.log


> 
> FTBFS bugs will be filed shortly.
> 
> Please be sure to let releng know if you see any bugs in the
> reporting. You can contact releng in #fedora-releng on freenode, by
> dropping an email to our list[2] or filing an issue in pagure[3]
> 
> Regards,
> Mohan Boddu.
> 
> [1] https://fedoraproject.org/wiki/Releases/26/Schedule
> [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedorap
> roject.org/
> [3] https://pagure.io/releng/
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.fedoraproj
> ect.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users

On Tue, 2017-02-14 at 22:22 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Feb 14, 2017 at 02:56:28PM -0500, Mohan Boddu wrote:
> > Hi all,
> > 
> > Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
> > on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:
> 
> systemd failed to rebuild. There were a couple of issues, but it's the
> last one that's interesting. gnutls and µhttpd dependencies are not
> detected properly:
> 
> $ rpm -q gnutls-devel
> gnutls-devel-3.5.9-1.fc26.x86_64
> $ "/usr/bin/pkg-config" "--cflags" "gnutls" || echo "NOT OK"
> Package libidn2 was not found in the pkg-config search path.
> ...
> NOT OK
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1422256
> 
> I assume that might impact any package which uses pkg-config
> to detect gnutls or libµhttpd.

This is quite likely to be due to
https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spec files maintained in external source control: please mention this in the spec file

On Tue, 2017-02-14 at 18:40 -0600, Jason L Tibbitts III wrote:
> > > > > > "AW" == Adam Williamson  writes:
> 
> AW> Hi folks! So I got bitten again today by the situation where the
> AW> primary contact for a given package considers the 'canonical' source
> AW> for the spec file to be some external SCM, and finds it a problem
> AW> when someone (e.g. a provenpackager like me...) changes the package
> AW> directly in dist-git.
> 
> But, uh, how does rel-eng do it?  Or do these maintainers all yell at
> rel-eng after every mass rebuild?

Yes, more or less. The good ones notice that the mass rebuild happened
and merge the change back. The bad ones just push back over the top of
the mass rebuild and mess stuff up.

> There are packages where people might want to request communication
> before people do work on the package.  Those packages might be
> especially complex or have special bootstrapping requirements or a
> delicate dependency chain.  That I can understand.  The spec file in
> Fedora git not being "canonical", though, is simply not a valid reason.
> For Fedora's workflow, which involves a community of package maintainers
> who expect to be able to make use of the Fedora's infrastructure and
> tools, there can be no possible alternate canonical location for the
> spec.

This is more or less my opinion, but there are those who don't agree
and have some kind of reason (such as using the same spec file to do
package builds in some other place, or wanting to maintain the spec
file for a tool alongside its source so they can easily do test package
builds as part of the tool's unit tests, etc.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Spec files maintained in external source control: please mention this in the spec file

2017-02-14 Thread Jason L Tibbitts III

> "ZJ" == Zbigniew Jędrzejewski-Szmek  writes:

ZJ> Indeed. I changed the status. (I feels a bit presumptuous to tell
ZJ> the FPC when exactly they have to discuss something, but if it's
ZJ> that's what it takes, then OK.)

trac unfortunately doesn't have any facility for auto-moving things back
from the needinfo status like bugzilla does, so occasionally things get
missed.  Trac will very soon be irrelevant for FPC-related things
anyway, but of course pagure doesn't really even have a concept of
"needinfo" at this point so we'll need to do something else.

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

Re: Spec files maintained in external source control: please mention this in the spec file

2017-02-14 Thread Jason L Tibbitts III

> "AW" == Adam Williamson  writes:

AW> Hi folks! So I got bitten again today by the situation where the
AW> primary contact for a given package considers the 'canonical' source
AW> for the spec file to be some external SCM, and finds it a problem
AW> when someone (e.g. a provenpackager like me...) changes the package
AW> directly in dist-git.

But, uh, how does rel-eng do it?  Or do these maintainers all yell at
rel-eng after every mass rebuild?

There are packages where people might want to request communication
before people do work on the package.  Those packages might be
especially complex or have special bootstrapping requirements or a
delicate dependency chain.  That I can understand.  The spec file in
Fedora git not being "canonical", though, is simply not a valid reason.
For Fedora's workflow, which involves a community of package maintainers
who expect to be able to make use of the Fedora's infrastructure and
tools, there can be no possible alternate canonical location for the
spec.

Someone who really, really wants to maintain a package in such a fashion
must be prepared to merge back every commit made to the Fedora package.

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

[Bug 1422300] perl-String-Compare-ConstantTime-0.312 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-String-Compare-ConstantTime-0.312-1.el7.src.rpm
for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=17869879

-- 
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: Fedora 26 Mass Rebuild

2017-02-14 Thread dennis



On 14 February 2017 4:30:12 pm GMT-06:00, Michael Cronenworth  
wrote:
>On 02/14/2017 01:56 PM, Mohan Boddu wrote:
>> Things still needing rebuilt
>>
>http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-need-rebuild.html
>>
>> 16160 builds have been tagged into f26, there s currently 1299 failed
>> builds that need to be addressed by the package maintainers.
>>
>> FTBFS bugs will be filed shortly.
>
>This is showing 'farstream' needs to be rebuilt when it has been
>orphaned and 
>retired two months ago. Whatever you are using to check for missed
>builds needs to 
>account for these packages.

It's not blocked in koji nor is it retired in pkgdb, it is orphaned however. So 
for everything we know it's in need of a rebuild.


>The php-zordius-lightncandy build has been running for 3 days. I'll
>cancel and look 
>at it when I have time. Koji possibly has an untold number of zombie
>processes that 
>need cleanup.

There is some builds that were restarted. Some all the processes went to sleep, 
others the test suite has caused zombies, koji will reap them when the tasks 
have been running for 48 hours.

Dennis
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1422300] perl-String-Compare-ConstantTime-0.312 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1250419
  --> https://bugzilla.redhat.com/attachment.cgi?id=1250419=edit
[patch] Update to 0.312 (#1422300)

-- 
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 1422300] New: perl-String-Compare-ConstantTime-0.312 is available

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

Bug ID: 1422300
   Summary: perl-String-Compare-ConstantTime-0.312 is available
   Product: Fedora
   Version: rawhide
 Component: perl-String-Compare-ConstantTime
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.312
Current version/release in rawhide: 0.311-3.fc25
URL: http://search.cpan.org/dist/String-Compare-ConstantTime/

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

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

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

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

-- 
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 1422298] New: perl-TAP-SimpleOutput-0.009 is available

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

Bug ID: 1422298
   Summary: perl-TAP-SimpleOutput-0.009 is available
   Product: Fedora
   Version: rawhide
 Component: perl-TAP-SimpleOutput
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.009
Current version/release in rawhide: 0.008-1.fc26
URL: http://search.cpan.org/dist/TAP-SimpleOutput/

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

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

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

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

-- 
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 1422296] New: perl-Test-Moose-More-0.043 is available

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

Bug ID: 1422296
   Summary: perl-Test-Moose-More-0.043 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Test-Moose-More
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.043
Current version/release in rawhide: 0.042-1.fc26
URL: http://search.cpan.org/dist/Test-Moose-More/

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

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

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

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

-- 
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 1422290] perl-Log-Dispatch-FileRotate-1.24 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Log-Dispatch-FileRotate-1.24-1.el7.src.rpm for
rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=17869744

-- 
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 1422290] New: perl-Log-Dispatch-FileRotate-1.24 is available

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

Bug ID: 1422290
   Summary: perl-Log-Dispatch-FileRotate-1.24 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Log-Dispatch-FileRotate
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest upstream release: 1.24
Current version/release in rawhide: 1.23-1.fc26
URL: http://search.cpan.org/dist/Log-Dispatch-FileRotate/

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

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

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

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

-- 
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 1422290] perl-Log-Dispatch-FileRotate-1.24 is available

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1250413
  --> https://bugzilla.redhat.com/attachment.cgi?id=1250413=edit
[patch] Update to 1.24 (#1422290)

-- 
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 1422289] New: perl-libwww-perl-6.19 is available

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

Bug ID: 1422289
   Summary: perl-libwww-perl-6.19 is available
   Product: Fedora
   Version: rawhide
 Component: perl-libwww-perl
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 6.19
Current version/release in rawhide: 6.18-1.fc26
URL: http://search.cpan.org/dist/libwww-perl/

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

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

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

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

-- 
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 1422283] New: perl-CPAN-2.16 is available

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

Bug ID: 1422283
   Summary: perl-CPAN-2.16 is available
   Product: Fedora
   Version: rawhide
 Component: perl-CPAN
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 2.16
Current version/release in rawhide: 2.14-4.fc26
URL: http://search.cpan.org/dist/CPAN/

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

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

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

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

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

fedora_openqa (scheduler/reporter) and createhdds split from openqa_fedora_tools, moved to Pagure

Hi folks! So continuing with the agreed plan (for openQA bits) to move
git repos to Pagure and split up openqa_fedora_tools, I've split out
and moved the scheduler/reporter library and CLI - now called
'fedora_openqa', since 'fedora_openqa_schedule' was a dumb name for a
thing that actually does more than just scheduling - and createhdds:

https://pagure.io/fedora-qa/fedora_openqa
https://pagure.io/fedora-qa/createhdds

I have renamed the Phabricator projects for the openQA tests and
scheduler too:

openqa_fedora -> os-autoinst-distri-fedora
openqa_fedora_tools -> fedora_openqa

The new names match the git repo names. Almost all the issues and diffs
for openqa_fedora_tools were really for the scheduler; for createhdds I
think we can just use Pagure issues / PRs. I will move the one
outstanding createhdds diff to Pagure manually. For fedora_openqa we
will still be using Phab for issues and diffs for now, just with the
new project name. The .arcconfig in the new repo should be correct.

I'm trying to clean up all the appropriate bits in Pagure, READMEs,
wiki, ansible tasks etc. this afternoon. If it doesn't all look to be
in line tomorrow AM, please do let me know (or just go ahead and fix
anything straightforward you find that I've overlooked). Yes, I know
that right now the fedora_openqa README references a 'Fedora openQA
wiki page' that doesn't exist, I'm planning to write it soon, and move
the 'how to install openQA' content from openqa_fedora_tools into it.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

[Bug 1421884] ctstream-26 is available

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



--- Comment #6 from Fedora Update System  ---
ctstream-26-1.fc25 has been pushed to the Fedora 25 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-99dad5a15a

-- 
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 1420957] perl-Log-Dispatch-FileRotate-1.23 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-Log-Dispatch-FileRotate-1.23-1.fc25 has been pushed to the Fedora 25
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-738c231b96

-- 
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: Intent to orphan and retire Hoard (a memory allocator)

2017-02-14 Thread Richard W.M. Jones

On Tue, Feb 14, 2017 at 09:14:22PM +, Emery Berger wrote:
> I am willing to take it over, if that is allowed,

Absolutely.  You should take a look at becoming a Fedora
packager if you're not one already:

https://fedoraproject.org/wiki/Package_maintenance_guide
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 26 Mass Rebuild

2017-02-14 Thread Michael Cronenworth


On 02/14/2017 01:56 PM, Mohan Boddu wrote:

Things still needing rebuilt
http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-need-rebuild.html

16160 builds have been tagged into f26, there s currently 1299 failed
builds that need to be addressed by the package maintainers.

FTBFS bugs will be filed shortly.


This is showing 'farstream' needs to be rebuilt when it has been orphaned and 
retired two months ago. Whatever you are using to check for missed builds needs to 
account for these packages.


The php-zordius-lightncandy build has been running for 3 days. I'll cancel and look 
at it when I have time. Koji possibly has an untold number of zombie processes that 
need cleanup.

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

Re: hardlink building issue in F26 armv7hl and i686

2017-02-14 Thread Jakub Jelinek

On Tue, Feb 14, 2017 at 11:23:43PM +0100, Jakub Jelinek wrote:
> GNU89 vs. C99 inlining, that code is really old and apparently nobody
> touched it since it has been written.
> 
> As everything is in a single file, either change all the inlines in the file
> to static inline, or turn them into extern inline (in C99/C11 that means
> if the function can't be inlined, an out of line copy is then emitted),
> or change inline into inline __attribute__((__gnu_inline__)), or compile
> with -fgnu89-inline.

Oh, and another option is inline __attribute__((__always_inline__))
(with or without gnu_inline), then you force the compiler to inline it and
so no out of line copy will be needed.

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

[Bug 1421884] ctstream-26 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
ctstream-26-1.fc24 has been pushed to the Fedora 24 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-1e1094091e

-- 
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: hardlink building issue in F26 armv7hl and i686

2017-02-14 Thread Dan Horák

On Tue, 14 Feb 2017 22:48:27 +0100 (CET)
"Francisco J. Tsao Santin"  wrote:

> On Mon, 13 Feb 2017, Dan Horák wrote:
> 
> > it could be a gcc7 bug on 32-bit arches, you can check by switching
> > to -O1 or -O0 instead of the default -O2, or by dropping "inline"
> > for stcmp()
> > 
> 
> I tested with -01 and O0, and it solves the issue partially.  If I
> drop the inlines, the program compiles ok. Thanks a lot for the
> advice :-)

you are welcome, please file a gcc bug in Fedora bugzilla for this issue


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

Re: hardlink building issue in F26 armv7hl and i686

2017-02-14 Thread Jakub Jelinek

On Mon, Feb 13, 2017 at 08:39:00PM +0100, Francisco J. Tsao Santin wrote:
> Hi all,
> 
> We have a problem with the hardlink package. The koji build made by Fedora
> Release Engineering failed in armv7hl and i686 architectures. I saw the logs
> and I tried a mock build in my own machine too, the problem is always the 
> same:
> 
> + gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 
> -march=i686 -fasynchronous-unwind-tables hardlink.c -o hardlink
> /tmp/cc1xWk9j.o: In function `rf':
> /builddir/build/BUILD/hardlink-1.1/hardlink.c:257: undefined reference to 
> `stcmp'
> collect2: error: ld returned 1 exit status
> 
> Of course, stcmp is declared. It's very weird, because the other architectures
> don't have the issue, nor f25 builds.
> 
> Any idea about what can be happening?

GNU89 vs. C99 inlining, that code is really old and apparently nobody
touched it since it has been written.

As everything is in a single file, either change all the inlines in the file
to static inline, or turn them into extern inline (in C99/C11 that means
if the function can't be inlined, an out of line copy is then emitted),
or change inline into inline __attribute__((__gnu_inline__)), or compile
with -fgnu89-inline.

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

Re: Fedora 26 Mass Rebuild - gnutls, µhttpd users

2017-02-14 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Feb 14, 2017 at 02:56:28PM -0500, Mohan Boddu wrote:
> Hi all,
> 
> Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
> on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:

systemd failed to rebuild. There were a couple of issues, but it's the
last one that's interesting. gnutls and µhttpd dependencies are not
detected properly:

$ rpm -q gnutls-devel
gnutls-devel-3.5.9-1.fc26.x86_64
$ "/usr/bin/pkg-config" "--cflags" "gnutls" || echo "NOT OK"
Package libidn2 was not found in the pkg-config search path.
...
NOT OK

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

I assume that might impact any package which uses pkg-config
to detect gnutls or libµhttpd.

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

Fedora 26 Mass Rebuild

2017-02-14 Thread Mohan Boddu

Hi all,

Per the Fedora 26 schedule[1] we started a mass rebuild for Fedora 26
on Feb 9th 2017. We did a mass rebuild for Fedora 26 for:

https://fedoraproject.org/wiki/Changes/pkgconf_as_system_pkg-config_implementation
https://fedoraproject.org/wiki/Changes/GCC7
https://fedoraproject.org/wiki/Changes/Fedora26CFlags
https://fedoraproject.org/wiki/Changes/golang1.8
https://fedoraproject.org/wiki/Changes/golang-buildmode-pie.

Mass rebuild was done in a side tag (f26-rebuild) and moved over to f26.

Failures can be seen
http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-failures.html

Things still needing rebuilt
http://dl.fedoraproject.org/pub/alt/mass-rebuild/f26-need-rebuild.html

16160 builds have been tagged into f26, there s currently 1299 failed
builds that need to be addressed by the package maintainers.

FTBFS bugs will be filed shortly.

Please be sure to let releng know if you see any bugs in the
reporting. You can contact releng in #fedora-releng on freenode, by
dropping an email to our list[2] or filing an issue in pagure[3]

Regards,
Mohan Boddu.

[1] https://fedoraproject.org/wiki/Releases/26/Schedule
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: hardlink building issue in F26 armv7hl and i686

2017-02-14 Thread Francisco J. Tsao Santin

On Mon, 13 Feb 2017, Dan Horák wrote:

> it could be a gcc7 bug on 32-bit arches, you can check by switching to
> -O1 or -O0 instead of the default -O2, or by dropping "inline" for
> stcmp()
> 

I tested with -01 and O0, and it solves the issue partially.  If I drop the
inlines, the program compiles ok. Thanks a lot for the advice :-)

-- 
Francisco Javier Tsao Santín
http://gattaca.es
1024D/71CF4D62  42 F1 53 35 EF 98 98 8A FC 6C 56 B3 4C A7 7D FB___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please test Vagrant 1.9.1

2017-02-14 Thread Colin Walters

On Tue, Feb 14, 2017, at 08:14 AM, Vít Ondruch wrote:

> 3) The downside of (1) is that the plugin registration scripts are baked
> into vagrant plugins, I had to apply some hacks to keep the backward
> compatibility with Vagrant plugins currently in Fedora.

While you're working on this, can you change the registration directory
to be in /usr?  This is following up on:
https://bugzilla.redhat.com/show_bug.cgi?id=1352152
which is part of 
https://bugzilla.redhat.com/show_bug.cgi?id=1352154
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Rawhide-20170213.n.1 compose check report

2017-02-14 Thread Fedora compose checker

Missing expected images:

Server dvd i386
Xfce raw-xz armhfp
Server boot i386
Minimal raw-xz armhfp

Failed openQA tests: 17/107 (x86_64), 2/2 (i386)

ID: 56930   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/56930
ID: 56931   Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/56931
ID: 56934   Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/56934
ID: 56953   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/56953
ID: 56958   Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/56958
ID: 56959   Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/56959
ID: 56960   Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56960
ID: 56968   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/56968
ID: 56970   Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/56970
ID: 56975   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/56975
ID: 56992   Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/56992
ID: 56995   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/56995
ID: 56996   Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/56996
ID: 57009   Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/57009
ID: 57011   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/57011
ID: 57016   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/57016
ID: 57022   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/57022
ID: 57023   Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/57023
ID: 57027   Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/57027

Soft failed openQA tests: 49/107 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 56920   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/56920
ID: 56921   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56921
ID: 56922   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/56922
ID: 56923   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56923
ID: 56929   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/56929
ID: 56939   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/56939
ID: 56941   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/56941
ID: 56942   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56942
ID: 56971   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/56971
ID: 56974   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/56974
ID: 56976   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/56976
ID: 56977   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/56977
ID: 56979   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/56979
ID: 56980   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/56980
ID: 56981   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/56981
ID: 56982   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/56982
ID: 56983   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/56983
ID: 56984   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/56984
ID: 56985   Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/56985
ID: 56986   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/56986
ID: 56987   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/56987
ID: 56988   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/56988
ID: 56989   Test: x86_64 universal

Re: Spec files maintained in external source control: please mention this in the spec file

2017-02-14 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Feb 14, 2017 at 03:41:52PM +, Mat Booth wrote:
> Ticket is still has "need info" status  -- if the info is provided, the
> status should be set to "discuss at next meeting"

Indeed. I changed the status. (I feels a bit presumptuous to tell the
FPC when exactly they have to discuss something, but if it's that's 
what it takes, then OK.)

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

Re: Taskotron CI in Taskotron

On Tue, 2017-02-14 at 14:46 -0500, Kamil Paral wrote:
> > The only problem with this kind of testing is, that we still don't really
> > have a good way to test trigger, as it is tied to external events. My idea
> > here was that I could add something like wiki edit consumer, and trigger
> > tasks off of that, making that one "triggering" edit from inside the
> > testsuite.
> 
> In my experience, some fedmsg notifications are quite delayed from
> time to time, easily by several hours. But I don't know if the delay
> is in actual fedmsg bus, or just in FMN (which I use to get notified
> on IRC). I suspect rather FMN. But if that turned out to be a fedmsg
> delay, that might make this approach impractical (or at least less
> reliable). So something to consider and possibly investigate. 

I believe it's FMN. I've noticed the same delay with FMN notifications,
but I've never noticed any delay with the actual fedmsg notifications
used by all the stuff we've built around release validation (compose
complete fedmsgs, openQA test complete fedmsgs etc.)

> I think it would be better to fake the input data. Either by having
> our own fedmsg producer and/or bus (I don't know precisely how fedmsg
> works and how hard is to set up something like that),

Are you aware of fedmsg-dg-replay? It's a fairly easy way to 'replay'
fedmsgs for testing. All you need (IIRC) is the fedmsg-relay service
running on the same system, and you can run
'fedmsg-dg-replay --msg-id ' and the message will be
replayed on the local bus (if the message is .prod. or .stg. , this
will be changed to .dev. , and the message will not be signed).

I don't remember exactly how the taskotron trigger code works, but it
shouldn't be too hard to configure a trigger to accept unsigned
messages with .dev. topics, for the purpose of testing with -replay. In
the fedmsg consumers I've written I have a pattern of providing three
consumers, one which listens for .prod. messages, one for .stg.
messages, and one which listens for for .dev. messages and is intended
for testing with fedmsg-dg-replay.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Re: Taskotron CI in Taskotron

2017-02-14 Thread Kamil Paral

> The only problem with this kind of testing is, that we still don't really
> have a good way to test trigger, as it is tied to external events. My idea
> here was that I could add something like wiki edit consumer, and trigger
> tasks off of that, making that one "triggering" edit from inside the
> testsuite.

In my experience, some fedmsg notifications are quite delayed from time to 
time, easily by several hours. But I don't know if the delay is in actual 
fedmsg bus, or just in FMN (which I use to get notified on IRC). I suspect 
rather FMN. But if that turned out to be a fedmsg delay, that might make this 
approach impractical (or at least less reliable). So something to consider and 
possibly investigate. 

I think it would be better to fake the input data. Either by having our own 
fedmsg producer and/or bus (I don't know precisely how fedmsg works and how 
hard is to set up something like that), or by making some code adjustments in 
trigger that will allow us to bypass the fedmsg reception and replace it with 
our own fedmsg, but cover as much surrounding code as possible. 
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

Broken dependencies: perl-ZMQ-LibZMQ3



perl-ZMQ-LibZMQ3 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.x86_64 requires libzmq.so.3()(64bit)
On armhfp:
perl-ZMQ-LibZMQ3-1.19-5.fc25.armv7hl requires libzmq.so.3
On ppc64le:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64le requires libzmq.so.3()(64bit)
On aarch64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.aarch64 requires libzmq.so.3()(64bit)
On ppc64:
perl-ZMQ-LibZMQ3-1.19-5.fc25.ppc64 requires libzmq.so.3()(64bit)
On i386:
perl-ZMQ-LibZMQ3-1.19-5.fc25.i686 requires libzmq.so.3
Please resolve this as soon as possible.

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

Broken dependencies: perl-Alien-ROOT



perl-Alien-ROOT has broken dependencies in the rawhide tree:
On ppc64:
perl-Alien-ROOT-5.34.36.1-3.fc26.noarch requires root-core
On ppc64le:
perl-Alien-ROOT-5.34.36.1-3.fc26.noarch requires root-core
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZMQ-LibZMQ2



perl-ZMQ-LibZMQ2 has broken dependencies in the rawhide tree:
On x86_64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZMQ-LibZMQ2-1.09-9.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZMQ-LibZMQ2-1.09-9.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZMQ-LibZMQ2-1.09-9.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

Broken dependencies: perl-ZeroMQ



perl-ZeroMQ has broken dependencies in the rawhide tree:
On x86_64:
perl-ZeroMQ-0.23-13.fc25.x86_64 requires libzmq.so.1()(64bit)
On armhfp:
perl-ZeroMQ-0.23-13.fc25.armv7hl requires libzmq.so.1
On ppc64le:
perl-ZeroMQ-0.23-13.fc25.ppc64le requires libzmq.so.1()(64bit)
On aarch64:
perl-ZeroMQ-0.23-13.fc25.aarch64 requires libzmq.so.1()(64bit)
On ppc64:
perl-ZeroMQ-0.23-13.fc25.ppc64 requires libzmq.so.1()(64bit)
On i386:
perl-ZeroMQ-0.23-13.fc25.i686 requires libzmq.so.1
Please resolve this as soon as possible.

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

jplesnik pushed to perl-Log-Dispatch-FileRotate (f25). "1.23 bump; Specify all dependencies"

From 89d49bbd03d9c1d881a09b001779ad00185d47c8 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 14 Feb 2017 14:28:40 +0100
Subject: 1.23 bump; Specify all dependencies

---
 .gitignore|  1 +
 perl-Log-Dispatch-FileRotate.spec | 29 -
 sources   |  2 +-
 3 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/.gitignore b/.gitignore
index cf86509..ffc09d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Log-Dispatch-FileRotate-1.19.tar.gz
 /Log-Dispatch-FileRotate-1.22.tar.gz
+/Log-Dispatch-FileRotate-1.23.tar.gz
diff --git a/perl-Log-Dispatch-FileRotate.spec 
b/perl-Log-Dispatch-FileRotate.spec
index 9ef1dd0..84a9a4e 100644
--- a/perl-Log-Dispatch-FileRotate.spec
+++ b/perl-Log-Dispatch-FileRotate.spec
@@ -1,19 +1,35 @@
 Name:   perl-Log-Dispatch-FileRotate
-Version:1.22
+Version:1.23
 Release:1%{?dist}
 Summary:Log to files that archive/rotate themselves
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Log-Dispatch-FileRotate/
-Source0:
http://www.cpan.org/authors/id/M/MA/MARKPF/Log-Dispatch-FileRotate-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/M/MS/MSCHOUT/Log-Dispatch-FileRotate-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
 BuildRequires:  perl-generators
+BuildRequires:  perl(base)
 BuildRequires:  perl(Date::Manip)
-BuildRequires:  perl(Log::Dispatch)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Path::Tiny)
+BuildRequires:  perl(Fcntl)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Log::Dispatch)
+BuildRequires:  perl(Log::Dispatch::File)
+BuildRequires:  perl(Log::Dispatch::Output)
+BuildRequires:  perl(Log::Dispatch::Screen)
+BuildRequires:  perl(Params::Validate)
+BuildRequires:  perl(Path::Tiny) >= 0.018
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.88
+BuildRequires:  perl(Test::Warn)
+BuildRequires:  perl(version)
+BuildRequires:  perl(warnings)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(version)
 
 %description
 This module provides a simple object for logging to files under the
@@ -44,6 +60,9 @@ make test
 
 
 %changelog
+* Tue Feb 14 2017 Jitka Plesnikova  - 1.23-1
+- 1.23 bump
+
 * Fri Oct 14 2016 Tom Callaway  - 1.22-1
 - update to 1.22
 
diff --git a/sources b/sources
index e61a9bd..bb7066d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-904b198de252edbdce1b49307486e849  Log-Dispatch-FileRotate-1.22.tar.gz
+SHA512 (Log-Dispatch-FileRotate-1.23.tar.gz) = 
f82158001a047532f1d43452da0f656ee7723cce131d89d743586a8fce59bcc670113a42c4682afe53eabd92c669443fb14c37fde28a5fce9cd615097c6290db
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Log-Dispatch-FileRotate.git/commit/?h=f25=89d49bbd03d9c1d881a09b001779ad00185d47c8
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1422190] New: RFE: Upgrade to Code::TidyAll

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

Bug ID: 1422190
   Summary: RFE: Upgrade to Code::TidyAll
   Product: Fedora
   Version: 25
 Component: perl-Code-TidyAll
  Assignee: jples...@redhat.com
  Reporter: rc040...@freenet.de
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Description of problem:

The versions of perl-Code-TidyAll in
Fedora 24 and 25 are outdated:
perl-Code-TidyAll-0.49-1.fc25 (Released July 2016)
perl-Code-TidyAll-0.44-1.fc24 (seamingly an inoffical, never formally released
snapshot)

Please consider to update them a more recent version.

Origin of this request is me being unable to add 
perl-Code-TidyAll-Plugin-Test-Vars to fedora 24 and 25, 
because it requires Code::TidyAll > 0.50

-- 
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: Python 3.6, Fedora, and the "C" locale

2017-02-14 Thread Charalampos Stratakis

Bumping this thread.

Draft of the self contained change:
https://fedoraproject.org/wiki/User:Cstratak/python3.6_c.utf-8_locale

Some of the sections are reworded from PEP 538 [0] as most (if not all) of the 
motivation section for upstream, also applies for Fedora.

[0] https://www.python.org/dev/peps/pep-0538/

Feedback will be greatly appreciated

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

jplesnik pushed to perl-Log-Dispatch-FileRotate (master). "1.23 bump; Specify all dependencies"

From 91e1d8fb4178bb1693614c77b366bfd30d2a22f1 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 14 Feb 2017 14:28:40 +0100
Subject: 1.23 bump; Specify all dependencies

---
 .gitignore|  1 +
 perl-Log-Dispatch-FileRotate.spec | 31 +--
 sources   |  2 +-
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/.gitignore b/.gitignore
index cf86509..ffc09d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Log-Dispatch-FileRotate-1.19.tar.gz
 /Log-Dispatch-FileRotate-1.22.tar.gz
+/Log-Dispatch-FileRotate-1.23.tar.gz
diff --git a/perl-Log-Dispatch-FileRotate.spec 
b/perl-Log-Dispatch-FileRotate.spec
index aa4194c..8ac439d 100644
--- a/perl-Log-Dispatch-FileRotate.spec
+++ b/perl-Log-Dispatch-FileRotate.spec
@@ -1,19 +1,35 @@
 Name:   perl-Log-Dispatch-FileRotate
-Version:1.22
-Release:2%{?dist}
+Version:1.23
+Release:1%{?dist}
 Summary:Log to files that archive/rotate themselves
 Group:  Development/Libraries
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/Log-Dispatch-FileRotate/
-Source0:
http://www.cpan.org/authors/id/M/MA/MARKPF/Log-Dispatch-FileRotate-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/M/MS/MSCHOUT/Log-Dispatch-FileRotate-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
 BuildRequires:  perl-generators
+BuildRequires:  perl(base)
 BuildRequires:  perl(Date::Manip)
-BuildRequires:  perl(Log::Dispatch)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Path::Tiny)
+BuildRequires:  perl(Fcntl)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(Log::Dispatch)
+BuildRequires:  perl(Log::Dispatch::File)
+BuildRequires:  perl(Log::Dispatch::Output)
+BuildRequires:  perl(Log::Dispatch::Screen)
+BuildRequires:  perl(Params::Validate)
+BuildRequires:  perl(Path::Tiny) >= 0.018
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More) >= 0.88
+BuildRequires:  perl(Test::Warn)
+BuildRequires:  perl(version)
+BuildRequires:  perl(warnings)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+Requires:   perl(version)
 
 %description
 This module provides a simple object for logging to files under the
@@ -44,6 +60,9 @@ make test
 
 
 %changelog
+* Tue Feb 14 2017 Jitka Plesnikova  - 1.23-1
+- 1.23 bump
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
1.22-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
diff --git a/sources b/sources
index e61a9bd..bb7066d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-904b198de252edbdce1b49307486e849  Log-Dispatch-FileRotate-1.22.tar.gz
+SHA512 (Log-Dispatch-FileRotate-1.23.tar.gz) = 
f82158001a047532f1d43452da0f656ee7723cce131d89d743586a8fce59bcc670113a42c4682afe53eabd92c669443fb14c37fde28a5fce9cd615097c6290db
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Log-Dispatch-FileRotate.git/commit/?h=master=91e1d8fb4178bb1693614c77b366bfd30d2a22f1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Log-Dispatch-FileRotate-1.23.tar.gz for perl-Log-Dispatch-FileRotate

f82158001a047532f1d43452da0f656ee7723cce131d89d743586a8fce59bcc670113a42c4682afe53eabd92c669443fb14c37fde28a5fce9cd615097c6290db
  Log-Dispatch-FileRotate-1.23.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Log-Dispatch-FileRotate/Log-Dispatch-FileRotate-1.23.tar.gz/sha512/f82158001a047532f1d43452da0f656ee7723cce131d89d743586a8fce59bcc670113a42c4682afe53eabd92c669443fb14c37fde28a5fce9cd615097c6290db/Log-Dispatch-FileRotate-1.23.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Libtaskotron - allow non-cli data input

2017-02-14 Thread Kamil Paral

> On Wed, Feb 8, 2017 at 2:26 PM, Kamil Paral < kpa...@redhat.com > wrote:

> > > This is what I meant - keeping item as is, but being able to pass another
> > > structure to the formula, which can then be used from it. I'd still like
> > > to
> > > keep the item to a single string, so it can be queried easily in the
> > > resultsdb. The item should still represent what was tested. It's just
> > > that
> > > I
> > > want to be able to pass arbitrary data to the formulae, without the need
> > > for
> > > ugly hacks like we have seen with the git commits lately.
> > 
> 

> > So, the question is now how much we want the `item` to uniquely identify
> > the
> > item under test. Currently we mostly do (rpmlint, rpmgrill) and sometimes
> > don't (depcheck, because item is NVR, but the full ID is NEVRA, and we
> > store
> > arch in the results extradata section).
> 

> I still kind of believe that the `item` should be chosen with great respect
> to what actually is the item under test, but it also really depends on what
> you want to do with it later on. Note that the `item` is actually a
> convention (yay, more water to adamw's "if we only had some awesome new
> project" mill), and is not enforced in any way. I believe that there should
> be firm rules (once again - conventions) on what the item is for each "well
> known" item type, so you can kind-of assume that if you query for
> `item=foo=koji_build` you are getting the results related to that
> build.
> As we were discussing privately with the item types (I'm not going to go into
> much detail here, but for the rest of you guys - I'm contemplating making
> the types more general, and using more of the 'metadata' to store additional
> spefics - like replacing `type=koji_build` with `type=build, source=koji`,
> or `type=build, source=brew` - on the high level, you know that a
> package/build was tested, and you don't really care where it came from, but
> you sometimes might care, and so there is the additional metadata stored. We
> could even have more types stored for one results, or I don't know... It's
> complicated), the idea behind item is that it should be a reasonable value,
> that carries the "what was tested" information, and you will use the other
> "extra-data" fields to provide more details (like we kind-of want to do with
> arch, but we don't really..). The reason for it to be 'reasonable value" and
> not "superset of all values that we have" is to make the general querying a
> bit more straightforward.

> > If we have structured input data, what happens to `item` for
> > check_modulemd?
> > Currently it is "namespace/module#commithash". Will it stay the same, and
> > they'll just avoid parsing it because we'll also provide ${data.namespace},
> > ${data.module} and ${data.hash}? Or will the `item` be perhaps just
> > "module"
> > (and the rest will be stored as extradata)? What happens when we have a
> > generic git_commit type, and the source can be an arbitrary service? Will
> > have some convention to use item as "giturl#commithash"?
> 

> Once again - whatever makes sense as the item. For me that would be the
> Repo/SHA combo, with server, repo, branch, and commit in extradata.
> And it comes to "storing as much relevant metadata as possible" once again.
> The thing is, that as long as stuff is predictable, it almost does not
> matter what it is, and it once again points out how good of an idea is the
> conventions stuff. I believe that we are now storing much less metadata in
> resultsdb than we should, and it is caused mostly by the fact that
> - we did not really need to use the results much so far
> - it is pretty hard to pass data into libtaskotron, and querying all the
> services all the time, to get the metadata, is/was deemed a bad idea - why
> do it ourselves, if the consumer can get it himself. They know that it is
> koji_build, so they can query koji.

> There is a fine balance to be struck, IMO, so we don't end up storing "all
> the data" in resultsdb. But I believe that the stuff relevant for the result
> consumption should be there.

> > Because the ideal way would be to store the whole item+data structure as
> > item
> > in resultsdb. But that's hard to query for humans, so we want a simple
> > string as an identifier.
> 

> This, for me, is once again about being predictable. As I said above, I still
> think that `item` should be a reasonable identifier, but not necessary a
> superset of all the info. That is what the extra data is for. Talking
> about...

> > But sometimes there can be a lot of data points which uniquely identify the
> > thing under test only when you specify it all (for example what Dan wrote,
> > sometimes the ID is the old NVR *plus* the new NVR). Will we want to
> > somehow
> > combine them into a single item value? We should give some directions how
> > people should construct their items.
> 

> My gut feeling here would be storing the "new NVR" (the thing that actually
> caused the test to be executed)

[Bug 1418132] perl-Net-STOMP-Client-2.3 is available

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



--- Comment #10 from Fedora Update System  ---
perl-Net-STOMP-Client-2.3-1.fc25 has been pushed to the Fedora 25 stable
repository. If problems still persist, please make note of it in this bug
report.

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

jplesnik pushed to perl-Log-Dispatch-Perl (master). "Specify all dependencies"

From 85534d5cc9dfe727e2d3bffc3e59e019e8656400 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 14 Feb 2017 14:06:01 +0100
Subject: Specify all dependencies

---
 perl-Log-Dispatch-Perl.spec | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/perl-Log-Dispatch-Perl.spec b/perl-Log-Dispatch-Perl.spec
index 0c4ab85..fc0cbae 100644
--- a/perl-Log-Dispatch-Perl.spec
+++ b/perl-Log-Dispatch-Perl.spec
@@ -1,17 +1,27 @@
 Name:   perl-Log-Dispatch-Perl
 Version:0.04
-Release:14%{?dist}
+Release:15%{?dist}
 Summary:Use core Perl functions for logging
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Log-Dispatch-Perl/
 Source0:
http://www.cpan.org/authors/id/E/EL/ELIZABETH/Log-Dispatch-Perl-%{version}.tar.gz
 BuildArch:  noarch
+
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
 BuildRequires:  perl-generators
+BuildRequires:  perl(base)
+BuildRequires:  perl(Carp)
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Log::Dispatch) >= 1.16
-Requires:  perl(Carp)
+BuildRequires:  perl(Log::Dispatch::Output)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(Test::More)
+BuildRequires:  perl(warnings)
+Requires:   perl(Carp)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
@@ -43,6 +53,9 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Feb 14 2017 Jitka Plesnikova  - 0.04-15
+- Specify all dependencies
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
0.04-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Log-Dispatch-Perl.git/commit/?h=master=85534d5cc9dfe727e2d3bffc3e59e019e8656400
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 26 Rawhide 20170214.n.0 nightly compose nominated for testing

2017-02-14 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 26 Rawhide 20170214.n.0. 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

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

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_26_Rawhide_20170214.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_26_Rawhide_20170214.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relval: https://www.happyassassin.net/relval/
___
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: undefined reference to `sf::String::operator std::__cxx11::basic_string

2017-02-14 Thread Jonathan Wakely


On 14/02/17 14:49 +0100, Marek Polacek wrote:

On Tue, Feb 14, 2017 at 01:27:27PM -, Martin Gansser wrote:

Hi,

when compiling marsshooter on rawhide it fails with the following error message:
undefined reference to `sf::String::operator std::__cxx11::basic_string() const'

This is the complete build.log
https://kojipkgs.fedoraproject.org//work/tasks/7032/17757032/build.log

On Fedora 26 gcc-7.0.1 is installed.


Looks like it might be 
https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling


Yes, definitely.

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

Re: Spec files maintained in external source control: please mention this in the spec file

2017-02-14 Thread Mat Booth

On 14 February 2017 at 02:58, Zbigniew Jędrzejewski-Szmek  wrote:

> On Mon, Feb 13, 2017 at 09:44:50AM -0800, Adam Williamson wrote:
> > Hi folks! So I got bitten again today by the situation where the
> > primary contact for a given package considers the 'canonical' source
> > for the spec file to be some external SCM, and finds it a problem when
> > someone (e.g. a provenpackager like me...) changes the package directly
> > in dist-git.
>
> https://fedorahosted.org/fpc/ticket/613
> It's seems to be going nowhere.
>
> > This is at least 50% my fault for not trying to check in before
> > changing the package
> It'd help if there was a standard way to mark such things.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>


Ticket is still has "need info" status  -- if the info is provided, the
status should be set to "discuss at next meeting"

-- 
Mat Booth
http://fedoraproject.org/get-fedora
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: undefined reference to `sf::String::operator std::__cxx11::basic_string

2017-02-14 Thread Martin Gansser

> On Tue, 2017-02-14 at 13:27 +, Martin Gansser wrote:
> 
> retry the marsshooter-0.7.6-4.fc26  f26-rebuild  build?
> 
> # fedpkg build --target f26-rebuild
> 
> Hopefully it will automagically work now that the f26-rebuild buildroot
> has a rebuilt SFML
> 
> 
> -Yanko

ok i will give it a try tomorrow, now it fails.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] EPEL meeting Agenda 2017-02-15 1800 UTC

2017-02-14 Thread Stephen John Smoogen

Report from Devconf/FOSDEM
Ideas for the coming year
Combining mailing lists
Getting CentOS builds done in the next 3 months?


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

Re: What if you only want to package part of upstream?

2017-02-14 Thread Matthew Miller

On Tue, Feb 14, 2017 at 11:19:11AM +, Richard W.M. Jones wrote:
> (3) Let others create subpackages for the other bindings in future on
> an as-needed basis (and make them become co-maintainers and do the
> work :-)

This seems like the right approach to me too.

-- 
Matthew Miller

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

pghmcfc pushed to perl-MetaCPAN-Client (master). "Update to 2.005000 (..more)"

From 321eef6ecc115f277c9218864678773ea15c8945 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 14 Feb 2017 12:22:44 +
Subject: Update to 2.005000

- New upstream release 2.005000
  - Added the ascii_name and perlmongers fields to the Author object (GH#66)
  - Fixed Author->dir to actually return something (GH#66)
---
 perl-MetaCPAN-Client.spec | 11 +--
 sources   |  2 +-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/perl-MetaCPAN-Client.spec b/perl-MetaCPAN-Client.spec
index 09e640f..ba6579f 100644
--- a/perl-MetaCPAN-Client.spec
+++ b/perl-MetaCPAN-Client.spec
@@ -3,8 +3,8 @@
 # TODO: BR: perl(HTTP::Tiny::Mech) and perl(WWW::Mechanize::Cache) when 
available
 
 Name:  perl-MetaCPAN-Client
-Version:   2.004000
-Release:   3%{?dist}
+Version:   2.005000
+Release:   1%{?dist}
 Summary:   A comprehensive, DWIM-featured client to the MetaCPAN API
 License:   GPL+ or Artistic
 URL:   https://github.com/CPAN-API/metacpan-client
@@ -43,6 +43,8 @@ BuildRequires:perl(LWP::Protocol::https)
 BuildRequires: perl(Test::Fatal)
 BuildRequires: perl(Test::More) >= 0.88
 BuildRequires: perl(Test::Requires)
+# Optional tests
+BuildRequires: perl(CPAN::Meta) >= 2.120900
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(HTTP::Tiny) >= 0.056
@@ -100,6 +102,11 @@ mv ./[a-z]*.t t/api/
 %{_mandir}/man3/MetaCPAN::Client::Types.3*
 
 %changelog
+* Tue Feb 14 2017 Paul Howarth  - 2.005000-1
+- Update to 2.005000
+  - Added the ascii_name and perlmongers fields to the Author object (GH#66)
+  - Fixed Author->dir to actually return something (GH#66)
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
2.004000-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
diff --git a/sources b/sources
index 72a27e4..71be5b2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MetaCPAN-Client-2.004000.tar.gz) = 
b5f19d20c8024caaa6521469b64cf4ff96e819f4c330824448de1c5c8964761c9e0c8013925582e3ecd1cc385fe2f3b18a74516d1fac1e9ed1f9d52029bbbec1
+SHA512 (MetaCPAN-Client-2.005000.tar.gz) = 
d73b473c49abf2b69e97a8ada28e6fa8ed2b2535f7ae8182927926adf254d1892d89377604a42e2116f4044bd2a34ed3899420de32579b6153004b507af8ddf2
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-MetaCPAN-Client.git/commit/?h=master=321eef6ecc115f277c9218864678773ea15c8945
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Devel-Confess (master). "0.009004 bump"

From a7e0e9c928237dbb2759c2cd9d7dfca793f6eb72 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 14 Feb 2017 13:22:14 +0100
Subject: 0.009004 bump

---
 .gitignore  | 1 +
 perl-Devel-Confess.spec | 5 -
 sources | 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 9ebfe6c..1c6ca20 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Devel-Confess-0.009003.tar.gz
+/Devel-Confess-0.009004.tar.gz
diff --git a/perl-Devel-Confess.spec b/perl-Devel-Confess.spec
index dda24b1..c57a2a0 100644
--- a/perl-Devel-Confess.spec
+++ b/perl-Devel-Confess.spec
@@ -1,5 +1,5 @@
 Name:   perl-Devel-Confess
-Version:0.009003
+Version:0.009004
 Release:1%{?dist}
 Summary:Include stack traces on all warnings and errors
 License:GPL+ or Artistic
@@ -68,5 +68,8 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Feb 14 2017 Jitka Plesnikova  - 0.009004-1
+- 0.009004 bump
+
 * Thu Feb 09 2017 Jitka Plesnikova  - 0.009003-1
 - Initial release
diff --git a/sources b/sources
index d583f9b..f7d3f79 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Devel-Confess-0.009003.tar.gz) = 
97e43f179b3c9a99ad1ce47e19411f3480808f9bb06139bff27d459f53e9e16f60aa843d04fe2615dbd98d92b7437118644e16e1dc2f7d3aee643fc610493d8f
+SHA512 (Devel-Confess-0.009004.tar.gz) = 
29f807e378bcb286d111f82f9ad564a610ca9813ba040a137ef149179c6909859f46a4a528eed6aea12162cdb291d8f79c7f7864c64b0ce77a44d16c3d207f25
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Devel-Confess.git/commit/?h=master=a7e0e9c928237dbb2759c2cd9d7dfca793f6eb72
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded MetaCPAN-Client-2.005000.tar.gz for perl-MetaCPAN-Client

d73b473c49abf2b69e97a8ada28e6fa8ed2b2535f7ae8182927926adf254d1892d89377604a42e2116f4044bd2a34ed3899420de32579b6153004b507af8ddf2
  MetaCPAN-Client-2.005000.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-MetaCPAN-Client/MetaCPAN-Client-2.005000.tar.gz/sha512/d73b473c49abf2b69e97a8ada28e6fa8ed2b2535f7ae8182927926adf254d1892d89377604a42e2116f4044bd2a34ed3899420de32579b6153004b507af8ddf2/MetaCPAN-Client-2.005000.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Devel-Confess-0.009004.tar.gz for perl-Devel-Confess

29f807e378bcb286d111f82f9ad564a610ca9813ba040a137ef149179c6909859f46a4a528eed6aea12162cdb291d8f79c7f7864c64b0ce77a44d16c3d207f25
  Devel-Confess-0.009004.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Devel-Confess/Devel-Confess-0.009004.tar.gz/sha512/29f807e378bcb286d111f82f9ad564a610ca9813ba040a137ef149179c6909859f46a4a528eed6aea12162cdb291d8f79c7f7864c64b0ce77a44d16c3d207f25/Devel-Confess-0.009004.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: undefined reference to `sf::String::operator std::__cxx11::basic_string

2017-02-14 Thread Yanko Kaneti

On Tue, 2017-02-14 at 13:27 +, Martin Gansser wrote:
> Hi,
> 
> when compiling marsshooter on rawhide it fails with the following
> error message:
> undefined reference to `sf::String::operator
> std::__cxx11::basic_string std::allocator >() const'
> 
> This is the complete build.log
> https://kojipkgs.fedoraproject.org//work/tasks/7032/17757032/build.lo
> g
> 
> On Fedora 26 gcc-7.0.1 is installed.
> 
> have somebody a solution ?

retry the marsshooter-0.7.6-4.fc26  f26-rebuild  build?

# fedpkg build --target f26-rebuild

Hopefully it will automagically work now that the f26-rebuild buildroot
has a rebuilt SFML


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

pghmcfc pushed to perl-MCE-Shared (master). "Update to 1.809 (..more)"

From 4983eb4771b8e2e4029a7eac9ea1f87adce333df Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 14 Feb 2017 12:12:56 +
Subject: Update to 1.809

- New upstream release 1.809
  - Fixed bug in MCE::Shared::Queue (dequeue_nb) when queue has zero items
  - Applied small optimization in MCE::Shared::Sequence
  - Added MCE::Shared::Cache, a fast and memory-efficient LRU-cache module
  - Added pipeline methods to MCE::Shared::Array, Hash, Minidb, and Ordhash
  - Added recommends section to Makefile and META files: IO::FDPass, Sereal
  - Added cross-platform template to MCE::Hobo for making an executable
  - Added hobo_timeout option to MCE::Hobo for timeout capability
Also, imply posix_exit => 1 when Gearman::XS is present
  - Added MCE::Hobo + Gearman demonstrations (xs and non-xs) on Github:
https://github.com/marioroy/mce-examples/tree/master/gearman_xs
https://github.com/marioroy/mce-examples/tree/master/gearman
  - Changed kilobytes and megabytes to kibiBytes (KiB) and mebiBytes (MiB)
respectively inside the documentation
  - Having IO::FDPass is beneficial for Condvar(s), Handle(s), and Queue(s);
thus, append IO::FDPass to PREREQ_PM if we can and not already installed
(run MCE_PREREQ_EXCLUDE_IO_FDPASS=1 perl Makefile.PL to bypass the check)
  - Improved documentation for QUERY STRING in various helper classes
  - Updated SYNOPSIS in various helper classes
  - Updated LOCKING section in MCE::Shared
---
 perl-MCE-Shared.spec | 35 ++-
 sources  |  2 +-
 2 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 7ce7fde..a08b31a 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,6 +1,6 @@
 Name:  perl-MCE-Shared
-Version:   1.808
-Release:   2%{?dist}
+Version:   1.809
+Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/MCE-Shared/
@@ -17,11 +17,12 @@ BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires: perl(bytes)
 BuildRequires: perl(Carp)
 BuildRequires: perl(constant)
-BuildRequires: perl(MCE) >= 1.805
+BuildRequires: perl(MCE) >= 1.811
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Util)
 BuildRequires: perl(overload)
 BuildRequires: perl(overloading)
+BuildRequires: perl(parent)
 BuildRequires: perl(Scalar::Util)
 BuildRequires: perl(Socket)
 BuildRequires: perl(Storable) >= 2.04
@@ -31,7 +32,7 @@ BuildRequires:perl(Time::HiRes)
 BuildRequires: perl(warnings)
 # Optional Functionality
 # Note: MCE will pull in Sereal if it is available
-BuildRequires: perl(IO::FDPass)
+BuildRequires: perl(IO::FDPass) >= 1.1
 BuildRequires: perl(threads)
 BuildRequires: perl(threads::shared)
 # Test Suite
@@ -40,7 +41,8 @@ BuildRequires:perl(MCE::Signal)
 BuildRequires: perl(Test::More) >= 0.88
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
-Requires:  perl(IO::FDPass)
+Requires:  perl(IO::FDPass) >= 1.1
+Requires:  perl(MCE) >= 1.811
 Requires:  perl(overloading)
 Requires:  perl(Storable) >= 2.04
 Requires:  perl(Symbol)
@@ -78,6 +80,7 @@ make test
 %{_mandir}/man3/MCE::Shared.3*
 %{_mandir}/man3/MCE::Shared::Array.3*
 %{_mandir}/man3/MCE::Shared::Base.3*
+%{_mandir}/man3/MCE::Shared::Cache.3*
 %{_mandir}/man3/MCE::Shared::Condvar.3*
 %{_mandir}/man3/MCE::Shared::Handle.3*
 %{_mandir}/man3/MCE::Shared::Hash.3*
@@ -89,6 +92,28 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Tue Feb 14 2017 Paul Howarth  - 1.809-1
+- Update to 1.809
+  - Fixed bug in MCE::Shared::Queue (dequeue_nb) when queue has zero items
+  - Applied small optimization in MCE::Shared::Sequence
+  - Added MCE::Shared::Cache, a fast and memory-efficient LRU-cache module
+  - Added pipeline methods to MCE::Shared::Array, Hash, Minidb, and Ordhash
+  - Added recommends section to Makefile and META files: IO::FDPass, Sereal
+  - Added cross-platform template to MCE::Hobo for making an executable
+  - Added hobo_timeout option to MCE::Hobo for timeout capability
+Also, imply posix_exit => 1 when Gearman::XS is present
+  - Added MCE::Hobo + Gearman demonstrations (xs and non-xs) on Github:
+https://github.com/marioroy/mce-examples/tree/master/gearman_xs
+https://github.com/marioroy/mce-examples/tree/master/gearman
+  - Changed kilobytes and megabytes to kibiBytes (KiB) and mebiBytes (MiB)
+respectively inside the documentation
+  - Having IO::FDPass is beneficial for Condvar(s), Handle(s), and Queue(s);
+thus, append IO::FDPass to PREREQ_PM if we can and not already installed
+(run MCE_PREREQ_EXCLUDE_IO_FDPASS=1 perl Makefile.PL to bypass the check)
+  - Improved documentation for QUERY STRING in various helper classes
+  - Updated SYNOPSIS in various helper classes
+  -

pghmcfc uploaded MCE-Shared-1.809.tar.gz for perl-MCE-Shared

4e6febb280281122117c701396766de369c72eef114853cdc5993d1337f0f1e402eeb8657a98b902726caede631c08a15edbfe130be75aa27df9c757d8dfa4b2
  MCE-Shared-1.809.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-MCE-Shared/MCE-Shared-1.809.tar.gz/sha512/4e6febb280281122117c701396766de369c72eef114853cdc5993d1337f0f1e402eeb8657a98b902726caede631c08a15edbfe130be75aa27df9c757d8dfa4b2/MCE-Shared-1.809.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

F26 Self Contained Change: Docker SDK for Python, version 2

2017-02-14 Thread Jan Kurik

= Proposed Self Contained Change: Docker SDK for Python, version 2 =
https://fedoraproject.org/wiki/Changes/Docker_SDK_For_Python_Version_2

Change owner(s):
* Tomas Tomecek 


Add new version of "Docker SDK for Python" to Fedora. This obsoletes
existing python-docker-py package.


== Detailed Description ==
On December 2016, upstream released a new version of python library
which communicates with Docker engine API. This new release is not
backwards compatible with previous 1.x series. As part of this
release, the upstream also renamed the package: it used to be named
docker-py on PyPI, now it's named docker.

We need to start a new review process and get the latest version of
the library to Fedora. Since the update will be backwards
incompatible, we need to make sure that all the software requiring
this library works with it.



== Scope ==
* Proposal owners:
-- Submit a review
-- Do a production build
-- Make sure that all the dependencies work with the updated package

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
N/A

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F26 Self Contained Change: Docker SDK for Python, version 2

2017-02-14 Thread Jan Kurik

= Proposed Self Contained Change: Docker SDK for Python, version 2 =
https://fedoraproject.org/wiki/Changes/Docker_SDK_For_Python_Version_2

Change owner(s):
* Tomas Tomecek 


Add new version of "Docker SDK for Python" to Fedora. This obsoletes
existing python-docker-py package.


== Detailed Description ==
On December 2016, upstream released a new version of python library
which communicates with Docker engine API. This new release is not
backwards compatible with previous 1.x series. As part of this
release, the upstream also renamed the package: it used to be named
docker-py on PyPI, now it's named docker.

We need to start a new review process and get the latest version of
the library to Fedora. Since the update will be backwards
incompatible, we need to make sure that all the software requiring
this library works with it.



== Scope ==
* Proposal owners:
-- Submit a review
-- Do a production build
-- Make sure that all the dependencies work with the updated package

* Other developers:
N/A (not a System Wide Change)

* Release engineering:
N/A

* List of deliverables:
N/A (not a System Wide Change)

* Policies and guidelines:
N/A (not a System Wide Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: heads up: planned changes of Git (split, credentials replacements) in rawhide

2017-02-14 Thread Kalev Lember

On 02/14/2017 01:58 PM, Petr Stodulka wrote:
> Hello,
> we are planning some changes in Git in rawhide according to some
> changes in upstream. I want to apply all changes during this week
> yet, but in case you have some recommendation or propmts to planned
> changes, you can yet give me feedback before we will do that.
> Briefly, changes what would be interesting for you:
> 
> - Move gnome-keyring credential helper from git-core to separate
>   subpackage git-gnome-keyring. If you use use someone this, you should
>   install it manually or modify requirements
>   Note: credential-gnome-keyring is deprecated by upstream.
> 
> - enable libsecret credential helper instead of libgnome-keyring
>   - part of git rpm
> 
> - fixed requirements of packages
>   - removed requirements:
>   rsync from git-core
>   libgnome-keyring from git-core
>   - added requirements:
>   libcurl for git-core
>   perl(Git) for git-email
>   perl(Git) for git-cvs
>   libsecret for git

Hi Petr,

Wouldn't it make sense to completely drop the libgnome-keyring git
backend and just switch to the new libsecret based one? I don't think
any gnome users would need both because the two libraries both talk to
the same daemon, gnome-keyring-daemon.

libsecret is just a new API and a replacement for libgnome-keyring, I
don't think there's a need to build the support for both.

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

Re: Fixing kmodtool / dropping kmodtool from redhat-rpm-config

2017-02-14 Thread Neal Gompa

On Tue, Feb 14, 2017 at 7:53 AM, Stanislav Kozina  wrote:
> Hi Neal,
>
>>> Hello Hans,
>>>
>>> (adding some more folks on CC..)
>>>
>>> You've correctly mentioned one of the problems with the kmod tools, that
>>> there are several versions in a various stages of loneliness. The other
>>> problem is that the usage of them is not trivial, eg. the
>>> %kernel_module_package macro (as the main user of the kmodtool) is quite
>>> complicated and limiting in the options you might need for the kmod
>>> build.
>>>
>>> For this reason we have recently developed a new tool which can be used
>>> to
>>> build a kmod. It doesn't use anything from the kernel-module-macros
>>> package,
>>> instead, it helps you to create a correct directory structure, generate a
>>> .spec file and package your kernel modules using this .spec file. This
>>> should make the kmod build much more self-contained. The tool has been
>>> recently also added to the Fedora COPR repository:
>>>
>>> https://copr.fedorainfracloud.org/coprs/ersin/ddiskit/
>>>
>>> Because of the current status of the content of the kernel-module-macros
>>> package I think it would be better to just remove it from Fedora
>>> completely.
>>> The ddiskit v.3 should be used as a replacement, we plan to propose it as
>>> a
>>> Fedora base package soon. The kernel module support from the
>>> /usr/lib/rpm/redhat/find-provides script might also be removed, together
>>> with the /usr/sbin/weak-modules script.
>>>
>>> It's worth mentioning that building kmods for Fedora won't make much
>>> sense
>>> because Fedora doesn't have a stable kernel ABI.
>>>
>> So how do you handle when kmods and userspace tools are built as part
>> of a single package?
>
>
> Why that would need to be in a single package? You can always create two
> packages that depend on each other. Or enhance ddiskit to cover your use
> case;-)
>

I mean they are built from a single source package. The kmod and the
utils would obviously be separate packages. :)

>> It seems like ddiskit is a rather myopic
>> solution. Not to mention, kmodtool has a very large userbase and this
>> is literally the first time I'm hearing of something like ddiskit.
>
>
> The first version of ddiskit dates at least to 2007, at least 10 years back:
> http://people.redhat.com/linville/ddiskit/
>
>> In addition, while you consider it to be valueless to offer kmod
>> packages, I would argue otherwise.
>
>
> I didn't say that.
>
>> Just because our tooling doesn't
>> allow us to track kernel releases and automatically build/rebuild
>> kernel module packages to target new kernels, doesn't mean others
>> don't (notably, building kmod packages with OBS tracking fedora
>> updates repo works quite well, and akmod works brilliantly as an
>> alternative path) and that others wouldn't find it useful anyway.
>
>
> I think that this is the source of our disconnection. That's a very
> different use case we're targeting.
> The kmodtool, and, most importantly, the weak-modules script is targeting
> packaging of kmods without recompilation with each kernel release. That's
> what doesn't make much sense on Fedora.
>

We could just disable weak-modules in Fedora. In fact, why haven't we?
It is useful for CentOS/RHEL, though.

>> RPM Fusion has been maintaining the kmod packaging standard since
>> Fedora (imho, wrongfully) expelled the specification and stopped
>> developing it. This is what ultimately led to the crazy fragmentation
>> we have across Fedora, RHEL, RPM Fusion, and other groups.
>
>
> For the module recompilation case it seems that DKMS is the preferred
> solution, as Panu also said. Why does RPM Fusion don't use that?
>

Where did Panu say that? I didn't see a message from him in this thread...

>> Instead, I propose that the ddiskit developers fold their work into
>> kmodtool and the kmod packaging work that RPM Fusion has done, so that
>> we have a unified solution.
>
>
> I don't think that these two different cases should be mixed together.
>

Are the use-cases really different though? What makes backport kmod
packages so different from regular ones?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fixing kmodtool / dropping kmodtool from redhat-rpm-config

2017-02-14 Thread Hans de Goede


Hi,

On 14-02-17 14:24, Stanislav Kozina wrote:



Hi,

On 13-02-17 14:27, Stanislav Kozina wrote:

Hello Hans,

(adding some more folks on CC..)

You've correctly mentioned one of the problems with the kmod tools, that there 
are several versions in a various stages of loneliness. The other problem is 
that the usage of them is not trivial, eg. the %kernel_module_package macro (as 
the main user of the kmodtool) is quite complicated and limiting in the options 
you might need for the kmod build.

For this reason we have recently developed a new tool which can be used to 
build a kmod. It doesn't use anything from the kernel-module-macros package, 
instead, it helps you to create a correct directory structure, generate a .spec 
file and package your kernel modules using this .spec file. This should make 
the kmod build much more self-contained. The tool has been recently also added 
to the Fedora COPR repository:

https://copr.fedorainfracloud.org/coprs/ersin/ddiskit/

Because of the current status of the content of the kernel-module-macros 
package I think it would be better to just remove it from Fedora completely.


That sounds like a fine plan.


The ddiskit v.3 should be used as a replacement, we plan to propose it as a 
Fedora base package soon


As explained by Neal Gompa 3th part repos have invested a lot
of effort into kmodtool and that will likely stay the preferred
way for them to package modules going forward at least for the
short term. So I think it would be good to:


Sure, that might be. I'm not a big fan of generating sub-package parts of the 
.spec file via script, but I totally understand it might work for others.


1) Drop the ancient kmodtool / entire kernel-module-macros package from 
redhat-rpm-config
2) Move kmodtool from rpmfusion to Fedora proper (where it can be shared with 
other 3th
   party repos) and extend it where necessary for other repo use-cases
3) Get ddiskit packaged into Fedora proper and promote people to use it for new 
kernel module
   packages / convert existing packages over (if the maintainer wishes)


Sounds like a good plan. I'd also add a docs step:
4) Make it clear that the kmodtool is required by akmod (so far). ddiskit can 
be used to package binary modules without recompilation on each new kernel 
release.


Ok, adding that 4th step is fine by me, the question is where do we put
these docs though ?


Technically, the ddiskit just generates the .spec file for you so you don't 
need to have hooks to kmodtool there. Of course it could be enhanced to 
generate the akmod subpackage code as well.


Think of this as how yum and dnf co-existed for a while.

> The kernel module support from the /usr/lib/rpm/redhat/find-provides script 
might also be removed, together with the /usr/sbin/weak-modules script.

I'm mostly coordinating things here, I'm not an expert on kernel module 
packaging,
so I'll let others weigh in if that is a good idea, specifically it would be 
good
to know if existing kernel (module) packages depend on this ?


The kernel package isn't calling weak-modules at all:
$ grep -i weak-modules kernel.spec

The RPM Fusion doesn't call it either:
$ grep weak-modules bin/kmodtool

Thinking about it, currently in Fedora it doesn't make sense for any of these 
sides to call weak-modules, as the recommended procedure is to rebuild the 
modules with the release of each new kernel. That's why I'm proposing to remove 
it.


As said I'm fine with removing it, just making sure doing so does not break
anything.

Regards,

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

Intent to orphan and retire Hoard (a memory allocator)

2017-02-14 Thread Richard W.M. Jones

Hoard is an alternative memory allocator (ie. malloc implementation)
for C++.  It is described in this 2000 paper:

  https://people.cs.umass.edu/~emery/pubs/berger-asplos2000.pdf

Fedora ships an old version (3.8) which fundamentally will not compile
on aarch64 because it is missing a bit of assembler to implement
atomic swaps.

The latest version of hoard (3.12) doesn't need this because it uses
C++  headers which should be portable:

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

However when I came to try and package this I found there are other
problems:

(1) Now requires a separate Heap-Layers library which would have to go
through the new package process.

(2) Lacks aarch64 and ppc64/ppc64le targets -- probably reasonably
easy to add to the Makefile, but another hassle.

There are also more modern alternative allocators around nowadays.

The original Fedora packager has expressed that he doesn't have time
to maintain it (https://bugzilla.redhat.com/show_bug.cgi?id=1034070#c4)

Nothing else in Fedora actually uses Hoard.  So my suggestion is we
should orphan and then retire the package, unless someone cares enough
to take it over.  Note you will probably need to package the separate
Heap-Layers library as described above.

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: Fixing kmodtool / dropping kmodtool from redhat-rpm-config

2017-02-14 Thread Stanislav Kozina




Hi,

On 13-02-17 14:27, Stanislav Kozina wrote:

Hello Hans,

(adding some more folks on CC..)

You've correctly mentioned one of the problems with the kmod tools, 
that there are several versions in a various stages of loneliness. 
The other problem is that the usage of them is not trivial, eg. the 
%kernel_module_package macro (as the main user of the kmodtool) is 
quite complicated and limiting in the options you might need for the 
kmod build.


For this reason we have recently developed a new tool which can be 
used to build a kmod. It doesn't use anything from the 
kernel-module-macros package, instead, it helps you to create a 
correct directory structure, generate a .spec file and package your 
kernel modules using this .spec file. This should make the kmod build 
much more self-contained. The tool has been recently also added to 
the Fedora COPR repository:


https://copr.fedorainfracloud.org/coprs/ersin/ddiskit/

Because of the current status of the content of the 
kernel-module-macros package I think it would be better to just 
remove it from Fedora completely.


That sounds like a fine plan.

The ddiskit v.3 should be used as a replacement, we plan to propose 
it as a Fedora base package soon


As explained by Neal Gompa 3th part repos have invested a lot
of effort into kmodtool and that will likely stay the preferred
way for them to package modules going forward at least for the
short term. So I think it would be good to:


Sure, that might be. I'm not a big fan of generating sub-package parts 
of the .spec file via script, but I totally understand it might work for 
others.


1) Drop the ancient kmodtool / entire kernel-module-macros package 
from redhat-rpm-config
2) Move kmodtool from rpmfusion to Fedora proper (where it can be 
shared with other 3th

   party repos) and extend it where necessary for other repo use-cases
3) Get ddiskit packaged into Fedora proper and promote people to use 
it for new kernel module

   packages / convert existing packages over (if the maintainer wishes)


Sounds like a good plan. I'd also add a docs step:
4) Make it clear that the kmodtool is required by akmod (so far). 
ddiskit can be used to package binary modules without recompilation on 
each new kernel release.


Technically, the ddiskit just generates the .spec file for you so you 
don't need to have hooks to kmodtool there. Of course it could be 
enhanced to generate the akmod subpackage code as well.



Think of this as how yum and dnf co-existed for a while.

> The kernel module support from the /usr/lib/rpm/redhat/find-provides 
script might also be removed, together with the /usr/sbin/weak-modules 
script.


I'm mostly coordinating things here, I'm not an expert on kernel 
module packaging,
so I'll let others weigh in if that is a good idea, specifically it 
would be good

to know if existing kernel (module) packages depend on this ?


The kernel package isn't calling weak-modules at all:
$ grep -i weak-modules kernel.spec

The RPM Fusion doesn't call it either:
$ grep weak-modules bin/kmodtool

Thinking about it, currently in Fedora it doesn't make sense for any of 
these sides to call weak-modules, as the recommended procedure is to 
rebuild the modules with the release of each new kernel. That's why I'm 
proposing to remove it.


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

Re: undefined reference to `sf::String::operator std::__cxx11::basic_string

2017-02-14 Thread Marek Polacek

On Tue, Feb 14, 2017 at 01:27:27PM -, Martin Gansser wrote:
> Hi,
> 
> when compiling marsshooter on rawhide it fails with the following error 
> message:
> undefined reference to `sf::String::operator std::__cxx11::basic_string std::char_traits, std::allocator >() const'
> 
> This is the complete build.log
> https://kojipkgs.fedoraproject.org//work/tasks/7032/17757032/build.log
> 
> On Fedora 26 gcc-7.0.1 is installed.

Looks like it might be 
https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling

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

[Bug 1420957] perl-Log-Dispatch-FileRotate-1.23 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Log-Dispatch-FileRotate-1.23-1.fc25 has been submitted as an update to
Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-738c231b96

-- 
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 1420957] perl-Log-Dispatch-FileRotate-1.23 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
jplesnik's perl-Log-Dispatch-FileRotate-1.23-1.fc26 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=859183

-- 
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 1420957] perl-Log-Dispatch-FileRotate-1.23 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Log-Dispatch-FileRotat
   ||e-1.23-1.fc26
   Assignee|tcall...@redhat.com |jples...@redhat.com



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

pghmcfc pushed to perl-IO-Socket-SSL (master). "Update to 2.045 (..more)"

From 46a5435ffc32293ee8a53b57936b9844666798af Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 14 Feb 2017 11:52:13 +
Subject: Update to 2.045

- New upstream release 2.045
  - Fixed memory leak caused by not destroying CREATED_IN_THIS_THREAD for SSL
objects (GH#55)
  - Optimization: don't track SSL objects and CTX in *CREATED_IN_THIS_THREAD if
perl is compiled without thread support
  - Small fix in t/protocol_version.t to use older versions of Net::SSLeay with
openssl build without SSLv3 support
  - When setting SSL_keepSocketOnError to true the socket will not be closed on
fatal error (GH#53, modified)
- Update patches as needed
---
 ...-SSL-2.044-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.044-use-system-default-cipher-list.patch | 98 --
 ...-SSL-2.045-use-system-default-SSL-version.patch | 36 
 ...-SSL-2.045-use-system-default-cipher-list.patch | 98 ++
 perl-IO-Socket-SSL.spec| 27 --
 sources|  2 +-
 6 files changed, 155 insertions(+), 142 deletions(-)
 delete mode 100644 IO-Socket-SSL-2.044-use-system-default-SSL-version.patch
 delete mode 100644 IO-Socket-SSL-2.044-use-system-default-cipher-list.patch
 create mode 100644 IO-Socket-SSL-2.045-use-system-default-SSL-version.patch
 create mode 100644 IO-Socket-SSL-2.045-use-system-default-cipher-list.patch

diff --git a/IO-Socket-SSL-2.044-use-system-default-SSL-version.patch 
b/IO-Socket-SSL-2.044-use-system-default-SSL-version.patch
deleted file mode 100644
index 90f98c0..000
--- a/IO-Socket-SSL-2.044-use-system-default-SSL-version.patch
+++ /dev/null
@@ -1,36 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -99,7 +99,7 @@ my $algo2digest = do {
- # global defaults
- my %DEFAULT_SSL_ARGS = (
- SSL_check_crl => 0,
--SSL_version => 'SSLv23:!SSLv3:!SSLv2', # consider both SSL3.0 and SSL2.0 
as broken
-+SSL_version => '',
- SSL_verify_callback => undef,
- SSL_verifycn_scheme => undef,  # fallback cn verification
- SSL_verifycn_publicsuffix => undef,  # fallback default list verification
-@@ -2227,7 +2227,7 @@ sub new {
- 
- my $ssl_op = $DEFAULT_SSL_OP;
- 
--my $ver;
-+my $ver = '';
- for (split(/\s*:\s*/,$arg_hash->{SSL_version})) {
-   m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1(?:_?[12])?))$}i
-   or croak("invalid SSL_version specified");
 lib/IO/Socket/SSL.pod
-+++ lib/IO/Socket/SSL.pod
-@@ -960,11 +960,12 @@ protocol to the specified version.
- All values are case-insensitive.  Instead of 'TLSv1_1' and 'TLSv1_2' one can
- also use 'TLSv11' and 'TLSv12'.  Support for 'TLSv1_1' and 'TLSv1_2' requires
- recent versions of Net::SSLeay and openssl.
-+The default SSL_version is defined by the underlying cryptographic library.
- 
- Independent from the handshake format you can limit to set of accepted SSL
- versions by adding !version separated by ':'.
- 
--The default SSL_version is 'SSLv23:!SSLv3:!SSLv2' which means, that the
-+For example, 'SSLv23:!SSLv3:!SSLv2' means that the
- handshake format is compatible to SSL2.0 and higher, but that the successful
- handshake is limited to TLS1.0 and higher, that is no SSL2.0 or SSL3.0 because
- both of these versions have serious security issues and should not be used
diff --git a/IO-Socket-SSL-2.044-use-system-default-cipher-list.patch 
b/IO-Socket-SSL-2.044-use-system-default-cipher-list.patch
deleted file mode 100644
index 8843f16..000
--- a/IO-Socket-SSL-2.044-use-system-default-cipher-list.patch
+++ /dev/null
@@ -1,98 +0,0 @@
 lib/IO/Socket/SSL.pm
-+++ lib/IO/Socket/SSL.pm
-@@ -107,10 +107,10 @@ my %DEFAULT_SSL_ARGS = (
- SSL_npn_protocols => undef,# meaning depends whether on server or 
client side
- SSL_alpn_protocols => undef,   # list of protocols we'll accept/send, for 
example ['http/1.1','spdy/3.1']
- 
--# https://wiki.mozilla.org/Security/Server_Side_TLS, 2016/04/20
--# "Old backward compatibility" for best compatibility
--# .. "Most ciphers that are not clearly broken and dangerous to use are 
supported"
--SSL_cipher_list =>

pghmcfc pushed to perl-Cpanel-JSON-XS (master). "Update to 3.0227 (..more)"

From 91bfd077d1a5e7cef10c6049962109db761dc449 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 14 Feb 2017 11:45:03 +
Subject: Update to 3.0227

- New upstream release 3.0227
  - Fix CLONE and END, broken with 3.0226 (GH#80); these methods are usually
called with arguments, which we ignore
---
 perl-Cpanel-JSON-XS.spec | 8 +++-
 sources  | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
index 37b4389..33a5955 100644
--- a/perl-Cpanel-JSON-XS.spec
+++ b/perl-Cpanel-JSON-XS.spec
@@ -1,6 +1,6 @@
 Name:  perl-Cpanel-JSON-XS
 Summary:   JSON::XS for Cpanel, fast and correct serializing
-Version:   3.0226
+Version:   3.0227
 Release:   1%{?dist}
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/Cpanel-JSON-XS/
@@ -156,10 +156,16 @@ make test %{!?perl_bootstrap:AUTHOR_TESTING=1}
 %{_mandir}/man3/Cpanel::JSON::XS::Boolean.3*
 
 %changelog
+* Tue Feb 14 2017 Paul Howarth  - 3.0227-1
+- Update to 3.0227
+  - Fix CLONE and END, broken with 3.0226 (GH#80); these methods are usually
+called with arguments, which we ignore
+
 * Sun Feb 12 2017 Paul Howarth  - 3.0226-1
 - Update to 3.0226
   - Relax longdouble Gconvert test on ppc64le and aarch64-linux-ld, with
 apparent HW quadmath without USE_QUADMATH (older perls)
+  - Fixed 2 uninit warnings in the XS
 
 * Sat Feb 11 2017 Fedora Release Engineering  - 
3.0225-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
diff --git a/sources b/sources
index d8e5448..b5da4ef 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Cpanel-JSON-XS-3.0226.tar.gz) = 
282fd66d44f3322596a3f0312ce5ee8ba8333ed5351c61201f99a07bfe305d1f65b492f4e1ae05d08a6be98a37dba707b655d7bbff0133ecee27049826bd10de
+SHA512 (Cpanel-JSON-XS-3.0227.tar.gz) = 
93a51246afab7feae6df204d63d84bef809c7aa07b524d08881afe77acba096704ab9f7ab9179efb8e446d3a7afc15024e8a82ea6a986fd122605d19d8ce
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-Cpanel-JSON-XS.git/commit/?h=master=91bfd077d1a5e7cef10c6049962109db761dc449
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded IO-Socket-SSL-2.045.tar.gz for perl-IO-Socket-SSL

fa2d1c9ad690965069a2f05a0bcecfd6c03fe3c2d38e50195933a9301c5c2374871eed3da637eaf3556df0c8e60ef8be26491d2d3ca453062079d69d2ce0ffa0
  IO-Socket-SSL-2.045.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-IO-Socket-SSL/IO-Socket-SSL-2.045.tar.gz/sha512/fa2d1c9ad690965069a2f05a0bcecfd6c03fe3c2d38e50195933a9301c5c2374871eed3da637eaf3556df0c8e60ef8be26491d2d3ca453062079d69d2ce0ffa0/IO-Socket-SSL-2.045.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

REMINDER: Change Checkpoint: Proposal submission deadline (Self contained Changes) of Fedora 26 in one week

2017-02-14 Thread Jan Kurik

Hi everyone!

The submission deadline for Self contained Changes of Fedora 26 [1] is
coming in one week, on February 21st. Please, submit your Self
contained Changes by this deadline, earlier better.
Alpha release of Fedora 26 is planned then on March 21th.

The submission deadline for System Wide Changes has already passed on
January 31st. Please schedule your potential System Wide Changes for
the next (Fedora 27) release.

[1] https://fedoraproject.org/wiki/Releases/26/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

undefined reference to `sf::String::operator std::__cxx11::basic_string

2017-02-14 Thread Martin Gansser

Hi,

when compiling marsshooter on rawhide it fails with the following error message:
undefined reference to `sf::String::operator std::__cxx11::basic_string() const'

This is the complete build.log
https://kojipkgs.fedoraproject.org//work/tasks/7032/17757032/build.log

On Fedora 26 gcc-7.0.1 is installed.

have somebody a solution ?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc uploaded Cpanel-JSON-XS-3.0227.tar.gz for perl-Cpanel-JSON-XS

93a51246afab7feae6df204d63d84bef809c7aa07b524d08881afe77acba096704ab9f7ab9179efb8e446d3a7afc15024e8a82ea6a986fd122605d19d8ce
  Cpanel-JSON-XS-3.0227.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-Cpanel-JSON-XS/Cpanel-JSON-XS-3.0227.tar.gz/sha512/93a51246afab7feae6df204d63d84bef809c7aa07b524d08881afe77acba096704ab9f7ab9179efb8e446d3a7afc15024e8a82ea6a986fd122605d19d8ce/Cpanel-JSON-XS-3.0227.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Please test Vagrant 1.9.1

2017-02-14 Thread Vít Ondruch

Hi everybody,

I spent last few days updating Vagrant in Rawhide. As it turned out, it
is quite significant update for several reasons:

1) Upstream changed the way how Vagrant is distributed in upstream RPM.
Hence this is good opportunity to change the way we ship Vagrant to be
close to upstream.
2) The upstream is not using Bundler for managing the Vagrant plugins
anymore, which seems to be change for good.
3) The downside of (1) is that the plugin registration scripts are baked
into vagrant plugins, I had to apply some hacks to keep the backward
compatibility with Vagrant plugins currently in Fedora.
4) And since (3) is PITA, it is good opportunity to use RPM filetriggers
instead. Therefore, I dropped the %vagrant_plugin_register and
%vagrant_plugin_unregister from Vagrant, which in turn means all the
Vagrant plugins in Fedora (maintainers are in CC) will become FTBFS.
I'll go through all the packages and fix them unless you say otherwise
(I might add them into my Copr repository for testing, not sure yet).
Please note that the plugins which are currently in Fedora should keep
working with Vagrant 1.9.1, but the plugins build against Vagrant 1.9.1
will not be compatible with older Vagrant versions, hence I suggest to
add "{,Build}Requires: vagrant >= 1.9.1".

To let everybody chance to test this prior I land the changes in
Rawhide, I built new Vagrant and vagrant-libvirt in Copr:

https://copr.fedorainfracloud.org/coprs/vondruch/vagrant/

You can see the changes in Vagrant here:

http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant.git/commit/?h=f26=34696a703e54a9b37e68e95d034e2a26fbe46d23

And these are the changes in vagrant-libvirt:

http://copr-dist-git.fedorainfracloud.org/cgit/vondruch/vagrant/vagrant-libvirt.git/commit/?h=f26=733217b68fc298e40c45524da4ac9036607d1558

Please give it a try. If no major issues are identified, I'd like to
land this in ~week, prior F27 branching.

Thx

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

Re: What if you only want to package part of upstream?

2017-02-14 Thread Rex Dieter

Randy Barlow wrote:

> In working on packaging Ampache, I found a dependency that has a
> bundled version of this file:
> 
> https://github.com/kazuhikoarase/qrcode-generator/blob/master/js/qrcode.js
...
> Is it ok to just name my source package js-qrcode-generator and package
> just the js bits of it, or do I need to name my package qrcode-
> generator? If the latter, would I be compelled to package all those
> language implementations as subpackages, or could I package just the JS
> one for now and wait to see if anyone files an issue to request the
> other languages in the future? 

I'd suggest a variant of the last option.  Keep the source package as 
canonical upstream name (qrcode-generator), and just generate a subpkg of 
the bits you want (js-qrcode-generator) for now.  That leaves the 
possibility open to include more later as needed.

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

Fedora Rawhide-20170214.n.0 compose check report

2017-02-14 Thread Fedora compose checker

Missing expected images:

Server dvd i386
Kde live x86_64
Xfce raw-xz armhfp
Server boot i386
Minimal raw-xz armhfp
Kde live i386

Failed openQA tests: 11/96 (x86_64)

ID: 56813   Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56813
ID: 56814   Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/56814
ID: 56822   Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/56822
ID: 56833   Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/56833
ID: 56834   Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56834
ID: 56845   Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/56845
ID: 56875   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/56875
ID: 56891   Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/56891
ID: 56896   Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/56896
ID: 56909   Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/56909
ID: 56918   Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/56918

Soft failed openQA tests: 48/96 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 56815   Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/56815
ID: 56821   Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/56821
ID: 56831   Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/56831
ID: 56851   Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/56851
ID: 56852   Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/56852
ID: 56854   Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/56854
ID: 56855   Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/56855
ID: 56856   Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/56856
ID: 56857   Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/56857
ID: 56858   Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/56858
ID: 56859   Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/56859
ID: 56860   Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/56860
ID: 56861   Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/56861
ID: 56862   Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/56862
ID: 56863   Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/56863
ID: 56864   Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/56864
ID: 56866   Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/56866
ID: 56867   Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/56867
ID: 56868   Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/56868
ID: 56869   Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/56869
ID: 56870   Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/56870
ID: 56873   Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/56873
ID: 56874   Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/56874
ID: 56877   Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/56877
ID: 56878   Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/56878
ID: 56879   Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/56879
ID: 56880   Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/56880
ID: 56882   Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/56882
ID: 56883   Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/56883
ID: 56884   Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/56884
ID: 56885   Test: x86_64 universal install_lvmthin@uefi
URL:

heads up: planned changes of Git (split, credentials replacements) in rawhide

2017-02-14 Thread Petr Stodulka

Hello,
we are planning some changes in Git in rawhide according to some
changes in upstream. I want to apply all changes during this week
yet, but in case you have some recommendation or propmts to planned
changes, you can yet give me feedback before we will do that.
Briefly, changes what would be interesting for you:

- Move gnome-keyring credential helper from git-core to separate
  subpackage git-gnome-keyring. If you use use someone this, you should
  install it manually or modify requirements
  Note: credential-gnome-keyring is deprecated by upstream.

- enable libsecret credential helper instead of libgnome-keyring
  - part of git rpm

- fixed requirements of packages
  - removed requirements:
  rsync from git-core
  libgnome-keyring from git-core
  - added requirements:
  libcurl for git-core
  perl(Git) for git-email
  perl(Git) for git-cvs
  libsecret for git
  
Cheers,
  Petr



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: Fixing kmodtool / dropping kmodtool from redhat-rpm-config

2017-02-14 Thread Stanislav Kozina


Hi Neal,


Hello Hans,

(adding some more folks on CC..)

You've correctly mentioned one of the problems with the kmod tools, that
there are several versions in a various stages of loneliness. The other
problem is that the usage of them is not trivial, eg. the
%kernel_module_package macro (as the main user of the kmodtool) is quite
complicated and limiting in the options you might need for the kmod build.

For this reason we have recently developed a new tool which can be used to
build a kmod. It doesn't use anything from the kernel-module-macros package,
instead, it helps you to create a correct directory structure, generate a
.spec file and package your kernel modules using this .spec file. This
should make the kmod build much more self-contained. The tool has been
recently also added to the Fedora COPR repository:

https://copr.fedorainfracloud.org/coprs/ersin/ddiskit/

Because of the current status of the content of the kernel-module-macros
package I think it would be better to just remove it from Fedora completely.
The ddiskit v.3 should be used as a replacement, we plan to propose it as a
Fedora base package soon. The kernel module support from the
/usr/lib/rpm/redhat/find-provides script might also be removed, together
with the /usr/sbin/weak-modules script.

It's worth mentioning that building kmods for Fedora won't make much sense
because Fedora doesn't have a stable kernel ABI.


So how do you handle when kmods and userspace tools are built as part
of a single package?


Why that would need to be in a single package? You can always create two 
packages that depend on each other. Or enhance ddiskit to cover your use 
case;-)



It seems like ddiskit is a rather myopic
solution. Not to mention, kmodtool has a very large userbase and this
is literally the first time I'm hearing of something like ddiskit.


The first version of ddiskit dates at least to 2007, at least 10 years back:
http://people.redhat.com/linville/ddiskit/


In addition, while you consider it to be valueless to offer kmod
packages, I would argue otherwise.


I didn't say that.


Just because our tooling doesn't
allow us to track kernel releases and automatically build/rebuild
kernel module packages to target new kernels, doesn't mean others
don't (notably, building kmod packages with OBS tracking fedora
updates repo works quite well, and akmod works brilliantly as an
alternative path) and that others wouldn't find it useful anyway.


I think that this is the source of our disconnection. That's a very 
different use case we're targeting.
The kmodtool, and, most importantly, the weak-modules script is 
targeting packaging of kmods without recompilation with each kernel 
release. That's what doesn't make much sense on Fedora.



RPM Fusion has been maintaining the kmod packaging standard since
Fedora (imho, wrongfully) expelled the specification and stopped
developing it. This is what ultimately led to the crazy fragmentation
we have across Fedora, RHEL, RPM Fusion, and other groups.


For the module recompilation case it seems that DKMS is the preferred 
solution, as Panu also said. Why does RPM Fusion don't use that?



Instead, I propose that the ddiskit developers fold their work into
kmodtool and the kmod packaging work that RPM Fusion has done, so that
we have a unified solution.


I don't think that these two different cases should be mixed together.

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

pghmcfc pushed to perl-MCE (master). "Update to 1.811 (..more)"

From 32d6f6bda2c59264ab35c0208b15cb696ebe358c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 14 Feb 2017 11:24:18 +
Subject: Update to 1.811

- New upstream release 1.811
  - Fixed bug in MCE::Queue (dequeue_nb) when queue has zero items
  - Applied small optimization in MCE::Core::Input::Sequence and Generator
  - Added cross-platform template to MCE::Examples for making an executable
  - Removed signal handling for XCPU and XFSZ from MCE::Signal
  - Imply posix_exit => 1 if Gearman::XS or Gearman::Util is present during
MCE construction
  - Added MCE + Gearman demonstrations (xs and non-xs) on Github:
https://github.com/marioroy/mce-examples/tree/master/gearman_xs
https://github.com/marioroy/mce-examples/tree/master/gearman
  - Changed kilobytes and megabytes to kibiBytes (KiB) and mebiBytes (MiB)
respectively inside the documentation
---
 .gitignore|  1 +
 perl-MCE.spec | 18 --
 sources   |  2 +-
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index cc3e6ff..db69e77 100644
--- a/.gitignore
+++ b/.gitignore
@@ -24,3 +24,4 @@
 /MCE-1.808.tar.gz
 /MCE-1.809.tar.gz
 /MCE-1.810.tar.gz
+/MCE-1.811.tar.gz
diff --git a/perl-MCE.spec b/perl-MCE.spec
index 242afb0..7f34f6d 100644
--- a/perl-MCE.spec
+++ b/perl-MCE.spec
@@ -1,6 +1,6 @@
 Name:   perl-MCE
-Version:1.810
-Release:2%{?dist}
+Version:1.811
+Release:1%{?dist}
 Summary:Many-core Engine for Perl providing parallel processing 
capabilities
 License:GPL+ or Artistic
 URL:http://search.cpan.org/dist/MCE/
@@ -136,6 +136,20 @@ make test
 %{_bindir}/mce_grep
 
 %changelog
+* Tue Feb 14 2017 Paul Howarth  - 1.811-1
+- Update to 1.811
+  - Fixed bug in MCE::Queue (dequeue_nb) when queue has zero items
+  - Applied small optimization in MCE::Core::Input::Sequence and Generator
+  - Added cross-platform template to MCE::Examples for making an executable
+  - Removed signal handling for XCPU and XFSZ from MCE::Signal
+  - Imply posix_exit => 1 if Gearman::XS or Gearman::Util is present during
+MCE construction
+  - Added MCE + Gearman demonstrations (xs and non-xs) on Github:
+https://github.com/marioroy/mce-examples/tree/master/gearman_xs
+https://github.com/marioroy/mce-examples/tree/master/gearman
+  - Changed kilobytes and megabytes to kibiBytes (KiB) and mebiBytes (MiB)
+respectively inside the documentation
+
 * Sat Feb 11 2017 Fedora Release Engineering  - 
1.810-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
 
diff --git a/sources b/sources
index bf8e00a..ed813ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-003b23ba6f87864e532d18ca1f8ea555  MCE-1.810.tar.gz
+SHA512 (MCE-1.811.tar.gz) = 
f51d81e2500c7be8e40145203962461edd2c7f787e96ec911344365b81f9cf695ede315def57b0b1a7342363a41e0df4d9234b6fa59b63d210e2e4cf612a3ac8
-- 
cgit v1.1



https://src.fedoraproject.org/cgit/perl-MCE.git/commit/?h=master=32d6f6bda2c59264ab35c0208b15cb696ebe358c
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded MCE-1.811.tar.gz for perl-MCE

f51d81e2500c7be8e40145203962461edd2c7f787e96ec911344365b81f9cf695ede315def57b0b1a7342363a41e0df4d9234b6fa59b63d210e2e4cf612a3ac8
  MCE-1.811.tar.gz

https://src.fedoraproject.org/lookaside/pkgs/perl-MCE/MCE-1.811.tar.gz/sha512/f51d81e2500c7be8e40145203962461edd2c7f787e96ec911344365b81f9cf695ede315def57b0b1a7342363a41e0df4d9234b6fa59b63d210e2e4cf612a3ac8/MCE-1.811.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1422061] perl-Devel-Confess-0.009004 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-Confess-0.009004
   ||-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2017-02-14 07:29:10



-- 
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 1422066] New: perl-MCE-1.811 is available

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

Bug ID: 1422066
   Summary: perl-MCE-1.811 is available
   Product: Fedora
   Version: rawhide
 Component: perl-MCE
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.811
Current version/release in rawhide: 1.810-1.fc26
URL: http://search.cpan.org/dist/MCE/

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

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

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

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

-- 
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 1422066] perl-MCE-1.811 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-MCE-1.811-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2017-02-14 07:20:27



--- Comment #1 from Paul Howarth  ---
Already built it.

-- 
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: BuildRequire debuginfo for debugging?

2017-02-14 Thread Sandro Mani




On 14.02.2017 12:21, Richard W.M. Jones wrote:

On Mon, Feb 13, 2017 at 11:07:05PM +0100, Sandro Mani wrote:


On 13.02.2017 21:35, Dan Horák wrote:

ask Fedora infra guys for a ppc64/ppc64le VM and debug it locally?

Well the debuginfo trick would have been a quick way to get a
stacktrace, but sure, if there are any VMs available that would also
work.

There are public access POWER servers available, but IIRC you have
to fill in a form to apply for them.

For something you can run* on your local x86-64 host:

https://rwmj.wordpress.com/2016/11/24/fedora-25-is-out-virt-builder-images-available/

Rich.

* I was going to say "run quickly" there, but there's nothing
very quick about emulating POWER on x86 ...
Thanks. I'll try building in COPR which has ppc64le with gdb + debuginfo 
packages added from an external repo, and if that does not work I'll 
look at the other options.


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

[Bug 1422061] New: perl-Devel-Confess-0.009004 is available

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

Bug ID: 1422061
   Summary: perl-Devel-Confess-0.009004 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-Confess
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.009004
Current version/release in rawhide: 0.009003-1.fc26
URL: http://search.cpan.org/dist/Devel-Confess/

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

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

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

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

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

ppisar changed sergiomb's 'commit' permission on perl-Git-Wrapper (master) to 'Approved'

ppisar changed sergiomb's 'commit' permission on perl-Git-Wrapper (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Git-Wrapper/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Log-Dispatch (master). "update to 2.62, re-enable tests - Devel::Confess added by mistake in 2.60"