unresponsive maintainer: ricardo

[gil]

Hi
I am now a couple of months that I have no news
for apply a further submitted patches for these packages:

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

for this package I did request to become co maintainer
snappy-java: https://bugzilla.redhat.com/show_bug.cgi?id=1245629
https://admin.fedoraproject.org/pkgdb/package/snappy-java/

and this
avro: https://bugzilla.redhat.com/show_bug.cgi?id=1239381
this package because of some broken dependencies [1]
suffered of FTBFS in rawhide.

Someone could take steps to apply the proposed adjustments?

Thanks in advance
gil

[1] hadoop , at the moment available in f24 andfor f23
https://bodhi.fedoraproject.org/updates/FEDORA-2015-15816
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 08:33, Ben Boeckel написа:

On Wed, 16 Sep, 2015 at 16:24:02 GMT, Alexander Todorov wrote:

Please let me know which packages need to genuinely be excluded and what should
we do with these packages ? Some will probably be fixed once they are rebuilt
but that may take a while.

Any package maintainers out there - please fix your packages in Rawhide so we
don't have to file bugs for all of them.


I see lots (probably all) of ghc-* packages, so filing one against
ghc-rpm-macros or ghc itself would probably be the most expedient there.
If it is just a missed flag or something, it can be rolled up with the
7.10.0 rebuild which I believe is planned for Rawhide.



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



Of course, if ghc doesn't support everything checksec looks for,
ignoring everything under %{_libdir}/ghc-*/ would be best. Jens?





For any CMake-using projects (I see at least CMake itself and ParaView
in the list), setting the `POSITION_INDEPENDENT_CODE` property[1] on
targets would fix any missing -fPIE. It is initialized with
`CMAKE_POSITION_INDEPENDENT_CODE`, so adding:

 -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON

to %cmake when hardening is enabled should fix -fPIE missing. Anything
with internal static libraries *might* need a scalpel to turn off the
property on those targets.

--Ben

[1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html



Ben,
is there any way this CMake property be turned on globally ?


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 23:05, Kaleb S. KEITHLEY написа:

On 09/16/2015 01:19 PM, Jason L Tibbitts III wrote:

"AT" == Alexander Todorov  writes:


AT> offending packages. You can find links to the script and execution
AT> log here:
AT> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/

BTW to see if any packages you own are on the list, you can do:

wget 
https://raw.githubusercontent.com/atodorov/fedora-scripts/master/checksec.log
for i in $(pkgdb-cli list --user tibbs --nameonly); do grep "^$i.*rpm$" 
checksec.log|uniq; done



GlusterFS packages have seven "No canary found" [1]. I get the same
results with gcc-5.1.1 on f22.

However GlusterFS _is_ built with '%global _hardened_build 1' and I have
confirmed that all its sources are compiled with -fstack-protector-strong.

As I read the gcc man page for -fstack-protector,
-fstack-protector-strong, and -fstack-protector-all, it's clear that
with just -fstack-protector-strong it's entirely plausible that these
DSOs would not have the call to __stack_chk_fail, i.e. the canary.

If I compile them with -fstack-protector-all then the resulting .o and
.so files _do_ have the call to __stack_chk_fail.

Off hand I'd say that checksec's test for the canary is wanting.

The glusterfs packages need to be excluded. Or change _hardened_build to
use -fstack-protector-all.




Hi Kaleb,
thanks for pointing this out.

Can somebody comment on the -fstack-protector-all vs -fstack-protector-strong 
issue ? Do we want to change the default for %__global_cflags in 
/usr/lib/rpm/redhat/macros ?



--
Alex




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 21:56, Adam Jackson написа:

On Wed, 2015-09-16 at 18:26 +0100, Peter Robinson wrote:


What is the proper fix to these issues? Having fixed some myself and
ajax having looked at a bunch of them I don't think it's as simple as
just mass rebuilding the packages.


A lot of it is libtool being shit, which is nothing new I suppose. I
suspect this patch will help a lot:

http://lists.gnu.org/archive/html/bug-libtool/2013-10/msg0.html

Apologies for not having looked at this for a while, I've been on a
much-needed vacation for the last few weeks. I'm going to test the
above and see if it magically fixes naive autotools builds, probably it
will.



Adam,
can you update this bug or comment on the mailing list when this is ready ?
https://bugzilla.redhat.com/show_bug.cgi?id=985592


Should we block on ^^^ before doing the mass rebuild ?


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Freeimage 3.10 -> 3.17 upgrade, dealing with library incompatibility

[Florian Weimer]

On 09/17/2015 10:28 AM, Sandro Mani wrote:

> - abi_compliance_checker reports that compatibility was not broken
> between libfreeimage of 3.10 and 3.17. However, in libfreeimageplus,
> various function signatures have changed due to switching from WORD (aka
> unsigned short) to unsigned for various size related parameters. The
> soname was not changed, so this is an upstream error.

Why doesn't abi_compliance_checker report this?  Doesn't such a
modification change the list of exported symbols due to C++ name mangling?

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Call for testing: 32-bit AMD CPU owners

[Adam Williamson]

On Thu, 2015-09-17 at 12:33 +0300, Alexander Ploumistos wrote:
> I tested
> https://dl.fedoraproject.org/pub/alt/stage/23_Alpha_RC2/Server/i386/i
> so/Fedora-Server-netinst-i386-23_Alpha.iso
> on a dual Athlon MP system and it boots fine to anaconda.
> 
> A little bit later I discovered
> https://dl.fedoraproject.org/pub/alt/stage/23_Beta_RC1/Server/i386/is
> o/Fedora-Server-netinst-i386-23_Beta.iso
> and tested it as well, same result.
> 
> Should I have tried some other image?

Nope, that's the right one, thanks for testing, and sorry to post the
wrong links originally!

With your report and a few others, it sounds like the bug doesn't
affect actual 32-bit AMD CPUs, which is good news.
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Unix-Statgrab

[buildsys]

perl-Unix-Statgrab has broken dependencies in the rawhide tree:
On x86_64:
perl-Unix-Statgrab-0.04-25.1.fc23.x86_64 requires 
libstatgrab.so.6()(64bit)
On i386:
perl-Unix-Statgrab-0.04-25.1.fc23.i686 requires libstatgrab.so.6
On armhfp:
perl-Unix-Statgrab-0.04-25.1.fc23.armv7hl requires libstatgrab.so.6
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the rawhide tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the rawhide tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the rawhide tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the rawhide tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Freeimage 3.10 -> 3.17 upgrade, dealing with library incompatibility

[Kalev Lember]

On 09/17/2015 10:28 AM, Sandro Mani wrote:
> - Nothing in Fedora seems to require libfreeimageplus, so just build
> 3.17 in rawhide and F23 and have the libfreeimageplus ABI break silently
> sneak in. Probably shouldn't even mention this option.

If nothing depends on it, just go with what's easiest for you. It really
doesn't matter much either way when we are talking about an unused library.

Also, as a side note, it probably makes sense to split off the unused
library into a separate subpackage so that regular libfreeimage
installations don't get it pulled in.

-- 
Hope this helps,
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the rawhide tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the rawhide tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

rawhide report: 20150917 changes

[Fedora Rawhide Report]

Compose started at Thu Sep 17 05:15:06 UTC 2015
Broken deps for i386
--
[IQmol]
IQmol-2.3.0-9.fc24.i686 requires libboost_serialization.so.1.58.0
IQmol-2.3.0-9.fc24.i686 requires libboost_iostreams.so.1.58.0
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aqsis]
aqsis-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_program_options.so.1.58.0
aqsis-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_wave.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-core-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_thread.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_system.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_regex.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_iostreams.so.1.58.0
aqsis-libs-1.8.2-20.fc24.i686 requires libboost_filesystem.so.1.58.0
[aws]
aws-tools-2015-2.fc23.i686 requires libaws_ssl.so
[bro]
bro-2.3.2-6.fc23.i686 requires libjemalloc.so.1
[bwm-ng]
bwm-ng-0.6-18.fc24.i686 requires libstatgrab.so.6
[cp2k]
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_usempif08.so.0(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_usempi_ignore_tkr.so.0(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi_mpifh.so.2(openmpi-i386)
cp2k-openmpi-2.7.0-0.2.20150911svn15878.fc24.i686 requires 
libmpi.so.1(openmpi-i386)
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.i686 requires MySQL-python(x86-32)
[elpa]
elpa-openmpi-2015.05.001-2.fc24.i686 requires 
libmpi_usempif08.so.0(openmpi-i386)
elpa-openmpi-2015.05.001-2.fc24.i686 requires 
libmpi_usempi_ignore_tkr.so.0(openmpi-i386)
elpa-openmpi-2015.05.001-2.fc24.i686 requires 
libmpi_mpifh.so.2(openmpi-i386)
elpa-openmpi-2015.05.001-2.fc24.i686 requires libmpi.so.1(openmpi-i386)
[ghc-hakyll]
ghc-hakyll-4.5.4.0-3.fc23.i686 requires libHSxml-1.3.13-ghc7.8.4.so
ghc-hakyll-4.5.4.0-3.fc23.i686 requires 
ghc(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
ghc-hakyll-devel-4.5.4.0-3.fc23.i686 requires 
ghc-devel(pandoc-1.13.2-54186dabcc89e90f1b8b1cafd8e569fe)
[gnash]
1:gnash-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_serialization.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_program_options.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_thread.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_system.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_serialization.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_iostreams.so.1.58.0
1:gnash-cygnal-0.8.10-19.fc24.i686 requires libboost_date_time.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-dejagnu-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0
1:gnash-extension-fileio-0.8.10-19.fc24.i686 requires 
libboost_iostreams.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_thread.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_system.so.1.58.0
1:gnash-extension-lirc-0.8.10-19.fc24.i686 requires 
libboost_program_options.so.1.58.0

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Florian Weimer]

On 09/17/2015 01:03 PM, Alexander Todorov wrote:
> На 17.09.2015 в 12:26, Richard W.M. Jones написа:
>>> As far as I can see most of them report "Partial RELRO" which may
>>> well be fixed as you propose below. If not I can easily exclude
>>> them.
>>
>> They're intermediate files used by developers.  They aren't runnable
>> binaries.  I think everything in %{libdir}/ocaml should be ignored.
>>
> 
> 
> I see .o files, .so files and some .cmxs ones. Should all of them be
> ignored then ?

.o files need to have an empty .note.GNU-stack section.

If they are compiled with GCC (see the .comment section), they need to
have debugging information, and the debugging information must include
the recorded command line options.  Those command line options must have
the required hardening flags.  The debugging information must cover all
object code.

For .so files, similar rules apply, but the debug information may have
been separated.  Instead of section, the non-executable stack is now
controlled by the GNU_STACK program header.  Additionally, there most be
GNU_RELRO program header. and the relocations must not overlap with a
page that is read-write.

checksec cannot check most of this, unfortunately.

I don't know how .cmxs files are used.  They seem similar to .so files,
so the same rules apply.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-23 Branched report: 20150917 changes

[Fedora Branched Report]

Compose started at Thu Sep 17 07:15:03 UTC 2015
Broken deps for armhfp
--
[apache-scout]
apache-scout-1.2.6-11.fc21.noarch requires mvn(org.apache.juddi:uddi-ws)
apache-scout-1.2.6-11.fc21.noarch requires 
mvn(org.apache.juddi:juddi-client)
[aws]
aws-tools-2015-2.fc23.armv7hl requires libaws_ssl.so
[cego]
cego-2.20.21-3.fc23.armv7hl requires liblfcbase.so.1
[dpm-contrib-admintools]
dpm-contrib-admintools-0.2.1-6.fc23.armv7hl requires 
MySQL-python(armv7hl-32)
[hadoop]
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-common-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-hdfs-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-mapreduce-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-servlet)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-tests-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey:jersey-client)
hadoop-yarn-2.4.1-8.fc22.noarch requires 
mvn(com.sun.jersey.contribs:jersey-guice)
[hawaii-shell]
hawaii-shell-0.3.0-3.fc22.armv7hl requires 
libqtaccountsservice-qt5.so.0.1.2
[hbase]
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json)
hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-server)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-json)
hbase-tests-0.98.3-4.fc22.noarch requires 
mvn(com.sun.jersey:jersey-core)
[klavaro]
klavaro-3.01-0.pre1.1.fc23.1.armv7hl requires libgtkdataboks.so.0
[licq]
licq-1.8.2-9.fc23.armv7hl requires libboost_regex.so.1.57.0
[mariadb-galera]
1:mariadb-galera-server-10.0.17-5.fc23.armv7hl requires galera >= 
0:25.3.3
[moon-buggy]
moon-buggy-1.0.51-14.fc23.armv7hl requires libesd.so.0
[netbeans-platform]
1:netbeans-platform-harness-7.0.1-11.fc22.armv7hl requires cobertura >= 
0:1.9.3
[nodejs-grunt-contrib-copy]
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) < 0:0.2
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires 
npm(file-sync-cmp) >= 0:0.1.0
nodejs-grunt-contrib-copy-0.8.0-2.fc23.noarch requires npm(chalk) >= 
0:0.5.1
[nodejs-grunt-saucelabs]
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(sauce-tunnel) 
>= 0:2.2.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) < 
0:1.3
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(requestretry) 
>= 0:1.2.2
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(lodash) >= 
0:3.7.0
nodejs-grunt-saucelabs-8.6.1-2.fc23.noarch requires npm(colors) >= 
0:1.0.0
[nodejs-proxy-agent]
nodejs-proxy-agent-1.1.0-1.fc22.noarch requires npm(socks-proxy-agent) 
< 0:1
[nodejs-socks-proxy-agent]
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
< 0:2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(socks-client) 
>= 0:1.1.2
nodejs-socks-proxy-agent-1.0.0-2.fc23.noarch requires npm(extend) < 0:2
[oat]
oat-appraiser-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
oat-client-1.6.0-16.fc22.armv7hl requires tomcat-servlet-3.0-api
[oozie]
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.pig:pig)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-serde)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-metastore)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-exec)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-common)
oozie-4.0.1-5.fc22.noarch requires mvn(org.apache.hive:hive-cli)
   

