Dne 19.12.2017 v 19:03 John Florian napsal(a):
On Tue, 2017-12-19 at 12:16 +0100, Tomáš Kopeček wrote:
Dne 18.12.2017 v 20:18 Kevin Fenzi napsal(a):
On 12/18/2017 03:19 AM, Neal Gompa wrote:
On Mon, Dec 18, 2017 at 2:35 AM, Miroslav Suchý <msu...@redhat.co
m> wrote:
Dne 15.12.2017 v 17:00 Dennis Gregorovic napsal(a):
Hi Miroslav. Thank you for the heads up. Do you have a list
of
changes that will included in the release?
Just a list of commits since last tag:
https://github.com/rpm-software-management/mock/commits/devel
Of course, once released there will be release notes as usual.
Are there plans to test
the new release with Koji or other tools that depend on mock
before
enabling karma?
I do not operate Koji. So I do not know. I *hope* that someone
tests with Koji.
My team is testing it with Copr, I am doing running regular
mock tests (included in mock itself), providing release
notes and these heads up.
But AFAIK fedora infra decided to stay with mock 1.3.4:
https://koji.fedoraproject.org/koji/buildinfo?buildID=100763
8
I am not really sure why.
It was because the private tmpfs /tmp thing from nspawn broke
Koji builds.
This is now fixed[1] in Koji 1.15, so Fedora Infrastructure has
no
reason to remain on 1.3.4.
[1]: https://pagure.io/koji/pull-request/602
no.
nspawn still does not work for a bunch of things koji does, some
known,
some unknown.
I've fixed only very basic issue, but we're not able to build e.g.
livemedia images at all as these depend on loopback devices, and yes,
I
also sometimes hit some random weird issues, which are not tracked
yet,
as I wasn't able to reproduce them.
I am successfully building livemedia images with koji-1.14 and only
needed to `koji edit-tag f25-build -x mock.new_chroot=False`. I'll
admit I haven't tried rebasing my custom spin on F27 yet, but I
wouldn't think that'd make a difference.
Yes, it shouldn't change for new_chroot=False - problems are with
nspawn-based approach.
_______________________________________________
buildsys mailing list -- buildsys@lists.fedoraproject.org
To unsubscribe send an email to buildsys-le...@lists.fedoraproject.org
--
Tomas Kopecek <tkope...@redhat.com>
Release Engineering Development, RedHat
_______________________________________________
buildsys mailing list -- buildsys@lists.fedoraproject.org
To unsubscribe send an email to buildsys-le...@lists.fedoraproject.org
