Re: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> But... in 2.35 you can give the DWARF level you want.
> The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> dwarf_level is never set! And then gas will happily create an
> .debug_info section with DWARF CUs that have a version of zero (!).

Doh!

> This, defaulting to version 4. Fixes it for me:
> 
> diff --git a/gas/as.c b/gas/as.c
> index 4c5881abd88..c2da78870ef 100644
> --- a/gas/as.c
> +++ b/gas/as.c
> @@ -103,7 +103,7 @@ int verbose = 0;
>  int flag_dwarf_cie_version = -1;
>  
>  /* The maximum level of DWARF DEBUG information we should manufacture.  */
> -unsigned int dwarf_level = 0;
> +unsigned int dwarf_level = 4;
>  
>  #if defined OBJ_ELF || defined OBJ_MAYBE_ELF
>  int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON;

I will apply this patch to the rawhide binutils (and the upstream binutils 
sources).

Thanks for finding the problem Mark.

Cheers
  Nick

___
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: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2020-07-30 16:00 UTC)

[Miro Hrončok]

On 30. 07. 20 3:25, James Antill wrote:

  Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-07-30 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

  Local time information (via. uitime):

= Day: Thursday ==
2020-07-30 09:00 PDT  US/Pacific
2020-07-30 12:00 EDT  --> US/Eastern <--
2020-07-30 16:00 UTC  UTC
2020-07-30 17:00 BST  Europe/London
2020-07-30 18:00 CEST Europe/Berlin
2020-07-30 18:00 CEST Europe/Paris
2020-07-30 21:30 IST  Asia/Calcutta
 New Day: Friday -
2020-07-31 00:00 HKT  Asia/Hong_Kong
2020-07-31 00:00 +08  Asia/Singapore
2020-07-31 01:00 JST  Asia/Tokyo
2020-07-31 02:00 AEST Australia/Brisbane


My apologies, I will not be able to attend this meeting.

--
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: Duplicate package was reviewed

[Kevin Kofler]

Vitaly Zaitsev via devel wrote:
> Libqmatrixclient is a very old version of libquotient. Compatibility
> packages should have compat- prefix.

Independently of what the current packaging guidelines say about this 
(apparently, "compat-" is not even a thing anymore there, see Rathann's 
reply), it simply does not make sense to use any sort of prefixing or 
suffixing to the package name when the old and the new library have 
different package names (as in this case: libqmatrixclient vs. libquotient).

If the actual sonames are conflicting, then that needs to be dealt with (but 
that would be an upstream issue then, they ought to use a different soname 
if the libraries are not binary-compatible!), but it does not require 
mangling the package name.

Kevin Kofler
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> Hi Guys,
> 
> > But... in 2.35 you can give the DWARF level you want.
> > The problem with not supplying -g (or --gdwarf-[VERSION]) is that the
> > dwarf_level is never set! And then gas will happily create an
> > .debug_info section with DWARF CUs that have a version of zero (!).
> 
> Doh!
> 
> > This, defaulting to version 4. Fixes it for me:
> > 
> > diff --git a/gas/as.c b/gas/as.c
> > index 4c5881abd88..c2da78870ef 100644
> > --- a/gas/as.c
> > +++ b/gas/as.c
> > @@ -103,7 +103,7 @@ int verbose = 0;
> >  int flag_dwarf_cie_version = -1;
> >  
> >  /* The maximum level of DWARF DEBUG information we should manufacture.  */
> > -unsigned int dwarf_level = 0;
> > +unsigned int dwarf_level = 4;
> >  
> >  #if defined OBJ_ELF || defined OBJ_MAYBE_ELF
> >  int flag_use_elf_stt_common = DEFAULT_GENERATE_ELF_STT_COMMON;
> 
> I will apply this patch to the rawhide binutils (and the upstream binutils 
> sources).

Thanks Nick - I will test this as soon as  I see the binutils
package in Rawhide.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
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: We have to talk about annobin... again

[Kevin Kofler]

