date:20160219


On 19/02/16 20:18 -0700, Orion Poplawski wrote:
octave has template functions that call abs() on templated variables, 
something like:


template 
T myfunc(T arg) {
T x = abs(arg);
}


This leads to errors when instantiated for unsigned types because 
abs(unsigned type) is not defined as is doesn't make sense to do.
That's fine and all, but how then does one write generic template code 
as above that works for signed and unsigned types.



template 
 typename std::enable_if::type
 generic_abs(T arg) {
   return abs(arg);
 }

template 
 typename std::enable_if::value, T>::type
 generic_abs(T arg) {
   return arg;
 }

template 
 T myfunc(T arg) {
   T x = generic_abs(arg);
 }
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Major issues with g++ 6 and gnulib


On 20/02/16 02:07 +, Jonathan Wakely wrote:

The next problem is that gnulib defines:

inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }

GCC 6 provides a standard-conforming  which defines the same
signbit overloads (as required by C++11 and C++14).  So the gnulib
header is incompatible with any conforming C++11 implementation.



Here's a patch for Octave which hacks around the above problem in
gnulib and then fixes Octave to include gnulib headers explicitly,
instead of assuming they'll get found by GCC's std::lib.

I haven't waited for octave to finish building (it's after 3am here)
but if other files fail just #include  or #include
 and it should work.

The gnulib change is a hack, a proper fix would only skip the signbit
overloads for __cplusplus >= 201103L, but would also make sure to
#undef signbit if there's an earlier #define signbit 1. Maybe that
should be done by defining @GNULIB_SIGNBIT@ to something different.

--- octave-4.0.0/libgnu/math.in.h.orig  2016-02-20 02:08:09.749957859 +
+++ octave-4.0.0/libgnu/math.in.h   2016-02-20 02:18:29.600429130 +
@@ -2204,7 +2204,7 @@
 #endif
 
 
-#if @GNULIB_SIGNBIT@
+#if @GNULIB_SIGNBIT@ && 0
 # if @REPLACE_SIGNBIT_USING_GCC@
 #  undef signbit
/* GCC 4.0 and newer provides three built-ins for signbit.  */
--- octave-4.0.0/liboctave/array/Range.cc.orig  2016-02-20 02:24:21.519828963 
+
+++ octave-4.0.0/liboctave/array/Range.cc   2016-02-20 03:00:17.681405544 
+
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include 
+
 #include "Range.h"
 #include "lo-error.h"
 #include "lo-mappers.h"
--- octave-4.0.0/liboctave/cruft/Faddeeva/Faddeeva.cc.orig  2016-02-20 
02:33:21.204975673 +
+++ octave-4.0.0/liboctave/cruft/Faddeeva/Faddeeva.cc   2016-02-20 
02:33:31.664017276 +
@@ -157,6 +157,8 @@
 
 #ifdef __cplusplus
 
+#  include 
+
 #  include "Faddeeva.hh"
 
 #  include 
--- octave-4.0.0/liboctave/numeric/lo-mappers.cc.orig   2016-02-20 
02:46:27.409102963 +
+++ octave-4.0.0/liboctave/numeric/lo-mappers.cc2016-02-20 
03:00:34.637472991 +
@@ -27,6 +27,8 @@
 
 #include 
 
+#include 
+
 #include "lo-error.h"
 #include "lo-ieee.h"
 #include "lo-mappers.h"
--- octave-4.0.0/liboctave/numeric/lo-specfun.cc.orig   2016-02-20 
02:47:00.785235724 +
+++ octave-4.0.0/liboctave/numeric/lo-specfun.cc2016-02-20 
02:47:09.936272124 +
@@ -26,6 +26,7 @@
 #include 
 #endif
 
+#include 
 #include "Range.h"
 #include "CColVector.h"
 #include "CMatrix.h"
--- octave-4.0.0/liboctave/util/cmd-edit.cc.orig2016-02-20 
02:47:30.192352697 +
+++ octave-4.0.0/liboctave/util/cmd-edit.cc 2016-02-20 03:00:42.914505914 
+
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include 
+
 #include "quit.h"
 
 #include "cmd-edit.h"
--- octave-4.0.0/liboctave/util/lo-utils.cc.orig2016-02-20 
02:48:55.376691535 +
+++ octave-4.0.0/liboctave/util/lo-utils.cc 2016-02-20 03:00:52.644544618 
+
@@ -37,6 +37,8 @@
 #include 
 #include 
 
+#include 
+
 #include "quit.h"
 
 #include "lo-error.h"
--- octave-4.0.0/libinterp/parse-tree/oct-parse.cc.orig 2016-02-20 
02:56:51.446585202 +
+++ octave-4.0.0/libinterp/parse-tree/oct-parse.cc  2016-02-20 
02:57:19.782697915 +
@@ -90,6 +90,8 @@
 #include 
 #include 
 
+#include 
+
 #include "Cell.h"
 #include "Matrix.h"
 #include "cmd-edit.h"
--- octave-4.0.0/libinterp/octave-value/ov-scalar.cc.orig   2016-02-20 
03:02:12.267861336 +
+++ octave-4.0.0/libinterp/octave-value/ov-scalar.cc2016-02-20 
03:02:20.363893540 +
@@ -26,6 +26,8 @@
 
 #include 
 
+#include 
+
 #include "data-conv.h"
 #include "mach-info.h"
 #include "lo-specfun.h"
--- octave-4.0.0/libinterp/octave-value/ov-re-mat.cc.orig   2016-02-20 
03:02:56.003035302 +
+++ octave-4.0.0/libinterp/octave-value/ov-re-mat.cc2016-02-20 
03:02:58.451045039 +
@@ -29,6 +29,8 @@
 #include 
 #include 
 
+#include 
+
 #include "data-conv.h"
 #include "lo-ieee.h"
 #include "lo-utils.h"
--- octave-4.0.0/libinterp/octave-value/ov-float.cc.orig2016-02-20 
03:03:10.763094013 +
+++ octave-4.0.0/libinterp/octave-value/ov-float.cc 2016-02-20 
03:03:18.556125011 +
@@ -26,6 +26,8 @@
 
 #include 
 
+#include 
+
 #include "data-conv.h"
 #include "mach-info.h"
 #include "lo-specfun.h"
--- octave-4.0.0/libinterp/octave-value/ov-cell.cc.orig 2016-02-20 
02:57:49.484816062 +
+++ octave-4.0.0/libinterp/octave-value/ov-cell.cc  2016-02-20 
03:04:25.203390114 +
@@ -31,6 +31,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include "Array-util.h"
 #include "byte-swap.h"
 #include "lo-utils.h"
--- octave-4.0.0/libinterp/octave-value/ov-flt-re-mat.cc.orig   2016-02-20 
03:06:10.76280 +
+++ octave-4.0.0/libinterp/octave-value/ov-flt-re-mat.cc2016-02-20 
03:05:21.411613695 +
@@ -29,6 +29,8 @@
 #include

Re: Self introduction: Ralf Senderek

Ralf Senderek wrote:
> During the development of the cryptobone software, I decided to reduce the
> cryptographic core to a bare minimum and to use Peter Gutmann's cryptlib
> as the only dependency for my own crypto code. I hope that including
> cryptlib in my own package will enrich the Fedora code base. And I hope
> to be able to make secure messaging a reality for many users who need it.

Why do you bundle cryptlib rather than simply packaging it as a library that 
other packages could use, too?

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Help with g++ 6 abs() and templates

octave has template functions that call abs() on templated variables, 
something like:


template 
T myfunc(T arg) {
T x = abs(arg);
}


