Re: Fwd: Use suid_dumpable=2 for development releases

[Jakub Filak]

It looks like that there are no opponents of this change but several 
supporters

and few of them even want to have suid_dumpable=2 in all releases.

I was thinking about it and Richard W.M. Jones' email about safeness of
suid_dumpable=2 without ABRT gave me an idea to teach ABRT to set
suid_dumpable=2 in abrt-ccpp.service. The service sets kernel.core_pattern
(/proc/sys/kernel/core_pattern) to ABRT pattern, so it could also update
suid_dumpable. If an administrator uninstalls/turns off ABRT, suid_dumpable
would get back the OS default value. If he/she modifies core_pattern by 
hand,

then he/she is skilled enough to spot kernel warning in the logs.

What do you think about it?
I would especially like to hear thoughts on this from security experts.

Do I need to get any permission to do so?


Regards,
Jakub

On 02/12/2016 01:24 PM, Jakub Filak wrote:

- Forwarded Message -
From: "Jakub Filak" 
To: secur...@lists.fedoraproject.org
Sent: Thursday, February 11, 2016 9:51:04 AM
Subject: Use suid_dumpable=2 for development releases

Hello,

As a maintainer of ABRT, I have been asked several times why ABRT does not catch
crashes of many processes and one kind of reasons dominate among other reasons
- processes that executes set-user-ID programs (man 5 core). These processes
are not dumped at all if the value of /proc/sys/fs/suid_dumpable is 0 (man 5
proc) which is the default value.  With the default suid_dumpable
value, crashes caused by SIGABRT are not detectable because kernel doesn't even
write a log message about that.

The default value 0 is there for good security reason, but I would like to
propose changing the default value to 2 for development Fedora releases (Alpha,
Beta, Rawhide). In this case, kernel would send core dump to ABRT (or
systemd-coredump) and the ABRT record would be accessible only to root.

I believe that maintainers of packages like chrony will be really delighted
with this change, while will not weaken security of Fedora for regular users.


Regards,
Jakub
--
security mailing list
secur...@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/secur...@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: GCC6: failure with -isystem /usr/include

[Orcan Ogetbil]

On 2 February 2016 at 07:54, Jakub Jelinek wrote:
>
> That said, why does it bother to do such a mess?  Does it think the g++
> driver is not able to do that itself?
>

I am not sure why qmake-qt5 doesn't want to trust gcc for the system
include dirs, but well.. it doesn't.
I reduced the problem down to this. Consider the following program:

#include 
int main(){}

This compiles fine with both gcc5 and 6 with
g++ -c inctest.cpp -o inctest.o

On the other hand, it compiles fine with gcc5, but fails with gcc6 if
the compiler is invoked liked this:
g++ -c -isystem /usr/include inctest.cpp -o inctest.o

The failure message is
/usr/include/c++/6.0.0/cstdlib:75:25: fatal error: stdlib.h: No such
file or directory

I am not sure what is the expected behavior. Maybe people familiar
with gcc can shed some light.

I noticed the difference: In cstdlib, the gcc5 line 75
#include 
became in gcc6:
#include_next 

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

GCC 6 and polymake

[Jerry James]

Would one of you C++ experts help me out with a polymake build failure with
gcc 6?  Polymake defines a Vector class in lib/core/include/Vector.h (also
see lib/core/include/GenericVector.h).  Unlike with gcc 5 and earlier,
everywhere in the code that something like this is done:

Vector x = ...;
Vector y = ..;
const Vector z = x + y;

where + can be one of several operators defined for the Vector class, gcc
errors like this:

error: invalid initialization of non-const reference of type
'pm::Vector&' from an rvalue of type 'pm::Vector'

I assume the error refers to the temporary created by the operator.  I've
added -std=gnu++98 to CXXFLAGS, but that doesn't help.  I guess that the
Vector class is missing something needed by gcc 6, but I don't know what
that something might be.  Any hints are much appreciated.

See http://koji.fedoraproject.org/koji/taskinfo?taskID=12969245 for an
example build showing the error.

Thank you,
-- 
Jerry James
http://www.jamezone.org/
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Michael Schwendt]

On Mon, 15 Feb 2016 16:46:32 +0100, Dan Horák wrote:

> you are welcome, there will be more packages suffering from the same
> problem (I own at least one :-)), sometimes appending "-fsigned-char"
> to CFLAGS will be easier.

A couple of narrowing-conversion problems had turned up in Oct 2015
already, so this is nothing new to GCC 6.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fedora Rawhide 20160215 compose check report

[Adam Williamson]

On Mon, 2016-02-15 at 19:58 +, Fedora compose checker wrote:
> Missing expected images:
> 
> Kde disk raw armhfp
> Cloud disk raw i386
> Kde live i386
> Minimal disk raw armhfp
> Kde live x86_64

KDE seems to have dependency issues. I'm not sure what's going on with
the cloud images.

> Images in this compose but not Rawhide 20160214:
> 
> Cloud disk qcow x86_64
> Cloud disk raw x86_64
> Cloud_atomic vagrant virtualbox x86_64
> Cloud_atomic vagrant libvirt x86_64
> 
> No images in Rawhide 20160214 but not this.
> 
> Failed openQA tests: 26 of 63

Most of the failures seem to be a repo problem - several install tests
and one upgrade test failed with:

"Failed to synchronize cache for repo 'rawhide' from 'https://mirrors.f
edoraproject.org/metalink?repo=rawhide&arch=x86_64': Cannot download
repomd.xml: Cannot download repodata/repomd.xml: All mirrors were
tried"

from dnf. It also looks like we need to re-take the 'clean GNOME
desktop' needle for latest Cantarell changes, and the Workstation live
hasn't been booting properly in openQA for the last few days, I'll look
into that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: GCC 6 Binaries segfaulting

[Richard Shaw]

On Mon, Feb 15, 2016 at 12:48 PM, Florian Weimer  wrote:

> On 02/15/2016 07:44 PM, Richard Shaw wrote:
> > I have one package where several of the binaries used for unit testing
> are
> > segfaulting.
> >
> > I'm guessing that's not likely a direct GCC 6 issue but some googling
> leads
> > me to believe that it could be an ABI breakage with a dependency that has
> > not been rebuilt.
> >
> > Is that the most likely cause?
>
> It's impossible to tell with the information you gave us.
>

Here's the BZ:

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



> It could also be this bug:
>
>   
>

I tried adding the workaround mentioned but it didn't seem to help.

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

Re: Please stop modifying other people's packages without coordinating with them first

[Igor Gnatenko]

Here I totally agree with Till and usually I'm doing the same (it doesn't
happen often, but anyway).

Because I also not available day to day. For example today I have time and
next time I will have time like month..

Just wanted to share my opinion.

On Mon, Feb 15, 2016, 7:23 PM Josh Boyer  wrote:

