Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)
On Wed, Dec 9, 2020 at 1:54 AM Petr Šabata wrote: > On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi wrote: > > > > On Mon, Dec 07, 2020 at 10:13:13PM +0100, Petr Šabata wrote: > > > On Sat, Dec 5, 2020 at 7:46 PM Kevin Fenzi wrote: > > > > > > > > On Fri, Dec 04, 2020 at 10:23:08PM +0100, Petr Šabata wrote: > > > > > On Fri, Dec 4, 2020 at 8:48 PM Kevin Fenzi > wrote: > > > > > > > > > > > > On Thu, Dec 03, 2020 at 11:26:18PM +0100, Petr Šabata wrote: > > > > > > > Also a couple of notes on modularity here: > > > > > > > > > > > > > > # By default, module stream name is derived from the branch > name > > > > > > > If we have any "master" modules, those will get unexpectedly > renamed > > > > > > > as soon as they get rebuilt. This might impact tagging or > updates and > > > > > > > cause confusion in general. We should check if there are any > like that > > > > > > > and decide on further steps. > > > > > > > > > > > > Good thing to check yes. I can try and do so. > > > > > > > > > > Thanks. > > > > > > > > hum, but I am not 100% sure what I am looking for. > > > > modules with a master branch and no name defined? > > > > What does the name being defined look like in the yaml file? > > > > > > Yes. You could also query MBS for stream=master and see if there's > > > anything reasonably recent to narrow your search. But branches would > > > be enough. > > > > > > In modulemd, stream name is defined as "stream: ". > > > > So, I looked back the last 3 months and I am pretty sure the only ones > > are all flatpaks. (firefix, thunderbird, etc) > > > https://mbs.fedoraproject.org/module-build-service/1/module-builds/?stream=master > > I can also see avocado:master built for f33 there on the first page. > But it could also matter for flatpaks if the name is referenced in the > build process. > > CC'ing Owen. > > > > > > > > # Modules might be pulling components from their master > branches to > > > > > > > build Rawhide artifacts > > > > > > > There are various use cases for this, too long to list. If the > master > > > > > > > ref is no longer available, these will not build. Modulemd > files that > > > > > > > pull components from master need to be updated after Phase 2. > > > > > > > > > > > > Yep. +1 > > > > > > > > > > Great, will you do that, too? > > > > > > > > There seems to be a bunch of them. ;( > > > > > > Many of those are definitely obsolete, though! > > > > Well, I checked out all the modules from rawhide. How can I tell they > > are obsolete? > > Uh; I was fairly certain some of those were my dev modules from the > Boltron era. > If I recall correctly, Merlin was working on marking modules as > obsolete at some point. Maybe we didn't actually run it all of them > and they're being built automatically. We should review everything > that's in Rawhide and obviously isn't supposed to be. > > CC'ing Merlin. > I created https://pagure.io/releng/issue/8887 last year to clean up a bunch of obsolete module stream branches, but it's still on the back burner. Merlin P > > > > > > > > # The modulemd component ref is optional and defaults to master > > > > > > > Unless this got changed later, if the ref field is omitted, > the value > > > > > > > defaults to "master". This is part of the specification and is > handled > > > > > > > by libmodulemd. Not sure how to proceed here. > > > > > > > > > > > > Can we change the default? > > > > > > > > > > According to Vít that's already happened (for completely unrelated > > > > > reasons), so we're good here. > > > > > > > > ok. > > > > > > > > > > > And besides modularity: > > > > > > > > > > > > > > There are people and teams who use bots to autobuild their > upstream > > > > > > > projects in Rawhide. If they have a bot account (and I hope > they do), > > > > > > > they should be notified to update their tooling. > > > > > > > > > > > > We don't have much tracking on bot accounts. People make them > and sign > > > > > > up for fas for them, etc. > > > > > > > > > > > > We can try and find things that are obvious, but we are likely > to miss > > > > > > some. We can definitely help people who notice breakage tho. > > > > > > > > > > Ah, I kinda expected these accounts to be clearly marked as being > > > > > non-human. Oh well. > > > > > > > > > > Anyway, besides the magical module stream renames, all of this > should > > > > > continue to work fine if we get the symbolic refs, I think? > > > > > > > > Well, I am ok with a symbolic ref from main to/from rawhide, but I > don't > > > > like the idea of a master symbolic ref. It kind of defeats the > purpose > > > > of the entire thing. ;( > > > > > > Well, okay. If we get the master ref, I'm happy as that's mostly a > no-op for me. > > > If not, it implies a lot of downstream RHEL work we'll have to handle. > > > Just let us all know in due time. > > > > Well, I don't want to keep master around in any form... and yeah, I > > realize there's going to be fallout. ;( > > > > kevin > >
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
On Thu, Nov 14, 2019 at 12:09 PM Miro Hrončok wrote: > On 14. 11. 19 18:57, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Nov 14, 2019 at 06:43:42PM +0100, Miro Hrončok wrote: > >> On 14. 11. 19 18:36, Zbigniew Jędrzejewski-Szmek wrote: > >>> On Thu, Nov 14, 2019 at 06:08:52PM +0100, Miro Hrončok wrote: > On 09. 10. 19 22:46, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot > > > > Enable module default streams in the buildroot repository for modular > > and non-modular RPMs. > > > > == Summary == > > This Change (colloquially referred to as "Ursa Prime") enables the > > Koji build-system to include the RPM artifacts provided by module > > default streams in the buildroot when building non-modular (or > > "traditional") RPMs. > > I have one more technical concern. > > Suppose a packager decides to package the "mycoolapp" software as a > non-modular package. "mycoolapp" is written in Python, it builds > again non-modular Python, currently 3.8, it requires "python(abi) = > 3.8" on runtime. > >>> > >>> Hmm, and what about an even simpler case: > >>> "myswankyapp" is also written in Python, and is packaged as a module. > >>> Python is rebuilt in a side tag, then the module blocks the upgrade. > >>> What is supposed to happen in that case? > >> > >> The module is rebuilt after the side tag is merged. Al least that is > >> what I think happened with avocado when we upgraded to Python 3.8. > > > > Automatically? And if the build fails? > > I don't think so. I think somebody actually went and did it. CCing Merlin. > At least for avocado, yes, I manually rebuilt it. Merlin ___ 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: A plan regarding SCLs in EPEL 8
On Thu, Oct 10, 2019 at 9:32 AM Merlin Mathesius wrote: > > > On Wed, Oct 9, 2019 at 4:05 PM Kevin Fenzi wrote: > >> On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: >> > I was asked to draft a plan stating what EPEL 8 should do regarding >> > Software Collections. The draft I came up with is included below. >> >> Looks good to me. +1 here. >> >> > EPEL Steering Committee: Please ratify this plan or provide feedback as >> > necessary. When it's ready, and I will prepare a PR for this to land in >> > https://pagure.io/epel/blob/master/f/docs/source >> >> That would be great... >> > > Thanks! > > Anyone else? > > I went ahead and created https://pagure.io/epel/pull-request/81 > Is there any further discussion or feedback on this plan? If not, could someone merge my documentation PR and make it official? Thank you! Merlin > > Merlin > > >> kevin >> -- >> > >> > Regards, >> > >> > Merlin >> > >> > -- >> > >> > >> > *Regarding EPEL and Software Collections* >> > *Background* >> > >> > For RHEL 8, Red Hat made the decision to provide multiple versions of >> > software in the form of App Stream modules instead of Red Hat Software >> > Collections (RHSCLs). >> > >> > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL >> > SIG. >> > >> > RHEL 8 comes with the scl-utils and scl-utils-build packages--which >> contain >> > tools for using and building SCLs. These packages appear to function as >> > expected with RHEL 8 and CentOS 8. >> > >> > *Recommendations* >> > >> > EPEL will not provide SCL support, although it will not prohibit use of >> the >> > SCL tools provided with RHEL 8. >> > >> > EPEL will not provide any SCLs. >> > >> > EPEL encourages the community to follow Red Hat’s lead and provide >> multiple >> > versions of software for RHEL 8 and CentOS 8 in the form of modules >> rather >> > than SCLs. >> > >> > For use cases that require the parallel installation of multiple >> versions >> > of the same component, EPEL recommends the same solution as RHEL 8: >> > containers. >> > >> > -- >> >> > ___ >> > 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 >> >> ___ >> 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 >> > ___ 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
[EPEL-devel] Re: A plan regarding SCLs in EPEL 8
On Wed, Oct 9, 2019 at 4:05 PM Kevin Fenzi wrote: > On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Mathesius wrote: > > I was asked to draft a plan stating what EPEL 8 should do regarding > > Software Collections. The draft I came up with is included below. > > Looks good to me. +1 here. > > > EPEL Steering Committee: Please ratify this plan or provide feedback as > > necessary. When it's ready, and I will prepare a PR for this to land in > > https://pagure.io/epel/blob/master/f/docs/source > > That would be great... > Thanks! Anyone else? I went ahead and created https://pagure.io/epel/pull-request/81 Merlin > kevin > -- > > > > Regards, > > > > Merlin > > > > -- > > > > > > *Regarding EPEL and Software Collections* > > *Background* > > > > For RHEL 8, Red Hat made the decision to provide multiple versions of > > software in the form of App Stream modules instead of Red Hat Software > > Collections (RHSCLs). > > > > SCLs are maintained by the CentOS Software Collections SIG, not the EPEL > > SIG. > > > > RHEL 8 comes with the scl-utils and scl-utils-build packages--which > contain > > tools for using and building SCLs. These packages appear to function as > > expected with RHEL 8 and CentOS 8. > > > > *Recommendations* > > > > EPEL will not provide SCL support, although it will not prohibit use of > the > > SCL tools provided with RHEL 8. > > > > EPEL will not provide any SCLs. > > > > EPEL encourages the community to follow Red Hat’s lead and provide > multiple > > versions of software for RHEL 8 and CentOS 8 in the form of modules > rather > > than SCLs. > > > > For use cases that require the parallel installation of multiple versions > > of the same component, EPEL recommends the same solution as RHEL 8: > > containers. > > > > -- > > > ___ > > 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 > > ___ > 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 > ___ 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
[EPEL-devel] A plan regarding SCLs in EPEL 8
I was asked to draft a plan stating what EPEL 8 should do regarding Software Collections. The draft I came up with is included below. EPEL Steering Committee: Please ratify this plan or provide feedback as necessary. When it's ready, and I will prepare a PR for this to land in https://pagure.io/epel/blob/master/f/docs/source Regards, Merlin -- *Regarding EPEL and Software Collections* *Background* For RHEL 8, Red Hat made the decision to provide multiple versions of software in the form of App Stream modules instead of Red Hat Software Collections (RHSCLs). SCLs are maintained by the CentOS Software Collections SIG, not the EPEL SIG. RHEL 8 comes with the scl-utils and scl-utils-build packages--which contain tools for using and building SCLs. These packages appear to function as expected with RHEL 8 and CentOS 8. *Recommendations* EPEL will not provide SCL support, although it will not prohibit use of the SCL tools provided with RHEL 8. EPEL will not provide any SCLs. EPEL encourages the community to follow Red Hat’s lead and provide multiple versions of software for RHEL 8 and CentOS 8 in the form of modules rather than SCLs. For use cases that require the parallel installation of multiple versions of the same component, EPEL recommends the same solution as RHEL 8: containers. -- ___ 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
RPM spec style
Greetings. I'd like a quick opinion on spec file style... Nearly all specs I've seen dealing with subpackages group all the %package/%description stanzas near the beginning, and put all the %files stanzas near the the end. (Example 1 below) However, are there any reasons, stylistic or otherwise, that the %files stanzas shouldn't be grouped with their corresponding %package/%description stanzas? (Example 2 below) Especially when there are a large number of subpackages... Thanks. Regards, Merlin Example 1: ... preable ... %description %package server %description server %package client %description client %package lib %description lib %prep %build %install %files %files server %files client %files lib %changelog ... Example 2: ... preable ... %description %files %package server %description server %files server %package client %description client %files client %package lib %description lib %files lib %prep %build %install %changelog ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