This leads to errors when instantiated for unsigned types because 
abs(unsigned type) is not defined as is doesn't make sense to do.
That's fine and all, but how then does one write generic template code 
as above that works for signed and unsigned types.


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

Re: Major issues with g++ 6 and gnulib


On 02/19/2016 07:07 PM, Jonathan Wakely wrote:

The next problem is that gnulib defines:

inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }

GCC 6 provides a standard-conforming  which defines the same
signbit overloads (as required by C++11 and C++14).  So the gnulib
header is incompatible with any conforming C++11 implementation.



Yeah, I think this has been addressed here:

http://lists.gnu.org/archive/html/bug-gnulib/2016-02/msg00027.html

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

mhddfs orphaned Re: Summary/Minutes from today's FESCo Meeting (2016-02-19)

2016-02-19 Thread Sérgio Basto

And also :) 
* #1548 imntreal package maintainer not responding

mhddfs - Fuse-based file system for unifying several mount points into
one ( master f23 f22 ) is orphan. 

Maybe someone want to take this package.

Thanks,
-- 
Sérgio M. B.

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

Re: CVE-2015-7547 fix for Fedora 21

Haïkel wrote:
> /me wearing his FESCO member hat.
> 
> Please remember that F21 has reached End of Life and is *not*
> supported by fedoraproject.org
> Though these packages may fix a very critical CVE, we cannot guarantee
> that CVEs in other packages are also fixed.
> 
> So no warranties from fp.o if you keep using F21 with or without these
> packages.

To be clear, this is clearly stated in my disclaimer, which is also 
contained in my .repo file. It is clear that I cannot resurrect the whole 
Fedora Legacy as a one-man show.

I really wish Fedora would provide the infrastructure to push security 
updates for EOL releases. I still think that the one thing that killed 
Fedora Legacy was its insane amount of bureaucracy and that with an ACL-less 
free-for-all approach with no QA and with direct pushes to the repository 
(basically, the way the old Fedora Extras worked), it would just work. (The 
only restriction should be that only security updates (and fixes for 
regressions introduced by previously pushed security updates, if any) are 
allowed and that people pushing any other changes without explicit approval 
will be banned from the infrastructure.) Basically, the idea should be: You 
want a CVE fixed, you just fix it.

> /me removing his FESCO member hat
> 
> Thank you Kevin for your effort to provided a very critical bugfix to
> people who may use F21, though they shouldn't.
> At least, I appreciate that you shared your efforts with a larger set of
> people.

Glad to be of help.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

Igor Gnatenko wrote:
> Why do you want to build such packages for EOLed distro?

Because I had an immediate need for it myself and decided to share it for 
the benefit of others stuck on F21 for whatever reason.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposal: spins-kickstarts workflow changes

2016-02-19 Thread Dan Book

This sounds like a good step to me. I am used to the pull request workflow
though.

On Fri, Feb 19, 2016 at 5:55 PM, Zach Villers  wrote:

> +1 for moving forward and involving pagure. I'm not experienced enough to
> pick out any issues, but will help however I can.
> On Fri, Feb 19, 2016 at 2:37 PM Kevin Fenzi  wrote:
>
>> Greetings.
>>
>> I am sending this to the devel and spins lists. Feel free to forward to
>> other places people who might be affected by it should see it.
>>
>> Some history:
>>
>> We setup the spin-kickstart project on fedorahosted a long time ago.
>> At the start it was just the various spins and it's trac instance was
>> used in the new spins workflow. Then, it was a handy place to put the
>> dvd iso kickstart that releng made also. Then over time we added cloud
>> and docker and everything else that used a kickstart to it. In the
>> start we added some bugzilla components for the various spins for end
>> user bugs, and used the trac for workflow things. Over time due to
>> all the images there lots of people have been given commit access to
>> the repo. Then the spins sig went quiet and we have sort of been limping
>> along since then with trac tickets not getting to anyone who cares,
>> etc.
>>
>> I'd like to propose the following plan of action:
>>
>> * Setup a new project at pagure.io called just kickstarts or
>>   releng-kickstarts or something. (Bikeshed alert).
>>
>> * Setup tags for all the various groups that have kickstarts. ie,
>>   'xfce' 'docker' 'cloud' 'atomic' 'workstation' etc. And get someone
>>   from each of those groups to actually watch the tags or someone to CC
>>   on who will actually look at those tagged issues.
>>
>> * Reduce the number of commiters a bunch and ask people to submit PR's
>>   when they want a change. This will allow releng/qa to control changes
>>   when in freeze. ie, we can require a freeze break and point to the
>>   PR/bug with the exact change and merge it when it's approved.
>>
>> * Copy the git repo over to it from fedorahosted. Close that repo.
>>
>> * Mass close all the fedorahosted trac tickets and close trac to new
>>   ones with a note to file new issues in pagure. ( 21 tickets
>>   currently): https://fedorahosted.org/spin-kickstarts/report/1
>>
>> * Close the "LiveCD*" components in bugzilla to new bugs and close any
>>   existing ones with a note to refile at pagure. (18 bugs currently):
>>
>> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=LiveCD=LiveCD%20-%20FEL=LiveCD%20-%20Games=LiveCD%20-%20KDE=LiveCD%20-%20LXDE=LiveCD%20-%20Xfce_id=4654195=Fedora_format=advanced
>>
>> * Adjust koji config to pull from pagure.io instead of fedorahosted.
>>
>> Thoughts? Additional steps? Better plans?
>>
>> kevin
>> --
>> devel mailing list
>> devel@lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [ANNOUNCE] Fedora support for Vulkan

David Airlie wrote:
> No, nothing concrete has been mentioned in this area at all.
> 
> sw rendering won't benefit from vulkan very much, in fact it would be
> worse than GL in some cases, as Vulkan really works on the building up
> long command buffers and executing them, rather than direct execution in a
> context that GL does.

But eventually there will be Vulkan-only software and some fallback is 
needed for the hardware not supported by any hardware driver.

Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Major issues with g++ 6 and gnulib


The next problem is that gnulib defines:

inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }

GCC 6 provides a standard-conforming  which defines the same
signbit overloads (as required by C++11 and C++14).  So the gnulib
header is incompatible with any conforming C++11 implementation.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Major issues with g++ 6 and gnulib


On 19/02/16 16:33 -0700, Orion Poplawski wrote:

I seem to be able to work around it at the moment by explicitly including
 before ,


That might actually be a reasonable fix.

There is no guarantee whatsoever that  includes , so it
is not portable and not guaranteed to work when Octave assumes that
including  will indirectly include gnulib's .

If Octave wants to include gnulib's  then it should be
including it itself, not relying on some other header doing so
indirectly.

Furthermore, when GCC's  wants to include  it *really*
does want libc's , which is what GCC was configured against,
and what it expects to find again when you compile. If some other
 turns up it could break all sorts of things.

Gnulib does seem to be going to some lengths to co-operate with the
real  (using #include_next itself, and putting everything in a
namespace when requested to) but it's entirely right that  gets
to decide what it wants to include, Octave should not be interfering
with the implementation's headers.

So for Octave to include gnulib's  either it should have a
different name, such as , or it should include it as
, or just ensure it is included directly, and not as a
side effect of including .
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Tim Orling

I am also interested in maintaining or co-maintaining:
rpms/bitbake -- Build tool executing tasks and managing metadata (
master f23 f22 )

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

Re: Major issues with g++ 6 and gnulib


On 19/02/16 23:45 +, Jonathan Wakely wrote:

If gnulib wants to play at being the standard library it needs to do
so correctly, to be compatible with whatever standard library is it
pretending to be, as documented at
https://gcc.gnu.org/gcc-6/porting_to.html (which would probably mean
the path to the gnulib headers needs to be specified with -isystem not
-I so that it comes after the libstdc++  not before it).