Jeff Law wrote:
> :(  I'll raise it again with Nick and Jakub, it's a sore point for
> everyone I think and it causes far more friction than just what we see
> here in Fedora.

IMHO, we should just drop annobin from Fedora (or at least disable it). It 
provides no tangible benefit to end users and the regular sync issues with 
the toolchain are a constant source of pain for packagers. Would it not be 
enough to do periodic rebuilds with annobin in a side tag to catch packages 
that are built with insecure or otherwise suboptimal flags, instead of 
burdening the production repository with this debugging tool?

Kevin Kofler
___
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: Disable LTO for now ?

[Vitaly Zaitsev via devel]

On 29.07.2020 15:59, Jeff Law wrote:
> In general I want to have a very good indicator the issue is LTO related 
> before I
> disable.  THe build you referenced doesn't have any good indicators that LTO 
> is
> the problem.

My packages nheko and mtxclient are failed due to LTO. Can you check
them? Currently built with Clang, but I can try to switch to GCC.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1558560
https://koji.fedoraproject.org/koji/buildinfo?buildID=1558793

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

Disabled LTO on qemu

[Richard W.M. Jones]

I just disabled LTO for qemu.

It caused what are best described as "weird" assert failures
in the test suite.

For comparison here's a good build (without LTO):
https://koji.fedoraproject.org/koji/taskinfo?taskID=48188577

And here's a bad build (with LTO):
https://koji.fedoraproject.org/koji/taskinfo?taskID=48182910

At some point we'll need to look at what's going on, but right now
disabling LTO was the easiest way to work around what might be
toolchain bugs.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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

Can we use emulation of other architectures to run integration tests?

[Aleksandra Fedorova]

Hi, all,

I'd like to get some understanding on the current state of emulation
of other architectures.

In the current CI infra we have infinite(*) access to x86_64 compute
resources, but we haven't yet got our hands on any non x86_64
hardware.

As COPR has recently got support for s390 builds, the question is: if
emulation is good enough for building packages, can we use it for
testing? What are the limitations there? Is it worth it?

If yes, can you suggest some links, tips on the topic?


(*) Not really, and some of our infra services are not yet good at
scaling up, but we are getting better at it.

-- 
Aleksandra Fedorova
bookwar
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> I will apply this patch to the rawhide binutils (and the upstream binutils 
> sources).

I don't know how worried we should be about this, but it seems every
test in the x86-64 build failed (although the build was successful):

https://kojipkgs.fedoraproject.org//work/tasks/6878/48186878/build.log

Whereas if we look at the corresponding x86-64 log from the previous
build the tests didn't fail:

https://kojipkgs.fedoraproject.org//packages/binutils/2.35/3.fc33/data/logs/x86_64/build.log

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: Can we use emulation of other architectures to run integration tests?

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote:
> Hi, all,
> 
> I'd like to get some understanding on the current state of emulation
> of other architectures.
> 
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on any non x86_64
> hardware.
> 
> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?
> 
> If yes, can you suggest some links, tips on the topic?

To be clear, are we talking qemu-system-X, qemu-user, or something
else entirely?  Are you planning to do the tests in a full VM (eg. in
qemu-system-X)?

Rich.

> 
> (*) Not really, and some of our infra services are not yet good at
> scaling up, but we are getting better at it.
> 
> -- 
> Aleksandra Fedorova
> bookwar
> ___
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: Can we use emulation of other architectures to run integration tests?

[Daniel P . Berrangé]

On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote:
> Hi, all,
> 
> I'd like to get some understanding on the current state of emulation
> of other architectures.
> 
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on any non x86_64
> hardware.
> 
> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?

I'm not familiar with what COPR is doing for s39x0 ?  Is it using the
simple QEMU linux-user syscall emulation, or is it running a proper
QEMU s390x VM.

I'm guessing probably the former. The linux-user syscall emulation is
truely amazing, but it is certainly not feature complete or fully
robust.

Applications that are multi-threaded are especially likely to expose
bugs and/or design limitations that are often hard to fix. If the
app uses common/simple syscalls it'll probably be OK in general; if it
uses more obscure stuff it'll come up against bugs / missing features.
It doesn't emulate ptrace, or robust futexes, and doesn't separate
rlimits for the emulation layer from the application lkayer. QEMU
isn't especially prompt about adding support for newly exposed kernel
syscalls. The quality can also vary depending on what target
architecture is involved.

Overall it is pretty decent at being able to run common toolchains for
performing builds. Once you get into running a broader class of
applications, things can get more hairy.

Basically if it works for an given app, that is great, but don't be
too surprised if apps experiance odd behaviour or hits bugs.

I certainly won't expect to be able to blindly throw any Fedora package
at it and expect to run arbitrary integration tests with the same level
of quality you'd experiance with bare metal for that particular arch.

The QEMU VM emulation will get a more reliable environment for integration
testing, since that's just emulating the CPU + hardware, with Linux still
providing the syscall ABI. The cost is that VM is higher overhead than
linux-user.

As something that individual packagers can opt-in to QEMU linux-user
emulation might be viable. Packagers would just have to try it and see
if it works well enough for their particular package's testing use cases.
I'm not sure if that makes it compelling enough to invest time into
though from a Fedora infra POV.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Can we use emulation of other architectures to run integration tests?

[Florian Weimer]

* Daniel P. Berrangé:

> I'm not familiar with what COPR is doing for s39x0 ?  Is it using the
> simple QEMU linux-user syscall emulation, or is it running a proper
> QEMU s390x VM.
>
> I'm guessing probably the former. The linux-user syscall emulation is
> truely amazing, but it is certainly not feature complete or fully
> robust.

It still implements vfork using fork, right?  This means we should
likely fix posix_spawn in glibc to support this deviation from the
kernel interface.  Other Linux emulations have exactly the same problem.

For emulating 32-bit targets, we have a broken readdir/telldir/seekdir
implementation in glibc on 64 bit host kernels because we try to use
d_ino directly, which is 64 bit and does not fit into the long value
that POSIX requires.  A kernel patch with a new interface has been
posted which would work around this has been proposed, but it is not
going anywhere.

The second issue also affects full-system virtualization if p9fs (not
sure what the right name is, it's the older pass-through file system) is
used.  But it's specific to 32 bit, so maybe not that important after
all.

Thanks,
Florian
___
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: Can we use emulation of other architectures to run integration tests?

[Pavel Raiskup]

On Thursday, July 30, 2020 1:28:49 PM CEST Daniel P. Berrangé wrote:
> On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote:
> > Hi, all,
> > 
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> > 
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> > 
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
> 
> I'm not familiar with what COPR is doing for s39x0 ?  Is it using the
> simple QEMU linux-user syscall emulation, or is it running a proper
> QEMU s390x VM.
>
> I'm guessing probably the former. The linux-user syscall emulation is
> truely amazing, but it is certainly not feature complete or fully
> robust.

Yes, it is just running `mock -r fedora--s390x` on x86_64 VM.  That
uses dnf's --forcearch feature (qemu-user-static emulation).

Pavel

> Applications that are multi-threaded are especially likely to expose
> bugs and/or design limitations that are often hard to fix. If the
> app uses common/simple syscalls it'll probably be OK in general; if it
> uses more obscure stuff it'll come up against bugs / missing features.
> It doesn't emulate ptrace, or robust futexes, and doesn't separate
> rlimits for the emulation layer from the application lkayer. QEMU
> isn't especially prompt about adding support for newly exposed kernel
> syscalls. The quality can also vary depending on what target
> architecture is involved.
> 
> Overall it is pretty decent at being able to run common toolchains for
> performing builds. Once you get into running a broader class of
> applications, things can get more hairy.
> 
> Basically if it works for an given app, that is great, but don't be
> too surprised if apps experiance odd behaviour or hits bugs.
> 
> I certainly won't expect to be able to blindly throw any Fedora package
> at it and expect to run arbitrary integration tests with the same level
> of quality you'd experiance with bare metal for that particular arch.
> 
> The QEMU VM emulation will get a more reliable environment for integration
> testing, since that's just emulating the CPU + hardware, with Linux still
> providing the syscall ABI. The cost is that VM is higher overhead than
> linux-user.
> 
> As something that individual packagers can opt-in to QEMU linux-user
> emulation might be viable. Packagers would just have to try it and see
> if it works well enough for their particular package's testing use cases.
> I'm not sure if that makes it compelling enough to invest time into
> though from a Fedora infra POV.
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> ___
> 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: Can we use emulation of other architectures to run integration tests?

[Nikos Mavrogiannopoulos]

On Thu, Jul 30, 2020 at 12:25 PM Aleksandra Fedorova  wrote:
>
> Hi, all,
>
> I'd like to get some understanding on the current state of emulation
> of other architectures.
>
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on any non x86_64
> hardware.
>
> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?

Few years ago we transformed the gnutls' upstream CI from baremetal
h/w to qemu-user [0] (reasoning was pretty much what you mention, we
had x86-64 systems for free, and we had to pay for everything else).
This eliminated the need for such dedicated hardware, and in practice
the years it was in use I believe it eliminated issues in
compatibility with non-x86-64 architectures  and also helped catch
problems in new code (such as alignment issues). For an upstream test
suite it was totally worth it, and I believe it eliminated all issues
we were getting with non-x86 hardware support. The only drawback that
was noticed is that it could not be used to test some special features
of these CPUs, but that's also a problem with dedicated hardware
(e.g., when it doesn't support the particular instruction set you'd
like to introduce).

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/-/blob/master/.gitlab-ci.yml#L718
___
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: Can we use emulation of other architectures to run integration tests?

[Daniel P . Berrangé]

On Thu, Jul 30, 2020 at 01:38:41PM +0200, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > I'm not familiar with what COPR is doing for s39x0 ?  Is it using the
> > simple QEMU linux-user syscall emulation, or is it running a proper
> > QEMU s390x VM.
> >
> > I'm guessing probably the former. The linux-user syscall emulation is
> > truely amazing, but it is certainly not feature complete or fully
> > robust.
> 
> It still implements vfork using fork, right?  This means we should
> likely fix posix_spawn in glibc to support this deviation from the
> kernel interface.  Other Linux emulations have exactly the same problem.

Yeah, all of fork(), vfork() and clone(), end up getting mapped onto
fork() or pthread_create() depending the precise set of CLONE_* flags
required.

Common helper for all:

  https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L172
  https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L6086

And then the syscall wiring

vfork: 
https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L10792

 fork: 
https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L7882

clone: 
https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L9792


there's no clone2/clone3 support at all either.

> For emulating 32-bit targets, we have a broken readdir/telldir/seekdir
> implementation in glibc on 64 bit host kernels because we try to use
> d_ino directly, which is 64 bit and does not fit into the long value
> that POSIX requires.  A kernel patch with a new interface has been
> posted which would work around this has been proposed, but it is not
> going anywhere.

> The second issue also affects full-system virtualization if p9fs (not
> sure what the right name is, it's the older pass-through file system) is
> used.  But it's specific to 32 bit, so maybe not that important after
> all.

Yep, 9p, its generally not great POSIX emulation no matter what.

The more modern virtio-fs is a more promising solution for the
future, based on FUSE.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Can we use emulation of other architectures to run integration tests?

[Florian Weimer]

* Daniel P. Berrangé:

>> For emulating 32-bit targets, we have a broken readdir/telldir/seekdir
>> implementation in glibc on 64 bit host kernels because we try to use
>> d_ino directly, which is 64 bit and does not fit into the long value

recte: d_off

>> that POSIX requires.  A kernel patch with a new interface has been
>> posted which would work around this has been proposed, but it is not
>> going anywhere.
>
>> The second issue also affects full-system virtualization if p9fs (not
>> sure what the right name is, it's the older pass-through file system) is
>> used.  But it's specific to 32 bit, so maybe not that important after
>> all.
>
> Yep, 9p, its generally not great POSIX emulation no matter what.
>
> The more modern virtio-fs is a more promising solution for the
> future, based on FUSE.

The second problem is not a matter of old vs modern interfaces, it's
that POSIX requires us to fit the 64-bit d_off value we get from the
kernel into a 32-bit long, because that's what telldir returns.  This is
true even for builds with 64-bit off_t values.  The kernel cannot really
fix this on our behalf because it would have to perform a
side-translation for every directory entry.  That's problematic for
large directories.

But in glibc, we know when we need the translation (when the application
calls telldir), and we can defer the translation until then.  It's just
a little bit awkward to implement because telldir must not fail, so we
need to preallocate space for the translation during the readdir call.
But it's not impossible.

Thanks,
Florian
___
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: Can we use emulation of other architectures to run integration tests?

[Aleksandra Fedorova]

Hi, Rich,

On Thu, Jul 30, 2020 at 1:10 PM Richard W.M. Jones  wrote:
>
> On Thu, Jul 30, 2020 at 12:24:19PM +0200, Aleksandra Fedorova wrote:
> > Hi, all,
> >
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> >
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> >
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
> >
> > If yes, can you suggest some links, tips on the topic?
>
> To be clear, are we talking qemu-system-X, qemu-user, or something
> else entirely?  Are you planning to do the tests in a full VM (eg. in
> qemu-system-X)?

Thank you for the question. I think I am actually interested in both.

The scenario we use for current x86 dist-git tests is based on vms: we
spin up a full vm with qemu-kvm, ssh inside it, install a package and
run the test script.
Should it be possible to do the same with qemu-system-s390x? Maybe
even with nested virtualization, with s390x inside x86?

> Rich.
>
> >
> > (*) Not really, and some of our infra services are not yet good at
> > scaling up, but we are getting better at it.
> >
> > --
> > Aleksandra Fedorova
> > bookwar
> > ___
> > 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

-- 
Aleksandra Fedorova
bookwar
___
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: Can we use emulation of other architectures to run integration tests?

[Miro Hrončok]

On 30. 07. 20 12:24, Aleksandra Fedorova wrote:

As COPR has recently got support for s390 builds, the question is: if
emulation is good enough for building packages, can we use it for
testing? What are the limitations there? Is it worth it?


I don't have that many experience with this but every time I've attempted to 
build some Python package via mock's forcearch emulation on s390x, I got some 
segfaults and gave up.


--
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: Can we use emulation of other architectures to run integration tests?

[Aleksandra Fedorova]

Hi, Nikos,

On Thu, Jul 30, 2020 at 1:48 PM Nikos Mavrogiannopoulos  wrote:
>
> On Thu, Jul 30, 2020 at 12:25 PM Aleksandra Fedorova  
> wrote:
> >
> > Hi, all,
> >
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> >
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> >
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
>
> Few years ago we transformed the gnutls' upstream CI from baremetal
> h/w to qemu-user [0] (reasoning was pretty much what you mention, we
> had x86-64 systems for free, and we had to pay for everything else).
> This eliminated the need for such dedicated hardware, and in practice
> the years it was in use I believe it eliminated issues in
> compatibility with non-x86-64 architectures  and also helped catch
> problems in new code (such as alignment issues). For an upstream test
> suite it was totally worth it, and I believe it eliminated all issues
> we were getting with non-x86 hardware support. The only drawback that
> was noticed is that it could not be used to test some special features
> of these CPUs, but that's also a problem with dedicated hardware
> (e.g., when it doesn't support the particular instruction set you'd
> like to introduce).

Thanks for the example.

If I understand correctly in the emulated environment you run _build_
of the gnutls. Do you also run any arch-specific integration tests?

Basically I am trying to find value we could bring on top of the
existing s390x-scratch builds, which are already done by Koji.

> regards,
> Nikos
>
> [0]. https://gitlab.com/gnutls/gnutls/-/blob/master/.gitlab-ci.yml#L718
> ___
> CI mailing list -- c...@lists.fedoraproject.org
> To unsubscribe send an email to ci-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/c...@lists.fedoraproject.org

--
Aleksandra Fedorova
bookwar
___
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: No debugsource generated, weird DWARF errors

[Mark Wielaard]

Hi Richard,

On Thu, 2020-07-30 at 12:01 +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> > I will apply this patch to the rawhide binutils (and the upstream
> > binutils sources).
> 
> I don't know how worried we should be about this, but it seems every
> test in the x86-64 build failed (although the build was successful):
> 
> https://kojipkgs.fedoraproject.org//work/tasks/6878/48186878/build.log

Nick is on it:
https://sourceware.org/pipermail/binutils/2020-July/112637.html

Looks like most are simply because the default DWARF version changed to
4 and the test expected another version even though it didn't specify
one.

Cheers,

Mark
___
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: We have to talk about annobin... again

[Mark Wielaard]

On Thu, 2020-07-30 at 10:09 +0200, Kevin Kofler wrote:
> Jeff Law wrote:
> > :(  I'll raise it again with Nick and Jakub, it's a sore point for
> > everyone I think and it causes far more friction than just what we see
> > here in Fedora.
> 
> IMHO, we should just drop annobin from Fedora (or at least disable it). It 
> provides no tangible benefit to end users and the regular sync issues with 
> the toolchain are a constant source of pain for packagers. Would it not be 
> enough to do periodic rebuilds with annobin in a side tag to catch packages 
> that are built with insecure or otherwise suboptimal flags, instead of 
> burdening the production repository with this debugging tool?

Although the sync issues are annoying I do think we, as developers of
and developers on the Fedora platform benefit from having the annobin
notes in the binaries. It is like making sure there is unwind
information or debug packages for each binary. If things are perfect,
they are just there for assurance. But if there is an issue you want to
look into, or you get a crash, want to do some profiling to see what
your machine is doing, writing a new program, combine two libraries,
etc. you are glad the information is there.

Cheers,

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

Orphaning openbabel

[Dominik 'Rathann' Mierzejewski]

Hi everyone,
I've finally admitted to myself that I have no time to take good care
of openbabel:
https://src.fedoraproject.org/rpms/openbabel
It has one FTBFS bug in rawhide (related to cmake macro changes)
and two requests to update. One in Fedora to move to the recent 3.x
series and one for EPEL to update from 2.3 to 2.4.

It has 9 consumers in Fedora:
avogadro
avogadro2
chemtool
ghemical
gnome-chemistry-utils
IQmol
kalzium
molsketch
xdrawchem

Hopefully, one of their maintainers (Bcc'd) or someone from SciTech SIG
(Cc'd) can pick this up.

I'll orphan it in a few days if nobody responds here with their
FAS ID.

Regards,
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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: Disabled LTO on qemu

[Jeff Law]

On Thu, 2020-07-30 at 11:06 +0100, Richard W.M. Jones wrote:
> I just disabled LTO for qemu.
> 
> It caused what are best described as "weird" assert failures
> in the test suite.
> 
> For comparison here's a good build (without LTO):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48188577
> 
> And here's a bad build (with LTO):
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48182910
> 
> At some point we'll need to look at what's going on, but right now
> disabling LTO was the easiest way to work around what might be
> toolchain bugs.
Agreed 100%.  qemu was one of the dozen or so things left on my "to review" list
that I couldn't get to with the binutils panic Fri/Sat.  I suspect there's an 
asm
gone awry, but we won't know for sure until we dig deeply into 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: Disable LTO for now ?

[Steven Munroe]

Sergio writes:

> Hello opencv [1] build also failed around LTO

Looking at the build logs:

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

For the build.log that ends with:

lto1: error: '__builtin_altivec_vadub' requires the '-mcpu=power9' option
lto1: fatal error: target specific builtin not available
compilation terminated.

The build uses a mix of compiler options.

-mcpu=power8 -mtune=power8
and
-mcpu=power9 -mtune=power9
and sometimes
-mcpu=power8 ... -mcpu=power9 -mtune=power9

I suspect this works at the level of individual object (*.o)
generation but this might cause problems when a mix of -mcpu=power8
and -mcpu=power9 objects are combined in LTO optimization.

The compiler might get confused.
___
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: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.

___
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: No debugsource generated, weird DWARF errors

[Nick Clifton]

Hi Guys,

> Looks like most are simply because the default DWARF version changed to
> 4 and the test expected another version even though it didn't specify
> one.

Yes - it was a silly snafu.  I set the default to 4 but the tests are expecting 
3.

I have now updated the patch and a new binutils (2.23-5.fc33) is building...

Cheers
  Nick

___
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: Disable LTO for now ?

[Jakub Jelinek]

On Thu, Jul 30, 2020 at 09:02:43AM -0500, Steven Munroe wrote:
> Sergio writes:
> 
> > Hello opencv [1] build also failed around LTO
> 
> Looking at the build logs:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48055082
> 
> For the build.log that ends with:
> 
> lto1: error: '__builtin_altivec_vadub' requires the '-mcpu=power9' option
> lto1: fatal error: target specific builtin not available
> compilation terminated.
> 
> The build uses a mix of compiler options.
> 
> -mcpu=power8 -mtune=power8
> and
> -mcpu=power9 -mtune=power9
> and sometimes
> -mcpu=power8 ... -mcpu=power9 -mtune=power9
> 
> I suspect this works at the level of individual object (*.o)
> generation but this might cause problems when a mix of -mcpu=power8
> and -mcpu=power9 objects are combined in LTO optimization.
> 
> The compiler might get confused.

For targets which do support the target attribute, each function should be
marked with the right set of options before streaming it, there can be bugs
of course, especially on the rs6000 side which uses target attribute far
less often then e.g. x86_64.

Jakub
___
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: Can we use emulation of other architectures to run integration tests?

[Jeff Law]

On Thu, 2020-07-30 at 13:48 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Jul 30, 2020 at 12:25 PM Aleksandra Fedorova  
> wrote:
> > Hi, all,
> > 
> > I'd like to get some understanding on the current state of emulation
> > of other architectures.
> > 
> > In the current CI infra we have infinite(*) access to x86_64 compute
> > resources, but we haven't yet got our hands on any non x86_64
> > hardware.
> > 
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
> 
> Few years ago we transformed the gnutls' upstream CI from baremetal
> h/w to qemu-user [0] (reasoning was pretty much what you mention, we
> had x86-64 systems for free, and we had to pay for everything else).
> This eliminated the need for such dedicated hardware, and in practice
> the years it was in use I believe it eliminated issues in
> compatibility with non-x86-64 architectures  and also helped catch
> problems in new code (such as alignment issues). For an upstream test
> suite it was totally worth it, and I believe it eliminated all issues
> we were getting with non-x86 hardware support. The only drawback that
> was noticed is that it could not be used to test some special features
> of these CPUs, but that's also a problem with dedicated hardware
> (e.g., when it doesn't support the particular instruction set you'd
> like to introduce).
We use it heavily in the GCC upstream tester for ancient targets (think m68k,
hppa, alpha and the like).  It works amazingly well.  Interestingly enough I've
found those old targets to work better than, say, s390.

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: Duplicate package was reviewed

[Vitaly Zaitsev via devel]

On 30.07.2020 10:03, Kevin Kofler wrote:
> Independently of what the current packaging guidelines say about this 
> (apparently, "compat-" is not even a thing anymore there, see Rathann's 
> reply), it simply does not make sense to use any sort of prefixing or 
> suffixing to the package name when the old and the new library have 
> different package names (as in this case: libqmatrixclient vs. libquotient).

Previously it wasn't allowed to push different versions of the same
project into repositories. That's why Fedora Modularity was invented.

I see the this is permitted now, sorry for the noise.

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

Re: Can we use emulation of other architectures to run integration tests?

[Mark Wielaard]

Hi Aleksandra,

On Thu, 2020-07-30 at 12:24 +0200, Aleksandra Fedorova wrote:
> I'd like to get some understanding on the current state of emulation
> of other architectures.
> 
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on any non x86_64
> hardware.
> 
> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?
> 
> If yes, can you suggest some links, tips on the topic?

I tried the copr emulation of arm32 and s390x with the valgrind
package. But although it seems to be able to produce binaries it was
unable to run the tests. Which makes it hard to know whether the
produced binaries are OK. And they make the build fail because we do
require at least some tests to succeed in %check.

Cheers,

Mark
___
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: Disable LTO for now ?

[Steven Munroe]

Jakub Jelinek writes:

> For targets which do support the target attribute, each
> function should be marked with the right set of options
> before streaming it,

Looking at the source (opencv 4.3.0) I can not find any usage of
__attribute__ ((target)) or #pragma ... optimization associated with ppc
specific code.

What I did find was a blind usage of

// absolute difference
#ifndef vec_absd
#   define vec_absd(a, b) vec_sub(vec_max(a, b), vec_min(a, b))
#endif

ie if vec_absd is defined use it otherwise fake it.

and vec_absd will be defined in altivec,h (for gcc 9/10)  #ifdef
__POWER9_VECTOR__

As I have found (repeatedly) this is not good enough.  PVECLIB Building
Multi-target Libraries
 I suspect
this is another case that does not work when mixing targeted objects in LTO.
___
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: Disable LTO for now ?

[Jakub Jelinek]

On Thu, Jul 30, 2020 at 10:24:50AM -0500, Steven Munroe wrote:
> > For targets which do support the target attribute, each
> > function should be marked with the right set of options
> > before streaming it,
> 
> Looking at the source (opencv 4.3.0) I can not find any usage of
> __attribute__ ((target)) or #pragma ... optimization associated with ppc
> specific code.

For LTO, gcc should use that attribute (well, the underlying behavior) for
all functions, essentially if one TU is compiled with
-mcpu=power8, then functions in there (unless they have other target
attributes already, then it would be slightly different) should get
behavior like with target ("cpu=power8"), similarly TUs that are compiled
with -mcpu=power9 should get target ("cpu=power9"), etc.
Now, the important question is e.g. if the backend disallows inlining
between those two target attributes or not.
The powerpc backend does implement rs6000_can_inline_p though.

So I guess the question is, in which function the error actually appears,
whether that one has been compiled with -mcpu=power9 or not, and whether
the vec_absd builtin call doesn't appear from something inlined into it.

Jakub
___
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: Can we use emulation of other architectures to run integration tests?

[Robbie Harwood]

Aleksandra Fedorova  writes:

> As COPR has recently got support for s390 builds, the question is: if
> emulation is good enough for building packages, can we use it for
> testing? What are the limitations there? Is it worth it?

Cross-architecture emulation is unbelievably slow in the general case.
While it helps for some specific use cases, it's not a substitute for
actually getting hardware.

Thanks,
--Robbie


signature.asc
Description: PGP 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: Fedora 32 aarch64 build failures on copr

[Jeremy Linton]

On 7/28/20 4:39 PM, Jeff Law wrote:

On Tue, 2020-07-28 at 15:29 -0500, Michael Catanzaro wrote:

On Tue, Jul 28, 2020 at 2:01 pm, Jeff Law  wrote:

If this is a new failure (say in the last week), it could be an out
of memory
scenario.  Try disabling LTO.  The standard way to do that is

%define _lto_cflags %{nil}

In your %build stanza in the spec file.

Heff


I agree, it's almost certainly OOM because it says "fatal error:
Killed." I've never seen that happen for any reason other than OOM.

I've seen it happen for a variety of reasons.  Please test with LTO disabled and
let me know if that helps.


As a FYI: I had similar problems not long ago building a tensorflow. 
Reducing the build parallelism in that case helped reduce the memory 
footprint sufficiently that the build completed.

___
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: Can we use emulation of other architectures to run integration tests?

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 02:10:58PM +0200, Aleksandra Fedorova wrote:
> The scenario we use for current x86 dist-git tests is based on vms: we
> spin up a full vm with qemu-kvm, ssh inside it, install a package and
> run the test script.

I guess you could do something with virt-builder, but ...

> Should it be possible to do the same with qemu-system-s390x? Maybe
> even with nested virtualization, with s390x inside x86?

qemu-system-s390x uses TCG to emulate instructions (so does
qemu-user).  qemu emulates a full System-z machine, at least enough to
boot and run Linux.  Nested virtualization would indicate something to
do with KVM, but that is never possible when the guest arch != host arch.

In the past support for both POWER and s390x has varied between what
Fedora (especially the kernel) requires and what qemu can emulate.  I
haven't actually tried it that recently, so I'm not sure if it works
right now.  Generally if it boots it will usually work very reliably.
But when it breaks it can be painful to try to discover what new
feature is missing or what qemu command line option is required to
enable/disable some machine feature to get it to work.

So I guess yes, it's the way to go, and it'll often work until it
doesn't and then you'll have some debugging on your hands.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: Can we use emulation of other architectures to run integration tests?

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 11:46:08AM -0400, Robbie Harwood wrote:
> Aleksandra Fedorova  writes:
> 
> > As COPR has recently got support for s390 builds, the question is: if
> > emulation is good enough for building packages, can we use it for
> > testing? What are the limitations there? Is it worth it?
> 
> Cross-architecture emulation is unbelievably slow in the general case.
> While it helps for some specific use cases, it's not a substitute for
> actually getting hardware.

Since qemu TCG now supports host thread per vCPU you can usually throw
lots of vCPUs at the problem, assuming your builds can be parallelised
and your x86 hardware has plenty of cores.

We use it reasonably successfully to build a lot of Fedora/RISC-V
packages, along with a limited amount of actual hardware.

Rich.

https://wiki.qemu.org/Features/tcg-multithread

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
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: s390 builds failing with "All mirrors were tried"

[Jeff Law]

On Wed, 2020-07-29 at 10:11 -0700, Kevin Fenzi wrote:
> On Wed, Jul 29, 2020 at 10:25:24AM -0600, Jeff Law wrote:
> > On Wed, 2020-07-29 at 09:19 -0700, Kevin Fenzi wrote:
> > > On Wed, Jul 29, 2020 at 10:31:32AM -0400, Scott Talbert wrote:
> > > > On Wed, 29 Jul 2020, Richard W.M. Jones wrote:
> > > > 
> > > > > libnbd failed in the mass rebuild.  I kicked off a second build by
> > > > > hand, and it failed in the exact same way:
> > > > > 
> > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48118058
> > > > > 
> > > > > DEBUG util.py:623:  Downloading Packages:
> > > > > DEBUG util.py:621:  Error: Error downloading packages:
> > > > > DEBUG util.py:621:Cannot download 
> > > > > toplink/packages/ocaml/4.11.0/0.4.dev2.fc33/s390x/ocaml-compiler-libs-4.11.0-0.4.dev2.fc33.s390x.rpm:
> > > > >  All mirrors were tried
> > > > > 
> > > > > Is this a generic s390 problem of is there really something wrong with
> > > > > the ocaml-compiler-libs package?  If it's generic then I guess this
> > > > > sort of error could be affecting a lot of other packages in the mass
> > > > > rebuild.
> > > > 
> > > > Seems to be a generic s390x problem (with networking / connectivity?). 
> > > > At
> > > > least one of my packages failed in a similar was on s390x.
> > > 
> > > Yes, the local to the s390x builders cache had issues last night.
> > > I disabled all builders and rebooted it, but likely it failed a lot of
> > > builds. 
> > > 
> > > Additionally, it seems like from time to time it just gets swamped.
> > > 
> > > We are planning on resubmitting the failed builds after the mass rebuild
> > > is complete. Or you can feel free to resubmit any of yours that failed
> > > in this way before then. 
> > > 
> > > I already have some ideas on how to make the s390x setup more robust,
> > > but I'm not going to make changes in the middle of the mass rebuild, but
> > > hopefully that will help for the next one. 
> > That reminds me.  My local testing has shown that -flto=auto works 
> > reasonably
> > well and can help significantly with build times (it parallelizes the 
> > compiler
> > invocations that occur at link time).
> > 
> > It'd planned to enable it after the mass rebuild, but I find myself 
> > wondering if
> > I should go ahead and update redhat-rpm-config now so that the second pass 
> > over
> > the packages will be faster.
> > 
> > Thoughts?
> 
> If all it does is parallelize, I'd say enable it anytime...
Done.
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: Can we use emulation of other architectures to run integration tests?

[Robbie Harwood]

"Richard W.M. Jones"  writes:

> On Thu, Jul 30, 2020 at 11:46:08AM -0400, Robbie Harwood wrote:
>> Aleksandra Fedorova  writes:
>> 
>>> As COPR has recently got support for s390 builds, the question is:
>>> if emulation is good enough for building packages, can we use it for
>>> testing? What are the limitations there? Is it worth it?
>> 
>> Cross-architecture emulation is unbelievably slow in the general
>> case.  While it helps for some specific use cases, it's not a
>> substitute for actually getting hardware.
>
> Since qemu TCG now supports host thread per vCPU you can usually throw
> lots of vCPUs at the problem, assuming your builds can be parallelised
> and your x86 hardware has plenty of cores.

That's good to know, and definitely I could see that helping with builds
themselves, but won't help with many (most?) test suites :)

Thanks,
--Robbie


signature.asc
Description: PGP 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: Can we use emulation of other architectures to run integration tests?

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 01:06:46PM -0400, Robbie Harwood wrote:
> "Richard W.M. Jones"  writes:
> 
> > On Thu, Jul 30, 2020 at 11:46:08AM -0400, Robbie Harwood wrote:
> >> Aleksandra Fedorova  writes:
> >> 
> >>> As COPR has recently got support for s390 builds, the question is:
> >>> if emulation is good enough for building packages, can we use it for
> >>> testing? What are the limitations there? Is it worth it?
> >> 
> >> Cross-architecture emulation is unbelievably slow in the general
> >> case.  While it helps for some specific use cases, it's not a
> >> substitute for actually getting hardware.
> >
> > Since qemu TCG now supports host thread per vCPU you can usually throw
> > lots of vCPUs at the problem, assuming your builds can be parallelised
> > and your x86 hardware has plenty of cores.
> 
> That's good to know, and definitely I could see that helping with builds
> themselves, but won't help with many (most?) test suites :)

This is sadly true for many :-(

For nbdkit though, our test suite will use as many ‘make -j #cores’ as
you can throw at it (I have tested 64) :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: Orphaning openbabel

[Alexander Ploumistos]

Hello Dominik and everyone else,

The next release of Molsketch is going to build against Open Babel
3.x, so I started working on updating the openbabel package around the
time version 3.1.1 came out, which supposedly fixed some issues
related to packaging on linux. Based on your spec file, I was trying
to see which patches were obsolete, what else might be required to get
it to build with as many features as possible and then test the
"abandonware" that depends on it. Unfortunately (fortunately?), the
local lockdown was lifted and I was among the people authorized back
in the lab and I got swamped with work, so I didn't get very far. I
got the base stuff building at some point, but I had trouble with some
runtime dependencies. In the meantime, there's been the CMake change
and I don't know if what I got building still does.
I am currently on vacation until the last week of August and away from
my systems, so I can't test things, or comment on the issues I
encountered. That being said, I think that of the packagers involved,
I am the least qualified to take up openbabel and I haven't touched
RHEL or CentOS in years, so I have no idea what's going on there and
what's required to maintain the EPEL branches. I'd be happy to
co-maintain the Fedora ones and help out as much as I can. Given the
time of the year in the Northern Hemisphere, do you think you could
hold on to the package a little longer (e.g. until the beginning of
September), so that people who are interested might get the chance to
get our act together?

Thank you for everything you've done so far,
A.
___
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: Duplicate package was reviewed

[Dominik 'Rathann' Mierzejewski]

On Thursday, 30 July 2020 at 17:11, Vitaly Zaitsev via devel wrote:
> On 30.07.2020 10:03, Kevin Kofler wrote:
> > Independently of what the current packaging guidelines say about this 
> > (apparently, "compat-" is not even a thing anymore there, see Rathann's 
> > reply), it simply does not make sense to use any sort of prefixing or 
> > suffixing to the package name when the old and the new library have 
> > different package names (as in this case: libqmatrixclient vs. libquotient).
> 
> Previously it wasn't allowed to push different versions of the same
> project into repositories. That's why Fedora Modularity was invented.
> 
> I see the this is permitted now, sorry for the noise.

I'm not sure where you got the idea that it wasn't permitted. It always
was, you just had to ensure the packages didn't conflict. The only thing
that changed some time ago is that the compat- prefix is no longer
required.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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

Orphaning perl-perl5i

[Paul Howarth]

I've just orphaned perl-perl5i
(https://src.fedoraproject.org/rpms/perl-perl5i).

I can't see any dependencies in Fedora so it shouldn't cause any issues
if it gets retired.

The package is FTBFS since Perl was updated to 5.32 and
perl-Devel-Declare was updated to a version compatible with 5.32:
https://github.com/evalEmpire/perl5i/issues/307

The perl5i module uses Devel::Declare to implement function and method
signatures
(https://metacpan.org/pod/perl5i#Subroutine-and-Method-Signatures),
in a similar fashion to the Function::Parameters module
(https://metacpan.org/pod/Function::Parameters), so it shouldn't be
*too* hard to fix but upstream has been inactive for a few years now.

Paul.
___
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

Orphaning unison240, unison227 and unison213 (and recommending that we retire them)

[Richard W.M. Jones]

This is the most important link to read and gives the reasoning
which I won't repeat here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QEDC4FKCAW73K3WLBMFFYSGQFYQBQPG4/

Also previous discussion:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBOQEJY4QHNPDUTUU7GCNVJLNEH6JYKN/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/
https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495

Per the first link above, I'm orphaning all 3 unison* packages now.

I recommend that we retire them.  If we want to introduce unison back
to Fedora we should do it as a unified package that would build the
latest version + possibly earlier versions (if they can be built - but
older versions currently cannot be built).

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: Help with reviewing a compiler toolchain

[Andy Mender]

On Wed, 29 Jul 2020 at 15:51, Jonathan Wakely 
wrote:

> On 28/07/20 22:46 +0200, Andy Mender wrote:
> >Dear Fedorians,
> >
> >I really need some help with a review of a GCC toolchain variant I've
> >started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884
> >
> >A Koji build of the most recent SRPM:
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=48035045
> >
> >Some minor issues have been fixed already, but the toolchain seems quite
> >complicated and frankly it went over my head :(.
>
> I'll take a look.
>

Thank you so much, Jonathan! Let me if you'd like me to review something
for you in exchange.
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

Thanks Nick, the binutils change does appear to have solved the
problem:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48212537
https://kojipkgs.fedoraproject.org//work/tasks/2537/48212537/build.log

Note (for Xavier) that I did NOT need to make any change to OCaml or
the flags that it passes to gas.

I think we can say this problem is fixed at the moment.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:

https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210
https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log

https://koji.fedoraproject.org/koji/taskinfo?taskID=48213712
https://kojipkgs.fedoraproject.org//work/tasks/3712/48213712/build.log

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 10:18:18PM +0100, Richard W.M. Jones wrote:
> 
> That problem is fixed, but binutils "ar" utility in Rawhide
> again segfaults, eg:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48212210
> https://kojipkgs.fedoraproject.org//work/tasks/2210/48212210/build.log
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48213712
> https://kojipkgs.fedoraproject.org//work/tasks/3712/48213712/build.log

Another report of the same thing:

https://kojipkgs.fedoraproject.org//work/tasks/3530/48213530/build.log

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: No debugsource generated, weird DWARF errors

[Tom Hughes via devel]

On 30/07/2020 22:18, Richard W.M. Jones wrote:


That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:


Yes, because the commit adding the DWARF 4 patch has also
turned LTO back on...

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
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: No debugsource generated, weird DWARF errors

[Tom Hughes via devel]

On 30/07/2020 22:26, Tom Hughes via devel wrote:

On 30/07/2020 22:18, Richard W.M. Jones wrote:


That problem is fixed, but binutils "ar" utility in Rawhide
again segfaults, eg:


Yes, because the commit adding the DWARF 4 patch has also
turned LTO back on...


...and for extra fun the broken build is on f33-rebuild by
the looks of it.

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
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> On 30/07/2020 22:18, Richard W.M. Jones wrote:
> 
> >That problem is fixed, but binutils "ar" utility in Rawhide
> >again segfaults, eg:
> 
> Yes, because the commit adding the DWARF 4 patch has also
> turned LTO back on...

Since this is causing a lot of trouble I have kicked off a binutils
build with the DWARF fix and with LTO turned off again:

https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master
https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> > On 30/07/2020 22:18, Richard W.M. Jones wrote:
> > 
> > >That problem is fixed, but binutils "ar" utility in Rawhide
> > >again segfaults, eg:
> > 
> > Yes, because the commit adding the DWARF 4 patch has also
> > turned LTO back on...
> 
> Since this is causing a lot of trouble I have kicked off a binutils
> build with the DWARF fix and with LTO turned off again:
> 
> https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master
> https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888

Of course that failed because one of the first things it tries to do
is run "ar", which comes from the broken binutils and fails.

We need someone to untag the broken binutils-2.35-5.fc33 and then
issue a new binutils build.  (I cannot do this)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: No debugsource generated, weird DWARF errors

[Richard W.M. Jones]

On Thu, Jul 30, 2020 at 10:37:22PM +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 10:33:18PM +0100, Richard W.M. Jones wrote:
> > On Thu, Jul 30, 2020 at 10:26:18PM +0100, Tom Hughes wrote:
> > > On 30/07/2020 22:18, Richard W.M. Jones wrote:
> > > 
> > > >That problem is fixed, but binutils "ar" utility in Rawhide
> > > >again segfaults, eg:
> > > 
> > > Yes, because the commit adding the DWARF 4 patch has also
> > > turned LTO back on...
> > 
> > Since this is causing a lot of trouble I have kicked off a binutils
> > build with the DWARF fix and with LTO turned off again:
> > 
> > https://src.fedoraproject.org/rpms/binutils/c/6442193bfff72a2b538bf2cb32110850033dea24?branch=master
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48214888
> 
> Of course that failed because one of the first things it tries to do
> is run "ar", which comes from the broken binutils and fails.
> 
> We need someone to untag the broken binutils-2.35-5.fc33 and then
> issue a new binutils build.  (I cannot do this)

We got the bad build untagged, and this is the new build:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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