date:20160219

On 17.2.2016 18:43, Jakub Jelinek wrote:
> On Wed, Feb 17, 2016 at 05:30:27PM +, Daniel P. Berrange wrote:
>> Instead of using __attribute__((nonnull)) directly in the code, define a
>> macro for it. When compiling normal builds with gcc, make the macro
>> expand to nothing, but when compiling with coverity or other static analysis
>> tools make it expand normally.
> 
> Well, nonnull attribute is not primarily a debugging aid, but an
> optimization hint, which allows the compiler to optimize, sometimes
> significantly, the code that gives the compiler the additional information
> it can't figure itself otherwise.
> So while it could make sense to disable it in debug builds if you want
> your assertions to work, for production builds built without assertions
> it is really unnecessary pessimization of the code if you don't define it.
> 
>>  * still requiring correct gcc syntax when it is turned off.  See also
>>  * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 */
> 
> Funny you mention this PR, because the new warning is one of the
> warnings requested in that PR.  And now some people are complaining that the
> warning got implemented.

The thing is that some developers (e.g. me and ISC :-)) do not think that
assert() should be used only in debug builds.

E.g. BIND itself is written in "Design by contract" spirit and asserts are
used all over the place to make sure that code which does not behave as
intended is killed as soon as possible (and thus prevented from doing
collateral damage). Call it defensive programming if you wish.

In past 15 years, this allowed BIND 9 to avoid exploitable code execution bugs
[1] and turned most of them into mere DoS.

You can compare this with BIND 4 and BIND 8 which were famous for this kind of
the bugs (and didn't have asserts() all over the place). BTW libresolv in
today's glibc was taken from BIND 8 :-)

Quick grep shows 10497 asserts in BIND itself, so it is not realistic to say
'go and rewrite it from scratch', sorry. Apparently BIND is using
-fno-delete-null-pointer-checks from GCC 4.9 times.

Anyway, thank you for your input, I will find my way how to hack around it.

[1] http://www.cvedetails.com/product/144/ISC-Bind.html?vendor_id=64

-- 
Petr Spacek  @  Red Hat
--
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:56AM +0100, Hans de Goede wrote:
> Hi Jason,
> 
> On 18-02-16 08:33, Jason L Tibbitts III wrote:
> >Here are the recent changes to the packaging guidelines.
> >
> >-
> >
> >A section on the treatment of pregenerated code has been added to the
> >main guideline page.
> >
> >  
> > *https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_pregenerated_code
> >  *https://fedorahosted.org/fpc/ticket/580
> 
> I was specifically interested in this one, but this seems to be missing
> from the wiki page ?

It's very strange, because this link was missing for me too, but I
made it work by going to the "history" tab and selecting the current
revision.  Then go to "packaging" tab, and lo-and-behold the section
appears.

That was yesterday.

Today I visited the page, and again, the section is missing!  But
going through the process above makes it appear again.

So there's some very strange caching going on.  I'm not sure what,
because *clearing* my browser cache makes the section go away ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
--
devel mailing list
devel@lists.fedoraproject.org
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

Here's a video demonstrating this:

  http://oirase.annexia.org/tmp/packaging-caching/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

rawhide report: 20160219 changes

2016-02-19 Thread Fedora Rawhide Report

Compose started at Fri Feb 19 05:15:03 UTC 2016
Broken deps for i386
--
[3Depict]
3Depict-0.0.18-3.fc24.i686 requires libmgl.so.7.4.0
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libOpenMeshCore.so.3.2
[alliance]
alliance-5.0-40.20090901snap.fc22.i686 requires libXm.so.2
[bluetile]
bluetile-0.6-30.fc24.i686 requires 
ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13)
bluetile-0.6-30.fc24.i686 requires 
ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d)
[bustle]
bustle-0.4.8-6.fc24.i686 requires 
ghc(gtk-0.13.9-617097e8e58bbdfcb14229157446fd13)
bustle-0.4.8-6.fc24.i686 requires 
ghc(gio-0.13.1.0-be3d2018727671c3e3e37abf8b7e522d)
[castxml]
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangSerialization.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangSema.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangParse.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangLex.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangFrontend.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangEdit.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangDriver.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangBasic.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libclangAnalysis.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires libclangAST.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMXCoreInfo.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMXCoreDisassembler.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMXCoreDesc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMXCoreCodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMXCoreAsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86Info.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86Disassembler.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86Desc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86CodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86AsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMX86AsmParser.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZInfo.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZDisassembler.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZDesc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZCodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZAsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSystemZAsmParser.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSupport.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcInfo.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcDisassembler.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcDesc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcCodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcAsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMSparcAsmParser.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCInfo.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCDisassembler.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCDesc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCCodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCAsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMPowerPCAsmParser.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMOption.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMNVPTXInfo.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMNVPTXDesc.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMNVPTXCodeGen.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMNVPTXAsmPrinter.so.3.7
castxml-0.1-0.9.20160125gitfc71eb9.fc24.i686 requires 
libLLVMMipsInfo.so.3.7

