On Tue, Dec 13, 2022 at 12:39 PM Ken Dreyer <kdreyer@xxxxxxxxxx> wrote:
This is an example of why we should move to el9-only (and drop el8
support).
RHEL8, C8, and Stream8 usage numbers are still (anecdotally by CentOS and Red Hat peeps) much higher than RHEL9/Stream9 numbers. If you want people using & testing it upstream, it needs to be built or buildable on el8. If you don't want to build it for el8 in teuthology, e.g., that's outside my area of interest and/or responsibility. Do whatever you want there.
AFAICT the utf8proc-epel package — which provides utf8proc-devel for epel8 — seems to have been allowed to fall behind what's in RHEL. Perhaps in anticipation of retiring it due to an apparent misunderstanding of what is in RHEL8. (A mistake?)
We should be good community members and the the bug fixed in epel8, instead of using it as justification for yanking support for el8. Which would be premature IMO.
It's in RHEL 9 in
https://bugzilla.redhat.com/show_bug.cgi?id=2041057
Uh, yes. As I already indicated in my earlier email. But it's in AppStream and CodeReadyBuilder. Not the base.
And utf8proc is in RHEL8, also in AppStream (in a module). And AFAICT we need to resurrect utf8proc-devel in epel8 and get it updated to the same version that's in RHEL and Stream8.
- Ken
On Sat, Dec 10, 2022 at 6:29 AM Kaleb Keithley <kkeithle@xxxxxxxxxx> wrote:
>
> I opened https://bugzilla.redhat.com/show_bug.cgi?id=2152211 and the utf8proc-epel packager has added the following comment:
>
> Actually, utf8proc-devel was added to the subversion-devel module in CRB - bz#1996237, so I have now retired this package. I noticed that subversion-devel seems to be missing from CentOS Stream 8, so I filed bz#2152265.
>
>
> On Fri, Dec 9, 2022 at 1:39 PM Kaleb Keithley <kkeithle@xxxxxxxxxx> wrote:
>>
>> For rhel8 and centos8/centos8s utf8proc is in base, and utf8proc-devel is in epel[1]. It appears that utf8proc-devel in epel is behind the times and installing utf8proc-devel will downgrade utf8proc to version 2.1.1. utf8proc was updated for rhel8.7 back in July and the epel maintainer has not updated it yet. I'll look into it.
>>
>> For rhel9 and centos9s utf8proc is in AppStream and utf8proc-devel is in codeready-builder (CRB)
>>
>> For both el8 and el9 libarrow(-devel) and libparquet(-devel) are in epel8[2] and epel9[3].
>>
>> [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=34406
>> [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2019255
>> [3] https://koji.fedoraproject.org/koji/buildinfo?buildID=2059829
>>
>>
>>
>>
>>
>> On Fri, Dec 9, 2022 at 1:16 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
>>>
>>> i've been trying to get our rpms to build without these arrow and
>>> utf8proc submodules in https://github.com/ceph/ceph/pull/46535, but
>>> the shaman centos builds can't find their EPEL packages:
>>>
>>> > No matching package to install: 'arrow-devel'
>>> > No matching package to install: 'parquet-devel'
>>>
>>> can anyone help me figure out why? do we need to do anything special
>>> to enable EPEL here, or would it already be available?
>>>
>>> On Thu, Mar 31, 2022 at 2:51 PM Casey Bodley <cbodley@xxxxxxxxxx> wrote:
>>> >
>>> > i've opened https://github.com/ceph/ceph/pull/45740 to add a paragraph
>>> > about these bundled dependencies under "CMake Options" of README.md.
>>> > it doesn't list all of these options, but a `grep WITH_SYSTEM_
>>> > CMakeLists.txt` will
>>> >
>>> > On Thu, Mar 31, 2022 at 9:05 AM Mark Nelson <mnelson@xxxxxxxxxx> wrote:
>>> > >
>>> > >
>>> > > On 3/30/22 10:05, Casey Bodley wrote:
>>> > > > On Tue, Mar 29, 2022 at 8:18 PM Kaleb Keithley <kkeithle@xxxxxxxxxx> wrote:
>>> > > >>
>>> > > >> On Tue, Mar 29, 2022 at 7:59 PM Gregory Farnum <gfarnum@xxxxxxxxxx> wrote:
>>> > > >>>
>>> > > >>>
>>> > > >>> install-deps.sh should handle grabbing any relevant packages.
>>> > > >>>
>>> > > >> Nope. Bad assumption.
>>> > > >>
>>> > > >> I'll be happy to walk you through building packages for RHEL, Fedora, and CentOS SIGs some time.
>>> > > >>
>>> > > >> Brew, Koji, and CBS all run builds in mock. Dependencies are preloaded and installed before rpmbuild runs. mock has networking disabled by default, so you quite simply can't do things like install other rpms, download outside sources, or do a git submodule init.
>>> > > >>
>>> > > >> I have some experience with pbuilder on Debian and Ubuntu too, but I don't know if it disables networking like mock does, although I suspect it may.
>>> > > >>
>>> > > >> --
>>> > > >>
>>> > > >> Kaleb
>>> > > > since this is a discussion about our default values for WITH_SYSTEM_
>>> > > > cmake variables, i think it's best to separate out packaging concerns
>>> > > > - we assume that distros are customizing these WITH_SYSTEM_ variables
>>> > > > to match what's available, as we do in-tree with ceph.spec.in and
>>> > > > debian/rules
>>> > > >
>>> > > > these cmake defaults are most important for ceph developers doing
>>> > > > their local builds. and here, we do expect that install-deps.sh will
>>> > > > install any system packages that are available on the user's distro
>>> > > >
>>> > > > from the perspective of a ceph developer trying to get the fastest
>>> > > > local builds, i agree that it would be nice for some of these
>>> > > > variables to default to ON instead of tuning them manually
>>> > > >
>>> > > > but from the perspective of maintaining an open source project, i also
>>> > > > see a value in making sure that our default cmake configuration 'just
>>> > > > works'. ceph is a big project with a complicated build system. by
>>> > > > minimizing barriers to entry, we encourage more participation in the
>>> > > > project
>>> > >
>>> > >
>>> > > 100% Casey. Right now we are going to release quincy in a state where
>>> > > it fails to build properly from source on RHEL and CentOS stream and
>>> > > installing the system level utf8proc doesn't fix it. The only way to fix
>>> > > it is to manually apply the fix from master or pass in
>>> > > -DWITH_SYSTEM_UTF8PROC=OFF to do_cmake.sh (which we don't give the
>>> > > user/developer instructions to do anywhere afaik). It's the kind of
>>> > > thing that makes a developer wonder if they are better off installing a
>>> > > non-redhat distro.
>>> > >
>>> > >
>>> > > Mark
>>> > >
>>> > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > Dev mailing list -- dev@xxxxxxx
>>> > > > To unsubscribe send an email to dev-leave@xxxxxxx
>>> > > >
>>> > >
>>> > > _______________________________________________
>>> > > Dev mailing list -- dev@xxxxxxx
>>> > > To unsubscribe send an email to dev-leave@xxxxxxx
>>>
>>
>>
>> --
>>
>> Kaleb
>
>
>
> --
>
> Kaleb
Kaleb
_______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