> On Mon, Feb 15, 2016 at 12:20 PM, Till Maas  wrote:
> > On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:
> >
> >> You misunderstand.  I was not suggesting you ask for permission.  I
> >> was stating that IRC contact alone, for whatever reason, is not
> >> necessarily sufficient as an attempt to contact a maintainer.  You can
> >> convey _much_ more information in an email, to the point of telling
> >> them exactly what you are committing and why.  It is so much better
> >> than a simple ping or brief sentence or two in IRC.
> >
> > I agree, that it is possible to be more informative via e-mail. However
> > at the time I reached out via IRC, I did not yet know all the details. I
> > only knew the build error from the previous build logs and a related
> > commit message in upstream git. Therefore an e-mail would be pretty
> > useless at this point, unless I stop working then. Otherwise there would
> > be several status report e-mails about my slowed-down progress. If I was
> > the targeted maintainer, I would be annoyed by this - we are not talking
> > about changes that might require an epoch bump here and therefore are
> > easily reverted.
> >
> >> As for waiting for a response, yes I think it is fine to wait a day.
> >
> > Not sure how it works for other volunteer maintainers, but this does not
> > fit with my time slots that I might have available. So waiting a day
> > might also mean wait till the next weekend, when I have time for this
> > again.
> >
> >> Timezones alone may mean that the duplicate work you wished to avoid
> >> was already queued on the maintainer's side and he was just waiting to
> >> finish testing before pushing.  Who knows.  Urgency in fixing packages
> >> is certainly appreciated, but this is not a critical package and it
> >> had already been broken for a week.
> >
> > To be honest, a one week old commit to dist-git that does not build due
> > to upstream bugs does not suggest to me that the maintainer has an extra
> > secret stash of changes that are just waiting of a lot of extra testing.
> > If the commit happened recently, it might be different.
>
> You and I are going to disagree on this issue and the finer points
> within it.  That is fine.  We will simply have to agree to disagree
> because spending further time with back and forth isn't going to be
> productive.
>
> Thank you for the very civil discourse.
>
> josh
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
-- 

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

Fedora Rawhide 20160215 compose check report

[Fedora compose checker]

Missing expected images:

Kde disk raw armhfp
Cloud disk raw i386
Kde live i386
Minimal disk raw armhfp
Kde live x86_64

Images in this compose but not Rawhide 20160214:

Cloud disk qcow x86_64
Cloud disk raw x86_64
Cloud_atomic vagrant virtualbox x86_64
Cloud_atomic vagrant libvirt x86_64

No images in Rawhide 20160214 but not this.

Failed openQA tests: 26 of 63

ID: 5380Test: x86_64 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/5380
ID: 5385Test: i386 workstation_live default_install
URL: https://openqa.fedoraproject.org/tests/5385
ID: 5381Test: x86_64 workstation_live default_install@uefi
URL: https://openqa.fedoraproject.org/tests/5381
ID: 5327Test: x86_64 universal server_delete_pata
URL: https://openqa.fedoraproject.org/tests/5327
ID: 5379Test: i386 generic_boot default_install
URL: https://openqa.fedoraproject.org/tests/5379
ID: 5326Test: x86_64 universal server_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/5326
ID: 5325Test: x86_64 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/5325
ID: 5368Test: i386 universal server_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/5368
ID: 5369Test: i386 universal server_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/5369
ID: 5370Test: i386 universal server_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/5370
ID: 5367Test: i386 universal package_set_minimal
URL: https://openqa.fedoraproject.org/tests/5367
ID: 5371Test: i386 universal server_software_raid
URL: https://openqa.fedoraproject.org/tests/5371
ID: 5356Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/5356
ID: 5361Test: x86_64 universal server_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/5361
ID: 5363Test: i386 universal server_lvmthin
URL: https://openqa.fedoraproject.org/tests/5363
ID: 5362Test: x86_64 universal european_language_install
URL: https://openqa.fedoraproject.org/tests/5362
ID: 5349Test: x86_64 universal server_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/5349
ID: 5372Test: i386 universal server_btrfs
URL: https://openqa.fedoraproject.org/tests/5372
ID: 5350Test: x86_64 universal server_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/5350
ID: 5373Test: i386 universal server_ext3
URL: https://openqa.fedoraproject.org/tests/5373
ID: 5364Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/5364
ID: 5343Test: x86_64 universal package_set_kde
URL: https://openqa.fedoraproject.org/tests/5343
ID: 5366Test: i386 universal package_set_kde
URL: https://openqa.fedoraproject.org/tests/5366
ID: 5358Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/5358
ID: 5355Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/5355
ID: 5365Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/5365

Passed openQA tests: 34 of 63
3 openQA tests may be still running or broken!
-- 
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: GCC 6 Binaries segfaulting

[Florian Weimer]

On 02/15/2016 07:44 PM, Richard Shaw wrote:
> I have one package where several of the binaries used for unit testing are
> segfaulting.
> 
> I'm guessing that's not likely a direct GCC 6 issue but some googling leads
> me to believe that it could be an ABI breakage with a dependency that has
> not been rebuilt.
> 
> Is that the most likely cause?

It's impossible to tell with the information you gave us.

It could also be this bug:

  

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

GCC 6 Binaries segfaulting

[Richard Shaw]

I have one package where several of the binaries used for unit testing are
segfaulting.

I'm guessing that's not likely a direct GCC 6 issue but some googling leads
me to believe that it could be an ABI breakage with a dependency that has
not been rebuilt.

Is that the most likely cause?

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

Re: Please stop modifying other people's packages without coordinating with them first

[Josh Boyer]

On Mon, Feb 15, 2016 at 12:20 PM, Till Maas  wrote:
> On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:
>
>> You misunderstand.  I was not suggesting you ask for permission.  I
>> was stating that IRC contact alone, for whatever reason, is not
>> necessarily sufficient as an attempt to contact a maintainer.  You can
>> convey _much_ more information in an email, to the point of telling
>> them exactly what you are committing and why.  It is so much better
>> than a simple ping or brief sentence or two in IRC.
>
> I agree, that it is possible to be more informative via e-mail. However
> at the time I reached out via IRC, I did not yet know all the details. I
> only knew the build error from the previous build logs and a related
> commit message in upstream git. Therefore an e-mail would be pretty
> useless at this point, unless I stop working then. Otherwise there would
> be several status report e-mails about my slowed-down progress. If I was
> the targeted maintainer, I would be annoyed by this - we are not talking
> about changes that might require an epoch bump here and therefore are
> easily reverted.
>
>> As for waiting for a response, yes I think it is fine to wait a day.
>
> Not sure how it works for other volunteer maintainers, but this does not
> fit with my time slots that I might have available. So waiting a day
> might also mean wait till the next weekend, when I have time for this
> again.
>
>> Timezones alone may mean that the duplicate work you wished to avoid
>> was already queued on the maintainer's side and he was just waiting to
>> finish testing before pushing.  Who knows.  Urgency in fixing packages
>> is certainly appreciated, but this is not a critical package and it
>> had already been broken for a week.
>
> To be honest, a one week old commit to dist-git that does not build due
> to upstream bugs does not suggest to me that the maintainer has an extra
> secret stash of changes that are just waiting of a lot of extra testing.
> If the commit happened recently, it might be different.

You and I are going to disagree on this issue and the finer points
within it.  That is fine.  We will simply have to agree to disagree
because spending further time with back and forth isn't going to be
productive.

Thank you for the very civil discourse.

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

Re: Please stop modifying other people's packages without coordinating with them first

[Till Maas]

On Mon, Feb 15, 2016 at 07:47:08AM -0500, Josh Boyer wrote:

> You misunderstand.  I was not suggesting you ask for permission.  I
> was stating that IRC contact alone, for whatever reason, is not
> necessarily sufficient as an attempt to contact a maintainer.  You can
> convey _much_ more information in an email, to the point of telling
> them exactly what you are committing and why.  It is so much better
> than a simple ping or brief sentence or two in IRC.

I agree, that it is possible to be more informative via e-mail. However
at the time I reached out via IRC, I did not yet know all the details. I
only knew the build error from the previous build logs and a related
commit message in upstream git. Therefore an e-mail would be pretty
useless at this point, unless I stop working then. Otherwise there would
be several status report e-mails about my slowed-down progress. If I was
the targeted maintainer, I would be annoyed by this - we are not talking
about changes that might require an epoch bump here and therefore are
easily reverted.

