From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ

From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?




From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal

From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor

From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian



From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal

From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian


From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon


From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.

From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken


From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)


From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy


From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy


From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy


From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon

From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford


From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.



From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)

From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian


From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!

From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian



From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html

From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 

From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian


From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon


From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?

From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment-0002.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment-0002.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ


From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?





From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal


From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor


From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian




From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment-0002.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment-0002.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment-0002.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment-0002.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal


From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian



From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment-0002.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment-0002.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon



From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment-0002.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment-0002.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment-0002.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment-0002.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment-0002.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment-0002.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment-0002.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.


From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment-0002.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken



From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment-0002.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)



From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment-0002.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment-0002.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy



From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment-0002.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy



From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy



From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment-0002.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment-0002.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment-0002.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon


From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment-0002.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment-0002.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment-0002.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford



From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.




From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment-0002.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)


From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment-0002.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment-0002.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment-0002.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian



From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment-0002.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!


From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian




From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html


From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment-0002.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment-0002.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 


From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian



From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.


From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon



From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?


From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment-0003.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment-0003.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ


From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?





From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal


From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor


From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian




From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment-0003.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment-0003.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment-0003.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment-0003.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal


From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian



From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment-0003.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment-0003.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon



From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment-0003.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment-0003.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment-0003.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment-0003.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment-0003.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment-0003.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment-0003.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.


From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment-0003.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken



From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment-0003.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)



From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment-0003.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment-0003.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy



From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment-0003.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy



From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy



From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment-0003.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment-0003.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment-0003.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon


From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment-0003.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment-0003.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment-0003.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford



From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.




From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment-0003.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)


From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment-0003.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment-0003.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment-0003.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian



From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment-0003.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!


From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian




From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html


From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment-0003.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment-0003.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 


From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian



From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.


From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon



From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?


From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment-0004.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment-0004.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ


From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?





From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal


From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor


From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian




From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment-0004.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment-0004.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment-0004.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment-0004.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal


From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian



From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment-0004.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment-0004.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon



From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment-0004.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment-0004.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment-0004.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment-0004.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment-0004.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment-0004.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment-0004.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.


From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment-0004.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken



From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment-0004.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)



From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment-0004.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment-0004.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy



From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment-0004.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy



From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy



From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment-0004.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment-0004.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment-0004.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon


From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment-0004.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment-0004.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment-0004.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford



From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.




From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment-0004.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)


From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment-0004.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment-0004.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment-0004.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian



From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment-0004.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!


From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian




From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html


From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment-0004.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment-0004.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 


From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian



From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.


From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon



From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?


From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment-0005.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment-0005.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ


From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?





From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal


From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor


From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian




From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment-0005.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment-0005.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment-0005.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment-0005.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal


From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian



From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment-0005.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment-0005.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon



From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment-0005.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment-0005.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment-0005.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment-0005.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment-0005.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment-0005.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment-0005.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.


From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment-0005.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken



From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment-0005.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)



From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment-0005.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment-0005.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy



From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment-0005.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy



From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy



From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment-0005.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment-0005.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment-0005.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon


From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment-0005.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment-0005.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment-0005.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford



From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.




From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment-0005.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)


From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment-0005.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment-0005.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment-0005.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian



From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment-0005.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!


From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian




From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html


From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment-0005.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment-0005.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 


From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian



From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.


From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon



From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?


From lee.iitb at gmail.com  Sat Aug  1 18:13:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Sat, 1 Aug 2020 23:43:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
Message-ID: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>

On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu> wrote:

> On 7/30/20 10:51 AM, Lamar Owen wrote:
> > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >> However, what is really odd to me is that after the dnf downgrade of
> >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >> issuing a dnf update I don't see the grub2 and shim updates listed
> >> anymore.
> >
> > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> > does now list the updated release.  When I get enough time to
> > reproduce I might try the update again.
> So, the first update this morning was with the GUI updater that does the
> update during a reboot.  I just updated to the '87 release of grub2
> using dnf from the command line, and the update was successful, with a
> correctly booting system.  So I can't reproduce the issue on this laptop.
>
>
> Red Hat fixes are available.

https://access.redhat.com/errata/RHBA-2020:3265
https://access.redhat.com/errata/RHBA-2020:3262

wait for CentOS.

--
Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200801/32779e3d/attachment-0006.html>

From Antal.Nemes at hycu.com  Mon Aug  3 10:37:27 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 12:37:27 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
Message-ID: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>

Hi all,

I need sources for latest Centos 8.2 kernel (kernel-4.18.0-193.14.2.el8_2).
Since they are (now customarily) not available on vault.centos.org, I am attempting to build from git.centos.org.

However, I am unable to find the exact commit to build from.
On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3, but not 14.2 that actually shipped.

$git log --format="%C(auto) %h %s" origin/c8 | head -n 20
08e2843 debrand kernel-4.18.0-193.14.3.el8_2
284ac7b import kernel-4.18.0-193.14.3.el8_2
f990a59 Manual CentOS Debranding
6694789 debrand kernel-4.18.0-193.13.2.el8_2
56933c6 import kernel-4.18.0-193.13.2.el8_2
efc1e5b Manual CentOS Debranding
afc068a debrand kernel-4.18.0-193.6.3.el8_2
d0c1e45 import kernel-4.18.0-193.6.3.el8_2
9af314c Manual CentOS Debranding
b36366f debrand kernel-4.18.0-193.1.2.el8_2
c6227ee import kernel-4.18.0-193.1.2.el8_2
063bbb9 change to centos.pem
05d7b37 Manual CentOS Debranding
9f8b3f1 debrand kernel-4.18.0-193.el8
78ffa6b import kernel-4.18.0-193.el8
89ceb16 Manual CentOS Debranding
47aeda1 debrand kernel-4.18.0-147.8.1.el8_1
e9cecf3 import kernel-4.18.0-147.8.1.el8_1
718e82b Manual CentOS Debranding
223d051 debrand kernel-4.18.0-147.5.1.el8_1

Any help would be appreciated.

Thanks,
Antal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3a85e61b/attachment-0006.html>

From merlin at mwob.org.uk  Mon Aug  3 12:02:02 2020
From: merlin at mwob.org.uk (Howard Johnson)
Date: Mon, 03 Aug 2020 13:02:02 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>

On 2020-08-03 11:37, Antal Neme? wrote:
> Hi all,
> 
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).
> 
> Since they are (now customarily) not available on vault.centos.org, I
> am attempting to build from git.centos.org.
> 
> However, I am unable to find the exact commit to build from.
> 
> On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> but not 14.2 that actually shipped.
> 
> $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> 
> 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> 
> 284ac7b import kernel-4.18.0-193.14.3.el8_2

Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 
into the wild.  The RHEL update 
(https://access.redhat.com/errata/RHSA-2020:3218) was 
kernel-4.18.0-193.14.3.el8_2, which is why that's the version in git 
(pushed from Red Hat's internal RelEng systems).  -193.14.2.el8_2 
appears to be something unique to CentOS.  Looking at the changelog of 
the CentOS package vs the RHEL one, this changelog entry is missing:

* Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> 
[4.18.0-193.14.3.el8_2]
- Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 
1837434] {CVE-2020-10713}

Something to do with differences between the way RHEL and CentOS do 
Secure Boot signing, perhaps?

-- 
HJ


From plageat at tut.by  Mon Aug  3 12:25:19 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 15:25:19 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module (RHEA-2020:3054)
Message-ID: <810531596457104@mail.yandex.ru>

Hi all,

Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
Is it planned to be skipped entirely?





From Antal.Nemes at hycu.com  Mon Aug  3 13:40:02 2020
From: Antal.Nemes at hycu.com (=?utf-8?B?QW50YWwgTmVtZcWh?=)
Date: Mon, 3 Aug 2020 15:40:02 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <7de6f26f8560a782d45ba4895e749ab6@mail.merlinthp.org>
Message-ID: <c1ff9a780bc64ce6b9a936ca2377d346@CORE-EXCH.comtrade.com>


> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Howard
> Johnson
> Sent: Monday, 3 August 2020 14:02
> To: The CentOS developers mailing list. <centos-devel at centos.org>
> Subject: Re: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
> 
> CAUTION: Origin is external! The content might not be safe!
> 
> 
> On 2020-08-03 11:37, Antal Neme? wrote:
> > Hi all,
> >
> > I need sources for latest Centos 8.2 kernel
> > (kernel-4.18.0-193.14.2.el8_2).
> >
> > Since they are (now customarily) not available on vault.centos.org, I
> > am attempting to build from git.centos.org.
> >
> > However, I am unable to find the exact commit to build from.
> >
> > On https://git.centos.org/rpms/kernel/commits/c8, I see 13.2 and 14.3,
> > but not 14.2 that actually shipped.
> >
> > $git log --format="%C(auto) %h %s" origin/c8 | head -n 20
> >
> > 08e2843 debrand kernel-4.18.0-193.14.3.el8_2
> >
> > 284ac7b import kernel-4.18.0-193.14.3.el8_2
> 
> Looking at upstream, Red Hat never released kernel-4.18.0-193.14.2.el8_2 into
> the wild.  The RHEL update
> (https://access.redhat.com/errata/RHSA-2020:3218) was kernel-4.18.0-
> 193.14.3.el8_2, which is why that's the version in git (pushed from Red Hat's
> internal RelEng systems).  -193.14.2.el8_2 appears to be something unique to
> CentOS.  Looking at the changelog of the CentOS package vs the RHEL one, this
> changelog entry is missing:
> 
> * Mon Jul 20 2020 Bruno Meneguele <bmeneg at redhat.com> [4.18.0-
> 193.14.3.el8_2]
> - Reverse keys order for dual-signing (Frantisek Hrbata) [1837433 1837434]
> {CVE-2020-10713}
> 
> Something to do with differences between the way RHEL and CentOS do Secure
> Boot signing, perhaps?
> 

Thanks. I guess that makes sense. But I still have no idea how to obtain the 
sources to build. I would backtrack to a previous one (193.13.2), but that one is 
missing kernel-modules-extra rpm package, even though koji[1] shows it was built.
This is the first time I saw an actual binary rpm missing, which is worrying.

So I have backtrack two levels, to 193.6.3.

Any idea when we can expect release of 193.14.3?

[1] https://koji.mbox.centos.org/koji/buildinfo?buildID=12631

Regards,
Antal


From trevor.hemsley at ntlworld.com  Mon Aug  3 13:50:58 2020
From: trevor.hemsley at ntlworld.com (Trevor Hemsley)
Date: Mon, 3 Aug 2020 14:50:58 +0100
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
Message-ID: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>

On 03/08/2020 11:37, Antal Neme? wrote:
> I need sources for latest Centos 8.2 kernel
> (kernel-4.18.0-193.14.2.el8_2).

I believe 14.3 is exactly the same as 14.2 except that RH needed to
adjust the signing order of their certificates and since those are RH
specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.

Trevor


From bstinson at centosproject.org  Mon Aug  3 14:13:43 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:13:43 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
Message-ID: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>


On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> On 03/08/2020 11:37, Antal Neme? wrote:
>> I need sources for latest Centos 8.2 kernel
>> (kernel-4.18.0-193.14.2.el8_2).
> I believe 14.3 is exactly the same as 14.2 except that RH needed to
> adjust the signing order of their certificates and since those are RH
> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>
> Trevor
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

This is the correct answer. The difference between 14.2 and 14.3 is only
applicable to RHEL, and is not a change in the underlying content. The
CentOS kernels were dual-signed in the right order for us in 14.2


--Brian




From johnny at centos.org  Mon Aug  3 14:17:48 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:17:48 -0500
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <810531596457104@mail.yandex.ru>
References: <810531596457104@mail.yandex.ru>
Message-ID: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>

On 8/3/20 7:25 AM, plageat at tut.by wrote:
> Hi all,
> 
> Is there any chance to see start building of new el8.2 eclipse:rhel8 modular packages?
> Is it planned to be skipped entirely?
> 

I am actually looking at that right now.

We will build it .. i may need to bootstrap it as it is the initial
release for CentOS-8 .. so i have no diea how long it will take at this
point.  But it is on my list :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/3d14704e/attachment-0006.sig>

From johnny at centos.org  Mon Aug  3 14:19:05 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 09:19:05 -0500
Subject: [CentOS-devel] recent updates cause grub not to load please
 advise
In-Reply-To: <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
Message-ID: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>

On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> <mailto:lowen at pari.edu>> wrote:
> 
>     On 7/30/20 10:51 AM, Lamar Owen wrote:
>     > On 7/30/20 10:35 AM, Lamar Owen wrote:
>     >> However, what is really odd to me is that after the dnf downgrade of
>     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
>     >> issuing a dnf update I don't see the grub2 and shim updates listed
>     >> anymore.
>     >
>     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
>     > does now list the updated release.? When I get enough time to
>     > reproduce I might try the update again.
>     So, the first update this morning was with the GUI updater that does
>     the
>     update during a reboot.? I just updated to the '87 release of grub2
>     using dnf from the command line, and the update was successful, with a
>     correctly booting system.? So I can't reproduce the issue on this
>     laptop.
> 
> 
> Red Hat fixes are available.
> 
> https://access.redhat.com/errata/RHBA-2020:3265
> https://access.redhat.com/errata/RHBA-2020:3262
> 
> wait for CentOS.

These were released over the weekend.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/61bda161/attachment-0006.sig>

From plageat at tut.by  Mon Aug  3 14:35:00 2020
From: plageat at tut.by (plageat at tut.by)
Date: Mon, 03 Aug 2020 17:35:00 +0300
Subject: [CentOS-devel] Building new eclipse:rhel8 module
	(RHEA-2020:3054)
In-Reply-To: <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
References: <810531596457104@mail.yandex.ru>
 <71658c75-bf0c-f623-0c07-be30c46b294b@centos.org>
Message-ID: <196851596464454@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/7c9f083e/attachment-0006.html>

From amyagi at gmail.com  Mon Aug  3 14:38:44 2020
From: amyagi at gmail.com (Akemi Yagi)
Date: Mon, 3 Aug 2020 07:38:44 -0700
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <CABA31DpT0tAROof38jQW_V8o9+rkUSMLXY_+hNdJef2UFDi3SA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:13 AM Brian Stinson <bstinson at centosproject.org>
wrote:

>
> On 8/3/20 8:50 AM, Trevor Hemsley via CentOS-devel wrote:
> > On 03/08/2020 11:37, Antal Neme? wrote:
> >> I need sources for latest Centos 8.2 kernel
> >> (kernel-4.18.0-193.14.2.el8_2).
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> > _______________________________________________
> > CentOS-devel mailing list
> > CentOS-devel at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
>
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The
> CentOS kernels were dual-signed in the right order for us in 14.2
>
>
> --Brian
>

In any event, releasing the srpm to vault will be the right answer to the
original post.

Akemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/1492a428/attachment-0006.html>

From Antal.Nemes at hycu.com  Mon Aug  3 14:43:49 2020
From: Antal.Nemes at hycu.com (=?iso-8859-2?Q?Antal=20Neme=B9?=)
Date: Mon, 3 Aug 2020 16:43:49 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
Message-ID: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>

> -----Original Message-----
> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
> Stinson
> Sent: Monday, 3 August 2020 16:14
> > I believe 14.3 is exactly the same as 14.2 except that RH needed to
> > adjust the signing order of their certificates and since those are RH
> > specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
> >
> > Trevor
> 
> This is the correct answer. The difference between 14.2 and 14.3 is only
> applicable to RHEL, and is not a change in the underlying content. The CentOS
> kernels were dual-signed in the right order for us in 14.2
> 
> 
> --Brian

Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?

Regards,
Antal


From bstinson at centosproject.org  Mon Aug  3 14:47:39 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Mon, 3 Aug 2020 09:47:39 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <4b19e5d3-5fdd-f37f-3c69-1ad49a969dc0@centosproject.org>


On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>
> Regards,
> Antal
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


These are very exceptional circumstances, but we're looking into how to
make our processes go easier for future coordinated fixes.

--Brian



From johnny at centos.org  Mon Aug  3 15:19:20 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:19:20 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
Message-ID: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>

On 8/3/20 9:43 AM, Antal Neme? wrote:
>> -----Original Message-----
>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>> Stinson
>> Sent: Monday, 3 August 2020 16:14
>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>> adjust the signing order of their certificates and since those are RH
>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>
>>> Trevor
>>
>> This is the correct answer. The difference between 14.2 and 14.3 is only
>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>> kernels were dual-signed in the right order for us in 14.2
>>
>>
>> --Brian
> 
> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
> 

Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
that requires a signature from Microsoft before release AND requires
hiding embargoed content (which CentOS is not set up to do ..we build
everythign in the open) .. is VERY MUCH an exceptional occurrence.

Then throw in the fact the both RHEL and CentOS installs could no longer
BOOT .. I think you are it the most unbelievable and most complicated
build we have ever done in as the CentOS Project.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/128708f2/attachment-0006.sig>

From johnny at centos.org  Mon Aug  3 15:23:12 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:23:12 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <ad4e299f-e02c-661c-93e8-c014ef137390@centos.org>

On 8/3/20 10:19 AM, Johnny Hughes wrote:
> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is only
>>> applicable to RHEL, and is not a change in the underlying content. The CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in my attempts 
>> at automating src.rpm generation from git.centos.org, so I hope this was an exceptional occurrence?
>>
> 
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Then throw in the fact the both RHEL and CentOS installs could no longer
> BOOT .. I think you are it the most unbelievable and most complicated
> build we have ever done in as the CentOS Project.

NOTE:  I have built, signed,  and released about 90% of ALL content for
CentOS Linux since 2004 // this is by far the most complicated thing I
have ever built.

Brian Stinson is a genius :)  So is Peter Jones.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/124ac650/attachment-0006.sig>

