Hi folks,
I am glad to announce, Fedora Developer Portal has official
mailing list.
developer-por...@lists.fedoraproject.org
If you want to discuss anything about the portal, feel free to send us
any feedback,
suggestions, etc. Or even file a n issue on GitHub.
In the most time you can reach
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
> "HdG" == Hans de Goede writes:
HdG> I was specifically interested in this one, but this seems to be
HdG> missing from the wiki page ?
That URL certainly works for me. Here's the text:
Use of pregenerated code
Often a package will contain code which was itself generated by other
code. Th
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
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
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 prog
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
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
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 ma
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 !=
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
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.
* g
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
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
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
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
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
>>
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 c
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 c
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 -Wal
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 S
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
per
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 d
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://list
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/adm
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:
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
hopefu
* 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.
E
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
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 littl
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
===
#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
--
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 lar
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, ho
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
>
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
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
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 binding
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
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-m
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
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.
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, a
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
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
-
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 calle
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
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 instan
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 (apar
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
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
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
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'
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 int
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 Rawhi
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 forwa
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
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
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 memcac
* 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.fedor
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 i
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
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
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 e
+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 b
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 gnul
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 th
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
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
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 th
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
s
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 execut
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 P
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.
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.
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://
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
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
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 cod
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 provide
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'
- 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 render
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
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 al
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:
>
> -
On 02/20/2016 08:44 AM, Pierre-Yves Chibon wrote:
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
privi
86 matches
Mail list logo
