Re: Missing arches on EPEL 8 for LibRaw?
Stephen John Smoogen wrote: > One of the problems with the above plan was that koji decides whats > artifacts it will pull into its build root with a sort of hierarchy of > 'if I built it use it even if an external repo has a higher NVR'. > There are ways to get around that but they are meant to be temporary > and this would need to make them 'permanent'. Again not impossible but > it would take a lot of engineering time that would have to be balanced > against all the other projects we have been asked to complete. Would it work to just give the epel-limitedarch repo lower priority than upstream RHEL in Koji? Or would it then try to use the RHEL builds across all architectures and fail to find builds for the missing ones? Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
On Sat, 17 Aug 2019 at 11:12, Kevin Kofler wrote: > > Stephen John Smoogen wrote: > > So part of the reason for this is that the old method of trying to > > make this happen is broken. > > > > In EPEL-6 and EPEL-7 we would have a person who needed a package dep > > to rebuild the package in EPEL but with a slightly lower NVR to make > > it so we did not replace on the x86_64 platform whatever missing > > package there was. However what happens constantly is that those > > packages end up never getting updated so any updates in RHEL can cause > > CVE warnings or other problems. Or some packager who doesn't know this > > package can't be upgraded to the latest, does so.. and we have now > > broken customers on x86_64 with no way to 'fix them'. Since the ratio > > of x86_64 to the next major architecture is 100,000:1 that is a lot of > > boxes broken for some smaller set. > > > > So for EPEL-8 we are not allowing for the 'limited arch' packages. At > > this point if a package is not shipped across architectures, please > > use Exclusive Arch towards the ones it is shipped on'. > > Wouldn't the proper solution be to rebuild those packages by an automated > process (using just a manually maintained list of affected packages, and > then having a builder automatically watch for updates in RHEL and rebuilding > them for the additional architectures) and put them into some extra > epel-limitedarch repository? > > In other words, the proposal is to: > * not import those packages into EPEL dist-git at all, but rebuild them > directly from CentOS dist-git or wherever RHEL pushes the sources to > (any unwanted ExcludeArch/ExclusiveArch can be eradicated with sed), > * maintain only a list of source package names in EPEL, > * publish only the binary packages and only for the architectures not > shipped in RHEL, possibly in a repository separate from EPEL proper (but > which EPEL proper would require), > * do all of the above with an automated script, > * drag in the above repository in EPEL Koji in addition to RHEL. > Kevin, I know we have had some major disagreements, but I want to say I agree with the ideas above here. They would need some tweaking to meet other tools but the core is something I have thought about but never put in as many clear steps as above. Thank you for proposing them. The main stopping point is that EPEL release engineering is done on spare time and a lot of this needs more time that anyone has had to put towards it in the last 12 years. Most of the time we are working on 'what won't break Fedora releases while we make these changes to make EPEL work'. I know we haven't always succeeded at that, but it has been a major goal. [This isn't meant to be a pity me thing.. just a we are trying to make sure that Fedora comes first in what we do and we don't make anything that hurts that.] One of the problems with the above plan was that koji decides whats artifacts it will pull into its build root with a sort of hierarchy of 'if I built it use it even if an external repo has a higher NVR'. There are ways to get around that but they are meant to be temporary and this would need to make them 'permanent'. Again not impossible but it would take a lot of engineering time that would have to be balanced against all the other projects we have been asked to complete. I will see what I can do with the above and use it as a template for decisions. > I think this would avoid the error-prone manual process that was used in > EPEL 6 and 7 while still doing the needed package rebuilds. > > This process could even be adapted to also handle missing subpackages > (across all architectures), if the Code Ready Builder remains as incomplete > as it is now. The script would just have to be taught to publish only the > specific subpackages and throw away everything already published in RHEL. > > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
Stephen John Smoogen wrote: > So part of the reason for this is that the old method of trying to > make this happen is broken. > > In EPEL-6 and EPEL-7 we would have a person who needed a package dep > to rebuild the package in EPEL but with a slightly lower NVR to make > it so we did not replace on the x86_64 platform whatever missing > package there was. However what happens constantly is that those > packages end up never getting updated so any updates in RHEL can cause > CVE warnings or other problems. Or some packager who doesn't know this > package can't be upgraded to the latest, does so.. and we have now > broken customers on x86_64 with no way to 'fix them'. Since the ratio > of x86_64 to the next major architecture is 100,000:1 that is a lot of > boxes broken for some smaller set. > > So for EPEL-8 we are not allowing for the 'limited arch' packages. At > this point if a package is not shipped across architectures, please > use Exclusive Arch towards the ones it is shipped on'. Wouldn't the proper solution be to rebuild those packages by an automated process (using just a manually maintained list of affected packages, and then having a builder automatically watch for updates in RHEL and rebuilding them for the additional architectures) and put them into some extra epel-limitedarch repository? In other words, the proposal is to: * not import those packages into EPEL dist-git at all, but rebuild them directly from CentOS dist-git or wherever RHEL pushes the sources to (any unwanted ExcludeArch/ExclusiveArch can be eradicated with sed), * maintain only a list of source package names in EPEL, * publish only the binary packages and only for the architectures not shipped in RHEL, possibly in a repository separate from EPEL proper (but which EPEL proper would require), * do all of the above with an automated script, * drag in the above repository in EPEL Koji in addition to RHEL. I think this would avoid the error-prone manual process that was used in EPEL 6 and 7 while still doing the needed package rebuilds. This process could even be adapted to also handle missing subpackages (across all architectures), if the Code Ready Builder remains as incomplete as it is now. The script would just have to be taught to publish only the specific subpackages and throw away everything already published in RHEL. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
Stephen John Smoogen wrote: > So part of the reason for this is that the old method of trying to > make this happen is broken. > > In EPEL-6 and EPEL-7 we would have a person who needed a package dep > to rebuild the package in EPEL but with a slightly lower NVR to make > it so we did not replace on the x86_64 platform whatever missing > package there was. However what happens constantly is that those > packages end up never getting updated so any updates in RHEL can cause > CVE warnings or other problems. Or some packager who doesn't know this > package can't be upgraded to the latest, does so.. and we have now > broken customers on x86_64 with no way to 'fix them'. Since the ratio > of x86_64 to the next major architecture is 100,000:1 that is a lot of > boxes broken for some smaller set. > > So for EPEL-8 we are not allowing for the 'limited arch' packages. At > this point if a package is not shipped across architectures, please > use Exclusive Arch towards the ones it is shipped on'. Wouldn't the proper solution be to rebuild those packages by an automated process (using just a manually maintained list of affected packages, and then having a builder automatically watch for updates in RHEL and rebuilding them for the additional architectures) and put them into some extra epel-limitedarch repository? In other words, the proposal is to: * not import those packages into EPEL dist-git at all, but rebuild them directly from CentOS dist-git or wherever RHEL pushes the sources to (any unwanted ExcludeArch/ExclusiveArch can be eradicated with sed), * maintain only a list of source package names in EPEL, * publish only the binary packages and only for the architectures not shipped in RHEL, possibly in a repository separate from EPEL proper (but which EPEL proper would require), * do all of the above with an automated script, * drag in the above repository in EPEL Koji in addition to RHEL. I think this would avoid the error-prone manual process that was used in EPEL 6 and 7 while still doing the needed package rebuilds. This process could even be adapted to also handle missing subpackages (across all architectures), if the Code Ready Builder remains as incomplete as it is now. The script would just have to be taught to publish only the specific subpackages and throw away everything already published in RHEL. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
On Fri, 16 Aug 2019 at 09:52, Troy Dawson wrote: > > On Fri, Aug 16, 2019 at 12:40 AM Vitaly Zaitsev via devel > wrote: > > > > On 16.08.2019 6:22, Richard Shaw wrote: > > > I assume this is because LibRaw is available in RHEL but only for x86_64 > > > and ppc64le? > > > > The same as Pidgin and lots of other apps/libs. You need to add > > "ExclusiveArch: x86_64 ppc64le" in order to build your package successfully. > > > > This has been reported in the EPEL issues > https://pagure.io/epel/issue/66 (Graphical Libraries/Desktop missing > from RHEL8 aarch64 and s390x) > > I like the issue because it has a full list of the packages that are > only available on x86_64 and ppc64le. > Besides the full list of packages, I think the next important is the comment > > "I have been told that the RHEL team is aware of this problem, and > have several bugs open because of it. I have also been told that it > will not be fixed in RHEL 8.1. Let's hope for RHEL 8.2." > > So, yes, do the ExclusiveArch, but keep in the back of your mind that > this is only needed temporarily ... hopefully. > So part of the reason for this is that the old method of trying to make this happen is broken. In EPEL-6 and EPEL-7 we would have a person who needed a package dep to rebuild the package in EPEL but with a slightly lower NVR to make it so we did not replace on the x86_64 platform whatever missing package there was. However what happens constantly is that those packages end up never getting updated so any updates in RHEL can cause CVE warnings or other problems. Or some packager who doesn't know this package can't be upgraded to the latest, does so.. and we have now broken customers on x86_64 with no way to 'fix them'. Since the ratio of x86_64 to the next major architecture is 100,000:1 that is a lot of boxes broken for some smaller set. So for EPEL-8 we are not allowing for the 'limited arch' packages. At this point if a package is not shipped across architectures, please use Exclusive Arch towards the ones it is shipped on'. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
On Fri, Aug 16, 2019 at 12:40 AM Vitaly Zaitsev via devel wrote: > > On 16.08.2019 6:22, Richard Shaw wrote: > > I assume this is because LibRaw is available in RHEL but only for x86_64 > > and ppc64le? > > The same as Pidgin and lots of other apps/libs. You need to add > "ExclusiveArch: x86_64 ppc64le" in order to build your package successfully. > This has been reported in the EPEL issues https://pagure.io/epel/issue/66 (Graphical Libraries/Desktop missing from RHEL8 aarch64 and s390x) I like the issue because it has a full list of the packages that are only available on x86_64 and ppc64le. Besides the full list of packages, I think the next important is the comment "I have been told that the RHEL team is aware of this problem, and have several bugs open because of it. I have also been told that it will not be fixed in RHEL 8.1. Let's hope for RHEL 8.2." So, yes, do the ExclusiveArch, but keep in the back of your mind that this is only needed temporarily ... hopefully. Troy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Missing arches on EPEL 8 for LibRaw?
On 16.08.2019 6:22, Richard Shaw wrote: > I assume this is because LibRaw is available in RHEL but only for x86_64 > and ppc64le? The same as Pidgin and lots of other apps/libs. You need to add "ExclusiveArch: x86_64 ppc64le" in order to build your package successfully. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: Missing arches on EPEL 8 for LibRaw?
(Moving to EPEL list) On 8/15/19 10:22 PM, Richard Shaw wrote: I assume this is because LibRaw is available in RHEL but only for x86_64 and ppc64le? So I'm assuming there is some sort of procedure to build only for s390x and aarch64 for EPEL? Yes, many libs appear to be missing on those arches. ExcludeArch: aarch64 s390x seems to be the thing to do. We have a limited arch policy for EPEL6/7, but I'm not sure if we want to continue that for EPEL8. https://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Missing arches on EPEL 8 for LibRaw?
I assume this is because LibRaw is available in RHEL but only for x86_64 and ppc64le? So I'm assuming there is some sort of procedure to build only for s390x and aarch64 for EPEL? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
