4:48 a.m.
Hi,
I plan to resolve few mock issues next week and do the release before Christmas.
The plan is not to enable karma, so you will not be surprised by new version of mock on
your stable servers.
If you have some patch in your private branch then now is the right time to send the PR.
Mirek
10 a.m.
Hi Miroslav. Thank you for the heads up. Do you have a list of
changes that will included in the release? Are there plans to test
the new release with Koji or other tools that depend on mock before
enabling karma?
Cheers
-- Dennis
On Fri, Dec 15, 2017 at 5:48 AM, Miroslav Suchý <msuchy(a)redhat.com> wrote:
Hi,
I plan to resolve few mock issues next week and do the release before Christmas.
The plan is not to enable karma, so you will not be surprised by new version of mock on
your stable servers.
If you have some patch in your private branch then now is the right time to send the PR.
Mirek
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
--
Dennis Gregorovic
Manager, PnT DevOps
Red Hat
dgregor(a)redhat.com T: +1-978.392.3112 M: +1-617.901.9799
1:35 a.m.
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=1007638
I am not really sure why.
Mirek
5:19 a.m.
On Mon, Dec 18, 2017 at 2:35 AM, Miroslav Suchý <msuchy(a)redhat.com> 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=1007638
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
--
真実はいつも一つ！/ Always, there's only one truth!
1:18 p.m.
On 12/18/2017 03:19 AM, Neal Gompa wrote:
On Mon, Dec 18, 2017 at 2:35 AM, Miroslav Suchý
<msuchy(a)redhat.com> 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=1007638
> 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.
https://pagure.io/releng/issue/6967
kevin
2:04 a.m.
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ý <msuchy(a)redhat.com> 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=1007638
>> 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.
https://pagure.io/releng/issue/6967
It is better to set
config_opts['use_nspawn'] = False
This way, you will get all new fixes and you will use the old chroot.
Mirek
5:16 a.m.
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ý <msuchy(a)redhat.com> 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=1007638
>> 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.
https://pagure.io/releng/issue/6967
kevin
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
--
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat
12:03 p.m.
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ý <msuchy(a)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.
5:49 a.m.
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ý <msuchy(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
--
Tomas Kopecek <tkopecek(a)redhat.com>
Release Engineering Development, RedHat
2316
days inactive
2321
days old
buildsys@lists.fedoraproject.org
8 comments
6 participants
participants (6)
-
Dennis Gregorovic -
John Florian -
Kevin Fenzi -
Miroslav Suchý -
Neal Gompa -
Tomáš Kopeček