On Wed, Dec 9, 2020 at 1:54 AM Petr Šabata <con...@redhat.com> wrote:
> On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi <ke...@scrye.com> 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 <ke...@scrye.com> 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 <ke...@scrye.com> > 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: <streamname>". > > > > 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 > > _______________________________________________ > > 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 > >
_______________________________________________ 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