> As for waiting for a response, yes I think it is fine to wait a day.

Not sure how it works for other volunteer maintainers, but this does not
fit with my time slots that I might have available. So waiting a day
might also mean wait till the next weekend, when I have time for this
again.

> Timezones alone may mean that the duplicate work you wished to avoid
> was already queued on the maintainer's side and he was just waiting to
> finish testing before pushing.  Who knows.  Urgency in fixing packages
> is certainly appreciated, but this is not a critical package and it
> had already been broken for a week.

To be honest, a one week old commit to dist-git that does not build due
to upstream bugs does not suggest to me that the maintainer has an extra
secret stash of changes that are just waiting of a lot of extra testing.
If the commit happened recently, it might be different.

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

Re: liborigin FTBFS

[Alexander Ploumistos]

On Mon, Feb 15, 2016 at 3:44 PM, Jonathan Wakely
 wrote:
> The problem is that the package defines a type 'function' in the
> global namespace, but also puts 'using namespace std;" in the global
> namespace, in a header. That causes the 'function' struct and
> 'std::function' to be ambiguous.

Was that considered correct or acceptable at the time the library was
written (ca 2008)?

> This patch fixes the build, but only by hacking around the problem,
> not fixing the evil 'using namespace std' in the header.

Thank you so much, I will apply this as soon as I get back!

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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Ralf Corsepius]

On 02/15/2016 04:54 PM, Jakub Jelinek wrote:

On Mon, Feb 15, 2016 at 04:46:32PM +0100, Dan Horák wrote:

On Mon, 15 Feb 2016 09:35:03 -0600
Richard Shaw  wrote:


On Mon, Feb 15, 2016 at 8:50 AM, Dan Horák  wrote:


On Mon, 15 Feb 2016 08:34:31 -0600
Richard Shaw  wrote:


Can someone point me in the right direction? My package
openCOLLADA is FTBFS in rawhide with the following (repeating)
error:



/builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:

error: narrowing conversion of '-1' from 'int' to 'char' inside
{ } [-Wnarrowing]
   };


isn't it on ARM? Then you should use explicit "signed char" as char
is unsigned by default on ARM (and other arches), see eg.
http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/



Thanks Dan, that got it, adding an explicit signed fixed the build.


you are welcome, there will be more packages suffering from the same
problem (I own at least one :-)), sometimes appending "-fsigned-char"
to CFLAGS will be easier.


Note that -fsigned-char changes the ABI, so it might have various
undesirable effects too.


Exactly. Because of this, I -fsigned-char should only be applied as a 
last resort/work-around to mere program/application packages and not to 
library packages, IMHO.


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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Jakub Jelinek]

On Mon, Feb 15, 2016 at 04:46:32PM +0100, Dan Horák wrote:
> On Mon, 15 Feb 2016 09:35:03 -0600
> Richard Shaw  wrote:
> 
> > On Mon, Feb 15, 2016 at 8:50 AM, Dan Horák  wrote:
> > 
> > > On Mon, 15 Feb 2016 08:34:31 -0600
> > > Richard Shaw  wrote:
> > >
> > > > Can someone point me in the right direction? My package
> > > > openCOLLADA is FTBFS in rawhide with the following (repeating)
> > > > error:
> > > >
> > > >
> > > /builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
> > > > error: narrowing conversion of '-1' from 'int' to 'char' inside
> > > > { } [-Wnarrowing]
> > > >   };
> > >
> > > isn't it on ARM? Then you should use explicit "signed char" as char
> > > is unsigned by default on ARM (and other arches), see eg.
> > > http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/
> > 
> > 
> > Thanks Dan, that got it, adding an explicit signed fixed the build.
> 
> you are welcome, there will be more packages suffering from the same
> problem (I own at least one :-)), sometimes appending "-fsigned-char"
> to CFLAGS will be easier.

Note that -fsigned-char changes the ABI, so it might have various
undesirable effects too.

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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Dan Horák]

On Mon, 15 Feb 2016 09:35:03 -0600
Richard Shaw  wrote:

> On Mon, Feb 15, 2016 at 8:50 AM, Dan Horák  wrote:
> 
> > On Mon, 15 Feb 2016 08:34:31 -0600
> > Richard Shaw  wrote:
> >
> > > Can someone point me in the right direction? My package
> > > openCOLLADA is FTBFS in rawhide with the following (repeating)
> > > error:
> > >
> > >
> > /builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
> > > error: narrowing conversion of '-1' from 'int' to 'char' inside
> > > { } [-Wnarrowing]
> > >   };
> >
> > isn't it on ARM? Then you should use explicit "signed char" as char
> > is unsigned by default on ARM (and other arches), see eg.
> > http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/
> 
> 
> Thanks Dan, that got it, adding an explicit signed fixed the build.

you are welcome, there will be more packages suffering from the same
problem (I own at least one :-)), sometimes appending "-fsigned-char"
to CFLAGS will be easier.


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

Re: Please stop modifying other people's packages without coordinating with them first

[Hans de Goede]

Hi,

On 15-02-16 14:15, Josh Boyer wrote:

On Mon, Feb 15, 2016 at 7:57 AM, Hans de Goede  wrote:

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




While I'm still very much on the fence about this, moving to pagure
for dist-git might very much help in these situations.  Being able to
send a pull request with your changes easily means you've fixed it,
the maintainer just needs to pull it in.  All of the information is
contained within that pull request.  It would seem to solve many of
our communication issues.



I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.

How many proven packager commits do we have a day / a week ? And how
much of those lead to "raised eyebrows" of the official package
maintainer ?

I think that with things like broken deps due to soname bumps +
mass-rebuild failures having proven=packagers help out is 99.9%
of the time very welcome help. I certainly always value such help
with my packages.


So they can continue.  I don't see why having pagure precludes them
from carrying on as normal.  YOu can even have "just commit, don't
send me pull requests" in the pagure repo info.


Ok, then I'm fine with it.


Both as a maintainer (having to respond to pull-reqs means extra work)
and as a proven packager I'm not in favor of adding this extra red-tape.


Why do people assume every change is going to be 100% mandatory for
everyone all the time?  I never said that.


I know you didn't say that I was just trying to pre-empt this possibly
becoming a mandatory thing.




If nobody else cares about this, then fine.  I'm not demanding it.
I'm simply suggesting it as a solution


I agree this maybe useful for some work flows, and people used to
the github workflow will likely like this, so if people want to work
on this as an extra option then I'm all for it.

> to the problem clearly highlighted in this thread.

I'm not sure there really is such a problem, which is exactly why
I replied. Yes there was a communication hiccup, those happen, but as
I said in my initial reply, how many provenpackager commits a day / week
do we have, and how often do we get such a communication hiccup ?

(Honest) Mistakes will always happen, we simply cannot "regulate"
mistakes away completely and trying to do so will just result
in needlessly complex procedures.

Regards,

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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Richard Shaw]

On Mon, Feb 15, 2016 at 8:50 AM, Dan Horák  wrote:

> On Mon, 15 Feb 2016 08:34:31 -0600
> Richard Shaw  wrote:
>
> > Can someone point me in the right direction? My package openCOLLADA is
> > FTBFS in rawhide with the following (repeating) error:
> >
> >
> /builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
> > error: narrowing conversion of '-1' from 'int' to 'char' inside { }
> > [-Wnarrowing]
> >   };
>
> isn't it on ARM? Then you should use explicit "signed char" as char is
> unsigned by default on ARM (and other arches), see eg.
> http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/


