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
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
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
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
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
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):
* 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
* 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
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
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):
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
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.
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,
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
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 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
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
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__
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 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 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
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
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 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
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
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
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
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
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 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
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
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
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
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
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
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:
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
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:
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:
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
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
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
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
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
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
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 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
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
https://bugzilla.redhat.com/show_bug.cgi?id=1842274
--- Comment #5 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-Excel-Writer-XLSX-1.05-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=48198612
--
The following Fedora EPEL 8 Security updates need testing:
Age URL
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-31b5963358
tor-0.4.3.6-1.el8
13 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a0f28fffcf
bashtop-0.9.24-1.el8
12
https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/31/report-389-ds-base-1.4.4.4-20200730git2c8e339.fc32.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to
The following Fedora EPEL 7 Security updates need testing:
Age URL
716 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d
condor-8.6.11-1.el7
455 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b
bubblewrap-0.3.3-2.el7
165
https://bugzilla.redhat.com/show_bug.cgi?id=1857787
--- Comment #13 from Fedora Update System ---
FEDORA-2020-949a75223b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1858481
--- Comment #8 from Fedora Update System ---
FEDORA-2020-20b70fc964 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1858476
--- Comment #8 from Fedora Update System ---
FEDORA-2020-6327f493e8 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1858467
--- Comment #7 from Fedora Update System ---
FEDORA-2020-ccb3c84ade has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1842274
Upstream Release Monitoring
changed:
What|Removed |Added
Summary|perl-Excel-Writer-XLSX-1.04
https://bugzilla.redhat.com/show_bug.cgi?id=1842274
--- Comment #4 from Upstream Release Monitoring
---
Created attachment 1702962
--> https://bugzilla.redhat.com/attachment.cgi?id=1702962=edit
[patch] Update to 1.05 (#1842274)
--
You are receiving this mail because:
You are on the CC
https://bugzilla.redhat.com/show_bug.cgi?id=1810831
--- Comment #1 from Fedora Update System ---
FEDORA-EPEL-2020-4e78eb6d88 has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4e78eb6d88
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1810831
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |MODIFIED
CC|
https://bugzilla.redhat.com/show_bug.cgi?id=1858951
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1859415
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1859415
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Log-Log4perl-1.50-1.fc |perl-Log-Log4perl-1.50-1.fc
https://bugzilla.redhat.com/show_bug.cgi?id=1858951
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-ExtUtils-HasCompiler-0 |perl-ExtUtils-HasCompiler-0
The following Fedora EPEL 6 Security updates need testing:
Age URL
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-713ebad0a1
golang-1.13.14-1.el6
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d1b24a2a25
snmptt-1.4.2-1.el6
The following builds have been
https://bugzilla.redhat.com/show_bug.cgi?id=1853722
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=1810831
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|ON_QA
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=1858467
--- Comment #8 from Fedora Update System ---
FEDORA-2020-ccb3c84ade has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1858476
--- Comment #9 from Fedora Update System ---
FEDORA-2020-6327f493e8 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1857787
--- Comment #14 from Fedora Update System ---
FEDORA-2020-949a75223b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1858481
--- Comment #9 from Fedora Update System ---
FEDORA-2020-20b70fc964 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1850776
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In Version|
-- Forwarded message -
From: Sumana Harihareswara
Date: Thu, Jul 30, 2020 at 11:36 AM
Subject: Re: [pypa/pip] New Resolver: Rollout, Feedback Loops and
Development Flow (#6536)
To: pypa/pip
Cc: Neal Gompa (ニール・ゴンパ) , Comment <
comm...@noreply.github.com>
Per #8511
Dear all,
You are kindly invited to the meeting:
EPEL Steering Committee on 2020-07-31 from 21:00:00 to 22:00:00 UTC
At freenode@fedora-meeting
The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.
A general agenda is the following:
#meetingname EPEL
#topic
78 matches
Mail list logo
