test

[Philip Kovacs via devel]

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Need package review to unretire fastbit (a C++ lib)

[Philip Kovacs via devel]

I am a little beyond the 8-week window for the "no-hassle" unretire, so I need 
a new review for the fastbit packagethat I retired a few months ago.   It's 
already in the Fedora git tree.  I have it building cleanly again and would 
liketo resurrect it.  I have gone over the review items locally, so it should 
now be in good condition.  
Thanks in advance.  Phil
1750501 – Package Review to unretire fastbit

| 
| 
|  | 
1750501 – Package Review to unretire fastbit


 |

 |

 |



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please fix the aarch64 g++ pic problems in f32 rawhide

[Philip Kovacs via devel]

 >> OK, here's one at least.  I have had to manually add -DPIC to the spec for 
 >> aarch64 in order to get
>> that arch to pass.  There were no problems with it up until recently.
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=37332928

>So I believe this is fixed with the rebuild on annobin so make sure
>you have the latest one of that and you should be OK.
Yep, the annobin update closes the issue for me.   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: aarch64 toolchain regression?

[Philip Kovacs via devel]

 >> Builds that were previously succeeding (e.g. pulseaudio) are now failing on 
>> aarch64 with errors like:
>> BUILDSTDERR: annobin: modules/module-loopback.c: ICE: Should be 64-bit 
>> target
>>
>>
>> Failed scratch build:
>> https://userbase.kde.org/Konversation/Configuring_SASL_authentication
>>
>> Prior successful build,
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1348793

>Looks like annobin needs to be rebuilt everywhere due to the recent gcc
>update.

?Nick?

>Thanks,
>Florian
I have been adding this temporary hack in openmpi to get aarch64 to passin F32. 
Note it is a mixed language package, mostly c, with some c++, and it is the c++ 
code that fails to link without this extra -fPIC manually thrown in.  I still 
see the annobin target 64-bit errors mentioned above throughout the build logs 
in aarch64, but it does build.# TEMP: hack for aarch64
%global opt_cxxflags -fPIC

  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please fix the aarch64 g++ pic problems in f32 rawhide

[Philip Kovacs via devel]

 >>You're much better off including a couple of koji tasks/packages
>>showing the issue, it's much easier to get some real context.


>OK, here's one at least.  I have had to manually add -DPIC to the spec for 
>aarch64 in order to get>that arch to pass.  There were no problems with it up 
>until recently.

>https://koji.fedoraproject.org/koji/taskinfo?taskID=37332928

checking for gcc option to produce PIC... -fPIC -DPICchecking if gcc PIC flag 
-fPIC -DPIC works... yeschecking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yeschecking for gcc option to 
produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yeschecking for ld used by g++... 
/usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... no  <===  What  


  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please fix the aarch64 g++ pic problems in f32 rawhide

[Philip Kovacs via devel]

 >On Friday, August 30, 2019, 07:45:19 AM EDT, Peter Robinson 
 > wrote:
 
 
 >On Thu, Aug 29, 2019 at 10:21 PM Philip Kovacs via devel
 wrote:
>>
>> Several of us are getting errors in our c++ packages related to missing PIC 
>> flags in aarch64.
>>
>> Something is amiss there.  A small snippet from openmpi:

>You're much better off including a couple of koji tasks/packages
>showing the issue, it's much easier to get some real context.


OK, here's one at least.  I have had to manually add -DPIC to the spec for 
aarch64 in order to getthat arch to pass.  There were no problems with it up 
until recently.

https://koji.fedoraproject.org/koji/taskinfo?taskID=37332928

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org






  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Please fix the aarch64 g++ pic problems in f32 rawhide

[Philip Kovacs via devel]

Several of us are getting errors in our c++ packages related to missing PIC 
flags in aarch64.
Something is amiss there.  A small snippet from openmpi:
make[2]: Entering directory 
'/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx'
/bin/sh ../../../libtool  --tag=CXX   --mode=link g++  -DNDEBUG -O2 -g -pipe 
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fasynchronous-unwind-tables 
-fstack-clash-protection -finline-functions -pthread -version-info 60:1:20 
-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld-o libmpi_cxx.la -rpath 
/usr/lib64/openmpi/lib mpicxx.lo intercepts.lo comm.lo datatype.lo file.lo 
win.lo cxx_glue.lo ../../../ompi/libmpi.la -lrt -lm -lutil  -lz  -lhwloc  
-levent -levent_pthreads
libtool: link: g++  -shared -nostdlib 
/usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64/crti.o 
/usr/lib/gcc/aarch64-redhat-linux/9/crtbeginS.o  .libs/mpicxx.o 
.libs/intercepts.o .libs/comm.o .libs/datatype.o .libs/file.o .libs/win.o 
.libs/cxx_glue.o-Wl,-rpath 
-Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/.libs -Wl,-rpath 
-Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs -Wl,-rpath 
-Wl,/builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs -Wl,-rpath 
-Wl,/usr/lib64/openmpi/lib -L/builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs 
-L/builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs 
../../../ompi/.libs/libmpi.so 
/builddir/build/BUILD/openmpi-4.0.2rc1/orte/.libs/libopen-rte.so 
/builddir/build/BUILD/openmpi-4.0.2rc1/opal/.libs/libopen-pal.so -ldl -lrt 
-lutil -lz -lhwloc -levent -levent_pthreads 
-L/usr/lib/gcc/aarch64-redhat-linux/9 
-L/usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64 -L/lib/../lib64 
-L/usr/lib/../lib64 -L/usr/lib/gcc/aarch64-redhat-linux/9/../../.. -lstdc++ -lm 
-lpthread -lc -lgcc_s /usr/lib/gcc/aarch64-redhat-linux/9/crtendS.o 
/usr/lib/gcc/aarch64-redhat-linux/9/../../../../lib64/crtn.o  -O2 -g 
-fstack-protector-strong -grecord-gcc-switches -pthread -Wl,-z -Wl,relro 
-Wl,--as-needed -Wl,-z -Wl,now   -pthread -Wl,-soname -Wl,libmpi_cxx.so.40 -o 
.libs/libmpi_cxx.so.40.20.1
make[2]: Leaving directory '/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx'
BUILDSTDERR: /usr/bin/ld: .libs/mpicxx.o: relocation R_AARCH64_ADR_PREL_PG_HI21 
against symbol `_ZTVN3MPI5GroupE' which may bind externally can not be used 
when making a shared object; recompile with -fPIC
BUILDSTDERR: .libs/mpicxx.o: in function `MPI::Group::Group(ompi_group_t*)':
BUILDSTDERR: 
/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx/../../../ompi/mpi/cxx/group.h:62:(.text._ZNK3MPI3Win9Get_groupEv[_ZNK3MPI3Win9Get_groupEv]+0x34):
 dangerous relocation: unsupported relocation
BUILDSTDERR: /usr/bin/ld: .libs/mpicxx.o: relocation R_AARCH64_ADR_PREL_PG_HI21 
against symbol `_ZTVN3MPI10ErrhandlerE' which may bind externally can not be 
used when making a shared object; recompile with -fPIC
BUILDSTDERR: .libs/mpicxx.o: in function 
`MPI::Errhandler::Errhandler(ompi_errhandler_t*)':
BUILDSTDERR: 
/builddir/build/BUILD/openmpi-4.0.2rc1/ompi/mpi/cxx/../../../ompi/mpi/cxx/errhandler.h:30:(.text._ZNK3MPI3Win14Get_errhandlerEv[_ZNK3MPI3Win14Get_errhandlerEv]+0x34):
 dangerous relocation: unsupported relocation
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: hwloc update with so-bump and mpich rebuild

[Philip Kovacs via devel]

 Thanks Jerry -- what you describe is exactly what I am seeing in the build.log 
 Phil
On Thursday, August 29, 2019, 04:20:22 PM EDT, Jerry James 
 wrote:  
 
 On Thu, Aug 29, 2019 at 2:05 PM Philip Kovacs via devel
 wrote:
> Is there something odd going on with arch aarch64 -- openmpi builds are 
> failing on that arch.