jplesnik uploaded Set-Object-1.35.tar.gz for perl-Set-Object

[notifications]

95be9c38e94a140bfd2209cae282d5d8  Set-Object-1.35.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Set-Object/Set-Object-1.35.tar.gz/md5/95be9c38e94a140bfd2209cae282d5d8/Set-Object-1.35.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

jplesnik pushed to perl-Set-Object (master). "1.35 bump"

[notifications]

From 9deba69b4241b63bf65e8e71e628d5be40997418 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 17 Sep 2015 14:00:36 +0200
Subject: 1.35 bump


diff --git a/.gitignore b/.gitignore
index d8484d2..c144a73 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 Set-Object-1.26.tar.gz
 /Set-Object-1.31.tar.gz
+/Set-Object-1.35.tar.gz
diff --git a/perl-Set-Object.spec b/perl-Set-Object.spec
index 6cd07b3..92101b2 100644
--- a/perl-Set-Object.spec
+++ b/perl-Set-Object.spec
@@ -1,13 +1,15 @@
 Name: perl-Set-Object
-Version: 1.31
-Release: 7%{?dist}
-License: GPL+ or Artistic
+Version: 1.35
+Release: 1%{?dist}
+License: Artistic 2.0
 Summary: Set of objects and strings
 Group: Development/Libraries
 URL: http://search.cpan.org/dist/Set-Object/
 Source0: http://www.cpan.org/modules/by-module/Set/Set-Object-%{version}.tar.gz
-Source1: license.txt
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root
+BuildRequires: coreutils
+BuildRequires: findutils
+BuildRequires: make
 BuildRequires: perl
 BuildRequires: perl(ExtUtils::MakeMaker)
 # Run-time
@@ -22,6 +24,7 @@ BuildRequires: perl(strict)
 BuildRequires: perl(vars)
 # Tests
 BuildRequires: perl(Config)
+BuildRequires: perl(constant)
 BuildRequires: perl(Data::Dumper)
 BuildRequires: perl(Devel::Peek)
 BuildRequires: perl(Test::More)
@@ -33,7 +36,6 @@ BuildRequires: perl(threads)
 BuildRequires: perl(threads::shared)
 BuildRequires: perl(warnings)
 Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
-Requires: perl(overload)
 Requires: perl(Scalar::Util)
 
 %description
@@ -45,7 +47,6 @@ anything that is a reference is considered an object.
 
 %prep
 %setup -q -n Set-Object-%{version}
-cp %{SOURCE1} .
 
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
@@ -75,6 +76,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Thu Sep 17 2015 Jitka Plesnikova  - 1.35-1
+- 1.35 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 1.31-7
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 4bed74e..4678761 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-541a25d5e1d06fb1d2cc459118559a08  Set-Object-1.31.tar.gz
+95be9c38e94a140bfd2209cae282d5d8  Set-Object-1.35.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Set-Object.git/commit/?h=master=9deba69b4241b63bf65e8e71e628d5be40997418
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1230803] Upgrade perl-Set-Object to 1.35

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Set-Object-1.35-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2015-09-17 08:02:24



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

jplesnik pushed to perl-Set-Object (master). "Remove license.txt"

[notifications]

From 2952e18166f002aa00d42137341a47f8809df1ff Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Thu, 17 Sep 2015 14:09:28 +0200
Subject: Remove license.txt


diff --git a/license.txt b/license.txt
deleted file mode 100644
index a86ca08..000
--- a/license.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-Set-Object used to be licensed under the Perl Artistic license, and
-the documentation still says so (I expect it being updated with the
-next upstream release).  Due to the artistic license not being
-accepted as free license by the FSF I've asked the authors whenever
-they agree to relicense the package and fortunaly they did, so the
-package now carries the same license as perl itself (which is the
-choice between Artistic and GPL).
-
-See also:
-  http://dev.perl.org/licenses/
-  https://fedoraproject.org/wiki/Licensing
-  https://bugzilla.redhat.com/show_bug.cgi?id=467175
-
-The relevant messages from the authors (Jean-Louis Leroy and Sam
-Vilain) are listed below.
-
--
-
-From: "jl" 
-To: Gerd Hoffmann 
-Subject: Re: Set-Object license question
-Date: Sat, 08 Nov 2008 08:51:51 +0100
-
-Hello Gerd. 
-
-I agree to relicense Set::Object under the same terms as (current) Perl 
-itself - which is probably the choice between two licenses: Artistic 2.0 and 
-GPL. 
-
-Cordially,
-Jean-Louis 
-
--
-
-Subject: Re: Set-Object license question
-From: Sam Vilain 
-To: Gerd Hoffmann 
-Date: Fri, 24 Oct 2008 00:33:23 +1300
-
-On Wed, 2008-10-22 at 11:58 +0200, Gerd Hoffmann wrote:
-> Sam Vilain wrote:
-> > AFAIK the original author has not responded to requests for relicensing
-> > under GPLv2.
-> 
-> You are refering to Jean-Louis Leroy I guess?
-
-That's right, of Sound Object Logic.
-
-> > Could get a notary public to serve them notice of the intention to
-> > relicense Set::Object as GPL under the requirements of the license for
-> > Tangram.  If they don't make claim, then it should be able to be
-> > relicensed, I'd guess.
-> 
-> I think I'll better try again asking by email first.
-> 
-> Given you apparently tried already to get it re-licenced I assume you
-> are fine with GPL, right?
-> 
-> What about "Catalyst IT (NZ) Limited" listed in the man-page?  Given you
-> are still listed as maintainer @ CPAN I assume this is the company you
-> are working for?
-
-Yes, I can speak for that copyright holder, and they are happy to
-license under any FSF-approved Free Software license, including the Perl
-Artistic/GPL disjunction.
-
-Contact Jean-Louis - if nothing comes back I might have to investigate a
-rewrite.
-
-Cheers,
-Sam.
diff --git a/perl-Set-Object.spec b/perl-Set-Object.spec
index 92101b2..6ac3f4b 100644
--- a/perl-Set-Object.spec
+++ b/perl-Set-Object.spec
@@ -54,7 +54,7 @@ make %{?_smp_mflags}
 
 %install
 rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
 
 # clean up buildroot
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
@@ -70,7 +70,8 @@ rm -rf %{buildroot}
 
 %files
 %defattr(-, root, root, -)