From simon.matter at invoca.ch  Mon Aug  3 15:34:05 2020
From: simon.matter at invoca.ch (Simon Matter)
Date: Mon, 3 Aug 2020 17:34:05 +0200
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
Message-ID: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>

> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>> -----Original Message-----
>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>> Stinson
>>> Sent: Monday, 3 August 2020 16:14
>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>> adjust the signing order of their certificates and since those are RH
>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>> builds.
>>>>
>>>> Trevor
>>>
>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>> only
>>> applicable to RHEL, and is not a change in the underlying content. The
>>> CentOS
>>> kernels were dual-signed in the right order for us in 14.2
>>>
>>>
>>> --Brian
>>
>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>> my attempts
>> at automating src.rpm generation from git.centos.org, so I hope this was
>> an exceptional occurrence?
>>
>
> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
> that requires a signature from Microsoft before release AND requires
> hiding embargoed content (which CentOS is not set up to do ..we build
> everythign in the open) .. is VERY MUCH an exceptional occurrence.

Some filtering rules in my brain just triggered an alarm here, too many
words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
a GNU/Linux devel list :-)

Simon



From johnny at centos.org  Mon Aug  3 15:38:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:38:34 -0500
Subject: [CentOS-devel] kernel-4.18.0-193.14.2.el8_2 in git.centos.org
In-Reply-To: <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
References: <56cb0733602b42808e9551f79b855cb8@CORE-EXCH.comtrade.com>
 <535a4f7f-1859-e454-63ce-9c61034f3e46@ntlworld.com>
 <77f8ccdb-e29f-6f25-8fcd-12aed52b11d4@centosproject.org>
 <bd14118f8f2b4044b45abf1fc5bc5bb6@CORE-EXCH.comtrade.com>
 <0ffe6b74-3fe5-cc95-1756-ba14b2f72b83@centos.org>
 <dfc241683104c3c9df8ac35d7e61ef73.squirrel@xxl.corp.invoca.ch>
Message-ID: <c6f76dea-8898-384f-a776-e9bfdb4c4fba@centos.org>

On 8/3/20 10:34 AM, Simon Matter via CentOS-devel wrote:
>> On 8/3/20 9:43 AM, Antal Neme? wrote:
>>>> -----Original Message-----
>>>> From: CentOS-devel <centos-devel-bounces at centos.org> On Behalf Of Brian
>>>> Stinson
>>>> Sent: Monday, 3 August 2020 16:14
>>>>> I believe 14.3 is exactly the same as 14.2 except that RH needed to
>>>>> adjust the signing order of their certificates and since those are RH
>>>>> specific, 14.2 == 14.3 for the intents and purposes of non-RHEL
>>>>> builds.
>>>>>
>>>>> Trevor
>>>>
>>>> This is the correct answer. The difference between 14.2 and 14.3 is
>>>> only
>>>> applicable to RHEL, and is not a change in the underlying content. The
>>>> CentOS
>>>> kernels were dual-signed in the right order for us in 14.2
>>>>
>>>>
>>>> --Brian
>>>
>>> Great, thanks for confirmation. This throws a gigantic monkey wrench in
>>> my attempts
>>> at automating src.rpm generation from git.centos.org, so I hope this was
>>> an exceptional occurrence?
>>>
>>
>> Yes .. one could say that an embargoed, 'named' sescureboot/kernel fix
>> that requires a signature from Microsoft before release AND requires
>> hiding embargoed content (which CentOS is not set up to do ..we build
>> everythign in the open) .. is VERY MUCH an exceptional occurrence.
> 
> Some filtering rules in my brain just triggered an alarm here, too many
> words like 'embargoed content', 'secureboot', 'hiding', 'Microsoft'... on
> a GNU/Linux devel list :-)

You and me both .. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/02b952fb/attachment-0006.sig>

From johnny at centos.org  Mon Aug  3 15:41:01 2020
From: johnny at centos.org (Johnny Hughes)
Date: Mon, 3 Aug 2020 10:41:01 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
Message-ID: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>

On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-1073) and
>> are working on releasing new packages for CentOS Linux 7, CentOS Linux 8
>> and CentOS Stream in response. These should make it out to a mirror near
>> you shortly.
>>
> 
> Should be ?
> CVE-2020-10713
> and
> CVE-2020-14308
> CVE-2020-14309
> CVE-2020-14310
> CVE-2020-14311
> 

We have no ability to match up CVE numbers and CentOS-8 releases .. as
modules use git commit IDs and build time stamps in the rpm names.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200803/e71191b9/attachment-0006.sig>

From lee.iitb at gmail.com  Mon Aug  3 19:29:35 2020
From: lee.iitb at gmail.com (Thomas Stephen Lee)
Date: Tue, 4 Aug 2020 00:59:35 +0530
Subject: [CentOS-devel] recent updates cause grub not to load please
	advise
In-Reply-To: <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
References: <CAOp5WB5k9Heo8madm6Z5LJ0Fg_kDSHbR=3fqnTfJx2-ufY37PA@mail.gmail.com>
 <e5d2340c-07dc-5222-eb30-efef2530c356@pari.edu>
 <51a377df-287c-9781-efb8-c597d0b614d4@pari.edu>
 <ee952bcc-9e24-b9da-833c-367736492b57@pari.edu>
 <CAG7s96W7mQ7_cfNM_nEy9D-2AhGKNbUv0fvHOfDX2gMPhntu_w@mail.gmail.com>
 <7185a5ad-ddc7-c30a-3a96-73a6320a7c1c@centos.org>
Message-ID: <CAG7s96Wd-qe2_XT2hqBjORm-imzbTdu3hKLQaoNFYjyBAHLjsA@mail.gmail.com>

On Mon, Aug 3, 2020 at 7:49 PM Johnny Hughes <johnny at centos.org> wrote:

> On 8/1/20 1:13 PM, Thomas Stephen Lee wrote:
> > On Thu, Jul 30, 2020 at 9:34 PM Lamar Owen <lowen at pari.edu
> > <mailto:lowen at pari.edu>> wrote:
> >
> >     On 7/30/20 10:51 AM, Lamar Owen wrote:
> >     > On 7/30/20 10:35 AM, Lamar Owen wrote:
> >     >> However, what is really odd to me is that after the dnf downgrade
> of
> >     >> grub2 and shim, which did get logged in /var/log/dnf.log, when
> >     >> issuing a dnf update I don't see the grub2 and shim updates listed
> >     >> anymore.
> >     >
> >     > So I'm on the latest kernel, but downrev on grub2 and a dnf update
> >     > does now list the updated release.  When I get enough time to
> >     > reproduce I might try the update again.
> >     So, the first update this morning was with the GUI updater that does
> >     the
> >     update during a reboot.  I just updated to the '87 release of grub2
> >     using dnf from the command line, and the update was successful, with
> a
> >     correctly booting system.  So I can't reproduce the issue on this
> >     laptop.
> >
> >
> > Red Hat fixes are available.
> >
> > https://access.redhat.com/errata/RHBA-2020:3265
> > https://access.redhat.com/errata/RHBA-2020:3262
> >
> > wait for CentOS.
>
> These were released over the weekend.
>
Got it. thanks ?

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200804/2356d314/attachment-0006.html>

From arrfab at centos.org  Wed Aug  5 11:41:12 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:41:12 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
Message-ID: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>

Due to a hardware issue, we'll have to move the existing NFS share used
by cbs.centos.org to a new node.

Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
You can convert to local time with $(date -d '2020-08-05 6:30 UTC')

The expected "downtime" is estimated to ~30 minutes , time needed to
stop services, reflect change for NFS storage, update dns A record , and
ansible restarting the whole process.

During that downtime, nothing will be processed on the koji builders
(nor signed and pushed out to mirror CDN)

Thanks for your comprehending and patience.

on behalf of the Infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/65be92c8/attachment-0006.sig>

From arrfab at centos.org  Wed Aug  5 11:50:48 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:50:48 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <d683b260-bc5e-a467-efb8-3a5d0f805399@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 

Correction (that's what happens when you look at your gnome clock and
coming back from PTO) : it's scheduled for tomorrow, so """"Thursday
August 6th, 6:30 am UTC time"""". ..

Thanks to Thomas for the notification :)


-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/e5c33a51/attachment-0006.sig>

From arrfab at centos.org  Wed Aug  5 11:59:35 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Wed, 5 Aug 2020 13:59:35 +0200
Subject: [CentOS-devel] New CentOS Infra/CBS/CI issues/requests tracker,
	please read !
Message-ID: <a5d2d42a-33ce-4b15-383a-78c6015f062b@centos.org>

Hi all,

As you probably noticed in the last weeks/months, we have a stronger
collaboration and synergy with the Fedora infrastructure team. Combining
forces and resources help both projects at the same time, as majority of
the CentOS contributors are already Fedora contributors and probably the
same in reverse.

It's not a secret (it was announced through CPE weekly mails on this
list) that the CentOS board approved the idea of merging authentication
systems in a near future (as an example).

This email to let you know that all RFE/issues concerning the following
areas should be reported to a new issues tracker :
https://pagure.io/centos-infra/issues/ , to adapt the same workflow as
the Fedora infra team is already using. ( see
https://docs.fedoraproject.org/en-US/cpe/working_with_us/ )

Concerned areas :
 - https://cbs.centos.org (Community BuildSystem, aka koji)
 - Special Interest Groups requests (for mirror, resources, etc)
 - https://ci.centos.org (All CI infra ecosystem)
 - Everything around CentOS Infra (mirror issues, etc)

We have already moved/migrated for example the (opened) tickets that
were filed under the "Buildsys" , "CI" and "Infrastructure" categories
to the new issues tracker. The idea being to *not* request work to be
done through IRC but rather through new infra issues tracker.

Imported tickets will be discussed there and worked on (reviewed on a
daily basis) after having been prioritized

Should you feel a need to discuss this new process, feel free to do so
in #centos-devel on irc.freenode.net or on this centos-devel list.

Kind Regards,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200805/2e3db1b6/attachment-0006.sig>

From arrfab at centos.org  Thu Aug  6 06:47:00 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 6 Aug 2020 08:47:00 +0200
Subject: [CentOS-devel] [Infra] - Planned outage : cbs.centos.org
In-Reply-To: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
References: <60b035ae-4cd2-3001-7a17-f4aaab97d91c@centos.org>
Message-ID: <5dc2c9b1-939e-2d38-051b-57c2a53c94e5@centos.org>

On 05/08/2020 13:41, Fabian Arrotin wrote:
> Due to a hardware issue, we'll have to move the existing NFS share used
> by cbs.centos.org to a new node.
> 
> Migration is scheduled for """"Thursday August 5th, 6:30 am UTC time"""".
> You can convert to local time with $(date -d '2020-08-05 6:30 UTC')
> 
> The expected "downtime" is estimated to ~30 minutes , time needed to
> stop services, reflect change for NFS storage, update dns A record , and
> ansible restarting the whole process.
> 
> During that downtime, nothing will be processed on the koji builders
> (nor signed and pushed out to mirror CDN)
> 
> Thanks for your comprehending and patience.
> 
> on behalf of the Infra team,
> 

Just to inform you that storage migration is done and all services back
in action.

-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/15cb001a/attachment-0006.sig>

From stefan.puiu at gmail.com  Thu Aug  6 16:58:22 2020
From: stefan.puiu at gmail.com (Stefan Puiu)
Date: Thu, 6 Aug 2020 19:58:22 +0300
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
Message-ID: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>

Hi,

We have a CentOS 7 -based (more accurately, CentOS 7 atomic
host-based) distro that we build and run on specialized hardware. For
the kernel, we pick the CentOS 7 kernel, apply two patches (and a
different configuration) and build it. We're mostly following CentOS
7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.

A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
it's labeled as a security update -
https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
so I decided to build it. Our kernel build process involves
downloading the src.rpm, patching the spec and then calling rpmbuild.
For this latest kernel, our spec patch (which adds our 2 patches)
failed to apply - as far as I can tell, the hunks where patches are
listed, like this one:

==
@@ -449,6 +449,8 @@
 Patch1000: debrand-single-cpu.patch
 Patch1001: debrand-rh_taint.patch
 Patch1002: debrand-rh-i686-cpu.patch
+Patch88881: kernel_ixia.patch
+Patch88882: at24.patch

 BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
 ==

I checked the new spec file, and the debrand patches are missing.
Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
if that's the right place), I see there's a debranding change
(https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
but it simply added a README saying debranding failed.

Do I need to wait for a new change fixing this? I see older kernels
have a "debranding" commit and then a "Manual CentOS Debranding"
commit, is something like that required now as well?

Thanks in advance,
Stefan.


From ancarrol at redhat.com  Thu Aug  6 17:23:48 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Thu, 6 Aug 2020 18:23:48 +0100
Subject: [CentOS-devel] CPE Feedback Survey
Message-ID: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>

Hey folks,

CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)

Over the last several months we've been trying to improve how we interact
and share information with you all. From the blog posts, to mails and how
we work on the tickets you send us.

Here is a link to a very short survey we've put together to learn how we
can give you the best experience possible going forward by understanding
the experiences you've had recently.
If you could take the time (5mins max) to complete it for us it would be
hugely valuable as we work on this continuous improvement -
https://fedoraproject.limequery.com/696793?lang=en
<https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>


Cheers,

Ant
-- 

Ant Carroll

Associate Manager, CPE Team

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/78930267/attachment-0006.html>

From kdreyer at redhat.com  Thu Aug  6 20:51:02 2020
From: kdreyer at redhat.com (Ken Dreyer)
Date: Thu, 6 Aug 2020 14:51:02 -0600
Subject: [CentOS-devel] installing cbs client on Fedora
In-Reply-To: <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
References: <CALqRxCy9L0EwZMLbpO0EyY04OKeRAmZJmUEhJ-ECCmH4Q43pwg@mail.gmail.com>
 <83312E1C-CD06-48EA-BC1B-C618AC8DBCDD@negate.org>
 <5f7914d8-1d45-4ee0-b666-a16f1f718dee@www.fastmail.com>
Message-ID: <CALqRxCz1aBTMo95WNt5YKsyVJQ_C9Ja0TTb40KG1BSGgrNzTmA@mail.gmail.com>

On Wed, Jun 3, 2020 at 8:25 PM Brian Stinson <brian at bstinson.com> wrote:
> We definitely need some work here, but a good first step is to get this out of personal accounts on github.
>
> If you don't mind forking this, we can start: https://git.centos.org/centos/centos-packager

Would you please merge
https://github.com/bstinsonmhk/centos-packager/pull/6 so everyone can
follow along with this move?

- Ken



From johnny at centos.org  Thu Aug  6 22:41:34 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 6 Aug 2020 17:41:34 -0500
Subject: [CentOS-devel] centos 7.8 and kernel-3.10.0-1127.18.2.el7
In-Reply-To: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
References: <CACKs7VDYqreLpJ1AveYQsbenvVMQpAxeA8hrApvepqCmW65jbQ@mail.gmail.com>
Message-ID: <aab8b287-cd90-c5ac-2269-fda94676ab26@centos.org>

On 8/6/20 11:58 AM, Stefan Puiu wrote:
> Hi,
> 
> We have a CentOS 7 -based (more accurately, CentOS 7 atomic
> host-based) distro that we build and run on specialized hardware. For
> the kernel, we pick the CentOS 7 kernel, apply two patches (and a
> different configuration) and build it. We're mostly following CentOS
> 7.8 at the moment, and using the 3.10.0-1127.13.1 kernel.
> 
> A few days ago, I noticed kernel-3.10.0-1127.18.2.el7 was out (and
> it's labeled as a security update -
> https://lists.centos.org/pipermail/centos-announce/2020-July/035780.html),
> so I decided to build it. Our kernel build process involves
> downloading the src.rpm, patching the spec and then calling rpmbuild.
> For this latest kernel, our spec patch (which adds our 2 patches)
> failed to apply - as far as I can tell, the hunks where patches are
> listed, like this one:
> 
> ==
> @@ -449,6 +449,8 @@
>  Patch1000: debrand-single-cpu.patch
>  Patch1001: debrand-rh_taint.patch
>  Patch1002: debrand-rh-i686-cpu.patch
> +Patch88881: kernel_ixia.patch
> +Patch88882: at24.patch
> 
>  BuildRoot: %{_tmppath}/kernel-%{KVRA}-root
>  ==
> 
> I checked the new spec file, and the debrand patches are missing.
> Looking at https://git.centos.org/rpms/kernel/commits/c7 (let me know
> if that's the right place), I see there's a debranding change
> (https://git.centos.org/rpms/kernel/c/548139faa91edfe29fc84695da827230de3c5d4f?branch=c7),
> but it simply added a README saying debranding failed.
> 
> Do I need to wait for a new change fixing this? I see older kernels
> have a "debranding" commit and then a "Manual CentOS Debranding"
> commit, is something like that required now as well?
> 
> Thanks in advance,
> Stefan.
> _______________________________________________
> 

We will better debrand the next kernel .. we were eliminating items to
get better builds from the shim / kernel error issues over the weekend
and did not get the debranding completely in that kernel, but it worked,
so we released it.

The next kernel will be more normal and with less urgency .. it should
have all the patches.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200806/75c42fa7/attachment-0006.sig>

From listmail at crazylinuxnerd.net  Sat Aug  8 06:36:04 2020
From: listmail at crazylinuxnerd.net (Jake Shipton)
Date: Sat, 08 Aug 2020 07:36:04 +0100
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
Message-ID: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>

2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
> > Am 29.07.20 um 19:38 schrieb Brian Stinson:
> > > We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
> > > 1073) and
> > > are working on releasing new packages for CentOS Linux 7, CentOS
> > > Linux 8
> > > and CentOS Stream in response. These should make it out to a
> > > mirror near
> > > you shortly.
> > > 
> > 
> > Should be ?
> > CVE-2020-10713
> > and
> > CVE-2020-14308
> > CVE-2020-14309
> > CVE-2020-14310
> > CVE-2020-14311
> > 
> 
> We have no ability to match up CVE numbers and CentOS-8 releases ..
> as
> modules use git commit IDs and build time stamps in the rpm names.
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel

Hi,

That's understandable. But on a separate note, is there any chance of
CentOS Announce receiving update information for CentOS 8?

Currently, 6 and 7 are receiving them. However, for several months now
CentOS 8 hasn't had any update emails on that list with the exception
of minor releases or this issue.

Just wondering, because I use that list to keep up with updates :-).

Kind Regards and Stay Safe

Jake Shipton (JakeMS)



From johnny at centos.org  Sun Aug  9 08:59:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Sun, 9 Aug 2020 03:59:06 -0500
Subject: [CentOS-devel] [CentOS-announce] CentOS Linux,
 CentOS Stream and the Boot Hole vulnerability
In-Reply-To: <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
References: <0f0d3ad8-7160-73b7-82d2-6d8ff51ef5f1@centosproject.org>
 <7aea826e-ea73-8b1f-81f5-3ed214d909ab@gmail.com>
 <8f93c1fd-4c70-9473-00f8-9cec50119289@centos.org>
 <193a5a423d316798f99dfa65c08dcef783b51535.camel@crazylinuxnerd.net>
Message-ID: <7caa9be4-1689-8a22-6c72-100688c5862a@centos.org>

On 8/8/20 1:36 AM, Jake Shipton wrote:
> 2020-08-03 (?) ? 10:41 -0500 ? Johnny Hughes ????????:
>> On 7/29/20 1:35 PM, Leon Fauster via CentOS-devel wrote:
>>> Am 29.07.20 um 19:38 schrieb Brian Stinson:
>>>> We are aware of the Boot Hole vulnerability in grub2 (CVE-2020-
>>>> 1073) and
>>>> are working on releasing new packages for CentOS Linux 7, CentOS
>>>> Linux 8
>>>> and CentOS Stream in response. These should make it out to a
>>>> mirror near
>>>> you shortly.
>>>>
>>>
>>> Should be ?
>>> CVE-2020-10713
>>> and
>>> CVE-2020-14308
>>> CVE-2020-14309
>>> CVE-2020-14310
>>> CVE-2020-14311
>>>
>>
>> We have no ability to match up CVE numbers and CentOS-8 releases ..
>> as
>> modules use git commit IDs and build time stamps in the rpm names.
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
> 
> Hi,
> 
> That's understandable. But on a separate note, is there any chance of
> CentOS Announce receiving update information for CentOS 8?
> 
> Currently, 6 and 7 are receiving them. However, for several months now
> CentOS 8 hasn't had any update emails on that list with the exception
> of minor releases or this issue.
> 
> Just wondering, because I use that list to keep up with updates :-).
> 
> Kind Regards and Stay Safe
> 
> Jake Shipton (JakeMS)
> 

What we have right now is two fold:

This:
https://feeds.centos.org/

And looking at what is built for dist-c8-compose (what will be in the
latest compose):
https://koji.mbox.centos.org/koji/builds?tagID=338


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200809/e994bcc6/attachment-0006.sig>

From arrfab at centos.org  Mon Aug 10 12:37:08 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Mon, 10 Aug 2020 14:37:08 +0200
Subject: [CentOS-devel] CBS : builders migration (already done,
	nothing to worry about)
Message-ID: <8ab55786-93d7-0e7b-ddcd-449a18f0b514@centos.org>

Hi,

On my backlog for quite some time, there was need to migrate existing
CBS/koji builders to new(er) hardware/hosts.
When I moved items from backlog to the new place, I so imported this one
: https://pagure.io/centos-infra/issue/52

This mail is just a "FYI" as nobody should have noticed any service
disruption, as each kojid instance was migrated while no job was
running, so disabled, migrated, enabled back in the pool and so on.

Hopefully you still *should* notice some speed improvements, including
for build jobs (newer/faster nodes) and surely because local storage for
these builders is SSD backed (instead of old SAS disks on 8y+ nodes).

Same rule applies for the distrepo tasks, as we now have multiple nodes
in the "createrepo" channel, with access to the koji NFS share now over
10Gbit ethernet (while it' was limited to 1Gbit on older nodes). That
was possible because of the previous storage migration that happened
last week :
https://lists.centos.org/pipermail/centos-devel/2020-August/055981.html

Should you encounter any issue, (but we're ran several --scratch builds)
, feel free to reply to this email, drop on #centos-devel irc channel on
irc.freenode.net, or even better now (really!), create a ticket on
https://pagure.io/centos-infra/issues.

Happy building !
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200810/b9e149bc/attachment-0006.sig>

From orion at nwra.com  Mon Aug 10 20:29:33 2020
From: orion at nwra.com (Orion Poplawski)
Date: Mon, 10 Aug 2020 14:29:33 -0600
Subject: [CentOS-devel] Missing -devel packages
Message-ID: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>

Is there anything I can do to help out with missing -devel packages in CentOS
8?  I'm waiting for a number of them, e.g.:

https://bugs.centos.org/view.php?id=17401

Thanks,
  Orion

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/


From tdawson at redhat.com  Mon Aug 10 20:41:04 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Mon, 10 Aug 2020 13:41:04 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
Message-ID: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>

On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>
> Is there anything I can do to help out with missing -devel packages in CentOS
> 8?  I'm waiting for a number of them, e.g.:
>
> https://bugs.centos.org/view.php?id=17401
>
Hi Orion,
It helps if it is linked to this ticket.
https://bugs.centos.org/view.php?id=16492
Although nothing has happened there for 5 months.

To be clear, there is two definitions of "missing -devel packages"

There are the ones that have never shown up anywhere  (I'm still
waiting on 4 I believe)

And then there are the ones that originally showed up, and we were
able to build from them in EPEL8, but then when RHEL 8.2 came along,
the EPEL8 packages are still the old ones from RHEL 8.1.
https://pagure.io/releng/issue/9580

Troy



From johnny at centos.org  Tue Aug 11 14:38:33 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 11 Aug 2020 09:38:33 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
Message-ID: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>

On 8/10/20 3:41 PM, Troy Dawson wrote:
> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>
>> Is there anything I can do to help out with missing -devel packages in CentOS
>> 8?  I'm waiting for a number of them, e.g.:
>>
>> https://bugs.centos.org/view.php?id=17401
>>
> Hi Orion,
> It helps if it is linked to this ticket.
> https://bugs.centos.org/view.php?id=16492
> Although nothing has happened there for 5 months.
> 
> To be clear, there is two definitions of "missing -devel packages"
> 
> There are the ones that have never shown up anywhere  (I'm still
> waiting on 4 I believe)
> 
> And then there are the ones that originally showed up, and we were
> able to build from them in EPEL8, but then when RHEL 8.2 came along,
> the EPEL8 packages are still the old ones from RHEL 8.1.
> https://pagure.io/releng/issue/9580

And while we would love to just publish these .. we can not.

There are competing goals here.  Bit for bit like RHEL .. RHEL does not
have the SRPMS, we should not.

Someone wants the SRPMS .. so they want us to like RHEL .. except when
they don't.  All our build system and where we pull info assumes we need
to be the same.  Introducing things were we are not is HARD ..
especially in el8 as we HAVE to use koji and mbox and pungi to build.
Introducing differences into compose configurations for pungi for
releases is HARD .. it has follow on impacts .. and we need a system in
place to make it continue to work when we get updated compose files in
the future.

We have people working on this, but it is just not a priority compared
to getting things released on time and builds working properly.  It is
not just a simple .. push a couple packages somewhere.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/e46a5962/attachment-0006.sig>

From tdawson at redhat.com  Tue Aug 11 14:57:23 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 07:57:23 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>
> On 8/10/20 3:41 PM, Troy Dawson wrote:
> > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> >>
> >> Is there anything I can do to help out with missing -devel packages in CentOS
> >> 8?  I'm waiting for a number of them, e.g.:
> >>
> >> https://bugs.centos.org/view.php?id=17401
> >>
> > Hi Orion,
> > It helps if it is linked to this ticket.
> > https://bugs.centos.org/view.php?id=16492
> > Although nothing has happened there for 5 months.
> >
> > To be clear, there is two definitions of "missing -devel packages"
> >
> > There are the ones that have never shown up anywhere  (I'm still
> > waiting on 4 I believe)
> >
> > And then there are the ones that originally showed up, and we were
> > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > the EPEL8 packages are still the old ones from RHEL 8.1.
> > https://pagure.io/releng/issue/9580
>
> And while we would love to just publish these .. we can not.
>
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
>
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
>
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.
>

You already have them published, that work is done.
http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/

It doesn't say it in the ticket, but from conversations the rsync area
that was setup for EPEL8 to sync that over, something happened and
they can't sync anymore.
I don't know the details.  It's possible that the syncing is already
fixed, and they just need to restart and/or update their script.

Troy



From tdawson at redhat.com  Tue Aug 11 17:10:38 2020
From: tdawson at redhat.com (Troy Dawson)
Date: Tue, 11 Aug 2020 10:10:38 -0700
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
Message-ID: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>

On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>
> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
> >
> > On 8/10/20 3:41 PM, Troy Dawson wrote:
> > > On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
> > >>
> > >> Is there anything I can do to help out with missing -devel packages in CentOS
> > >> 8?  I'm waiting for a number of them, e.g.:
> > >>
> > >> https://bugs.centos.org/view.php?id=17401
> > >>
> > > Hi Orion,
> > > It helps if it is linked to this ticket.
> > > https://bugs.centos.org/view.php?id=16492
> > > Although nothing has happened there for 5 months.
> > >
> > > To be clear, there is two definitions of "missing -devel packages"
> > >
> > > There are the ones that have never shown up anywhere  (I'm still
> > > waiting on 4 I believe)
> > >
> > > And then there are the ones that originally showed up, and we were
> > > able to build from them in EPEL8, but then when RHEL 8.2 came along,
> > > the EPEL8 packages are still the old ones from RHEL 8.1.
> > > https://pagure.io/releng/issue/9580
> >
> > And while we would love to just publish these .. we can not.
> >
> > There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> > have the SRPMS, we should not.
> >
> > Someone wants the SRPMS .. so they want us to like RHEL .. except when
> > they don't.  All our build system and where we pull info assumes we need
> > to be the same.  Introducing things were we are not is HARD ..
> > especially in el8 as we HAVE to use koji and mbox and pungi to build.
> > Introducing differences into compose configurations for pungi for
> > releases is HARD .. it has follow on impacts .. and we need a system in
> > place to make it continue to work when we get updated compose files in
> > the future.
> >
> > We have people working on this, but it is just not a priority compared
> > to getting things released on time and builds working properly.  It is
> > not just a simple .. push a couple packages somewhere.
> >
>
> You already have them published, that work is done.
> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>
> It doesn't say it in the ticket, but from conversations the rsync area
> that was setup for EPEL8 to sync that over, something happened and
> they can't sync anymore.
> I don't know the details.  It's possible that the syncing is already
> fixed, and they just need to restart and/or update their script.
>
> Troy

Turns out the syncing was fixed, but the ticket not closed.
Sorry for all the noise.
If I had just tried to rebuild my package again, I would have seen it was fixed.

Troy



From orion at nwra.com  Wed Aug 12 04:21:08 2020
From: orion at nwra.com (Orion Poplawski)
Date: Tue, 11 Aug 2020 22:21:08 -0600
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
Message-ID: <c4803315-89e4-0b1f-d74b-04117d41b3a8@nwra.com>

On 8/11/20 8:38 AM, Johnny Hughes wrote:
> On 8/10/20 3:41 PM, Troy Dawson wrote:
>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>
>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>> 8?  I'm waiting for a number of them, e.g.:
>>>
>>> https://bugs.centos.org/view.php?id=17401
>>>
>> Hi Orion,
>> It helps if it is linked to this ticket.
>> https://bugs.centos.org/view.php?id=16492
>> Although nothing has happened there for 5 months.
>>
>> To be clear, there is two definitions of "missing -devel packages"
>>
>> There are the ones that have never shown up anywhere  (I'm still
>> waiting on 4 I believe)
>>
>> And then there are the ones that originally showed up, and we were
>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>> the EPEL8 packages are still the old ones from RHEL 8.1.
>> https://pagure.io/releng/issue/9580
> 
> And while we would love to just publish these .. we can not.
> 
> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
> have the SRPMS, we should not.
> 
> Someone wants the SRPMS .. so they want us to like RHEL .. except when
> they don't.  All our build system and where we pull info assumes we need
> to be the same.  Introducing things were we are not is HARD ..
> especially in el8 as we HAVE to use koji and mbox and pungi to build.
> Introducing differences into compose configurations for pungi for
> releases is HARD .. it has follow on impacts .. and we need a system in
> place to make it continue to work when we get updated compose files in
> the future.
> 
> We have people working on this, but it is just not a priority compared
> to getting things released on time and builds working properly.  It is
> not just a simple .. push a couple packages somewhere.

I understand that it's not the top priority, and there is work involved. 
  But it did seem like a process was defined so that it wasn't such a 
crazy thing to do.  But maybe it is.

As Troy noted, a number of packages have been published, including 
libuv-devel from the above report.  I'll make some notes in those bug 
reports.  But others are still missing, including for example libtar-devel.

Thanks again for your work, and maybe someday others will be able to 
help you.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       orion at nwra.com
Boulder, CO 80301                 https://www.nwra.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3799 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200811/923ea603/attachment-0006.p7s>

From johnny at centos.org  Wed Aug 12 14:55:54 2020
From: johnny at centos.org (Johnny Hughes)
Date: Wed, 12 Aug 2020 09:55:54 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
Message-ID: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>

On 8/11/20 12:10 PM, Troy Dawson wrote:
> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>
>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>
>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>
>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>
>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>
>>>> Hi Orion,
>>>> It helps if it is linked to this ticket.
>>>> https://bugs.centos.org/view.php?id=16492
>>>> Although nothing has happened there for 5 months.
>>>>
>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>
>>>> There are the ones that have never shown up anywhere  (I'm still
>>>> waiting on 4 I believe)
>>>>
>>>> And then there are the ones that originally showed up, and we were
>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>> https://pagure.io/releng/issue/9580
>>>
>>> And while we would love to just publish these .. we can not.
>>>
>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>> have the SRPMS, we should not.
>>>
>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>> they don't.  All our build system and where we pull info assumes we need
>>> to be the same.  Introducing things were we are not is HARD ..
>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>> Introducing differences into compose configurations for pungi for
>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>> place to make it continue to work when we get updated compose files in
>>> the future.
>>>
>>> We have people working on this, but it is just not a priority compared
>>> to getting things released on time and builds working properly.  It is
>>> not just a simple .. push a couple packages somewhere.
>>>
>>
>> You already have them published, that work is done.
>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>
>> It doesn't say it in the ticket, but from conversations the rsync area
>> that was setup for EPEL8 to sync that over, something happened and
>> they can't sync anymore.
>> I don't know the details.  It's possible that the syncing is already
>> fixed, and they just need to restart and/or update their script.
>>
>> Troy
> 
> Turns out the syncing was fixed, but the ticket not closed.
> Sorry for all the noise.
> If I had just tried to rebuild my package again, I would have seen it was fixed.
> 
> Troy

Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
stay fixed.

But some -devel packages are also not fixed, as there are lots of things
that need to be modified in the automation to keep them fixed.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/13522fd2/attachment-0006.sig>

From yatinkarel at gmail.com  Wed Aug 12 15:53:15 2020
From: yatinkarel at gmail.com (YATIN KAREL)
Date: Wed, 12 Aug 2020 21:23:15 +0530
Subject: [CentOS-devel]  NFV SIG meeting minutes - 2020-08-12
Message-ID: <CANOTru4_t-x1G3XQtXCAe31WjoAkS_GzLOEfvJ4e19pzj=MTeQ@mail.gmail.com>

=============================================
#centos-meeting: NFV SIG meeting - 2020-08-12
=============================================


Meeting started by ykarel at 15:07:53 UTC. The full logs are available
athttps://www.centos.org/minutes/2020/August/centos-meeting.2020-08-12-15.07.log.html
.



Meeting summary
---------------
* roll call  (ykarel, 15:08:23)

* New issue tracking for infra issues  (ykarel, 15:12:43)
  * LINK: https://pagure.io/centos-infra/issues/   (ykarel, 15:12:57)
  * LINK: https://wiki.centos.org/SIGGuide   (ykarel, 15:14:00)

* SIG Membership  (ykarel, 15:14:15)
  * All members requested
    membership(https://bugs.centos.org/view.php?id=17629) have been
    added to sig-nfv  (ykarel, 15:14:31)
  * LINK: https://git.centos.org/group/sig-nfv   (ykarel, 15:14:41)

* Distgit branches  (ykarel, 15:17:54)
  * https://bugs.centos.org/view.php?id=17614 is resolved  (ykarel,
    15:18:42)
  * Pushed a branch(c8-sig-nfv-openvswitch-2.13) for
    openvswitch(imported openvswitch2.13-2.13.0-39), ovn(imported
    ovn2.13-2.13.0-39)  (ykarel, 15:19:21)
  * Built both ovn and openvswitch 2.13 against nfv8-openvswitch-2-el8
    tag https://cbs.centos.org/koji/builds?tagID=2120  (ykarel,
    15:19:42)
  * LINK: https://cbs.centos.org/koji/builds?tagID=2120   (ykarel,
    15:20:17)
  * LINK: https://git.centos.org/rpms/ovn/branches   (ykarel, 15:21:31)
  * Packages available in Testing repo:-
    https://buildlogs.centos.org/centos/8/nfv/x86_64/openvswitch-2/Packages/o/
    (ykarel, 15:24:57)

* tuned profiles  (tfherbert, 15:30:13)

* Any other discussion?  (tfherbert, 15:42:09)

* chair for next meeting  (ykarel, 15:46:23)
  * ACTION: tfherbert to chair next week  (ykarel, 15:47:46)
  * ACTION: correction next meeting not next week.  (tfherbert,
    15:48:26)

Meeting ended at 15:48:34 UTC.




Action Items
------------
* tfherbert to chair next week
* correction next meeting not next week.




Action Items, by person
-----------------------
* tfherbert
  * tfherbert to chair next week
* **UNASSIGNED**
  * correction next meeting not next week.




People Present (lines said)
---------------------------
* ykarel (64)
* tfherbert (31)
* dholler (13)
* centbot (4)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot

_______________________________________________
CentOS-devel mailing list
CentOS-devel at centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200812/a4a18ddf/attachment-0006.html>

From leonfauster at googlemail.com  Wed Aug 12 19:01:55 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Wed, 12 Aug 2020 21:01:55 +0200
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
Message-ID: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>

Am 12.08.20 um 16:55 schrieb Johnny Hughes:
> On 8/11/20 12:10 PM, Troy Dawson wrote:
>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>
>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org> wrote:
>>>>
>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com> wrote:
>>>>>>
>>>>>> Is there anything I can do to help out with missing -devel packages in CentOS
>>>>>> 8?  I'm waiting for a number of them, e.g.:
>>>>>>
>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>
>>>>> Hi Orion,
>>>>> It helps if it is linked to this ticket.
>>>>> https://bugs.centos.org/view.php?id=16492
>>>>> Although nothing has happened there for 5 months.
>>>>>
>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>
>>>>> There are the ones that have never shown up anywhere  (I'm still
>>>>> waiting on 4 I believe)
>>>>>
>>>>> And then there are the ones that originally showed up, and we were
>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>> https://pagure.io/releng/issue/9580
>>>>
>>>> And while we would love to just publish these .. we can not.
>>>>
>>>> There are competing goals here.  Bit for bit like RHEL .. RHEL does not
>>>> have the SRPMS, we should not.
>>>>
>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>> they don't.  All our build system and where we pull info assumes we need
>>>> to be the same.  Introducing things were we are not is HARD ..
>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>> Introducing differences into compose configurations for pungi for
>>>> releases is HARD .. it has follow on impacts .. and we need a system in
>>>> place to make it continue to work when we get updated compose files in
>>>> the future.
>>>>
>>>> We have people working on this, but it is just not a priority compared
>>>> to getting things released on time and builds working properly.  It is
>>>> not just a simple .. push a couple packages somewhere.
>>>>
>>>
>>> You already have them published, that work is done.
>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>
>>> It doesn't say it in the ticket, but from conversations the rsync area
>>> that was setup for EPEL8 to sync that over, something happened and
>>> they can't sync anymore.
>>> I don't know the details.  It's possible that the syncing is already
>>> fixed, and they just need to restart and/or update their script.
>>>
>>> Troy
>>
>> Turns out the syncing was fixed, but the ticket not closed.
>> Sorry for all the noise.
>> If I had just tried to rebuild my package again, I would have seen it was fixed.
>>
>> Troy
> 
> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
> stay fixed.
> 
> But some -devel packages are also not fixed, as there are lots of things
> that need to be modified in the automation to keep them fixed.


I am not so deep in this "koji mbox pungi" infra thing but like other
devel packages, they are also the output of the build process and
survive the repo build, so why not letting them also there where they
already are? I can not believe that this is hardcoded in "koji mbox 
pungi" :-)?

Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
(Side note does Upstream have a rhelplus like centosplus repo? So,
no justification to have not an full populated Devel repo?)

While the packages are _actively_ deleted (process step before repo
build). Why not substitute "rm $1" with "mv -t Devel $1".
An automatic process and no need to request packages, like here:

https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2

The most requests for such devel packages are done because people are
building others packages that depend on (BuildRequires) also CentOS need
them. Well, they are devel rpms right. But what I wanted to say is they
are mostly not requested to get installed for ever and maybe produce bug
reports etc. (exactly this case is not supported, claimed by upstream).

BTW, you already do the right thing in putting a warning into the 
reponame/file.

Building the SRPM is straight forward and the people have then the 
missing devel packages. So why this hassle?


As I said, I do not know the internal process. Its just my mental model 
that gets here depicted from a point of view outside of the project.


--
Thanks,
Leon


From arrfab at centos.org  Thu Aug 13 14:46:58 2020
From: arrfab at centos.org (Fabian Arrotin)
Date: Thu, 13 Aug 2020 16:46:58 +0200
Subject: [CentOS-devel] Infra Pre-Announce : moving CI ssh jump host soon,
	please read !
Message-ID: <1e7b13aa-1fc9-872d-5ebc-46e44c9ba7cd@centos.org>

Hi,

As you noticed recently, we started to refresh the infra used for CentOS
CI (not the hardware, still the same, but the software stack and the way
to control/manage it).

One of the identified nodes still being used and that needs to be
converted to the new infra layout is the ssh jumphost (see
https://wiki.centos.org/QaWiki/CI/GettingStarted#How_to_use_it)

Normally, some of you have switched to OpenShift workload, (including to
the new Openshift 4/OCP setup that went live recently) but some Projects
are still on the old setup with sometimes a need to reach
dedicated/shared VMs acting as Jenkins agent[s], connected to Jenkins
behind https://ci.centos.org.

We have already provisioned a new VM in the new setup (that can reach
the whole CI subnet and VLAN) but here are some points to consider,
reason why we wanted to pre-announce long time in advance before we do
the real switch) :

 * New ssh jump host is CentOS 8 based, versus CentOS 6, meaning that if
you used ssh-dss key (instead of ssh-rsa), you'll *not* be able to
connect through that new host. We already identified such keys and Vipul
will try (when it's tied to a real email address for the project) to
reach out. But better to announce it here too, so that you have time to
ask us to reflect a change (through ticket on
https://pagure.io/centos-infra/issues)

 * Old VM allowed shell access, but it will be disallowed on the new one
(there is no need for shell on that intermediate node anyway). Reminder
that you can configure your ssh config to directly use ProxyCommand or
even now ProxyJump (on recent openssh-client). See
https://wiki.centos.org/TipsAndTricks/SshTips/JumpHost)

 * Because the host has a new sshd_host_key, it will come with a new
fingerprint too, so if you have automation and that you don't trust our
CA already, the fingerprint for new host will be :

[fingerprint]
rsa=3072 SHA256:n7y0qZS/FvhjaskOBds3TTKQh5EtgNQ25E7cmTNBATg  (RSA)
rsa_md5=3072 MD5:9e:83:46:d0:c5:8a:a0:94:50:10:58:9d:af:ca:50:19  (RSA)
ecdsa=256 SHA256:ZQacwDsWkKBYL9HJJYwHr94Ny1sMhHMDnz9GiLFb8Uc  (ECDSA)
ecdsa_md5=256 MD5:dd:24:ea:6a:fd:8b:29:3d:1d:d0:a9:32:8c:b2:ea:62  (ECDSA)

As we know that it's August and that some of you are probably on PTO
(coming back or leaving soon), after discussion with Vipul , David and
myself, we considered that we'll probably go live around beginning of
September.

Should you have any question around that migration, feel free to reply
to this thread (ideally on dedicated ci-users mailing list), or on
irc.freenode.net (#centos-ci)

On behalf of the CentOS CI infra team,
-- 
Fabian Arrotin
The CentOS Project | https://www.centos.org
gpg key: 17F3B7A1 | twitter: @arrfab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/f523904d/attachment-0006.sig>

From johnny at centos.org  Thu Aug 13 15:02:23 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:02:23 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
Message-ID: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>

On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>
>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>> wrote:
>>>>>
>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>> packages in CentOS
>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>
>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>
>>>>>> Hi Orion,
>>>>>> It helps if it is linked to this ticket.
>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>> Although nothing has happened there for 5 months.
>>>>>>
>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>
>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>> waiting on 4 I believe)
>>>>>>
>>>>>> And then there are the ones that originally showed up, and we were
>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>> https://pagure.io/releng/issue/9580
>>>>>
>>>>> And while we would love to just publish these .. we can not.
>>>>>
>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>> not
>>>>> have the SRPMS, we should not.
>>>>>
>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>> they don't.? All our build system and where we pull info assumes we
>>>>> need
>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>> Introducing differences into compose configurations for pungi for
>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>> system in
>>>>> place to make it continue to work when we get updated compose files in
>>>>> the future.
>>>>>
>>>>> We have people working on this, but it is just not a priority compared
>>>>> to getting things released on time and builds working properly.? It is
>>>>> not just a simple .. push a couple packages somewhere.
>>>>>
>>>>
>>>> You already have them published, that work is done.
>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>
>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>> that was setup for EPEL8 to sync that over, something happened and
>>>> they can't sync anymore.
>>>> I don't know the details.? It's possible that the syncing is already
>>>> fixed, and they just need to restart and/or update their script.
>>>>
>>>> Troy
>>>
>>> Turns out the syncing was fixed, but the ticket not closed.
>>> Sorry for all the noise.
>>> If I had just tried to rebuild my package again, I would have seen it
>>> was fixed.
>>>
>>> Troy
>>
>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>> stay fixed.
>>
>> But some -devel packages are also not fixed, as there are lots of things
>> that need to be modified in the automation to keep them fixed.
> 
> 
> I am not so deep in this "koji mbox pungi" infra thing but like other
> devel packages, they are also the output of the build process and
> survive the repo build, so why not letting them also there where they
> already are? I can not believe that this is hardcoded in "koji mbox
> pungi" :-)?
> 
> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
> (Side note does Upstream have a rhelplus like centosplus repo? So,
> no justification to have not an full populated Devel repo?)
> 
> While the packages are _actively_ deleted (process step before repo
> build). Why not substitute "rm $1" with "mv -t Devel $1".
> An automatic process and no need to request packages, like here:
> 
> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
> 
> 
> The most requests for such devel packages are done because people are
> building others packages that depend on (BuildRequires) also CentOS need
> them. Well, they are devel rpms right. But what I wanted to say is they
> are mostly not requested to get installed for ever and maybe produce bug
> reports etc. (exactly this case is not supported, claimed by upstream).
> 
> BTW, you already do the right thing in putting a warning into the
> reponame/file.
> 
> Building the SRPM is straight forward and the people have then the
> missing devel packages. So why this hassle?

> 
> As I said, I do not know the internal process. Its just my mental model
> that gets here depicted from a point of view outside of the project.

If I was the decider .. any -devel package that comes out would signed
and released .. I am not the decider.

I don't decide what gets in RHEL -devel files .. nor do i decide what
gets released from pungi .. but it matches what is released in RHEL with
approved additional -devel files.

That is just how it is.

We are working on a

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/be49c7c5/attachment-0006.sig>

From johnny at centos.org  Thu Aug 13 15:08:08 2020
From: johnny at centos.org (Johnny Hughes)
Date: Thu, 13 Aug 2020 10:08:08 -0500
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
Message-ID: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>

On 8/13/20 10:02 AM, Johnny Hughes wrote:
> On 8/12/20 2:01 PM, Leon Fauster via CentOS-devel wrote:
>> Am 12.08.20 um 16:55 schrieb Johnny Hughes:
>>> On 8/11/20 12:10 PM, Troy Dawson wrote:
>>>> On Tue, Aug 11, 2020 at 7:57 AM Troy Dawson <tdawson at redhat.com> wrote:
>>>>>
>>>>> On Tue, Aug 11, 2020 at 7:39 AM Johnny Hughes <johnny at centos.org>
>>>>> wrote:
>>>>>>
>>>>>> On 8/10/20 3:41 PM, Troy Dawson wrote:
>>>>>>> On Mon, Aug 10, 2020 at 1:29 PM Orion Poplawski <orion at nwra.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Is there anything I can do to help out with missing -devel
>>>>>>>> packages in CentOS
>>>>>>>> 8?? I'm waiting for a number of them, e.g.:
>>>>>>>>
>>>>>>>> https://bugs.centos.org/view.php?id=17401
>>>>>>>>
>>>>>>> Hi Orion,
>>>>>>> It helps if it is linked to this ticket.
>>>>>>> https://bugs.centos.org/view.php?id=16492
>>>>>>> Although nothing has happened there for 5 months.
>>>>>>>
>>>>>>> To be clear, there is two definitions of "missing -devel packages"
>>>>>>>
>>>>>>> There are the ones that have never shown up anywhere? (I'm still
>>>>>>> waiting on 4 I believe)
>>>>>>>
>>>>>>> And then there are the ones that originally showed up, and we were
>>>>>>> able to build from them in EPEL8, but then when RHEL 8.2 came along,
>>>>>>> the EPEL8 packages are still the old ones from RHEL 8.1.
>>>>>>> https://pagure.io/releng/issue/9580
>>>>>>
>>>>>> And while we would love to just publish these .. we can not.
>>>>>>
>>>>>> There are competing goals here.? Bit for bit like RHEL .. RHEL does
>>>>>> not
>>>>>> have the SRPMS, we should not.
>>>>>>
>>>>>> Someone wants the SRPMS .. so they want us to like RHEL .. except when
>>>>>> they don't.? All our build system and where we pull info assumes we
>>>>>> need
>>>>>> to be the same.? Introducing things were we are not is HARD ..
>>>>>> especially in el8 as we HAVE to use koji and mbox and pungi to build.
>>>>>> Introducing differences into compose configurations for pungi for
>>>>>> releases is HARD .. it has follow on impacts .. and we need a
>>>>>> system in
>>>>>> place to make it continue to work when we get updated compose files in
>>>>>> the future.
>>>>>>
>>>>>> We have people working on this, but it is just not a priority compared
>>>>>> to getting things released on time and builds working properly.? It is
>>>>>> not just a simple .. push a couple packages somewhere.
>>>>>>
>>>>>
>>>>> You already have them published, that work is done.
>>>>> http://mirror.centos.org/centos/8/Devel/x86_64/os/Packages/
>>>>> http://mirror.centos.org/centos/8.2.2004/Devel/x86_64/os/Packages/
>>>>>
>>>>> It doesn't say it in the ticket, but from conversations the rsync area
>>>>> that was setup for EPEL8 to sync that over, something happened and
>>>>> they can't sync anymore.
>>>>> I don't know the details.? It's possible that the syncing is already
>>>>> fixed, and they just need to restart and/or update their script.
>>>>>
>>>>> Troy
>>>>
>>>> Turns out the syncing was fixed, but the ticket not closed.
>>>> Sorry for all the noise.
>>>> If I had just tried to rebuild my package again, I would have seen it
>>>> was fixed.
>>>>
>>>> Troy
>>>
>>> Thanks Troy .. as i said, we did get SOME packages added and they SHOULD
>>> stay fixed.
>>>
>>> But some -devel packages are also not fixed, as there are lots of things
>>> that need to be modified in the automation to keep them fixed.
>>
>>
>> I am not so deep in this "koji mbox pungi" infra thing but like other
>> devel packages, they are also the output of the build process and
>> survive the repo build, so why not letting them also there where they
>> already are? I can not believe that this is hardcoded in "koji mbox
>> pungi" :-)?
>>
>> Ok, the argument is - RHEL is ... and CentOS will be also so. Okay.
>> (Side note does Upstream have a rhelplus like centosplus repo? So,
>> no justification to have not an full populated Devel repo?)
>>
>> While the packages are _actively_ deleted (process step before repo
>> build). Why not substitute "rm $1" with "mv -t Devel $1".
>> An automatic process and no need to request packages, like here:
>>
>> https://bugs.centos.org/view_all_set.php?sort_add=category_id&dir_add=DESC&type=2
>>
>>
>> The most requests for such devel packages are done because people are
>> building others packages that depend on (BuildRequires) also CentOS need
>> them. Well, they are devel rpms right. But what I wanted to say is they
>> are mostly not requested to get installed for ever and maybe produce bug
>> reports etc. (exactly this case is not supported, claimed by upstream).
>>
>> BTW, you already do the right thing in putting a warning into the
>> reponame/file.
>>
>> Building the SRPM is straight forward and the people have then the
>> missing devel packages. So why this hassle?
> 
>>
>> As I said, I do not know the internal process. Its just my mental model
>> that gets here depicted from a point of view outside of the project.
> 
> If I was the decider .. any -devel package that comes out would signed
> and released .. I am not the decider.
> 
> I don't decide what gets in RHEL -devel files .. nor do i decide what
> gets released from pungi .. but it matches what is released in RHEL with
> approved additional -devel files.
> 
> That is just how it is.
> 
> We are working on a
> 

hmmm .. got cut off ..

We are working on a public mirror of the koji files .. they should be
downloadable from there when it is available.  I don't know when that is
going to happen.

Attend the next CPE community meeting and ask:

https://blog.centos.org/2020/07/cpe-weekly-2020-07-25/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200813/b46bcc37/attachment-0006.sig>

From amoloney at redhat.com  Fri Aug 14 21:04:05 2020
From: amoloney at redhat.com (Aoife Moloney)
Date: Fri, 14 Aug 2020 22:04:05 +0100
Subject: [CentOS-devel] CPE Weekly: 2020-08-14
Message-ID: <CAJqbrbfPYxf6AJyrVGLxg8O6oumOvGQQsDs5wuzUyKdZfxswTw@mail.gmail.com>

---
title: CPE Weekly status email
tags: CPE Weekly, email
---

# CPE Weekly: 2020-08-14
Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/


## General Project Updates

The CPE team are working on the following projects for Quarter 3,
which is the months of July, August & September:
* Data Centre Move - Final Works
* CentOS Stream Phase 3
* Noggin Phase 3
* Packager Workflow Healthcare
* Fedora Messaging Schemas

Details of the above projects, and of projects currently in progress,
done and what projects are in our backlog, can be found on our taiga
board per project card:
https://tree.taiga.io/project/amoloney1-cpe-team-projects/kanban?epic=null

We also have an updated initiative timetable for briefing in new
projects to our team & key dates
here:https://docs.fedoraproject.org/en-US/cpe/time_tables/
*Note: Initiatives are large pieces of work that require a team of
people and weeks/months to complete. Please continue to open tickets
in the normal way for bugs, issues, etc.





### CPE Product Owner Office Hours
#### #fedora-meeting-1
* Weekly on Thursdays @ 1300 UTC on #fedora-meeting-1
    * Next Meeting: 2020-08-20
#### #centos-meeting
* Every second Tuesday @ 1500 UTC on #centos-meeting
    * Next Meeting: 2020-08-18

### Misc

#### Nest With Fedora Note
Thank you to everyone who attended Nest With Fedora over the weekend
and engaged with us during our talks and social sessions. It was a
fantastic event, very well put together and run by the Fedora team and
it was both my pleasure and honour to have been a part of what was a
fantastic schedule! I cant wait to catch up on talks I missed when
they are uploaded, and the CPE team, with thanks to Michal Konecny who
put the structure of our piece together, will be submitting a
collaborative blog post to the Community blog space in the coming
weeks, recapping our experience at Nest this year. Well done Marie
Nordin, Matthew Miller and the wider team, and our very own Vipul
Siddarth, on what was a very successful and enjoyable event!


#### Engagement Email Feedback
At the beginning of July I sent an email to devel-announce requesting
feedback from the community on changes I and the wider CPE team have
made when scheduling projects to work on, in an effort to find the
balance between work and life. We are still searching :)
However, I got some very good tips that I will definitely be
incorporating which I shared at Nest during the CPE AMA Session and in
reply to the original mail.
The link to the mails are here for full reading
https://lists.fedoraproject.org/archives/list/devel-announce at lists.fedoraproject.org/thread/UNWTLOI2U4VKAU4IKJZGZLZ2DTMPEFBW/
But the suggestions and actions are here for quicker reference:
Continue to communicate regularly on projects & updates
- Will do, weekly emails have been a bit more sporadic lately as I have had
some time off

Less acronyms & abbreviations in comms :)
- Sure, that's an easy fix on my end and makes sense

Publish team members timezone on docs.fpo/cpe to help define our ?working
hours?
- Will do, I hope to get to this by end of August and they will be
reflected on docs.fpo/cpe

Publish the workflow diagram to docs.fpo/cpe and add filtered versions that
are user specific
- Same as above, publishing it on docs.fpo/cpe-initiatives

Office Hours on IRC are a useful way to contact team Product Owner
- Great to hear, please feel free to stop by when you can/want to. They are
on Thursdays @ 1300 UTC on #fedora-meeting-1 and every second Tuesday @
1500 UTC on #centos-meeting

Public tracker for bugs
- Our team meets twice a day, every day on IRC to review tickets and issues
to work on. They meet @ 0830 UTC on #centos-meeting and again @ 1800 UTC on
#fedora-admin. These are public meetings so please feel free to attend.

If you would like to offer any further suggestions or feedback on the
Community Platform Engineering team, please feel free to complete our
survey which is open until August 30th
https://fedoraproject.limequery.com/696793?lang=en


## Fedora Updates

### Data Centre Move
* Nearly done!!!!!!
* Firewalls for staging are going up this week
* Last of the hardware has been set up for networking changes
* The bringup of Communishift is being made into a dedicated project
for work as soon as the team have capacity to do so - this may be in
late September as the members of the colo team will (hopefully) take
some very well deserved time off work before tackling this one :)



### AAA Replacement
* Some of the Noggin team have been enjoying some very well deserved
time off work over the last week or two so work has, naturally slowed.
* The code is currently being security audited by Patrick Uiterwijk,
thank you Patrick!
* Next steps will be to successfully deploy Noggin to staging when it
has been brought back up - we are estimating this to be late next week
* Once Noggin has been deployed to staging, we would love some
community feedback on the application and its performance. We will be
emailing the infra/devel lists on when to test and how to give us
feedback when we are fully deployed in stg.
* In the meantime. Please feel free to check out the team kanban board
for more information on the features the team are working on and have
already completed here https://github.com/orgs/fedora-infra/projects/6





### Fedora Messaging Schemas
* This project is being worked on by the same team as Noggin, so there
has been some progress made but not a lot as team members enjoy some
holidays
* The team have already built a list of applications that require
messaging schemas, list can be found here
https://hackmd.io/@nilsph/H1i8CAbkP/edit
* They also have completed a readme which contains documentation on
messaging schemas, a cookie-cutter template to create the schema and a
definition of Done for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7




### Packager Workflow Healthcare
* Project information: This is an investigative project that aims to
look at the entire packager workflow as a single piece of tooling to
identify where failures happen, and try to identify when and why
packages fail at different points within the workflow. We hope to have
two possible outcomes from this project at the end of the quarter
(September):
    * The workflow breaks at X point and we will work on a solution to fix
    * OR
    * The workflow works fine, but we will need better monitoring on
the pipeline so we will work on a solution for this
* The team are using this Monitor-Script
https://pagure.io/fedora-ci/monitor-gating/ and are making
improvements to it on resiliency/reliability.
* They are finishing the investigation phase of the project and are
going to document the packager workflow (with graphs I have been
promised!) showcasing how the different systems interact with one
another
* And are working on an outline of the workflow steps (from packager
PoV) and systems involved (CPE team PoV), identifying metrics to be
measured
* The teams work is being tracked here
https://teams.fedoraproject.org/project/cpe-cicd/kanban







## CentOS Updates

### CentOS
* CentOS-infra team have created a ticket board, check it out here
https://pagure.io/centos-infra/boards/CentOS%20CI%20Infra
* CBS Koji x86 builders moved to new(er) infrastructure
(https://lists.centos.org/pipermail/centos-devel/2020-August/055988.html)
* The team also caught up C6,  C7 and C8 Linux .. 2 outstanding
Bootstrap Modules for C8 Linux (eclipse and the latest rust-toolset).




### CentOS Stream
* Not too much to report this week - The team are mostly working on
developing utility scripts that will ease the CentOS 8 and CentOS
Stream packaging workflow and business as usual updates to CentOS
Stream.



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford



From plageat at tut.by  Sat Aug 15 22:06:20 2020
From: plageat at tut.by (plageat at tut.by)
Date: Sun, 16 Aug 2020 01:06:20 +0300
Subject: [CentOS-devel] Missing -devel packages
In-Reply-To: <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
References: <532f116a-e2b3-8619-8867-d05fc8802cf6@nwra.com>
 <CAKndyURr5_=ueq331rLx0nEuWm9g43edKWSwLXqsAYK26o0NRQ@mail.gmail.com>
 <77d945b8-6906-d8f2-21bf-a949096a1e50@centos.org>
 <CAKndyURTY-L1f18UAh5YS5n6G_Co6HfSEejN8E83FQxMx5e_wA@mail.gmail.com>
 <CAKndyUT2kv459S1triwhWH9OhXbmfh64fCrGYmT580mJ8KG1eA@mail.gmail.com>
 <27837b1f-19dc-c21e-b5cb-52eab882c57e@centos.org>
 <b805d688-ed9a-abe5-e10d-2d98c764b5f5@gmail.com>
 <8b0315d6-3fb6-4a2c-ece7-4fef98dda100@centos.org>
 <88759d30-e928-d606-2a7d-18ca7ffbf000@centos.org>
Message-ID: <1616331597527959@mail.yandex.ru>


> 13.08.2020, 18:08, "Johnny Hughes" <johnny at centos.org>:
>
> We are working on a public mirror of the koji files .. they should be
> downloadable from there when it is available. I don't know when that is
> going to happen.

Just keep official repos like they are in RHEL without -devel ot -libs or whatever in according with errata.
But it would be very VERY nice to have all '(download)' things to be downloadable instead of '403 'Forbidden' for any build on https://koji.mbox.centos.org. Signed or not - does not really matter. We just need them in 99.999% cases for build reproducibility for our soft or modifications in CentOS as users. We do not really expect any support from CentOS on them or depended builded by us software modifications.
Just like it was a year ago during 8.0beta.
Just like we can download everything from https://buildlogs.centos.org for el7 (and this is super usefull).
That is the point the whole community is waiting for a year or more and keep creating dozen repeated bugs/topics here.




From ancarrol at redhat.com  Fri Aug 21 15:24:15 2020
From: ancarrol at redhat.com (Ant Carroll)
Date: Fri, 21 Aug 2020 16:24:15 +0100
Subject: [CentOS-devel] CPE Feedback Survey
In-Reply-To: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
References: <CADbh8kAigfB9_G5tKdTiaivf2o9AA+isWSvJ2VNGD3D6t-0yqg@mail.gmail.com>
Message-ID: <CADbh8kAsG_JOU2x8UVBFVf_9Q4q4pbbANf1Nh7xEyEKMGFHY_Q@mail.gmail.com>

Hey all,

First of all, thanks to everyone that has taken the time to complete the
survey for us already. It will remain open until the end of August, so if
you haven't had the chance to fill it in yet, we'd really appreciate you
taking the few minutes to do so before it closes.

Thanks again,

Ant

On Thu, Aug 6, 2020 at 6:23 PM Ant Carroll <ancarrol at redhat.com> wrote:

> Hey folks,
>
> CPE <https://docs.fedoraproject.org/en-US/cpe/>need your help :)
>
> Over the last several months we've been trying to improve how we interact
> and share information with you all. From the blog posts, to mails and how
> we work on the tickets you send us.
>
> Here is a link to a very short survey we've put together to learn how we
> can give you the best experience possible going forward by understanding
> the experiences you've had recently.
> If you could take the time (5mins max) to complete it for us it would be
> hugely valuable as we work on this continuous improvement -
> https://fedoraproject.limequery.com/696793?lang=en
> <https://meet.google.com/linkredirect?authuser=0&dest=https%3A%2F%2Ffedoraproject.limequery.com%2F696793%3Flang%3Den>
>
>
> Cheers,
>
> Ant
> --
>
> Ant Carroll
>
> Associate Manager, CPE Team
>
> Red Hat Waterford <http://www.redhat.com>
>
> Communications House
>
> Cork Road, Waterford City
>
> ancarrol at redhat.com
> M: +353876213163     IM: ancarrol
> @redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
> <https://www.facebook.com/redhatjobs> @redhatjobs
> <https://instagram.com/redhatjobs>
> <https://www.redhat.com/>
>


-- 

Ant Carroll

Associate Manager, Software Engineering

Red Hat Waterford <http://www.redhat.com>

Communications House

Cork Road, Waterford City

ancarrol at redhat.com
M: +353876213163     IM: ancarrol
@redhatjobs <https://twitter.com/redhatjobs>   redhatjobs
<https://www.facebook.com/redhatjobs> @redhatjobs
<https://instagram.com/redhatjobs>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200821/90549cda/attachment-0006.html>

From ascanio.alba7 at gmail.com  Sat Aug 22 01:04:25 2020
From: ascanio.alba7 at gmail.com (Anthony Alba)
Date: Sat, 22 Aug 2020 09:04:25 +0800
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR 0x48e
	to 0xfff9fffe04006172
Message-ID: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>

On 8.2, with modular virt installed OR switching to
centos-release-advanced-virtualization I am seeing

qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172

when trying to create a VM with virt-install on a Dell PowerEdge R630
with a Xeon E5-2640. The command works on a desktop Haswell.

There was such a bug in RH bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
nested virtualisation and L1->L1 migration with a L2 guest. I am not
doing any such magick, just a plain L1 VM.

I tried reloading kvm_intel with pml=0 but got the same error.

qemu-kvm-4.2.0-19.el8.x86_64
libvirt-6.0.0-17.el8.x86_64

Any ideas? (See below, does intel_iommu have to be on?)

The CPU type is

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 2809.143
cache size      : 20480 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
l1tf mds swapgs itlb_multihit
bogomips        : 5200.46
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

# virt-host-validate
  QEMU: Checking for hardware virtualization
      : PASS
  QEMU: Checking if device /dev/kvm exists
      : PASS
  QEMU: Checking if device /dev/kvm is accessible
      : PASS
  QEMU: Checking if device /dev/vhost-net exists
      : PASS
  QEMU: Checking if device /dev/net/tun exists
      : PASS
  QEMU: Checking for cgroup 'cpu' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuacct' controller support
      : PASS
  QEMU: Checking for cgroup 'cpuset' controller support
      : PASS
  QEMU: Checking for cgroup 'memory' controller support
      : PASS
  QEMU: Checking for cgroup 'devices' controller support
      : PASS
  QEMU: Checking for cgroup 'blkio' controller support
      : PASS
  QEMU: Checking for device assignment IOMMU support
      : PASS
  QEMU: Checking if IOMMU is enabled by kernel
      : WARN (IOMMU appears to be disabled in kernel. Add
intel_iommu=on to kernel cmdline arguments)


From tmittermair at cvl.tuwien.ac.at  Tue Aug 25 16:21:38 2020
From: tmittermair at cvl.tuwien.ac.at (Theodor Mittermair)
Date: Tue, 25 Aug 2020 18:21:38 +0200
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>

Hello,

I'd like to inquire about the status of the "dlm" package on Centos 8, 
which is required for using 'lvmlockd', replacement of 'clvmd'.
I also asked on #centos irc channel and was directed to this mailing list
There is a corresponding bug ticket [2] for this issue for quite some 
time, but since the end-of-life of CentOS 6 grows closer, some people 
would like to replace their CentOS 6 Cluster with a CentOS 8 one, which 
is why I ask on this mailing list now.

With the release of CentOS 8.0 it seems there were some issues with 
HighAvailability in general [1], but seem to have been resolved with 
CentOS 8.1.

However, as already mentioned there is a separate ticket [2], for the 
dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i 
am aware.
This prevents the use of clustered lvm and gfs2 out of the box, not an 
uncommon use when configuring a HA Cluster, also described by RedHat 
documentation [3].
In that tickets' conversation, it is mentioned that "that package is not 
in RHEL .. we have released what is in RHEL", however someone else 
seemed to have been in contact with RedHat and received information that 
"...this package is in fact part of a RedHat repository and then CentOS 
members should be able to take a look into it again...".

I'd also like to bring attention to the following explicitly:
* dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is 
available while dlm is not.
* apparently at some point in time dlm could be downloaded from koji 
[4], but no more. For testing purposes we built dlm ourselves, locally 
as well as on copr [5], which seems to work thus far.
* fedora (however much this might mean) provides dlm.
* It might just be a configuration error on the build system, if I 
understood correctly, there was/is larger amounts of restructuring. Also 
see chders' post from 2020-08-21 [2], which provides a possible 
explanation and solution.

For completeness, you should be able reproduce the absence of that 
package with:
"yum --disablerepo='*' 
--enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack 
list available | grep dlm"
or simply attempt to
"yum install dlm"
on your CentOS 8.x Installation.

Therefore, I would like to ask:
Is this an error on my end, am I doing something wrong or missing a 
configuration?
If no, is there actually any political/technical/administrative/law 
based reason for the unavailability of the "dlm" package?
If no, according to recent posts on the ticket [2], there might be a 
rather simple solution (simplified, declaring the package to be included 
in a repository), is it valid and who could do this if applicable?

with best regards
Theodor Mittermair
<https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
[1] https://bugs.centos.org/view.php?id=16553
[2] https://bugs.centos.org/view.php?id=16939
[3] 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
[4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
[5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/314f9bc0/attachment-0006.html>

From johnny at centos.org  Tue Aug 25 18:47:43 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:47:43 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>

On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/

I have already stated it several places.  Resilient Storageis not base
RHEL and not added to CentOS Linux 8.  If you want Advance Platform
items, subscribe to RHEL.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/80008137/attachment-0006.sig>

From johnny at centos.org  Tue Aug 25 18:50:09 2020
From: johnny at centos.org (Johnny Hughes)
Date: Tue, 25 Aug 2020 13:50:09 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
 <b7cfff89-bdf1-2e88-80ff-61db35130a60@centos.org>
Message-ID: <7bcc154d-cc23-8324-0dd9-9bb08838f9a0@centos.org>

On 8/25/20 1:47 PM, Johnny Hughes wrote:
> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> I have already stated it several places.  Resilient Storageis not base
> RHEL and not added to CentOS Linux 8.  If you want Advance Platform
> items, subscribe to RHEL.

And before anyone asks .. it is not my decision to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200825/31e96420/attachment-0006.sig>

From bstinson at redhat.com  Tue Aug 25 20:32:39 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Tue, 25 Aug 2020 15:32:39 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
References: <1bad6438-da79-3c1f-3214-29494df4a1d0@cvl.tuwien.ac.at>
Message-ID: <d4ca553f-d8ca-ed5e-d9e0-1752d33443ca@redhat.com>



On 8/25/20 11:21 AM, Theodor Mittermair wrote:
> Hello,
> 
> I'd like to inquire about the status of the "dlm" package on Centos 8,
> which is required for using 'lvmlockd', replacement of 'clvmd'.
> I also asked on #centos irc channel and was directed to this mailing list
> There is a corresponding bug ticket [2] for this issue for quite some
> time, but since the end-of-life of CentOS 6 grows closer, some people
> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
> is why I ask on this mailing list now.
> 
> With the release of CentOS 8.0 it seems there were some issues with
> HighAvailability in general [1], but seem to have been resolved with
> CentOS 8.1.
> 
> However, as already mentioned there is a separate ticket [2], for the
> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
> am aware.
> This prevents the use of clustered lvm and gfs2 out of the box, not an
> uncommon use when configuring a HA Cluster, also described by RedHat
> documentation [3].
> In that tickets' conversation, it is mentioned that "that package is not
> in RHEL .. we have released what is in RHEL", however someone else
> seemed to have been in contact with RedHat and received information that
> "...this package is in fact part of a RedHat repository and then CentOS
> members should be able to take a look into it again...".
> 
> I'd also like to bring attention to the following explicitly:
> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
> available while dlm is not.
> * apparently at some point in time dlm could be downloaded from koji
> [4], but no more. For testing purposes we built dlm ourselves, locally
> as well as on copr [5], which seems to work thus far.
> * fedora (however much this might mean) provides dlm.
> * It might just be a configuration error on the build system, if I
> understood correctly, there was/is larger amounts of restructuring. Also
> see chders' post from 2020-08-21 [2], which provides a possible
> explanation and solution.
> 
> For completeness, you should be able reproduce the absence of that
> package with:
> "yum --disablerepo='*'
> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
> list available | grep dlm"
> or simply attempt to
> "yum install dlm"
> on your CentOS 8.x Installation.
> 
> Therefore, I would like to ask:
> Is this an error on my end, am I doing something wrong or missing a
> configuration?
> If no, is there actually any political/technical/administrative/law
> based reason for the unavailability of the "dlm" package?
> If no, according to recent posts on the ticket [2], there might be a
> rather simple solution (simplified, declaring the package to be included
> in a repository), is it valid and who could do this if applicable?
> 
> with best regards
> Theodor Mittermair
> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
> [1] https://bugs.centos.org/view.php?id=16553
> [2] https://bugs.centos.org/view.php?id=16939
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
> 
> 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

Hi Folks,

Some clarity will follow on how we plan to deliver Addon repositories
like ResilientStorage, HighAvailability and NFV.

Because of Red Hat?s desire to develop Addons along with the next minor
release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
Stream for direct consumption.

If you think a package belongs in another repository, we encourage you
to open a CentOS Stream bugzilla to discuss with RHEL maintainers:

https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream

We do not plan to expand the portfolio of Addons for CentOS Linux.

If there is a group of interested folks who wish to maintain extra
content built against CentOS Linux, you may apply for a Special Interest
Group: https://wiki.centos.org/SIGGuide

Cheers!
--Brian



From sbonazzo at redhat.com  Wed Aug 26 13:37:17 2020
From: sbonazzo at redhat.com (Sandro Bonazzola)
Date: Wed, 26 Aug 2020 15:37:17 +0200
Subject: [CentOS-devel] 8.2+Xeon: qemu-kvm: error: failed to set MSR
 0x48e to 0xfff9fffe04006172
In-Reply-To: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
References: <CADkWibecRWu=DeOUkGJmBnQ-=H5UwMmKm=TK-pQNtBihpEhxpQ@mail.gmail.com>
Message-ID: <CAPQRNTnGO_17O5dR_c6NiK64N2KysWfKxfD4+PG796rjSauWMA@mail.gmail.com>

Adding +Miroslav Rezanina <mrezanin at redhat.com> , +Danilo Cesar Lemes de
Paula <ddepaula at redhat.com> and +Paolo Bonzini <pbonzini at redhat.com>

Il giorno sab 22 ago 2020 alle ore 03:04 Anthony Alba <
ascanio.alba7 at gmail.com> ha scritto:

> On 8.2, with modular virt installed OR switching to
> centos-release-advanced-virtualization I am seeing
>
> qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172
>
> when trying to create a VM with virt-install on a Dell PowerEdge R630
> with a Xeon E5-2640. The command works on a desktop Haswell.
>
> There was such a bug in RH bugzilla
> https://bugzilla.redhat.com/show_bug.cgi?id=1738741 but that is about
> nested virtualisation and L1->L1 migration with a L2 guest. I am not
> doing any such magick, just a plain L1 VM.
>
> I tried reloading kvm_intel with pml=0 but got the same error.
>
> qemu-kvm-4.2.0-19.el8.x86_64
> libvirt-6.0.0-17.el8.x86_64
>
> Any ideas? (See below, does intel_iommu have to be on?)
>
> The CPU type is
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 63
> model name      : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz
> stepping        : 2
> microcode       : 0x43
> cpu MHz         : 2809.143
> cache size      : 20480 KB
> physical id     : 0
> siblings        : 16
> core id         : 0
> cpu cores       : 8
> apicid          : 0
> initial apicid  : 0
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 15
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
> rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq
> dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm
> pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes
> xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti
> ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm xsaveopt cqm_llc
> cqm_occup_llc dtherm ida arat pln pts md_clear flush_l1d
> bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass
> l1tf mds swapgs itlb_multihit
> bogomips        : 5200.46
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 46 bits physical, 48 bits virtual
> power management:
>
> # virt-host-validate
>   QEMU: Checking for hardware virtualization
>       : PASS
>   QEMU: Checking if device /dev/kvm exists
>       : PASS
>   QEMU: Checking if device /dev/kvm is accessible
>       : PASS
>   QEMU: Checking if device /dev/vhost-net exists
>       : PASS
>   QEMU: Checking if device /dev/net/tun exists
>       : PASS
>   QEMU: Checking for cgroup 'cpu' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuacct' controller support
>       : PASS
>   QEMU: Checking for cgroup 'cpuset' controller support
>       : PASS
>   QEMU: Checking for cgroup 'memory' controller support
>       : PASS
>   QEMU: Checking for cgroup 'devices' controller support
>       : PASS
>   QEMU: Checking for cgroup 'blkio' controller support
>       : PASS
>   QEMU: Checking for device assignment IOMMU support
>       : PASS
>   QEMU: Checking if IOMMU is enabled by kernel
>       : WARN (IOMMU appears to be disabled in kernel. Add
> intel_iommu=on to kernel cmdline arguments)
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA <https://www.redhat.com/>

sbonazzo at redhat.com
<https://www.redhat.com/>

*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
<https://mojo.redhat.com/docs/DOC-1199578>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200826/55ccb57a/attachment-0006.html>

From centoslistmail at gmail.com  Thu Aug 27 14:55:33 2020
From: centoslistmail at gmail.com (BC)
Date: Thu, 27 Aug 2020 10:55:33 -0400
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
Message-ID: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>

I have noticed some email announcements missing recently. Just to
mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
behind this I wasn't aware of or if it was a fluke or whatever.

As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
some updates come weeks after. Is this a known issue or is my setup
perhaps broken? Does anyone else see the same behavior?

Thanks for all the hard work!


From bstinson at centosproject.org  Thu Aug 27 18:33:31 2020
From: bstinson at centosproject.org (Brian Stinson)
Date: Thu, 27 Aug 2020 13:33:31 -0500
Subject: [CentOS-devel] Scheduled RDU2 Network Maintenance 03-Sept-2020
	12:00-13:00 UTC
Message-ID: <517a9d57-97fe-6bbd-0da9-16905e6db99f@centosproject.org>

Hi Folks,

We'd like to announce an outage window from Noon to 13:00 UTC on
Thursday, 03-Sept-2020 for our services in the RDU2 Community Cage.

This includes ci.centos.org, apps.ci.centos.org, apps.ocp.ci.centos.org,
and cbs.centos.org

During this period we expect intermittent network disconnects while our
switches receive firmware upgrades.


Thank you for your patience while we complete this maintenance.


--Brian




From judd.obannon at rackspace.com  Fri Aug 28 11:58:28 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 11:58:28 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
Message-ID: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>

> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>> Hello,
>>
>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>> I also asked on #centos irc channel and was directed to this mailing list
>> There is a corresponding bug ticket [2] for this issue for quite some
>> time, but since the end-of-life of CentOS 6 grows closer, some people
>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>> is why I ask on this mailing list now.
>>
>> With the release of CentOS 8.0 it seems there were some issues with
>> HighAvailability in general [1], but seem to have been resolved with
>> CentOS 8.1.
>>
>> However, as already mentioned there is a separate ticket [2], for the
>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>> am aware.
>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>> uncommon use when configuring a HA Cluster, also described by RedHat
>> documentation [3].
>> In that tickets' conversation, it is mentioned that "that package is not
>> in RHEL .. we have released what is in RHEL", however someone else
>> seemed to have been in contact with RedHat and received information that
>> "...this package is in fact part of a RedHat repository and then CentOS
>> members should be able to take a look into it again...".
>>
>> I'd also like to bring attention to the following explicitly:
>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>> available while dlm is not.
>> * apparently at some point in time dlm could be downloaded from koji
>> [4], but no more. For testing purposes we built dlm ourselves, locally
>> as well as on copr [5], which seems to work thus far.
>> * fedora (however much this might mean) provides dlm.
>> * It might just be a configuration error on the build system, if I
>> understood correctly, there was/is larger amounts of restructuring. Also
>> see chders' post from 2020-08-21 [2], which provides a possible
>> explanation and solution.
>>
>> For completeness, you should be able reproduce the absence of that
>> package with:
>> "yum --disablerepo='*'
>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>> list available | grep dlm"
>> or simply attempt to
>> "yum install dlm"
>> on your CentOS 8.x Installation.
>>
>> Therefore, I would like to ask:
>> Is this an error on my end, am I doing something wrong or missing a
>> configuration?
>> If no, is there actually any political/technical/administrative/law
>> based reason for the unavailability of the "dlm" package?
>> If no, according to recent posts on the ticket [2], there might be a
>> rather simple solution (simplified, declaring the package to be included
>> in a repository), is it valid and who could do this if applicable?
>>
>> with best regards
>> Theodor Mittermair
>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>> [1] https://bugs.centos.org/view.php?id=16553
>> [2] https://bugs.centos.org/view.php?id=16939
>> [3]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>
>>
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel at centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>>
> Hi Folks,
>
> Some clarity will follow on how we plan to deliver Addon repositories
> like ResilientStorage, HighAvailability and NFV.
>
> Because of Red Hat?s desire to develop Addons along with the next minor
> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
> Stream for direct consumption.
>
> If you think a package belongs in another repository, we encourage you
> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>
> We do not plan to expand the portfolio of Addons for CentOS Linux.
>
> If there is a group of interested folks who wish to maintain extra
> content built against CentOS Linux, you may apply for a Special Interest
> Group: https://wiki.centos.org/SIGGuide
>
> Cheers!
> --Brian

My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?

First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?

Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.

Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.

Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

If I'm misunderstanding any of this please educate me.

Thank you,
Judd

[1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
[2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html


From johnny at centos.org  Fri Aug 28 18:07:06 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:07:06 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
Message-ID: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>

On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://koji.mbox.centos.org/koji/buildinfo?buildID=4801>
>>> [1] https://bugs.centos.org/view.php?id=16553
>>> [2] https://bugs.centos.org/view.php?id=16939
>>> [3]
>>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters
>>> [4] https://koji.mbox.centos.org/koji/buildinfo?buildID=145
>>> [5] https://copr.fedorainfracloud.org/coprs/astra/dlm/
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://lists.centos.org/mailman/listinfo/centos-devel
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%208&version=CentOS%20Stream
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://wiki.centos.org/SIGGuide
>>
>> Cheers!
>> --Brian
> 
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.?
> 
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't?understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?? I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
> 
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
> 
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
> 
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

> 
> If I'm misunderstanding any of this please educate me.
> 

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
> 
> [1]?http://mirror.centos.org/centos-7/7/os/x86_64/Packages/dlm-4.0.7-1.el7.x86_64.rpm
> [2]?https://lists.centos.org/pipermail/centos-devel/2020-July/037034.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/7249e5ed/attachment-0006.sig>

From johnny at centos.org  Fri Aug 28 18:13:56 2020
From: johnny at centos.org (Johnny Hughes)
Date: Fri, 28 Aug 2020 13:13:56 -0500
Subject: [CentOS-devel] Update announcement question (6, 7, and 8)
In-Reply-To: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
References: <CADYKQ6nj-mYyHungXWFFP=bXfup69U6xagKP=XTptZmjrLtj-w@mail.gmail.com>
Message-ID: <ceffa600-e624-0318-7c36-6ec9bac74923@centos.org>

On 8/27/20 9:55 AM, BC wrote:
> I have noticed some email announcements missing recently. Just to
> mention a few, the 3.10.0-1127.19.1.el7, 2.6.32-754.31.1.el6, and
> 2.6.32-754.33.1.el6 kernels. I'm just wondering if there was a reason
> behind this I wasn't aware of or if it was a fluke or whatever.

We have scripts that allow us to announce CentOS-6 and CentOS-7 updates
.. we do not hav any for CetnOS-8.

Our scripts need this page to be functioning properly when they are run:

https://access.redhat.com/errata/#/

If we do not get good announments from the API of that page, we have to
wait until the site is fixed.  I will try to see if the announcements
work now (they did not on the day of release).

> 
> As to the RSS feed for 8, I'm using feeds.centos.org/ via liferea and
> some updates come weeks after. Is this a known issue or is my setup
> perhaps broken? Does anyone else see the same behavior?

It is a known issue.  Modules are extremely hard right now.  We have to
bootstrap them, test that they link properly, etc.  CentOS Linux 8 is
going to lag, especially for modules.

> 
> Thanks for all the hard work!

We are doing our best .. wish we could do more.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200828/b6b6d01e/attachment-0006.sig>

From judd.obannon at rackspace.com  Fri Aug 28 21:08:06 2020
From: judd.obannon at rackspace.com (Judd O'Bannon)
Date: Fri, 28 Aug 2020 21:08:06 +0000
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>,
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
Message-ID: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>

From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
Sent: Friday, August 28, 2020 13:07
To: centos-devel at centos.org
Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable

CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!


On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>> Hello,
>>>
>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>> I also asked on #centos irc channel and was directed to this mailing list
>>> There is a corresponding bug ticket [2] for this issue for quite some
>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>> is why I ask on this mailing list now.
>>>
>>> With the release of CentOS 8.0 it seems there were some issues with
>>> HighAvailability in general [1], but seem to have been resolved with
>>> CentOS 8.1.
>>>
>>> However, as already mentioned there is a separate ticket [2], for the
>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>> am aware.
>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>> documentation [3].
>>> In that tickets' conversation, it is mentioned that "that package is not
>>> in RHEL .. we have released what is in RHEL", however someone else
>>> seemed to have been in contact with RedHat and received information that
>>> "...this package is in fact part of a RedHat repository and then CentOS
>>> members should be able to take a look into it again...".
>>>
>>> I'd also like to bring attention to the following explicitly:
>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>> available while dlm is not.
>>> * apparently at some point in time dlm could be downloaded from koji
>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>> as well as on copr [5], which seems to work thus far.
>>> * fedora (however much this might mean) provides dlm.
>>> * It might just be a configuration error on the build system, if I
>>> understood correctly, there was/is larger amounts of restructuring. Also
>>> see chders' post from 2020-08-21 [2], which provides a possible
>>> explanation and solution.
>>>
>>> For completeness, you should be able reproduce the absence of that
>>> package with:
>>> "yum --disablerepo='*'
>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>> list available | grep dlm"
>>> or simply attempt to
>>> "yum install dlm"
>>> on your CentOS 8.x Installation.
>>>
>>> Therefore, I would like to ask:
>>> Is this an error on my end, am I doing something wrong or missing a
>>> configuration?
>>> If no, is there actually any political/technical/administrative/law
>>> based reason for the unavailability of the "dlm" package?
>>> If no, according to recent posts on the ticket [2], there might be a
>>> rather simple solution (simplified, declaring the package to be included
>>> in a repository), is it valid and who could do this if applicable?
>>>
>>> with best regards
>>> Theodor Mittermair
>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>> [3]
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>
>>>
>>> _______________________________________________
>>> CentOS-devel mailing list
>>> CentOS-devel at centos.org
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>
>> Hi Folks,
>>
>> Some clarity will follow on how we plan to deliver Addon repositories
>> like ResilientStorage, HighAvailability and NFV.
>>
>> Because of Red Hat?s desire to develop Addons along with the next minor
>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>> Stream for direct consumption.
>>
>> If you think a package belongs in another repository, we encourage you
>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>
>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>
>> If there is a group of interested folks who wish to maintain extra
>> content built against CentOS Linux, you may apply for a Special Interest
>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>
>> Cheers!
>> --Brian
>
> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>
> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>
> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>
> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>
> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.

Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
way it is.  If it were up to me, I would push it .. it is not up to me.

>
> If I'm misunderstanding any of this please educate me.
>

It has already been stated that we will bot be putting the addon items
in CentOS Linux .. just in Stream.

You have to test and decide what you will use.

> Thank you,
> Judd
>
> [1]?https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
> [2]?https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0


One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 

Thank you,

Judd 


From bstinson at redhat.com  Fri Aug 28 22:05:03 2020
From: bstinson at redhat.com (Brian Stinson)
Date: Fri, 28 Aug 2020 17:05:03 -0500
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
Message-ID: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>



On 8/28/20 4:08 PM, Judd O'Bannon via CentOS-devel wrote:
> From: CentOS-devel <centos-devel-bounces at centos.org> on behalf of Johnny Hughes <johnny at centos.org>
> Sent: Friday, August 28, 2020 13:07
> To: centos-devel at centos.org
> Subject: Re: [CentOS-devel] Centos 8.x, dlm Package unavailable
> 
> CAUTION: This message originated externally, please use caution when clicking on links or opening attachments!
> 
> 
> On 8/28/20 6:58 AM, Judd O'Bannon via CentOS-devel wrote:
>>> On 8/25/20 11:21 AM, Theodor Mittermair wrote:
>>>> Hello,
>>>>
>>>> I'd like to inquire about the status of the "dlm" package on Centos 8,
>>>> which is required for using 'lvmlockd', replacement of 'clvmd'.
>>>> I also asked on #centos irc channel and was directed to this mailing list
>>>> There is a corresponding bug ticket [2] for this issue for quite some
>>>> time, but since the end-of-life of CentOS 6 grows closer, some people
>>>> would like to replace their CentOS 6 Cluster with a CentOS 8 one, which
>>>> is why I ask on this mailing list now.
>>>>
>>>> With the release of CentOS 8.0 it seems there were some issues with
>>>> HighAvailability in general [1], but seem to have been resolved with
>>>> CentOS 8.1.
>>>>
>>>> However, as already mentioned there is a separate ticket [2], for the
>>>> dlm package, which is unresolved as far ( 2020-08-25, Centos8.2 ) as i
>>>> am aware.
>>>> This prevents the use of clustered lvm and gfs2 out of the box, not an
>>>> uncommon use when configuring a HA Cluster, also described by RedHat
>>>> documentation [3].
>>>> In that tickets' conversation, it is mentioned that "that package is not
>>>> in RHEL .. we have released what is in RHEL", however someone else
>>>> seemed to have been in contact with RedHat and received information that
>>>> "...this package is in fact part of a RedHat repository and then CentOS
>>>> members should be able to take a look into it again...".
>>>>
>>>> I'd also like to bring attention to the following explicitly:
>>>> * dlm-lib and dlm seem to be built from the same source rpm, dlm-lib is
>>>> available while dlm is not.
>>>> * apparently at some point in time dlm could be downloaded from koji
>>>> [4], but no more. For testing purposes we built dlm ourselves, locally
>>>> as well as on copr [5], which seems to work thus far.
>>>> * fedora (however much this might mean) provides dlm.
>>>> * It might just be a configuration error on the build system, if I
>>>> understood correctly, there was/is larger amounts of restructuring. Also
>>>> see chders' post from 2020-08-21 [2], which provides a possible
>>>> explanation and solution.
>>>>
>>>> For completeness, you should be able reproduce the absence of that
>>>> package with:
>>>> "yum --disablerepo='*'
>>>> --enablerepo=BaseOS,AppStream,HighAvailability,epel,cr,centosplus,PowerTools,Devel,extras,fasttrack
>>>> list available | grep dlm"
>>>> or simply attempt to
>>>> "yum install dlm"
>>>> on your CentOS 8.x Installation.
>>>>
>>>> Therefore, I would like to ask:
>>>> Is this an error on my end, am I doing something wrong or missing a
>>>> configuration?
>>>> If no, is there actually any political/technical/administrative/law
>>>> based reason for the unavailability of the "dlm" package?
>>>> If no, according to recent posts on the ticket [2], there might be a
>>>> rather simple solution (simplified, declaring the package to be included
>>>> in a repository), is it valid and who could do this if applicable?
>>>>
>>>> with best regards
>>>> Theodor Mittermair
>>>> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D4801&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=1uu0JPTCRCiVMxMHBBN63ga7FvXxdtesvTrXNZddCHA%3D&amp;reserved=0>
>>>> [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16553&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=IQaAl6qEjkwVWWOrHwnWSVtORrtXIJDm%2FT3tPSW3ME8%3D&amp;reserved=0
>>>> [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.centos.org%2Fview.php%3Fid%3D16939&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=g1S0BaGZ89XqyzWFfszbL35Wv2j%2FGn%2BZQ%2FBTcuE1zUM%3D&amp;reserved=0
>>>> [3]
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Faccess.redhat.com%2Fdocumentation%2Fen-us%2Fred_hat_enterprise_linux%2F8%2Fhtml%2Fconfiguring_and_managing_high_availability_clusters%2Fassembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=c95tVsARRd28rVmKmVupiiHniHJchfvM63zzaRu9LGQ%3D&amp;reserved=0
>>>> [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkoji.mbox.centos.org%2Fkoji%2Fbuildinfo%3FbuildID%3D145&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=q5V2nTWqkmU443YpeB%2FMElLxUD%2FHNPaae4wQO5zN304%3D&amp;reserved=0
>>>> [5] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcopr.fedorainfracloud.org%2Fcoprs%2Fastra%2Fdlm%2F&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=xgzIL%2F3XGXJ0AfKrc0DPQSRPT9S%2BvZ60vUyZj5ZAa2M%3D&amp;reserved=0
>>>>
>>>>
>>>> _______________________________________________
>>>> CentOS-devel mailing list
>>>> CentOS-devel at centos.org
>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fmailman%2Flistinfo%2Fcentos-devel&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=uMuUaWbyldLVlEjtYFzufdfrqGGvl4smxnp%2FwWQSYxI%3D&amp;reserved=0
>>>>
>>> Hi Folks,
>>>
>>> Some clarity will follow on how we plan to deliver Addon repositories
>>> like ResilientStorage, HighAvailability and NFV.
>>>
>>> Because of Red Hat???s desire to develop Addons along with the next minor
>>> release of RHEL our plan is to enable ResilientStorage and NFV in CentOS
>>> Stream for direct consumption.
>>>
>>> If you think a package belongs in another repository, we encourage you
>>> to open a CentOS Stream bugzilla to discuss with RHEL maintainers:
>>>
>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fenter_bug.cgi%3Fproduct%3DRed%2520Hat%2520Enterprise%2520Linux%25208%26version%3DCentOS%2520Stream&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=2qY4lAm%2FnhxrK%2FpUd33s7NWayvIjOuk2cr6ZFLcYRYA%3D&amp;reserved=0
>>>
>>> We do not plan to expand the portfolio of Addons for CentOS Linux.
>>>
>>> If there is a group of interested folks who wish to maintain extra
>>> content built against CentOS Linux, you may apply for a Special Interest
>>> Group: https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.centos.org%2FSIGGuide&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=wn2IhVrMpgmcy6BpWZWCf1mL0TV9CVa2Ih%2BV4ki%2F%2BKI%3D&amp;reserved=0
>>>
>>> Cheers!
>>> --Brian
>>
>> My apologies as I just subscribed to this list, I'll likely break the thread up. I did my best to contain relevance above.
>>
>> First question, the statement ""...Resilient Storage is not base...". There has been a shift from 7 to 8 that I don't understand. RHEL 7 provides dlm in ResilientStorage, then CentOS 7 provides dlm in base [1]. The dlm package is still part of ResilientStorage in RHEL 8, but can't be provided?  I wasn't able to find any answer to why that was changed. Can you provide any insight to the shift?
>>
>> Second question, the current advice seems to be "dlm will be in centos-stream and you should use that." However, tdawson made a pretty explicit statement: "If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem."[2] These statements appear contradictory.
>>
>> Just trying to piece this all together so I can explain to my peers the business and community decisions going on here.
>>
>> Currently someone that set up a cluster with gfs2 in 7 can't do the same thing in 8 due to the dlm package missing. That is a loss of functionality and seems to indicate it's a bug or intentional reduction in feature set.
> 
> Yes, it is different than CentOS Linux 7.  I'm sorry, that is just the
> way it is.  If it were up to me, I would push it .. it is not up to me.
> 
>>
>> If I'm misunderstanding any of this please educate me.
>>
> 
> It has already been stated that we will bot be putting the addon items
> in CentOS Linux .. just in Stream.
> 
> You have to test and decide what you will use.
> 
>> Thank you,
>> Judd
>>
>> [1]??https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmirror.centos.org%2Fcentos-7%2F7%2Fos%2Fx86_64%2FPackages%2Fdlm-4.0.7-1.el7.x86_64.rpm&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=u3sSGfZQKek5SRYDzhjSWcXWHxX7nDMUjilu%2FQixhDI%3D&amp;reserved=0
>> [2]??https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.centos.org%2Fpipermail%2Fcentos-devel%2F2020-July%2F037034.html&amp;data=02%7C01%7Cjudd.obannon%40rackspace.com%7C95b03022065d4215a0cf08d84b7d325f%7C570057f473ef41c8bcbb08db2fc15c2b%7C0%7C0%7C637342349428182226&amp;sdata=AOu1u%2B5Ss6GccBiNKDVkLL0dsgjWg4szSKCRO6dU6Ds%3D&amp;reserved=0
> 
> 
> One further question for further clarification and us to plan how this might work in the future: Currently the HA (HighAvailability) addon is provided. Should we plan for that to be removed as a great deal of the rpms are in common between HA and RS? 
> 
> Thank you,
> 
> Judd 
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
> 

We will continue delivering the HighAvailability addon in CentOS Linux 8

--Brian



From andyjohnhall at gmail.com  Fri Aug 28 23:05:46 2020
From: andyjohnhall at gmail.com (Andy Hall)
Date: Sat, 29 Aug 2020 00:05:46 +0100
Subject: [CentOS-devel] plasma has moved from epel into playground causing
	update conflicts
Message-ID: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>

Can the below be fixed ? I guess this package should not be in both repos...

# yum update
Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST.
Error:
 Problem 1: package
plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install the best update candidate for package
plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64
  - cannot install the best update candidate for package
gpsd-libs-3.19-4.el8.1.x86_64
 Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
and gpsd-libs-3.19-4.el8.1.x86_64
  - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and
gpsd-libs-3.18.1-2.epel8.playground.1.x86_64
  - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64
requires libgps.so.24()(64bit), but none of the providers can be
installed
  - package plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64
requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground,
but none of the providers can be installed
  - cannot install the best update candidate for package
plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64

# yum info plasma-workspace-geolocation
Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST.
Installed Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.el8
Architecture : x86_64
Size         : 206 k
Source       : plasma-workspace-5.18.4.1-2.el8.src.rpm
Repository   : @System
>From repo    : epel
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.

Available Packages
Name         : plasma-workspace-geolocation
Version      : 5.18.4.1
Release      : 2.epel8.playground
Architecture : x86_64
Size         : 87 k
Source       : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm
Repository   : epel-playground
Summary      : Plasma5 geolocation components
URL          : https://cgit.kde.org/plasma-workspace.git
License      : GPLv2+
Description  : Plasma5 geolocation components.


From leonfauster at googlemail.com  Fri Aug 28 23:15:15 2020
From: leonfauster at googlemail.com (Leon Fauster)
Date: Sat, 29 Aug 2020 01:15:15 +0200
Subject: [CentOS-devel] plasma has moved from epel into playground
 causing update conflicts
In-Reply-To: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
References: <CAOp5WB7FZN347iBj1BA2B6NAAms+7zRrm+YGyba=+3eJ1p7NdQ@mail.gmail.com>
Message-ID: <888708fa-c472-ca6c-e741-4d46483328e1@gmail.com>

Am 29.08.20 um 01:05 schrieb Andy Hall:
> Can the below be fixed ? I guess this package should not be in both repos...

should be directed to epel-devel at lists.fedoraproject.org

--
Leon



From nkadel at gmail.com  Sun Aug 30 18:10:56 2020
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2020 14:10:56 -0400
Subject: [CentOS-devel] Centos 8.x, dlm Package unavailable
In-Reply-To: <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
References: <SN1PR20MB20788C306515F665E6FA610D96520@SN1PR20MB2078.namprd20.prod.outlook.com>
 <47b71a25-c46c-9c72-85cc-61ef3f7bd090@centos.org>
 <BL0PR20MB206776B92E3D6F7D23E62E8796520@BL0PR20MB2067.namprd20.prod.outlook.com>
 <c6527883-3b48-878d-7c48-01211adf7f0d@redhat.com>
Message-ID: <CAOCN9rx=t4uzDmYE3O6P44E57FN5bZ+gBEst8u4UELZnrY_JHQ@mail.gmail.com>

On Fri, Aug 28, 2020 at 6:05 PM Brian Stinson <bstinson at redhat.com> wrote:

> We will continue delivering the HighAvailability addon in CentOS Linux 8
>
> --Brian

This is good. Can we get it into the "mock" configurations for CentOS
8, available if not enabled by default?