Re: Can't push update to stable

2020-09-15 Thread Richard W.M. Jones
https://pagure.io/fedora-infrastructure/issue/9320 -- 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

Re: Can't push update to stable (was: Re: What is the status of this F33 update?)

2020-09-15 Thread Richard W.M. Jones
On Tue, Sep 15, 2020 at 02:52:14PM +0100, Richard W.M. Jones wrote: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 again ... > > I cannot push this to stable, at least, not through the web UI. > The button does nothing. Meanwhile the command line hangs for

Can't push update to stable (was: Re: What is the status of this F33 update?)

2020-09-15 Thread Richard W.M. Jones
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 again ... I cannot push this to stable, at least, not through the web UI. The button does nothing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog:

Re: What is the status of this F33 update?

2020-09-11 Thread Richard W.M. Jones
On Fri, Sep 11, 2020 at 10:15:06PM +0200, Miro Hrončok wrote: > On 11. 09. 20 22:11, Richard W.M. Jones wrote: > >On Fri, Sep 11, 2020 at 10:03:11PM +0200, Miro Hrončok wrote: > >>On 11. 09. 20 21:57, Richard W.M. Jones wrote: > >>>I built libnbd against the s

Re: What is the status of this F33 update?

2020-09-11 Thread Richard W.M. Jones
On Fri, Sep 11, 2020 at 10:03:11PM +0200, Miro Hrončok wrote: > On 11. 09. 20 21:57, Richard W.M. Jones wrote: > >I built libnbd against the side tag (libnbd-1.4.1-1.fc33.1) but can't > >work out how to add it to the update. There seems to be no way to > >edit the li

Re: What is the status of this F33 update?

2020-09-11 Thread Richard W.M. Jones
On Fri, Sep 11, 2020 at 08:57:20PM +0100, Richard W.M. Jones wrote: > On Fri, Sep 11, 2020 at 09:41:09PM +0200, Fabio Valentini wrote: > > On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones > > wrote: > > > > > > > > > https://bodhi.fedora

Re: What is the status of this F33 update?

2020-09-11 Thread Richard W.M. Jones
On Fri, Sep 11, 2020 at 09:41:09PM +0200, Fabio Valentini wrote: > On Fri, Sep 11, 2020 at 9:38 PM Richard W.M. Jones wrote: > > > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 > > > > I'm confused about what state this update it is. &qu

What is the status of this F33 update?

2020-09-11 Thread Richard W.M. Jones
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 I'm confused about what state this update it is. "Pending" - pending what exactly? What we really want to know is how long before it ends up in F33 and Jerry can build more OCaml packages against it. Rich. -- Richard Jones,

Re: OCaml F33 rebuild and .1 release tags

2020-09-03 Thread Richard W.M. Jones
On Wed, Sep 02, 2020 at 09:06:58PM +0100, Richard W.M. Jones wrote: > I'm doing a rebuild of the OCaml-related packages in F33 to move from > OCaml 4.11.0 prerelease to OCaml 4.11.1 because: > > https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 > > "A serious bug h

OCaml F33 rebuild and .1 release tags

2020-09-02 Thread Richard W.M. Jones
I'm doing a rebuild of the OCaml-related packages in F33 to move from OCaml 4.11.0 prerelease to OCaml 4.11.1 because: https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 "A serious bug has been discovered last week in OCaml 4.11.0: explicit polymorphic annotations are checked too

Re: FYI Fedora 34 OCaml 4.11.1 rebuild

2020-09-01 Thread Richard W.M. Jones
On Tue, Sep 01, 2020 at 11:10:56AM -0600, Jerry James wrote: > On Tue, Sep 1, 2020 at 10:28 AM Richard W.M. Jones wrote: > > We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, > > something like 170+ packages. Well, a compiler bug was found and > > upstream

FYI Fedora 34 OCaml 4.11.1 rebuild

2020-09-01 Thread Richard W.M. Jones
We did a Fedora 34 OCaml 4.11.0 rebuild a couple of weeks back, something like 170+ packages. Well, a compiler bug was found and upstream released OCaml 4.11.1. Details here: https://bugzilla.redhat.com/show_bug.cgi?id=1870368#c26 So I'm going to do a 4.11.1 build (into a side tag first).

Re: Did default umask change in Rawhide?