Thanks Dan, that got it, adding an explicit signed fixed the build.

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

Re: F24 Self Contained Change: Let's Encrypt client now in Fedora

[Pete Travis]

On Feb 10, 2016 6:29 AM, "Josh Boyer"  wrote:
>
> On Tue, Feb 9, 2016 at 11:32 AM, Jared K. Smith
>  wrote:
> >
> > On Mon, Feb 8, 2016 at 10:55 PM, Neal Gompa  wrote:
> >>
> >> And aren't we supposed to *not* do stuff like this
> >> anymore?
> >
> >
> >
> > If I had to guess, I'd say that this was proposed as an F24 change to
help
> > it get publicity in the release notes, etc.
>
> Changes are not used for that purpose.  It is expressly the reason we
> decided to stop calling them Features.  Changes focus on the technical
> content and impact for communication with Fedora developers.  There's
> nothing in this one that other developers really need to know about on
> a project wide scale.
>
> If someone wants to market something, they should be working with the
> docs and marketing teams directly.
>
> josh
> --

FWIW, to get attention for a new package in the release notes process, you
can simply set the review ticket's fedora_requires_release_notes flag to ?.

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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Dan Horák]

On Mon, 15 Feb 2016 08:34:31 -0600
Richard Shaw  wrote:

> Can someone point me in the right direction? My package openCOLLADA is
> FTBFS in rawhide with the following (repeating) error:
> 
> /builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
> error: narrowing conversion of '-1' from 'int' to 'char' inside { }
> [-Wnarrowing]
>   };

isn't it on ARM? Then you should use explicit "signed char" as char is
unsigned by default on ARM (and other arches), see eg.
http://blog.cdleary.com/2012/11/arm-chars-are-unsigned-by-default/


Dan
 
> I tried using the gcc6 porting guide but I'm not qutie enough of a
> programmer to understand how to apply it in this case. The offending
> code is:
> 
> const char HEX2DEC[256] = ^M
> {^M
> /*   0  1  2  3   4  5  6  7   8  9  A  B   C  D
> E  F */^M
> /* 0 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 1 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 2 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 3 */  0, 1, 2, 3,  4, 5, 6, 7,  8, 9,-1,-1,
> -1,-1,-1,-1,^M
> ^M
> /* 4 */ -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 5 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 6 */ -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 7 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> ^M
> /* 8 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* 9 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* A */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* B */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> ^M
> /* C */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* D */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* E */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1,^M
> /* F */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
> -1,-1,-1,-1^M };^M
> 
> Thanks,
> Richard
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Richard Shaw]

On Mon, Feb 15, 2016 at 8:46 AM, Mamoru TASAKA 
wrote:

> Richard Shaw wrote on 02/15/2016 11:34 PM:
>
>> Can someone point me in the right direction? My package openCOLLADA is
>> FTBFS in rawhide with the following (repeating) error:
>>
>>
>> /builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
>> error: narrowing conversion of '-1' from 'int' to 'char' inside { }
>> [-Wnarrowing]
>>};
>>
>> I tried using the gcc6 porting guide but I'm not qutie enough of a
>> programmer to understand how to apply it in this case. The offending code
>> is:
>>
>>  const char HEX2DEC[256] = ^M
>>  {^M
>>  /*   0  1  2  3   4  5  6  7   8  9  A  B   C  D  E
>> F
>> */^M
>>  /* 0 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
>> -1,-1,-1,-1,^M
>>  /* 1 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
>>
>
> 
>
> On _ARM_ (actually build failure seems to be on ARM) char is _unsigned_
> by default, so converting (int)-1 to char on ARM is narrowing conversion
> and C++11 forbids this on list-initialization.
>

Yes, I forgot to mention this was an ARM failure, i686 and x86_64 builds
will complete.


> You can do this when you explicitly cast, like
>  const char HEX2DEC[256] = { (char)-1, . }


I almost tried that but thought there might be a better way, I guess not...

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

Re: openCOLLADA: Help with GCC6 narrowing conversion

[Mamoru TASAKA]

Richard Shaw wrote on 02/15/2016 11:34 PM:

Can someone point me in the right direction? My package openCOLLADA is
FTBFS in rawhide with the following (repeating) error:

/builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
error: narrowing conversion of '-1' from 'int' to 'char' inside { }
[-Wnarrowing]
   };

I tried using the gcc6 porting guide but I'm not qutie enough of a
programmer to understand how to apply it in this case. The offending code
is:

 const char HEX2DEC[256] = ^M
 {^M
 /*   0  1  2  3   4  5  6  7   8  9  A  B   C  D  E  F
*/^M
 /* 0 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
 /* 1 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,




On _ARM_ (actually build failure seems to be on ARM) char is _unsigned_
by default, so converting (int)-1 to char on ARM is narrowing conversion
and C++11 forbids this on list-initialization.

You can do this when you explicitly cast, like
 const char HEX2DEC[256] = { (char)-1, . }

Regards,
Mamoru

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

openCOLLADA: Help with GCC6 narrowing conversion

[Richard Shaw]

Can someone point me in the right direction? My package openCOLLADA is
FTBFS in rawhide with the following (repeating) error:

/builddir/build/BUILD/OpenCOLLADA-3335ac164e68b2512a40914b14c74db260e6ff7d/COLLADABaseUtils/src/COLLADABUURI.cpp:57:2:
error: narrowing conversion of '-1' from 'int' to 'char' inside { }
[-Wnarrowing]
  };

I tried using the gcc6 porting guide but I'm not qutie enough of a
programmer to understand how to apply it in this case. The offending code
is:

const char HEX2DEC[256] = ^M
{^M
/*   0  1  2  3   4  5  6  7   8  9  A  B   C  D  E  F
*/^M
/* 0 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 1 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 2 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 3 */  0, 1, 2, 3,  4, 5, 6, 7,  8, 9,-1,-1,
-1,-1,-1,-1,^M
^M
/* 4 */ -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 5 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 6 */ -1,10,11,12, 13,14,15,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 7 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
^M
/* 8 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* 9 */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* A */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* B */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
^M
/* C */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* D */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* E */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1,
-1,-1,-1,-1,^M
/* F */ -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1^M
};^M

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

Re: F24 Self Contained Change: Let's Encrypt client now in Fedora

[Jan Kurik]

I just deferred this Change as it is not needed anymore.
https://fedoraproject.org/wiki/Changes/LetsEncrypt

Regards,
Jan

