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 t
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
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 s
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 w
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
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?
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/task
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
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:/
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 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
* 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 f
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
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
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. T
* 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 wit
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 hav
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
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 w
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
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 le
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
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
>
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
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 dev
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
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_
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 infinit
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
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 a
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 pp
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__ ((tar
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
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
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 ...
>
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
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:
> >
"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
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
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 t
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
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:
ht
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.fedo
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 mo
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 pass
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.fedor
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
>
>
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/
_
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 bu
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 i
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
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 bin
52 matches
Mail list logo
