Re: [ELN] bpeck/jenkins-continuous-infra.apps.ci.centos.org's vtk-8.2.0-18.eln103 failed to build

[Orion Poplawski]

On 8/6/20 3:26 AM, Aleksandra Fedorova wrote:

Hi,

On Thu, Aug 6, 2020 at 5:01 AM Orion Poplawski  wrote:


So, I'm getting one of these messages every couple of hours and I'd
really rather not.  Who do I need to talk to about it?


You can talk about it with the ELN SIG [1] or Fedora CI SIG [2]. Mail
thread on devel works, we recommend to use [ELN] as a tag in the
subject, but this works too.

So let me explain first what is going on, and then what we are going
to do about it.

1) Why do you get the message?

We don't send messages to you or anyone directly. We trigger koji
builds for packages which are considered part of the ELN buildroot.


Sorry, but this is a bit like saying we don't splash you with water, we 
just throw a rock in that lake you are standing next to :)



2) Why do you get them so often?

The goal of the ELN is to contain exactly the same versions of the
packages which were built for Rawhide.

To achieve that goal we have automation, which rebuilds Rawhide
packages for the ELN buildroot. This automation is triggered when a
new package is tagged to f33 koji tag.
Thus ideally you would get just one eln-related message per package update.

Now, as Fedora Mass Rebuild happened over the weekend, there was a
mass retagging event, which automation couldn't process at once. And
we got the backlog of 3500 packages, which we need to rebuild for eln.

To not overload koji, rather than sending all of these packages to be
built at once, we added a background process, which regularly chooses
some random packages from the backlog and sends it to koji.

With this helper script in three days we managed to reduce the backlog
to 190 packages, and then, with some additional filtering, to 40. So
now we have about 40 packages and the script which chooses random
packages from the list hits you package again and again. Sorry for
that.


Okay, glad to hear that this was hopefully a one-time thing.  The 
frequency was a bit much.



3) What can you do about it?


...

Option 3: Join the ELN effort :)


In general as a big EPEL user/packager I'm more than happy to help with 
the ELN effort.  Again, was just concerned that this was going to be the 
norm.



FWIW - It seems to fail because of missing deps:

DEBUG util.py:621:  No matching package to install: 'cmake(Qt5)'
DEBUG util.py:621:  No matching package to install: 'cmake(Qt5X11Extras)'



Thanks for looking at it.

Afaik we have qt5-5.14.2-4.eln103 in the eln buildroot, so it is not
clear for me why this dependency resolution fails, but we will look
into it.


It looks to me like the cmake automatic rpm provides generator is 
failing for some reason.  Compare the provides from the qt5-qtbase ELN 
build to the Fedora one.



Thanks,

Orion


[1] https://fedoraproject.org/wiki/SIGs/ELN
[2] https://fedoraproject.org/wiki/SIGs/CI
[3] https://apps.fedoraproject.org/notifications
[4] https://pagure.io/releng/issue/9619
[5] https://hopin.to/events/nest-with-fedora#schedule





--
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/



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: [ELN] Opt out python2.7 from ELN

[Miro Hrončok]

On 08. 08. 20 1:03, Miro Hrončok wrote:

On 08. 06. 20 16:49, Miro Hrončok wrote:

Hello,

as a maintainer of the python2.7 package I was surprised to see it being built 
for ELN and I like to start a discussion on whether and how can I opt out this 
deprecated package from ELN.


Since there is no tracker or dedicated mailing list, I am following the advice 
given somewhere else on devel, to use this list, possibly with the [ELN] 
marker in subject.


Thanks,


After couple months, I still see python2.7, python3.8 and python3.6 being build 
in ELN, despite them being marked as unwanted in


https://github.com/minimization/content-resolver-input

While I understand that python2.7 might still be pulled in as dependency by 
other ELN packages (presumably gimp), I don't understand why is python3.8 and 
python3.6 built.


Is there anybody from the ELN SIG who would help me solve this?

Is this the proper communication channel?


In case it is not, I've also opened

https://github.com/minimization/content-resolver-input/issues/162

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: [ELN] Opt out python2.7 from ELN

[Miro Hrončok]