And also using the _GLIBCXX_INCLUDE_NEXT_C_HEADERS trick to forward on
to libc 


If gnulib is not trying to be  but is just borrowing the name
then it needs to change the name to avoid undefined behaviour.


This seems more likely, if it's defining gnulib::floor and not
std::floor.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Major issues with g++ 6 and gnulib


On 19/02/16 16:33 -0700, Orion Poplawski wrote:

It appears that as of 6.0.0, /usr/include/c++/6.0.0/cmath does:

#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

which appears to have the effect of forcing it to include /usr/include/math.h


It has the effect of skipping the first  that gets found, so
that we don't end up in a loop. The purpose of that is to find the
libc  rather than the libstdc++ one, so typically
/usr/include/math.h, yes.


instead of the math.h from gnulib, which I expect is how gnulib worked with
C++ before.  This appears to be done now for all of the C++ C library header
wrappers, e.g. cstdlib:


No, only for  and .


This is currently causing lots of trouble for octave by effectively disabling
gnulib.  Since octave uses the GNULIB_NAMESPACE of "gnulib", it is using
things like "gnulib::floor", but since the gnulib math.h is no longer included
there is no gnulib::floor declared.


 is a standard header, putting another header with that name
in the include path is undefined behaviour.

If gnulib wants to play at being the standard library it needs to do
so correctly, to be compatible with whatever standard library is it
pretending to be, as documented at
https://gcc.gnu.org/gcc-6/porting_to.html (which would probably mean
the path to the gnulib headers needs to be specified with -isystem not
-I so that it comes after the libstdc++  not before it).

If gnulib is not trying to be  but is just borrowing the name
then it needs to change the name to avoid undefined behaviour.


I seem to be able to work around it at the moment by explicitly including
 before , although I still haven't managed to get octave to
compile yet.  But I expect a better solution will need to be found for a
permanent fix.


I'll look into it and see what gnulib is playing at.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Major issues with g++ 6 and gnulib

It appears that as of 6.0.0, /usr/include/c++/6.0.0/cmath does:

#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

which appears to have the effect of forcing it to include /usr/include/math.h
instead of the math.h from gnulib, which I expect is how gnulib worked with
C++ before.  This appears to be done now for all of the C++ C library header
wrappers, e.g. cstdlib:


// Need to ensure this finds the C library's  not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS


This is currently causing lots of trouble for octave by effectively disabling
gnulib.  Since octave uses the GNULIB_NAMESPACE of "gnulib", it is using
things like "gnulib::floor", but since the gnulib math.h is no longer included
there is no gnulib::floor declared.

I seem to be able to work around it at the moment by explicitly including
 before , although I still haven't managed to get octave to
compile yet.  But I expect a better solution will need to be found for a
permanent fix.

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

Re: Proposal: spins-kickstarts workflow changes

2016-02-19 Thread Zach Villers

+1 for moving forward and involving pagure. I'm not experienced enough to
pick out any issues, but will help however I can.
On Fri, Feb 19, 2016 at 2:37 PM Kevin Fenzi  wrote:

> Greetings.
>
> I am sending this to the devel and spins lists. Feel free to forward to
> other places people who might be affected by it should see it.
>
> Some history:
>
> We setup the spin-kickstart project on fedorahosted a long time ago.
> At the start it was just the various spins and it's trac instance was
> used in the new spins workflow. Then, it was a handy place to put the
> dvd iso kickstart that releng made also. Then over time we added cloud
> and docker and everything else that used a kickstart to it. In the
> start we added some bugzilla components for the various spins for end
> user bugs, and used the trac for workflow things. Over time due to
> all the images there lots of people have been given commit access to
> the repo. Then the spins sig went quiet and we have sort of been limping
> along since then with trac tickets not getting to anyone who cares,
> etc.
>
> I'd like to propose the following plan of action:
>
> * Setup a new project at pagure.io called just kickstarts or
>   releng-kickstarts or something. (Bikeshed alert).
>
> * Setup tags for all the various groups that have kickstarts. ie,
>   'xfce' 'docker' 'cloud' 'atomic' 'workstation' etc. And get someone
>   from each of those groups to actually watch the tags or someone to CC
>   on who will actually look at those tagged issues.
>
> * Reduce the number of commiters a bunch and ask people to submit PR's
>   when they want a change. This will allow releng/qa to control changes
>   when in freeze. ie, we can require a freeze break and point to the
>   PR/bug with the exact change and merge it when it's approved.
>
> * Copy the git repo over to it from fedorahosted. Close that repo.
>
> * Mass close all the fedorahosted trac tickets and close trac to new
>   ones with a note to file new issues in pagure. ( 21 tickets
>   currently): https://fedorahosted.org/spin-kickstarts/report/1
>
> * Close the "LiveCD*" components in bugzilla to new bugs and close any
>   existing ones with a note to refile at pagure. (18 bugs currently):
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=LiveCD=LiveCD%20-%20FEL=LiveCD%20-%20Games=LiveCD%20-%20KDE=LiveCD%20-%20LXDE=LiveCD%20-%20Xfce_id=4654195=Fedora_format=advanced
>
> * Adjust koji config to pull from pagure.io instead of fedorahosted.
>
> Thoughts? Additional steps? Better plans?
>
> kevin
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: unannounced soname bump: libglpk

2016-02-19 Thread Jerry James

On Fri, Feb 19, 2016 at 10:12 AM, Andrew Lutomirski  wrote:
> I believe this is the list of broken packages in rawhide.

I have already rebuilt cbmc and python(2,3)-cvxopt.  I am preparing an
update for ntl that will require rebuilds of 4ti2(-libs) and
sagemath-core anyway, so those will be fixed en passant (possibly not
until tomorrow, depending on how fast I am).
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: unannounced soname bump: libglpk

On 02/19/2016 11:33 AM, Björn Esser wrote:
> 
> Am 19.02.2016 18:12 schrieb Andrew Lutomirski :
>>
>> I believe this is the list of broken packages in rawhide.
>>
>> $ sudo dnf --disablerepo=\* --enablerepo=rawhide repoquery --whatrequires 
>> 'libglpk.so.36()(64bit)'
>> Fedora rawhide - x86_64 277 kB/s |  45 MB 02:46  
>>   
>> Last metadata expiration check performed 0:01:51 ago on Fri Feb 19 09:08:26 
>> 2016.
>> 4ti2-0:1.6.3-7.fc24.x86_64
>> 4ti2-libs-0:1.6.3-7.fc24.x86_64
>> R-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> cbmc-0:5.3-3.fc24.x86_64
>> coin-or-lemon-0:1.3.1-6.fc24.x86_64
>> coin-or-lemon-tools-0:1.3.1-6.fc24.x86_64
>> java-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> lua-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> mono-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> octave-6:4.0.0-10.fc24.x86_64
>> octave-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> openms-0:2.0.0-30.20160121git6f51b3.fc24.x86_64
>> ppl-utils-0:1.1-12.fc24.x86_64
>> python2-cvxopt-0:1.1.8-3.fc24.x86_64
>> python2-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> python3-cvxopt-0:1.1.8-3.fc24.x86_64
>> python3-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> ruby-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> sagemath-core-0:6.8-2.fc24.x86_64
>> shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> shogun-cli-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>>
>> I'm rebuilding coin-or-lemon now.
> 
> Shogun depends on Octave, which depends on glpk, and that FTBFS currently...

I'm working on a fix for octave.


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

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Sérgio Basto