2020-08-26 Thread Richard W.M. Jones
On Wed, Aug 26, 2020 at 10:03:24AM +0100, Richard W.M. Jones wrote: > > Suddenly the umask in my Fedora Rawhide system seems to have > changed from 0002 -> 0077. As far as I know this didn't > happen because of any action I have taken. Never mind, this was a bug: https://bugz

Did default umask change in Rawhide?

2020-08-26 Thread Richard W.M. Jones
Suddenly the umask in my Fedora Rawhide system seems to have changed from 0002 -> 0077. As far as I know this didn't happen because of any action I have taken. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog:

Re: Where do we stand OCaml-wise?

2020-08-21 Thread Richard W.M. Jones
On Wed, Aug 19, 2020 at 04:19:59PM -0600, Jerry James wrote: > On Wed, Aug 19, 2020 at 4:04 PM Richard W.M. Jones wrote: > > OCaml 4.11.0 is out. Is this a good time to start a rebuild > > of all the OCaml packages? (in a Rawhide side tag) > > > > I have to say it

Re: Where do we stand OCaml-wise?

2020-08-19 Thread Richard W.M. Jones
OCaml 4.11.0 is out. Is this a good time to start a rebuild of all the OCaml packages? (in a Rawhide side tag) I have to say it doesn't matter if not every OCaml package is in perfect shape, because we can build any stragglers afterwards. https://bugzilla.redhat.com/show_bug.cgi?id=1870368

Re: What is the real value of Release and %changelog metadata?

2020-08-17 Thread Richard W.M. Jones
On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote: > Let's stop requiring Release bumps for each build. And let's put an > additional tag into Release, like proposed in [4]: > > "Release: 1%{?dist}%{?buildtag}" Can I ask why this wouldn't be: Release: 1%{?buildtag}%{?dist} ?

nothing provides kernel needed by libguestfs-1:1.43.1-4.fc33.x86_64

2020-08-12 Thread Richard W.M. Jones
I suppose this might be a temporary issue caused by branching, but this build in Rawhide has been failing since yesterday: https://koji.fedoraproject.org/koji/taskinfo?taskID=49144308 The error is a bit odd: DEBUG util.py:621: Error: DEBUG util.py:621: Problem: package

Re: dummy libraries for proprietary dependencies (especially NVIDIA)