On 08. 06. 20 16:49, Miro Hrončok wrote:

Hello,

as a maintainer of the python2.7 package I was surprised to see it being built 
for ELN and I like to start a discussion on whether and how can I opt out this 
deprecated package from ELN.


Since there is no tracker or dedicated mailing list, I am following the advice 
given somewhere else on devel, to use this list, possibly with the [ELN] marker 
in subject.


Thanks,


After couple months, I still see python2.7, python3.8 and python3.6 being build 
in ELN, despite them being marked as unwanted in


https://github.com/minimization/content-resolver-input

While I understand that python2.7 might still be pulled in as dependency by 
other ELN packages (presumably gimp), I don't understand why is python3.8 and 
python3.6 built.


Is there anybody from the ELN SIG who would help me solve this?

Is this the proper communication channel?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Fedora rawhide compose report: 20200807.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200806.n.0
NEW: Fedora-Rawhide-20200807.n.0

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  118
Dropped packages:1
Upgraded packages:   171
Downgraded packages: 0

Size of added packages:  41.29 MiB
Size of dropped packages:13.93 KiB
Size of upgraded packages:   7.09 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -65.52 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200807.n.0.x86_64.vagrant-virtualbox.box
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20200807.n.0.x86_64.vagrant-libvirt.box
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20200807.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200807.n.0.x86_64.vagrant-libvirt.box

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: clash-1.0.0-4.fc33
Summary: A rule-based tunnel in Go
RPMs:clash golang-github-dreamacro-clash-devel
Size:14.11 MiB

Package: lector-0.5.1-2.fc33
Summary: Ebook reader and collection manager
RPMs:lector
Size:580.77 KiB