On Sex, 2016-02-19 at 15:11 -0500, Felix Miata wrote:
> Tomasz Torcz composed on 2016-02-19 20:40 (UTC+0100):
> 
> > On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
> 
> > > Igor Gnatenko composed:
> 
> > > > Why do you want to build such packages for EOLed distro?
> 
> > > Because he's a nicy guy and it's an important patch?
> 
> >   It's counter productive.  It's even dangerous, by introducing
> > false sense of safety (apart from glibc, there are lots of
> > other packages with security vulnerabilities in F21).
> 
> The problem with 22+ is that they provide an unstable playground
> variously
> called KDE5 or Plasma5, while 21 has a nice stable fully functional
> KDE4. I'm
> pretty sure IIRC that OP is primarily a KDE user.

yeah , the nice stable fully functional KDE4, continues in copr with my
and Piotr repos [1] and what I'm using in F23 

[1]
https://copr.fedoraproject.org/coprs/peem/kde4-fedora/builds/
https://copr.fedorainfracloud.org/coprs/sergiomb/kde4for23/

-- 
Sérgio M. B.

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

Re: CVE-2015-7547 fix for Fedora 21


On 19/02/16 20:18 +0100, Fabio Alessandro Locati wrote:

From my point of view, the whole concept of "EOL" is: if you use this
version you acknowledge that NO security patch will arrive and therefore
it's possible and very likely that you are running an unsafe system.

I think the important part is to help people to update to supported
versions, not to push patches is EOL releses.


He didn't push it to fedora repos, he created his own repo to share
packages with people who might use them.

I don't think anyone who is still running F21 is going to think
Kevin's one good deed for this important fix implies the rest of the
EOL distro is safe. If they are willing to configure a separate repo
to get the fix I assume they know they're running an EOL release, and
know what that implies.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Emmanuel Seyman

* Josh Boyer [19/02/2016 13:09] :
>
> As a heads up to the greater community, the packages are listed below.

[ snip lots of perl modules ]

I'll ping the Perl SIG and ask how many people are willing to share the load.

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

Re: [Guidelines change] Changes to the packaging guidelines

2016-02-19 Thread Richard W.M. Jones

On Fri, Feb 19, 2016 at 09:29:16AM -0700, Kevin Fenzi wrote:
> On Fri, 19 Feb 2016 10:07:29 +
> "Richard W.M. Jones"  wrote:
> 
> > Here's a video demonstrating this:
> > 
> >   http://oirase.annexia.org/tmp/packaging-caching/
> 
> I think this is fallout from some problems we had with a memcached
> server yesterday. I've cleared out our varnish cache, so it should
> hopefully refresh right now from memcached. 
> 
> Can you let me know if the problem persists? And if so, ideally file an
> infrastructure ticket on it?

Yes, the problem persists.  It still behaves exactly the same as the
video.  I filed a ticket here:

  https://fedorahosted.org/fedora-infrastructure/ticket/5118

Rich.

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

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Jonathan Underwood

On 19 February 2016 at 18:09, Josh Boyer  wrote:
> rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( master f23 f22 )

I am happy to take this (already a co-maintainer).
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Tim Orling

I have an interest in either taking over or co-maintaining:
rpms/bwm-ng -- Bandwidth Monitor NG ( master f23 f22 epel7 el6 )
rpms/libstatgrab -- A library that provides cross platform access to
statistics of the system ( master f23 f22 epel7 el6 )

I'll have to digest the rest of the list to see if there are more.

Regards,
Tim
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Haïkel

