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
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 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
- 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 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'
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
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
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
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
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://
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.
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.
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
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
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
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
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 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
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
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
+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
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
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 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 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
* 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 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
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
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
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
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
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
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'
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
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
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 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
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?
From my point of view, the whole concept of "EOL" is: if you use this
version you acknowledge
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
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
-
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
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
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.
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
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'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
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
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
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
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
>
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
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
===
#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
--
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
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
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
* 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
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 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:
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
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
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
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
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 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
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, 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: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 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/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 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 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 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 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 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
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
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
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
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
> "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
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
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
86 matches
Mail list logo