There sure is.  I had the same thing happen with a qd build.  Look for
this in your build log:

checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... no

and then configure decides not to add -fPIC to the compiler flags, and
the library fails to build due to invalid relocations for a shared
object.  It only happens with g++, not gcc, and it only happens in
Rawhide.  I messed around with the qd build for awhile, and
accidentally found that adding -mabi=lp64 to CXXFLAGS makes that
configure test pass.  That shouldn't be necessary, as -mabi=lp64 is
already the default.  So, yes, something strange is going on with
aarch64 in Rawhide.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: hwloc update with so-bump and mpich rebuild

[Philip Kovacs via devel]

 Is there something odd going on with arch aarch64 -- openmpi builds are 
failing on that arch.
On Thursday, August 29, 2019, 04:37:55 AM EDT, Zbigniew Jędrzejewski-Szmek 
 wrote:  
 
 Packages are now built. Update is submitted for F31
[https://bodhi.fedoraproject.org/updates/FEDORA-2019-af50f19b83].

On Wed, Aug 28, 2019 at 08:08:23AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> I started doing the rebuilds now. I'll submit buildroot overrides
> as I go. (I was hoping to do this before the bodhi enablement in F31,
> but I got confused about the deadline). Unfortunately mpich now failed,
> so there'll be some delay. I'll submit one big update for F31 at the
> end.
> 
> Zbyszek
> 
> 
> On Wed, Aug 28, 2019 at 06:19:36AM +, Philip Kovacs wrote:
> >  
> > Are you going to submit f31 bodhi updates for these rebuilds?  Am watching 
> > the notifications    On Sunday, August 25, 2019, 09:01:05 PM EDT, Orion 
> > Poplawski  wrote:  
> >  
> >  On 8/25/19 1:17 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > > Hi,
> > > 
> > > I made a minor mess in the mpich world and instead of upgrading to
> > > 3.3.1 from 3.2.1., I built 3.1.1. I was a bit surprised when I got
> > > a bug [1] that mpich in Fedora is from 2014 :(
> > > 
> > > I'd like to update to 3.3.1, but that needs newer hwloc which has an
> > > so-bump.
> > > 
> > > There's a number of users of hwloc:
> > > 
> > > mpich
> > > pmix
> > > openmpi
> > > pocl
> > > slurm
> > > hpx
> > > legion
> > > aircrack-ng
> > > gromacs
> > > 
> > > They all build fine with hwloc 2.0.4, except from legion.
> > > Legion is incompatible.
> > > I came up with a patch to partially disable hwloc use [2],
> > > and after reporting the issue upstream, I got the feedback
> > > that this is the correct approach [3].
> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1745252
> > > [2] https://src.fedoraproject.org/rpms/legion/pull-request/1
> > > [3] https://github.com/StanfordLegion/legion/issues/575
> > > 
> > > As a stop-gap measure, I rebuilt mpich-3.2.1 again today in
> > > rawhide and F31. I'd like to do the update though.
> > > 
> > > I plan to build hwloc-2.0 and the packages listed above, incl. legion
> > > with the patch on Wednesday.
> > > 
> > > Zbyszek
> > 
> > Sounds good to me.  Thanks for taking this on.
> > 
> > 
> > -- 
> > Orion Poplawski
> > Manager of NWRA Technical Systems          720-772-5637
> > NWRA, Boulder/CoRA Office            FAX: 303-415-9702
> > 3380 Mitchell Lane                      or...@nwra.com
> > Boulder, CO 80301                https://www.nwra.com/
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

 
> But there's not anything actually wrong anymore?\
>I'm not sure what else you would like me to do here...>kevin

Yeah it's all good now -- f30 and f29 are all in testing now.   Thanks for 
checking.Phil___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

 UTC 00:00:00 has come and gone and nothing was pushed to testing, yet again.  
My reference to "7 days" was the time I have to wait until I can request 
stable.That timer cannot start until the packages hit testing.
There really should be more than one guy who happens to be at a 
conferencetaking care of this.

On Saturday, August 10, 2019, 04:40:31 PM EDT, Kevin Fenzi 
 wrote:  
 
 On 8/10/19 11:33 AM, Philip Kovacs via devel wrote:
> Just look at the updates pending pages.  Here are f30 and f29, resp:
> https://bodhi.fedoraproject.org/updates/?releases=F30=pending
> https://bodhi.fedoraproject.org/updates/?releases=F29=pending

Updates are pushed every single day at 00:00UTC.

However, todays failed because there were some unsigned packages.
(This is caused by updates that stay in updates testing for a long time
and their signed copies get grabage collected).

I fixed that and finished the broken push, but I am at flock and didn't
have time to start a full push. One should fire off in about 3 hours...

There should never be an update that waits 7 days to push to testing...

kevin
--
>    On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen 
> wrote:  
>  
>  
> 
> On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel 
>  wrote:
> 
> Why does it take days sometimes just to start the 7 day timer? 
> 
> Can we have some examples to track this down? Because without that.. no idea 
> and no way to fix.
>  
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

Just look at the updates pending pages.  Here are f30 and f29, resp:
https://bodhi.fedoraproject.org/updates/?releases=F30=pending
https://bodhi.fedoraproject.org/updates/?releases=F29=pending
   On Saturday, August 10, 2019, 02:29:24 PM EDT, Stephen John Smoogen 
 wrote:  
 
 

On Sat, 10 Aug 2019 at 13:22, Philip Kovacs via devel 
 wrote:

Why does it take days sometimes just to start the 7 day timer? 

Can we have some examples to track this down? Because without that.. no idea 
and no way to fix.
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Stephen J Smoogen.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Please sweep bodhi updates to testing in a timely manner

[Philip Kovacs via devel]

Why does it take days sometimes just to start the 7 day timer? ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: true or false: pkgconfig(foo) vs foo-devel

[Philip Kovacs via devel]

 > It does not matter if the config process uses pkgconfig or not. 
> Depending on the package name is not a way to state you're not using 
> pkgconfig, it's a way to get broken builds when the package you depend 
> on gets restructured.

Then the docs should be strengthened to state the case from the perspective of 
the providerof the .pc and not the consumer of it:
Current:
"Fedora packages which use pkg-config to build against a library (e.g. 'foo') 
on which they depend,  SHOULD express their build dependency correctly as 
pkgconfig(foo)."

becomes:
"Build dependencies on Fedora packages which provide pkg-config files SHOULD be 
expressed as pkgconfig(foo) and not foo-devel, whether the dependent package 
uses pkg-config or not."

  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

true or false: pkgconfig(foo) vs foo-devel

[Philip Kovacs via devel]

A "necessary and sufficient" question on the use of .pc files supplied by 
library providers.
1. Package foo-devel installs a pkgconfig .pc file as a convenience to 
developers.
2. Package bar requires headers and libraries provided by foo and is both a 
build    and runtime dependency of foo.3. Package bar uses autotools and m4 to 
discover and test for the presence    of foo.h and libfoo, but does not use not 
pkgconfig in any way.
True or False:
The spec for package bar MUST use BuildRequires: foo-devel and not 
BuildRequires: pkgconfig(foo), because bar does not use pkgconfig directly.
Ref: 
https://docs.fedoraproject.org/en-US/packaging-guidelines/PkgConfigBuildRequires/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: RPM building on s390x sometimes is very slow on F-30+

[Philip Kovacs via devel]

 It's likely the big endian emulation running on little endian machines which 
is killing performance.  I also have some time sensitive package tests failing 
on s390x.   On Thursday, July 11, 2019, 05:30:28 AM EDT, Peter Lemenkov 
 wrote:  
 
 Hello All,
Not sure if it's only me but every time I'm trying to build Erlang on
F-30 or Rawhide it takes forever to complete. It's all started
relatively recently (maybe a month or two). See the following logs for
the example.

* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131019
* https://koji.fedoraproject.org/koji/taskinfo?taskID=36131065 (s390x
task, two days and still work-in-progress)

Does anyone experience the same issue?
-- 
With best regards, Peter Lemenkov.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: gcc/g++ compiler memory exhaustion on build vms

[Philip Kovacs via devel]

 

   > On Wednesday, June 26, 2019, 02:42:29 AM EDT, Dan Horák  
wrote:>
> what package is it?

fastbit.   This evening I retired it in master since no upstream updates have 
been issued since 02/2016.
 https://src.fedoraproject.org/rpms/fastbit

The build problems are completely recent, nothing "real" has changed with this 
package in years.   I just startedgetting intermittent failures.   f30 and f29 
are still in the git tree if you want to look at it.    
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: gcc/g++ compiler memory exhaustion on build vms

[Philip Kovacs via devel]

 > On Wednesday, June 26, 2019, 01:05:13 AM EDT, John Reiser 
 >  wrote:
 
> Please quantify: What is the byte size of the .s file?

> First hint: give the virtual machine enough resources!
> Either RAM, or "swap" (paging) space.

The .s got up to about 375M before that particular g++ compile process died.   
The jobs are submitted with the usual suspects: koji or fedpkg.   I don't think 
we have any control over the resources allocatedto the vm's or containers the 
jobs land on (and we shouldn't).  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

gcc/g++ compiler memory exhaustion on build vms

[Philip Kovacs via devel]

I am finding that one of my c++ packages has compilation units that generate 
very large assembly (.s)files -- so large that any attempt to build them in 
memory (e.g. with -pipe) causes memory exhaustion.The only way I have found to 
reliably get the build to run to completion is by using -save-temps to forceg++ 
to save the .s assembly files to disk.  I also have to remove any (make) 
parallelism in the builds.
I am doing this:
%configure \    CXXFLAGS="${CXXFLAGS} -save-temps" \    ...
and using make (-j1 implied) instead of make_build.
Just curious if anyone has a better suggestion here.
Phil___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rawhide no longer recognizing autotool macros

[Philip Kovacs via devel]

 I use those macros wherever possible, but sometimes I need a raw `make`in 
order to specify uncommon targets.
I'll just replace `__make` with `make` for now.   No harm there.On 
Wednesday, June 19, 2019, 12:06:44 PM EDT, Vitaly Zaitsev via devel 
 wrote:  
 
 Hello, Philip Kovacs via devel.

Wed, 19 Jun 2019 15:28:10 + (UTC) you wrote:

> I notice I am still using the `__make` macro in my specs.  While they
> still work, should we proactively replace them with `make` ?

You can use %make_build and %make_install instead.

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rawhide no longer recognizing autotool macros

[Philip Kovacs via devel]

 
None that I can tell.  Years ago when I was writing my specs to add the 
packages I now maintain, I recallsomeone recommended to me the use of these 
macros as Fedora "tribal knowledge."  
I am happy to remove mine if their use is unnecessary and could lead to 
breakage. On Wednesday, June 19, 2019, 11:31:24 AM EDT, Christophe de 
Dinechin  wrote:  
 
 

> On 19 Jun 2019, at 17:28, Philip Kovacs via devel 
>  wrote:
> 
> I notice I am still using the `__make` macro in my specs.  While they still 
> work, should we proactively replace them with `make` ?

What’s the downside of removing it?

> 
> The additional message I am getting here is that the under-under macros might 
> be subject to removal.
> 
> Thanks
> Phil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rawhide no longer recognizing autotool macros

[Philip Kovacs via devel]

I notice I am still using the `__make` macro in my specs.  While they still 
work, should we proactively replace them with `make` ?
The additional message I am getting here is that the under-under macros might 
be subject to removal.
ThanksPhil___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: rawhide no longer recognizing autotool macros

[Philip Kovacs via devel]

 OK, my builds are back in order having removed those macros and replaced them 
with commands.
I expect that many package maintainers will be hit with this.
On Wednesday, June 19, 2019, 12:01:31 AM EDT, Neal Gompa 
 wrote:  
 
 On Tue, Jun 18, 2019 at 10:48 PM Philip Kovacs via devel
 wrote:
>
> I'm getting new build failures on the autotools macros that had been working 
> for years.  rpmbuild doesn't like
> them anymore in rawhide.  The macros are (or were) in the file 
> `/usr/lib/rpm/macros`.  The relevant portion
> of my spec is here:
>
> -- spec --
> %build
> %{__aclocal} -I auxdir
> %{__autoconf}
> %{__automake} --no-force
>
> Is there a new dependency I need to add or is something just broken?
>

Panu ripped them out for rpm 4.15:
https://github.com/rpm-software-management/rpm/pull/691

You can trivially switch to just calling the commands...




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

rawhide no longer recognizing autotool macros

[Philip Kovacs via devel]

I'm getting new build failures on the autotools macros that had been working 
for years.  rpmbuild doesn't likethem anymore in rawhide.  The macros are (or 
were) in the file `/usr/lib/rpm/macros`.   The relevant portion of my spec is 
here:
-- spec -- %build%{__aclocal} -I auxdir%{__autoconf}%{__automake} --no-force
Is there a new dependency I need to add or is something just broken?
Thanks,Phil


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automating package maintainers responsivity check

[Philip Kovacs]

 > Being a volunteer doesn't mean to not have any responsibility.
It's grossly unfair to insinuate that being a volunteer is associated with 
laziness or a lack of responsibility.
There are a myriad of things that we as packagers do that are completely silent 
to the surrounding automation and for which most people are never even aware.  
Working with upstream development teams, for example, filing bugs on their 
systems.  What Fedora sees as a patch or a version bump to a package may be the 
result of hours of thankless work on the part of the volunteer packager.   
If you want to find a way to automate notification that a maintainer is 
unresponsive after a reasonably period, fine.   Obsoleting their packages is 
just wrong however. On Sunday, November 18, 2018, 4:45:00 AM EST, Mattia 
Verga  wrote:  
 
  Il 11/17/18 10:59 PM, Philip Kovacs ha scritto:
  
 
  You want to attract packagers, not irritate them. 

   
In my opinion, "irritating" is when a maintainer doesn't reply to bugs that 
users fill in Bugzilla. If they can't found enough time to reply or change 
state of any bug in a six months period, than maybe it is better someone else 
take care of their package.
 
Being a volunteer doesn't mean to not have any responsibility.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automating package maintainers responsivity check

[Philip Kovacs]

 There already is a fedora_active_user script of sorts 
https://github.com/pypingou/fedora-active-user.
I would not be in favor of any respond or die automation.   We volunteer our 
time and effort to be packagersand the job is often thankless enough as it is.  
Having some additional automation orphan your packagesbecause you happen to be 
away for a bit is overkill.   You want to attract packagers, not irritate them.
On Saturday, November 17, 2018, 11:58:27 AM EST, Mattia Verga 
 wrote:  
 
 Il 11/17/18 4:50 PM, Ron Olson ha scritto:
> What about packages that see infrequent updates; I maintain Nethack 
> and the Dev Team can and does take years between releases. If it's 
> just a blanket email to ask the packagers if they're still interested 
> that's one thing, but going off package updates may be problematic for 
> some folks.
>
>
I'm thinking about a script which would run every month and:

- checks maintainer activities in git / bugzilla / mailing lists 
(something like fedora-active-user already does) in the last six months
- if the user hasn't done any activity, send an email with a link
   - if the user visit the link, do not bother them for the next 6 months
   - if the user doesn't visit the link, send a second email after one 
week and a third after another week
- after three emails without response, orphan their packages and inform 
devel list

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Heads up: selinux-policy-3.14.1-25.fc28 breaks GDM

[Philip Kovacs]

 I got hit with this too on F28 using negativo17's nvidia driver 
packages.Downgrading selinux-policy-3.14.1-25 / 
selinux-policy-targeted-3.14.1-25 clears it up.There's a fedora update to 
-3.14.1-29 pending:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-a74875b364

Too bad dnf doesn't allow excludepkgs granularity down to the release number, 
i,e,you can set dnf.conf to exclude/skip 3.14.1, but not 3.14.1-25. On 
Thursday, May 24, 2018, 5:42:38 PM EDT, Adam Williamson 
 wrote:  
 
 On Wed, 2018-05-23 at 20:13 -0600, Jerry James wrote:



> [1] Which is totally useless, by the way.  It says "Oh no!  Something went
> wrong!"  (Great.  *WHAT* went wrong?) and informs me that I must logout.  I
> wasn't logged in.  There's a nice logout button there, but it can't be
> pressed.  There is no mouse pointer.  No keyboard shortcut that I can think
> of causes the button to change appearance.  Even if I did manage to press
> it, what exactly would that do?  I'm already not logged in!

I'd file a bug on upstream GNOME for this, against gdm or gnome-shell.
The screen is part of *gnome-shell*, in fact, not GDM. IIRC and AIUI
(put those on my gravestone!), the screen was introduced before gdm
became basically a special case of shell - so the screen was written
assuming it'd be displayed when a *logged-in session* hit a critical
failure. But now gdm *is* just a special case of gnome-shell...it also
shows up when a *gdm instance* hits a critical failure. And obviously,
as you say, makes very little sense in that case. CCing desktop list.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B3QVO6L7OHSS4UZJM2DNTITEOQX56NT7/
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6KKLUD6QXFL6HQGPU3W4CUC2CYGAXPJI/

Re: fedpkg on rawhide

[Philip Kovacs]

 # dnf downgrade fedpkg
Last metadata expiration check: 0:05:17 ago on Sun 20 May 2018 06:55:43 PM 
EDT.Package fedpkg of lowest version already installed, cannot downgrade 
it.Error: No packages marked for downgrade.

On Saturday, May 19, 2018, 6:28:21 PM EDT, Kevin Fenzi <ke...@scrye.com> 
wrote:  
 
 On 05/19/2018 03:21 PM, Philip Kovacs wrote:
> Is there a workaround or fix forthcoming for fedpkg?
> 
> 
> $ fedpkg --helpTraceback (most recent call last):  File "/usr/bin/fedpkg", 
> line 6, in     from pkg_resources import load_entry_point  File 
> "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3088, in 
>     @_call_aside  File 
> "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3072, in 
> _call_aside    f(*args, **kwargs)  File 
> "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3101, in 
> _initialize_master_working_set    working_set = WorkingSet._build_master()  
> File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 574, 
> in _build_master    ws.require(__requires__)  File 
> "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 892, in 
> require    needed = self.resolve(parse_requirements(requirements))  File 
> "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 778, in 
> resolve    raise DistributionNotFound(req, 
> requirers)pkg_resources.DistributionNotFound: The 'rpm-py-installer' 
> distribution was not found and is required by rpkg

Downgrade for now.

This is
https://bugzilla.redhat.com/show_bug.cgi?id=1579367

and hopefully will be fixed soon...

kevin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RKIKDG6EGAZUDQGQMAW5DH7XYD4POFOA/
  ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RJIVOLNAVW5PVCULYDZRGNWHYRMU5ESV/

fedpkg on rawhide

[Philip Kovacs]

Is there a workaround or fix forthcoming for fedpkg?


$ fedpkg --helpTraceback (most recent call last):  File "/usr/bin/fedpkg", line 
6, in     from pkg_resources import load_entry_point  File 
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3088, in 
    @_call_aside  File 
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3072, in 
_call_aside    f(*args, **kwargs)  File 
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3101, in 
_initialize_master_working_set    working_set = WorkingSet._build_master()  
File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 574, in 
_build_master    ws.require(__requires__)  File 
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 892, in 
require    needed = self.resolve(parse_requirements(requirements))  File 
"/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 778, in 
resolve    raise DistributionNotFound(req, 
requirers)pkg_resources.DistributionNotFound: The 'rpm-py-installer' 
distribution was not found and is required by rpkg

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GAWY2GCTEU35WFAGGX5OJLXFS4LPC3DE/

Re: How do you bump fedora-repos-rawhide to f29?

[Philip Kovacs]

Alright I got around the catch-22 of dnf needing the f29 keys in order to 
install the f29 keys with:
dnf install --nogpgcheck fedora-gpg-keys-29-0.1

That cleared the road for me. 

On Saturday, March 3, 2018 5:41 PM, Philip Kovacs <pkde...@yahoo.com> wrote:
 

 Yeah I'm living in the chaos of going from f28 rawhide to f29 rawhide.    
Thanks for the tips. 

On Saturday, March 3, 2018 5:26 PM, stan <stanl-fedorau...@vfemail.net> 
wrote:
 

 On Sat, 3 Mar 2018 21:15:22 + (UTC)
Philip Kovacs <pkde...@yahoo.com> wrote:

> I would settle for knowledge of where the f29/rawhide gpg keys are
> hidden so I import them. The "To Rawhide" instructions below are
> outdated as they direct you to a page where the f29/rawhideare not
> presented. Upgrading Fedora using package manager - Fedora Project
> Wiki

You can go here
https://koji.fedoraproject.org/koji/buildinfo?buildID=1047417
and here
https://koji.fedoraproject.org/koji/buildinfo?buildID=1047416
and grab the packages for f29 and install them using
dnf -C update [list of packages]

In the past, I've had good luck enabling rawhide just by commenting out
the current repos, enabling the rawhide repos, and doing a dnf update
when I've been 1 version below rawhide.  I think things are somewhat
chaotic between rawhide and F28 because there have been so few composes
lately.  So the direct install of the files is probably better.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   

   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How do you bump fedora-repos-rawhide to f29?

[Philip Kovacs]

Yeah I'm living in the chaos of going from f28 rawhide to f29 rawhide.    
Thanks for the tips. 

On Saturday, March 3, 2018 5:26 PM, stan <stanl-fedorau...@vfemail.net> 
wrote:
 

 On Sat, 3 Mar 2018 21:15:22 + (UTC)
Philip Kovacs <pkde...@yahoo.com> wrote:

> I would settle for knowledge of where the f29/rawhide gpg keys are
> hidden so I import them. The "To Rawhide" instructions below are
> outdated as they direct you to a page where the f29/rawhideare not
> presented. Upgrading Fedora using package manager - Fedora Project
> Wiki

You can go here
https://koji.fedoraproject.org/koji/buildinfo?buildID=1047417
and here
https://koji.fedoraproject.org/koji/buildinfo?buildID=1047416
and grab the packages for f29 and install them using
dnf -C update [list of packages]

In the past, I've had good luck enabling rawhide just by commenting out
the current repos, enabling the rawhide repos, and doing a dnf update
when I've been 1 version below rawhide.  I think things are somewhat
chaotic between rawhide and F28 because there have been so few composes
lately.  So the direct install of the files is probably better.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How do you bump fedora-repos-rawhide to f29?

[Philip Kovacs]

I would settle for knowledge of where the f29/rawhide gpg keys are hidden so I 
import them.
The "To Rawhide" instructions below are outdated as they direct you to a page 
where the f29/rawhideare not presented.
Upgrading Fedora using package manager - Fedora Project Wiki

  
|  
|   |  
Upgrading Fedora using package manager - Fedora Project Wiki
   |  |

  |

 


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Change to linker flags injection (#1548397)

[Philip Kovacs]

A scratch build won't find bind now errors as they are discovered at run time 
when the dlopen occurs.
I have been using:%define _hardened_ldflags "-Wl,-z,lazy"to allow the 
compile-time hardening, stack protection, etc to remain but filter out the -z 
now linker flag.I assume this won't work anymore. 

On Saturday, February 24, 2018 1:03 PM, Florian Weimer <fwei...@redhat.com> 
wrote:
 

 On 02/24/2018 06:32 PM, Jerry James wrote:
> On Sat, Feb 24, 2018 at 10:24 AM, Florian Weimer <fwei...@redhat.com> wrote:
>> We currently inject “-z now” hidden behind a -specs= option for the gcc
>> compiler driver.  libtool drops this -specs= option from the linker command
>> line, but it preserves -Wl,-z,relro, so I'm trying whether listing
>> -Wl,-z,now directly improves the linker flag injection here.
>>
>> I'm doing this in two stages and will remove -z now from the GCC specs file
>> only after I have rebuilt a couple of extension builders (python2, python3,
>> ruby), so that we do not lose -z now due to the non-synchronized switchover
>> between the hard-coded command line (in the extension builder) and the GCC
>> specs file contents (from redhat-rpm-config).
>>
>> This will happen both in rawhide and Fedora 28.
> 
> Are you also implementing a way to disable it, as Philip Kovacs asked
> for yesterday?

It's still for hardened builds only.  Sorry, I should have mentioned 
that.  It's next to -specs=…/redhat-hardened-ld, not next to -Wl,-z,relro.

> I also maintain some packages that use plugins, and
> are broken by -z now.  If you would like to look at any of them to see
> what might be done, these are the packages that currently use
> %undefine _hardened_build to work around the issue:

That should just work as before.  Feel free to do a (scratch) build in 
rawhide to verify.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

The package is slurm and the issue is their plugins.  It's a deep architectural 
problem unfortunately,To summarize the issue briefly:  When designing a plugin 
system, the services a plugin providesought not depend on the environment that 
loads it.  That is not the case for slurm.   Their pluginscontain symbols that 
refer back to the program that loads them. 
Suppose you have a plugin P loaded by programs A and B.   Slurm's plugins often 
contain symbols a in A and b in B.  When program A loads plugin P, the symbols 
b remain unresolved.  When program B loads plugin P, the symbols a remain 
unresolved.
I have spent hours supplying complex patches for them to "harden" and meet the 
bind now requirement,They acknowledge the problem but do not have enough 
customers complaining about it yet.  Slurm issoftware deployed in large HPC 
research centers typically (hundred, thousands or more nodes). 
 

On Friday, February 23, 2018 12:26 PM, John Reiser <jrei...@bitwagon.com> 
wrote:
 

 Philip Kovacs wrote:
> My particular concern is not "missing" bind now flags in the elf objects.  I 
> am concerned about
> making sure bind now is omitted because the package cannot operate with that 
> flag.

Please tell us the name of the packages, and some indication of why
the package does not work with BIND_NOW.  Having specific information
might help to identify and understand a more-general situation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

My particular concern is not "missing" bind now flags in the elf objects.  I am 
concerned aboutmaking sure bind now is omitted because the package cannot 
operate with that flag. 

On Friday, February 23, 2018 11:35 AM, Florian Weimer <fwei...@redhat.com> 
wrote:
 

 On 02/23/2018 05:16 PM, Philip Kovacs wrote:
> The bind now issue is a real problem for some packages.  I have interacted 
> with upstream countlesstimes on it and simply lost the fight.  Please, 
> whatever you do, leave some route to disable bind now.

Disable it for what?

The vast majority of missing BIND_NOW flags has been caused by 
accidentally dropped LDFLAGS settings.  (That, and firmware files which 
happen to be ELF.)

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libtool and LDFLAGS build flags injection

[Philip Kovacs]

The bind now issue is a real problem for some packages.  I have interacted with 
upstream countlesstimes on it and simply lost the fight.  Please, whatever you 
do, leave some route to disable bind now. 

On Friday, February 23, 2018 10:55 AM, Florian Weimer  
wrote:
 

 I've seen a fair amount of LDFLAGS injection failures related to 
libtool.  For the most part, 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld is dropped, leading to a 
lack of BIND_NOW in the resulting binary.

Is there a way we can fix this in libtool or the auto* tools?  I'm also 
considering moving -Wl,-z,now to the command line from the GCC specs 
file, which might help here, too.  But I'd prefer a direct, unfiltered 
channel from redhat-rpm-config to the linker invocation in case we need 
to inject additional flags.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Philip Kovacs]

Ok, my configure.ac initializes libtool with both c and c++ :
LT_INIT()LT_LANG([C])LT_LANG([C++])
where only C is needed.   There are no ill-effects other than producing some 
noise in the configureoutput, but I will patch out the LT_LANG([C++]) line to 
trim the noise.


On Sunday, February 18, 2018 3:37 PM, Tomasz Kłoczko 
 wrote:
 

 On 18 February 2018 at 17:09, Igor Gnatenko
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to 
> random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.

Yesterday I've replayed on your proposal but I've not realized that my
reply was held by the moderator.
You started introducing changes only after less than 24h after
publishing proposal.
It does not make any sense sending any proposals if you will be not
waiting for feedback at least few days :-/


Here is the copy of my yesterday reply:


As definitely proposed change will create the whole wave of small
changes adding at least one new BuildRequires I just started thinking
about going slightly deeper (but only a bit deeper ;) ).