2016-02-19 3:35 GMT+01:00 Kevin Kofler :
> Hi,
>
> I have built an updated glibc package for Fedora 21, with (alleged) fixes
> for the following security issues:
> * CVE-2015-7547 (CRITICAL)
> * CVE-2015-1781
> * CVE-2015-8777
> * glibc PR17269
> * glibc PR18032
> backported from Fedora 22 or forward-ported from CentOS 7. (To the best of
> my knowledge, the patches I backported do indeed address the above issues,
> but I cannot provide any kind of guarantees for that.)
>
> You can find it in the following repository:
> https://repos.fedorapeople.org/kkofler/f21-security/
> (I had to use the old repos.fedorapeople.org infrastructure because the Copr
> maintainers "helpfully" deleted the Fedora 21 buildroots, making Copr
> entirely useless for the purpose of building security updates for
> distributions Fedora no longer provides them for. I consider this a very bad
> idea and an absolutely counterproductive practice.)
>
> As specified in the .repo file, the packages are signed with my CalcForge
> GPG key, available over HTTPS (with a valid certificate from Let's Encrypt):
> https://www.calcforge.org/RPM-GPG-KEY-calcforge
>
> This repository is provided "AS IS", in the hope that it will be useful, but
> WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> or FITNESS FOR A PARTICULAR PURPOSE.  In particular, NO warrants of any kind
> are made for completeness of security fix coverage.
>
> Currently, glibc is the ONLY package that has an update available in the
> above repository.
>
> Kevin Kofler

/me wearing his FESCO member hat.

Please remember that F21 has reached End of Life and is *not*
supported by fedoraproject.org
Though these packages may fix a very critical CVE, we cannot guarantee
that CVEs in other packages are also fixed.

So no warranties from fp.o if you keep using F21 with or without these packages.


/me removing his FESCO member hat

Thank you Kevin for your effort to provided a very critical bugfix to
people who may use F21, though they shouldn't.
At least, I appreciate that you shared your efforts with a larger set of people.

Regards,
H.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Fedora Rawhide 20160219 compose check report

2016-02-19 Thread Fedora compose checker

Missing expected images:

Cloud disk raw i386
Cloud_atomic disk raw x86_64
Generic boot x86_64
Workstation live x86_64
Workstation live i386
Generic boot i386
Kde disk raw armhfp
Kde live i386
Cloud disk raw x86_64
Kde live x86_64

No images in this compose but not Rawhide 20160218

Images in Rawhide 20160218 but not this:

Design_suite live x86_64
Generic boot x86_64
Lxde live i386
Soas disk raw armhfp
Xfce disk raw armhfp
Cloud vagrant virtualbox x86_64
Xfce live i386
Scientific_kde live x86_64
Lxde live x86_64
Cloud disk raw x86_64
Design_suite live i386
Cloud_atomic disk raw x86_64
Games live x86_64
Robotics live i386
Workstation live i386
Games live i386
Cloud_atomic disk qcow x86_64
Soas live i386
Cloud_atomic vagrant libvirt x86_64
Cloud disk qcow x86_64
Generic boot i386
Security live x86_64
Cloud vagrant libvirt x86_64
Cinnamon live i386
Xfce live x86_64
Workstation disk raw armhfp
Cinnamon live x86_64
Kde live x86_64
Mate live x86_64
Workstation live x86_64
Cloud docker x86_64
Robotics live x86_64
Kde disk raw armhfp
Soas live x86_64
Kde live i386
Mate disk raw armhfp
Cloud_atomic vagrant virtualbox x86_64
Scientific_kde live i386
Mate live i386
Security live i386

No openQA tests found for compose.
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Przemek Klosowski


On 02/19/2016 02:40 PM, Tomasz Torcz wrote:

On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:

Igor Gnatenko  writes:

Why do you want to build such packages for EOLed distro?

Because he's a nicy guy and it's an important patch?

   It's counter productive.  It's even dangerous, by introducing
false sense of safety (apart from glibc, there are lots of
other packages with security vulnerabilities in F21).
I don't think anyone sees it as precedent; it's more of a public health 
emergency measure.
People who run F21 either don't care (in which case this is moot), or 
had a specific reason to run it in spite of lack of support.


Did you argue against providing Heartbleed patches for ancient systems?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Felix Miata

Tomasz Torcz composed on 2016-02-19 20:40 (UTC+0100):

> On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:

>> Igor Gnatenko composed:

>> > Why do you want to build such packages for EOLed distro?

>> Because he's a nicy guy and it's an important patch?

>   It's counter productive.  It's even dangerous, by introducing
> false sense of safety (apart from glibc, there are lots of
> other packages with security vulnerabilities in F21).

The problem with 22+ is that they provide an unstable playground variously
called KDE5 or Plasma5, while 21 has a nice stable fully functional KDE4. I'm
pretty sure IIRC that OP is primarily a KDE user.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

orphaning virtuoso

2016-02-19 Thread Rex Dieter

I've been nmaintaining virtuoso-opensource primarily due to it being needed 
by (kde) nepomuk, but as we've recently deprecated/retired nepomuk recently 
in rawhide, I will be orphaning virtuoso (in the hopes that it finds a 
better home).

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

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Pierre-Yves Chibon

On Fri, Feb 19, 2016 at 08:43:09PM +0100, Pierre-Yves Chibon wrote:
> On Fri, Feb 19, 2016 at 06:34:03PM +, Igor Gnatenko wrote:
> >rpms/python-pygit2 -- Python 2.x bindings for libgit2 ( master f23 f22
> >epel7 )
> > 
> >whats wrong with this package? I think it is well-maintained by me.
> 
> It needs an upgrade to 0.23.3 on F23 as otherwise it just failed upon import 
> for
> me.
I forgot to add that to make things interesting 0.23.3 builds fine on x86_64 but
fails on i686...

http://koji.fedoraproject.org/koji/taskinfo?taskID=13024033


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

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Pierre-Yves Chibon

On Fri, Feb 19, 2016 at 06:34:03PM +, Igor Gnatenko wrote:
>rpms/python-pygit2 -- Python 2.x bindings for libgit2 ( master f23 f22
>epel7 )
> 
>whats wrong with this package? I think it is well-maintained by me.

It needs an upgrade to 0.23.3 on F23 as otherwise it just failed upon import for
me.
I don't mind helping with it if you're interested.

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

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Tomasz Torcz

On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
> 
> Igor Gnatenko  writes:
> > Why do you want to build such packages for EOLed distro?
> 
> Because he's a nicy guy and it's an important patch?

  It's counter productive.  It's even dangerous, by introducing
false sense of safety (apart from glibc, there are lots of
other packages with security vulnerabilities in F21).

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Proposal: spins-kickstarts workflow changes

2016-02-19 Thread Kevin Fenzi

Greetings.

I am sending this to the devel and spins lists. Feel free to forward to
other places people who might be affected by it should see it.

Some history:

We setup the spin-kickstart project on fedorahosted a long time ago.
At the start it was just the various spins and it's trac instance was
used in the new spins workflow. Then, it was a handy place to put the
dvd iso kickstart that releng made also. Then over time we added cloud
and docker and everything else that used a kickstart to it. In the
start we added some bugzilla components for the various spins for end
user bugs, and used the trac for workflow things. Over time due to
all the images there lots of people have been given commit access to
the repo. Then the spins sig went quiet and we have sort of been limping
along since then with trac tickets not getting to anyone who cares,
etc.

I'd like to propose the following plan of action:

* Setup a new project at pagure.io called just kickstarts or
releng-kickstarts or something. (Bikeshed alert).

* Setup tags for all the various groups that have kickstarts. ie,
'xfce' 'docker' 'cloud' 'atomic' 'workstation' etc. And get someone
from each of those groups to actually watch the tags or someone to CC
on who will actually look at those tagged issues.

* Reduce the number of commiters a bunch and ask people to submit PR's
when they want a change. This will allow releng/qa to control changes
when in freeze. ie, we can require a freeze break and point to the
PR/bug with the exact change and merge it when it's approved.

* Copy the git repo over to it from fedorahosted. Close that repo.

* Mass close all the fedorahosted trac tickets and close trac to new
ones with a note to file new issues in pagure. ( 21 tickets
currently): https://fedorahosted.org/spin-kickstarts/report/1

* Close the "LiveCD*" components in bugzilla to new bugs and close any
existing ones with a note to refile at pagure. (18 bugs currently):

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=LiveCD=LiveCD%20-%20FEL=LiveCD%20-%20Games=LiveCD%20-%20KDE=LiveCD%20-%20LXDE=LiveCD%20-%20Xfce_id=4654195=Fedora_format=advanced

* Adjust koji config to pull from pagure.io instead of fedorahosted.

Thoughts? Additional steps? Better plans?

kevin

pgpn3CaKCBxKE.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread Fabio Alessandro Locati

On Fri, Feb 19, 2016 at 02:05:18PM -0500, DJ Delorie wrote:
> Igor Gnatenko  writes:
> > Why do you want to build such packages for EOLed distro?
> 
> Because he's a nicy guy and it's an important patch?

From my point of view, the whole concept of "EOL" is: if you use this
version you acknowledge that NO security patch will arrive and therefore
it's possible and very likely that you are running an unsafe system.

I think the important part is to help people to update to supported
versions, not to push patches is EOL releses.

-- 
Fabio Alessandro Locati

PGP Fingerprint: B960 BE9D E7A8 FA12 273A  98BB 6D6A 29D6 709A 7851
https://keybase.io/fale

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

Self introduction: Ralf Senderek

2016-02-19 Thread Ralf Senderek

Hello,

my name is Ralf Senderek, I'm a secure solutions designer. Linux is
my operating system since 1994. Over time I have developed and 
released security related analysis and open source software on my 
personal web site. 

Recently, since Jan 2015, I am working on a secure message system called 
Crypto Bone which combines usability and security. I tried to make this system
as usable as possible with an new approach to encryption key management,
because I realized, that complex key management is the main reason for
ordinary users not to use encryption. And I want to change that.

On the other hand, I need to secure the encryption keys in a way that enables
the ordinary user to take control himself. The result - the cryptobone - is now
finished and I thought I should package this software for the Fedora 
repository. 

So I requested a review of the new cryptobone package: 
https://bugzilla.redhat.com/show_bug.cgi?id=1310092

And, of course, I'm seeking a sponsor for this package, because I'm a 
new contributor.

During the development of the cryptobone software, I decided to reduce the
cryptographic core to a bare minimum and to use Peter Gutmann's cryptlib
as the only dependency for my own crypto code. I hope that including
cryptlib in my own package will enrich the Fedora code base. And I hope
to be able to make secure messaging a reality for many users who need it.

Thank you for your interest and feedback.

Ralf.

PGP key: https://senderek.ie/keys/encryptionkey.asc (2546174A)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Fabio Alessandro Locati

If Christopher will not respond, I can take care of:

- rpms/2ping -- Bi-directional ping utility
- rpms/NetPIPE -- Network Protocol Independent Performance Evaluator
- rpms/ascii-design -- A tool to create ascii arts
- rpms/bonesi -- The DDoS Botnet Simulator
- rpms/cdk -- Curses Development Kit
- rpms/httrack -- Website copier and offline browser
- rpms/httraqt -- HTTrack Qt GUI
- rpms/ioping -- Simple disk I/O latency monitoring tool
- rpms/libnatpmp -- Library of The NAT Port Mapping Protocol (NAT-PMP)
- rpms/libproxy -- A library handling all the details of proxy configuration
- rpms/libupnp -- Universal Plug and Play (UPnP) SDK
- rpms/lzma -- LZMA utils
- rpms/mylvmbackup -- Utility for creating MySQL backups via LVM snapshots
- rpms/nf3d -- 3D Netfilter visualization utility
- rpms/ngrep -- Network layer grep tool
- rpms/nload -- A tool can monitor network traffic and bandwidth usage
  in real time
- rpms/nsnake -- The classic snake game with textual interface
- rpms/pgpdump -- PGP packet visualizer
- rpms/pixz -- Parallel indexed xz compressor
- rpms/postgrey -- Postfix Greylisting Policy Server
- rpms/python-pgpdump -- PGP packet parser library in Python 2.x 
- rpms/python-pygit2 -- Python 2.x bindings for libgit2
- rpms/python-reportlab -- Python 2.x library for generating PDFs and
  graphics
- rpms/python3-dugong -- Python 3.x HTTP 1.1 client module
- rpms/rats -- Rough Auditing Tool for Security
- rpms/recoverjpeg -- Recover JPEG pictures and MOV movies from damaged
  devices
- rpms/ripright -- Minimal CD to FLAC ripper
- rpms/tiptop -- Performance monitoring tool based on hardware counters
- rpms/zmap -- Network scanner for Internet-wide network studies 

Also I can help with the i3 packages as I volounteered few weeks ago and
have been shot down by Christopher becase "no more help is needed". 

-- 
Fabio Alessandro Locati

PGP Fingerprint: B960 BE9D E7A8 FA12 273A  98BB 6D6A 29D6 709A 7851
https://keybase.io/fale


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

Re: CVE-2015-7547 fix for Fedora 21

2016-02-19 Thread DJ Delorie


Igor Gnatenko  writes:
> Why do you want to build such packages for EOLed distro?

Because he's a nicy guy and it's an important patch?
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Josh Boyer

On Fri, Feb 19, 2016 at 2:01 PM, Remi Collet  wrote:
> Le 19/02/2016 19:09, Josh Boyer a écrit :
>> Hello,
>>
>> In today's FESCo meeting, FESCo agreed to orphan all of Christoper
>> Meng's packages on February 26, 2016 at 17:00 UTC if there was no
>> further contact from Christopher.
>
> Please, also be aware of 78 pending reviews
>
> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Package%20Review=i%40cicku.me=1=substring_id=4654252=Fedora_format=advanced

Thanks.  That is good to be aware of indeed.

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

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Remi Collet

Le 19/02/2016 19:09, Josh Boyer a écrit :
> Hello,
> 
> In today's FESCo meeting, FESCo agreed to orphan all of Christoper
> Meng's packages on February 26, 2016 at 17:00 UTC if there was no
> further contact from Christopher.  

Please, also be aware of 78 pending reviews

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Package%20Review=i%40cicku.me=1=substring_id=4654252=Fedora_format=advanced


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

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Remi Collet

I no answer from C.M., I will take:

> rpms/libsodium -- The Sodium crypto library ( master f23 f22 epel7 el6 )



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

[Bug 1306668] slic3r-1.2.9-4.fc24 FTBFS: redefinition of 'struct boost::polygon::coordinate_traits'

2016-02-19 Thread bugzilla

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

Yaakov Selkowitz  changed:

   What|Removed |Added

 CC||yselk...@redhat.com



--- Comment #3 from Yaakov Selkowitz  ---
Culprit is boost 1.60.  Mentioned upstream in
https://github.com/alexrj/Slic3r/issues/3117 (scroll down to Jan 8).  No fix
yet upstream.

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

Re: Large number of packages to be orphaned on Feb 26

You are not the owner. This is not a question of maintainance itself in
this case (and in case of my i3 stuff too)

On 02/19/2016 07:34 PM, Igor Gnatenko wrote:
> rpms/python-pygit2 -- Python 2.x bindings for libgit2 ( master f23 f22
> epel7 )
>
> whats wrong with this package? I think it is well-maintained by me.
>
> On Fri, Feb 19, 2016 at 7:09 PM Josh Boyer  > wrote:
>
> Hello,
>
> In today's FESCo meeting, FESCo agreed to orphan all of Christoper
> Meng's packages on February 26, 2016 at 17:00 UTC if there was no
> further contact from Christopher.  Normally we would not necessarily
> pre-announce an oprhaning action, however the number of packages in
> question is quite large.  He is the point of contact for 230 packages.
>
> As a heads up to the greater community, the packages are listed below.
> In the event that we have to go through with the orphaning, please
> review them for packages you may wish to take over as the primary
> point of contact.  Should Christopher respond, we would still
> encourage actively seeking out co-maintainers for all of these
> packages.
>
> Thank you.
>
> josh
>
> rpms/2ping -- Bi-directional ping utility ( master f23 f22 epel7 el6 )
> rpms/CImg -- C++ Template Image Processing Toolkit ( master f23 f22 )
> rpms/NetPIPE -- Network Protocol Independent Performance Evaluator (
> master f23 f22 epel7 el6 )
> rpms/PyMca -- PyMca X-ray Fluorescence Toolkit ( master f23 f22 )
> rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( master f23 f22 )
> rpms/RemoteBox -- Open Source VirtualBox Client with Remote Management
> ( master f23 f22 epel7 el6 )
> rpms/abakus -- The simple KDE calculator ( master f23 f22 )
> rpms/aime -- An application embeddable programming language
> interpreter ( master f23 f22 )
> rpms/ale -- Combines multiple inputs of the same scene ( f22 )
> rpms/alliance -- VLSI EDA System ( master f23 f22 )
> rpms/ansifilter -- ANSI terminal escape code converter ( master f23
> f22 epel7 el6 )
> rpms/ascii-design -- A tool to create ascii arts ( master f23 f22
> epel7 )
> rpms/backintime -- Simple backup tool inspired from the Flyback
> project and TimeVault ( master f23 f22 epel7 )
> rpms/be -- Bugs Everywhere, a distributed bug tracker ( master f23
> f22 el6 )
> rpms/bitbake -- Build tool executing tasks and managing metadata (
> master f23 f22 )
> rpms/bleachbit -- Python utility to free disk space and improve
> privacy ( master f23 f22 epel7 el6 el5 )
> rpms/blktap -- Blktap Userspace Tools + Library ( master f23 f22 )
> rpms/bonesi -- The DDoS Botnet Simulator ( master f23 f22 )
> rpms/budgie -- Simple and distraction free GTK+3 media player (
> master f23 f22 )
> rpms/bunny -- Instrumented C code security fuzzer ( master f23 f22 )
> rpms/bwm-ng -- Bandwidth Monitor NG ( master f23 f22 epel7 el6 )
> rpms/cal3d -- Skeletal based 3-D character animation library ( master
> f23 f22 el6 el5 )
> rpms/cdk -- Curses Development Kit ( epel7 el6 )
> rpms/cego -- A relational and transactional database ( master f23 f22
> epel7 el6 )
> rpms/cfengine -- A systems administration tool for networks (
> master f23 f22 )
> rpms/cgnslib -- Computational Fluid Dynamics General Notation System (
> master f23 f22 epel7 el6 )
> rpms/chinese-calendar -- A Chinese traditional calendar of UbuntuKylin
> ( master f23 f22 )
> rpms/cln -- Class Library for Numbers ( master f23 f22 epel7 el6 )
> rpms/ctemplate -- A simple but powerful template language for C++ (
> master f23 f22 epel7 )
> rpms/darkhttpd -- A secure, lightweight, fast, single-threaded
> HTTP/1.1 server ( master f23 f22 epel7 el6 )
> rpms/desktopcouch -- A CouchDB instance on every desktop ( master
> f23 f22 )
> rpms/diffuse -- Graphical tool for merging and comparing text
> files ( epel7 )
> rpms/dinotrace -- Waveform viewer for electronics ( master f23 f22 )
> rpms/dissy -- Graphical frontend to the objdump disassembler (
> master f23 f22 )
> rpms/dmenu -- Generic menu for X ( master f23 f22 epel7 el6 )
> rpms/docky -- Advanced dock application written in Mono ( master
> f23 f22 )
> rpms/dreampie -- A graphical cross-platform interactive Python shell (
> master f23 f22 )
> rpms/dvdbackup -- Command line tool for ripping video DVDs ( master
> f23 f22 epel7 el6 )
> rpms/elektra -- A key/value pair database to store software
> configurations ( master f23 f22 epel7 )
> rpms/eqntott -- Generates truth tables from Boolean equations ( master
> f23 f22 el6 )
> rpms/exaile -- Simple but powerful Amarok-style music player for GTK
> users ( master f23 f22 epel7 )
> rpms/fakechroot -- Gives a fake chroot environment ( master f23 f22 )
> rpms/fdm --

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Björn Esser

I'll take json-c and qd, since both are Shogun dependencies.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

Btw you can take it after orphaning ;)