On Wed, Feb 10, 2016 at 4:27 PM, James Hogarth  wrote:
>
>
> On 10 February 2016 at 14:57, Josh Boyer  wrote:
>>
>> On Wed, Feb 10, 2016 at 9:41 AM, James Hogarth 
>> wrote:
>> >>
>> > Marketing are aware the package exists ... I worked with them on the
>> > Fedora
>> > Magazine article(s) after all ... even got a >5000 view badge for it! ;)
>>
>> Fantastic.
>>
>
> I was rather happy with the result.
>
>>
>> > Putting on my #centos community hat though ...
>> >
>> > Recently there was an uproar in mailing lists there and we told people
>> > to
>> > pay attention to Fedora ChangeSets for a loose indication on things to
>> > be
>> > aware of coming up.
>>
>> So you took a process that originally already had problems and added
>> more problems by telling people to use it for things it wasn't meant
>> for? :)
>>
>> Seriously, I understand the motivation there but Changes is not the
>> place to pay attention to things from a CentOS perspective.  Not every
>> Change will wind up in RHEL, so it is already misleading.  Further,
>> given the lifecycles, a Change that lands in one Fedora release may be
>> superseded by one in a later release.
>>
>
> Err I don't know where you are getting this from ... I *did not* submit this
> change ...
>
> I'm the point of contact and one of the maintainers for Let's Encrypt but
> I'm not the one that put together the wiki page.
>
> As I pointed out I'm at best ambivalent about this being a valid change -
> but we should probably have some mechanism to highlight new non-change
> features.
>
> Indeed though many (most?) Fedora changes won't affect future RHEL Mattdm
> was the one over on those lists suggesting people pay attention to Fedora
> ChangeSets for at least a rough heads up on what might be coming at some
> point.
>
>
>
>>
>> > If new packages/technology aren't to be mentioned and only changes to
>> > existing technology that may affect $developer are we do need a better
>> > way
>> > of exposing new things that are not changes.
>>
>> Yes.  New packages land in Fedora all the time.  We don't want to
>> require them to file a Change simply because someone in some other
>> project might be interested in it.  It's too much process.
>>
>> If we need cross-project collaboration on things that will either be
>> _in_ RHEL for sure, or things that CentOS wants/needs, that is a
>> totally separate discussion.  One that is certainly worth having.
>
>
>
> Realistically I think LE has had enough publicity for now and given the
> strong feelings would dismiss this from the F24 ChangeSet.
>
> I would say it's taking it to the extreme to declare about all new packages
> - most people won't care about the vast majority - but certain ones that
> have a significant community interest around makes sense.
>
> Regardless of potentially upcoming RHEL releases, the ability to highlight
> non-change features in a Fedora release, outside of $random FM article,
> sounds like it would be a worthwhile discussion to have on the marketing@
> mailing list.
>
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Fwd: Use suid_dumpable=2 for development releases

[Jakub Filak]

I'm not a security expert but I would rather start with something
less ambitious and more secure. Just for sure.


Regards,
Jakub


On 02/15/2016 11:22 AM, Miroslav Vadkerti wrote:

The issue described in the article was fixed by requiring an absolute
path in core_pattern (If I understand it correctly).

If core_pattern is unsafe, the process is not dumped at all  (man 5 proc).

The kernel commit adds a warning, because kernel was silently ignoring
crashes and no one could notice.

If this is true, shouldn't we be safe to set the default to 2?

Note also, that having suid_dumpable = 0 is sometimes blocking other security 
features in Fedora, for example sssd running as non-root by default - 
https://bugzilla.redhat.com/show_bug.cgi?id=1212503

Regards,
/M



Regards,
Jakub

On 02/12/2016 07:32 PM, Richard W.M. Jones wrote:

--
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: Please stop modifying other people's packages without coordinating with them first

[Peter Robinson]

>>> > While I'm still very much on the fence about this, moving to pagure
>>> > for dist-git might very much help in these situations.  Being able
>>> > to send a pull request with your changes easily means you've fixed
>>> > it, the maintainer just needs to pull it in.  All of the
>>> > information is contained within that pull request.  It would seem
>>> > to solve many of our communication issues.
>>>
>>> I do not think that adding a pull-req to the process of proven
>>> packager commits is really helpful. To me this feels like adding
>>> unnecessary red-tape in a response to one are two cases where a
>>> provenpackager commit was not 100% to the liking of the maintainer.
>>>
>>> How many proven packager commits do we have a day / a week ? And how
>>> much of those lead to "raised eyebrows" of the official package
>>> maintainer ?
>>>
>>> I think that with things like broken deps due to soname bumps +
>>> mass-rebuild failures having proven=packagers help out is 99.9%
>>> of the time very welcome help. I certainly always value such help
>>> with my packages.
>>>
>>> Both as a maintainer (having to respond to pull-reqs means extra work)
>>> and as a proven packager I'm not in favor of adding this extra
>>> red-tape.
>>>
>>> Note that it does not matter how easy you make this, it is still more
>>> work then the current process for both the proven-packager and the
>>> maintainer. And no it is not just 5 seconds with a good gui, that
>>> totally discounts the mental load of needing to do another task
>>> and loosing concentration / breaking your work flow because of those
>>> 5 seconds.
>>
>> dunno if Josh means the pull requests to be mandatory, but they would
>> add a nice option how to provide fixes for package maintainers from
>> non-proven packagers. A review of the suggested changes can be useful
>> and will be easier than patch attached in bugzilla.
>
> Yes, this is true as well.

Agreed, I know there was a discussion at some point of putting pagure
on top of dist-git to facilitate this sort of thing, having dealt with
a LOT of packages when doing arch bringups etc having to file bugs,
await responses from maintainers is a lot of work for often what is a
few line fix which is blocking a vast work flow so the ability for
people to push directly is essential but the ability to have pull
requests would be a great addition to the work flow.

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

[POC-change] Fedora packages point of contact updates

[nobody]

Change in package status over the last 168 hours


32 packages were orphaned
-
acpitool [f23, f22, master] was orphaned by kevin
 Command line ACPI client
 https://admin.fedoraproject.org/pkgdb/package/acpitool
gmm [f23, f22, master] was orphaned by kevin
 A generic C++ template library for sparse, dense and skyline matrices
 https://admin.fedoraproject.org/pkgdb/package/gmm
kmess [f23, f22, master] was orphaned by kevin
 Messaging client for MSN
 https://admin.fedoraproject.org/pkgdb/package/kmess
mockito [el6] was orphaned by raphgro
 A Java mocking framework
 https://admin.fedoraproject.org/pkgdb/package/mockito
netmonitor [f23, f22, master] was orphaned by kevin
 The free linux network bandwidth monitor
 https://admin.fedoraproject.org/pkgdb/package/netmonitor
powerman [f23, f22, el6, master, el5] was orphaned by kevin
 PowerMan - Power to the Cluster
 https://admin.fedoraproject.org/pkgdb/package/powerman
python-mwclient [f23, f22, master, el6, epel7, el5] was orphaned by kevin
 Mwclient is a client to the MediaWiki API
 https://admin.fedoraproject.org/pkgdb/package/python-mwclient
sugar-analyze [f23, f22, master] was orphaned by kevin
 Analysing tool for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-analyze
sugar-calculator [f23, f22, master] was orphaned by kevin
 Calculator for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-calculator
sugar-chat [f23, f22, master] was orphaned by kevin
 Chat client for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-chat
sugar-clock [f23, f22, master] was orphaned by kevin
 Clock activity for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-clock
sugar-connect [f23, f22, master] was orphaned by kevin
 Connect for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-connect
sugar-distance [f23, f22, master] was orphaned by kevin
 Distance measurement for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-distance
sugar-finance [f23, f22, master] was orphaned by kevin
 Financial planning for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-finance
sugar-flipsticks [f23, f22, master] was orphaned by kevin
 A keyframe animation activity for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-flipsticks
sugar-getiabooks [f23, f22, master] was orphaned by kevin
 Internet Archive Books receiver for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-getiabooks
sugar-help [f23, f22, master] was orphaned by kevin
 Help and Dokumentation for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-help
sugar-imageviewer [f23, f22, master] was orphaned by kevin
 Simple Image viewer for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-imageviewer
sugar-implode [f23, f22, master] was orphaned by kevin
 Implode for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-implode
sugar-infoslicer [f23, f22, master] was orphaned by kevin
 Downloader for articles from Wikipedia
 https://admin.fedoraproject.org/pkgdb/package/sugar-infoslicer
sugar-maze [f23, f22, master] was orphaned by kevin
 Maze for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-maze
