11:22 p.m.
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
2:39 a.m.
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 (vitaly(a)easycoding.org)
8:48 a.m.
On Fri, Aug 16, 2019 at 12:40 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> 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
11:32 a.m.
On Fri, 16 Aug 2019 at 09:52, Troy Dawson <tdawson(a)redhat.com> wrote:
On Fri, Aug 16, 2019 at 12:40 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> 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.
6:56 a.m.
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
12:58 p.m.
On Sat, 17 Aug 2019 at 11:12, Kevin Kofler <kevin.kofler(a)chello.at> 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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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.
5:09 p.m.
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
8 a.m.
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
1707
days inactive
1708
days old
7 comments
5 participants
participants (5)
-
Kevin Kofler -
Richard Shaw -
Stephen John Smoogen -
Troy Dawson -
Vitaly Zaitsev