On Tue, Dec 8, 2020 at 11:57 PM Kevin Fenzi <kevin(a)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 <kevin(a)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 <kevin(a)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/?strea...
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.
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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