sugar-memorize [f23, f22, master] was orphaned by kevin
 Memorize for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-memorize
sugar-pippy [f23, f22, master] was orphaned by kevin
 Pippy for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-pippy
sugar-playgo [f23, f22, master] was orphaned by kevin
 Go for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-playgo
sugar-record [f23, f22, master] was orphaned by kevin
 Recording tool for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-record
sugar-speak [f23, f22, master] was orphaned by kevin
 Speak for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-speak
sugar-stopwatch [f23, f22, master] was orphaned by kevin
 Simple stopwatch for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-stopwatch
sugar-terminal [f23, f22, master] was orphaned by kevin
 Terminal for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-terminal
sugar-view-slides [f23, f22, master] was orphaned by kevin
 Image serie viewer for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-view-slides
sugar-write [f23, f22, master] was orphaned by kevin
 Word processor for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-write
sugar-xoirc [f23, f22, master] was orphaned by kevin
 IRC client for Sugar
 https://admin.fedoraproject.org/pkgdb/package/sugar-xoirc
tripwire [f23, f22, el6, master, el5] was orphaned by kevin
 IDS (Intrusion Detection System)
 https://admin.fedoraproject.org/pkgdb/package/tripwire

9 

Re: liborigin FTBFS

[Jonathan Wakely]

On 14/02/16 19:55 +0200, Alexander Ploumistos wrote:

Yesterday I was notified that liborigin failed to build in rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=1307729


The problem is that the package defines a type 'function' in the
global namespace, but also puts 'using namespace std;" in the global
namespace, in a header. That causes the 'function' struct and
'std::function' to be ambiguous.

This is why 'using namespace std' should never appear in (or before)
headers.

This patch fixes the build, but only by hacking around the problem,
not fixing the evil 'using namespace std' in the header.


diff --git a/liborigin-20080225-cxx11.patch b/liborigin-20080225-cxx11.patch
new file mode 100644
index 000..da2d893
--- /dev/null
+++ b/liborigin-20080225-cxx11.patch
@@ -0,0 +1,8 @@
+767c767
+<  vector  FUNCTION;
+---
+>  vector <::function> FUNCTION;
+927c927
+<  FUNCTION.push_back(function(sname, dataIndex));
+---
+>  FUNCTION.push_back(::function(sname, 
dataIndex));
diff --git a/liborigin.spec b/liborigin.spec
index bcd2014..b95d0ce 100644
--- a/liborigin.spec
+++ b/liborigin.spec
@@ -1,6 +1,6 @@
 Name:  liborigin
 Version:   20080225
-Release:   16%{?dist}
+Release:   17%{?dist}
 Summary:   Library for reading OriginLab OPJ project files
 
 License:   GPLv2
@@ -10,6 +10,7 @@ URL:   http://sourceforge.net/projects/%{name}/
 Source:
http://belnet.dl.sourceforge.net/sourceforge/liborigin/%{name}-%{version}.tar.gz
 # Include  into tree.hh
 Patch0:%{name}-%{version}-gcc.patch
+Patch1:%{name}-%{version}-cxx11.patch
 
 BuildRequires: cmake
 Requires(post):/sbin/ldconfig
@@ -65,6 +66,9 @@ chmod 0644 ws4.opj
 %{_libdir}/%{name}.so
 
 %changelog
+* Mon Feb 15 2016 Jonathan Wakely  - 20080225-17
+- Patched for C++11 compatibility
+
 * Thu Feb 04 2016 Fedora Release Engineering  - 
20080225-16
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please stop modifying other people's packages without coordinating with them first

[Jonathan Wakely]

On 15/02/16 13:57 +0100, Hans de Goede wrote:

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




While I'm still very much on the fence about this, moving to pagure
for dist-git might very much help in these situations.  Being able to
send a pull request with your changes easily means you've fixed it,
the maintainer just needs to pull it in.  All of the information is
contained within that pull request.  It would seem to solve many of
our communication issues.


I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.


Personally I'd be happy with it. When patching lots of packages for
mass rebuilds I don't want to have to wait for dozens of email
responses and context-switch back to repos I was working in hours or
days earlier.  But if instead of pushing a fix I could send a pull
request and still "forget about" the package I'd be happy. The fix
would be shared with the maintainer, and I no longer need to track it
myself locally and chase people to respond.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Is my package a special Conflict: snowflake?

[Peter Lemenkov]

Hello All!
Fortunately this particular issue will be resolved soon. For those who
curious - we decided to switch to rds13 as a new upstream for
erlang-xmlrpc. It looks more promising since it's actively maintained
(last commit to the original xmlrpc repo was ~5 years ago).


2016-02-13 15:59 GMT+01:00 Randy Barlow :
> Hello fellow Fedora hackers!
>
> I am in a sticky packaging situation, and I think setting a Conflicts:
> in my package might be the solution. According to the Conflict
> guidelines[0], making a case here is a good way to go.
>
> jcline and I have been working for a number of weeks on getting the
> ejabberd package updated. It's been unmaintained for quite some time,
> and so updating it involved adding 15 more packages. Unfortunately
> during the process, I failed to notice that the dependency that ejabberd
> needed called "xmlrpc" was not the same upstream as the Fedora package
> "erlang-xmlrpc". We really want to get this in before the F24 branch in
> a week and change, so there's not much time to add the xmlrpc that
> ejabberd needs.
>
> One possibility that I've been investigating is renaming the new package
> to erlang-rds13_xmlrpc (rds13 being the github account that owns it),
> but it's non trivial and means applying lots of patching to both it and
> to ejabberd.
>
> Under more usual circumstances, I might think that's the way to go, but
> ejabberd's master branch has abandoned the use of this package in favor
> of a fork they are carrying of it they call p1_xmlrpc. This makes the
> Conflicts option attractive to me, as I will retire the new package in
> Fedora 25. It also makes it seem like it's not worth trying to get the
> upstreams to rename since I'm planning to drop the new package soon.
>
> I did consider going ahead and packaging their fork, but it may not be
> trivial as they have made changes to it and I'm not sure those changes
> are compatible with their older releases.
>
> I have done a little research on the package that conflicts with mine.
> It seems to be used by yaws:
>
> $ dnf repoquery --whatrequires erlang-xmlrpc
> yaws-0:2.0-2.fc24.x86_64
>
> Of course, we can't know what users might be depending on this package
> who's software is not in Fedora, and what I'm proposing could cause an
> issue for those users who might also want to use ejabberd on the same
> system.
>
> So what do you all think? Are there other options that I should be
> considering? Am I a special snowflake?
>
>
> [0]
> https://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files
>
> --
> Randy Barlow
> xmpp: bowlofe...@electronsweatshop.com
> irc:  bowlofeggs on Freenode
>
>
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>



-- 
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please stop modifying other people's packages without coordinating with them first

[Josh Boyer]