On 02/19/2016 07:36 PM, Christian Dersch wrote:
> You are not the owner. This is not a question of maintainance itself
> in this case (and in case of my i3 stuff too)
>
> On 02/19/2016 07:34 PM, Igor Gnatenko wrote:
>> rpms/python-pygit2 -- Python 2.x bindings for libgit2 ( master f23
>> f22 epel7 )
>>
>> whats wrong with this package? I think it is well-maintained by me.
>>
>> On Fri, Feb 19, 2016 at 7:09 PM Josh Boyer
>>  wrote:
>>
>> Hello,
>>
>> In today's FESCo meeting, FESCo agreed to orphan all of Christoper
>> Meng's packages on February 26, 2016 at 17:00 UTC if there was no
>> further contact from Christopher.  Normally we would not necessarily
>> pre-announce an oprhaning action, however the number of packages in
>> question is quite large.  He is the point of contact for 230
>> packages.
>>
>> As a heads up to the greater community, the packages are listed
>> below.
>> In the event that we have to go through with the orphaning, please
>> review them for packages you may wish to take over as the primary
>> point of contact.  Should Christopher respond, we would still
>> encourage actively seeking out co-maintainers for all of these
>> packages.
>>
>> Thank you.
>>
>> josh
>>
>> rpms/2ping -- Bi-directional ping utility ( master f23 f22 epel7
>> el6 )
>> rpms/CImg -- C++ Template Image Processing Toolkit ( master f23 f22 )
>> rpms/NetPIPE -- Network Protocol Independent Performance Evaluator (
>> master f23 f22 epel7 el6 )
>> rpms/PyMca -- PyMca X-ray Fluorescence Toolkit ( master f23 f22 )
>> rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( master f23 f22 )
>> rpms/RemoteBox -- Open Source VirtualBox Client with Remote
>> Management
>> ( master f23 f22 epel7 el6 )
>> rpms/abakus -- The simple KDE calculator ( master f23 f22 )
>> rpms/aime -- An application embeddable programming language
>> interpreter ( master f23 f22 )
>> rpms/ale -- Combines multiple inputs of the same scene ( f22 )
>> rpms/alliance -- VLSI EDA System ( master f23 f22 )
>> rpms/ansifilter -- ANSI terminal escape code converter ( master f23
>> f22 epel7 el6 )
>> rpms/ascii-design -- A tool to create ascii arts ( master f23 f22
>> epel7 )
>> rpms/backintime -- Simple backup tool inspired from the Flyback
>> project and TimeVault ( master f23 f22 epel7 )
>> rpms/be -- Bugs Everywhere, a distributed bug tracker ( master
>> f23 f22 el6 )
>> rpms/bitbake -- Build tool executing tasks and managing metadata (
>> master f23 f22 )
>> rpms/bleachbit -- Python utility to free disk space and improve
>> privacy ( master f23 f22 epel7 el6 el5 )
>> rpms/blktap -- Blktap Userspace Tools + Library ( master f23 f22 )
>> rpms/bonesi -- The DDoS Botnet Simulator ( master f23 f22 )
>> rpms/budgie -- Simple and distraction free GTK+3 media player (
>> master f23 f22 )
>> rpms/bunny -- Instrumented C code security fuzzer ( master f23 f22 )
>> rpms/bwm-ng -- Bandwidth Monitor NG ( master f23 f22 epel7 el6 )
>> rpms/cal3d -- Skeletal based 3-D character animation library ( master
>> f23 f22 el6 el5 )
>> rpms/cdk -- Curses Development Kit ( epel7 el6 )
>> rpms/cego -- A relational and transactional database ( master f23 f22
>> epel7 el6 )
>> rpms/cfengine -- A systems administration tool for networks (
>> master f23 f22 )
>> rpms/cgnslib -- Computational Fluid Dynamics General Notation
>> System (
>> master f23 f22 epel7 el6 )
>> rpms/chinese-calendar -- A Chinese traditional calendar of
>> UbuntuKylin
>> ( master f23 f22 )
>> rpms/cln -- Class Library for Numbers ( master f23 f22 epel7 el6 )
>> rpms/ctemplate -- A simple but powerful template language for C++ (
>> master f23 f22 epel7 )
>> rpms/darkhttpd -- A secure, lightweight, fast, single-threaded
>> HTTP/1.1 server ( master f23 f22 epel7 el6 )
>> rpms/desktopcouch -- A CouchDB instance on every desktop ( master
>> f23 f22 )
>> rpms/diffuse -- Graphical tool for merging and comparing text
>> files ( epel7 )
>> rpms/dinotrace -- Waveform viewer for electronics ( master f23 f22 )
>> rpms/dissy -- Graphical frontend to the objdump disassembler (
>> master f23 f22 )
>> rpms/dmenu -- Generic menu for X ( master f23 f22 epel7 el6 )
>> rpms/docky -- Advanced dock application written in Mono ( master
>> f23 f22 )
>> rpms/dreampie -- A graphical cross-platform interactive Python
>> shell (
>> master f23 f22 )
>> rpms/dvdbackup -- Command line tool for ripping video DVDs ( master
>> f23 f22 epel7 el6 )
>> rpms/elektra -- A key/value pair database to store software
>> configurations ( master f23 f22 epel7 )
>> rpms/eqntott -- Generates truth tables from Boolean equations (
>> master
>> f23 f22 el6 )