Re: GCC 6 -Wnonnull is too aggressive

On 17.2.2016 19:20, Ralf Corsepius wrote:
> On 02/17/2016 06:51 PM, Jan Kratochvil wrote:
>> On Wed, 17 Feb 2016 18:25:29 +0100, Ralf Corsepius wrote:
>>> Remove -Werror.
>> [...]
>>> -Werror is useful to devs when actively working on code, but using it in
>>> released production code to be used in packages is plain st***.
>>
>> -Werror has found me many times bugs in Fedora add-on patches not being
> You are developing with upstream and are using Fedora a test bed.
> 
> This is unlike the situation many packages are in.
> For these, all -Werror does is to raise in most case negligible warnings to
> errors and to causes FTBFS for negligible reasons, such indentation, unused
> vars or other stylishness.
> 
> This shows especially in situations like now, when gcc received a major update
> starts to raise _warnings_ for a new set of issues, and -Werror enabled are
> going to FTBFS in masses.
> 
> In other words: WARNINGS are warnings and not errors for a reason.

In this case the warning which was turned into error saved us asses because
the code would behave differently under too aggressive optimizations.

It is not black-white question.

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

On 19.2.2016 08:50, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
>> Jakub Jelinek wrote:
>>> ASSERT(this) is pointless, it is testing if undefined behavior didn't
>>> happen after the fact, that is just too late.  As I said, use
>>> -fsanitize=undefined to make sure you don't call methods on nullptr.
>>
>> Doesn't -fno-delete-null-pointer-checks make such ASSERTs work (and also 
>> explicit "if (this)" type checks)? I read that that flag fixes programs 
>> which rely on "if (this)" checks.
> 
> That switch allows to work around buggy programs, at the cost of optimizing
> them less, yes.  In any case, such programs should be fixed, this must be
> always non-NULL, methods can't be called on NULL pointers.

Could you elaborate on this, please?

What is wrong with
if (ptr != NULL)
?

What standard says that it is wrong?

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Tom Hughes


On 19/02/16 12:04, Petr Spacek wrote:


Could you elaborate on this, please?

What is wrong with
 if (ptr != NULL)
?

What standard says that it is wrong?


That isn't what's wrong. What is wrong is the method call that got you 
there. You have a method like this:


void foo()
{
  if (this != NULL) ...
}

and then you invoke it with a null pointer:

xxx->foo();

and it is that call that is not allowed by the standard when xxx is null.

So the compiler is allowed to assume that this will never be null in a 
method, because calling a method on a null pointer is not allowed, so it 
can just remove your null test in the method.


Then when you do call it on a null pointer you crash because the method 
is not doing the null test and just tries to access members of the object.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Marek Polacek

