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 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 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 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:/
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
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
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
> defaults
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 wrot
(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
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
> >
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
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
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.
> >
> >
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, b
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 L
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
/
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 dead
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 librari
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 the
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
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 --mode=co
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:
> > > >
> > > > f
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 intent
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 builds
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
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 b
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 w
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 Fedora
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:
https://en.wikipedi
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/...
>
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,
> >>
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.
>
> I
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:
https://kojipkgs.fedoraproject.org//packages/qemu/5.0.0
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
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 applia
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 cr
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 /li
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 emphasiz
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 Fedora
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 topics
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 Fe
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
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
> >>r
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
when
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 to
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
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. ...
> > >
> > >
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 the
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 els
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:
>
On Tue, Jun 02, 2020 at 07:53:23PM +0200, Igor Raits wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2020-06-02 at 18:09 +0100, Richard W.M. Jones wrote:
> > DEBUG util.py:600: Problem: package python3-dnf-4.2.21-
> > 2.fc33.noarch requires pytho
On Tue, Jun 02, 2020 at 12:44:17PM +0200, Florian Weimer wrote:
> * Panu Matilainen:
>
> > Lets start with the basics:
> > - is sqlite even involved - it will only be used on rawhide builds if
> > mock bootstrap is used
> > - does it make a difference if you override _db_backend to bdb/sqlite
> >
DEBUG util.py:600: Problem: package python3-dnf-4.2.21-2.fc33.noarch requires
python3-hawkey >= 0.46.2, but none of the providers can be installed
DEBUG util.py:600:- package python3-hawkey-0.48.0-1.fc33.x86_64 conflicts
with python3-dnf < 4.2.23 provided by python3-dnf-4.2.21-2.fc33.noarc
On Sat, May 30, 2020 at 12:46:18PM -0600, Orion Poplawski wrote:
> Folks -
>
>I'm afraid the new FailsToInstall bugs may be a bit much for me.
> Often it seems:
>
> - There is already a FTBFS bug against the package which is the root
> cause of the FTI.
> - There was a soname bump in rawide a
On Fri, May 29, 2020 at 09:59:27PM +0200, Miro Hrončok wrote:
> coccinelle rjones
This one has a bug and an upstream fix already, I "just" have to apply it:
https://bugzilla.redhat.com/show_bug.cgi?id=1791765#c10
The only possible problem is it seems to be bundling a Python library
whi
On Tue, May 26, 2020 at 11:19:11PM +0800, Andy Li wrote:
> Hi Richard,
>
> Thank you for looking into this.
>
> On Tue, May 26, 2020 at 6:51 PM Richard W.M. Jones wrote:
> > I looked at the packages in Fedora which BR ocaml-extlib and it looks
> > like nothing uses th
https://bugzilla.redhat.com/show_bug.cgi?id=1837823
Hopefully I've CC'd this to everyone who has a package that
BuildRequires ocaml-extlib in Fedora.
As Andy pointed out in the bug report above, ocaml-extlib has two ways
to build it, and upstream recommends building using the "minimal"
variant.
Context:
https://bugzilla.redhat.com/show_bug.cgi?id=1837809#c28
https://rwmj.wordpress.com/2020/03/21/new-nbdkit-remote-tmpfs-tmpdisk-plugin/
http://libguestfs.org/nbdkit-tmpdisk-plugin.1.html
https://github.com/libguestfs/nbdkit/blob/0632acc76bfeb7d70d3eefa42fc842ce6b7be4f8/plugins/tmpdisk/tmpdis
On Tue, May 19, 2020 at 08:43:01PM -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 20:24 -0700, Adam Williamson wrote:
> > On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > > The most suspicious change between the two build envs that I can see is
> > > openssl. GOOD has openssl-1.
On Tue, May 19, 2020 at 11:40:50AM +0200, Fabio Valentini wrote:
> On Tue, May 19, 2020 at 11:28 AM Vitaly Zaitsev via devel
> wrote:
> > Next time FESCo should forbid gcc updates to unreleased versions in
> > branched Fedora releases.
> >
> > Now we need a new mass rebuild in Fedora 32 with fixed
I was trying to chase down why modules.dep is no longer built in
Rawhide (which affects supermin and therefore libguestfs), but it
looks like there's a much more serious problem:
https://kojipkgs.fedoraproject.org//work/tasks/8242/44698242/root.log
(from https://koji.fedoraproject.org/koji/taskinf
On Fri, May 15, 2020 at 02:12:00PM -0400, Charalampos Stratakis wrote:
> nbdkit rjones
I guess nbdkit is one of the good ones? We link to libpython because
we want to run Python code from a C main program (nbdkit, an NBD
server written in C).
http://libguestfs.org/nbdkit-python-plu
New package honggfuzz (an easy to use fuzz tester) was added a few
hours ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1834964
Because it's ExcludeArch on s390x, I need to file a bug for that.
However as far as I can tell no honggfuzz component has been created
yet. How long should that norm
On Wed, May 13, 2020 at 12:49:35PM -0500, Michael Catanzaro wrote:
> On Wed, May 13, 2020 at 9:51 am, Stephen John Smoogen
> wrote:
> >Those pages are needing some love and care as aarch64 should not
> >be on it anymore. Currently the primary architectures that Fedora
> >builds against are
> >
> >
FYI:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-852e4b2199
--
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 Win
On Mon, May 04, 2020 at 05:02:13PM +0200, Fabio Valentini wrote:
> For you, those broken packages are:
>
> jjames flocq
> jjames frama-c
> jjames gappalib-coq
> jjames ocaml-lablgtk3
> jjames ocaml-lablgtk3-devel
> jjames ocaml-lablgtk3-gtkspell3
> jjames ocaml-lablgtk3
On Tue, May 05, 2020 at 02:09:46PM +0100, Richard W.M. Jones wrote:
> On Sun, May 03, 2020 at 09:46:35AM +0200, Igor Gnatenko wrote:
> > Hello,
> >
> > Is anybody planning to fix bunch of FTI (Fails To Install) ocaml
> > packages in rawhide?
>
> Sorry, didn'
On Sun, May 03, 2020 at 09:46:35AM +0200, Igor Gnatenko wrote:
> Hello,
>
> Is anybody planning to fix bunch of FTI (Fails To Install) ocaml
> packages in rawhide?
Sorry, didn't see this email to now.
There's a new build of OCaml 4.11 prerelease going through right now
(since yesterday evening).
On Wed, Apr 22, 2020 at 08:28:45PM +0100, Richard W.M. Jones wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-150918c861
>
> A summary of what happened:
>
> * Coq (and friends) don't build because camlp5 -> lablgtk3 -> coq.
> camlp5 has not been porte
On Thu, Apr 23, 2020 at 05:22:01PM +0100, Stephen Coady wrote:
> Hi,
>
> Development work has begun on the API which will give applications access
> to the new AAA solution. As part of our effort to migrate to this new AAA
> solution we need to identify applications which consume the old FAS API i
On Thu, Apr 23, 2020 at 10:16:49AM -0500, Richard Shaw wrote:
> On Wed, Apr 22, 2020 at 7:16 AM Nick Clifton wrote:
>
> > *sigh* Sorry guys. Please try using annobin-9.21.1-fc33. This should
> > fix the issue.
> >
>
> Just got bit by this on a local mock build for Rawhide... Can it be ignore
https://bodhi.fedoraproject.org/updates/FEDORA-2020-150918c861
A summary of what happened:
* Coq (and friends) don't build because camlp5 -> lablgtk3 -> coq.
camlp5 has not been ported upstream to OCaml 4.11.
* Same for haxe and why3.
* I wasn't able to "unbootstrap" menhir and dune since the
gpgverify commands are failing in Rawhide at the moment:
gpgv2: symbol lookup error: /lib64/libgcrypt.so.20: undefined symbol: dlopen
I filed a BZ about it:
https://bugzilla.redhat.com/show_bug.cgi?id=1826925
(or is this a bug in gnupg2?) I guess this will affect any package
that verifies
On Wed, Apr 22, 2020 at 06:05:57PM +0200, Florian Weimer wrote:
> * Jerry James:
>
> > On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones
> > wrote:
> >> It turns out it comes from dune (the build tool), although I'm still
> >> unclear how and why. In a
On Wed, Apr 22, 2020 at 10:19:47AM -0500, Richard Shaw wrote:
> On Wed, Apr 22, 2020 at 10:13 AM Michael Cronenworth
> wrote:
>
> > On 4/22/20 9:51 AM, Richard Shaw wrote:
> > > So it seems what's really needed is a method to support software with
> > > optimizations above the baseline without le
On Wed, Apr 22, 2020 at 12:47:11PM +0100, Richard W.M. Jones wrote:
> This is a strange one:
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1496787
>
> (cd _build/default/src && /usr/bin/gcc -I /usr/lib64/ocaml -I
> /usr/lib64/ocaml/bytes -I /usr/lib64/ocam
This is a strange one:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1496787
(cd _build/default/src && /usr/bin/gcc -I /usr/lib64/ocaml -I
/usr/lib64/ocaml/bytes -I /usr/lib64/ocaml/cudf -I /usr/lib64/ocaml/extlib -I
glpk -O2 -fno-strict-aliasing -fwrapv -fexcess-precision=standard -O2
For example in:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43612915
annobin: spydual.c: debugging: index = 1384 max = 1917
annobin: spydual.c: ICE: attempting to access a gcc command line option that is
not stored in global_options
annobin: spydual.c: ICE: Please contact the annobin mai
The second attempt at building OCaml packages in Rawhide (in a side
tag) is under way now.
All the bugs mentioned in the previous email should have been fixed
both upstream and by backporting those changes into our compiler.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.re
I was asked by David how we do OCaml builds, and finally I've written it up:
http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=blob;f=README
TL;DR - it's hard!
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog:
On Thu, Apr 16, 2020 at 09:48:11PM +0200, Fabio Valentini wrote:
> On Thu, Apr 16, 2020, 21:00 Richard W.M. Jones wrote:
>
> > On Thu, Apr 16, 2020 at 10:04:52AM -0600, Jerry James wrote:
> > > Sorry for the delay. In spite of being stuck in my house, life has
> > &
So several things went wrong, nothing too bad but it'll take a bit of
time to fix.
* We discovered two actual OCaml compiler bugs:
https://github.com/ocaml/ocaml/issues/9460
https://github.com/ocaml/ocaml/issues/9461
The first one is more serious and means we will need to completely
rest
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d57f17e529
I accidentally built it into Rawhide instead of into the side tag.
Unfortunately I can't untag it myself apparently:
$ koji untag-build f33 ocaml-4.11.0-0.1.pre.fc33
2020-04-17 17:17:37,473 [ERROR] koji: ActionNotAllowed: tag requires
On Thu, Apr 16, 2020 at 03:43:39PM -0600, Jerry James wrote:
> On Thu, Apr 16, 2020 at 1:00 PM Richard W.M. Jones wrote:
> > Sure, I can do the rebuild tomorrow, if you push the changes
> > today.
>
> All of the changes have been pushed. I have made utop buildable
> agai
On Thu, Apr 16, 2020 at 10:04:52AM -0600, Jerry James wrote:
> Sorry for the delay. In spite of being stuck in my house, life has
> been amazingly busy lately...
>
> On Mon, Apr 13, 2020 at 2:32 PM Richard W.M. Jones wrote:
> > Long and the short is this will require some sort
On Mon, Apr 13, 2020 at 11:36:03AM -0600, Jerry James wrote:
> I would like to update the ocaml-bisect-ppx package to its latest
> version, 2.3.1. It is currently on a post-1.4.1 git snapshot. The
> new version requires ocaml-ppx-tools-versioned >= 5.3.0. That
> requirement sets off a cascade of
(Previously and briefly discussed on this list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2O4HBOK6PTQZAFAVIRDVMZGG2PYB2QHM/)
In:
https://github.com/ocaml/ocaml/pull/9435
Especially the second comment onwards, claims that the host triple
that our %config
On Mon, Apr 06, 2020 at 09:42:22AM +0100, Richard W.M. Jones wrote:
> On Sun, Apr 05, 2020 at 09:08:51PM -0600, Jerry James wrote:
> > Hi Richard,
> >
> > On Sun, Apr 5, 2020 at 3:45 AM Richard W.M. Jones wrote:
> > > https://koji.fedoraproject.org/koji/taskinfo?t
Oh actually it's just started being pushed to stable. Thanks all.
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/vir
On Wed, Apr 08, 2020 at 01:43:37PM +0200, Clement Verna wrote:
> On Wed, 8 Apr 2020 at 13:15, Richard W.M. Jones wrote:
>
> > On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote:
> > > >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120d
On Wed, Apr 08, 2020 at 11:57:27AM +0200, Clement Verna wrote:
> >> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
> You need to edit the update and remove these builds. You can click on the
> "edit" button on the left side of the update status, then you will have a
> list build
On Wed, Apr 08, 2020 at 08:53:38AM +0200, Igor Gnatenko wrote:
> I agree, if this would not happen then everything would just blow up.
Wouldn't the lower NVR builds simply be ignored?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and
On Tue, Apr 07, 2020 at 05:36:44PM -0400, Mohan Boddu wrote:
> On Tue, Apr 7, 2020 at 2:56 AM Richard W.M. Jones wrote:
> >
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
>
> I guess it should be a fixed in bodhi. But for now you can re
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d120de33c5
This one is a Rawhide update from a side tag, submitted on Sunday
morning which has been in pending for 2 days. (As it's Rawhide it's
supposed to spend 0 days in testing.) Is there any problem with it,
or do we just have to wait lon
On Thu, Apr 02, 2020 at 09:43:35AM +0100, Richard W.M. Jones wrote:
> On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
> > On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
> > >
> > >This is _only_ going into Rawhide / F33? It looks like the change to
&g
On Sat, Apr 04, 2020 at 12:42:29AM +0200, Miro Hrončok wrote:
> On 03. 04. 20 13:03, Richard W.M. Jones wrote:
> >
> >I've been waiting on:
> >
> >$ koji wait-repo f33-build-side-20855 --build=ocaml-lacaml-9.3.2-17.fc33
> >
> >for hours now. Seems li
I've been waiting on:
$ koji wait-repo f33-build-side-20855 --build=ocaml-lacaml-9.3.2-17.fc33
for hours now. Seems like newRepo generation is again taking a very
long time?
Also it'd be nice if this command didn't time out after 2 hours
(seems like a very odd and arbitrary choice - why not wa
On Thu, Apr 02, 2020 at 10:36:58AM +0300, Panu Matilainen wrote:
> On 4/1/20 8:40 PM, Richard W.M. Jones wrote:
> >
> >This is _only_ going into Rawhide / F33? It looks like the change to
> >the new OCaml dependency generator will require a complete rebuild of
> >all O
On Wed, Apr 01, 2020 at 03:38:45PM -0600, Jerry James wrote:
> On Wed, Apr 1, 2020 at 11:26 AM Richard W.M. Jones wrote:
> > Right, this change was made by Olaf (and I reviewed it), see:
> >
> > https://github.com/rpm-software-management/rpm/issues/913
> >
>
This is _only_ going into Rawhide / F33? It looks like the change to
the new OCaml dependency generator will require a complete rebuild of
all OCaml packages.
https://github.com/rpm-software-management/rpm/commit/a6fe37c39b39acbcbd014dd1e6d5653ff84254a1
https://github.com/rpm-software-management
901 - 1000 of 3293 matches
Mail list logo