When gcc or other compilers are no longer part of the core build env
suit/env as you mention it is necessary to add it straight in
BuildRequires for example gcc.
That is OK.

Q: does it really needs to be gcc? What about clang?
A: theoretically it does not need to be gcc .. especially as macros
like %cmake, %configure are injecting over CC, CXX and other variables
exact commands.

As long as none of the macros like %cmake or %cobfigure has straight
dependency and are not forcing to use gcc (those macros are using
other macros like %{__cc}) already it possible to test build package
written in C using C++ compiler to for example expose some set of
compile warnings generated by C++ compiler or .. use clang.
Build the whole package with using some C code security scanners? No
problem. It is possible to do this without touching spec file.

OK, so .. at the moment macros like:

%__cc gcc
%__cpp gcc -E
%__cxx g++

are defined in /usr/lib/macros which is part of the rpm.
If those macros will be removed from this file and moved to
/usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
the platform which will open the whole spectrum of completely new
possibilities with some minimal changes in whole build env and no
other changes in all specs.
Only weak point in above is how to force use gcc if both gcc and clang
will be installed (which will be quite typical in case all packages
private build envs).
However, I think that even this is a very small obstacle which can be
easily handled.

Now by default %/{__cc} is provided by gcc but if here it will be
introduced small flexible it should be possible to control which
the compiler should be used even if in packagers build system will be
installed both gcc and clang by simple few changes in ~.rpmrc or on
Fedora build systems in ~mock/.rpmrc file.