On Fri, Feb 19, 2016 at 01:04:04PM +0100, Petr Spacek wrote:
> On 19.2.2016 08:50, Jakub Jelinek wrote:
> > On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
> >> Jakub Jelinek wrote:
> >>> ASSERT(this) is pointless, it is testing if undefined behavior didn't
> >>> happen after the fact, that is just too late.  As I said, use
> >>> -fsanitize=undefined to make sure you don't call methods on nullptr.
> >>
> >> Doesn't -fno-delete-null-pointer-checks make such ASSERTs work (and also 
> >> explicit "if (this)" type checks)? I read that that flag fixes programs 
> >> which rely on "if (this)" checks.
> > 
> > That switch allows to work around buggy programs, at the cost of optimizing
> > them less, yes.  In any case, such programs should be fixed, this must be
> > always non-NULL, methods can't be called on NULL pointers.
> 
> Could you elaborate on this, please?
> 
> What is wrong with
> if (ptr != NULL)
> ?
> 
> What standard says that it is wrong?

It's about checking whether "this", in C++, is NULL.  Since any call on a null
pointer is undefined behavior, any code relying on such checks is non-standard.

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

Re: GCC 6 -Wnonnull is too aggressive


On 02/19/2016 12:16 PM, Petr Spacek wrote:


It is not black-white question.


Absolutely.

But I say, there should not be any room for -Werror in production 
SW/packages.


The fact,
* different version of gcc raise different warnings
* gcc on different architectures raise different warnings.
* gcc raises warnings on coding styles.
makes -Werror non-suiteable for long-term maintainance.


Worse, this causing non-experienced packagers to take action on 
non-issues and potentially introduce bugs.



Most absurd piece of a spec I saw in Fedora spec recently, was this:
...
export CFLAGS="$RPM_OPT_FLAGS -Wall -Werror -Wno-unused-function 
-Wno-unused-variable -Wno-unused-but-set-variable -Wno-array-bounds 
-fno-strict-aliasing -Wno-logical-not-parentheses 
-Wno-error=misleading-indentation"


%configure
...


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

Re: GCC 6 -Wnonnull is too aggressive

On 19/02/16 08:50 +0100, Jakub Jelinek wrote:

On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:

Jakub Jelinek wrote:
> ASSERT(this) is pointless, it is testing if undefined behavior didn't
> happen after the fact, that is just too late.  As I said, use
> -fsanitize=undefined to make sure you don't call methods on nullptr.

Doesn't -fno-delete-null-pointer-checks make such ASSERTs work (and also
explicit "if (this)" type checks)? I read that that flag fixes programs
which rely on "if (this)" checks.

That switch allows to work around buggy programs, at the cost of optimizing
them less, yes.  In any case, such programs should be fixed, this must be
always non-NULL, methods can't be called on NULL pointers.

Right, using -fno-delete-null-pointer-checks doesn't "fix" the
programs, they still have undefined behaviour.

Checking "if (this)" is completely brain-damaged. If you want to ask
questions like "do I exist?" then practise philosophy not C++.

The other common problem uncovered by the new optimization is in code
like:

   foo()->bar();

where foo() happens to return a null pointer. If bar() doesn't access
any members of *this then previously this compiled and ran without
error. This code isn't brain-damaged, it's just got a bug, and should
have checked for null if that is a possible result of foo() e.g.

   if (auto p = foo())
 p->bar();
   else
 /* do something appropriate */;

Using -fno-delete-null-pointer-checks will make the code appear to
work correctly again, but obviously it's still wrong if foo() can
return a null pointer. And if bar() was ever changed to access a
member of *this then it would start crashing, even with
-fno-delete-null-pointer-checks.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive


On 19/02/16 10:49 +0100, Petr Spacek wrote:

The thing is that some developers (e.g. me and ISC :-)) do not think that
assert() should be used only in debug builds.

E.g. BIND itself is written in "Design by contract" spirit and asserts are
used all over the place to make sure that code which does not behave as
intended is killed as soon as possible (and thus prevented from doing
collateral damage). Call it defensive programming if you wish.


