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
> > __