On Mon, Feb 15, 2016 at 8:09 AM, Dan Horák  wrote:
> On Mon, 15 Feb 2016 13:57:39 +0100
> Hans de Goede  wrote:
>
>> Hi,
>>
>> On 15-02-16 13:47, Josh Boyer wrote:
>>
>> 
>>
>> > While I'm still very much on the fence about this, moving to pagure
>> > for dist-git might very much help in these situations.  Being able
>> > to send a pull request with your changes easily means you've fixed
>> > it, the maintainer just needs to pull it in.  All of the
>> > information is contained within that pull request.  It would seem
>> > to solve many of our communication issues.
>>
>> I do not think that adding a pull-req to the process of proven
>> packager commits is really helpful. To me this feels like adding
>> unnecessary red-tape in a response to one are two cases where a
>> provenpackager commit was not 100% to the liking of the maintainer.
>>
>> How many proven packager commits do we have a day / a week ? And how
>> much of those lead to "raised eyebrows" of the official package
>> maintainer ?
>>
>> I think that with things like broken deps due to soname bumps +
>> mass-rebuild failures having proven=packagers help out is 99.9%
>> of the time very welcome help. I certainly always value such help
>> with my packages.
>>
>> Both as a maintainer (having to respond to pull-reqs means extra work)
>> and as a proven packager I'm not in favor of adding this extra
>> red-tape.
>>
>> Note that it does not matter how easy you make this, it is still more
>> work then the current process for both the proven-packager and the
>> maintainer. And no it is not just 5 seconds with a good gui, that
>> totally discounts the mental load of needing to do another task
>> and loosing concentration / breaking your work flow because of those
>> 5 seconds.
>
> dunno if Josh means the pull requests to be mandatory, but they would
> add a nice option how to provide fixes for package maintainers from
> non-proven packagers. A review of the suggested changes can be useful
> and will be easier than patch attached in bugzilla.

Yes, this is true as well.

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

Re: Please stop modifying other people's packages without coordinating with them first

[Josh Boyer]

On Mon, Feb 15, 2016 at 7:57 AM, Hans de Goede  wrote:
> Hi,
>
> On 15-02-16 13:47, Josh Boyer wrote:
>
> 
>
>> While I'm still very much on the fence about this, moving to pagure
>> for dist-git might very much help in these situations.  Being able to
>> send a pull request with your changes easily means you've fixed it,
>> the maintainer just needs to pull it in.  All of the information is
>> contained within that pull request.  It would seem to solve many of
>> our communication issues.
>
>
> I do not think that adding a pull-req to the process of proven packager
> commits is really helpful. To me this feels like adding unnecessary red-tape
> in a response to one are two cases where a provenpackager commit was
> not 100% to the liking of the maintainer.
>
> How many proven packager commits do we have a day / a week ? And how
> much of those lead to "raised eyebrows" of the official package
> maintainer ?
>
> I think that with things like broken deps due to soname bumps +
> mass-rebuild failures having proven=packagers help out is 99.9%
> of the time very welcome help. I certainly always value such help
> with my packages.

So they can continue.  I don't see why having pagure precludes them
from carrying on as normal.  YOu can even have "just commit, don't
send me pull requests" in the pagure repo info.

> Both as a maintainer (having to respond to pull-reqs means extra work)
> and as a proven packager I'm not in favor of adding this extra red-tape.

Why do people assume every change is going to be 100% mandatory for
everyone all the time?  I never said that.

> Note that it does not matter how easy you make this, it is still more
> work then the current process for both the proven-packager and the
> maintainer. And no it is not just 5 seconds with a good gui, that
> totally discounts the mental load of needing to do another task
> and loosing concentration / breaking your work flow because of those
> 5 seconds.

Yet it forces one to write up what you're changing and why they're
changing it, instead of just changing things and throwing in a crappy
commit message that doesn't actually explain anything.  It forces the
communication that was clearly missing in the originating problem to
happen if the maintainer has set up the repo that way.  What you view
as red tape is the very thing that makes high quality open source
projects high quality in the long run.  Imagine if kernel commits
didn't have descriptive changelogs or random people committing well
intentioned fixes without talking to the subsystem maintainer.  It'd
be terrible.  I don't see why we think it's OK for pkg-git commits in
a multi-committer environment to resort to the wild west days of
software development when we have tools that can help us if people
want.

I'm not suggesting your specific commits or Till's commits are like
this, but from an overall project standpoint I think improving our
commit logs and communication would be great.  If people just want to
go do that without tooling, fantastic.  Send patches to devel list or
something.  Pagure isn't _the_ solution, it just provides more prompts
to get there.

If nobody else cares about this, then fine.  I'm not demanding it.
I'm simply suggesting it as a solution to the problem clearly
highlighted in this thread.

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

Re: Please stop modifying other people's packages without coordinating with them first

[Dan Horák]

On Mon, 15 Feb 2016 13:57:39 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 15-02-16 13:47, Josh Boyer wrote:
> 
> 
> 
> > While I'm still very much on the fence about this, moving to pagure
> > for dist-git might very much help in these situations.  Being able
> > to send a pull request with your changes easily means you've fixed
> > it, the maintainer just needs to pull it in.  All of the
> > information is contained within that pull request.  It would seem
> > to solve many of our communication issues.
> 
> I do not think that adding a pull-req to the process of proven
> packager commits is really helpful. To me this feels like adding
> unnecessary red-tape in a response to one are two cases where a
> provenpackager commit was not 100% to the liking of the maintainer.
> 
> How many proven packager commits do we have a day / a week ? And how
> much of those lead to "raised eyebrows" of the official package
> maintainer ?
> 
> I think that with things like broken deps due to soname bumps +
> mass-rebuild failures having proven=packagers help out is 99.9%
> of the time very welcome help. I certainly always value such help
> with my packages.
> 
> Both as a maintainer (having to respond to pull-reqs means extra work)
> and as a proven packager I'm not in favor of adding this extra
> red-tape.
> 
> Note that it does not matter how easy you make this, it is still more
> work then the current process for both the proven-packager and the
> maintainer. And no it is not just 5 seconds with a good gui, that
> totally discounts the mental load of needing to do another task
> and loosing concentration / breaking your work flow because of those
> 5 seconds.

dunno if Josh means the pull requests to be mandatory, but they would
add a nice option how to provide fixes for package maintainers from
non-proven packagers. A review of the suggested changes can be useful
and will be easier than patch attached in bugzilla.


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

Re: System CA certificate trust store management meeting

[David Woodhouse]

On Tue, 2016-02-02 at 17:13 +0100, Tomas Mraz wrote:
> Hello,
> for anyone interested in the subject and visiting DevConf in Brno on 
> this Friday - we will be holding an informal meeting to gather use-cases 
> for needed improvements in this area. We are interested in feedback from 
> Fedora/RHEL system administrators and developers.
> 
> The meeting will happen on Friday Feb 5th 2016 13:10-14:30 at the 
> DevConf venue in the room C228.
> 
> See also:
> https://communityblog.fedoraproject.org/system-ca-certificate-trust-management-review-planning-meeting-devconf/
> 
> Regards,
> 
> Tomas Mraz, Security Technologies Team member at Red Hat

Hi Tomas,

Was there a conclusion for this?

-- 
dwmw2



smime.p7s
Description: S/MIME cryptographic signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Please stop modifying other people's packages without coordinating with them first

[Hans de Goede]

Hi,

On 15-02-16 13:47, Josh Boyer wrote:




While I'm still very much on the fence about this, moving to pagure
for dist-git might very much help in these situations.  Being able to
send a pull request with your changes easily means you've fixed it,
the maintainer just needs to pull it in.  All of the information is
contained within that pull request.  It would seem to solve many of
our communication issues.


I do not think that adding a pull-req to the process of proven packager
commits is really helpful. To me this feels like adding unnecessary red-tape
in a response to one are two cases where a provenpackager commit was
not 100% to the liking of the maintainer.

How many proven packager commits do we have a day / a week ? And how
much of those lead to "raised eyebrows" of the official package
maintainer ?

I think that with things like broken deps due to soname bumps +
mass-rebuild failures having proven=packagers help out is 99.9%
of the time very welcome help. I certainly always value such help
with my packages.