That's fine. Don't use attribute((nonnull)) then.

It's illogical to promise the compiler that something will never,
ever, ever be null, but also check whether it's null. If you're not
100% certain it can't be null, then you lied to the compiler. If you
are 100% certain it can't be null then the assert is redundant and can
be removed.

If you're only 99.999% certain, and so the assert serves a useful
purpose, then don't make promises that you can't keep.

If you just want to advise the compiler that something *probably*
won't be null, and tell it to optimize based on that assumption, then
you can use __builtin_expect() to provide that hint (although I
wouldn't actually recommend doing so).

Don't make a promise when you mean to give a hint.

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

Re: GCC 6 -Wnonnull is too aggressive

On 19.2.2016 13:08, Marek Polacek wrote:
> On Fri, Feb 19, 2016 at 01:04:04PM +0100, Petr Spacek wrote:
>> On 19.2.2016 08:50, Jakub Jelinek wrote:
>>> On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
 Jakub Jelinek wrote:
> ASSERT(this) is pointless, it is testing if undefined behavior didn't
> happen after the fact, that is just too late.  As I said, use
> -fsanitize=undefined to make sure you don't call methods on nullptr.

 Doesn't -fno-delete-null-pointer-checks make such ASSERTs work (and also 
 explicit "if (this)" type checks)? I read that that flag fixes programs 
 which rely on "if (this)" checks.
>>>
>>> That switch allows to work around buggy programs, at the cost of optimizing
>>> them less, yes.  In any case, such programs should be fixed, this must be
>>> always non-NULL, methods can't be called on NULL pointers.
>>
>> Could you elaborate on this, please?
>>
>> What is wrong with
>> if (ptr != NULL)
>> ?
>>
>> What standard says that it is wrong?
> 
> It's about checking whether "this", in C++, is NULL.  Since any call on a null
> pointer is undefined behavior, any code relying on such checks is 
> non-standard.

Ah, okay. I was talking about pure C all the time, so I got confused :-)

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Jakub Jelinek

On Fri, Feb 19, 2016 at 01:44:45PM +0100, Petr Spacek wrote:
> > It's about checking whether "this", in C++, is NULL.  Since any call on a 
> > null
> > pointer is undefined behavior, any code relying on such checks is 
> > non-standard.
> 
> Ah, okay. I was talking about pure C all the time, so I got confused :-)

It is not really different for C, just that "this" is in C++ implicitly
nonnull.  Otherwise, if you use a nonnull attribute, you make the same
promise, this function will never be called with NULL as some particular
pointer argument (or all pointer arguments).  So, the undefined behavior
happens if you violate that and call a function with an invalid argument.

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

Re: GCC 6 -Wnonnull is too aggressive