So maybe instead:

BuildRequires: gcc

better would be to use:

BuildRequires: %{__cc}

or:

BuildRequires: c-compiler

??
if  both gcc and clang will have:

Provides: c-compiler

still it will be possible installed gcc and clang without conflicts.
I'm sure that above it is not complete idea and few small bits still
are missing.

I think that we should hold for few seconds and consider change a bit
this proposal to pen those possibilities.


Comments?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Philip Kovacs]

False positive on project pmix.  I checked my rawhide build logs for all six 
arches and there is no `checking for c++`, as you report, in the autotools 
configure output. The project is a C project and the spec properly lists 
BuildRequires: gcc`.  There is nothing wrong and nothing to do. 

On Sunday, February 18, 2018 2:53 PM, Tom Hughes  wrote:
 

 On 18/02/18 19:01, Igor Gnatenko wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, 2018-02-18 at 18:53 +, Tom Hughes wrote:
>> On 18/02/18 17:09, Igor Gnatenko wrote:
>>
>>> Over this weekend I've performed scratch-mass-rebuild without having gcc
>>> and
>>> gcc-c++ in buildroot of all Fedora packages, many of which failed due to
>>> random
>>> reasons and I grepped all logs for some common errors found by analyzing
>>> hundreds of build logs.
>>>
>>> Guidelines: https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B#BuildReq
>>> uire
>>> s_and_Requies
>>>
>>> The grep output is located here:
>>> https://ignatenkobrain.fedorapeople.org/gcc-removal.txt
>>
>> I can see python-mapnik at least in there is one of mine and I'll
>> be happy to fix it once the current dependency hell in rawhide allows
>> me to build it...
> 
> Just push commit, not necessary to build it right away.

Tried that with mapnik and ldconfig scriptlets and I'm still
trying to get a build three weeks later ;-)

I've pushed it now anyway, and also fixed libdwarf and osmpbf.

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Philip Kovacs]

Is Koschei eventually going to rebuild with the corrected gcc?  I see 
dependency changes after the last failed build, but Koschei hasn't rebuilt yet. 

On Saturday, January 27, 2018 4:01 AM, Peter Robinson 
 wrote:
 

  ATM all rawhide builds are failing for me, because autoconf's tests for
 CC are failing.
>>>
>>>
>>> Yes, we had an internal dependency issue involving annobin (not related
>>> to RPM dependencies), fixed by an annobin rebuild.  Later, a defective build
>>> of annobin was tagged into rawhide which had a file conflict, but this has
>>> since been resolved as well.
>>
>>
>> Is annobin-3.2-2.fc28 the fixed version?
>
>
> Ah!  We currently have:
>
>            nevra            |          name
> +-
>  annobin-2.0-3.fc27.x86_64  | Fedora/27/x86_64
>  annobin-3.1-1.fc28.src    | Fedora/rawhide/source
>  annobin-3.1-1.fc28.x86_64  | Fedora/rawhide/x86_64
>  annobin-3.1-3.fc28.aarch64 | Fedora/28-build/aarch64
>  annobin-3.1-3.fc28.i686    | Fedora/28-build/i386
>  annobin-3.1-3.fc28.ppc64le | Fedora/28-build/ppc64le
>  annobin-3.1-3.fc28.s390x  | Fedora/28-build/s390x
>  annobin-3.1-3.fc28.x86_64  | Fedora/28-build/x86_64
> (8 rows)
>
> rawhide repositories are composes, the *-build repositories come directly
> from Koji.  (I haven't mirrored everything, which is why the list is
> incomplete.)
>
> Koji isn't currently generating repositories, so annobin-3.2-2.fc28 hasn't
> showed up.  However, annobin-3.1-3.fc28 is also fine (annobin-3.2-1.fc28 has
> this particularly bug), as long as you use it with GCC 7.3.  So if you build
> using Koji use the mysteriously named “local” repository in mock, you should
> be able to build packages.

The newRepo issue is known by rel-eng/infra and is being investigated/worked on.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Philip Kovacs]

I'm getting:
configure: error: C compiler cannot create executables 

On Friday, January 26, 2018 1:53 AM, Ralf Corsepius  
wrote:
 

 Hi,

ATM all rawhide builds are failing for me, because autoconf's tests for 
CC are failing.

Digging into details led me to this error:
...
cc1: error: fail to initialize plugin 
/usr/lib/gcc/x86_64-redhat-linux/7/plugin/annobin.so
annobin: conftest.c: Error: plugin built for compiler version (7.3.1) 
but run with compiler version (7.2.1)
...

AFAIS, GCC in rawhide was updated to GCC-7.3.1, but apparently annobin 
wasn't rebuilt, resulting into rawhide now carrying an inconsistent 
GCC-toolchain.

Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Test gating enabled in Bodhi

[Philip Kovacs]

On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote:
>> Can someone please elaborate on how I can control the abi tests
>> directly?Where exactly can I access these and refine them on a per-
>> package basis?

>That text isn't talking about "fixing the tests", but about fixing the
>*bugs*. It assumes that the test indicates a real issue that needs
>fixing, therefore you can fix the issue in your package and cause the
>test to pass.

OK, thanks. The abi check canvases everything in the package and is sensitive 
to changes that are internal to the package.  Thoser internal changes are not 
bugs for us to manage.Take, for example, a c/c++ package with many .so plugins 
or other internal libraries that provide services to the application, but are 
not user-facing -- the abi check sees these internal changes as noteworthy, but 
they really are not and should be filtered.  
I guess I'll have to use the waiver for now.  

On Tuesday, January 23, 2018 5:44 PM, Adam Williamson 
<adamw...@fedoraproject.org> wrote:
 

 On Tue, 2018-01-23 at 21:25 +, Philip Kovacs wrote:
> Can someone please elaborate on how I can control the abi tests
> directly?Where exactly can I access these and refine them on a per-
> package basis?

> How to fix the tests?

That text isn't talking about "fixing the tests", but about fixing the
*bugs*. It assumes that the test indicates a real issue that needs
fixing, therefore you can fix the issue in your package and cause the
test to pass.

It doesn't really cover the scenario where what the test is reporting
isn't really a problem and doesn't need to be fixed. You can't resolve
that from your package git repository, but you *can* submit a waiver,
as discussed upthread.

Additionally, as Ralph wrote, he has removed abicheck from the list of
gating tests for now, so you shouldn't need to worry about abicheck
failures blocking updates, as soon as Bodhi starts applying that
change.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Test gating enabled in Bodhi

[Philip Kovacs]

Can someone please elaborate on how I can control the abi tests directly?Where 
exactly can I access these and refine them on a per-package basis?

How to fix the tests?
The tests are all in your hand, you can fix the dist.depcheck and dist.abicheck 
by adjusting the update or the build and you can fix the package level testing 
since the tests are stored in the dist-git repository of the package itself. 
You have the control on the tests.
 

On Tuesday, January 23, 2018 2:16 PM, Matthew Miller 
 wrote:
 

 On Tue, Jan 23, 2018 at 12:25:56PM -0600, Rex Dieter wrote:
> > There are three tests that must pass in order for updates to go to stable:
> > 0. dist.depcheck - to make sure the update's dependencies are available.
> > 1. dist.abicheck - to make sure the update's ABI remains stable in a
> >    given Fedora release.
> ...
> > Finally, if it turns out you need to push an update through despite of the
> > test results, you can do so using waiver-cli (dnf install waiverdb-cli).
> > We are working on integrating this into Bodhi itself, making this easier.
> I think it unwise to make item 1 a mandatory item at this point.  I'd argue 
> a large number of packages do not provide public api/abi that's worth 
> worrying about in this regard.

I think we should definine a set of packages where we care about this,
and enable it on a case-by-case basis and make it advisory otherwise.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Philip Kovacs]

Any word on the performance hit before you push to stable?  Is it discernible? 

On Wednesday, January 3, 2018 8:15 PM, stan  
wrote:
 

 On Wed, 03 Jan 2018 15:02:11 -0800
Adam Williamson  wrote:

> * We know that the fix can lead to reduced performance in some cases
> (this affects synthetic benchmarks rather more than real-world
> performance). The kernel team thinks the fix is sufficiently important
> that it should go out despite the performance impact. Accordingly,
> please do not file negative karma for this reason. If the update
> somehow results in such a significant performance impact that the
> system becomes unusable, though, please report that.

>From my reading about the problem on the web, the fix always has a
degrading effect on performance, since the page table can no longer be
kept in the program memory space, so has to be reloaded every time a
system call is made.

> * The fix is currently applied only to x86_64 kernels. No fix is yet
> present for any other architecture, but of course all architectures
> are rebuilt for the update.

Again, from my reading on the web this only affects Intel CPUs of the
last decade.  So, no other manufacturer or architecture needs to have
the fix applied.

There is a lot of hype and speculation about this, but AMD *have* stated
that their CPUs are not affected by the exploit.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Proposal] Mass change: remove executing gtk-update-icon-cache in %post/%postu/%postrans to update hicolor theme cache

[Philip Kovacs]

Can we remove the gtk-update-icon-cache entries from our packages now, 
manually, in advance of the mass update?   

On Wednesday, January 3, 2018 11:10 AM, Charalampos Stratakis 
 wrote:
 

 - Original Message -
> From: "Tomasz Kłoczko" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, January 3, 2018 4:53:24 PM
> Subject: [Proposal] Mass change: remove executing gtk-update-icon-cache in 
> %post/%postu/%postrans to update hicolor
> theme cache
> 
> Hi,
> 
> I'm trying to follow procedure described on
> https://fedoraproject.org/wiki/Mass_package_changes
> 
> Description of the current state
> ===
> 
> At the moment more than many spec files have %post/%postu/%postrans
> scriptles in which is done updating hicolor theme cache by calling:
> 
> gtk-update-icon-cache -f %{_datadir}/icons/hicolor
> 
> All those scriptles are no longer needed because in hicolor-icon-theme
> package has file triggers updating theme cache on any change in single
> dnf/rpm transaction.
> 
> $ rpm -q --filetriggers hicolor-icon-theme
> transfiletriggerin scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
> gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
> transfiletriggerpostun scriptlet (using /bin/sh) -- /usr/share/icons/hicolor
> gtk-update-icon-cache --force /usr/share/icons/hicolor &>/dev/null || :
> 
> Remove all those %post/%postu/%postrans scriptles will speedup install
> and upgrades as only one time gtk-update-icon-cache will be executed
> as hicolor-icon-theme transaction action.
> 
> List of affected packages
> ===
> On the list is more than 1300 packages.
> List has been generated in directory with all spec files extracted
> from git repos using command:
> 
> $ grep 'gtk-update-icon-cache.*hicolor' * | grep -v hicolor-icon-theme
> | awk -F\. '{print $1}' | uniq > gtk-update-icon-cache_hicolor.lst
> 
> gtk-update-icon-cache_hicolor.lst has been added as the attachment in
> this email.
> 
> 
> If it will be no more comments about this proposal I'll try in a week
> follow next steps of the procedure described on Fedora wiki sending
> final proposal to devel-announce list and after this raise ticket in
> BTS.
> 
> PS. Please advise how to implement change without raising +1300
> tickets on bugzilla (I'm not going to sped weeks or months on
> introduce such simple change)
> 
> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 


Hi.

You might want to take a look at https://pagure.io/python-fixrequires which is 
from a python-SIG member, and modify it for your usecase.

It basically forks a repo, makes the changes to the SPEC, pushes it to your 
fork and creates a PR to the original repo.

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

>Artistic (volatile) temperament” is just a euphemistic way of saying “engages 
>in unchecked abusive behaviour toward their peers”, and no member of the 
>community should be expected to bend over backwards to >tolerate this or to 
>turn a blind eye to it.

You completely, utterly and totally misread the meaning and spirit of what I 
said.  
To reiterate, if the maintainer is responsive, my opinion is that is a courtesy 
to notify him/her.  
That's all.  Some people are more attached and involved with their code and 
would appreciate the gesture. 
No need to imagine that the maintainer is demonstrating "unchecked abusive 
behavior."  
For Pete's sake.  
 

On Tuesday, December 12, 2017 7:09 AM, Graham Leggett <minf...@sharp.fm> 
wrote:
 

 On 09 Dec 2017, at 8:21 PM, Philip Kovacs <pkde...@yahoo.com> wrote:

I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.

We need to nip this kind of thing in the bud.
“Artistic (volatile) temperament” is just a euphemistic way of saying “engages 
in unchecked abusive behaviour toward their peers”, and no member of the 
community should be expected to bend over backwards to tolerate this or to turn 
a blind eye to it.
Even more specifically nobody at Fedora should be forced to ask special 
permission from or give special notification to specific individuals over and 
above the established procedures before doing their work. Their commit 
privileges / karma / following the established procedure give them that 
permission.
If someone makes a change to your code, start with the premise that the person 
who made the change did so in good faith, and respond appropriately from there.
Regards,Graham—
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

>I deeply believe that such maintainers and such packages as you
>describe must become a thing of a past.  For the moment, until your new world 
>order arrives, packages are maintained by people of all types volunteering 
>their time and effort.  These are people who will probably never even hear a 
>thank you from anyone for their efforts.  One important way to extend to them 
>respect and gratitude for that contribution is to notify them prior to 
>changing the files they spent time maintaining.   It's just simple human 
>courtesy. 

On Saturday, December 9, 2017 2:13 PM, Zbigniew Jędrzejewski-Szmek 
<zbys...@in.waw.pl> wrote:
 

 On Sat, Dec 09, 2017 at 06:26:28PM +, Philip Kovacs wrote:
> s/do want/do NOT want 
> 
>    On Saturday, December 9, 2017 1:21 PM, Philip Kovacs <pkde...@yahoo.com> 
>wrote:
>  
> 
>  I am opposed to allowing PP unfettered access to projects in which
>  the maintainer(s) are responsive.  It's common for developers to
>  have artistic (volatile) temperaments , like a painter who paints
>  on canvas owned by someone else.

It's possible that this it crux of the difference between different
sides in this thread.

I deeply believe that such maintainers and such packages as you
describe must become a thing of a past. Don't get me wrong — I have
been there, I have done that (über-complicated packages, spec files
full of custom code) — and I think was a waste of time. If a program
requires a complicated spec file, then usually something is wrong with
the program.

Look at the recent fedora-devel thread "Forge-hosted projects
packaging automation": all the valiant efforts by maintainers to
express their creativity by fighting with github and gitlab hosting and
commit hashes and git tags and tarballs are replaced by very-strictly
scripted approach where you just define a few fields and let the
tooling do the rest.

The same story happened with python packaging a while back: all the
ways to call setup.py are replaced by a very boring %py_build and
%py_install invocations.

Fedora as a distro is moving away from arcane setups where only one or
two people can make changes towards team maintenance and having
everything simplified to avoid mistakes and documented to make things
easy for newcomers. I'd say that this is a trend which is true for all
of the Linux ecosystem. People have realized that bus factors of one
or two are bad for long term sustainability. Eh, even the kernel now
has sphinx-based docs so you can actually read the stuff.

The reason why that is happening is that we have ever more packages,
released more often, with a smaller maintainer/package ratio then
ever. If you want to scale, you need to simplify and automate.
Essentially, expressing your creativity/spirit/style in how the
whitespace is organized and how macros are defined is passé.

Zbyszek


  Does the owner have the right to change the color jars?  Perhaps.  Does the  
owner have the right to look at the painting and say "I don't like the way you 
painted that tree.  I'm going to change it."  Absolutely not.
> Perhaps add a project setting that allows package maintainers to configure 
> how PP changes can be made, by direct commit, by pull request, etc.  That 
> would allow maintainerswho are more "involved" with their packages to have 
> more control.   It's a common management problem.  People who have taken on 
> responsibility must also have control to the extent to which system allows.  
> You certainly do want to drive good people away..  
> 
>    On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
><mru...@matthias-runge.de> wrote:
>  
> 
>  On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> > Now this has gone back and forth. The system worked more or less ok.
> > Maybe it is more about the changes (and communication) of a
> > specific provenpackager?
> 
> After sleeping a night over this, I should have put it in different
> words:
> 
> My questionis are here:
> - do we have an issue at all?
> - do we have an issue with a single provenpacker
> - do we have an issue of attitude or with a group of people?
> 
> The consensus of this long thread was: no, the system works mostly ok.
> That makes me believe, we don't have a generic issue.
> 
> It's not my intention to blame anyone here, I'm still assuming best
> intentions.
> 
> Nevertheless, since people are different, and not everybody can be
> friends with each other, maybe it's a good idea to make communication
> mandatory, in cases where proven packagers touch others packages? For
> mass changes, there is/should always be an announcement to the
> devel mailing list.
> 
> Matthias
> -- 
> Matthias Runge <mru...@matthias-runge.de>
> ___
> devel m

Re: What to I have to do....

[Philip Kovacs]

s/do want/do NOT want 

On Saturday, December 9, 2017 1:21 PM, Philip Kovacs <pkde...@yahoo.com> 
wrote:
 

 I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
<mru...@matthias-runge.de> wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge <mru...@matthias-runge.de>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   

   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Philip Kovacs]

I am opposed to allowing PP unfettered access to projects in which the 
maintainer(s) are responsive.  It's common for developers to have artistic 
(volatile) temperaments , like a painter who paints on canvas owned by someone 
else.  Does the owner have the right to change the color jars?  Perhaps.  Does 
the  owner have the right to look at the painting and say "I don't like the way 
you painted that tree.  I'm going to change it."  Absolutely not.
Perhaps add a project setting that allows package maintainers to configure how 
PP changes can be made, by direct commit, by pull request, etc.  That would 
allow maintainerswho are more "involved" with their packages to have more 
control.   It's a common management problem.  People who have taken on 
responsibility must also have control to the extent to which system allows.  
You certainly do want to drive good people away..  

On Saturday, December 9, 2017 5:06 AM, Matthias Runge 
 wrote:
 

 On Fri, Dec 08, 2017 at 08:30:20PM +0100, Matthias Runge wrote:
> Now this has gone back and forth. The system worked more or less ok.
> Maybe it is more about the changes (and communication) of a
> specific provenpackager?

After sleeping a night over this, I should have put it in different
words:

My questionis are here:
- do we have an issue at all?
- do we have an issue with a single provenpacker
- do we have an issue of attitude or with a group of people?

The consensus of this long thread was: no, the system works mostly ok.
That makes me believe, we don't have a generic issue.

It's not my intention to blame anyone here, I'm still assuming best
intentions.

Nevertheless, since people are different, and not everybody can be
friends with each other, maybe it's a good idea to make communication
mandatory, in cases where proven packagers touch others packages? For
mass changes, there is/should always be an announcement to the
devel mailing list.

Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Basic package split question

[Philip Kovacs]

>> You need to add Obsoletes: foo < 2

>Sorry, hit send too early. You need to add such obsoletes BOTH to foo and foo-
>bar.
Adding obsoletes foo < 2 on both packages worked.  Thanks much. 

On Saturday, December 2, 2017 4:28 AM, Igor Gnatenko 
<ignatenkobr...@fedoraproject.org> wrote:
 

 -BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2017-12-02 at 10:25 +0100, Igor Gnatenko wrote:
> On Sat, 2017-12-02 at 09:24 +0100, Mattia Verga wrote:
> > Il 01/12/2017 20:20, Philip Kovacs ha scritto:
> > > If I have version 1 of package foo, containing items bar, xxx, yyy, 
> > > zzz, i.e.
> > > 
> > > foo-1
> > > -
> > > bar
> > > xxx
> > > yyy
> > > zzz
> > > 
> > > and, for version 2, bar is split off to its own sub-package, foo-bar, 
> > > so that
> > > the desired packaging becomes:
> > > 
> > > foo-2  foo-bar-2
> > > -  -
> > > xxx          bar
> > > yyy
> > > zzz
> > > 
> > > with foo-bar permanently requiring foo going forward.  How does one 
> > > structure the
> > > Obsoletes/Requires such that foo-2 pulls in foo-bar-2 only once, 
> > > during the upgrade
> > > from 1 to 2?
> > > 
> > > What is the best practice for this?
> 
> You need to add Obsoletes: foo < 2

Sorry, hit send too early. You need to add such obsoletes BOTH to foo and foo-
bar.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAloicagACgkQaVcUvRu8
X0wmsg/9HpU/b7rm2FjfV296awFOc+TlLyoIFNJNshoeWm44WvGOu+wGOXHpfjQ6
JUE+NtZTR/DRIr7IMsXDuHfNoHa4oAH2VxIbwq/PjmPZDPdmxq0D9I/JOwhZX3yI
BUhqiDd9W5sB9Rv9ZWuuS359UnOgkSbrYKWUgYX2dlzP4oZGBij10RRU8KyLcTP7
NFcgyV4rkUnWUCndqP8rZLKyRR+vMc0ABiF8jXe8MoKOSDJdxaopgz/kaaxLyWBg
2Uvnn2gLanwIL/iaYWYabCG88pEq0JrR68HpeXFDChFGJGmiumJEoSsPois8WI9t
r+DoZAfNDNowBsG69HyrPmRgZHVT26+/f1UsX+EwX0siEGyuoqowcpabDTdmQ6gW
qTcDMZ6zQ5xLs/57GyrN/auE6kTmCyFsdaGHE6pUoL9vlna9NNBvqNFIItMMhhpO
ffqeedxpRGQRsA0EaR/1kOEGpxJZkQEXW3/AheA0Yzb/O9O8McT4XwxfJPe/5uLg
sr9+AYRkd2Akpz25IjIOIHhws9ienOiqZl0JI0mw/R24PPUmdVXTehNNh/NvJzDf
nqrFcp8+XXpgsD2qakpwq9xbDTVIFIr7RHRMz5kohuy4cJuetim6e3onC/8Mej8O
itLTGAcoK+XR8YOiIoxAbbAM05VA7SauAFv0DejUOvmFPeGR9S0=
=1qgG
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Basic package split question

[Philip Kovacs]

If I have version 1 of package foo, containing items bar, xxx, yyy, zzz, i.e.
foo-1-barxxxyyyzzz
and, for version 2, bar is split off to its own sub-package, foo-bar, so that 
the desired packaging becomes:
foo-2         foo-bar-2-         -xxx           baryyyzzz
with foo-bar permanently requiring foo going forward.  How does one structure 
theObsoletes/Requires such that foo-2 pulls in foo-bar-2 only once, during the 
upgradefrom 1 to 2?  
What is the best practice for this? 
TIA
Philip

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: -Wl,--as-needed by default

[Philip Kovacs]

One concern is that -Wl,--as-needed requires greater accuracy with the ordering 
of objects and 
libraries as you link.   Also, if a package uses a library indirectly, i.e. A 
uses C via B: A -> B -> C,--as-needed will peel away C and break A unless A 
explicitly mentions its need for C.  Of course that should be the case already, 
but you're going to see a number of weaknesses in the variouspackages revealed 
by adding --as-needed.

On Monday, November 13, 2017 5:48 PM, Tomasz Kłoczko 
 wrote:
 

 On 13 November 2017 at 22:01, Tomasz Kłoczko  wrote:
[..]
> In other words -Wl,--as-needed should be used everywhere WITHOUT exceptions.
> Easiest way apply this globally in Fedora is add --as-needed in
> /usr/lib/rpm/redhat/redhat-hardened-ld spec file by apply patch:
>
> --- /usr/lib/rpm/redhat/redhat-hardened-ld.orig
> +++ /usr/lib/rpm/redhat/redhat-hardened-ld
> @@ -2,4 +2,4 @@
>  + %{!static:%{!shared:%{!r:-pie}}}
>
>  *link:
> -+ -z now
> ++ -z now --as-needed

Just created pull request with above change:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3#request_diff

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Requires for local install

[Philip Kovacs]

Or use Fedora Copr to create personal repos for your projects.  There is a lot 
of utility in doing that,esp.  when you start dealing with multiple boxes or 
vms.  Doing local installs directly from rpms doesnot scale and becomes tedious 
very quickly.  If you're writing or modifying the spec yourself, try Copr.
https://copr.fedorainfracloud.org/
 

On Saturday, September 23, 2017 9:52 AM, Matthew Miller 
 wrote:
 

 On Fri, Sep 22, 2017 at 09:47:15PM -0400, David Muse wrote:
> But, when doing a yum localinstall or dnf install with a local path,
> the user has to either install all rpm's or manually resolve
> dependencies.
> 
> Is it common to specify inter-subpackage dependencies using Requires
> to resolve this, or are users just on their own if they're
> installing packages manually?

You should certainly use inter-subpackage requires in any case, if they
are genuine. But that won't help DNF (or Yum), as with local install
they only know about the files they are told about. But, what you
*could* do is:

 1. run "createrepo_c" on your directory of downloaded RPMs,
 2. use `dnf --repofrompath local,.`, and then
 3. use `dnf install packagename`

In step 1, createrepo_c is a drop-in but faster replacement for
createrepo.

In step 2, the syntax is "--repofrompath made-reponame,path", so you
could do '--repofrompath "My Repository",/home/mattdm/Downloads/RPMs'.

In step 3, use the package name not the file name, so no .rpm on the
end.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


   ___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Introduction

[Philip Kovacs]

Hello all.  My name is Philip Kovacs and I would like to introduce myself.
I'm in the US and I've been in software development for more than 25 years.  My 
interests are in parallel and distributed computing, cloud, networking, 
virtualization, container technology, performance monitoring, bunch of 
otherthings.  I have very strong C/C++, golang and scripting skills.  I've been 
using Fedora and EL professionally and personally for many years.  
Recently I decided to write a new rpm spec for the Slurm HPC resource 
managerand try to get that software accepted into Fedora.  I've been working 
closely with upstream on bugs and have cleared the issues blocking the package. 
 I am happy to report that the package has passed the review.  It was a fair 
amount of work to get just right. 
I am grateful to reviewer Robert-Andre Mauchin for his timely interaction 
duringthe review process.  
https://bugzilla.redhat.com/show_bug.cgi?id=1489668
Would someone consider sponsoring me into the maintainers group?
Regards,
Philip___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org