[EPEL-devel] Re: To buildroot, or not to buildroot
On Tue, 19 Oct 2021 at 01:22, Andrew C Aitchison wrote: > > On Thu, 7 Oct 2021, Stephen John Smoogen wrote: > > Things have probably improved, but the lesson I learned from EPEL-8 > > and afterwords was that koji depsolving is weird no matter how set up. > > Koji sets up mock environments in a way that will do fine as long as > > there are NO modules in the repositories it is looking at. Once a > > module, even a non-default module, is there things start to go wonky > > because the way that koji depsolves will say that > > 'foobaz-3.10.1-3+module' is a better solution than > > 'foobax-3.9.4.' it will then try to pull that in and boom you > > end up with broken builds. You can change the method that koji chooses > > packages to be in the buildroot, but the other option ends up trying > > to insert things like foobax-3.9.4-i386 into an x86_64 or still does > > the modular change but chooses foobar-2 due to some depsolv quirk. > > Is the foobar/foobaz/foobax intended or are they typos ? > If they are intended, then I think we have a partially ordered set of > packages, ie it isn't always possible to say whether a > b or a < b. > > Without knowing anything about koji, I'd say that whilst > foobaz and foobax can provide foobar (and perhaps foobar==3) > they cannot satisfy foobar>=3.9 (unless they are forks or > reimplementations of foobar-3.9). > In the case I was remembering they were forks and say inside them that they satisfy anything >= 3.9. Normally you would only have one in a buildroot but you could have alternatives in modules because they each fixed something specific to that module. If you tried to install both modules you would get conflicts so only one module was to be installed at a time.. However, Koji doesn't know that.. one solution method only knows NEVR, Provides and Requires and another tries to use a bit of dnf to do resolutions but that seemed to act weirdly also. In the case where they are all foobar but say foobar-4.0 or foobar4 is in a non-default module, then koji and dnf might come again to different conclusions of what is needed to be in the buildroot. The only mental solution I could come up with was that there would need to be some tool to put all modules (and bare rpms dependent on them) into a RHEL-modularity tree and somehow import that into MBS so that it could deal with them. That would then allow for both EPEL modules to depend on them, and keep them out of the way for koji regular builds. The major problems with that was a) no perl/python/ruby/etc in non-modular builds (all that would be available is platform-python) b) it would break Fedora build system in ways because it assumes what is in its toolkit was built by it and we are faking these. In any case, it is a conundrum wrapped up in an enigma surrounded by a puzzle. > -- > Andrew C. Aitchison Kendal, UK > and...@aitchison.me.uk > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, 7 Oct 2021, Stephen John Smoogen wrote: Things have probably improved, but the lesson I learned from EPEL-8 and afterwords was that koji depsolving is weird no matter how set up. Koji sets up mock environments in a way that will do fine as long as there are NO modules in the repositories it is looking at. Once a module, even a non-default module, is there things start to go wonky because the way that koji depsolves will say that 'foobaz-3.10.1-3+module' is a better solution than 'foobax-3.9.4.' it will then try to pull that in and boom you end up with broken builds. You can change the method that koji chooses packages to be in the buildroot, but the other option ends up trying to insert things like foobax-3.9.4-i386 into an x86_64 or still does the modular change but chooses foobar-2 due to some depsolv quirk. Is the foobar/foobaz/foobax intended or are they typos ? If they are intended, then I think we have a partially ordered set of packages, ie it isn't always possible to say whether a > b or a < b. Without knowing anything about koji, I'd say that whilst foobaz and foobax can provide foobar (and perhaps foobar==3) they cannot satisfy foobar>=3.9 (unless they are forks or reimplementations of foobar-3.9). -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, 7 Oct 2021 at 09:52, Neal Gompa wrote: > > > > > That is the theory, yes, that grobisplitter isn't required. > > But nobody was able to say that was for certain. Thus, it needs to be > > tested. > > > > I've verified this with my internal build infrastructure, so yes, I > know it's not required. > > Admittedly, it's not a Koji system, but I'm also not enabling any > modules in my build environment right now. I'm rebuilding content from > Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9 > packages to build for work, which is how some of my requests to add > stuff to CRB have come about[1][2][3]. Things have probably improved, but the lesson I learned from EPEL-8 and afterwords was that koji depsolving is weird no matter how set up. Koji sets up mock environments in a way that will do fine as long as there are NO modules in the repositories it is looking at. Once a module, even a non-default module, is there things start to go wonky because the way that koji depsolves will say that 'foobaz-3.10.1-3+module' is a better solution than 'foobax-3.9.4.' it will then try to pull that in and boom you end up with broken builds. You can change the method that koji chooses packages to be in the buildroot, but the other option ends up trying to insert things like foobax-3.9.4-i386 into an x86_64 or still does the modular change but chooses foobar-2 due to some depsolv quirk. At the moment I think building without grobisplitter will work, but I am thinking some other solution will need to be made when EL9.x starts rolling out with modules in it. > > This can also be verified when using something like mock with > mock-core-configs v36 or higher, because I made the necessary > adjustments to test building on CentOS Stream 9 the same way that > Fedora Koji and the CentOS CBS would. > > [1]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140 > [2]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139 > [3]: > https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135 > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on a BBS... time to shutdown -h now. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 9:44 AM Troy Dawson wrote: > > > > On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa wrote: >> >> On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: >> > >> > >> > >> > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: >> >> >> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: >> >> > >> >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* >> >> > >> >> > It sounds like the epel9-next is going to startup by building against >> >> > the CS buildroot. Changing it at this time would cause a delay. >> >> > >> >> > Thus we need to write some "verify build deps are released" checker. I >> >> > have an idea of how to do this, so I'm willing to volunteer to write >> >> > and run something. >> >> > >> >> > But, it would be good to have some discussion to determine if we want >> >> > to keep using the CS buildroot for epel9-next, always. Or if we want >> >> > to use it just as a bootstrap mechanism, and then switch to building >> >> > just off the available CentOS Stream repos at some point. >> >> > >> >> > Thoughts? >> >> > Should we always use buildroot? Or just keep up until we're fairly >> >> > stable? >> >> > >> >> >> >> We should only use the buildroot repo for as long as we need to. The >> >> *sooner* we can switch to the published content, the better. >> > >> > >> > This was discussed at the EPEL Steering Committee meeting. Here is the >> > summary. >> > Someone correct me if I'm wrong. >> > >> > epel9-next: >> > - starts off building off CS buildroot >> > - I will write a "check if all build packages are in the normal repos" >> > checker, called "will it build" [1] >> > >> >> How are we going to know whether all the build-time and run-time >> packages are in the normal repos? We need to check generated >> dependencies too, especially now that it's possible to have dynamic >> BuildRequires! > > > run-time dependencies: > That's always been a problem, even without the buildroot. > But I will also be writing a "will it install" to go along with "will it > build" > > build-time dependencies: > Grab the root.log of the package build, and parse it. > This gets around any hidden and dynamic BuildRequires. > I've already written code that does this for Content Resolver, and checked it > against traditional dnf/libsolve dependency generation. > It was 98% equal, and those 2% were on packages where it was possible for > more than one package to be installed for a dependency, and for that, I'd > prefer going with the root.log. > > I think I've got everything I need already written, just in three separate > projects. > I really want to pull that code together and make "willit" > >> >> > epel9: >> > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) >> > >> > Checks/Tests/Future: (It's a little fuzzy on the timing of these) >> > >> > - grobisplitter >> > -- see if we really need to use grobisplitter >> > -- I'm a little fuzzy on how or when we are going to test this >> > >> >> With the retirement of the container-tools default module, >> grobisplitter will not be required at all unless we want to use it to >> support non-default modules. > > > That is the theory, yes, that grobisplitter isn't required. > But nobody was able to say that was for certain. Thus, it needs to be tested. > I've verified this with my internal build infrastructure, so yes, I know it's not required. Admittedly, it's not a Koji system, but I'm also not enabling any modules in my build environment right now. I'm rebuilding content from Rawhide targeting CentOS Stream 9 to get a list of initial EPEL 9 packages to build for work, which is how some of my requests to add stuff to CRB have come about[1][2][3]. This can also be verified when using something like mock with mock-core-configs v36 or higher, because I made the necessary adjustments to test building on CentOS Stream 9 the same way that Fedora Koji and the CentOS CBS would. [1]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/140 [2]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/139 [3]: https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/135 -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 6:28 AM Neal Gompa wrote: > On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: > > > > > > > > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: > >> > >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: > >> > > >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* > >> > > >> > It sounds like the epel9-next is going to startup by building against > the CS buildroot. Changing it at this time would cause a delay. > >> > > >> > Thus we need to write some "verify build deps are released" checker. > I have an idea of how to do this, so I'm willing to volunteer to write and > run something. > >> > > >> > But, it would be good to have some discussion to determine if we want > to keep using the CS buildroot for epel9-next, always. Or if we want to > use it just as a bootstrap mechanism, and then switch to building just off > the available CentOS Stream repos at some point. > >> > > >> > Thoughts? > >> > Should we always use buildroot? Or just keep up until we're fairly > stable? > >> > > >> > >> We should only use the buildroot repo for as long as we need to. The > >> *sooner* we can switch to the published content, the better. > > > > > > This was discussed at the EPEL Steering Committee meeting. Here is the > summary. > > Someone correct me if I'm wrong. > > > > epel9-next: > > - starts off building off CS buildroot > > - I will write a "check if all build packages are in the normal repos" > checker, called "will it build" [1] > > > > How are we going to know whether all the build-time and run-time > packages are in the normal repos? We need to check generated > dependencies too, especially now that it's possible to have dynamic > BuildRequires! > run-time dependencies: That's always been a problem, even without the buildroot. But I will also be writing a "will it install" to go along with "will it build" build-time dependencies: Grab the root.log of the package build, and parse it. This gets around any hidden and dynamic BuildRequires. I've already written code that does this for Content Resolver, and checked it against traditional dnf/libsolve dependency generation. It was 98% equal, and those 2% were on packages where it was possible for more than one package to be installed for a dependency, and for that, I'd prefer going with the root.log. I think I've got everything I need already written, just in three separate projects. I really want to pull that code together and make "willit" > > epel9: > > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) > > > > Checks/Tests/Future: (It's a little fuzzy on the timing of these) > > > > - grobisplitter > > -- see if we really need to use grobisplitter > > -- I'm a little fuzzy on how or when we are going to test this > > > > With the retirement of the container-tools default module, > grobisplitter will not be required at all unless we want to use it to > support non-default modules. > That is the theory, yes, that grobisplitter isn't required. But nobody was able to say that was for certain. Thus, it needs to be tested. Troy ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Thu, Oct 7, 2021 at 9:24 AM Troy Dawson wrote: > > > > On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: >> >> On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: >> > >> > *this is worth a discussion in todays EPEL Steering Committee Meeting* >> > >> > It sounds like the epel9-next is going to startup by building against the >> > CS buildroot. Changing it at this time would cause a delay. >> > >> > Thus we need to write some "verify build deps are released" checker. I >> > have an idea of how to do this, so I'm willing to volunteer to write and >> > run something. >> > >> > But, it would be good to have some discussion to determine if we want to >> > keep using the CS buildroot for epel9-next, always. Or if we want to use >> > it just as a bootstrap mechanism, and then switch to building just off the >> > available CentOS Stream repos at some point. >> > >> > Thoughts? >> > Should we always use buildroot? Or just keep up until we're fairly stable? >> > >> >> We should only use the buildroot repo for as long as we need to. The >> *sooner* we can switch to the published content, the better. > > > This was discussed at the EPEL Steering Committee meeting. Here is the > summary. > Someone correct me if I'm wrong. > > epel9-next: > - starts off building off CS buildroot > - I will write a "check if all build packages are in the normal repos" > checker, called "will it build" [1] > How are we going to know whether all the build-time and run-time packages are in the normal repos? We need to check generated dependencies too, especially now that it's possible to have dynamic BuildRequires! > epel9: > - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) > > Checks/Tests/Future: (It's a little fuzzy on the timing of these) > > - grobisplitter > -- see if we really need to use grobisplitter > -- I'm a little fuzzy on how or when we are going to test this > With the retirement of the container-tools default module, grobisplitter will not be required at all unless we want to use it to support non-default modules. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Wed, Oct 6, 2021 at 7:39 PM Neal Gompa wrote: > On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: > > > > *this is worth a discussion in todays EPEL Steering Committee Meeting* > > > > It sounds like the epel9-next is going to startup by building against > the CS buildroot. Changing it at this time would cause a delay. > > > > Thus we need to write some "verify build deps are released" checker. I > have an idea of how to do this, so I'm willing to volunteer to write and > run something. > > > > But, it would be good to have some discussion to determine if we want to > keep using the CS buildroot for epel9-next, always. Or if we want to use > it just as a bootstrap mechanism, and then switch to building just off the > available CentOS Stream repos at some point. > > > > Thoughts? > > Should we always use buildroot? Or just keep up until we're fairly > stable? > > > > We should only use the buildroot repo for as long as we need to. The > *sooner* we can switch to the published content, the better. > This was discussed at the EPEL Steering Committee meeting. Here is the summary. Someone correct me if I'm wrong. epel9-next: - starts off building off CS buildroot - I will write a "check if all build packages are in the normal repos" checker, called "will it build" [1] epel9: - Use normal RHEL 9 repos (AppStream, BaseOS, CRB) Checks/Tests/Future: (It's a little fuzzy on the timing of these) - grobisplitter -- see if we really need to use grobisplitter -- I'm a little fuzzy on how or when we are going to test this - "will it build" -- After a period of time, check and see if we are happy with the combination of CS buildroot + "will it build" ? --- Yes - determine if we want to keep it like this even after epel9 --- No - determine when the best/safest time to switch to normal repos Troy [1] - I plan on integrating "will it build" with a "will it install" checker. It will be called "will it" or "willit". I'm sorta excited about doing this. It's something I've wanted to do for a long time and I think I've finally got it figured out. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Wed, Oct 6, 2021 at 3:36 PM Troy Dawson wrote: > > *this is worth a discussion in todays EPEL Steering Committee Meeting* > > It sounds like the epel9-next is going to startup by building against the CS > buildroot. Changing it at this time would cause a delay. > > Thus we need to write some "verify build deps are released" checker. I have > an idea of how to do this, so I'm willing to volunteer to write and run > something. > > But, it would be good to have some discussion to determine if we want to keep > using the CS buildroot for epel9-next, always. Or if we want to use it just > as a bootstrap mechanism, and then switch to building just off the available > CentOS Stream repos at some point. > > Thoughts? > Should we always use buildroot? Or just keep up until we're fairly stable? > We should only use the buildroot repo for as long as we need to. The *sooner* we can switch to the published content, the better. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
*this is worth a discussion in todays EPEL Steering Committee Meeting* It sounds like the epel9-next is going to startup by building against the CS buildroot. Changing it at this time would cause a delay. Thus we need to write some "verify build deps are released" checker. I have an idea of how to do this, so I'm willing to volunteer to write and run something. But, it would be good to have some discussion to determine if we want to keep using the CS buildroot for epel9-next, always. Or if we want to use it just as a bootstrap mechanism, and then switch to building just off the available CentOS Stream repos at some point. Thoughts? Should we always use buildroot? Or just keep up until we're fairly stable? Troy ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On Fri, Oct 1, 2021 at 5:39 PM Miro Hrončok wrote: > > On 01. 10. 21 22:11, Troy Dawson wrote: > > I'll have to file all those "please move these packages into CRB" bugz after > > RHEL9 is out. > > I wonder whether we should file those before it is out, if at all possible? > Ideally, yes because it's an extreme pain to deal with them post-GA. Red Hat's policies around this stuff is such that after 9.0, they can only be introduced in 6 month intervals (that is, we have to wait for 9.1 for them to show up in EPEL9). We should *never* use the buildroot repository for EPEL-Next because it massively complicates discovering this stuff and getting it straightened out immediately. Unlike CentOS SIGs that only build for CentOS Stream, EPEL needs to work on RHEL, and Red Hat will *never* ship the buildroot repo for RHEL, because it opens up the door for things to depend on that content, which is highly problematic for them. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: To buildroot, or not to buildroot
On 01. 10. 21 22:11, Troy Dawson wrote: I'll have to file all those "please move these packages into CRB" bugz after RHEL9 is out. I wonder whether we should file those before it is out, if at all possible? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