On 19.2.2016 13:30, Jonathan Wakely wrote:
> On 19/02/16 10:49 +0100, Petr Spacek wrote:
>> The thing is that some developers (e.g. me and ISC :-)) do not think that
>> assert() should be used only in debug builds.
>>
>> E.g. BIND itself is written in "Design by contract" spirit and asserts are
>> used all over the place to make sure that code which does not behave as
>> intended is killed as soon as possible (and thus prevented from doing
>> collateral damage). Call it defensive programming if you wish.
> 
> That's fine. Don't use attribute((nonnull)) then.
> 
> It's illogical to promise the compiler that something will never,
> ever, ever be null, but also check whether it's null. If you're not
> 100% certain it can't be null, then you lied to the compiler. If you
> are 100% certain it can't be null then the assert is redundant and can
> be removed.
> 
> If you're only 99.999% certain, and so the assert serves a useful
> purpose, then don't make promises that you can't keep.
> 
> If you just want to advise the compiler that something *probably*
> won't be null, and tell it to optimize based on that assumption, then
> you can use __builtin_expect() to provide that hint (although I
> wouldn't actually recommend doing so).
> 
> Don't make a promise when you mean to give a hint.

This is nice in a theory but not in practice. You can give promises about
state of your program you wish, but these promises can 100 % hold only for
bug-free programs using bug-free libraries.

Everything else is going to face real world where various bugs cause that
various 'promises' will not hold.

As I said above in the original question, the (nonnull) attribute is used to
help static analyzers, not as optimization hint.
#if defined (__GNUC__) and -fno-delete-null-pointer-checks
will workaround it for me.

Thank you for your input, guys.

-- 
Petr Spacek  @  Red Hat
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Jan Kratochvil

On Fri, 19 Feb 2016 13:07:53 +0100, Ralf Corsepius wrote:
> But I say, there should not be any room for -Werror in production
> SW/packages.
> 
> The fact,
> * different version of gcc raise different warnings
> * gcc on different architectures raise different warnings.
> * gcc raises warnings on coding styles.
> makes -Werror non-suiteable for long-term maintainance.

You miss here false warnings (errors) are much less costly than a missed
warning (errors).  If upstream package is free of warnings thanks to -Werror
then a Fedora packaging should not introduce so many warnings they would not
be manageable by its Fedora maintainer.

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

Schedule for Friday's FESCo Meeting (2016-02-19)

Following is the list of topics that will be discussed in the FESCo
meeting Friday at 17:00UTC in #fedora-meeting on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2016-02-19 17:00 UTC'


Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1541 F24 System Wide Change: LiveUSBCreator as Primary Downloadable
.fesco 1541
https://fedorahosted.org/fesco/ticket/1541

= New business =

#topic #1478 F24 Self Contained Changes
.fesco 1478
https://fedorahosted.org/fesco/ticket/1478

#topic #1542 backintime - nonresponsive maintainer
.fesco 1542
https://fedorahosted.org/fesco/ticket/1542

#topic #1517 Can coprs depend on third part repositories to be usable at runtime
.fesco 1517
https://fedorahosted.org/fesco/ticket/1517

= Open Floor =

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Florian Weimer

On 02/19/2016 01:07 PM, Ralf Corsepius wrote:
> On 02/19/2016 12:16 PM, Petr Spacek wrote:
> 
>> It is not black-white question.
> 
> Absolutely.
> 
> But I say, there should not be any room for -Werror in production
> SW/packages.

I agree that blanket -Werror is questionable, especially with -Wall,
which includes warnings dependent on optimization.

But using -Werror selectively makes a lot of sense.  For example, for C
code, you could use -Werror=implicit-function-declaration
-Werror=implicit-int.

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

Re: Fedora Rawhide 20160218 compose check report

2016-02-19 Thread Jared K. Smith

On Thu, Feb 18, 2016 at 9:18 PM, Kevin Kofler 
wrote:

> Yet another completely avoidable fatal error caused by SELinux. How many
> such show stoppers will it take until people finally realize that enabling
> SELinux by default was a horrible idea?
>

Not to put too fine a point on it, but I see SELinux like a seat-belt in a
car.  Yes, you can point out some cases where someone would have been safer
*not* wearing a seat-belt, or would have been less inconvenienced.  But the
benefits vastly outweigh the inconvenience.  So yes, SELinux does cause the
occasional problem in development -- but I'd much rather have slightly more
complicated development if it means a safer experience for Fedora users.

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

Orphan of ocsinventory and some perl dependencies

2016-02-19 Thread Remi Collet

I just orphan some package I don't use anymore and don't want to
maintain anymore:

libx86 (EPEL)
monitor-edid (Mandriva tool, seems dead)
ocsinventory
ocsinventory-agent

perl-AnyEvent-HTTP
perl-Apache-DBI
perl-Apache2-SOAP
perl-Net-CUPS (EPEL)
perl-Net-NBName
perl-Net-SSLGlue
perl-Proc-Daemon
perl-XML-Entities


Feel free to take the ones which have interest for you.


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

Re: Orphan of ocsinventory and some perl dependencies

2016-02-19 Thread Marianne Lombard

I will take perl package need by fusioninventory-agent
I will be glad to have a co-maintener

Cheers

Marianne

Le 19/02/2016 16:20, Remi Collet a écrit :
> I just orphan some package I don't use anymore and don't want to
> maintain anymore:
> 
> libx86 (EPEL)
> monitor-edid (Mandriva tool, seems dead)
> ocsinventory
> ocsinventory-agent
> 
> perl-AnyEvent-HTTP
> perl-Apache-DBI
> perl-Apache2-SOAP
> perl-Net-CUPS (EPEL)
> perl-Net-NBName
> perl-Net-SSLGlue
> perl-Proc-Daemon
> perl-XML-Entities
> 
> 
> Feel free to take the ones which have interest for you.
> 
> 
> Remi.
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> 

-- 
Marianne (Jehane) Lombard
Geekfeminist and sysadmin
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

remi changed remi's 'commit' permission on perl-Net-NBName (epel7) to 'Obsolete'

2016-02-19 Thread notifications

remi changed remi's 'commit' permission on perl-Net-NBName (epel7) to 'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-NBName/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

remi changed owner of perl-Net-NBName (epel7) to 'orphan'

2016-02-19 Thread notifications

remi changed owner of perl-Net-NBName (epel7) to 'orphan'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-NBName/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

remi changed remi's 'approveacls' permission on perl-Net-NBName (epel7) to 'Obsolete'

2016-02-19 Thread notifications

remi changed remi's 'approveacls' permission on perl-Net-NBName (epel7) to 
'Obsolete'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-NBName/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/perl-de...@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

2016-02-19 Thread Kevin Fenzi

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?

Thanks, 

kevin

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

Re: Orphan of ocsinventory and some perl dependencies

2016-02-19 Thread Emmanuel Seyman

* Remi Collet [19/02/2016 16:20] :
>
> perl-AnyEvent-HTTP
> perl-Apache-DBI
> perl-Apache2-SOAP
> perl-Net-CUPS (EPEL)
> perl-Net-NBName
> perl-Net-SSLGlue
> perl-Proc-Daemon
> perl-XML-Entities

I've taken all of these on their Fedora branches.
Co-maintainers (and EPEL maintainers) are welcome.

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

Re: 4.4 rebase coming to F23 soon

2016-02-19 Thread Sérgio Basto

Kernel 4.4, which was announce as long term support (LTS)  

https://www.linux.com/news/software/applications/878214-44-linux-kernel
-long-term-support-release-is-now-available

On Sex, 2016-02-19 at 01:41 -0500, Eric Griffith wrote:
> The kernel, presumably. I was confused as well, but if you look at
> the sent line, you'll see that this got sent to -devel and -kernel.
> On Feb 19, 2016 01:40, "Garrett Holmstrom" 
> wrote:
> > On 2016-02-18 17:51, Laura Abbott wrote:
> > >  4.4.2 is currently building and should be in updates-testing
> > > soon. As
> > > usual, please test and give karma appropriately (negative karma
> > > for
> > > new issues, not existing issues).
> > > 
> > Forgive my ignorance, but version 4.4.2 of _what_?
> > 
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraprojec
> > t.org
> > 
-- 
Sérgio M. B.

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

Re: 4.4 rebase coming to F23 soon

On Fri, Feb 19, 2016 at 11:45 AM, Sérgio Basto  wrote:
> Kernel 4.4, which was announce as long term support (LTS)
>
> https://www.linux.com/news/software/applications/878214-44-linux-kernel
> -long-term-support-release-is-now-available

That's correct from an upstream perspective, but it has little impact
to Fedora's use of 4.4.y at this time.

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

unannounced soname bump: libglpk

2016-02-19 Thread 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.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2016-02-19)