Both as a maintainer (having to respond to pull-reqs means extra work)
and as a proven packager I'm not in favor of adding this extra red-tape.

Note that it does not matter how easy you make this, it is still more
work then the current process for both the proven-packager and the
maintainer. And no it is not just 5 seconds with a good gui, that
totally discounts the mental load of needing to do another task
and loosing concentration / breaking your work flow because of those
5 seconds.

Regards,

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

Re: Please stop modifying other people's packages without coordinating with them first

[Josh Boyer]

On Sun, Feb 14, 2016 at 2:32 PM, Till Maas  wrote:
> On Sat, Feb 13, 2016 at 04:29:38PM -0500, Josh Boyer wrote:
>
>> I'm not going to weigh in on the changes, but I did want to address
>> this in public so others can learn.
>
> IMHO the kind of changes are important here. The situation was that
> there were was an incomplete update to the sigrok packages in Rawhide
> and Fedora 23 testing for about a week. This means that any Rawhide user
> wanting to use pulseview (the GUI tool for sigrok) could not install it
> freshly or would get broken dependency warnings when trying to update
> Rawhide. The same goes for F23 testing. Also the necessary buildroot
> overrides required for F23 were expired, requiring them to be extended
> to be able to build pulseview and also sigrok-cli, which just failed in
> F23 because of missing dependencies from the buildroot overrides.
> But pulseview also did not compile because of errors already fixed by
> upstream.
>
> So the main change I did was adding unmodified upstream patches to
> pulseview getting it to compile. While doing this I noticed that
> pulseview was not using the %license macro yet, so I fixed this as well.

The changes all sound fine and well intended.

>> IRC alone is not sufficient.  We cannot expect volunteer maintainers
>> to be on IRC all the time.  In the future, please email and wait at
>> least a bit for a reply.
>
> Given the changes that I described, do you still state that this (fixing
> incomplete updates/dependencies/package building) is something that
> provenpackagers should first get permission to do by the package
> maintainer? I mainly cared about not doing the same work twice and
> making sure that I do not commit something conflicting to the GIT as the
> same time the maintainer might commit something, which is why I found
> IRC sufficient at that time. Also IMHO it is beneficial to the Fedora
> project to fix breakage in the repositories as soon as possible. And as
> a package maintainer myself I would be thankful for every other package
> maintainer fixing bugs in my packages while I sleep. Since I am a
> volunteer maintainer myself, the strict requirement to get permission
> via e-mail to fix sigrok in this situation would have meant that I would
> have done nothing. Yesterday I had time and motivation to look into it
> and fix it. But if I asked "May I please fix your package?", it is very
> likely that I would not have the time or motivation to actually do it
> once I get the response.

You misunderstand.  I was not suggesting you ask for permission.  I
was stating that IRC contact alone, for whatever reason, is not
necessarily sufficient as an attempt to contact a maintainer.  You can
convey _much_ more information in an email, to the point of telling
them exactly what you are committing and why.  It is so much better
than a simple ping or brief sentence or two in IRC.

As for waiting for a response, yes I think it is fine to wait a day.
Timezones alone may mean that the duplicate work you wished to avoid
was already queued on the maintainer's side and he was just waiting to
finish testing before pushing.  Who knows.  Urgency in fixing packages
is certainly appreciated, but this is not a critical package and it
had already been broken for a week.

While I'm still very much on the fence about this, moving to pagure
for dist-git might very much help in these situations.  Being able to
send a pull request with your changes easily means you've fixed it,
the maintainer just needs to pull it in.  All of the information is
contained within that pull request.  It would seem to solve many of
our communication issues.

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

Re: Use suid_dumpable=2 for development releases

[Andrew Clayton]

On Mon, 15 Feb 2016 07:00:36 +0100, Jakub Filak wrote:

> On 02/12/2016 07:57 PM, Andrew Lutomirski wrote:
> > We could change the kernel to add suid_dumpable == 3 which is like
> > suid_dumpable==2 but only if the core_pattern is a pipe.
> >  
> I didn't know that 3 is supported for suid_dumpable.
> The value of 3 is not documented [1] and I can't find it in the
> source code [2].

It isn't. What he's saying is that option could be added.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf remove qemu-img uninstall kernel

[Michal Luscon]

On 02/15/2016 08:53 AM, Jan Zelený wrote:

On 12. 2. 2016 at 18:42:50, Sérgio Basto wrote:

On Sex, 2016-02-12 at 19:36 +0100, Mattia Verga wrote:

Il 12/02/2016 19:22, Sérgio Basto ha scritto:

On Sex, 2016-02-12 at 19:18 +0100, Mattia Verga wrote:

I've installed qemu to play with arm virtualization, now I want
to
uninstall it, but it seems that trying to uninstall anything qemu
related also removes all installed kernels Is this a DNF bug?

no this is :

clean_requirements_on_remove=true

in /etc/dnf/dnf.conf

Thanks, setting it to "false" avoid kernel uninstalling.

But if it's not a bug, I can hardly see the reason to have a
"feature"
that removes the kernel... dnf should not autoremove mandatory
system
components. But that's my opinion, there's probably an important
reason
for which I'm wrong.

This behavior might not be caused by a bug in dnf. There has recently been a
bug in PackageKit which you might be hitting.

Most likely #1259865 is causing this issue.

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

Re: Subject: Self Introduction: Romain Philibert

[Lubomir Rintel]

Hello Romain,

On Mon, 2016-02-15 at 10:14 +, Romain Philibert wrote:
> Hello,
> 
> I am working at Worldline, we are using massively CentOS and EPEL.
> Unfortunately somes packages installed on our serveurs are becoming
> retired from EPEL. I would like to be part of the Fedora community in
> order to maintain such packages.

It's nice to see you on board. Welcome!

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

Re: ntpstat

[Miroslav Lichvar]

On Fri, Feb 12, 2016 at 08:48:41AM -0500, Przemek Klosowski wrote:
> On 02/12/2016 06:10 AM, Miroslav Lichvar wrote:
> >It has been included in the ntp package for a very long time, but it's
> >not actually part of the upstream ntp package (and can't be as it's
> >licensed under GPL). I guess ntpstat should rather have its own
> >package.
> Since you are thinking of rewriting, it would make sense to offer it to
> upstream. Do you think they'd take it?

That's a good point. I'll ask them. I think they wouldn't be
interested in the part of the script that adds chrony support, so it
would continue as an ntpd only utility.

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

Re: Fwd: Use suid_dumpable=2 for development releases

[Miroslav Vadkerti]

> The issue described in the article was fixed by requiring an absolute
> path in core_pattern (If I understand it correctly).
> 
> If core_pattern is unsafe, the process is not dumped at all  (man 5 proc).
> 
> The kernel commit adds a warning, because kernel was silently ignoring
> crashes and no one could notice.

If this is true, shouldn't we be safe to set the default to 2?

Note also, that having suid_dumpable = 0 is sometimes blocking other security 
features in Fedora, for example sssd running as non-root by default - 
https://bugzilla.redhat.com/show_bug.cgi?id=1212503

Regards,
/M

> 
> 
> Regards,
> Jakub
> 
> On 02/12/2016 07:32 PM, Richard W.M. Jones wrote:
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Subject: Self Introduction: Romain Philibert

[Romain Philibert]

Hello,

I am working at Worldline, we are using massively CentOS and EPEL. 
Unfortunately somes packages installed on our serveurs are becoming retired 
from EPEL. I would like to be part of the Fedora community in order to maintain 
such packages.

On my free time, I love playing with OpenSource, GitHub 
(https://github.com/Filirom1), NodeJS and Docker.

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