2020-08-11 Thread Richard W.M. Jones
On Tue, Aug 11, 2020 at 03:11:03PM +0100, Dave Love wrote: > Is there the possibility of building packages with dummy shims for > proprietary dynamic libraries that could be substituted at runtime > (i.e. a package BRs dummy-libthing-devel, and dynamic linker paths > provide the nasty real

Re: Zanata removal is soon, please finish migration

2020-08-11 Thread Richard W.M. Jones
On Tue, Aug 11, 2020 at 05:28:26AM -, Jean-Baptiste Holcroft wrote: > libguestfshttps://bugzilla.redhat.com/show_bug.cgi?id=1787301 I believe we have now done everything on our side. > virt-top No bug ..? Rich. -- Richard Jones, Virtualization Group, Red Hat

Re: OCaml + binutils 2.35 on i386

2020-08-05 Thread Richard W.M. Jones
On Wed, Aug 05, 2020 at 09:54:14AM +0200, Florian Weimer wrote: > * Richard W. M. Jones: > > > On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote: > >> When ocamlopt is used with binutils 2.35 to link an executable, we now > >> get warnings that look like this: > >> > >> /usr/bin/ld:

Re: OCaml + binutils 2.35 on i386

2020-08-04 Thread Richard W.M. Jones
On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote: > When ocamlopt is used with binutils 2.35 to link an executable, we now > get warnings that look like this: > > /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only > section `.text' > /usr/bin/ld: warning: creating

Re: ocaml-ppx-tools-versioned debuginfo disabled, dune and ppx extensions

2020-08-04 Thread Richard W.M. Jones
On Tue, Aug 04, 2020 at 08:46:40AM +0100, Richard W.M. Jones wrote: > I disabled debuginfo generation in ocaml-ppx-tools-versioned > temporarily. > > It seems there is a bug in dune which causes the -g option to be > omitted when linking ppx extensions. This will requir

Re: Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)

2020-08-04 Thread Richard W.M. Jones
On Tue, Aug 04, 2020 at 11:24:24AM +0200, Mark Wielaard wrote: > Hi Richard, > > On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote: > > In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log > > (from https://koji.fedoraproject.org/koji/tas

Still seeing "DWARF version 0 unhandled" (was: Re: No debugsource generated, weird DWARF errors)

2020-08-04 Thread Richard W.M. Jones
In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877) I'm still seeing errors like: /usr/lib/rpm/debugedit:

ocaml-ppx-tools-versioned debuginfo disabled, dune and ppx extensions

2020-08-04 Thread Richard W.M. Jones
I disabled debuginfo generation in ocaml-ppx-tools-versioned temporarily. It seems there is a bug in dune which causes the -g option to be omitted when linking ppx extensions. This will require a fix to dune, and then I should be able to reenable debuginfo again in this package. (The same bug

FTBFS filed incorrectly and linked to the wrong build

2020-08-03 Thread Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1865666 links to the latest build, but that's the ELN build (which failed): https://koji.fedoraproject.org/koji/packageinfo?packageID=8391 The latest F33 build did not fail. I believe this bug was filed incorrectly and perhaps the script that files

Re: /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied

2020-08-03 Thread Richard W.M. Jones
On Mon, Aug 03, 2020 at 10:42:01PM +0100, Richard W.M. Jones wrote: > I can't reproduce this locally but it happens in Koji reliably enough: > > + /usr/lib/rpm/brp-strip /usr/bin/strip > /usr/bin/strip: unable to copy file > '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33

/usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied

2020-08-03 Thread Richard W.M. Jones
I can't reproduce this locally but it happens in Koji reliably enough: + /usr/lib/rpm/brp-strip /usr/bin/strip /usr/bin/strip: unable to copy file '/builddir/build/BUILDROOT/ocaml-omake-0.10.3-27.fc33.x86_64/usr/bin/omake'; reason: Permission denied error: Bad exit status from

Re: What do to about massive # of FTBFS bugs?

2020-08-03 Thread Richard W.M. Jones
On Mon, Aug 03, 2020 at 04:04:57PM -0500, Richard Shaw wrote: > I'm up to 21 and climbing. Technically two are failure to install... > > I'm confused if I should even fix these right now due to the various issues > I've seen on the list. > > Is it safe to do builds right now? Everything is

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-08-01 Thread Richard W.M. Jones
On Sat, Aug 01, 2020 at 01:28:09PM -0600, Jeff Law wrote: > On Sat, 2020-08-01 at 12:34 +0100, Richard W.M. Jones wrote: > > On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > > > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > > > On Fri, Ju

Re: libcroco retired on Rawhide, breaking builds

2020-08-01 Thread Richard W.M. Jones
On Sat, Aug 01, 2020 at 03:13:50PM +0200, Fabio Valentini wrote: > On Sat, Aug 1, 2020 at 2:44 PM Richard W.M. Jones wrote: > > > > On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > > > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(

Re: libcroco retired on Rawhide, breaking builds

2020-08-01 Thread Richard W.M. Jones
On Sat, Aug 01, 2020 at 03:25:48AM -0400, Elliott Sales de Andrade wrote: > libcroco was retired on Rawhide, but the libcroco-0.6.so.3()(64bit) it > provides is used by libtextstyle.so.0, part of gettext. > > gettext is used by many many things. Please unretire libcroco, or > rebuild gettext

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-08-01 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 05:32:34PM -0600, Jeff Law wrote: > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > > Looks like it's in the buildroots now. Let me know if that doesn't fix >

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 01:37:25PM -0600, Jeff Law wrote: > On Fri, 2020-07-31 at 19:26 +0100, Richard W.M. Jones wrote: > > On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > > > Looks like it's in the buildroots now. Let me know if that doesn't fix >

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 12:02:22PM -0600, Jeff Law wrote: > Looks like it's in the buildroots now. Let me know if that doesn't fix the > problem. Looks as if "ar" is segfaulting again ... https://koji.fedoraproject.org/koji/taskinfo?taskID=48288440

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 10:55:15AM -0600, Jeff Law wrote: > On Fri, 2020-07-31 at 14:07 +0200, Florian Weimer wrote: > > * Richard W. M. Jones: > > > > > Here's another one: > > > > > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > > > libguestfs-tools-c-1.43.1-2.fc33.x86_64 > > >

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 05:19:15PM +0100, Richard W.M. Jones wrote: > (It's a bit big so I sent this to you privately) Ooops, at least that was what I intended to do. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualizat

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
(It's a bit big so I sent this to you privately) On Fri, Jul 31, 2020 at 10:07:09AM -0600, Jeff Law wrote: > On Fri, 2020-07-31 at 11:52 +0100, Richard W.M. Jones wrote: > > Here's another one: > > > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > > libgu

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 11:52:05AM +0100, Richard W.M. Jones wrote: > Here's another one: > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > libguestfs-tools-c-1.43.1-2.fc33.x86_64 > readline-8.0-5.fc33.x86_64 > $ guestfish --version > Segmentati

Re: No debugsource generated, weird DWARF errors

2020-07-31 Thread Richard W.M. Jones
On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote: > Hi Guys, > > >> Yes, because the commit adding the DWARF 4 patch has also > >> turned LTO back on... > > *double sigh*. Yes I was trying to fix the LTO bug at the same time, > and forgot that I had re-enabled it in my local copy

Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Richard W.M. Jones
Here's another one: $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 libguestfs-tools-c-1.43.1-2.fc33.x86_64 readline-8.0-5.fc33.x86_64 $ guestfish --version Segmentation fault (core dumped) (gdb) bt #0 0x in () #1 0x7f3212b72dad in history_filename

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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: > > > &

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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 > > >

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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 a

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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/t

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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

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

2020-07-30 Thread 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:

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

2020-07-30 Thread 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

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

2020-07-30 Thread 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

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

2020-07-30 Thread 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 ... >

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

2020-07-30 Thread 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

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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):

Disabled LTO on qemu

2020-07-30 Thread 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):

Re: No debugsource generated, weird DWARF errors

2020-07-30 Thread 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

Re: No debugsource generated, weird DWARF errors

2020-07-29 Thread Richard W.M. Jones
On Wed, Jul 29, 2020 at 06:50:43PM +0200, Xavier Leroy wrote: > However, please keep backward compatibility in mind: from the Info manual > it looks like gas version 2.34 has no `-g` option and no directives to > control the generation of DWARF information. So there should be reasonable >

Re: No debugsource generated, weird DWARF errors

2020-07-29 Thread Richard W.M. Jones
On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote: > > (Adding OCaml author) > > (Adding binutils/gas maintainer) > > > On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard w

Re: No debugsource generated, weird DWARF errors

2020-07-29 Thread Richard W.M. Jones
(Adding OCaml author) On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote: > Hi Richard, > > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote: > > On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote: > > > Given these are .ml files I suspect

Re: No debugsource generated, weird DWARF errors

2020-07-29 Thread Richard W.M. Jones
On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote: > > On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails > >

s390 builds failing with "All mirrors were tried"

2020-07-29 Thread Richard W.M. Jones
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

ceph -> qemu -> lots failing in the mass rebuild

2020-07-29 Thread Richard W.M. Jones
qemu is uninstallable at the moment because ceph is uninstallable because fmt was upgraded from 6 to 7 in the middle of the build (resulting in an soname bump - it was announced). There are quite a few things failing in the mass rebuild as a result. I've kicked off a new build of ceph, and will

Re: Rebase of fmt to 7.0.0

2020-07-29 Thread Richard W.M. Jones
On Wed, Jul 29, 2020 at 01:44:34PM +0100, Richard W.M. Jones wrote: > On Tue, Jul 07, 2020 at 04:56:40PM +0200, Vitaly Zaitsev via devel wrote: > > Hello all. > > > > Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next > > week. > > > >

Re: Rebase of fmt to 7.0.0

2020-07-29 Thread Richard W.M. Jones
On Tue, Jul 07, 2020 at 04:56:40PM +0200, Vitaly Zaitsev via devel wrote: > Hello all. > > Fmt package will be rebased in Rawhide from version 6.2.1 to 7.0.0 next > week. > > This will include soversion bump from 6 to 7. All dependent packages > must be rebuilt. > > Please check your packages,

Re: DWARF version 0 unhandled

2020-07-29 Thread Richard W.M. Jones
On Tue, Jul 28, 2020 at 08:58:22PM -0600, Jeff Law wrote: > On Tue, 2020-07-28 at 16:26 -0600, Jerry James wrote: > > Here's a bit of fallout from the mass rebuild. The alt-ergo build failed: > > > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1548139 > [ ... ] > You might try without

No debugsource generated, weird DWARF errors

2020-07-29 Thread Richard W.M. Jones
https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails with: error: Empty %files file /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list However it works when I build locally: $ rpm -qlp /home/rjones/d/fedora/hevea/master/x86_64/hevea-debugsource-2.34-7.fc33.x86_64.rpm

Re: Over 1000 (retired) packages orphaned

2020-07-28 Thread Richard W.M. Jones
I went through this list ... On Mon, Jul 27, 2020 at 10:10:36PM +0200, Pierre-Yves Chibon wrote: > Orphaning rpms/jbuilder from tc01 Right, this was renamed "dune", so this should be orphaned. > Orphaning rpms/ocaml-preludeml from rjones > Orphaning rpms/ocaml-reins from rjones Right, both

Re: xen soname bump

2020-07-28 Thread Richard W.M. Jones
On Mon, Jul 27, 2020 at 02:40:28PM -0700, Kevin Fenzi wrote: > On Sun, Jul 26, 2020 at 05:03:50PM +0100, Michael Young wrote: > > I am about to update xen to xen-4.14.0 on rawhide, which will update the > > version on many libraries in xen-libs from 4.13 to 4.14. Packages that use > > these

Re: ar (binutils) segfaulting in Rawhide - known bug?

2020-07-25 Thread Richard W.M. Jones
On Sat, Jul 25, 2020 at 01:11:25AM -0600, Jeff Law wrote: > So at a high level ar makes a call to lrealpath. That naturally goes through > the > PLT. The PLT stub loads the value out of the GOT and jumps to it. The > problem > is the entry in the GOT is *zero* when it should be pointing to

Re: ar (binutils) segfaulting in Rawhide - known bug?

2020-07-24 Thread Richard W.M. Jones
On Fri, Jul 24, 2020 at 03:37:05PM -0600, Jeff Law wrote: > Hmm, what's interesting here is that it's binutils-2.34, so it's not > the update that Nick was doing to do today. I've seen a couple > folks trip over this today and just saw it in a couple of my builds. I believe it's the version that

ar (binutils) segfaulting in Rawhide - known bug?

2020-07-24 Thread Richard W.M. Jones
Just upgraded a development machine to: binutils-2.34.0-10.fc33.x86_64 gcc-10.1.1-2.fc33.x86_64 glibc-2.31.9000-21.fc33.x86_64 and a very simple C compile (non-LTO) is now segfaulting: make[3]: Entering directory '/home/rjones/d/nbdkit/common/protocol' /bin/sh ../../libtool --tag=CC

Re: pagure pull-request email workflow

2020-07-24 Thread Richard W.M. Jones
On Wed, Jul 22, 2020 at 02:19:59PM +0200, Mark Wielaard wrote: > Hi Tom, > > On Tue, 2020-07-21 at 13:53 +0100, Tom Hughes via devel wrote: > > On 21/07/2020 13:12, Mark Wielaard wrote: > > > > I normally just edit .git/config and add to the origin remote > > > > an extra fetch: > > > > > > > >

Re: Preparing for ocaml 4.11

2020-07-03 Thread Richard W.M. Jones
FWIW looks like OCaml 4.11 beta 1 was released earlier this week. https://discuss.ocaml.org/t/ocaml-4-11-first-beta-release/6042 So I will try a mass rebuild into a side tag soon, and see what the fallout is. I believe I've added all the new packages added recently to my list. I've no

Re: out of Koji disk space

2020-07-01 Thread Richard W.M. Jones
On Wed, Jul 01, 2020 at 02:00:09PM +0200, Jan Kratochvil wrote: > On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote: > > In the end we have limited resources and you are running into those > > limits. We can either have fewer builders with more disk space and a > > long queue of

Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 03:27:45PM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote: > > * Jóhann B. Guðmundsson: > > > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > > changes it beg the question if now would not be the

Re: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 04:25:58PM +0200, Marcin Juszkiewicz wrote: > W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze: > > On 30/06/2020 15:00, Florian Weimer wrote: > >> * Jóhann B. Guðmundsson: > >> > >>> Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > >>> changes it

Re: Better Thermal Management for the Workstation - Fedora 33 Self-Contained Change proposal

2020-07-01 Thread Richard W.M. Jones
On Tue, Jun 30, 2020 at 10:30:21AM -0400, Owen Taylor wrote: > So, this was discussed quite a bit in > https://pagure.io/fedora-workstation/issue/71 and the conclusion that > the Workstatopn Working Group came to 3 months ago was that we didn't > want to do this. We basically understood that main

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-01 Thread Richard W.M. Jones
While this isn't a problem for Fedora per se, it's worth noting. OpenSUSE uses btrfs by default and as a result we're unable to open SUSE guest images from distros that don't include btrfs in the kernel (ie. RHEL, and maybe CentOS unless you use an alternate kernel). So that would apply to

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-07-01 Thread Richard W.M. Jones
I might support this, but Nano is a terrible editor. It has key bindings that are quite unlike any other program and conflict with normal bindings that newbies might be used to (eg. ^X is cut, not exit). If we're going to newbies how about a more MS-DOS-ish experience, eg:

Re: Please BuildRequire python3-setuptools explicitly

2020-07-01 Thread Richard W.M. Jones
On Tue, Jun 23, 2020 at 06:28:00PM -, Miro Hrončok wrote: > > On Tue, Jun 23, 2020 at 06:26:23PM +0200, Tomas Hrnciar wrote: > > > > This package depends on python3-devel. However the last build.log: > > > > > > https://kojipkgs.fedoraproject.org//packages/qemu/5.0.0/2.fc33/data/logs/...

Re: Preparing for ocaml 4.11

2020-06-25 Thread Richard W.M. Jones
On Thu, Jun 25, 2020 at 12:15:51PM +0200, Dan Čermák wrote: > "Richard W.M. Jones" writes: > > >> Maybe I should do COPR builds of all this so everybody can easily see > >> what I'm talking about? I did a total of 63 package builds in mock, > >> ma

Re: Preparing for ocaml 4.11

2020-06-24 Thread Richard W.M. Jones
On Wed, Jun 24, 2020 at 12:39:24PM -0600, Jerry James wrote: > This message is mostly for Richard Jones, but I'm sending it to the > list so that others who maintain OCaml packages can weigh in if they > choose. I have BCCed a few of you that are affected by some > suggestions I make below. > >

Re: Please BuildRequire python3-setuptools explicitly

2020-06-23 Thread Richard W.M. Jones
On Tue, Jun 23, 2020 at 06:26:23PM +0200, Tomas Hrnciar wrote: > qemu amitshah berrange bonzini crobinso dwmw2 ehabkost > jforbes lkundrak quintela rjones This package depends on python3-devel. However the last build.log:

Re: Easier way to autogenerate Provides?

2020-06-15 Thread Richard W.M. Jones
On Mon, Jun 15, 2020 at 07:50:11AM -0400, Neal Gompa wrote: > On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa wrote: > > > > On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones > > wrote: > > > > > > We autogenerate RPM Requires/Provides in a few projects, a

Easier way to autogenerate Provides?

2020-06-15 Thread Richard W.M. Jones
We autogenerate RPM Requires/Provides in a few projects, and it's quite nice. eg: supermin-devel has: $ rpm -ql supermin-devel /usr/lib/rpm/fileattrs/supermin.attr /usr/lib/rpm/supermin-find-requires and this means other packages that contain supermin appliances can simply put their

Re: Something weird with modules in kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64

2020-06-09 Thread Richard W.M. Jones
On Tue, Jun 09, 2020 at 03:05:05PM +0100, Richard W.M. Jones wrote: > I've installed kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64 but > not rebooted (still running 5.6.0-0.rc5.git0.1.fc33.x86_64 on the host). > > However /lib/modules/5.8.0-[...] has not been fully created

Something weird with modules in kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64

2020-06-09 Thread Richard W.M. Jones
I've installed kernel-5.8.0-0.rc0.20200608gitaf7b4801030c.1.fc33.x86_64 but not rebooted (still running 5.6.0-0.rc5.git0.1.fc33.x86_64 on the host). However /lib/modules/5.8.0-[...] has not been fully created in some way. In particular there are no *.ko files at all under that directory: $ ls

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-08 Thread Richard W.M. Jones
On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: > On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann wrote: > > > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > > > To me this sounds like too much dependency on swap. > > > > That's not what I meant, I wanted to

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-08 Thread Richard W.M. Jones
On Sat, Jun 06, 2020 at 03:10:37PM -0700, Samuel Sieb wrote: > On 6/6/20 9:04 AM, Richard W.M. Jones wrote: > >On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: > >>This laptop with 8GiB RAM is running two VMs at the same time: Windows > >>10 and Fedo

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-06 Thread Richard W.M. Jones
On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: > See, this is a clear indication that you don't understand what it is > doing and weren't listening to the various people trying to explain > it. Not sure this is needed. The conversation so far has talked about many interesting

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-06 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: > This laptop with 8GiB RAM is running two VMs at the same time: Windows > 10 and Fedora Workstation 32. The host is Fedora Workstation 32. So this suggests another interesting question: If I have Fedora virtual machines running on a

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-06 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 05:55:26PM +0200, Igor Raits wrote: > On Fri, 2020-06-05 at 15:11 +0100, Richard W.M. Jones wrote: > > I'm unclear: that ~50M is still in RAM? Or it's compressed on a disk > > somewhere? > > IIUC, it takes some part of the RAM and just com

Re: Let's standardize the way to disable tests during RPM build?

2020-06-05 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 04:38:03PM +0200, Miro Hrončok wrote: > On 05. 06. 20 16:26, Richard W.M. Jones wrote: > >On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote: > >>Hi, > >>I think it would be useful to have a standard way of disabling the > >&

Re: [Fedora-packaging] Let's standardize the way to disable tests during RPM build?

2020-06-05 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 10:28:39AM -0400, Paul Wouters wrote: > Or just a new option to rpmbuild that skips %check ? It exists already: rpmbuild --nocheck. It's not wired into the rest of the stack - eg. you cannot start a Koji build with checks disabled. IMHO that's a good thing, although

Re: Let's standardize the way to disable tests during RPM build?

2020-06-05 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 04:10:20PM +0200, Tomas Orsava wrote: > Hi, > I think it would be useful to have a standard way of disabling the > running of tests during RPM build (in the %check section of a spec > file). > > I see a lot of packages already having %bcond's or other macro > definitions

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 08:27:13AM -0400, Neal Gompa wrote: > On Fri, Jun 5, 2020 at 8:26 AM Neal Gompa wrote: > > > > On Fri, Jun 5, 2020 at 6:47 AM Vitaly Zaitsev via devel > > wrote: > > > > > > On 05.06.2020 09:52, Kevin Kofler wrote: > > > > I am opposed to this change. Chromium and Firefox

Re: Fedora 33 System-Wide Change proposal: swap on zram

2020-06-05 Thread Richard W.M. Jones
On Fri, Jun 05, 2020 at 01:50:29AM -0600, Chris Murphy wrote: > On Fri, Jun 5, 2020 at 12:33 AM Milan Crha wrote: > > > > On Thu, 2020-06-04 at 16:30 -0400, Ben Cotton wrote: > > > ... The memory used is not preallocated. It's > > > dynamically allocated and deallocated, on demand. ... > > > > >

Is the name of this review package OK?

2020-06-05 Thread Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1825456 Proposed package name is "libvirt-test-api". Upstream name is "libvirt-test-API". It is, very very loosely, a Python 3 API and the package includes Python development files. But on the other hand it's a set of regression tests and the fact

Re: Has something changed with RPMS?

2020-06-03 Thread Richard W.M. Jones
I should say that there's also the possibility of writing a block device plugin which is highly tuned in some way to the Koji use case. We've already done discarding flushes and showed that you get all the benefit of a RAM disk just by doing that (even when backed by a disk). Is there anything

Re: Has something changed with RPMS?

2020-06-03 Thread Richard W.M. Jones
On Wed, Jun 03, 2020 at 11:13:26AM +0200, Vít Ondruch wrote: > > Dne 02. 06. 20 v 19:26 Richard W.M. Jones napsal(a): > > On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote: > >> * Panu Matilainen: > >> > >>> Lets start with the basics: >

  1   2   3   4   5   6   7   8   9   10   >