===
#fedora-meeting: FESCO (2016-02-19)
===


Meeting started by jwboyer at 17:00:17 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2016-02-19/fesco.2016-02-19-17.00.log.html
.



Meeting summary
---
* init process  (jwboyer, 17:00:20)

* #1541 F24 System Wide Change: LiveUSBCreator as Primary Downloadable
  (jwboyer, 17:02:33)
  * LINK: https://fedorahosted.org/fesco/ticket/1541   (jwboyer,
17:02:38)
  * AGREED: LiveUSBCreator as Primary Downloadable is accepted for F24
(+5, -0, 1)  (jwboyer, 17:19:20)
  * Change owners need to follow up with rel-eng on signing and hosting
requriements  (jwboyer, 17:19:38)

* #1478 F24 Self Contained Changes  (jwboyer, 17:19:50)
  * LINK: https://fedorahosted.org/fesco/ticket/1478   (jwboyer,
17:19:51)
  * AGREED: System Python is approved (+5, -1, 1)  (jwboyer, 17:25:19)
  * AGREED: Drop php-pear dependency for pecl modules is approved (+8,
-0, 0)  (jwboyer, 17:25:48)

* #1542 backintime - nonresponsive maintainer  (jwboyer, 17:26:15)
  * LINK: https://fedorahosted.org/fesco/ticket/1542   (jwboyer,