Re: unannounced soname bump: libglpk

Note that Scientific and Astronomy Spins are also broken due to this
issue:
http://koji.fedoraproject.org/koji/tasks?method=livemedia=ausil=all=tree=-id

On 02/19/2016 07:33 PM, Björn Esser wrote:
> Am 19.02.2016 18:12 schrieb Andrew Lutomirski :
>> I believe this is the list of broken packages in rawhide.
>>
>> $ sudo dnf --disablerepo=\* --enablerepo=rawhide repoquery --whatrequires 
>> 'libglpk.so.36()(64bit)'
>> Fedora rawhide - x86_64 277 kB/s |  45 MB 02:46  
>>   
>> Last metadata expiration check performed 0:01:51 ago on Fri Feb 19 09:08:26 
>> 2016.
>> 4ti2-0:1.6.3-7.fc24.x86_64
>> 4ti2-libs-0:1.6.3-7.fc24.x86_64
>> R-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> cbmc-0:5.3-3.fc24.x86_64
>> coin-or-lemon-0:1.3.1-6.fc24.x86_64
>> coin-or-lemon-tools-0:1.3.1-6.fc24.x86_64
>> java-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> lua-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> mono-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> octave-6:4.0.0-10.fc24.x86_64
>> octave-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> openms-0:2.0.0-30.20160121git6f51b3.fc24.x86_64
>> ppl-utils-0:1.1-12.fc24.x86_64
>> python2-cvxopt-0:1.1.8-3.fc24.x86_64
>> python2-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> python3-cvxopt-0:1.1.8-3.fc24.x86_64
>> python3-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> ruby-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> sagemath-core-0:6.8-2.fc24.x86_64
>> shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>> shogun-cli-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>>
>> I'm rebuilding coin-or-lemon now.
> Shogun depends on Octave, which depends on glpk, and that FTBFS currently...
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26

2016-02-19 Thread Igor Gnatenko

 rpms/python-pygit2 -- Python 2.x bindings for libgit2 ( master f23 f22
epel7 )

whats wrong with this package? I think it is well-maintained by me.

On Fri, Feb 19, 2016 at 7:09 PM Josh Boyer 
wrote:

> Hello,
>
> In today's FESCo meeting, FESCo agreed to orphan all of Christoper
> Meng's packages on February 26, 2016 at 17:00 UTC if there was no
> further contact from Christopher.  Normally we would not necessarily
> pre-announce an oprhaning action, however the number of packages in
> question is quite large.  He is the point of contact for 230 packages.
>
> As a heads up to the greater community, the packages are listed below.
> In the event that we have to go through with the orphaning, please
> review them for packages you may wish to take over as the primary
> point of contact.  Should Christopher respond, we would still
> encourage actively seeking out co-maintainers for all of these
> packages.
>
> Thank you.
>
> josh
>
> rpms/2ping -- Bi-directional ping utility ( master f23 f22 epel7 el6 )
> rpms/CImg -- C++ Template Image Processing Toolkit ( master f23 f22 )
> rpms/NetPIPE -- Network Protocol Independent Performance Evaluator (
> master f23 f22 epel7 el6 )
> rpms/PyMca -- PyMca X-ray Fluorescence Toolkit ( master f23 f22 )
> rpms/PyOpenGL -- Python 2.x bindings for OpenGL ( master f23 f22 )
> rpms/RemoteBox -- Open Source VirtualBox Client with Remote Management
> ( master f23 f22 epel7 el6 )
> rpms/abakus -- The simple KDE calculator ( master f23 f22 )
> rpms/aime -- An application embeddable programming language
> interpreter ( master f23 f22 )
> rpms/ale -- Combines multiple inputs of the same scene ( f22 )
> rpms/alliance -- VLSI EDA System ( master f23 f22 )
> rpms/ansifilter -- ANSI terminal escape code converter ( master f23
> f22 epel7 el6 )
> rpms/ascii-design -- A tool to create ascii arts ( master f23 f22 epel7 )
> rpms/backintime -- Simple backup tool inspired from the Flyback
> project and TimeVault ( master f23 f22 epel7 )
> rpms/be -- Bugs Everywhere, a distributed bug tracker ( master f23 f22 el6
> )
> rpms/bitbake -- Build tool executing tasks and managing metadata (
> master f23 f22 )
> rpms/bleachbit -- Python utility to free disk space and improve
> privacy ( master f23 f22 epel7 el6 el5 )
> rpms/blktap -- Blktap Userspace Tools + Library ( master f23 f22 )
> rpms/bonesi -- The DDoS Botnet Simulator ( master f23 f22 )
> rpms/budgie -- Simple and distraction free GTK+3 media player ( master f23
> f22 )
> rpms/bunny -- Instrumented C code security fuzzer ( master f23 f22 )
> rpms/bwm-ng -- Bandwidth Monitor NG ( master f23 f22 epel7 el6 )
> rpms/cal3d -- Skeletal based 3-D character animation library ( master
> f23 f22 el6 el5 )
> rpms/cdk -- Curses Development Kit ( epel7 el6 )
> rpms/cego -- A relational and transactional database ( master f23 f22
> epel7 el6 )
> rpms/cfengine -- A systems administration tool for networks ( master f23
> f22 )
> rpms/cgnslib -- Computational Fluid Dynamics General Notation System (
> master f23 f22 epel7 el6 )
> rpms/chinese-calendar -- A Chinese traditional calendar of UbuntuKylin
> ( master f23 f22 )
> rpms/cln -- Class Library for Numbers ( master f23 f22 epel7 el6 )
> rpms/ctemplate -- A simple but powerful template language for C++ (
> master f23 f22 epel7 )
> rpms/darkhttpd -- A secure, lightweight, fast, single-threaded
> HTTP/1.1 server ( master f23 f22 epel7 el6 )
> rpms/desktopcouch -- A CouchDB instance on every desktop ( master f23 f22 )
> rpms/diffuse -- Graphical tool for merging and comparing text files (
> epel7 )
> rpms/dinotrace -- Waveform viewer for electronics ( master f23 f22 )
> rpms/dissy -- Graphical frontend to the objdump disassembler ( master f23
> f22 )
> rpms/dmenu -- Generic menu for X ( master f23 f22 epel7 el6 )
> rpms/docky -- Advanced dock application written in Mono ( master f23 f22 )
> rpms/dreampie -- A graphical cross-platform interactive Python shell (
> master f23 f22 )
> rpms/dvdbackup -- Command line tool for ripping video DVDs ( master
> f23 f22 epel7 el6 )
> rpms/elektra -- A key/value pair database to store software
> configurations ( master f23 f22 epel7 )
> rpms/eqntott -- Generates truth tables from Boolean equations ( master
> f23 f22 el6 )
> rpms/exaile -- Simple but powerful Amarok-style music player for GTK
> users ( master f23 f22 epel7 )
> rpms/fakechroot -- Gives a fake chroot environment ( master f23 f22 )
> rpms/fdm -- Simple, lightweight tool of fetching, filtering and
> delivering emails ( master f23 f22 )
> rpms/fife -- Cross platform game creation framework ( master f23 f22 )
> rpms/figtoipe -- FIG to IPE conversion tool ( master f23 f22 )
> rpms/firehol -- Simple and powerful firewall and traffic shaping
> languages ( master f23 f22 epel7 el6 )
> rpms/flickcurl -- C library for the Flickr API ( epel7 el6 )
> rpms/florence -- Extensible scalable on-screen virtual keyboard for
> GNOME ( master f23 f22 epel7 el6 )
> rpms/freefem++ -- PDE solving tool (

Re: unannounced soname bump: libglpk

2016-02-19 Thread Björn Esser


Am 19.02.2016 18:12 schrieb Andrew Lutomirski :
>
> I believe this is the list of broken packages in rawhide.
>
> $ sudo dnf --disablerepo=\* --enablerepo=rawhide repoquery --whatrequires 
> 'libglpk.so.36()(64bit)'
> Fedora rawhide - x86_64 277 kB/s |  45 MB 02:46   
>  
> Last metadata expiration check performed 0:01:51 ago on Fri Feb 19 09:08:26 
> 2016.
> 4ti2-0:1.6.3-7.fc24.x86_64
> 4ti2-libs-0:1.6.3-7.fc24.x86_64
> R-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> cbmc-0:5.3-3.fc24.x86_64
> coin-or-lemon-0:1.3.1-6.fc24.x86_64
> coin-or-lemon-tools-0:1.3.1-6.fc24.x86_64
> java-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> lua-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> mono-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> octave-6:4.0.0-10.fc24.x86_64
> octave-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> openms-0:2.0.0-30.20160121git6f51b3.fc24.x86_64
> ppl-utils-0:1.1-12.fc24.x86_64
> python2-cvxopt-0:1.1.8-3.fc24.x86_64
> python2-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> python3-cvxopt-0:1.1.8-3.fc24.x86_64
> python3-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> ruby-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> sagemath-core-0:6.8-2.fc24.x86_64
> shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
> shogun-cli-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
>
> I'm rebuilding coin-or-lemon now.

Shogun depends on Octave, which depends on glpk, and that FTBFS currently...
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Large number of packages to be orphaned on Feb 26