Package: perl-Algorithm-Diff-1.1903-17.module_f33+9481+2b9430bf
Summary: Compute `intelligent' differences between two files/lists
RPMs:perl-Algorithm-Diff
Size:47.52 KiB

Package: perl-Archive-Tar-2.38-3.module_f33+9481+2b9430bf
Summary: A module for Perl manipulation of .tar files
RPMs:perl-Archive-Tar
Size:72.88 KiB

Package: perl-Archive-Zip-1.68-3.module_f33+9481+2b9430bf
Summary: Perl library for accessing Zip archives
RPMs:perl-Archive-Zip
Size:107.39 KiB

Package: perl-CPAN-2.28-4.module_f33+9481+2b9430bf
Summary: Query, download and build perl modules from CPAN sites
RPMs:perl-CPAN
Size:545.65 KiB

Package: perl-CPAN-DistnameInfo-0.12-20.module_f33+9481+2b9430bf
Summary: Extract distribution name and version from a distribution filename
RPMs:perl-CPAN-DistnameInfo
Size:14.56 KiB

Package: perl-CPAN-Meta-2.150010-457.module_f33+9481+2b9430bf
Summary: Distribution metadata for a CPAN dist
RPMs:perl-CPAN-Meta
Size:176.15 KiB

Package: perl-CPAN-Meta-Requirements-2.140-458.module_f33+9481+2b9430bf
Summary: Set of version requirements for a CPAN dist
RPMs:perl-CPAN-Meta-Requirements
Size:31.65 KiB

Package: perl-CPAN-Meta-YAML-0.018-458.module_f33+9481+2b9430bf
Summary: Read and write a subset of YAML for CPAN Meta files
RPMs:perl-CPAN-Meta-YAML
Size:26.34 KiB

Package: perl-Carp-1.50-457.module_f33+9481+2b9430bf
Summary: Alternative warn and die for modules
RPMs:perl-Carp
Size:29.14 KiB

Package: perl-Compress-Bzip2-2.28-2.module_f33+9481+2b9430bf
Summary: Interface to Bzip2 compression library
RPMs:perl-Compress-Bzip2
Size:346.83 KiB

Package: perl-Compress-Raw-Bzip2-2.096-1.module_f33+9481+2b9430bf
Summary: Low-level interface to bzip2 compression library
RPMs:perl-Compress-Raw-Bzip2
Size:170.52 KiB

Package: perl-Compress-Raw-Lzma-2.096-1.module_f33+9481+2b9430bf
Summary: Low-level interface to lzma compression library
RPMs:perl-Compress-Raw-Lzma
Size:247.01 KiB

Package: perl-Compress-Raw-Zlib-2.096-1.module_f33+9481+2b9430bf
Summary: Low-level interface to the zlib compression library
RPMs:perl-Compress-Raw-Zlib
Size:301.73 KiB

Package: perl-Config-Perl-V-0.32-458.module_f33+9481+2b9430bf
Summary: Structured data retrieval of perl -V output
RPMs:perl-Config-Perl-V
Size:21.42 KiB

Package: perl-DB_File-1.853-458.module_f33+9481+2b9430bf
Summary: Perl5 access to Berkeley DB version 1.x
RPMs:perl-DB_File
Size:405.51 KiB

Package: perl-Data-Dumper-2.174-458.module_f33+9481+2b9430bf
Summary: Stringify perl data structures, suitable for printing and eval
RPMs:perl-Data-Dumper
Size:278.91 KiB

Package: perl-Data-OptList-0.110-14.module_f33+9481+2b9430bf
Summary: Parse and validate simple name/value option pairs
RPMs:perl-Data-OptList
Size:26.48 KiB

Package: perl-Data-Section-0.27-11.module_f33+9481+2b9430bf
Summary: Read multiple hunks of data out of your DATA section
RPMs:perl-Data-Section
Size:24.97 KiB

Package: perl-Devel-PPPort-3.58-4.module_f33+9481+2b9430bf
Summary: Perl Pollution Portability header generator
RPMs:perl-Devel-PPPort
Size:850.71 KiB

Package: perl-Devel-Size-0.83-7.module_f33+9481+2b9430bf
Summary: Perl extension for finding the memory usage of Perl variables
RPMs:perl-Devel-Size
Size:155.90 KiB

Package: perl-Digest-1.17-457.module_f33+9481+2b9430bf
Summary: Modules that calculate message digests
RPMs:perl-Digest
Size:24.40 KiB

Package: perl-Digest-MD5-2.55-458.module_f33+9481+2b9430bf
Summary: Perl interface to the MD5 algorithm

Re: mame fails to build with LTO enabled

[Julian Sikorski]

W dniu 07.08.2020 o 17:02, Jeff Law pisze:

On Fri, 2020-08-07 at 07:19 +0200, Julian Sikorski wrote:

Hi list,

mame has failed to build with lto enabled due to violation of C++ one
definition rule apparently:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48829086
I don't really know how to fix it. I am going to disable lto for now as,
according to upstream comment from 2017, mame is likely too big for LTO
to work anyway [1].
If anybody would like to help re-enabling the lto, support is
appreciated. Thanks!


In simplest terms you're not allowed to have a type with global scope with
different definitions.  Look at how BREGS is defined in necpriv.h and v25priv.h.
  THe enum type has the same name (BREGS), but the values in the enum are
different.

Similarly you've got some structures with the same name and external scope, but
with differences in their members (extFloat80M)

Jeff


Thanks! I will attempt a patch once I fix unrelated non-x86 build failures.

Best regards,
Julian

___
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: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

[Jeff Law]

On Tue, 2020-08-04 at 13:16 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 04, 2020 at 12:02:05PM +0200, Florian Weimer wrote:
> > * Daniel P. Berrangé:
> > 
> > > Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923
> > 
> > Sorry, what would be more interesting is the linker invocation.  The
> > build log does not show this, only the libtool invocation.  We don't
> > really know what kind of transformations libtool does in this case.
> 
> Upstream libvirt has just yesterday replaced use of autotools with
> meson. I just tried a Fedora rawhide build of our new meson based
> code and it succeeded with LTO.
> 
> Given this, I think I'm fine just disabling LTO in rawhide for the
> current libvirt release, with the expectation we'll re-enable LTO
> in ~1 month time when we import the meson based release of libvirt.
> 
> IOW lets not waste any more time debugging this LTO / LD_PRELOAD
> problem with libvirt.
That works for me.  If you haven't already committed the change, please make a
quite note about the planned move to meson and reenablement of LTO at that point
so I don't dig any further when I review all the opted-out packages.  I'm likely
to forget the decision by the time I'm reviewing the opt-outs.


> 
> > libtool is really not built for LTO, and it really should not be used on
> > GNU systems.  But I understand that this is not uncontroversial.
> There's oooh so many problems with libtool we've hit over the years,
> especially with it re-arranging order of compiler/linker flags, and
> so I'm beyond ecstatic that we've finally thrown it away for libvirt
> in favour of meson.
> 
> There may have been a time & place for libtool and autotools in
> general, but that time has passed
Yea, I find libtool amazingly painful and the primary motivation for it has long
since become a minor issue rather than major one (seriously who cares about
dynamic linking on hpux, sco, irix, etc) anymore.  But killing it I'm sure will
be difficult.

jeff
> 
___
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: What do to about massive # of FTBFS bugs?

[Jeff Law]

On Fri, 2020-08-07 at 17:08 +0200, Dominique Martinet wrote:
> Fabio Valentini wrote on Fri, Aug 07, 2020:
> > - waypipe / armv7hl:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713
> 
> See the "arm/neon LTO-related FTBS" thread on the list for that one; I
> gave a short recap on the last message on Thursday (Aug 6)
> 
> 
> I'm still unsure if I should disable LTO for now or just patiently wait
> for help at this point, so I'll give Jeff and others another week or two
> first :)
Thanks.  I'm about done with my pass over the failures to find those that are
obviously LTO related and get those assigned to me.

Jeff
> 
___
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: What do to about massive # of FTBFS bugs?

[Dominique Martinet]

Fabio Valentini wrote on Fri, Aug 07, 2020:
> - waypipe / armv7hl:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713

See the "arm/neon LTO-related FTBS" thread on the list for that one; I
gave a short recap on the last message on Thursday (Aug 6)


I'm still unsure if I should disable LTO for now or just patiently wait
for help at this point, so I'll give Jeff and others another week or two
first :)

Please say if there's anything I can do to help without access to any
arm hardware :/
-- 
Dominique
___
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: InsightToolkit LTO build failure

[Jeff Law]

On Thu, 2020-08-06 at 20:40 -0600, Orion Poplawski wrote:
> On 8/6/20 9:01 AM, Jeff Law wrote:
> > On Thu, 2020-08-06 at 08:03 -0600, Orion Poplawski wrote:
> > > InsightToolkit fails to build with LTO:
> > > 
> > > /usr/bin/ld.gold: fatal error: lto-wrapper failed
> > > collect2: error: ld returned 1 exit status
> > > gmake[2]: ***
> > > [Modules/Filtering/ImageIntensity/test/CMakeFiles/ITKImageIntensityTestDriver.dir/build.make:1307:
> > > bin/ITKImageIntensityTestDriver] Error 1
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48777433
> > > 
> > > I'm disabling for now.  Let me know where I should file a bug if needed.
> > No need to file a bug right now.  Once we're past the mass rebuild we'll 
> > review
> > everything that's opted out and see what upstream actions need to be taken.
> > 
> > Note that it appears this package is using the "gold" linker.  That's been
> > deprecated upstream, so you might want to look at transitioning away to 
> > either
> > ld.bfd or lld.
> > 
> > Thanks,
> > jeff
> > 
> 
> Thanks.  However it appears to fails the same way with "ld" (presumably 
> ld.bfd):
I didn't expect it to change, I just wanted to make sure you were aware that
ld.gold is being deprecated and you might want to transition away from it.

Jeff
> 
___
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: mame fails to build with LTO enabled

[Jeff Law]

On Fri, 2020-08-07 at 07:19 +0200, Julian Sikorski wrote:
> Hi list,
> 
> mame has failed to build with lto enabled due to violation of C++ one
> definition rule apparently:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48829086
> I don't really know how to fix it. I am going to disable lto for now as,
> according to upstream comment from 2017, mame is likely too big for LTO
> to work anyway [1].
> If anybody would like to help re-enabling the lto, support is
> appreciated. Thanks!

In simplest terms you're not allowed to have a type with global scope with
different definitions.  Look at how BREGS is defined in necpriv.h and v25priv.h.
 THe enum type has the same name (BREGS), but the values in the enum are
different.

Similarly you've got some structures with the same name and external scope, but
with differences in their members (extFloat80M)

Jeff
___
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: LXQT: FTBFS Requires

[Евгений Пивнев]

Ok, I’ll fix them.

> 7 авг. 2020 г., в 14:28, Mamoru TASAKA  написал(а):
> 
> Евгений Пивнев wrote on 2020/08/07 20:07:
>> 1. libsysstat and libqtxdg required by LXQT only (?)
>> 2. they are incompilable now in f33 
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1864053 
>>  
>> https://bugzilla.redhat.com/show_bug.cgi?id=1864039 
>> )
>> 3. but lqxt-0.15.0 built ok without them (?)
>> So, the question is - what about to kill them in f33+ at all?
> 
> That those packages FTBFS does not mean that they become unavailable at 
> buildroot immediately.
> Packages depending on those packages use the ones that were previously built 
> successfully.
> Actually building lxqt packages are using previously built libsysstat or 
> libqtxdg.
> But if we leave those packages unbuildable, at some day they gets retired 
> forcibly, which means
> that lxqt packages becomes unbuildable at that time.
> 
> So the correct solution (for now) is to fix FTBFS status for those packages.
> 
> Regards,
> Mamoru
> ___
> 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: Coin4 build failure

[Richard Shaw]

On Fri, Aug 7, 2020 at 7:27 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Thu, Aug 06, 2020 at 07:58:10PM -0500, Richard Shaw wrote:
> > /builddir/build/BUILD/coin-6enkw/src/xml/expat/xmlparse.c:94:3: error:
> > #error You do not have support for any sources of high quality entropy
> > enabled. For end user security, that is probably not what you want.
>
> > Your options include:
> > * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM
> > * Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM
> > * BSD / macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF
> ...
>
> The first one is the one you want. So the question is how to get the
> compilation script to detect that. Maybe just -DHAVE_GETRANDOM will work?
>

Nope, but I think I got it fixed. Cmake was complaining that it couldn't
find expat, which I don't remember seeing before so I added it. Now the
build completes.

Something must have changed in Rawhide at some point, no clue what, but
it's "fixed".

Thanks everyone!

Richard
___
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: Coin4 build failure

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 06, 2020 at 07:58:10PM -0500, Richard Shaw wrote:
> /builddir/build/BUILD/coin-6enkw/src/xml/expat/xmlparse.c:94:3: error:
> #error You do not have support for any sources of high quality entropy
> enabled. For end user security, that is probably not what you want.

> Your options include:
> * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM
> * Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM
> * BSD / macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF
...

The first one is the one you want. So the question is how to get the
compilation script to detect that. Maybe just -DHAVE_GETRANDOM will work?

Zbyszek
___
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: Coin4 build failure

[Richard Shaw]

On Fri, Aug 7, 2020 at 7:21 AM J. Scheurich  wrote:

> About a question related to #error...
>
> On 8/7/20 2:12 PM, Richard Shaw wrote:
> > So I was curious what the error was, but my bigger question is, what
> > changed?
> >
> > This was just a rebuild for the CMake change FTBFS. I have not changed
> > anything other than what was necessary to fix the CMake commands.
>
> Maybe the source maintainers improooved securitiy related things ?
>

Coin4 upstream? I haven't changed anything to do with the source.

Thanks,
Richard
___
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: Coin4 build failure

[J. Scheurich]

About a question related to #error...

On 8/7/20 2:12 PM, Richard Shaw wrote:

So I was curious what the error was, but my bigger question is, what
changed?

This was just a rebuild for the CMake change FTBFS. I have not changed
anything other than what was necessary to fix the CMake commands.


Maybe the source maintainers improooved securitiy related things ?

so long
MUFTI
___
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: Coin4 build failure

[Richard Shaw]

So I was curious what the error was, but my bigger question is, what
changed?

This was just a rebuild for the CMake change FTBFS. I have not changed
anything other than what was necessary to fix the CMake commands.

Thanks,
Richard
___
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: LXQT: FTBFS Requires

[Mamoru TASAKA]

Евгений Пивнев wrote on 2020/08/07 20:07:

1. libsysstat and libqtxdg required by LXQT only (?)
2. they are incompilable now in f33 (https://bugzilla.redhat.com/show_bug.cgi?id=1864053 
 
https://bugzilla.redhat.com/show_bug.cgi?id=1864039 
)
3. but lqxt-0.15.0 built ok without them (?)

So, the question is - what about to kill them in f33+ at all?



That those packages FTBFS does not mean that they become unavailable at 
buildroot immediately.
Packages depending on those packages use the ones that were previously built 
successfully.
Actually building lxqt packages are using previously built libsysstat or 
libqtxdg.
But if we leave those packages unbuildable, at some day they gets retired 
forcibly, which means
that lxqt packages becomes unbuildable at that time.

So the correct solution (for now) is to fix FTBFS status for those packages.

Regards,
Mamoru
___
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: LXQT: FTBFS Requires

[Peter Robinson]

> 1. libsysstat and libqtxdg required by LXQT only (?)
> 2. they are incompilable now in f33 
> (https://bugzilla.redhat.com/show_bug.cgi?id=1864053 
> https://bugzilla.redhat.com/show_bug.cgi?id=1864039)
> 3. but lqxt-0.15.0 built ok without them (?)
>
> So, the question is - what about to kill them in f33+ at all?

Well just looking at libsysstat, it's used just by lxqt-panel, and
looking at that it's used by the plugin-sysstat option, so if you
remove it that functionality will disappear. Also in this context
libsysstat is a LXDE library so it's not particularly surprising it's
only used by that project.

I think the same goes for the libqtxdg, I suspect things will build
but you'll lose functionality.

But looking at the FTBFS builds in koji it should be a simple fix for
the builds because of the cmake build changes.

Peter
___
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

LXQT: FTBFS Requires

[Евгений Пивнев]

1. libsysstat and libqtxdg required by LXQT only (?)
2. they are incompilable now in f33 
(https://bugzilla.redhat.com/show_bug.cgi?id=1864053 
 
https://bugzilla.redhat.com/show_bug.cgi?id=1864039 
)
3. but lqxt-0.15.0 built ok without them (?)

So, the question is - what about to kill them in f33+ at all?___
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: Coin4 build failure

[Björn Persson]

> You do not have support for any sources of high quality entropy
> enabled. For end user security, that is probably not what you want. Your
> options include: * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM, *
> Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD
> / macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF, * BSD / macOS <10.7
> (arc4random): HAVE_ARC4RANDOM, * libbsd (arc4random_buf):
> HAVE_ARC4RANDOM_BUF + HAVE_LIBBSD, * libbsd (arc4random): HAVE_ARC4RANDOM +
> HAVE_LIBBSD, * Linux / BSD / macOS (/dev/urandom): XML_DEV_URANDOM *
> Windows (RtlGenRandom): _WIN32. If insist on not using any of these,
> bypass this error by defining XML_POOR_ENTROPY; you have been warned.
> If you have reasons to patch this detection code away or need changes
> to the build system, please open a bug. Thank you!

My interpretation is that they want you to choose a source of
randomness by defining one of those macros, so can you get the build
system to pass -DXML_DEV_URANDOM to g++?

Björn Persson


pgpPcZvc6LN8c.pgp
Description: OpenPGP digital signatur
___
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: What do to about massive # of FTBFS bugs?

[Fabio Valentini]

On Thu, Aug 6, 2020 at 10:52 PM Jeff Law  wrote:
> On Thu, 2020-08-06 at 17:54 +0200, Fabio Valentini wrote:
> > I can compile a list, if it helps.
> Sure that helps.

Those are the "suspicious" issues I found on non-x86_64 platforms:
(I excluded packages that have been "fixed" by disabling LTO in the meantime.)

- botan2 / armv7hl: https://koji.fedoraproject.org/koji/taskinfo?taskID=48430105
- dd_rescue / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48686467
- firebird / s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=48493584
- gdb / ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=48619025
- gnutls / ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=48651407
- graphehe / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48600725
- grep / ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=48682540
- gtatool / ppc64le:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48720554
- libscrypt / s390x:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48531225
- m4 / ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=48720088
- mathicgb / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48648746
- mono / ppc64le: https://koji.fedoraproject.org/koji/taskinfo?taskID=48645851
- nest / armv7hl: https://koji.fedoraproject.org/koji/taskinfo?taskID=48408044
- prelude-lml / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48719262
- sbcl / aarch64: https://koji.fedoraproject.org/koji/taskinfo?taskID=48586438
- scummvm / i686: https://koji.fedoraproject.org/koji/taskinfo?taskID=48493515
- tiny-dnn / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48719921
- trickle / s390x: https://koji.fedoraproject.org/koji/taskinfo?taskID=48623165
- waypipe / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48698713
- zynaddsubfx / armv7hl:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48687956

There may be more, I haven't looked at x86_64 failures separately yet.

Fabio
___
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: vim has lost it's damn mind

[Jonathan Wakely]

On 06/08/20 11:34 -0400, John Florian wrote:

I understand better now my problems with my mappings.  Above, I said I
had a mapping for  :nohlsearch.  In actuality, this was ^E
:nohlsearch.  Both should work but only the latter now only works
with vim; gvim shows the mapping with :map but I can't make it trigger.


A mapping for "^E" (i.e. the two characters '^' and 'E') doesn't work
in vim or gvim for me.  works in both, and so does the literal
control character entered into my vimrc with CTRL-V CTRL-E.

I get the same results on two up-to-date KDE desktops but also a
headless CentOS 6.10 server.

Silly question: are you actually using the same version for vim and
gvim? Do you have some different version of vim in your path?


I still don't know what's up with the yaml indenting.  I'll have to
check on the cindent setting that's been brought up recently.  I also


You can check whether cindent is enabled in a given file (e.g. after
opening a yaml file) with ':set cindent?'

If you put 'finish' right at the top of you personal vimrc and check
':set cindent?' again you'll see whether its presence/absence is
affected by something in your vimrc. If it's on even when you make
your personal vimrc 'finish' before changing anything, then it's
coming from global settings not personal ones.



don't understand the new Ctrl-6 behavior, but I suspect that's konsole
that's changed.

___
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

Build failure of zynaddsubfx on armv7hl

[Guido Aulisi]

Hi,

I got a segmentation fault trying to rebuild zynaddsubfx [0].

I pasted the main build.log below.

I found some strange compiler options passed by the build system and
g++ warns about that:
cc1plus: warning: switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' 
switch

Is this an annobin or lto problem?
Do I need to disable lto?

Thanks

Ciao
Guido
FAS: tartina

---
cc1plus: warning: switch '-mcpu=cortex-a9' conflicts with '-march=armv7-a' 
switch
*** WARNING *** there are active plugins, do not report this as a bug unless 
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START  | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
during IPA pass: icf
In member function 'replyArray':
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: /usr/bin/g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/UI/CMakeFiles/zynaddsubfx-ext-gui.dir/build.make:116: 
src/UI/zynaddsubfx-ext-gui] Error 1
gmake[2]: Leaving directory 
'/builddir/build/BUILD/zynaddsubfx-3.0.5/armv7hl-redhat-linux-gnueabi'
gmake[1]: *** [CMakeFiles/Makefile2:2313: 
src/UI/CMakeFiles/zynaddsubfx-ext-gui.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs

[0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=48863016


___
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: Segmentation fault (core dumped) doxygen docs/doxygen.cfg when compiling sayonara

[Martin Gansser]

opened a bugzilla ticket [1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1867025
___
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

Orphaned rubygem-wikicloth

[Vít Ondruch]

Hi everybody,

I don't have any use for rubygem-wikicloth, therefore I orphaned the
package.


Ví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

evolution-ews license change

[Milan Crha]

Hello,
the upstream license for evolution-ews had been LGPL-2.1-or-later, but
the sources didn't reflect it properly, thus it had been corrected
upstream. The distgit in Fedora will correct the version as well, from
LGPLv2 to LGPLv2+, together with the 3.37.90 release.
Bye,
Milan

___
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