17:26:16)
  * AGREED: Orphan backintime immediately and orphan the remainder of
cicku's packages in one week's time if there is no further contact
(+8, 0, 0)  (jwboyer, 17:31:07)
  * nirik to orphan backintime  (jwboyer, 17:32:04)
  * jwb to email devel list about the remainder of the packages
(jwboyer, 17:32:13)

* #1517 Can coprs depend on third part repositories to be usable at
  runtime  (jwboyer, 17:32:30)
  * LINK: https://fedorahosted.org/fesco/ticket/1517   (jwboyer,
17:32:35)
  * AGREED: package build in copr must be functional with requirements
complying w/ Fedora licensing policies. Dependencies using
third-party repositories are ok if they are non-essential at runtime
(e.g Recommends/Suggest) (+8, -0, 0)  (jwboyer, 17:38:30)

* next week's chair  (jwboyer, 17:38:52)
  * dgilmore to chair next week's meeting  (jwboyer, 17:39:09)

* Open Floor  (jwboyer, 17:39:15)
  * the pungi change is close to completion, next week we will be
seeking feedback on teh composes as we prepare to switch rawhide
over  (dgilmore, 17:42:29)

Meeting ended at 17:52:21 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* jwboyer (94)
* dgilmore (48)
* number80 (39)
* nirik (32)
* kalev (22)
* zodbot (19)
* jsmith (18)
* maxamillion (18)
* paragan (8)
* mhroncok (7)
* pviktori (1)
* sgallagh (0)
* jwb (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Large number of packages to be orphaned on Feb 26

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 ( master f23 f22 el6 )
rpms/freetalk -- A console based Jabber client ( master f23 f22 )
rpms/gausssum -- A GUI application for analysis of output of quantum
computations ( master f23 f22 )
rpms/gcin -- An input method focused on Chinese users ( master f23 f22
epel7 el6 el5 )
rpms/gdpc -- A program for visualising molecular dynamics simulations
data ( master f23 f22 )
rpms/gentoo -- Graphical file management progr

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

On 02/19/2016 07: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/i3 -- Improved tiling window manager ( master f23 f22 epel7 )
> rpms/i3-ipc -- Inter-process communication with i3 ( master f23 f22 )
> rpms/i3lock -- Simple X display locker like slock ( master f23 f22 epel7 el6 )
> rpms/i3status -- Status bar generator for i3bar, dzen2, xmobar or
> similar programs ( master f23 f22 epel7 el6 )
>

I'll take the i3-related packages in case of no response as I'm already
comaintaining them.

Greetings,
Christian
--
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 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

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 ( master f23 f22 el6 )
> rpms/fr

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&owner=ausil&state=all&view=tree&order=-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

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 )
>> rpms/exaile -- Simple

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

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 -- Simple, lightweight tool of fet

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

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&bug_status=ASSIGNED&component=Package%20Review&email1=i%40cicku.me&emailreporter1=1&emailtype1=substring&list_id=4654252&product=Fedora&query_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

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&bug_status=ASSIGNED&component=Package%20Review&email1=i%40cicku.me&emailreporter1=1&emailtype1=substring&list_id=4654252&product=Fedora&query_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: 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 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

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

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&bug_status=ASSIGNED&classification=Fedora&component=LiveCD&component=LiveCD%20-%20FEL&component=LiveCD%20-%20Games&component=LiveCD%20-%20KDE&component=LiveCD%20-%20LXDE&component=LiveCD%20-%20Xfce&list_id=4654195&product=Fedora&query_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 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

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

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

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

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

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: 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: [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 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: 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: 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: 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: 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: 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&bug_status=ASSIGNED&classification=Fedora&component=LiveCD&component=LiveCD%20-%20FEL&component=LiveCD%20-%20Games&component=LiveCD%20-%20KDE&component=LiveCD%20-%20LXDE&component=LiveCD%20-%20Xfce&list_id=4654195&product=Fedora&query_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

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

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: 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 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: 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: [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: 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&bug_status=ASSIGNED&classification=Fedora&component=LiveCD&component=LiveCD%20-%20FEL&component=LiveCD%20-%20Games&component=LiveCD%20-%20KDE&component=LiveCD%20-%20LXDE&component=LiveCD%20-%20Xfce&list_id=4654195&product=Fedora&query_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: 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: 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

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

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

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

Re: Help with g++ 6 abs() and templates


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::value, T>::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: [ANNOUNCE] Fedora support for Vulkan

2016-02-19 Thread David Airlie



- Original Message -
> From: "Kevin Kofler" 
> To: devel@lists.fedoraproject.org
> Sent: Saturday, 20 February, 2016 12:14:00 PM
> Subject: 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.
> 

Not necessarily. Until someone writes one, there are no plans to have one.

We have GL, I doubt we'll be writing compositors in Vulkan anytime soon,

fallbacks would probably be to use GL.

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


On 02/19/2016 07: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.


Unless somebody else wants them, I could take these 2:

rpms/alliance -- VLSI EDA System ( master f23 f22 )
rpms/freefem++ -- PDE solving tool ( master f23 f22 el6 )


I also could take some of the perl packages, esp. should there be some 
on rt's dep-chain (I haven't checked, yet).


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

Access denied [Was: Large number of packages to be orphaned on Feb 26]


On 02/20/2016 05:01 AM, Ralf Corsepius wrote:


rpms/freefem++ -- PDE solving tool ( master f23 f22 el6 )


I am trying to push an update for freefem++, using my provenpackager 
privileges, but I am denied access:


--
$ git push
Enter passphrase for key 'XX':
WARNING: 'freefem++' is an alias for 'rpms/freefem++'
FATAL: W any freefem++ corsepiu DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
--

What is going here?


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

Re: Access denied [Was: Large number of packages to be orphaned on Feb 26]

2016-02-19 Thread Pierre-Yves Chibon

On Sat, Feb 20, 2016 at 06:26:42AM +0100, Ralf Corsepius wrote:
> On 02/20/2016 05:01 AM, Ralf Corsepius wrote:
> 
> >>rpms/freefem++ -- PDE solving tool ( master f23 f22 el6 )
> 
> I am trying to push an update for freefem++, using my provenpackager
> privileges, but I am denied access:
> 
> --
> $ git push
> Enter passphrase for key 'XX':
> WARNING: 'freefem++' is an alias for 'rpms/freefem++'
> FATAL: W any freefem++ corsepiu DENIED by fallthru
> (or you mis-spelled the reponame)
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
> --
> 
> What is going here?

There is a bug, we've been investigating but haven't fix yet.
For the moment, you can just clone with:
fedpkg clone rpms/freefem++

And working from this clone should work fine.


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

Re: Access denied [Was: Large number of packages to be orphaned on Feb 26]