-%doc Changes.pod META.yml README license.txt
+%license LICENSE
+%doc Changes.pod META.yml README
 %{perl_vendorarch}/auto/*
 %{perl_vendorarch}/Set*
 %{_mandir}/man3/*.3*
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Set-Object.git/commit/?h=master=2952e18166f002aa00d42137341a47f8809df1ff
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1230621] Upgrade perl-Library-CallNumber-LC to 0.23

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|d...@coffeecode.net  |ppi...@redhat.com



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

perl-Set-Object license change

[Jitka Plesníková]

perl-Set-Object-1.35-1.fc24 changes license
from (GPL+ or Artistic) to Artistic 2.0.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-Data-Alias

[buildsys]

perl-Data-Alias has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Alias-1.18-4.fc22.x86_64 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Data-Alias-1.18-4.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Alias-1.18-4.fc22.armv7hl requires perl(:MODULE_COMPAT_5.20.0)
perl-Data-Alias-1.18-4.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Data-Dump-Streamer

[buildsys]

perl-Data-Dump-Streamer has broken dependencies in the F-23 tree:
On x86_64:
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Data-Dump-Streamer-2.38-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Thu, 17 Sep 2015 11:07:37 +0300
Alexander Todorov  wrote:

> Can somebody comment on the -fstack-protector-all vs
> -fstack-protector-strong issue ? Do we want to change the default for
> %__global_cflags in /usr/lib/rpm/redhat/macros ?

-all is not needed, -strong is the right balance between security and
performance. For example

int add(int a, int b)
{
return a+b;
}

Does that need a stack canary? This is the nature of why some functions
don't get a canary. Whenever knowledge of a stack frame is passed as a
pointer to a function, then -strong will kick in and do a stack check
on return. 

To know if the right thing is being done is hard to script. You really
need to see what flags are passed to each source file being compiled.
You just can't get at that from readelf.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 13:34, Steve Grubb написа:

On Thu, 17 Sep 2015 11:07:37 +0300
Alexander Todorov  wrote:


Can somebody comment on the -fstack-protector-all vs
-fstack-protector-strong issue ? Do we want to change the default for
%__global_cflags in /usr/lib/rpm/redhat/macros ?


-all is not needed, -strong is the right balance between security and
performance. For example

int add(int a, int b)
{
return a+b;
}

Does that need a stack canary? This is the nature of why some functions
don't get a canary. Whenever knowledge of a stack frame is passed as a
pointer to a function, then -strong will kick in and do a stack check
on return.



Hi Steve,
thanks for the explanation.

So it looks like I should ignore stack canary warnings (assuming the package is 
using the default flags). Should this be ignore for both libraries and 
executable binaries or only libraries ? Or the answer is once again, you can't 
tell that easily ?




To know if the right thing is being done is hard to script. You really
need to see what flags are passed to each source file being compiled.
You just can't get at that from readelf.



Is it realistic to request a RFE with this information stored in the compiled 
object and then be read by readelf ? If so I can file bugs in 
bugzilla.redhat.com or upstream .



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Richard W.M. Jones]

On Thu, Sep 17, 2015 at 02:03:51PM +0300, Alexander Todorov wrote:
> На 17.09.2015 в 12:26, Richard W.M. Jones написа:
> >>As far as I can see most of them report "Partial RELRO" which may
> >>well be fixed as you propose below. If not I can easily exclude
> >>them.
> >
> >They're intermediate files used by developers.  They aren't runnable
> >binaries.  I think everything in %{libdir}/ocaml should be ignored.
> >
> 
> 
> I see .o files, .so files and some .cmxs ones. Should all of them be ignored 
> then ?

Yes.  Everything under here is for developers.  The .so files would
only be run under the bytecode interpreter, and Fedora only builds
those for the benefit of developers.

All Fedora-shipped OCaml applications should use native code, and go
in /usr/bin.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Resources for upstream testing?

[Dave Love]

Dave Johansen  writes:

> I've never used docker/vagrant, so I was wondering if there was any
> information on how to get the docker image setup so it can be used. Also,
> is there anything special that needs to be done once it's running? Or do
> the typical commands like "dnf install" and such "just work"?

I don't know about docker.  Fort vagrant it's basically (at least in
Debian for the install stage):

  $  install virtualbox vagrant
[output ...]
  $ mkdir ~/vagrant-rawhide; cd ~/vagrant-rawhide
  $ vagrant init kaorimatz/fedora-rawhide-x86_64
[output ...]
  $ vagrant up
[output ...]
  $ vagrant ssh
  Last login: Sun Dec 21 03:27:18 2014 from gateway
  [vagrant@localhost ~]$ # sudo dnf update, etc., etc.
  [vagrant@localhost ~]$ logout
  $ vagrant halt
  
Subsequently,

  $ cd ~/vagrant-rawhide
  $ vagrant up # bring machine up
  $ vagrant ssh
[do stuff in it and logout]
  $ vagrant halt  # take it down when you've finished with it

~/vagrant-rawhide is an arbitrary directory for the environment, which
is mounted as /vagrant in the VM.  The "box" you get initially is
obviously an old rawhide, so it needs appropriate dnf updates, which
worked in the cases I tried.  Doubtless an update would be useful.

You need enough space for the VM environment, of course, and a rather
recent vagrant if you use virtualbox 5.  I don't think they're in EPEL
-- my RHEL6 one is from the vagrant site, with virtualbox from
virtualbox.org.

See  (hype-me-not).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: rpmbuild - empty RPMS directory

[Dave Love]

arnaud gaboury  writes:

>> Why?  I ask as someone who supports R rpms on HPC systems and knows a
>> bit about relevant libraries and compilers.
>
> Please visit this blog[0] or many other talking about R-benchmark.R.

I don't think this is the place for a lecture on all that's wrong with
that; it's the sort of thing I try to educate users about.

>> If you want to subvert R's BLAS (and other slower versions) with
>> something largely optimal, look at the openblas-compat package under
>> .  [Yes, linear
>> algebra in Fedora is a shambles, with at least one failed attempt to
>> sort it out, but adding Intel stuff will only make things worse, and
>> that package finesses the issue fairly handily.]
>
> I agree than open-blas is a good soultion, but not as fast as the
> Intel BLAS libraries.

So are published, apparently-reproducible, results to the contrary by
OpenBLAS maintainers and others, wrong due to incompetence or
dishonesty?  Likewise for unpublished ones I've made in cases of
interest, and analysis of myths about Intel's code generation.

Anyhow, there's a demonstration that you don't need to rebuild Fedora
rpms to use a different BLAS.

-- 
Stand back I'm going to try SCIENCE  — XKCD

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Broken dependencies: perl-B-Hooks-OP-Check-EntersubForCV

[buildsys]

perl-B-Hooks-OP-Check-EntersubForCV has broken dependencies in the F-23 tree:
On x86_64:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.i686 requires 
libperl.so.5.20
On armhfp:
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-B-Hooks-OP-Check-EntersubForCV-0.09-10.fc22.armv7hl requires 
libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-POE-API-Peek

[buildsys]

perl-POE-API-Peek has broken dependencies in the F-23 tree:
On x86_64:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On i386:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
On armhfp:
1:perl-POE-API-Peek-2.20-8.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.0)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: polymake

[buildsys]

polymake has broken dependencies in the F-23 tree:
On x86_64:
polymake-2.13-22.git20141013.fc23.x86_64 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.x86_64 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
polymake-2.13-22.git20141013.fc23.i686 requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.i686 requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.i686 requires libperl.so.5.20
On armhfp:
polymake-2.13-22.git20141013.fc23.armv7hl requires 
perl(:MODULE_COMPAT_5.20.2)
polymake-2.13-22.git20141013.fc23.armv7hl requires perl = 4:5.20.2
polymake-2.13-22.git20141013.fc23.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-BeginLift

[buildsys]

perl-Devel-BeginLift has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.x86_64 requires 
libperl.so.5.20()(64bit)
On i386:
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-BeginLift-0.001003-9.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Devel-FindRef

[buildsys]

perl-Devel-FindRef has broken dependencies in the F-23 tree:
On x86_64:
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.x86_64 requires libperl.so.5.20()(64bit)
On i386:
perl-Devel-FindRef-1.44-3.fc22.i686 requires perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.i686 requires libperl.so.5.20
On armhfp:
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires 
perl(:MODULE_COMPAT_5.20.0)
perl-Devel-FindRef-1.44-3.fc22.armv7hl requires libperl.so.5.20
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Method-Signatures

[buildsys]

perl-Method-Signatures has broken dependencies in the F-23 tree:
On x86_64:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On i386:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
On armhfp:
perl-Method-Signatures-20141021-1.fc22.noarch requires 
perl(:MODULE_COMPAT_5.20.1)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Wed, 16 Sep 2015 19:24:02 +0300
Alexander Todorov  wrote:

> Including fedora-devel on this topic.
> 
> На 12.09.2015 в 08:48, Dominik 'Rathann' Mierzejewski написа:
> >>>
> >>> Question is how to deal with these because they appear to be in
> >>> the hundreds ?
> >>
> >> How many, exactly? We have around 2 SRPMs in the distribution.
> >
> 
>  From today's Rawhide snapshot my script counted around 4500
> offending packages. You can find links to the script and execution
> log here:
> http://atodorov.org/blog/2015/09/16/4000-bugs-in-fedora-checksec-failures/
> 
> 
> Please let me know which packages need to genuinely be excluded and
> what should we do with these packages ? Some will probably be fixed
> once they are rebuilt but that may take a while.

I have studied this issue for a long time. You cannot say that a
package must have a stack canary. Its quite possible that no function
is eligible for a stack canary. In good cases, stack-protector-strong
only gives 20 - 30% function coverage. It can actually be lower. I have
hints on this in my devconf speech a couple years ago.

As for FORTIFY_SOURCE, same thing. Gcc may decide that there is no size
information available and therefore cannot have a _check function.
FORTIFY_SOURCE coverage is lower than the stack protector.

Also, the full RELRO thing is a bit oversold. You need it if the
executable is PIE, and that's not needed in the general case. There are
far worse problems that are easy to fix that are not getting attention.
With the RELRO thing, you already have to have an exploit that allows
writing arbitrary memory under attacker control. Most vulnerabilities
just don't have this quality about them.

What is more important is preventing common vulnerabilities from
achieving control over execution with simple heap and stack corruption
bugs. Hopefully we can start addressing this in F24.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 12:26, Richard W.M. Jones написа:

As far as I can see most of them report "Partial RELRO" which may
well be fixed as you propose below. If not I can easily exclude
them.


They're intermediate files used by developers.  They aren't runnable
binaries.  I think everything in %{libdir}/ocaml should be ignored.




I see .o files, .so files and some .cmxs ones. Should all of them be ignored 
then ?

Looking at other replies on this thread it may even be better to focus only on 
executable binaries and as Steve Grubb says this also may not be a big deal 
after all.



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 06:28, Jerry James написа:

On Wed, Sep 16, 2015 at 10:24 AM, Alexander Todorov  wrote:

Please let me know which packages need to genuinely be excluded and what
should we do with these packages ? Some will probably be fixed once they are
rebuilt but that may take a while.


Some language environments provide their own memory managers that
don't take kindly to address randomization, such as:
- gcl
- polyml
- xemacs


Hi Jerry,
how about other offenses like "No PIE" or "No canary found" ?

xemacs and polyml appear to have files with both good and bad values.


--
Alex




--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Richard W.M. Jones]

On Thu, Sep 17, 2015 at 11:27:36AM +0300, Alexander Todorov wrote:
> На 16.09.2015 в 22:59, Richard W.M. Jones написа:
> >The majority of the packages of mine on this list fall into
> >three groups:
> >
> >  - erlang packages
> >
> >  - mingw packages
> >
> >  - ocaml packages
> >
> >I'm pretty sure mingw packages should all be excluded.  Who knows what
> >Windows uses (and who cares).
> >
> 
> Hi Richard,
> please correct me if I'm wrong but aren't these mingw* packages
> supposed to facilitate development of Windows applications on Linux
> ? IOW they are supposed to be working on Linux. As such I'd say they
> should also be hardened, but this is probably a low priority item.

Actually yes that's correct.  For some reason I thought it was looking
at the Windows DLLs, but it's looking at the native Linux binaries.

> >For OCaml, I think you should ignore anything under %{libdir}/ocaml/
> >since those are development files.  (Their contents may eventually end
> >up in a binary, but we can worry about that when we see the binary).
> >That removes most of the failures.
> >
> 
> As far as I can see most of them report "Partial RELRO" which may
> well be fixed as you propose below. If not I can easily exclude
> them.

They're intermediate files used by developers.  They aren't runnable
binaries.  I think everything in %{libdir}/ocaml should be ignored.

> >For OCaml binaries, it seems as if most of them are like this:
> >
> >   Partial RELRO   Canary found   NX enabled  No PIE   No RPATH  No RUNPATH  
> > ./usr/bin/ocamlc.opt
> >
> >As far as I understand it, the only problems there are "Partial RELRO"
> >which should in an ideal world be "Full RELRO"; and "No PIE".
> >
> >I guess we can fix the RELRO problem by linking with -z now.  It may
> >require a compiler patch.
> >
> 
> Please post a link if you file a bug upstream.

Rich.

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

Re: Call for testing: 32-bit AMD CPU owners

[Alexander Ploumistos]

I tested
https://dl.fedoraproject.org/pub/alt/stage/23_Alpha_RC2/Server/i386/iso/Fedora-Server-netinst-i386-23_Alpha.iso
on a dual Athlon MP system and it boots fine to anaconda.

A little bit later I discovered
https://dl.fedoraproject.org/pub/alt/stage/23_Beta_RC1/Server/i386/iso/Fedora-Server-netinst-i386-23_Beta.iso
and tested it as well, same result.

Should I have tried some other image?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 16.09.2015 в 22:59, Richard W.M. Jones написа:

The majority of the packages of mine on this list fall into
three groups:

  - erlang packages

  - mingw packages

  - ocaml packages

I'm pretty sure mingw packages should all be excluded.  Who knows what
Windows uses (and who cares).



Hi Richard,
please correct me if I'm wrong but aren't these mingw* packages supposed to 
facilitate development of Windows applications on Linux ? IOW they are supposed 
to be working on Linux. As such I'd say they should also be hardened, but this 
is probably a low priority item.




Erlang code generation is an unknown quantity.


So I take this we should treat erlang packages as genuine errors until we know 
better.




For OCaml, I think you should ignore anything under %{libdir}/ocaml/
since those are development files.  (Their contents may eventually end
up in a binary, but we can worry about that when we see the binary).
That removes most of the failures.



As far as I can see most of them report "Partial RELRO" which may well be fixed 
as you propose below. If not I can easily exclude them.



For OCaml binaries, it seems as if most of them are like this:

   Partial RELRO   Canary found   NX enabled  No PIE   No RPATH  No RUNPATH  
./usr/bin/ocamlc.opt

As far as I understand it, the only problems there are "Partial RELRO"
which should in an ideal world be "Full RELRO"; and "No PIE".

I guess we can fix the RELRO problem by linking with -z now.  It may
require a compiler patch.



Please post a link if you file a bug upstream.



--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Freeimage 3.10 -> 3.17 upgrade, dealing with library incompatibility

[Sandro Mani]

Hello

I'm looking at updating freeimage from 3.10 to 3.17, also to resolve 
CVE-2015-0852, and I'm wondering how to deal with the following situation:


- The package ships two libraries, libfreeimage (C API) and 
libfreeimageplus (C++ wrapper)
- abi_compliance_checker reports that compatibility was not broken 
between libfreeimage of 3.10 and 3.17. However, in libfreeimageplus, 
various function signatures have changed due to switching from WORD (aka 
unsigned short) to unsigned for various size related parameters. The 
soname was not changed, so this is an upstream error.



So, I see the following options:
- Contact upstream and wait for them to resolve the issue. Could take 
some time
- Patch the C++ API to restore compatibility with 3.10 (i.e. change 
unsigned back to WORD) as a short-term solution, contact upstream and 
notify them about the issue.
- Nothing in Fedora seems to require libfreeimageplus, so just build 
3.17 in rawhide and F23 and have the libfreeimageplus ABI break silently 
sneak in. Probably shouldn't even mention this option.
- Change library versioning from using libfreeimage{plus}.MAJOR to 
libfreeimage-%{version} (i.e. as in libtool -release vs -version-info), 
requiring rebuilds whenever freeimage is updated.


I'm leaning towards the second option. Other opinions?

Thanks,
Sandro

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Freeimage 3.10 -> 3.17 upgrade, dealing with library incompatibility

[Sandro Mani]

On 17.09.2015 10:46, Florian Weimer wrote:

On 09/17/2015 10:28 AM, Sandro Mani wrote:


- abi_compliance_checker reports that compatibility was not broken
between libfreeimage of 3.10 and 3.17. However, in libfreeimageplus,
various function signatures have changed due to switching from WORD (aka
unsigned short) to unsigned for various size related parameters. The
soname was not changed, so this is an upstream error.

Why doesn't abi_compliance_checker report this?  Doesn't such a
modification change the list of exported symbols due to C++ name mangling?

Uh guess didn't express this very clearly: it does not report 
incompatibilities on the libfreeimage library, but it does report them 
on libfreeimageplus library.


(i.e. libfreeimage referring to that actual library, not the entire 
package).

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 06:28, Jerry James написа:

I am baffled as to why some of my packages show up on this list, as
they use %configure or invoke gcc with both $RPM_OPT_FLAGS and
$RPM_LD_FLAGS.  For example, memtailor, which I just built yesterday,
shows as lacking a canary, but it uses the %configure macro.  What is
going on there?



Probably because memtailor builds with -fstack-protector-strong, see previous 
message from Kaleb about this.


--
Alex

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ppisar uploaded Library-CallNumber-LC-0.23.tar.gz for perl-Library-CallNumber-LC

[notifications]

9b077cc9fc75f7142cd3f78ad91bb000  Library-CallNumber-LC-0.23.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Library-CallNumber-LC/Library-CallNumber-LC-0.23.tar.gz/md5/9b077cc9fc75f7142cd3f78ad91bb000/Library-CallNumber-LC-0.23.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

ppisar pushed to perl-Library-CallNumber-LC (master). "0.23 bump"

[notifications]

From fbb4c992a4814777c2271e45151150f2475859ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 17 Sep 2015 14:22:49 +0200
Subject: 0.23 bump


diff --git a/.gitignore b/.gitignore
index 9847497..6fb2490 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Library-CallNumber-LC-0.22.tar.gz
+/Library-CallNumber-LC-0.23.tar.gz
diff --git a/perl-Library-CallNumber-LC.spec b/perl-Library-CallNumber-LC.spec
index 48b2e00..3bf49c6 100644
--- a/perl-Library-CallNumber-LC.spec
+++ b/perl-Library-CallNumber-LC.spec
@@ -1,6 +1,6 @@
 Name:   perl-Library-CallNumber-LC
-Version:0.22
-Release:10%{?dist}
+Version:0.23
+Release:1%{?dist}
 Summary:Normalize Library of Congress call numbers for sorting
 
 Group:  Development/Libraries
@@ -9,12 +9,15 @@ URL:
http://search.cpan.org/dist/Library-CallNumber-LC/
 Source0:
http://search.cpan.org/CPAN/authors/id/D/DB/DBWELLS/Library-CallNumber-LC-%{version}.tar.gz
 
 BuildArch:  noarch
-BuildRequires:  perl(Math::BigInt)
+BuildRequires:  perl
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(strict)
-BuildRequires:  perl(Test::More)
 BuildRequires:  perl(warnings)
-Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+# Run-time:
+BuildRequires:  perl(Math::BigInt)
+# Tests:
+BuildRequires:  perl(Test::More)
+Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
 This module takes Library of Congress (LC) call numbers and normalizes them so
@@ -26,12 +29,11 @@ call numbers.
 %setup -q -n Library-CallNumber-LC-%{version}
 
 %build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
 ./Build
 
 %install
 ./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
 
 %check
 ./Build test
@@ -43,6 +45,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 
2>/dev/null \;
 
 
 %changelog
+* Thu Sep 17 2015 Petr Pisar  - 0.23-1
+- 0.23 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 0.22-10
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 600fd63..40ee822 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b25acaa6354e38b7623e084a1f9ce40a  Library-CallNumber-LC-0.22.tar.gz
+9b077cc9fc75f7142cd3f78ad91bb000  Library-CallNumber-LC-0.23.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Library-CallNumber-LC.git/commit/?h=master=fbb4c992a4814777c2271e45151150f2475859ec
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1230628] Upgrade Lingua-EN-Syllable to 0.28

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|r.landm...@redhat.com   |ppi...@redhat.com



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

[Bug 1230621] Upgrade perl-Library-CallNumber-LC to 0.23

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Library-CallNumber-LC-
   ||0.23-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2015-09-17 08:30:59



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

ppisar uploaded Lingua-EN-Syllable-0.28.tar.gz for perl-Lingua-EN-Syllable

[notifications]

b96c009e8a57e71b5acacf69f58047da  Lingua-EN-Syllable-0.28.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Lingua-EN-Syllable/Lingua-EN-Syllable-0.28.tar.gz/md5/b96c009e8a57e71b5acacf69f58047da/Lingua-EN-Syllable-0.28.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

ppisar pushed to perl-Lingua-EN-Syllable (master). "0.28 bump"

[notifications]

From 760fa7ef13d7e8b67ab5f8821ad15be56e96fde4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 17 Sep 2015 14:39:19 +0200
Subject: 0.28 bump


diff --git a/.gitignore b/.gitignore
index f9f4e7a..87c20a0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /Lingua-EN-Syllable-0.251.tar.gz
+/Lingua-EN-Syllable-0.28.tar.gz
diff --git a/perl-Lingua-EN-Syllable.spec b/perl-Lingua-EN-Syllable.spec
index 27920f0..b2da27e 100644
--- a/perl-Lingua-EN-Syllable.spec
+++ b/perl-Lingua-EN-Syllable.spec
@@ -1,14 +1,25 @@
 Name:   perl-Lingua-EN-Syllable
-Version:0.251
-Release:6%{?dist}
+Epoch:  1
+Version:0.28
+Release:1%{?dist}
 Summary:Routine for estimating syllable count in words
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Lingua-EN-Syllable/
-Source0:
http://www.cpan.org/authors/id/G/GR/GREGFAST/Lingua-EN-Syllable-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/N/NE/NEILB/Lingua-EN-Syllable-%{version}.tar.gz
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildArch:  noarch
+BuildRequires:  coreutils
+BuildRequires:  findutils
+BuildRequires:  make
+BuildRequires:  perl
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+# Run-time:
+BuildRequires:  perl(Exporter)
+# Tests:
+BuildRequires:  perl(Test::More) >= 0.88
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
@@ -35,12 +46,15 @@ make test
 rm -rf $RPM_BUILD_ROOT
 
 %files
-%defattr(-,root,root,-)
-%doc README
+%license LICENSE
+%doc Changes README
 %{perl_vendorlib}/*
 %{_mandir}/man3/*
 
 %changelog
+* Thu Sep 17 2015 Petr Pisar  - 1:0.28-1
+- 0.28 bump
+
 * Thu Jun 18 2015 Fedora Release Engineering  
- 0.251-6
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
 
diff --git a/sources b/sources
index 3b635ad..c21bdd2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f44a056e92c1d9df89e190591879d84f  Lingua-EN-Syllable-0.251.tar.gz
+b96c009e8a57e71b5acacf69f58047da  Lingua-EN-Syllable-0.28.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Lingua-EN-Syllable.git/commit/?h=master=760fa7ef13d7e8b67ab5f8821ad15be56e96fde4
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1230641] Upgrade perl-Lucy to 0.4.2

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|lkund...@v3.sk  |ppi...@redhat.com



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

[Bug 1230628] Upgrade Lingua-EN-Syllable to 0.28

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Lingua-EN-Syllable-0.2
   ||8-1.fc24
 Resolution|--- |RAWHIDE
Last Closed||2015-09-17 08:44:39



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

Why packages sources are NOT mirrored?

[Marcin Juszkiewicz]

My traceroute  [v0.85]
puchatek (0.0.0.0)Thu Sep 17 14:42:22 2015
Keys:  Help   Display mode   Restart statistics   Order of fields quit
 Packets   Pings
 Host   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. krzys.lan0.0%160.3   0.3   0.3   0.3   0.0
 2. 192.168.0.1  0.0%160.6   0.6   0.5   0.8   0.0
 3. ???
 4. 89-75-11-97.infra.chell  0.0%168.5   9.7   7.3  16.4   2.1
 5. 84.116.252.162   0.0%16  224.2 220.9 218.1 227.2   2.4
 6. 84.116.252.174   0.0%16  219.6 220.3 218.3 226.8   1.9
 7. 84.116.252.9 0.0%15  223.8 221.4 219.9 225.0   1.5
 8. 84.116.252.410.0%15  230.5 221.8 219.6 230.5   2.7
 9. 84.116.136.141  71.4%15   44.0  42.3  40.7  44.0   1.3
10. 84-116-130-130.aorta.ne  0.0%15  222.2 220.3 218.2 227.9   2.3
11. ch-zrh02a-ra1-xe-2-1-0.  0.0%15  224.3 229.6 219.6 251.9  11.2
12. 84-116-130-125.aorta.ne 85.7%15   42.3  41.5  40.8  42.3   1.0
13. 84-116-130-122.aorta.ne  0.0%15  148.2 149.9 145.4 177.0   8.2
14. 84.116.133.158   0.0%15  222.7 220.7 219.5 222.7   0.7
15. mpr1.sjc7.us 0.0%15  222.5 223.3 219.4 253.3   8.5
16. ae9.cr1.sjc2.us.zip.zay  0.0%15  249.4 225.0 218.8 249.4   9.7
17. v11.ae29.cr1.lax112.us.  0.0%15  232.1 231.2 228.1 240.9   3.1
18. ae7.mpr3.phx2.us.zip.za  0.0%15  242.7 239.8 236.5 249.9   3.5
19. 208.184.108.38.IPYX-072  0.0%15  223.8 222.8 221.5 226.2   1.1
20. border1.po1-bbnet1.phx0  0.0%15  221.7 222.2 220.7 226.0   1.3
21. redhat-2.border1.phx004  0.0%15  226.7 224.8 222.0 238.2   3.9
22. tx-160-181-132-209.redh  0.0%15  222.4 222.7 221.4 227.2   1.4
23. pkgs.fedoraproject.org   0.0%15  232.3 225.3 222.6 232.3   2.7

This is my connection to pkgs.fedoraproject.org machine. Fetching 48MB 
archive reached 36% in 2 (two) hours...


We ship binaries through mirrors all around the world. yum/dnf knows how 
to use them to get packages in a quick way. Knows how to handle lack of 
connection etc.


But sources used to build packages came from one place. ONE...

Why? Why we are not have them mirrored?

Or if we have then which magic option I did not managed to find yet?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Ben Boeckel]

On Thu, Sep 17, 2015 at 10:57:28 +0300, Alexander Todorov wrote:
> FYI:
> https://bugzilla.redhat.com/show_bug.cgi?id=1263957

Thanks.

> > [1]http://www.cmake.org/cmake/help/v3.3/prop_tgt/POSITION_INDEPENDENT_CODE.html
> 
> Ben,
> is there any way this CMake property be turned on globally ?

When a target is made, the POSITION_INDEPENDENT_CODE property is set to
the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden
manually. Anything that turns it or the property off explicitly will
have to be patched. Or do you mean more globally than "this one CMake
build"?

--Ben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[Kevin Fenzi]

On Thu, 17 Sep 2015 14:46:33 +0200
Marcin Juszkiewicz  wrote:

...snip...

> This is my connection to pkgs.fedoraproject.org machine. Fetching
> 48MB archive reached 36% in 2 (two) hours...
> 
> We ship binaries through mirrors all around the world. yum/dnf knows
> how to use them to get packages in a quick way. Knows how to handle
> lack of connection etc.
> 
> But sources used to build packages came from one place. ONE...
> 
> Why? Why we are not have them mirrored?

Very few people download sources directly from our lookaside cache, and
I am not sure mirrors would see much advantage in mirroring that for
little use. 

> Or if we have then which magic option I did not managed to find yet?

You can get the source from the src.rpm which is mirrored?

kevin


pgpRrsRlyt0vR.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Alexander Todorov]

На 17.09.2015 в 16:24, Ben Boeckel написа:


Ben,
is there any way this CMake property be turned on globally ?


When a target is made, the POSITION_INDEPENDENT_CODE property is set to
the value of CMAKE_POSITION_INDEPENDENT_CODE and may then be overridden
manually. Anything that turns it or the property off explicitly will
have to be patched. Or do you mean more globally than "this one CMake
build"?



I meant turning it on globally as in "everything built with CMake in Fedora", 
like updating the default flags in a RPM macro or updating the default CMake 
config in Fedora. Which will change all the packages using CMake once they are 
rebuilt.


--
Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: request for more visible KDE netinstall

[Matthew Miller]

On Thu, Sep 17, 2015 at 02:03:16AM +0100, Sérgio Basto wrote:
> > This came in in Bugzilla filed against the
> > fedora-productimg-workstation, which isn't the right place for it, so
> > I'm passing it on: https://bugzilla.redhat.com/show_bug.cgi?id=1263565
> Well , after some analyze the bug report is not about KDE netinstall but
> netinstall is general (which could help on KDE installs). Paraphrasing
> the report :


But, it's really that the netinstall is hard to find from the KDE page.
It's reasonably easy to find if you know what to look for on 
.

-- 
Matthew Miller

Fedora Project Leader
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Problem with build system?

[Kevin Fenzi]

On Wed, 16 Sep 2015 21:34:59 -0700
Susi Lehtola  wrote:

> Hi all,
> 
> 
> I was just trying to build QMsgBox-0-6.20130830git94677dc, but the
> build fails on all distros. The difference to the earlier release is
> that I put in a qt5 build, and split the headers to a separate
> subpackage.
> 
> The packages build successfully, but crash in the postprocessing
> stage:
> 
> BuildError: mismatch when analyzing 
> QMsgBox-headers-0-6.20130830git94677dc.fc22.noarch.rpm, rpmdiff
> output was: error: cannot open Packages index using db5 - Permission
> denied (13) error: cannot open Packages database in /var/lib/rpm
> error: cannot open Packages database in /var/lib/rpm
> removed REQUIRES QMsgBox(armv7hl-32) = 0-6.20130830git94677dc.fc22
> added   REQUIRES QMsgBox(x86-64) = 0-6.20130830git94677dc.fc22
> 
> Is the build system ill?

No. 

Your headers subpackage is different on x86_64 and armv7. Koji builds
noarch subpackages on all arches and checks if they are the same. If
they are not, it's an error. 

You are going to need to redo your headers subpackage so it's the same
on all arches, or make it archfull.  

kevin


pgpzF46gOfnRd.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

No agenda for Env-and-Stacks WG meeting -> no meeting? (2015-09-17)

[Honza Horak]

WG meeting should be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 
2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode.


However, there is no agenda proposed.. If there is something we should 
cover on the meeting, let me know asap... otherwise we can skip this week.


Honza
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ppisar uploaded Lucy-0.4.2.tar.gz for perl-Lucy

[notifications]

0aea7e386e987548b720467aeb862b61  Lucy-0.4.2.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Lucy/Lucy-0.4.2.tar.gz/md5/0aea7e386e987548b720467aeb862b61/Lucy-0.4.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 1230641] Upgrade perl-Lucy to 0.4.2

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
This requires not yet packaged Clownfish.

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

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Ben Boeckel]

On Thu, Sep 17, 2015 at 16:45:46 +0300, Alexander Todorov wrote:
> I meant turning it on globally as in "everything built with CMake in Fedora", 
> like updating the default flags in a RPM macro or updating the default CMake 
> config in Fedora. Which will change all the packages using CMake once they 
> are 
> rebuilt.

Sorry, my first email may have been too subtle. From my first email:

> so adding:
>
>  -DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=ON
>
> to %cmake when hardening is enabled should fix -fPIE missing.

The %cmake macro is defined in macros.cmake which is the CMake version
of %configure. It is part of the cmake package, so a bug there would be
best.

--Ben
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Please review ticket 48266 (3rd): Fractional replication evaluates several times the same CSN

[thierry bordaz]

Thank you Noriko and Simon for your careful reviews.
I modified the fix:

 * create the subentry with 'cn' value 'repl keep alive '
 * slapi_ch_free without cast
 * do the keep alive entry with '(&(objectclass=ldapsubentry)(cn=%s
   %d))', in previous fix I forgot '%d'

I modified the test case following the recommended modifications

https://fedorahosted.org/389/ticket/48266

https://fedorahosted.org/389/attachment/ticket/48266/0001-Ticket-48266-3-Fractional-replication-evaluates-severa.patch

https://fedorahosted.org/389/attachment/ticket/48266/0001-Ticket-48266-2-test-case.patch
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Adam Jackson]

On Thu, 2015-09-17 at 12:00 +0100, Steve Grubb wrote:

> Also, the full RELRO thing is a bit oversold. You need it if the
> executable is PIE, and that's not needed in the general case. There are
> far worse problems that are easy to fix that are not getting attention.
> With the RELRO thing, you already have to have an exploit that allows
> writing arbitrary memory under attacker control. Most vulnerabilities
> just don't have this quality about them.

Honestly the security benefits are a sideshow to me. Full relro and
eager binding means that C's const keyword actually works. That alone
justifies the effort to me.

> What is more important is preventing common vulnerabilities from
> achieving control over execution with simple heap and stack corruption
> bugs. Hopefully we can start addressing this in F24.

I look forward to your patches.

- ajax
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Problem with build system?

[Susi Lehtola]

On 09/17/2015 08:03 AM, Kevin Fenzi wrote:

On Wed, 16 Sep 2015 21:34:59 -0700
Susi Lehtola  wrote:

BuildError: mismatch when analyzing
QMsgBox-headers-0-6.20130830git94677dc.fc22.noarch.rpm, rpmdiff
output was: error: cannot open Packages index using db5 - Permission
denied (13) error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
removed REQUIRES QMsgBox(armv7hl-32) = 0-6.20130830git94677dc.fc22
added   REQUIRES QMsgBox(x86-64) = 0-6.20130830git94677dc.fc22

Is the build system ill?


No.

Your headers subpackage is different on x86_64 and armv7. Koji builds
noarch subpackages on all arches and checks if they are the same. If
they are not, it's an error.

You are going to need to redo your headers subpackage so it's the same
on all arches, or make it archfull.


Ah, I got distracted by the rpm errors.

The problem was indeed that I had an archful require in the noarch 
headers package. Thanks!

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Call for testing: 32-bit AMD CPU owners

[Adam Williamson]

On Wed, 2015-09-16 at 11:29 -0700, Adam Williamson wrote:
> Hi, folks!

Thanks for all your feedback on this, folks, and sorry for messing up
the links in the original post :)

Thanks to all your work we had sufficient information to determine the
bug does not need to block the Beta release, so we don't need any more
feedback now, thanks very much. The information on upgrade testing and
workarounds was also useful and will be documented in the Common Bugs
page.

Thanks again!
-- 
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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Germano Massullo]

===
Definition of flat-volumes from [1] : it scales the device-volume with
the volume of the "loudest" application. For example, raising the VoIP
call volume will raise the hardware volume and adjust the music-player
volume so it stays where it was, without having to lower the volume of
the music-player manually.
===

Today I had a scary experience with the audio of my computer.
I was listening to music with Amarok, using my headphones... The KMix
volume level was ~ 35%. When I logged into a video conference
application, the volume suddenly reached the 100%. I was shocked, having
the maximum audio level shooted in your ears is a painful experience.
The conference application that triggered PulseAudio pushing volume to
maximum level probably should have never asked the system for a 100%
audio level, but on the other hand, PulseAudio should never allow an
application to make such sudden changes.
To avoid that, you have to set
flat-volumes = no
in /etc/pulse/daemon.conf

I found many users stories complaining about this default setting [2]
[3] [4] and you can easily find other by searching "pulseaudio flat
volumes".
I completely agree with user gaggra comment at [3]

<>

Moreover this default setting can cause sound crackling [5].

So I would like to start a discussion about disabling this default
behaviour for the mentioned reasons.


[1] https://wiki.archlinux.org/index.php/PulseAudio
[2]
https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/
[3]
https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/
[4]
http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[EPEL-devel] pygame-1.9.1-4.el6.x86_64 broken by updates

[Robert Arkiletian]

The latest updates of libX11 and/or SDL seems to have broken pygame.

pygame can no longer be imported into python.

Here is the error message

 File "/usr/lib64/python2.6/site-packages/pygame/__init__.py", line 95, in

from pygame.base import *
ImportError: /usr/lib64/libSDL-1.2.so.0: undefined symbol: _XGetRequest


Can anyone else please confirm this bug.

Thank you
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: Why packages sources are NOT mirrored?

[Stephen John Smoogen]

On Sep 17, 2015 06:46, "Marcin Juszkiewicz"  wrote:
>
> My traceroute  [v0.85]
 This is my connection to pkgs.fedoraproject.org machine. Fetching 48MB
archive reached 36% in 2 (two) hours...
>
> We ship binaries through mirrors all around the world. yum/dnf knows how
to use them to get packages in a quick way. Knows how to handle lack of
connection etc.
>
> But sources used to build packages came from one place. ONE...
>
> Why? Why we are not have them mirrored?
>

I would talk with the mirrors in your area and find out why they don't
mirror it. Mirroring is a volunteer activity and mirrors do what they think
will be useful for users near them.

And to pre-answer something that might be related, there is no budget to
put this into a CDN. Those are extremely expensive operations and do not
volunteer space.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [EPEL-devel] pygame-1.9.1-4.el6.x86_64 broken by updates

[Robert Arkiletian]

On Thu, Sep 17, 2015 at 10:34 AM, Anssi Johansson  wrote:

> 17.9.2015, 20.03, Robert Arkiletian kirjoitti:
>
>>
>> The latest updates of libX11 and/or SDL seems to have broken pygame.
>>
>> pygame can no longer be imported into python.
>>
>> Here is the error message
>>
>>   File "/usr/lib64/python2.6/site-packages/pygame/__init__.py", line 95,
>> in 
>>  from pygame.base import *
>> ImportError: /usr/lib64/libSDL-1.2.so.0: undefined symbol: _XGetRequest
>>
>>
>> Can anyone else please confirm this bug.
>>
>
> As far as I know, Red Hat would need to fix
> https://bugzilla.redhat.com/show_bug.cgi?id=1249970 to get rid of this
> problem.
>
>
Thanks. I didn't know about that bug report. I thought it was odd that a
package should break because of base updates. I will try to downgrade the
SDL package until it's fixed as you mention in the report.

Thanks
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] pygame-1.9.1-4.el6.x86_64 broken by updates

[Anssi Johansson]

17.9.2015, 20.03, Robert Arkiletian kirjoitti:


The latest updates of libX11 and/or SDL seems to have broken pygame.

pygame can no longer be imported into python.

Here is the error message

  File "/usr/lib64/python2.6/site-packages/pygame/__init__.py", line 95,
in 
 from pygame.base import *
ImportError: /usr/lib64/libSDL-1.2.so.0: undefined symbol: _XGetRequest


Can anyone else please confirm this bug.


As far as I know, Red Hat would need to fix 
https://bugzilla.redhat.com/show_bug.cgi?id=1249970 to get rid of this 
problem.


___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Fedora 23 Beta status is GO, release on September 22, 2015

[Jan Kurik]

At the Fedora 23 Beta Go/No-Go Meeting that just ends, was agreed to Go
with the Fedora 23 Beta.
Fedora 23 Beta is considered as GOLD.

Fedora 23 Beta will be publicly available on Tuesday, September 22, 2015.

Meeting details can be seen here:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-17/f23_beta_go_no-go_meeting.2015-09-17-16.00.html
Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-17/f23_beta_go_no-go_meeting.2015-09-17-16.00.log.html

Thanks everyone!

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

Fedora 23 Beta status is GO, release on September 22, 2015

[Jan Kurik]

At the Fedora 23 Beta Go/No-Go Meeting that just ends, was agreed to Go
with the Fedora 23 Beta.
Fedora 23 Beta is considered as GOLD.

Fedora 23 Beta will be publicly available on Tuesday, September 22, 2015.

Meeting details can be seen here:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-17/f23_beta_go_no-go_meeting.2015-09-17-16.00.html
Log:
http://meetbot.fedoraproject.org/fedora-meeting-2/2015-09-17/f23_beta_go_no-go_meeting.2015-09-17-16.00.log.html

Thanks everyone!

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list
devel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[Kevin Fenzi]

On Thu, 17 Sep 2015 16:36:52 -0400
DJ Delorie  wrote:

> 
> Stephen John Smoogen  writes:
> > I would talk with the mirrors in your area and find out why they
> > don't mirror it.
> 
> Do mirror sites have the option to not include sources? [*]

The pkgs.fedoraproject.org lookaside cache? 
(Which is what this thread was about)
No, because we don't offer it for mirroring currently.

If you mean SRPMS, then yes, they can choose to mirror some or none of
those.

> If so, does letting them have this choice have GPL implications?  I
> mean, if they're distributing binaries without making the sources
> available via the same site...  (and one of the arguments for that
> clause of the GPL was "the user may not be able to access the part of
> the internet where you put the sources" - which seems to be the case
> here)

IANAL, but no. 

kevin


pgpwp5hxsBeb6.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Andrew Lutomirski]

On Thu, Sep 17, 2015 at 11:59 AM, Germano Massullo
 wrote:
>
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix volume
> level was ~ 35%. When I logged into a video conference application, the
> volume suddenly reached the 100%. I was shocked, having the maximum audio
> level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100% audio
> level, but on the other hand, PulseAudio should never allow an application
> to make such sudden changes.

To clarify: did you get blasted by music or by video conference
sounds?  If the music volume got louder, then it sounds like either a
straight-up bug in PulseAudio (and a severe and dangerous one at that)
or a serious bug in your video conference volume in which it adjusts
the volume of streams other than its own.

If you got blasted by video conference sounds, then I'd say it's a
serious design flaw in PulseAudio.  PulseAudio should offer an
easy-to-configure maximum volume (probably A-weighted power, but peak
level works, too, if considerably less well) on a per-output basis
with which to protect your ears.

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Rawhide 20150917 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not Rawhide 20150916:

Cloud base Vagrant x86_64
Cloud atomic Disk x86_64
Cloud base Disk i386
Cloud atomic Vagrant x86_64
Cloud base Disk x86_64

No images in Rawhide 20150916 but not this.

Failed openQA tests: 51 of 52

ID: 2859Test: i386 universal server_software_raid
ID: 2858Test: x86_64 universal server_software_raid
ID: 2855Test: x86_64 universal server_software_raid
ID: 2844Test: i386 kde_live default_install
ID: 2838Test: i386 workstation_live default_install
ID: 2837Test: x86_64 workstation_live default_install
ID: 2836Test: x86_64 workstation_live default_install
ID: 2835Test: x86_64 kde_live default_install
ID: 2834Test: i386 generic_boot default_install
ID: 2833Test: x86_64 generic_boot default_install
ID: 2832Test: x86_64 generic_boot default_install
ID: 2831Test: i386 universal upgrade_desktop_32bit
ID: 2830Test: i386 universal server_lvmthin
ID: 2829Test: i386 universal server_ext3
ID: 2828Test: i386 universal server_btrfs
ID: 2826Test: i386 universal server_simple_encrypted
ID: 2825Test: i386 universal server_repository_http_graphical
ID: 2824Test: i386 universal server_scsi_updates_img
ID: 2823Test: i386 universal package_set_minimal
ID: 2822Test: x86_64 universal server_no_swap
ID: 2821Test: x86_64 universal server_lvmthin
ID: 2820Test: x86_64 universal server_ext3
ID: 2819Test: x86_64 universal server_btrfs
ID: 2817Test: x86_64 universal server_multi_empty
ID: 2816Test: x86_64 universal server_simple_free_space
ID: 2815Test: x86_64 universal server_simple_encrypted
ID: 2814Test: x86_64 universal server_delete_partial
ID: 2813Test: x86_64 universal server_delete_pata
ID: 2812Test: x86_64 universal server_sata_multi
ID: 2811Test: x86_64 universal european_language_install
ID: 2810Test: x86_64 universal server_shrink_ntfs
ID: 2809Test: x86_64 universal server_shrink_ext4
ID: 2808Test: x86_64 universal server_updates_img_local
ID: 2807Test: x86_64 universal upgrade_desktop_64bit
ID: 2806Test: x86_64 universal upgrade_minimal_64bit
ID: 2805Test: x86_64 universal server_kickstart_hdd
ID: 2804Test: x86_64 universal server_no_swap
ID: 2803Test: x86_64 universal server_lvmthin
ID: 2802Test: x86_64 universal server_ext3
ID: 2801Test: x86_64 universal server_btrfs
ID: 2799Test: x86_64 universal server_multi_empty
ID: 2798Test: x86_64 universal server_simple_free_space
ID: 2797Test: x86_64 universal server_simple_encrypted
ID: 2796Test: x86_64 universal server_delete_partial
ID: 2795Test: x86_64 universal server_repository_http_variation
ID: 2794Test: x86_64 universal server_repository_http_graphical
ID: 2793Test: x86_64 universal server_mirrorlist_graphical
ID: 2792Test: x86_64 universal server_delete_pata
ID: 2790Test: x86_64 universal server_scsi_updates_img
ID: 2789Test: x86_64 universal server_sata_multi
ID: 2788Test: x86_64 universal package_set_minimal

Passed openQA tests: 1 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[DJ Delorie]

Stephen John Smoogen  writes:
> I would talk with the mirrors in your area and find out why they don't
> mirror it.

Do mirror sites have the option to not include sources? [*]

If so, does letting them have this choice have GPL implications?  I
mean, if they're distributing binaries without making the sources
available via the same site...  (and one of the arguments for that
clause of the GPL was "the user may not be able to access the part of
the internet where you put the sources" - which seems to be the case
here)


[*] granted, they can mirror whatever they want, but I mean, in order to
be listed as an official Fedora mirror and participate in the yum
update network...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Please review ticket 48266 (4th): Fractional replication evaluates several times the same CSN

[thierry bordaz]

Thanks to Noriko who ran coverity tests the previous fix was invalid.
Changing the call slapi_ch_free into slapi_ch_free_string.

https://fedorahosted.org/389/attachment/ticket/48266/0001-Ticket-48266-4-Fractional-replication-evaluates-severa.patch 

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Fedora 23 Branched 20150917 compose check report

[Fedora compose checker]

No missing expected images.

Images in this compose but not 23 Branched 20150916:

Cloud base Vagrant x86_64
Docker Filesystem x86_64
Cloud base Disk i386
Cloud atomic Vagrant x86_64
Cloud atomic Disk x86_64

No images in 23 Branched 20150916 but not this.

Failed openQA tests: 8 of 52

ID: 2852Test: x86_64 kde_live default_install
ID: 2849Test: i386 kde_live default_install
ID: 2845Test: x86_64 universal server_delete_pata
ID: 2779Test: i386 universal upgrade_desktop_32bit
ID: 2764Test: x86_64 universal server_simple_free_space
ID: 2762Test: x86_64 universal server_delete_partial
ID: 2754Test: x86_64 universal upgrade_minimal_64bit
ID: 2749Test: x86_64 universal server_btrfs

Passed openQA tests: 44 of 52
-- 
Mail generated by check-compose:
https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Major Hayden]

On 09/17/2015 01:59 PM, Germano Massullo wrote:
> I found many users stories complaining about this default setting [2] [3] [4] 
> and you can easily find other by searching "pulseaudio flat volumes".
> I completely agree with user gaggra comment at [3]
> 
> < misbehaving software can /physically hurt you/. You would think that once 
> that was understood, the design of this sort of behaviour would be treated in 
> a very conservative, careful manner.>>
> 
> Moreover this default setting can cause sound crackling [5].

I've experienced the crackling and deafening sounds as well (as referenced in 
my blog post).  I've have zero issues for months after setting flat-volumes to 
'no'.

What are the negative aspects of setting flat-volumes = no?

--
Major Hayden
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Germano Massullo]

Il 17/09/2015 21:13, Andrew Lutomirski ha scritto:
>
> To clarify: did you get blasted by music or by video conference
> sounds?  If the music volume got louder, then it sounds like either a
> straight-up bug in PulseAudio (and a severe and dangerous one at that)
> or a serious bug in your video conference volume in which it adjusts
> the volume of streams other than its own.
>
> If you got blasted by video conference sounds, then I'd say it's a
> serious design flaw in PulseAudio.  PulseAudio should offer an
> easy-to-configure maximum volume (probably A-weighted power, but peak
> level works, too, if considerably less well) on a per-output basis
> with which to protect your ears.
>
> --Andy
I got blasted from the music because I was not making a conference, I
only logged into the software, so the music was the only sound I was
listening to. PulseAudio pushed the master audio level to 100%
(therefore all applications audio level changed to 100%, due flat-volume
setting).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[Marcin Juszkiewicz]

W dniu 17.09.2015 o 22:42, Kevin Fenzi pisze:

> >I would talk with the mirrors in your area and find out why they
> >don't mirror it.

>
>Do mirror sites have the option to not include sources? [*]



The pkgs.fedoraproject.org lookaside cache?
(Which is what this thread was about)
No, because we don't offer it for mirroring currently.


Ok, for next time when I will have that issue I will forget about 
'fedpkg sources' and will fetch srpm, extract it and then build local 
srpm for hacking package for local build.


It would be nice to have an option/fallback in fedpkg to do it 
automatically but it is not so often needed.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
I can second this. Currently we do this in sonar on versions after
2015.3, which have to be built atm. There are two applications off the
top of my head I know of that will currently do this. They are, kodi
media center, and qemu virtualization software, if you emulate a sound
card of anything other than es1370. I'll add your voip application to
this list, though I don't know what it's called. To disable flat
volumes, edit /etc/pulse/daemon.conf, and change the "flat volumes" line
from yes to no, and remove the semicolon, which is the comment. Then
restart pulseaudio, either by killing pulseaudio, causing it to respawn
or restart your computer.
I'm not sure what should be done to prevent this. Usually, the only
applications that do this are applications that are not pulse audio
aware. Applications that are use the pulse audio API, and thus don't
jump the volume. I completely agree, this requires a change to pulse
audio, but I've had no luck contacting the pulse audio devs. I go onto
their irc channel, and there's literally no response to queries.
Thanks
Kendell clark


On 09/17/2015 01:59 PM, Germano Massullo wrote:
> ===
> Definition of flat-volumes from [1] : it scales the device-volume with
> the volume of the "loudest" application. For example, raising the VoIP
> call volume will raise the hardware volume and adjust the music-player
> volume so it stays where it was, without having to lower the volume of
> the music-player manually.
> ===
> 
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix
> volume level was ~ 35%. When I logged into a video conference
> application, the volume suddenly reached the 100%. I was shocked, having
> the maximum audio level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100%
> audio level, but on the other hand, PulseAudio should never allow an
> application to make such sudden changes.
> To avoid that, you have to set
> flat-volumes = no
> in /etc/pulse/daemon.conf
> 
> I found many users stories complaining about this default setting [2]
> [3] [4] and you can easily find other by searching "pulseaudio flat
> volumes".
> I completely agree with user gaggra comment at [3]
> 
> < misbehaving software can /physically hurt you/. You would think that
> once that was understood, the design of this sort of behaviour would be
> treated in a very conservative, careful manner.>>
> 
> Moreover this default setting can cause sound crackling [5].
> 
> So I would like to start a discussion about disabling this default
> behaviour for the mentioned reasons.
> 
> 
> [1] https://wiki.archlinux.org/index.php/PulseAudio
> [2]
> https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/
> [3]
> https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/
> [4]
> http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Thomas Daede]

I also absolutely hate flat-volumes. Often I have trouble getting an
application loud enough, and discover that it's too low in the mixer.
The idea of flat volumes is to avoid a global volume, but the way it
interacts is super confusing and unlike any other system people use
(except maybe Android, but all of its "content" apps are still coalesced
under one mixer).

That said, apps shouldn't be setting their own Pulseaudio volume in
general. Firefox did that for a while and ran into a similar bug as you
got with Amarok, so they implemented their own internal soft volume
rather than adjusting their Pulseaudio volume.

That said, flat-volume is the upstream default so we might want their
input, as well as looking at what other distros do.

On 09/17/2015 11:59 AM, Germano Massullo wrote:
> ===
> Definition of flat-volumes from [1] : it scales the device-volume with
> the volume of the "loudest" application. For example, raising the VoIP
> call volume will raise the hardware volume and adjust the music-player
> volume so it stays where it was, without having to lower the volume of
> the music-player manually.
> ===
> 
> Today I had a scary experience with the audio of my computer.
> I was listening to music with Amarok, using my headphones... The KMix
> volume level was ~ 35%. When I logged into a video conference
> application, the volume suddenly reached the 100%. I was shocked, having
> the maximum audio level shooted in your ears is a painful experience.
> The conference application that triggered PulseAudio pushing volume to
> maximum level probably should have never asked the system for a 100%
> audio level, but on the other hand, PulseAudio should never allow an
> application to make such sudden changes.
> To avoid that, you have to set
> flat-volumes = no
> in /etc/pulse/daemon.conf
> 
> I found many users stories complaining about this default setting [2]
> [3] [4] and you can easily find other by searching "pulseaudio flat
> volumes".
> I completely agree with user gaggra comment at [3]
> 
> < misbehaving software can /physically hurt you/. You would think that
> once that was understood, the design of this sort of behaviour would be
> treated in a very conservative, careful manner.>>
> 
> Moreover this default setting can cause sound crackling [5].
> 
> So I would like to start a discussion about disabling this default
> behaviour for the mentioned reasons.
> 
> 
> [1] https://wiki.archlinux.org/index.php/PulseAudio
> [2]
> https://major.io/2015/06/08/pulseaudio-popping-with-multiple-sounds-in-fedora-22/
> [3]
> https://www.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/
> [4]
> http://awesomelinux.blogspot.it/2013/06/pulseaudios-dynamic-volume-levels-are.html
> [5] https://bugzilla.redhat.com/show_bug.cgi?id=1264177
> 
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Why packages sources are NOT mirrored?

[Florian Weimer]

On 09/17/2015 07:26 PM, Stephen John Smoogen wrote:

> And to pre-answer something that might be related, there is no budget to
> put this into a CDN. Those are extremely expensive operations and do not
> volunteer space.

Some of them do, for Debian at least.  But I don't know what has
happened to early attempts in that direction, lack of IPv6 support was a
bit of a dealbreaker back then.

The problem I see is that CDNs are only work well if you use popular
resources because unlikely mirrors, local nodes are not preseeded with
content almost no one ever downloads.  So getting a SRPM or source
tarball from a CDN will likely trigger a local cache miss and a sluggish
CDN-internal download.

For my needs and my network location, the Fedora (and CentOS and Debian)
mirror infrastructure offers significantly better performance than
cdn.redhat.com.

-- 
Florian Weimer / Red Hat Product Security
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

wfp pushed to perl-Net-HL7 (master). "Initial import (#1243506)"

[notifications]

From b8cffed96cc37dea19536d55d537734fdedfefa7 Mon Sep 17 00:00:00 2001
From: Bill Pemberton 
Date: Thu, 17 Sep 2015 20:53:25 -0400
Subject: Initial import (#1243506)


diff --git a/.gitignore b/.gitignore
index e69de29..56fa859 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-HL7-0.81.tar.gz
diff --git a/perl-Net-HL7.spec b/perl-Net-HL7.spec
new file mode 100644
index 000..cbb70a8
--- /dev/null
+++ b/perl-Net-HL7.spec
@@ -0,0 +1,70 @@
+Name:  perl-Net-HL7
+Version:   0.81
+Release:   2%{?dist}
+Summary:   Simple perl API for HL7 messages
+License:   Beerware and (GPL+ or Artistic)
+Group: Development/Libraries
+URL:   http://search.cpan.org/dist/Net-HL7/
+Source0:   
http://www.cpan.org/authors/id/D/DD/DDOKTER/Net-HL7-%{version}.tar.gz
+
+BuildArch: noarch
+
+BuildRequires: perl
+BuildRequires: perl(base)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: perl(Config)
+BuildRequires: perl(Errno)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(IO::Socket)
+BuildRequires: perl(IO::Socket::INET)
+BuildRequires: perl(IO::Socket::Timeout)
+BuildRequires: perl(Sys::Hostname)
+BuildRequires: perl(Test::More)
+BuildRequires: findutils
+BuildRequires: make
+BuildRequires: coreutils
+
+Requires:  perl(Sys::Hostname)
+Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+The Net-HL7 package is a simple Perl API for creating, parsing, sending and
+receiving HL7 messages.
+
+%prep
+%setup -q -n Net-HL7-%{version}
+find . -type f -executable -exec chmod -x {} \;
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -delete
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc CHANGES README
+%if 0%{?_licensedir:1}
+%license LICENSE
+%else
+%doc LICENSE
+%endif
+%{perl_vendorlib}/*
+%{_mandir}/man3/Net::HL7*.3pm*
+
+%changelog
+* Thu Sep 17 2015 Bill Pemberton  - 0.81-2
+- update the BuildRequires
+- update the files section to get everything
+
+* Thu Sep 17 2015 Bill Pemberton  - 0.81-1
+- Initial version
diff --git a/sources b/sources
index e69de29..ac9502a 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+190c40279520093a4a76be7c1e7fdf02  Net-HL7-0.81.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Net-HL7.git/commit/?h=master=b8cffed96cc37dea19536d55d537734fdedfefa7
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

wfp uploaded Net-HL7-0.81.tar.gz for perl-Net-HL7

[notifications]

190c40279520093a4a76be7c1e7fdf02  Net-HL7-0.81.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Net-HL7/Net-HL7-0.81.tar.gz/md5/190c40279520093a4a76be7c1e7fdf02/Net-HL7-0.81.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

wfp pushed to perl-Net-HL7 (f23). "Initial import (#1243506)"

[notifications]

From b8cffed96cc37dea19536d55d537734fdedfefa7 Mon Sep 17 00:00:00 2001
From: Bill Pemberton 
Date: Thu, 17 Sep 2015 20:53:25 -0400
Subject: Initial import (#1243506)


diff --git a/.gitignore b/.gitignore
index e69de29..56fa859 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-HL7-0.81.tar.gz
diff --git a/perl-Net-HL7.spec b/perl-Net-HL7.spec
new file mode 100644
index 000..cbb70a8
--- /dev/null
+++ b/perl-Net-HL7.spec
@@ -0,0 +1,70 @@
+Name:  perl-Net-HL7
+Version:   0.81
+Release:   2%{?dist}
+Summary:   Simple perl API for HL7 messages
+License:   Beerware and (GPL+ or Artistic)
+Group: Development/Libraries
+URL:   http://search.cpan.org/dist/Net-HL7/
+Source0:   
http://www.cpan.org/authors/id/D/DD/DDOKTER/Net-HL7-%{version}.tar.gz
+
+BuildArch: noarch
+
+BuildRequires: perl
+BuildRequires: perl(base)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: perl(Config)
+BuildRequires: perl(Errno)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(IO::Socket)
+BuildRequires: perl(IO::Socket::INET)
+BuildRequires: perl(IO::Socket::Timeout)
+BuildRequires: perl(Sys::Hostname)
+BuildRequires: perl(Test::More)
+BuildRequires: findutils
+BuildRequires: make
+BuildRequires: coreutils
+
+Requires:  perl(Sys::Hostname)
+Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+The Net-HL7 package is a simple Perl API for creating, parsing, sending and
+receiving HL7 messages.
+
+%prep
+%setup -q -n Net-HL7-%{version}
+find . -type f -executable -exec chmod -x {} \;
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -delete
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc CHANGES README
+%if 0%{?_licensedir:1}
+%license LICENSE
+%else
+%doc LICENSE
+%endif
+%{perl_vendorlib}/*
+%{_mandir}/man3/Net::HL7*.3pm*
+
+%changelog
+* Thu Sep 17 2015 Bill Pemberton  - 0.81-2
+- update the BuildRequires
+- update the files section to get everything
+
+* Thu Sep 17 2015 Bill Pemberton  - 0.81-1
+- Initial version
diff --git a/sources b/sources
index e69de29..ac9502a 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+190c40279520093a4a76be7c1e7fdf02  Net-HL7-0.81.tar.gz
-- 
cgit v0.10.2



http://pkgs.fedoraproject.org/cgit/perl-Net-HL7.git/commit/?h=f23=b8cffed96cc37dea19536d55d537734fdedfefa7
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[Michael Catanzaro]

On Thu, 2015-09-17 at 15:33 -0700, Thomas Daede wrote:
> That said, flat-volume is the upstream default so we might want their
> input, as well as looking at what other distros do.

Ubuntu disables it. To the best of my knowledge, all other distros
stick with the upstream default.

I am in favor of disabling. It can be extremely frustrating when apps
are misbehaving.

Michael
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
The only negative issue, although to me it's more of an oh, that's right
moment, is that you can no longer adjust application volumes up beyond
the master volume, only down, but that's kind of the idea. I do suggest,
and I don't know how easy this would be to do, that sound application
settings, such as gnome's control center, display volumes as percentages
rather than arbitrary numbers. I'm smart enough to know that 65536 is
somewhat equal to sorry, you've reached max, you can't go further, but
to most people, they'll see taht and go huh? Mind you I'm blind, and
there might be a percentage hidden somewhere. This is the case with the
volume slider on the top bar, and I have to use orca's where am I
functionality to read it. I then get output that looks like, volume
slider 0.5 47 percent, as opposed to just volume slider 0.5.
Thanks
Kendell clark


On 09/17/2015 04:30 PM, Major Hayden wrote:
> On 09/17/2015 01:59 PM, Germano Massullo wrote:
>> I found many users stories complaining about this default setting [2] [3] 
>> [4] and you can easily find other by searching "pulseaudio flat volumes".
>> I completely agree with user gaggra comment at [3]
>>
>> <> misbehaving software can /physically hurt you/. You would think that once 
>> that was understood, the design of this sort of behaviour would be treated 
>> in a very conservative, careful manner.>>
>>
>> Moreover this default setting can cause sound crackling [5].
> 
> I've experienced the crackling and deafening sounds as well (as referenced in 
> my blog post).  I've have zero issues for months after setting flat-volumes 
> to 'no'.
> 
> What are the negative aspects of setting flat-volumes = no?
> 
> --
> Major Hayden
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] RFC mass bug reporting: checksec failures

[Steve Grubb]

On Thu, 17 Sep 2015 13:53:38 +0300
Alexander Todorov  wrote:

> На 17.09.2015 в 13:34, Steve Grubb написа:
> > On Thu, 17 Sep 2015 11:07:37 +0300
> > Alexander Todorov  wrote:
> >
> >> Can somebody comment on the -fstack-protector-all vs
> >> -fstack-protector-strong issue ? Do we want to change the default
> >> for %__global_cflags in /usr/lib/rpm/redhat/macros ?
> >
> > -all is not needed, -strong is the right balance between security
> > and performance. For example
> >
> > int add(int a, int b)
> > {
> > return a+b;
> > }
> >
> > Does that need a stack canary? This is the nature of why some
> > functions don't get a canary. Whenever knowledge of a stack frame
> > is passed as a pointer to a function, then -strong will kick in and
> > do a stack check on return.
> >
> 
> Hi Steve,
> thanks for the explanation.
> 
> So it looks like I should ignore stack canary warnings (assuming the
> package is using the default flags). Should this be ignore for both
> libraries and executable binaries or only libraries ? Or the answer
> is once again, you can't tell that easily ?

Not completely. See below.


> > To know if the right thing is being done is hard to script. You
> > really need to see what flags are passed to each source file being
> > compiled. You just can't get at that from readelf.
> >
> 
> Is it realistic to request a RFE with this information stored in the
> compiled object and then be read by readelf ? If so I can file bugs
> in bugzilla.redhat.com or upstream .
> 

I think Florian answered this. Indeed, the --debug-dump option does
find these strings, but they are mixed in with other data. I think that
if there is no canary and flags were passed, its not a problem. If the
flags are absent, the build scripts are suspect.

-Steve
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Additional information in email about Koji garbage collection?

[Kevin Fenzi]

On Wed, 16 Sep 2015 12:19:46 -0700
Dave Johansen  wrote:

> Would it be possible to add more information to the emails sent to
> notify about Koji Garbage Collection (
> http://fedoraproject.org/wiki/Koji/GarbageCollection )? 

I would think so yeah. ;) 

Looks like these messages are hard coded into the koji-gc script, which
is part of the koji-utils subpackage of koji. 

https://git.fedorahosted.org/cgit/koji/tree/util/koji-gc

> I receive
> these emails and I usually know why I received them (usually an
> update was obsoleted because of a fix for an issue that was
> identified in the testing repo), but sometimes I receive them and
> have no idea why. Was there a build I did but forgot about? Was it
> because of a rebuild that someone else did? Did I forgot to push an
> update to stable? Is this something I need to look into? It's usually
> possible to track down the "why" but annoying and time consuming to
> do so. So is the "why" available in the system that sends out the
> notification emails? If so, would it be possible for that to be
> included? Thanks,

Not sure. The config we use is at: 

http://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji_hub/files/koji-gc.conf

I'm not sure it knows what rule matched or didn't match when it runs,
but it might be possible to extend it. 

kevin



pgpud7Nzt_TPD.pgp
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Disable PulseAudio flat volumes to prevent it from pushing volume level to max

[kendell clark]

hi
I'll second michael. Although I'll add that this should probably be a
temporary measure. This really should be addressed by pulseaudio
upstream, so that flat volumes can still be used, even with misbehaving
applications. There's currently zero documentation on what causes this,
whic means for me at least it was trial and error.
Thanks
Kendell clark


On 09/17/2015 05:53 PM, Michael Catanzaro wrote:
> On Thu, 2015-09-17 at 15:33 -0700, Thomas Daede wrote:
>> That said, flat-volume is the upstream default so we might want their
>> input, as well as looking at what other distros do.
> 
> Ubuntu disables it. To the best of my knowledge, all other distros
> stick with the upstream default.
> 
> I am in favor of disabling. It can be extremely frustrating when apps
> are misbehaving.
> 
> Michael
> 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

limb changed perl-sig's 'watchcommits' permission on perl-Net-HL7 (f23) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Net-HL7 (f23) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-HL7/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

limb changed perl-sig's 'watchbugzilla' permission on perl-Net-HL7 (f23) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Net-HL7 (f23) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-HL7/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

limb changed perl-sig's 'watchcommits' permission on perl-Net-HL7 (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchcommits' permission on perl-Net-HL7 (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-HL7/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

limb changed perl-sig's 'watchbugzilla' permission on perl-Net-HL7 (master) to 'Approved'

[notifications]

limb changed perl-sig's 'watchbugzilla' permission on perl-Net-HL7 (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-HL7/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel