On Thu, Aug 19, 2021 at 2:42 PM Steven Rosenberg via CentOS-devel centos-devel@centos.org wrote:
How do I follow errata on patches to Stream 8?
You don't. CentOS will not provide erratum information.
Aug 19, 2021, 11:44 AM by ngompa13@gmail.com:
On Thu, Aug 19, 2021 at 2:42 PM Steven Rosenberg via CentOS-devel centos-devel@centos.org wrote:
How do I follow errata on patches to Stream 8?
You don't. CentOS will not provide erratum information.
-- 真実はいつも一つ！/ Always, there's only one truth!
Even emails like I see for for CentOS 7 would be ok.
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
John
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
The two dynamic parts are an index number (the 886 in the centos rpm and 11822 in the rhel rpm) and a git commit id (c9a8d9ad and c9a8d9ad).
There does not exist a way to cross reference those items to each other and they will never be the same as they are being built on two different closed systems.
I asked for community help to be able to possibly figure out a way to cross reference these items and I got zero response. It must then not be very important to the CentOS Community.
That is for actual CentOS Linux 8 and just modularity differences. In Stream 8 there are other differences. Some number of packages, besides modules, will be exactly the same between RHEL 8.4 and RHEL 8.5 .. usually around 80%-90% .. so that leaved 10-20% of packages that are different between CentOS Stream 8 and RHEL 8 at any point in time.
The bottom line is .. zero modules and about 10-20% of packages do not match up with the errata at any given time for Stream.
If someone wants audited packages with software assurance .. Red Hat has thousands of people who do that, who create errata metadata and publish it .. that is one of the things you are paying for with RHEL :)
To reiterate .. IF I had the information available for CentOS Linux 8, I would have provided it. Much less of it will be relevant to CentOS Stream 8 than was relevant to CentOS Linux 8.
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
On 8/20/21 11:34 AM, Neal Gompa wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
The problem is that theoretically .. the same ENV could be in more than one module. That would make this problematic for items that might the same ENV and possibly a different release.
You would also need something that queried several git modulemd items and did compares, etc.
And now that is a moot point as we are at about 3 months left in the CentOS Linux 8 lifetime. And these things are not at all relevant for most of stream.
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
josh
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
The idea is not new: I've talked to the CentOS project folks about it many times in the past. They get *extremely* uncomfortable and tell me that they can't do it for various reasons even though they want to. It's one of the biggest complaints everyone has about the project. It's made worse by the fact that none of the ecosystem tooling for updates works in any useful manner without updateinfo. RPM changelogs are no substitute because no automation works with that. You know that as well as everyone else here.
-- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: > Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie
You have clearly never worked on making a change to a RHEL package :). I will promise you that there are already a significant number of steps that developers must do to even get to the point where they can file an MR. Putting more process and tooling and hurdles in their way before the code even gets into RHEL is absolutely a resource problem and I am not going to sign them up to do that. If anything, we're trying to simplify even though many will tell you it doesn't look like that.
I know you meant that with good intention, but it's easy to read it as "there's no resourcing problem because someone else has to do the work."
the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
The idea is not new: I've talked to the CentOS project folks about it many times in the past. They get *extremely* uncomfortable and tell me that they can't do it for various reasons even though they want to. It's one of the biggest complaints everyone has about the project. It's made worse by the fact that none of the ecosystem tooling for updates works in any useful manner without updateinfo. RPM changelogs are no substitute because no automation works with that. You know that as well as everyone else here.
Producing that information isn't only about tooling, and the fact that people would immediately rely on it for automation makes it difficult to suggest anyone else doing it on the side is a viable solution. If it's wrong, that has bad consequences. I'd certainly be against it under the project umbrella if it wasn't part of the official delivery anyway.
I still question the utility of it though. It's a continuous delivery model. You have to update. Want to know if you have all available bug fixes? Update. If your bug isn't fixed, it doesn't change the fact that you have all *available* bug fixes. There are no batches or releases. It's called Stream for a reason.
josh
On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote: > On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: >> Even emails like I see for for CentOS 7 would be ok. > > Considering that people have had nearly 2 years to get such notices out > for 8 and it's still not happened I wouldn't hold my breath if I were > you. >
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie
You have clearly never worked on making a change to a RHEL package :). I will promise you that there are already a significant number of steps that developers must do to even get to the point where they can file an MR. Putting more process and tooling and hurdles in their way before the code even gets into RHEL is absolutely a resource problem and I am not going to sign them up to do that. If anything, we're trying to simplify even though many will tell you it doesn't look like that.
I know you meant that with good intention, but it's easy to read it as "there's no resourcing problem because someone else has to do the work."
I certainly have made changes to RHEL packages. My name exists in changelogs and commits in enough packages in RHEL and CentOS Stream that I think that would be an unfair characterization. :)
I'm aware of most of the steps for making package changes in RHEL, and I already am aware that packagers for RHEL have to go through the effort of declaring what an update is, what it's for, and whether it requires relogin/reboot to fully apply. These are the core properties that are defined in updateinfo. Defining them to push a build in CentOS Stream is something that I don't think is an unreasonable ask. It's the same thing we ask community folks in Fedora to do, after all.
the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
The idea is not new: I've talked to the CentOS project folks about it many times in the past. They get *extremely* uncomfortable and tell me that they can't do it for various reasons even though they want to. It's one of the biggest complaints everyone has about the project. It's made worse by the fact that none of the ecosystem tooling for updates works in any useful manner without updateinfo. RPM changelogs are no substitute because no automation works with that. You know that as well as everyone else here.
Producing that information isn't only about tooling, and the fact that people would immediately rely on it for automation makes it difficult to suggest anyone else doing it on the side is a viable solution. If it's wrong, that has bad consequences. I'd certainly be against it under the project umbrella if it wasn't part of the official delivery anyway.
I still question the utility of it though. It's a continuous delivery model. You have to update. Want to know if you have all available bug fixes? Update. If your bug isn't fixed, it doesn't change the fact that you have all *available* bug fixes. There are no batches or releases. It's called Stream for a reason.
That doesn't mean I shouldn't have the ability to configure dnf-automatic to apply all updates automatically that don't require relogin and reboot and then have it email me to notify me for updates that *do* require that so I can schedule time to actually go and apply it.
On Fri, Aug 20, 2021, 5:16 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 4:09 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 3:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com
wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes <
johnny@centos.org> wrote:
> > On 8/19/21 11:21 PM, John R. Dennison wrote: > > On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg
via CentOS-devel wrote:
> >> Even emails like I see for for CentOS 7 would be ok. > > > > Considering that people have had nearly 2 years to get such
notices out
> > for 8 and it's still not happened I wouldn't hold my breath
if I were
> > you. > > > > I would provide the information if i could, it is not easy to
do because
> of modularity. > > The thing that builds el8 modules is called MBS .. if you look
at MBS
> operations, one of the things that gets generated as part of
the
> filename. Here is an example: > > https://koji.mbox.centos.org/koji/buildinfo?buildID=18783 > > Part of the file name is dynamic, created by MBS at build
time. For
> example, one of the Source RPM filenames generated is: > > runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm > > That is not it's filename in RHEL8. In RHEL 8 .. the filename
is:
> > runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm > > There is no easy way to figure out the file names that match
up between
> the two systems. I took me 15 minutes to figure out that one
filename,
> this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist,
which
results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally,
when
the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd
commits
between RHEL and CentOS, you have enough baseline references to
be
able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported
modulemd
before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around
providing
errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project.
If
there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through
the
CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day
basis.
Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie
You have clearly never worked on making a change to a RHEL package :). I will promise you that there are already a significant number of steps that developers must do to even get to the point where they can file an MR. Putting more process and tooling and hurdles in their way before the code even gets into RHEL is absolutely a resource problem and I am not going to sign them up to do that. If anything, we're trying to simplify even though many will tell you it doesn't look like that.
I know you meant that with good intention, but it's easy to read it as "there's no resourcing problem because someone else has to do the work."
I certainly have made changes to RHEL packages. My name exists in changelogs and commits in enough packages in RHEL and CentOS Stream that I think that would be an unfair characterization. :)
I'm aware of most of the steps for making package changes in RHEL, and I already am aware that packagers for RHEL have to go through the effort of declaring what an update is, what it's for, and whether it requires relogin/reboot to fully apply.
These are the core properties
that are defined in updateinfo. Defining them to push a build in CentOS Stream is something that I don't think is an unreasonable ask. It's the same thing we ask community folks in Fedora to do, after all.
We don't ask the Fedora community to do it twice through two different tools though. Again, I'm not adding more process to an already arduous process.
Also, it's a case of frequency as well. An errata in RHEL has to be finalized officially once before it's released. Some maintainers do it multiple times as they go, but many do not. Bugs attached, notes updated, etc need to be completed before GA, every 6 months. Your proposal would require them to do this for every build. That's expensive.
the gating into the auto-release criteria. The Fedora CI folks were
already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
The idea is not new: I've talked to the CentOS project folks about it many times in the past. They get *extremely* uncomfortable and tell me that they can't do it for various reasons even though they want to. It's one of the biggest complaints everyone has about the project. It's made worse by the fact that none of the ecosystem tooling for updates works in any useful manner without updateinfo. RPM changelogs are no substitute because no automation works with that. You know that as well as everyone else here.
Producing that information isn't only about tooling, and the fact that people would immediately rely on it for automation makes it difficult to suggest anyone else doing it on the side is a viable solution. If it's wrong, that has bad consequences. I'd certainly be against it under the project umbrella if it wasn't part of the official delivery anyway.
I still question the utility of it though. It's a continuous delivery model. You have to update. Want to know if you have all available bug fixes? Update. If your bug isn't fixed, it doesn't change the fact that you have all *available* bug fixes. There are no batches or releases. It's called Stream for a reason.
That doesn't mean I shouldn't have the ability to configure dnf-automatic to apply all updates automatically that don't require relogin and reboot and then have it email me to notify me for updates that *do* require that so I can schedule time to actually go and apply it.
The list that sets needs reboot via errata is literally hard coded to a few packages, and we have other tools being introduced that will actually measure this via runtime heuristics via dnf plugins. I'm happy to just give you the list, (kernel, glibc, systemd, maybe one or two others) and you're welcome to use the improved tools already in the distro.
josh
On 8/20/21 2:35 PM, Neal Gompa wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: > Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
It's not Bodhi vs. another tool in this case. The reason we don't deploy an update manager in Stream is that we want to avoid an artificial gate before the RHEL process begins. In practice, CentOS Stream builds are promoted through the workflow in lockstep with their RHEL counterparts. This means CentOS Stream builds are subject to the fate of the RHEL gating results and other bits of paperwork and process that maintainers must go through to release a build into RHEL proper. If any of that RHEL process leads to a NAK we want to NAK a build in Stream too and we'd be overriding any pre-prepared updates in a hypothetical Stream update manager anyways.
The idea is not new: I've talked to the CentOS project folks about it many times in the past. They get *extremely* uncomfortable and tell me that they can't do it for various reasons even though they want to. It's one of the biggest complaints everyone has about the project. It's made worse by the fact that none of the ecosystem tooling for updates works in any useful manner without updateinfo. RPM changelogs are no substitute because no automation works with that. You know that as well as everyone else here.
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
--Brian
On Fri, Aug 20, 2021 at 4:19 PM Brian Stinson bstinson@redhat.com wrote:
On 8/20/21 2:35 PM, Neal Gompa wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote: > On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: >> Even emails like I see for for CentOS 7 would be ok. > > Considering that people have had nearly 2 years to get such notices out > for 8 and it's still not happened I wouldn't hold my breath if I were > you. >
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
It's not Bodhi vs. another tool in this case. The reason we don't deploy an update manager in Stream is that we want to avoid an artificial gate before the RHEL process begins. In practice, CentOS Stream builds are promoted through the workflow in lockstep with their RHEL counterparts. This means CentOS Stream builds are subject to the fate of the RHEL gating results and other bits of paperwork and process that maintainers must go through to release a build into RHEL proper. If any of that RHEL process leads to a NAK we want to NAK a build in Stream too and we'd be overriding any pre-prepared updates in a hypothetical Stream update manager anyways.
Maybe I said this wrong, but I think that this use-case is something that Bodhi supports fine. Configuring Bodhi to respond to RHEL gating and only push when RHEL pushes is something that Bodhi could do by listening to whatever pushes RHEL builds. Having the RHEL NAK block a CentOS Stream build seems reasonable, just as the other way would too. You should be able to enforce that they land in tandem. Not reusing Bodhi for this seems like a bad idea, especially after all the effort to implement this capability in there for Fedora CI on Rawhide builds.
On 8/20/21 4:31 PM, Neal Gompa wrote:
On Fri, Aug 20, 2021 at 4:19 PM Brian Stinson bstinson@redhat.com wrote:
On 8/20/21 2:35 PM, Neal Gompa wrote:
On Fri, Aug 20, 2021 at 2:41 PM Josh Boyer jwboyer@redhat.com wrote:
On Fri, Aug 20, 2021 at 1:37 PM Carl George carl@redhat.com wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote: > > On 8/19/21 11:21 PM, John R. Dennison wrote: >> On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote: >>> Even emails like I see for for CentOS 7 would be ok. >> >> Considering that people have had nearly 2 years to get such notices out >> for 8 and it's still not happened I wouldn't hold my breath if I were >> you. >> > > I would provide the information if i could, it is not easy to do because > of modularity. > > The thing that builds el8 modules is called MBS .. if you look at MBS > operations, one of the things that gets generated as part of the > filename. Here is an example: > > https://koji.mbox.centos.org/koji/buildinfo?buildID=18783 > > Part of the file name is dynamic, created by MBS at build time. For > example, one of the Source RPM filenames generated is: > > runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm > > That is not it's filename in RHEL8. In RHEL 8 .. the filename is: > > runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm > > There is no easy way to figure out the file names that match up between > the two systems. I took me 15 minutes to figure out that one filename, > this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
information at the end. So there is some mapping. Additionally, when the RPMs are imported from RHEL into CentOS, the original NVR is present as a tag. Ignoring transmodrifier remapping modulemd commits between RHEL and CentOS, you have enough baseline references to be able to connect the dots because the RHEL dist-git shorthash is present in the import tag, which would exist in the imported modulemd before transmodification.
That process could be automated, but I was never particularly motivated to do it because of the historical attitude around providing errata for CentOS users like Fedora users get.
I'm not aware of any policy against allowing this in the project. If there is I hope board members will speak up and clarify that. I suspect it's more of a resource thing than anything.
I think lack of awareness of a publicly documented policy against allowing this in the project is likely true, but also irrelevant. We don't have a policy against allowing a FreeBSD kernel or using Ubuntu's version of gcc, yet we wouldn't do those. In the absence of meticulously detailed bylaws, we have historical precedent setting defacto policy. I don't expect this to change.
That being said, an update metadata mechanism for CentOS Stream is certainly hampered by resource constraints both in terms of tooling and in terms of the impact on the people developing the OS through the CentOS Stream project. For a continuously developed and continuously delivered OS, we expect a large amount of churn on a day to day basis. Updates are a regular occurence, and they're important either because of fixes or because of new features. Changes are documented in MRs, RPM changelogs, and referenced bugs for those interested.
It's always been possible to have updateinfo generated as build submissions go through. That's literally how it's done in Fedora with Bodhi.
It's not that much of a stretch to say "deploy Bodhi, make voting advisory or turn it off, and have builds submitted through it with the right information and auto-release based on gating checks". That structured data can be pulled in and used for Red Hat update advisories internally too, which simplifies the pipeline to validate and release updates. Or if you have a beef against Bodhi, then why not use the tooling Scientific Linux created to make updateinfo? Troy and Pat are very familiar with it, and it's publicly available: https://pagure.io/python-Updateinfo
Okay, let's say we can't do it for CentOS Stream 8 because of resource constraints. Well then, what about CentOS Stream 9, where the RHEL developers themselves are submitting the builds? There's no logical resourcing problem there. Deploy Bodhi for update submissions and tie the gating into the auto-release criteria. The Fedora CI folks were already doing that for Fedora Rawhide, so it's no stretch to have it for CentOS Stream too.
It's not Bodhi vs. another tool in this case. The reason we don't deploy an update manager in Stream is that we want to avoid an artificial gate before the RHEL process begins. In practice, CentOS Stream builds are promoted through the workflow in lockstep with their RHEL counterparts. This means CentOS Stream builds are subject to the fate of the RHEL gating results and other bits of paperwork and process that maintainers must go through to release a build into RHEL proper. If any of that RHEL process leads to a NAK we want to NAK a build in Stream too and we'd be overriding any pre-prepared updates in a hypothetical Stream update manager anyways.
Maybe I said this wrong, but I think that this use-case is something that Bodhi supports fine. Configuring Bodhi to respond to RHEL gating and only push when RHEL pushes is something that Bodhi could do by listening to whatever pushes RHEL builds. Having the RHEL NAK block a CentOS Stream build seems reasonable, just as the other way would too. You should be able to enforce that they land in tandem. Not reusing Bodhi for this seems like a bad idea, especially after all the effort to implement this capability in there for Fedora CI on Rawhide builds.
The thing that pushes RHEL builds is already the thing that influences when Stream builds move along in the workflow.
Let's break this down by use-case, though:
"I want to comment on a build before it makes it into RHEL" => Use the open bugzilla or comment on the open merge request
"I want to try out a build before it makes it on the mirrors" => Pull from the buildsystem or from the development composes
"I want to test a package before a build is made" => We're working on expanding pre-merge and post-merge CI. Note: this is a much better place to influence and provide feedback before a build makes it into the process than an update/errata
Running an update manager in Stream would be extra work, when we want to encourage the use-cases to be addressed elsewhere anyways.
--Brian
On 20.08.21 19:36, Carl George wrote:
On Fri, Aug 20, 2021 at 11:35 AM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Aug 20, 2021 at 12:28 PM Johnny Hughes johnny@centos.org wrote:
On 8/19/21 11:21 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Considering that people have had nearly 2 years to get such notices out for 8 and it's still not happened I wouldn't hold my breath if I were you.
I would provide the information if i could, it is not easy to do because of modularity.
The thing that builds el8 modules is called MBS .. if you look at MBS operations, one of the things that gets generated as part of the filename. Here is an example:
https://koji.mbox.centos.org/koji/buildinfo?buildID=18783
Part of the file name is dynamic, created by MBS at build time. For example, one of the Source RPM filenames generated is:
runc-1.0.0-74.rc95.module_el8.4.0+886+c9a8d9ad.src.rpm
That is not it's filename in RHEL8. In RHEL 8 .. the filename is:
runc-1.0.0-74.rc95.module+el8.4.0+11822+6cc1e7d7.src.rpm
There is no easy way to figure out the file names that match up between the two systems. I took me 15 minutes to figure out that one filename, this does not scale.
Everything prior to ".module" should be unique, identifiable, and identical between RHEL and CentOS. MBS whacks %dist to add MBS
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
and BTW
RH uses the plus sign after module and before %dist :
RH:qemu-img-4.2.0-48.module+el8.4.0+11909+3300d70f.3.x86_64 C8:qemu-img-4.2.0-48.module_el8.4.0+885+5e18b468.3.x86_64
is this intentional?
-- Leon
On Sat, 21 Aug 2021 at 08:44, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:
On 20.08.21 19:36, Carl George wrote:
Not exactly. Sometimes RHEL maintainers add digits after %dist, which results in NVRs like foo-1.0-1.module_el8.4.0+123+a0a0a0a0.1. It's not impossible to parse, but it's much more complicated that just ignoring everything after ".module".
and BTW
RH uses the plus sign after module and before %dist :
RH:qemu-img-4.2.0-48.module+el8.4.0+11909+3300d70f.3.x86_64 C8:qemu-img-4.2.0-48.module_el8.4.0+885+5e18b468.3.x86_64
is this intentional?
As far as I know it is intentional to make it clearer to parsing tools that there was a difference. If they used a _ that would break some existing tools and if they used . (dot) it would break a lot more. Using the + was found to break the least of the ones that were being looked at in Fedora 27? days when this was being set up. [Basically various versions were tried, various tools were tested and all kinds of fun and 'laughter' when you find that your Nagios, corporate antivirus, etc now assumes your architecture is .885 versus .x86_64 or some other item.
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Sorry for the double reply but I was reminded of this after I post my previous reply.
While not a perfect solution there exists an rss feed of all updates for 7, 8 and 8stream at https://feeds.centos.org/ that Fabian was nice enough to set up a couple years ago.
Perhaps this can continue for 9stream moving forward.
John
On 8/20/21 12:25 AM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Sorry for the double reply but I was reminded of this after I post my previous reply.
While not a perfect solution there exists an rss feed of all updates for 7, 8 and 8stream at https://feeds.centos.org/ that Fabian was nice enough to set up a couple years ago.
A year or so ago I mentioned this script - https://github.com/rbowen/centos-community-tools/blob/main/scripts/rss_updat... - which consumes (some of) those RSS feeds and generates some reports of what's new in a couple of different formats.
Caveat: I don't know if it still works, but I presume it does - RSS is RSS.
Caveat 2: The RSS contains the latest N updates. I never definitely determined what N is. So if N+1 updates were delivered at any given period between running the script, you'd miss 1 of them.
Caveat 3: I don't know what the future plans are for this service, and am not making any promises.
On Fri, 2021-08-20 at 09:33 -0400, Rich Bowen wrote:
A year or so ago I mentioned this script - https://github.com/rbowen/centos-community-tools/blob/main/scripts/rss_updat...
- which consumes (some of) those RSS feeds and generates some reports
of what's new in a couple of different formats.
Caveat: I don't know if it still works, but I presume it does - RSS is RSS.
Caveat 2: The RSS contains the latest N updates. I never definitely determined what N is. So if N+1 updates were delivered at any given period between running the script, you'd miss 1 of them.
Caveat 3: I don't know what the future plans are for this service, and am not making any promises.
Rich, thank you for that script. I installed python3-feedparser from the repo, and then it ran perfectly. It makes the RSS very readable.
On Thu, Aug 19, 2021 at 9:25 PM John R. Dennison jrd@gerdesas.com wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Sorry for the double reply but I was reminded of this after I post my previous reply.
While not a perfect solution there exists an rss feed of all updates for 7, 8 and 8stream at https://feeds.centos.org/ that Fabian was nice enough to set up a couple years ago.
Perhaps this can continue for 9stream moving forward.
Thanks for the link. This is a good way to keep an eye on it.
On 8/19/21 11:25 PM, John R. Dennison wrote:
On Fri, Aug 20, 2021 at 06:05:49AM +0200, Steven Rosenberg via CentOS-devel wrote:
Even emails like I see for for CentOS 7 would be ok.
Sorry for the double reply but I was reminded of this after I post my previous reply.
While not a perfect solution there exists an rss feed of all updates for 7, 8 and 8stream at https://feeds.centos.org/ that Fabian was nice enough to set up a couple years ago.
Perhaps this can continue for 9stream moving forward.
I don't know of any reason why it can't be used for Stream 9.
-
Brian Stinson -
Carl George -
John R. Dennison -
Johnny Hughes -
Josh Boyer -
Leon Fauster -
Neal Gompa -
Rich Bowen -
Stephen John Smoogen -
Steven R -
Steven Rosenberg -
Steven Rosenberg