Re: Guidance on individual packages requiring x86_64-v2 baseline ?

[Josh Boyer]

On Thu, Jun 20, 2024 at 7:30 AM Stephen Smoogen  wrote:
>
> On Wed, 19 Jun 2024 at 16:23, Fabio Valentini  wrote:
> >
> > On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson  wrote:
> > >
> > > On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
> > >  wrote:
> > > >
> > > > On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > > > > [...] at some point we need to do the cut and not being held back by 
> > > > > old
> > > > > / ancient hardware forever.
> > > >
> > > > What do you mean by "being held back"? What's being prevented by not
> > > > requiring x86-64-v2 for all packages while allowing few select ones to
> > > > have higher arch requirements? And why do "we need to"?
> > > >
> > > > As Neal said, rpm allows building for target x86_64_v2, so... let's do
> > > > that for those packages that require it?
> > >
> > > That may mean having two versions of the same package, one built
> > > against v1 and one v2, you're then doubling the workload for a whole
> > > lot of contributors for the sake of old hardware.
> > >
> > > We had the same discussions on i686 and the first few times it was
> > > proposed it didn't get traction, but it eventually did. There was a
> > > i686 SIG which ultimately went nowhere.
> > >
> > > To put this a different way, would you be prepared to do the work to
> > > maintain the old v1 packages if maintainers don't want to maintain 2
> > > versions?
> >
> > IIUC this wouldn't require maintaining a separate package, but just
> > adding x86_64-v2 as a separate build *target* for the same package.
> >
>
> I don't think Peter meant additional packages since with the i686 it
> didn't mean that. What it did mean was having to understand why two
> architectures might do things differently and why bugs might show up
> in one but not another. It also means that someone needs to
> continually help release engineering make sure that the entire Fedora
> build system (koji, composers, mock, createrepo, test tools, etc) make
> sure the packages get built, and put into the repositories correctly,
> that images get made correctly and such. This is continual work
> because as has been seen any change to one tool in an update can make
> the others stop working in weird ways.
>
> I am not saying this is a 'can't be done'.. but this is not Free Work.
> The Fedora release engineering is pretty small, its physical and
> compute resources are pretty confined. You can only keep so many
> spinning plates going before they all come crashing down.

That covers infra and rel-eng, but there's another aspect that is
being underrepresented here as well.  Testing.  If you take a single
SRPM and build it for v1 and v2, ideally you'd test it on v1 and v2
hardware.  If you only test one target, then you're basically just
assuming it works[1] on the other.  In that scenario, whatever target
is preferred for testing is the defacto default.

I really don't think it's worth introducing more x86_64 targets across
the entire package set.  It doesn't scale on many levels.  Pick your
baseline according to whatever criteria you see best for the project
and stick with it.

josh

[1] Quite frankly, I think the vast majority of the i686 builds fall
into this "assume it works" category and it's a waste of resources to
continue i686 on a large scale.  I know "Steam games" is one of the
leading use cases, and that seems like a great thing for a SIG to
actually center around and continue focused package builds for.
However, I've been ranting about i686 for years and have just accepted
the fact that Fedora seems to want to pretend it's a worthwhile
effort.
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-06-17)

[Josh Boyer]

On Tue, Jun 18, 2024 at 1:13 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jun 18, 2024 at 12:30:23PM -0400, Josh Boyer wrote:
> > On Tue, Jun 18, 2024 at 8:25 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Tue, Jun 18, 2024 at 03:20:07PM +0300, Otto Liljalaakso wrote:
> > > > Stephen Gallagher kirjoitti 17.6.2024 klo 23.07:
> > > > > =
> > > > > # #meeting:fedoraproject.org: fesco
> > > > > =
> > > > >
> > > > > Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05
> > > > >
> > > > > Meeting summary
> > > > > ---
> > > > > * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31)
> > > > > * TOPIC: #3222  Change: Make Tuned the Default Power Profile
> > > > > Management Daemon (@sgallagh:fedora.im, 19:12:35)
> > > > > * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59)
> > > > >  * ACTION: zbyszek to chair the next meeting 
> > > > > (@sgallagh:fedora.im, 19:53:23)
> > > > > * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30)
> > > > >  * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away
> > > > > from ODCS (@sgallagh:fedora.im, 20:04:29)
> > > > >
> > > > > Meeting ended at 2024-06-17 20:06:17
> > > > >
> > > > > On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher 
> > > > >  wrote:
> > > > > > = New business =
> > > > > >
> > > > > > #3222 Change: Make Tuned the Default Power Profile Management Daemon
> > > > > > https://pagure.io/fesco/issue/3222
> > > >
> > > > This creates the impression that you did not decide anything regarding
> > > > #3222. Checking from logs, I see that that is not the case:
> > > >
> > > > > #agreed FESCo approves the Change to use tuned as the default
> > > > power-management tool for desktop installs. P-P-D remains in the
> > > > distribution as an alternative that can be manually installed. (+7, 0, 
> > > > -1)
> > > >
> > > > Is the meetbot somehow broken, or was that just wrong syntax or 
> > > > something?
> > > We forgot to say '!agreed …'.
> >
> > I would love for someone to tweak zodbot to use generative AI to
> > actually make it useful.  It served us well for a very long time, but
> > the published summaries aren't useful for those just wanting to follow
> > along and the need to remember what was agreed on with implicit
> > commands is cumbersome.  It wouldn't be that hard to just pipe the
> > logs through an LLM to produce a much better summary and auto-generate
> > the agreements and decisions.  A human would need to review before
> > sending it out, but I think end consumers would benefit much more.
>
> I think this is one of the rare occasions where we forgot to invoke
> the right commands. We almost always remember to do that. Sometimes
> it's useful to edit the summary a bit, I usually do that before sending
> it out.

Yes, I understand it was a rare instance of forgetting the command but
the underlying point of my suggestion was that the summaries are not
really useful even when you remember to use the commands.  If you're
in the meeting and remember the discussion, they might seem like they
capture things well but for those that are not they don't really
provide a lot of value.  The difference between the sent summary from
the tool and the full logs is huge, so a better summary would improve
the experience.  Using a tool to provide a better summary with more
context seems like a good win.

josh
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-06-17)

[Josh Boyer]

On Tue, Jun 18, 2024 at 8:25 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jun 18, 2024 at 03:20:07PM +0300, Otto Liljalaakso wrote:
> > Stephen Gallagher kirjoitti 17.6.2024 klo 23.07:
> > > =
> > > # #meeting:fedoraproject.org: fesco
> > > =
> > >
> > > Meeting started by @sgallagh:fedora.im at 2024-06-17 19:00:05
> > >
> > > Meeting summary
> > > ---
> > > * TOPIC: Init Process (@sgallagh:fedora.im, 19:00:31)
> > > * TOPIC: #3222  Change: Make Tuned the Default Power Profile
> > > Management Daemon (@sgallagh:fedora.im, 19:12:35)
> > > * TOPIC: Next week's chair (@sgallagh:fedora.im, 19:50:59)
> > >  * ACTION: zbyszek to chair the next meeting (@sgallagh:fedora.im, 
> > > 19:53:23)
> > > * TOPIC: Open Floor (@sgallagh:fedora.im, 19:53:30)
> > >  * ACTION: @sgallagh to submit a Change to migrate Fedora ELN away
> > > from ODCS (@sgallagh:fedora.im, 20:04:29)
> > >
> > > Meeting ended at 2024-06-17 20:06:17
> > >
> > > On Mon, Jun 17, 2024 at 8:21 AM Stephen Gallagher  
> > > wrote:
> > > > = New business =
> > > >
> > > > #3222 Change: Make Tuned the Default Power Profile Management Daemon
> > > > https://pagure.io/fesco/issue/3222
> >
> > This creates the impression that you did not decide anything regarding
> > #3222. Checking from logs, I see that that is not the case:
> >
> > > #agreed FESCo approves the Change to use tuned as the default
> > power-management tool for desktop installs. P-P-D remains in the
> > distribution as an alternative that can be manually installed. (+7, 0, -1)
> >
> > Is the meetbot somehow broken, or was that just wrong syntax or something?
> We forgot to say '!agreed …'.

I would love for someone to tweak zodbot to use generative AI to
actually make it useful.  It served us well for a very long time, but
the published summaries aren't useful for those just wanting to follow
along and the need to remember what was agreed on with implicit
commands is cumbersome.  It wouldn't be that hard to just pipe the
logs through an LLM to produce a much better summary and auto-generate
the agreements and decisions.  A human would need to review before
sending it out, but I think end consumers would benefit much more.

josh
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Node.js] Stepping down as Node.js Maintainer in Fedora

[Josh Boyer]

On Wed, May 29, 2024 at 11:32 AM Stephen Gallagher  wrote:
>
> tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20
> and nodejs16 packages in Fedora, effective June 30, 2024. I will
> continue to maintain libuv.
>
>
>
> It's been a hard decision to come to, but I think this is the correct
> decision for me. I've been effectively the sole maintainer of Node.js
> in Fedora for nearly a dozen years now (apparently, I landed the first
> official package in Fedora on Dec. 18, 2012). It has been a long, long
> road.
>
> I first picked up Node.js because it was being added as a new
> dependency on a package I maintained at the time: Review Board (a
> Django-base code-review application). When I looked into it, I
> discovered that others had tried - and failed - to package Node.js
> previously, but Fedora's rules at the time were *very* strict with
> regards to carrying bundled software and Node.js upstream at the time
> had a build-system that pretty much only allowed bundling. It took
> quite a bit of effort to work through that, but we got there in the
> end and I was able to deliver Node.js 0.8 as the very first version to
> ship as part of Fedora. It's been a wild ride ever since.
>
> For a long time, Fedora carried a single version of Node.js - whatever
> was the latest version destined for LTS status at the time that Fedora
> version would be released. Then, along came... Modularity. As you may
> know, I was heavily involved with the design of Modularity. Node.js in
> particular was something I viewed as a perfect consumer of this new
> packaging mechanism: it gave us the ability to ship all versions of
> Node.js in Fedora (not just the LTS ones) in a way that could be
> packaged in VMs and (new at the time) container images without needing
> to modify the way the applications were launched.
>
> Sadly, as you probably know, the implementation of Modularity fell
> short of its lofty goals and has largely been relegated to the
> dust-bin of history. When it became clear that Modules were going to
> be dropped from Fedora, I took on another big packaging exercise:
> DE-modularizing Node.js. Rather than go back to the "single Node.js
> version in Fedora" approach, I moved to a hybrid approach where we
> would have a single "system" version of Node.js LTS like in the older
> style, but we would also package the older (and newer!) LTS releases
> in a non-default arrangement, similar to how Python packages are
> delivered in Fedora. I've been doing it this way for a few years now,
> and while there have been some bumps in the road around major-release
> upgrades, it's been overall quite workable.
>
> Recently, the Node.js downstream maintainers made some additional
> improvements in Node.js 20 to unbundle some previously-precompiled
> WASM code into their own packages which build it properly. This is
> great! Unfortunately, it has introduced some new issues with the
> non-default version in the release (as many of you probably saw last
> week). We sorted this out by temporarily re-bundling the WASM in the
> non-default versions, but this is really a stop-gap solution.
>
> It's not a huge issue, but it took a big chunk out of my week to get
> that resolved and in doing it, I came to an important realization: I'm
> burnt out. I took a moment to think through it and realized that I
> don't actually *use* Node.js anywhere anymore. I've been maintaining
> it for so long that it's become a habit, but I'm not a real consumer
> of it. I've sent requests in the past to fedora-devel asking for
> comaintainers, but I've never actually had anyone step up, so I've
> just kept going.

Thank you for all the work you've done on this, Stephen.  Kudos to you
for recognizing where you're at, and having the courage to share it.

> So that brings us to today and my decision to step down. It's been a
> wild ride, but I need to step away and focus on other things. I hope
> someone out there will pop up and take over for me. I'm perfectly
> happy to train someone on how I maintain the various versions, but my
> time as a maintainer is coming to an end. I'll keep things going for
> another month, but after that it becomes Someone Else's Problem.
>
> If you read this far, thanks for suffering through that rambling journey.

No, again, thank you.

josh
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Summary/Minutes from today's FESCo Meeting (2023-11-09)

[Josh Boyer]

On Thu, Nov 16, 2023, 9:05 AM Stephen Smoogen  wrote:

>
>
> On Thu, 16 Nov 2023 at 07:46, Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> Zbigniew Jędrzejewski-Szmek wrote:
>> > This is called "shooting the messenger".
>>
>> It is not. See my reply to Fabio.
>>
>> > LSB requires various obsolete interfaces, in particular it requires
>> > Python 2 to be available as /usr/bin/python. Comment [1] contains a
>> > nice listing. We are not going to bring back Python 2 or old PERL
>> > modules to satisfy LSB.
>>
>> That is exactly the attitude I am complaining about!
>>
>> It would be very much possible to support the Python 2 parts of the spec,
>> without even shipping unmaintained software: Package Tauthon 2.8.4, and
>> make
>> both /usr/bin/python and /usr/bin/python2 symlinks to /usr/bin/tauthon.
>> That
>
>
> 1. It is not clear that would actually be 'valid' for being LSB compliant.
> The LSB was written to be very specific in the 'actual' software used.
> Substitutes would need approval by the now defunct LSB committee.
> 2. The packages in Fedora are put in there by individuals who are
> interested in maintaining them.  The only things I know of stopping you or
> a group of individuals from packing up tauthon or the other 'dead' software
> is just the sheer size of the work required. However, that is just the easy
> stuff. The perl changes also require similar locked older versions of perl
> and module trees so every perl script would also need to now be changed to
> refer to specific versions (one being the perl5 approved by LSB and the
> other not).
>
> In the end, the real work needed is getting LSB 'going' again. The last
> version was over 10 years old and based on what the state of the 'OS' was
> in 2012 (it takes time to standardize so even with the last version being
> from 2015, it is going to aim at what is generally available in 2012). It
> needs a 'reboot' which either meets what is the state of things are in say
> 2019 or newer. Or interested people can make an OS which will stick to
> LSB-5.0 forever.
>

I question whether any of that is actually needed.  Evidence from the past
decade seems to show we get by just fine without it.  I think it's better
to just let LSB fade gracefully into the night.

josh
--
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: An update on RHEL moving to issues.redhat.com

[Josh Boyer]

On Sat, Sep 9, 2023 at 4:17 AM Sandro  wrote:
>
> On 09-09-2023 05:33, Brendan Conoboy wrote:
> > On Fri, Sep 8, 2023 at 7:34 PM Maxwell G  wrote:
> >
> >> 2023-09-09T01:05:39Z Brendan Conoboy :
> >>
> >>> All new issues found or desired in RHEL (Or CentOS Stream) need to be
> >>> filed on issues.redhat.com[http://issues.redhat.com].
> >> Hi Brendan,
> >>
> >> Thanks for the update.
> >>
> >> How can I watch (i.e. get email notifications about) specific packages'
> >> bugs in Jira like I could with
> >> ? I
> >> currently watch ansible-core bugs so I can keep up with RHEL changes and
> >> properly maintain the ansible community package in EPEL.
> >>
> >
> > Hey, this is a great question, especially because I have a decent answer
> > ;-)  I don't think there is an exact analogue, but this approach will
> > probably do what you want, and maybe be even better:
> >
> > 0. I'm assuming you've created an account and are logged in.
> > 1. Visit issues.redhat.com, open the Issues drop-down menu, and select
> > Search.
> > 2. Enter this search term: "project = RHEL and component = ansible-core"
> > and click "Search". You'll see all current issues.  This is called a filter
> > and it works approximately like an SQL query. It's fast.
> > 3. Click the "Save as" button just above the dialogue box. This will let
> > you save the filter for later use, sharing, etc. Let's say you call it
> > "epel ansible-core bugs"
> > 4. Return to the Issues drop-down menu and select "Manage Filters". You'll
> > be taken to a page that shows all the filters you own, probably just "epel
> > ansible-core bugs" to start.
> > 5. On the row showing "epel ansible-core bugs" you'll see a column with a
> > link titled "Subscribe".  Pick the frequency you'd like to have it run, and
> > you'll get an email with the results of the filter on that frequency.
> > 6. Soon you'll get tired of seeing the same stuff, and want to change the
> > filter to something like "project = RHEL and component = ansible-core and
> > (createdDate > -1d OR updatedDate > -1d)".  You can do that, save it to the
> > same filter, and you'll get that report instead.
> >
> > There's a ton of documentation, youtube videos, etc out there on Jira
> > intrinsics like this.  If we find that there's a need for some
> > Fedora-flavored documentation to support EPEL that's cool, let's figure out
> > where to put it and we'll make it happen.
>
> I think you just made perfectly clear why Jira is a beast [1] not aimed
> at usability. I hope Red Hat will heed the feedback of their customers
> once that beast is unleashed upon them.

Customers are directed to the Customer Portal for defects, issues, and
support help in general.

josh

> For context: Years ago I had to manage a stack of Atlassian tools, with
> Jira being one of them. We came from Bugzilla. I hated it ever since.
> Adding insult to injury: the development process didn't improve. Yes
> managers were able to produce nice graphics, but developers in that
> company were still the same old Java boneheads. It's true what they say
> about old dogs.
>
> Since there are now two issue trackers on the redhat.com domain
> (bugzilla.rh.c and issues.rh.c), would it be an idea to migrate
> bugzilla.rh.c to bugzilla.fp.o (or better bugs.fp.o)?
>
> [1] At least Atlassian sort of admit it by choosing the name Jira:
> https://en.wikipedia.org/wiki/Zilla_(Godzilla)
>
> -- Sandro
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in August

[Josh Boyer]

On Tue, Jul 25, 2023 at 11:44 AM Florian Weimer  wrote:
>
> * Josh Boyer:
>
> > On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok  wrote:
> >>
> >> On 25. 07. 23 16:42, Florian Weimer wrote:
> >> > * Miro Hrončok:
> >> >
> >> >> glibc32   codonell, fweimer, jakub, 
> >> >> mcermak
> >> >
> >> > Is this about FTBFS issues?  There isn't any recent build failure in
> >> > Koji, so I don't get why it's on this list?
> >>
> >> The build currently in Rawhide was done on Fedora 36 which is end of life.
> >>
> >> Apparently the release engineering team has not rebuilt this package in a 
> >> mass
> >> rebuild at least since Fedora 35.
> >>
> >> To remove it from the list, build the package on Rawhide please.
> >
> > Or we could not, and drop i686 completely.
>
> If we drop glibc32, we can't build any 32-bit code at all because GCC
> will no longer support -m32.  In this regardm x86-64 is different than
> the other Fedora architectures which can target bare metal 32-bit even
> from 64-bit-only compilers.
>
> Are bootloaders fully treated as firmware and no longer built by Fedora?
> At least the shim package does not come with corresponding source code
> AFAICS.  But I expect that there are other 32-bit pre-boot packages that
> we still rebuild.
>
> We need to fix this GCC build issue for CentOS 10 eventually, and at
> that point, we won't need glibc32 anymore.  It's been a constant source
> of annoyance.

Necessity is the mother of all invention.  If you need this solved by
CentOS Stream 10, you really want to solve it now and get that
solution into F39 or F40 at the latest.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in August

[Josh Boyer]

On Tue, Jul 25, 2023 at 10:53 AM Miro Hrončok  wrote:
>
> On 25. 07. 23 16:42, Florian Weimer wrote:
> > * Miro Hrončok:
> >
> >> glibc32   codonell, fweimer, jakub, mcermak
> >
> > Is this about FTBFS issues?  There isn't any recent build failure in
> > Koji, so I don't get why it's on this list?
>
> The build currently in Rawhide was done on Fedora 36 which is end of life.
>
> Apparently the release engineering team has not rebuilt this package in a mass
> rebuild at least since Fedora 35.
>
> To remove it from the list, build the package on Rawhide please.

Or we could not, and drop i686 completely.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

[Josh Boyer]

On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro 
wrote:

> On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer
>  wrote:
> > Which means equivalent fixes are in CentOS Stream and anyone wanting
> > to recreate exactly what is in RHEL is welcome to backport that code
> > from CentOS Stream or upstream.
>
> Yes, but that's going to be pretty hard to do if you cannot see what
> needs to be backported because you don't have a Customer Portal
> subscription. :)
>

Yes, the work you do is not easy.

In this particular case, there are two CVEs fixed somewhere in the
> middle of maybe 100 other upstream changes, and the correspondence
> between CVE vs. upstream commit is intentionally not public to
> discourage distros from backporting individual security fixes. (It's
> not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes
> do security backports for RHEL anyway for regulatory rather than
> security reasons.) Anyway, to figure out what to backport in order to
> match what's in RHEL, you'd have to either somehow get access to the
> RHEL SRPM, or else email me and ask what to do.
>

Or build up a knowledge of the code base that allows one to do it
themselves.

I don't really have any strong opinion about this change. Just pointing
> out that it's going to be effectively impossible to reverse-engineer
> RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders
> are going to need to get copies of the RHEL SRPMs somehow if they want
> to match RHEL, and they do.
>

I don't think it's impossible.  I think it requires work, skill, and
investment.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: What is Fedora?

[Josh Boyer]

On Fri, Jun 23, 2023 at 9:35 AM Michael Catanzaro  wrote:
>
> On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch
>  wrote:
> > Please understand that (speaking of the user space packages, I cannot
> > speak for kernel) there are no other sources then the sources in
> > GitLab,
> > which is publicly accessible (AFAIK).
>
> The sources that are actually used for RHEL releases are certainly not
> available on GitLab. E.g. the latest released version of webkit2gtk3 is
> currently 2.38.5-1.el9.2. You can try finding the source for that on
> GitLab, but it's not there because we don't have stable branches on
> GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.

Which means equivalent fixes are in CentOS Stream and anyone wanting
to recreate exactly what is in RHEL is welcome to backport that code
from CentOS Stream or upstream.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Josh Boyer]

On Thu, Jun 22, 2023 at 5:02 AM Matthew Miller  wrote:
>
> >> ELN is a build of (some) Fedora packages with EL-specific options, so
> >> it requires Fedora.
> > ELN can exist off an internal non fedora tree. Just depends who is
> > updating the tree.
>
> Sure, but... that's the _opposite_ of the direction things are going.
> Previously, what happened to make a major RHEL release was:
>
> 1. Some Fedora Linux Release -> an internal bootstrap
> 2. ...  a year or so of secret work ...
> 3. RHEL Beta
> 4. RHEL Release
> 5. CentOS Linux rebuild
> 6. Internal RHEL build process, internal work on minor release
> 7. RHEL updates appear in publiuc
> 8. CentOS Linux rebuilds of those.
>
> There's no connection to Fedora beyond the intial fork, and a lot of work
> done inside Red Hat without any transparency.
>
>
> Now, CentOS Stream brings that to the surface:
>
> 1. Fedora Rawhide continually updated
> 2. ELN maintained in parallel, as part of Fedora
> 3. At some point, ELN branched to new CentOS Stream
> 4. ... a year or so of CentOS Stream development in public ...
> 5. RHEL Beta forked from that, released
> 6. Work on RHEL updates visible in CentOS Stream
> 7. Updates appear in CentOS Stream
> 8. Updates released to RHEL
>
> Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git
> history from Fedora, which is a big improvement in preserving all of the
> incredible, valuable work from Fedora contributors.
>
> All of this is the exact opposite of Red Hat preparing to make some new base
> for RHEL. Additionally, this model provides a clean path for
> Red-Hat-opinionated decisions to differ from those we make from Fedora. Take
> BTRFS as an example. Or, the increase in CPU baseline. Like this:
>
>
> Fedora Linux: Community Space
> -
>
> * Community engineering decisions
> * No special code privileges due to your employer
> * Community-run infrastructure with RH investment, significant resources
>   from Amazon, contributions from other companies
> * Community quality engineering with RH investment
> * Community support
> * No cost
>
>
> CentOS Stream: Shared Space
> ---
>
> * Red Hat Engineering decisions with community input
> * Pull requests from the community, approval from Red Hat engineers
> * Red Hat-provided and maintained infrastructure
> * Red Hat quality engineering with partner and community involvement
> * Community support
> * no cost
>
>
> Red Hat Enterprise Linux: Product Space
> ---
>
> * Red Hat Engineering decisions with customer input
> * Red Hat engineers and only RH engineers do the work
> * Red Hat infrastructure
> * Red Hat quality engineering (mostly done in Stream, though)
> * Enterprise support
> * Subscription, including low- and no-cost options
>
>
> Previously, we had a whole convoluted thing which people tried to describe
> in terms of MC Escher paintings. This is far better, and Fedora is in a
> better place. In the earlier setup, CentOS _was_ sometimes positioned as a
> competitor (although generally, those of us working in the actual Fedora and
> CentOS communities didn't have any interest in playing that game.)

Agree with Matthew fully here.  We've been working rather hard
internally to adjust the development process for RHEL to be more
collaborative and open than it ever has before.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Proposal: Make Toolbx a release-blocking deliverable and have release-blocking test criteria (System-Wide Change)

[Josh Boyer]

On Mon, Jun 5, 2023 at 6:28 AM Debarshi Ray via devel
 wrote:
>
> Hey,
>
> I wanted to wrap up this sub-thread on-list, after Owen and I chatted
> about it off-list.
>
> I am fine with having the fedora-toolbox OCI images being defined as
> kickstart files in the Fedora infrastructure and built by ImageFactory
> and published as another base image, just like the fedora base image
> currently is.

Just an FYI, but we're trying to move away from ImageFactory in the
general sense.  I'm not sure if/how that will manifest itself in
Fedora, but ImageFactory is pretty terrible for debugging things when
it goes wrong.  The options we're looking at elsewhere are Image
Builder, OSBS2, and RHTAP.

Honestly, for base container images the simplest solution is just
buildah but nobody has put a lot of time into making that workable in
the ways that many projects would view as "official".

josh

> This means that the downstream sources of the images in Fedora that are
> actually used to make them available to users will differ from the
> upstream sources that are used for testing and CI and are currently
> represented as Containerfiles.  If we can't use ImageFactory for
> upstream testing and CI, we will have to carefully keep them
> synchronized whenever there are changes.  If this is the price to pay
> for making the fedora-toolbox images release-blocking deliverables,
> then so be it.  :)
>
> That said, my understanding is that Owen is still not settled on all
> the tooling changes for building Fedora Flatpaks.  So, we may or may
> not end up using ImageFactory for the fedora-toolbox images in the end.
>
> Cheers,
> Rishi
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Using AI/Machine Learning with rpmautospec?

[Josh Boyer]

On Sat, Jun 3, 2023 at 4:06 PM Reon Beon via devel
 wrote:
>
> How far along is this? Possible in the next 5-10 years or so?

What do you want it to actually do?

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LibreOffice packages

[Josh Boyer]

On Sat, Jun 3, 2023 at 3:56 AM Vitaly Zaitsev via devel
 wrote:
>
> On 03/06/2023 02:46, Leslie Satenstein via devel wrote:
> > No LibreOffice, no continuation with Fedora. LO better be there with
> > F39. Without it, all you have is Firefox. It is not enough to keep
> > Fedora Diehards from jumping to another popular distribution.
>
> Yes, Fedora is dying. Slow, but imminent. IBM doesn't want to keep it in
> a good condition, so they fired a lot of good engineers. It's very sad.
> I have been using it for years.

I'm not sure what led you to the conclusion that IBM has anything to
do with this or that "they fired a lot of good engineers".  I don't
see evidence of either being the case.

Please don't state your own assumptions as facts.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Josh Boyer]

On Thu, May 25, 2023 at 7:58 AM Kevin Kofler via devel
 wrote:
>
> Joe Doss wrote:
> > On 5/24/23 4:49 PM, Mattia Verga via devel wrote:
> >> Wait, what?? Someone at RH wakes up in the morning and decides to cut
> >> one of the key roles (or better, THE) of Fedora community and this goes
> >> completely unannounced, unnoticed and without any backup plan?
> >>
> >> I have seen other dumb decisions by RH about Fedora in the past, but I
> >> think this is the greatest one, both for Ben's role and for their person.
> >
> > I totally agree. I am pretty upset that they chose to let bcotton go.
> > His work was top notch and I will miss him and his contributions. Losing
> > him as the Fedora Program Manager is going to be very impacting to the
> > project in the short to medium term. We are already seeing things fall
> > through the cracks. What a short-sighted decision.
> >
> > Also finding out about this in a random thread is a bummer. There should
> > have been an announcement.
> >
> > To the RH powers that be that made this decision. You chuckleheads dun
> > goofed.
>
> That is the kind of braindead decisions that was to be expected after the
> sellout to the mega(dis)trust IBM.

This is neither accurate nor helpful to any conversation.  If you want
to throw invectives at people or companies, please do it elsewhere.

josh

> The total lack of advance communication (because they want to lay off their
> employees as quietly as possible in order not to scare potential
> shareholders?) just makes it worse.
>
> Kevin Kofler
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Josh Boyer]

On Wed, May 24, 2023 at 9:34 PM Gary Buhrmaster
 wrote:
>
> On Wed, May 24, 2023 at 9:50 PM Mattia Verga via devel
>  wrote:
>
> > Wait, what?? Someone at RH wakes up in the morning and decides to cut
> > one of the key roles (or better, THE) of Fedora community and this goes
> > completely unannounced, unnoticed and without any backup plan?
>
> I do understand why RedHat itself will not announce
> who got laid off, but the Council members should have
> been informed (I hope!) at the time, and should have
> worked on an announcement to the community, even
> if all they could say was "stay tuned, we are working
> it out".

The Council members were not informed in advance.  They found out
about the layoffs at the same time the public did, and also found out
about Ben's specific role only after he informed others he was
impacted.

> I would like to believe this will be a learning
> opportunity for the Council to improve their
> communications for the next time something
> impacts their group (and the Fedora community).

I do believe they are working on something, but you're laying blame at
the feet of the wrong people here.  The Council was blindsided like
everyone else.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Josh Boyer]

On Wed, May 24, 2023 at 3:23 PM Tom Stellard  wrote:
>
> On 5/24/23 12:19, Josh Boyer wrote:
> > On Wed, May 24, 2023 at 2:55 PM Peter Boy  wrote:
> >>
> >>
> >>
> >>> Am 24.05.2023 um 20:30 schrieb Chris Murphy :
> >>>
> >>> I'm pretty sure we no longer have a program manager?
> >>
> >> What’s that about?
> >
> > Red Hat recently announced a round of layoffs[1] and the Fedora
> > Program Manager role was impacted.
> >
> > Ben posted this blog: 
> > https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/
> >
>
> What's the process for selecting a new Program Manager?

The Fedora Program Manager was a paid Red Hat position before.  We do
not have a process defined for selecting one from the community.
There are a few people trying to spread the responsibilities around in
the meantime.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Election Status?

[Josh Boyer]

On Wed, May 24, 2023 at 2:55 PM Peter Boy  wrote:
>
>
>
> > Am 24.05.2023 um 20:30 schrieb Chris Murphy :
> >
> > I'm pretty sure we no longer have a program manager?
>
> What’s that about?

Red Hat recently announced a round of layoffs[1] and the Fedora
Program Manager role was impacted.

Ben posted this blog: https://funnelfiasco.com/blog/2023/05/12/inaction-bcotton/

josh

[1] https://www.redhat.com/en/blog/message-red-hat-associates-today
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: RHEL 8 Python 3.8 EOL

[Josh Boyer]

On Thu, May 18, 2023 at 3:17 AM Miro Hrončok  wrote:
>
> Hello folks,
>
> just a heads up that according to
> https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle#rhel8_application_streams
> the Python 3.8 application stream will be retired in May 2023 (I suppose at 
> the
> end).

Yes, at the end of May.

For clarity, the content will still be available however it will no
longer be updated or supported.

Miro, do you have recommendations to the EPEL maintainers?  E.g.
Upgrade to python39/python3.11, or use the system-level python?

josh

> $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3.8 --whatrequires
> 'python(abi) = 3.8' --whatrequires 'libpython3.8.so.1.0()(64bit)' | pkgname
> git-revise
> openscap-report
> pagure-ev
> pagure-milters
> python38-click
> python38-dateutil
> python38-freezegun
> python38-git-revise
> python38-hvac
> python38-hypothesis
> python38-itsdangerous
> python38-jmespath
> python38-jsonschema
> python38-ldap
> python38-netaddr
> python38-netaddr-shell
> python38-ntlm-auth
> python38-pyasn1
> python38-pyasn1-modules
> python38-pynetbox
> python38-pyrsistent
> python38-pytest-runner
> python38-radicale3
> python38-requests_ntlm
> python38-setuptools_scm
> python38-textfsm
> python38-toml
> python38-winrm
> python38-xmltodict
> radicale3
>
> $ repoquery ... --source | pkgname
> openscap-report
> pagure
> python-git-revise
> python38-click-epel
> python38-dateutil-epel
> python38-freezegun-epel
> python38-hvac
> python38-hypothesis-epel
> python38-itsdangerous-epel
> python38-jmespath
> python38-jsonschema-epel
> python38-ldap-epel
> python38-netaddr-epel
> python38-ntlm-auth-epel
> python38-pyasn1-epel
> python38-pynetbox
> python38-pyrsistent-epel
> python38-pytest-runner-epel
> python38-requests_ntlm-epel
> python38-setuptools_scm-epel
> python38-textfsm-epel
> python38-toml-epel
> python38-winrm-epel
> python38-xmltodict-epel
> radicale
>
> --
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Ansible in EPEL 9

[Josh Boyer]

On Tue, May 9, 2023 at 11:24 PM Maxwell G  wrote:
>
> Hello EPEL users and developers,
>
>
> RHEL 9.2 was released today,
> so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
> 9.2's ansible-core bump from 2.13.3 to 2.14.2.
> Each ansible major version is tied to a specific major version of
> ansible-core, and we keep them in sync.
>
> Along with this change, RHEL 9.2 builds ansible-core for the python3.11
> stack instead of the default python3 (3.9) stack.
> Therefore, ansible in EPEL now built for python3.11 as well.
>
> Here is the Bodhi update: 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
> Please help test and give karma.

Thank you for your efforts and clear communication!  It is very much
appreciated.

josh

>
> Until this update is pushed to stable, you may receive an error like
> this when running dnf upgrade
>
> ```
> Error:
>  Problem: package ansible-6.3.0-2.el9.noarch requires 
> python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be 
> installed
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install both ansible-core-2.14.2-4.el9.x86_64 and 
> ansible-core-2.13.3-1.el9.x86_64
>   - cannot install the best update candidate for package 
> ansible-core-2.13.3-2.el9_1.x86_64
>   - cannot install the best update candidate for package 
> ansible-6.3.0-2.el9.noarch
> (try to add '--allowerasing' to command line to replace conflicting packages 
> or '--skip-broken' to skip uninstallable packages or '--nobest' to use not 
> only best candidate packages)
> ```
>
> There are a couple potential solutions:
>
> 1. Run
>  $ dnf upgrade --exclude ansible-core
>to skip ansible-core and upgrade everything else.
> 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to 
> install
>ansible 7.2.0 from testing with
>  $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
>and then run a plain `dnf upgrade` as usual.
>
>
> --
> Happy automating,
>
>
> Maxwell G (@gotmax23)
> Pronouns: He/They
> ___
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Josh Boyer]

On Wed, Apr 26, 2023 at 8:43 AM Kevin Kofler via devel
 wrote:
>
> Josh Boyer wrote:
> > Ah.  May or may not.  That gives me hope at least.
>
> Well, considering that we have hundreds of existing contributors, who all
> may or may not be willing to adapt to a platform that is clearly not
> designed for them (Discourse is very strongly newbie-centric, see the
> "achievements" and all the other hand-holding), I think it is safe to assume
> that several important contributors WILL leave, tone down their
> participation, and/or miss some important communication (leading to breakage
> in the distribution, e.g., broken dependencies making it into Rawhide) if
> Fedora makes the switch.
>
> > I don't think it's a double standard.  I think people that already
> > know how Fedora development and contribution works are inherently in a
> > better position to adapt to something new, whereas net-new
> > contributors are unlikely to even start based on an email driven
> > practice.
>
> And as I already answered, I think this is completely backwards. If you want
> to newly join a project, you learn their way to do things and adapt to it.
> If, on the other hand, you are already involved in a project and have
> workflows that work for you, any forced change to something perceived as a
> regression will annoy you and make you want to leave.

I think you and I fundamentally disagree on this and that's OK.  I'm
not trying to convince you.  I was trying to understand your stance on
why you'd potentially leave and express the reasons why I think it's
worth it.

We'll have to end our conversation here, because we've both stated
clearly where we stand and I respect that you and I are simply not
aligned.  Thank you for your thoughts.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Josh Boyer]

On Tue, Apr 25, 2023 at 10:42 PM Kevin Kofler via devel
 wrote:
>
> Josh Boyer wrote:
> > I want to make sure I understand that statement.  You're saying you
> > will actively walk away from Fedora because you would have to change
> > the manner in which you discuss things?
>
> I am saying I and many other existing contributors may or may not walk away
> from Fedora entirely, and even if not, may reduce our interaction with
> Fedora, due to being forced to use a discussion tool that does not support
> our workflows.

Ah.  May or may not.  That gives me hope at least.

> Heck, it does not even work in my browser (Falkon) without ugly workarounds.
> (https://discuss.kde.org/t/discuss-kde-org-cannot-be-accessed-by-konqueror/548)
>
> > That's certainly a choice one could make.  Personally, I would not
> > prioritize keeping my bespoke email setup intact over working with a
> > community on a project I care about.  If there's even a remote
> > possibility moving to Discourse will attract more contributors to
> > Fedora then I'd happily learn how to deal with it.  Change is
> > difficult, but in the end it's something we're all capable of.
>
> I do not understand this double standard: You and several others are
> expecting new contributors to walk away from Fedora due to the manner in
> which we discuss things, but in the same time act surprised when warned that
> existing contributors are likely to do exactly that. In fact, we have much
> more reason to do so because the new workflow is a regression, and forcing
> it on us over our objections actively tells us we are no longer welcome.

I don't think it's a double standard.  I think people that already
know how Fedora development and contribution works are inherently in a
better position to adapt to something new, whereas net-new
contributors are unlikely to even start based on an email driven
practice.  It's a barrier to entry problem.  If we, as the experienced
and capable contributor base, can adapt to something and lower the
barrier to entry then it benefits us all.

To be clear, I do not like forums.  Discourse is perhaps the best
forum platform I've used, but that doesn't mean I like it.  What I
dislike more than forum software is knowing we're leaving people that
could do great things and spread more awareness of Fedora simply
because we've ossified on a communication platform that is hard to
discover and consume.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Josh Boyer]

On Mon, Apr 24, 2023 at 10:21 PM Kevin Kofler via devel
 wrote:
>
> Kamil Paral wrote:
> > I've spent more than a decade perfecting my email filters and I have a
> > setup that works for me very well. I dislike certain aspects of mailing
> > lists (cross-posting, top-posting, reply-to, etc, which just can't work
> > well when everyone has to be vigilant all the time to do things right),
> > but I *like* my existing setup and processes. But that's me, us, the old
> > timers.
>
> But that is exactly why it is an absurd idea to move away from mailing
> lists. Fedora will *lose* all the existing contributors like you or me.

I want to make sure I understand that statement.  You're saying you
will actively walk away from Fedora because you would have to change
the manner in which you discuss things?

That's certainly a choice one could make.  Personally, I would not
prioritize keeping my bespoke email setup intact over working with a
community on a project I care about.  If there's even a remote
possibility moving to Discourse will attract more contributors to
Fedora then I'd happily learn how to deal with it.  Change is
difficult, but in the end it's something we're all capable of.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: Future of ClamAV on EPEL ?

[Josh Boyer]

On Tue, Mar 7, 2023 at 3:00 PM Andrew C Aitchison
 wrote:
>
>
> This question is prompted by a question from kumar bava about EPEL7
> on the ClamaAV Users list:
> https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html
>
> EPEL currently ship the anti-virus ClamAV v0.103.8
>
> From September ClamAV 0.103 will be EOL, and all
> supported versions will require Rust.
>
> Rust is available on RHEL 7, 8 and 9 as a part of Red Hat Developer Tools.

Small clarification: Rust is available directly in RHEL 8 and 9, not
as part of Red Hat Developer Tools.  I mention it because it means the
EPEL considerations are different in terms of buildroot availability
and requirements.

josh

> Does that mean that EPEL will or will not be able to continue packaging
> ClamAV ?
>
> ClamAV do provide rpms, so it may not be the end of the world if
> ClamAV disappears from EPEL, but the details of the packing,
> especially config locations and defaults may be different.
>
> Thanks,
>
> --
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring Bottles in favor of Flatpak provided by upstream

[Josh Boyer]

On Wed, Jan 25, 2023 at 5:56 AM Vít Ondruch  wrote:
>
> I am not user of Bottles so I won't complain about this particular case,
> but the push towards (upstream) Flatpaks is unfortunate :/

Can you elaborate on why you feel that way?

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: gcc ee this bug on RHEL9 , How we reach RHEL team ?

[Josh Boyer]

On Tue, Jan 24, 2023 at 9:26 AM Troy Dawson  wrote:
>
> Just so people don't need to go to the bug.
> This has already been reported for RHEL 9.
> https://bugzilla.redhat.com/show_bug.cgi?id=2140266
>
> If I understand "Approved Release" correctly, the fix will come out in RHEL 
> 9.2

Most people can't see the field you're referencing.  The bug is in
VERIFIED state though, which means anyone should be able to test gcc
in CentOS Stream 9 and confirm if it's fixed right now.

josh
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: gcc bug on RHEL9 , How we reach RHEL team ?

[Josh Boyer]

On Tue, Jan 24, 2023 at 7:01 AM Sérgio Basto  wrote:
>
> Hi,
> Sorry, now subject is correct, the gcc have one patch for the error
> above, that is seen on rhel 9
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1996330#c14

If you believe this is present in RHEL 9, please clone the bug to the
Red Hat Enterprise Linux 9 bugzilla family.

josh
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: List of long term FTBFS packages to be retired in February

[Josh Boyer]

On Wed, Jan 11, 2023 at 2:02 PM Miro Hrončok  wrote:
>
> On 11. 01. 23 17:52, Mattia Verga via devel wrote:
> > Il 11/01/23 13:58, Miro Hrončok ha scritto:
> >> sigulkevin, mitr
> >
> > Retiring this would blow up Fedora infrastructure... the FTB/FTI is
> > being worked on, but it depends on python-nss to be un-retired and the
> > package review for that is in progress (just approved a few days ago).
> >
> > Can you just remove it from the list to stay on the safe side?
>
> Retiring it from rawhide would not change anything in the infrastructure at 
> all
> considering the package does not currently even install.

Thank you for saying this.  I know Mattia's concerns are valid in the
long run, but we tend to lean into hyperbole a lot on the list and I
think we'd be better off avoiding it when we can :)

Mattia, thank you also for raising the larger concern.

josh

> I trust it will be fixed in time, I am watching the nss review request (it has
> been approved).
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
 wrote:
>
> On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
> >
> > On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
> > >
> > > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  
> > > wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > >  wrote:
> > > > >
> > > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > > > >
> > > > > > > Summary from multi-year discussions/feedback on this:
> > > > > > > - We don't have proper hardware to put into the data center that 
> > > > > > > holds
> > > > > > > servers used by Fedora infrastructure.
> > > > > > Right.  dev boards are not the solution here.  It's got to be 
> > > > > > something
> > > > > > that can be racked and with enough performance to matter.
> > > > > >
> > > > > > > - Not enough single and multi thread performance to avoid large 
> > > > > > > impact
> > > > > > > to Fedora development.
> > > > > > Agreed.   Returning to a situation like we had with armv7 isn't
> > > > > > acceptable IMHO.
> > > > > >
> > > > > > >
> > > > > > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > > > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On 
> > > > > > > a
> > > > > > > good day we can keep up (if the builds aren't too large, e.g. 
> > > > > > > GCC). We
> > > > > > > don't really run Bodhi thus once package is built it's immediately
> > > > > > > available. We run a very minimal setup right now (ideas to expand
> > > > > > > that).
> > > > > > It's fantastic we've got that far.  But clearly it's not viable 
> > > > > > long term.
> > > > >
> > > > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > > > cannot move forward until the proper hardware (and things around it)
> > > > > becomes available.
> > > > >
> > > > > >
> > > > > >
> > > > > > > Another news is that Fedora/RISCV Koji server (
> > > > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra 
> > > > > > > owned
> > > > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > > > Excellent.  I'll have to update my chroots and containers as the F38
> > > > > > bits start appearing.
> > > > >
> > > > > I am still tweaking the server configuration, but I should be ready
> > > > > for mass building soonish.
> > > > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > > > happen soon (I think).
> > > > >
> > > > > >
> > > > > > >
> > > > > > > 2023 is potentially a transition year. Ventana Veyron V1 
> > > > > > > Development
> > > > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should 
> > > > > > > also
> > > > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I 
> > > > > > > am not
> > > > > > > yet convinced about their upstream support efforts (TBD).
> > > > > > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > > > > > significant insight into the T-HEAD efforts other than they do work 
> > > > > > a
> > > > > > fair amount with VRULL on compiler and related technology.
> > > > >
> > > > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > > > potentially kernel side for a few months now. This makes them much
> > > > > more optimistic about their SoC/HW support in general.
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > If there is away to acquire Veyron V1 Development Platform I 
> > > > > > > w

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
>
> On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
> >
> > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> >  wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> > > >
> > > >
> > > >
> > > > On 1/6/23 23:41, David Abdurachmanov wrote:
> > > > >
> > > > > Summary from multi-year discussions/feedback on this:
> > > > > - We don't have proper hardware to put into the data center that holds
> > > > > servers used by Fedora infrastructure.
> > > > Right.  dev boards are not the solution here.  It's got to be something
> > > > that can be racked and with enough performance to matter.
> > > >
> > > > > - Not enough single and multi thread performance to avoid large impact
> > > > > to Fedora development.
> > > > Agreed.   Returning to a situation like we had with armv7 isn't
> > > > acceptable IMHO.
> > > >
> > > > >
> > > > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > > > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > > > > don't really run Bodhi thus once package is built it's immediately
> > > > > available. We run a very minimal setup right now (ideas to expand
> > > > > that).
> > > > It's fantastic we've got that far.  But clearly it's not viable long 
> > > > term.
> > >
> > > Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> > > cannot move forward until the proper hardware (and things around it)
> > > becomes available.
> > >
> > > >
> > > >
> > > > > Another news is that Fedora/RISCV Koji server (
> > > > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > > > server. We are about to start work on Fedora 38/Rawhide.
> > > > Excellent.  I'll have to update my chroots and containers as the F38
> > > > bits start appearing.
> > >
> > > I am still tweaking the server configuration, but I should be ready
> > > for mass building soonish.
> > > I might want to wait for GCC 13 to land in Rawhide, which should
> > > happen soon (I think).
> > >
> > > >
> > > > >
> > > > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > > > yet convinced about their upstream support efforts (TBD).
> > > > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > > > significant insight into the T-HEAD efforts other than they do work a
> > > > fair amount with VRULL on compiler and related technology.
> > >
> > > I noticed that VRULL has been involved with T-HEAD on GCC and
> > > potentially kernel side for a few months now. This makes them much
> > > more optimistic about their SoC/HW support in general.
> > >
> > > >
> > > >
> > > > >
> > > > > If there is away to acquire Veyron V1 Development Platform I would be
> > > > > interested to talk, and figure out what that would take. Such hardware
> > > > > would be a game charger, and I do trust Ventana regarding upstream
> > > > > support :)
> > > > I'll be pushing to make systems available to Fedora and the GCC farm,
> > > > but in general Ventana is more aligned towards Ubuntu.  My goal is to
> > > > have Fedora and Ubuntu on equal footing as quickly as possible.
> > >
> > > We have been trying to get stuff into GCC Compiler Farm for years now.
> > > There are a couple of boards IIRC. There are additional requirements
> > > on the software side (well, distributions) that we couldn't provide
> > > for quite some time.
> > >
> > > >
> > > > I do know rackable systems will be limited -- there's one particular
> > > > component needed on the rackable systems that is in very short supply.
> > > > We've got multiple orders in, but quantities are limited and lead times
> > > > are absolutely insane.
> > >
> > > FYI, I think, the new aarch64 builders

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
 wrote:
>
> On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  wrote:
> >
> >
> >
> > On 1/6/23 23:41, David Abdurachmanov wrote:
> > >
> > > Summary from multi-year discussions/feedback on this:
> > > - We don't have proper hardware to put into the data center that holds
> > > servers used by Fedora infrastructure.
> > Right.  dev boards are not the solution here.  It's got to be something
> > that can be racked and with enough performance to matter.
> >
> > > - Not enough single and multi thread performance to avoid large impact
> > > to Fedora development.
> > Agreed.   Returning to a situation like we had with armv7 isn't
> > acceptable IMHO.
> >
> > >
> > > Other than that Fedora/RISCV 37 is the first Fedora version to be
> > > built fully natively using 20+ SiFive HiFive Unmatched boards. On a
> > > good day we can keep up (if the builds aren't too large, e.g. GCC). We
> > > don't really run Bodhi thus once package is built it's immediately
> > > available. We run a very minimal setup right now (ideas to expand
> > > that).
> > It's fantastic we've got that far.  But clearly it's not viable long term.
>
> Agreed. We have been cooking Fedora/RISCV since 2016, but we really
> cannot move forward until the proper hardware (and things around it)
> becomes available.
>
> >
> >
> > > Another news is that Fedora/RISCV Koji server (
> > > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned
> > > server. We are about to start work on Fedora 38/Rawhide.
> > Excellent.  I'll have to update my chroots and containers as the F38
> > bits start appearing.
>
> I am still tweaking the server configuration, but I should be ready
> for mass building soonish.
> I might want to wait for GCC 13 to land in Rawhide, which should
> happen soon (I think).
>
> >
> > >
> > > 2023 is potentially a transition year. Ventana Veyron V1 Development
> > > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also
> > > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not
> > > yet convinced about their upstream support efforts (TBD).
> > Yes Veyron-v1 will have a BMC and will be rackable.   I have no
> > significant insight into the T-HEAD efforts other than they do work a
> > fair amount with VRULL on compiler and related technology.
>
> I noticed that VRULL has been involved with T-HEAD on GCC and
> potentially kernel side for a few months now. This makes them much
> more optimistic about their SoC/HW support in general.
>
> >
> >
> > >
> > > If there is away to acquire Veyron V1 Development Platform I would be
> > > interested to talk, and figure out what that would take. Such hardware
> > > would be a game charger, and I do trust Ventana regarding upstream
> > > support :)
> > I'll be pushing to make systems available to Fedora and the GCC farm,
> > but in general Ventana is more aligned towards Ubuntu.  My goal is to
> > have Fedora and Ubuntu on equal footing as quickly as possible.
>
> We have been trying to get stuff into GCC Compiler Farm for years now.
> There are a couple of boards IIRC. There are additional requirements
> on the software side (well, distributions) that we couldn't provide
> for quite some time.
>
> >
> > I do know rackable systems will be limited -- there's one particular
> > component needed on the rackable systems that is in very short supply.
> > We've got multiple orders in, but quantities are limited and lead times
> > are absolutely insane.
>
> FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G
> swap. The older machines had 8G/core setup. There seems to be 8 (?)
> servers with 80 cores, but so far only 40-50 builders are enabled (no
> overcommitting on CPU as that's not a great idea [based on my own
> experience]).
>
> I expect Veyron V1 to deliver a decent single and multi thread
> performance, but we will need a lot of them. Probably 20-25 systems if
> we assume a similar configuration as aarch64 builders (8-core, 32-64G
> of RAM, 100-200G for storage). RAM and storage are cheap, but systems
> will continue to be a problem. If we could somehow get to this level
> we could stop investing into SBCs as they are stop-gap solutions for
> builders.
>
> Based on some guesses there isn't a lot of time either. I would love
> to bootstrap CentOS Stream 10. It would be nice to have Fedora +
> riscv64 in a good shape before that happens, but probably unrealistic.

It is very unlikely that CentOS Stream 10 will include RISC-V as a
fully included architecture.  Perhaps via a CentOS Stream SIG.

josh
___
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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Josh Boyer]

On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa  wrote:
>
> On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
> >
> > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> > >
> > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > > >
> > > It's not only about loosing attributions. There will be NEVRA 
> > > discrepancies in
> > > RHEL:
> > >
> > > Different number of commits will mean different release numbers. That will
> > > break package interdependencies which requires a specific release number. 
> > > E.g
> > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus 
> > > Fedora foo
> > > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > > break.
> >
> > That's a good point.  The design works well within a single,
> > continuous development environment such as Fedora's but any usage of
> > the sources outside of that, either by importing SRPMs or by importing
> > subsets of dist-git, seems like it would struggle.  Does something
> > like OBS suffer from the same issue?  Seems it would, but I don't know
> > much about how OBS works.
> >
>
> OBS parses the spec file on import and sets the Release value auto
> increment based on the value of the Release field at import time. Then
> when you do a version bump, it resets the Release field back to 1.
>
> OBS does not (by default) let you control the Release field, though a
> project/instance admin can change these defaults. By default, OBS
> overrides the Release value and does its own increments with a commit
> counter and a build counter, formatted as such: .

Thank you!

josh

>
> If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
> build. Any triggered rebuilds will bump the build counter. When you
> bump to foo-6, then the new build will be foo-6-1.1.
>
> If you want to tweak OBS to retain the spec file Release value, you
> can configure the project or the instance entirely to use another
> scheme. For example, for the OBS project that obsctl is released
> to[1], the scheme is +obs.. That allows the
> original spec file's Release value to remain, while allowing OBS'
> generated data to be appended. You can see this in motion with a build
> of obsctl[2], where you can see that we've done the 6th rebuild of the
> 11th checkin of commit b6e1e99.
>
> [1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
> [2]: 
> https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Josh Boyer]

On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
>
> V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > that they don't truncate or eliminate the Git history anymore? Because I 
> > would
> > personally be very displeased if my historical attribution went away
> > because of broken processes like the one used to fork all the Fedora
> > Linux 34 packages for CentOS Stream 9.
> >
> It's not only about loosing attributions. There will be NEVRA discrepancies in
> RHEL:
>
> Different number of commits will mean different release numbers. That will
> break package interdependencies which requires a specific release number. E.g
> foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
> will strengthen the dependency with "Requires: bar >= 1-2". However, after
> importing to RHEL, bar will become bar-1-1. The dependency from foo will
> break.

That's a good point.  The design works well within a single,
continuous development environment such as Fedora's but any usage of
the sources outside of that, either by importing SRPMs or by importing
subsets of dist-git, seems like it would struggle.  Does something
like OBS suffer from the same issue?  Seems it would, but I don't know
much about how OBS works.

> Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will
> contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
> the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
> schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
> maintainers to revert rpmautospec to manual numbering for minor RHEL updates.

Or automation grows the ability to support that kind of versioning, if
it were to be used in RHEL.

> None of these issues are Fedora issues. But considering the ecosystems
> wholistically, the proposed rpmautospec propotion will add a friction.

Nothing is free, that's for sure :)

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Josh Boyer]

On Mon, Jan 2, 2023 at 5:56 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> Gaps in release numbering are just not neat. To me, they create an
> unnecessary confusion. Each bump in Release field should have a
> corresponding build in koji and it makes me wonder why if it doesn't.

Which means you go and investigate and learn why, which is a sane
thing to do if you want to know that information.

Equating Release values with builds is folly unless the build system
automatically does a build for every commit.  If it did, it could
autogenerate the Release value and probably the changelog oh wait
:)

josh

> > Or it is my origin in BASIC that I am not afraid of that? We numbered
> > the lines as a multiply of 5 or 10. :)
>
> I've written code in BASIC back in the day. This comment is irrelevant
> to the issue at hand.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Josh Boyer]

On Mon, Jan 2, 2023 at 4:43 AM Maxwell G via devel
 wrote:
>
> On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> The release number shows how many builds of the same version have been
> made. A high release is also baseline indicator that a package/project
> is stale downstream and/or upstream. When the first build of foo v1.5.0
> is foo-1.5.0-6 because the author took the time to split up logical
> changes into separate commits, the value of that release number is lost.

The heuristics you are describing are assumptions, not facts.  They
are decent assumptions in the context of the Fedora project, but they
don't necessarily actually apply equally across the package set.

Personally, I think we should avoid tying any assumption to the
Release value and simply realize that it is the mechanism used to
present an update to a system.  Guessing what foo-1.5.0-6 vs.
foo-1.5.0-560 means based on what we think Release denotes is kind of
dangerous.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Josh Boyer]

On Fri, Dec 30, 2022 at 5:17 PM Neal Gompa  wrote:
>
> On Fri, Dec 30, 2022 at 4:48 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa wrote:
> > > On Fri, Dec 30, 2022 at 2:02 PM Ben Cotton  wrote:
> > > > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > that they don't truncate or eliminate the Git history anymore? Because I 
> > > would
> > > personally be very displeased if my historical attribution went away
> > > because of broken processes like the one used to fork all the Fedora
> > > Linux 34 packages for CentOS Stream 9.
> >
> > I can't speak for the RH folks who do the forking… It'd be great if
> > somebody who knows how that's done could answer.
> >
> > Fedora is already using rpmautospec widely enough that (if it was to
> > be problem at all), it must already be a problem.
> >
> > At the level of specific solutions, obviously the obvious answer is to
> > keep the git history. It's in general a great of source of information
> > and discarding that is just an error. But if somebody were really to do 
> > that,
> > it's fairly trivial to undo the conversion and get a static changelog
> > again by inserting the output of 'rpmautospec changelog' in the %changelog
> > section.
> >
>
> As they are the most prominent downstream we have, I would like this
> resolved before changing Fedora's defaults.
>
> At the time we branched from Fedora Linux 34, there were very few
> packages using rpmautospec and I don't think any that were kept used
> rpmautospec. Now it is very obvious it would be a problem, so I would
> like that fixed first. CentOS and RHEL infrastructure needs to account
> for it properly and not gut the Git history.

We can look into it, but at the moment this is unlikely to change on
the CentOS Stream/RHEL side.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 2:01 PM Stephen Smoogen  wrote:
>
>
>
> On Tue, 6 Dec 2022 at 13:50, Josh Boyer  wrote:
>>
>> On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>> >
>> > On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  
>> > wrote:
>> > >
>> > > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>> > > >
>> > > > On 05/12/2022 16:00, Jarek Prokop wrote:
>> > > >
>> > > >
>> > > > On 12/5/22 14:57, Peter Robinson wrote:
>> > > >
>> > > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>> > > >  wrote:
>>
>> > > I wouldn't expect them to build for a Fedora version.  I also wouldn't
>> > > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
>> > > work on Fedora either.
>> > >
>> >
>> > As a practical matter, I generally *do* expect them to be compatible
>> > at some level. RHEL is a derivative of Fedora. Otherwise it gets very
>> > difficult to use commercial software on a Fedora system. I know plenty
>> > of ISVs that have a similar expectation.
>>
>> That compatibility degrades over time though.  At this point in time,
>> with RHEL 7 being almost 9 years old, I would not expect software
>> built on RHEL 7 to work on any supported Fedora version.  If it does
>> work, that's fantastic and a testament to Fedora, but people should
>> not have that expectation.  Terry is politely asking for a policy that
>> would set that expectation.  I think the intention is good, but I
>> don't believe it to be realistic.
>>
>
> I think he would be happy with the policy spelled out in any form. Something 
> like:
>
> While the Fedora Project is the upstream of CentOS Stream and Red Hat 
> Enterprise Linux, it does not give any guarantees of its releases being 
> compatible with either. Software built in either may not work due to missing 
> dependencies, changes in kernel, compile time or library options, or similar 
> issues.

Ah!  Yes, making that clear would be good.

josh

>> To perhaps illustrate the point further, Red Hat Enterprise Linux does
>> not support applications built on version X-1 running on X unless it
>> is constrained to using a very very small set of dependencies (glibc,
>> libgcc/libstdc++, and a few smaller libraries).  Again, it may work
>> fine but the expectation and support policies set for RHEL are
>> (simplified) build on X, run on X where X is within a major version.
>> Our full documentation on this is available in the Application
>> Compatibility Guides.
>>
>> josh
>> ___
>> 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
>> Do not reply to spam, report it: 
>> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle. -- 
> Ian MacClaren
> ___
> 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
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 11:27 AM Neal Gompa  wrote:
>
> On Tue, Dec 6, 2022 at 7:54 AM Josh Boyer  wrote:
> >
> > On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
> > >
> > > On 05/12/2022 16:00, Jarek Prokop wrote:
> > >
> > >
> > > On 12/5/22 14:57, Peter Robinson wrote:
> > >
> > > On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
> > >  wrote:
> > >
> > > On 05/12/2022 12:39, Terry Barnaby wrote:
> > >
> > > I am wondering what Fedora's policy is on depreciated old shared
> > > libraries and particularly compat RPM's ?
> > >
> > > Fedora is a bleeding edge distribution. If you need old versions, you
> > > should try CentOS or RHEL.
> > >
> > > Being leading edge doesn't mean those usecases aren't relevant, one is
> > > not mutually exclusive to the other, especially when it comes to
> > > things like FPGAs etc.
> > >
> > > We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> > > gnome-boxes, and probably others I forgot).
> > > There shouldn't be a problem spinning up a graphical environment of 
> > > CentOS 7, getting EPEL and then using the tool.
> > >
> > > Maybe the tool would work using the `toolbox` utility using last known 
> > > good Fedora version for the tool.
> > > That is just my wild guess however.
> > >
> > > This is sometimes the tax for being "too" modern.
> > > If the vendor does not want to support Fedora, we can't be held 
> > > accountable to fully support their solution.
> > > Does the software work? Yes? That is great! If not, well… we can't do 
> > > much without the source code under nice FOSS license, can we.
> > >
> > > Regards,
> > > Jarek
> > >
> > > Although yes, there are things like VM's, containers etc. which we use 
> > > for old development environments all of these are, IMO, clumsy and 
> > > awkward to use and difficult to manage especially within automated build 
> > > environments that build the complete code for an embedded system with 
> > > various CPU's, FPGA's, other tools etc.
> > >
> > > I know Fedora is fairly bleeding edge (really too bleeding edge for our 
> > > uses, but others are too far behind), but there is obviously going to be 
> > > a balance here so that Fedora is still useful to as many people as 
> > > reasonably possible, hence the question on a policy.
> > >
> > > In the particular case I am talking about, libncurses*5.so, this is a 
> > > fairly common shared library used by quite a few command line tools. A 
> > > lot of external/commercial programs are built on/for Redhat7 as it is a 
> > > de-facto base Linux platform and programs built on it will likely work on 
> > > many other Linux systems. These companies are not going to build for a 
> > > version of Fedora, it changes far to fast and would require large amounts 
> > > or development/support work because of this. Some of the tools I am using 
> > > were built/shipped in Feburary 2022, so we are not talking about old 
> > > tools here.
> >
> > I wouldn't expect them to build for a Fedora version.  I also wouldn't
> > expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
> > work on Fedora either.
> >
>
> As a practical matter, I generally *do* expect them to be compatible
> at some level. RHEL is a derivative of Fedora. Otherwise it gets very
> difficult to use commercial software on a Fedora system. I know plenty
> of ISVs that have a similar expectation.

That compatibility degrades over time though.  At this point in time,
with RHEL 7 being almost 9 years old, I would not expect software
built on RHEL 7 to work on any supported Fedora version.  If it does
work, that's fantastic and a testament to Fedora, but people should
not have that expectation.  Terry is politely asking for a policy that
would set that expectation.  I think the intention is good, but I
don't believe it to be realistic.

To perhaps illustrate the point further, Red Hat Enterprise Linux does
not support applications built on version X-1 running on X unless it
is constrained to using a very very small set of dependencies (glibc,
libgcc/libstdc++, and a few smaller libraries).  Again, it may work
fine but the expectation and support policies set for RHEL are
(simplified) build on X, run on X where X is within a major version.
Our full documentation on this is available in the Application
Compatibility Guides.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Policy on supporting old and external software packages and compat RPMS

[Josh Boyer]

On Tue, Dec 6, 2022 at 1:43 AM Terry Barnaby  wrote:
>
> On 05/12/2022 16:00, Jarek Prokop wrote:
>
>
> On 12/5/22 14:57, Peter Robinson wrote:
>
> On Mon, Dec 5, 2022 at 12:01 PM Vitaly Zaitsev via devel
>  wrote:
>
> On 05/12/2022 12:39, Terry Barnaby wrote:
>
> I am wondering what Fedora's policy is on depreciated old shared
> libraries and particularly compat RPM's ?
>
> Fedora is a bleeding edge distribution. If you need old versions, you
> should try CentOS or RHEL.
>
> Being leading edge doesn't mean those usecases aren't relevant, one is
> not mutually exclusive to the other, especially when it comes to
> things like FPGAs etc.
>
> We still have myriad of VM orchestrating solutions (libvirt, vagrant, 
> gnome-boxes, and probably others I forgot).
> There shouldn't be a problem spinning up a graphical environment of CentOS 7, 
> getting EPEL and then using the tool.
>
> Maybe the tool would work using the `toolbox` utility using last known good 
> Fedora version for the tool.
> That is just my wild guess however.
>
> This is sometimes the tax for being "too" modern.
> If the vendor does not want to support Fedora, we can't be held accountable 
> to fully support their solution.
> Does the software work? Yes? That is great! If not, well… we can't do much 
> without the source code under nice FOSS license, can we.
>
> Regards,
> Jarek
>
> Although yes, there are things like VM's, containers etc. which we use for 
> old development environments all of these are, IMO, clumsy and awkward to use 
> and difficult to manage especially within automated build environments that 
> build the complete code for an embedded system with various CPU's, FPGA's, 
> other tools etc.
>
> I know Fedora is fairly bleeding edge (really too bleeding edge for our uses, 
> but others are too far behind), but there is obviously going to be a balance 
> here so that Fedora is still useful to as many people as reasonably possible, 
> hence the question on a policy.
>
> In the particular case I am talking about, libncurses*5.so, this is a fairly 
> common shared library used by quite a few command line tools. A lot of 
> external/commercial programs are built on/for Redhat7 as it is a de-facto 
> base Linux platform and programs built on it will likely work on many other 
> Linux systems. These companies are not going to build for a version of 
> Fedora, it changes far to fast and would require large amounts or 
> development/support work because of this. Some of the tools I am using were 
> built/shipped in Feburary 2022, so we are not talking about old tools here.

I wouldn't expect them to build for a Fedora version.  I also wouldn't
expect ISV software built against Red Hat Enterprise Linux 7 (or 8) to
work on Fedora either.

> My view is that compat versions of the commonly used shared libraries for 
> programs that are used on Redhat7 should be kept available until most people 
> are not producing programs for that system at least +nyears and then I guess 
> Redhat8 once that really becomes a core base platform that external people 
> use. A core list of these (there are only a few) could be kept somewhere and 
> when one is to be depreciated, or users see problems when Fedora is updated,  
> a decision on this can be then made with that info. This would keep the 
> Fedora system relevant for more users needs without too much work. In the 
> case of ncurses, it is really just putting back into the SPEC file that which 
> was removed for F37 plus the extra storage on mirrors for the compat RPM's.

As a data point, Red Hat Enterprise Linux 9 does not provide
ncurses-compat-libs.  If you can, it would be good to ask your ISVs to
provide a timeline when they will migrate off of a very old version of
ncurses.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Replacing GNOME Disks with Blivet GUI in comps' admin-tools?

[Josh Boyer]

On Tue, Oct 18, 2022 at 9:37 AM Matthew Miller  wrote:
>
> On Sun, Oct 09, 2022 at 05:17:29AM +0200, Kevin Kofler via devel wrote:
> > IMHO, we need a proper solution for the general comps issue rather than that
> > half-baked compromise that does not really improve the situation. KDE Plasma
>
> I agree -- comps has a lot of problems which limit our flexibility, and
> doesn't really even expose useful collections to users. I'd love to see a
> modern replacement.

I think it would be interesting to replace it with Colin's OS
Container ideas.  Want KDE?  Install the KDE OS container layer.
Creation of that is in a container file.

That's a departure from traditional installations, but it's still
interesting.  The rub here is that comps isn't well loved, but it's
not very complicated either.  It's a list of packages associated with
a thing, and our tools know how to interpret it.  A modern replacement
for "a list of things" by itself isn't going to be very ground
breaking.  Changing how we think about and deploy the OS gives us more
interesting options.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Copr delete-by-default expiration policy still unacceptable

[Josh Boyer]

On Thu, Oct 13, 2022 at 11:04 AM Gary Buhrmaster
 wrote:
>
> On Thu, Oct 13, 2022 at 2:25 PM Josh Boyer  wrote:
>
> > Would you be willing to pay for that feature?
>
> A "freemium" COPR service?
>
> I suspect that that would be such a
> niche service that the cost per user
> (to pay for the overheads to create
> and maintain it) would not be
> acceptable to anyone.

I find that statement to be... ironic.  We're already running a free
COPR service and paying for the overhead to create and maintain it.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Copr delete-by-default expiration policy still unacceptable

[Josh Boyer]

On Thu, Oct 13, 2022 at 10:48 AM Kevin Kofler via devel
 wrote:
>
> Josh Boyer wrote:
> > Would you be willing to pay for that feature?
>
> Probably not, because at that point, it would probably be cheaper to just
> set up a mirror or even a full-fledged build system on a VPS somewhere. Or
> even to use OBS, though I do not know what their retention policies for old
> repositories are (i.e., whether they are any better or even worse).

Ok.  Then perhaps you should pursue the mirror idea to solve your
needs.  Putting that into a cloud storage bucket seems like it would
give you what you want.

> What makes Copr so interesting is that it is offered at no cost to all
> Fedora contributors. But it has always been treated as an unloved stepchild
> by Red Hat and has never received the kind of resources, e.g., OBS has.
> Though it is still better than what smaller distributions like Arch are able
> to offer, where, e.g., the AUR only allows publishing the source PKGBUILD
> files and no binaries at all.

Yes, COPR is great.  But "indefinite storage" or "user defined
storage" is not a core tenant of what it is for.  Keeping it free
while iterating on useful features requires limitations elsewhere.

To be clear, I am in no way suggesting COPR should ever move to a
paid-for model.  I'm just highlighting that it's a free service that
has operating costs and budget and it is reasonable to limit that in
some ways.

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Copr delete-by-default expiration policy still unacceptable

[Josh Boyer]

On Thu, Oct 13, 2022 at 8:41 AM Kevin Kofler via devel
 wrote:
>
> Miroslav Suchý wrote:
> > Dne 13. 10. 22 v 6:12 Kevin Kofler via devel napsal(a):
> >> I am really angry at Copr's expiration policy once again. It looks like I
> >> missed the deadline to renew the expired chroots (I still do not get any
> >> notification mails, they end up eaten in a spam filter somewhere), so
> >> once again a lot of data was deleted forever with no way to recover it.
> > What is your proposal then? The resources are not infinite.
>
> At least allow the opt-out per maintainer.
>
> I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and
> then evaluate how many maintainers actually check that checkbox and how much
> resource usage is actually caused by it. Then after a year or two, decide
> whether to keep the checkbox or revert to the current status quo. Or drop it
> sooner if you really run out of disk space as quickly as you seem to expect.

Would you be willing to pay for that feature?

josh
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

[Josh Boyer]

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Make DNF5 the new default packaging tool. The change will replace DNF,
> LIBDNF, and DNF-AUTOMATIC with the new DNF5 and new Libdnf5 library.
> It is a second step after
> https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf.
>
> == Owner ==
> * Name: [[User:jmracek| Jaroslav Mracek]]
> * Email: jmra...@redhat.com
>
>
> == Detailed Description ==
> The new DNF5 will provide a significant improvement in user
> experiences and performance. The replacement is the second step in
> upgrade of Fedora Software Management stack. Without the change there
> will be multiple software management tool (DNF5, old Microdnf,
> PackageKit, and DNF) based on different libraries (libdnf, libdnf5),
> providing a different behavior, and not sharing a history. We can also
> expect that DNF will have only limited support from upstream. The DNF5
> development was announced on
> [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NWSURJRGZAIIMNZJT244DHDPOG2PBQXZ/
> Fedora-Devel] list in 2020.
>
> === New DNF5 Features ===
>
> * Fully featured package manager without requirement of Python
> ** Smaller system
> ** Faster
> ** Replace DNF and Microdnf
>
> * Unified behavior of in the software management stack
> ** New Libdnf5 plugins (C++, Python) will be applicable to DNF5, Dnf5Daemon
> *** DNF4 plugins were not applicable for PackageKit and Microdnf (e.g.
> versionlock, subscription-manager), therefore PackageKit behaves
> differently in comparison to DNF

Is there any analysis on how many yum3/dnf4 plugins exist outside of
the core set that the DNF team maintains?  I'm curious how much of a
porting effort is required to move from yum3/dnf4 for plugin authors.

Will there be documentation and best practices on migration for plugin
maintainers?

> ** Shared configurations
> *** In DNF4 not all configuration is honored by PackageKit and Microdnf
> ** DNF/YUM was developed for decades with impact of multiple styles
> and naming conventions (options, configuration, options, commands)
>
> * New Daemon
> ** The new daemon can provide an alternative to PackageKit for RPMs
> (only one backend of PackageKit) if it will be integrated into Desktop

Is this daemon optional depending on installation type, or will it be
running on all installations?  I am assuming it is optional and
centered mostly around whatever currently needs PackageKit.

> ** Support of Modularity and Comps group
> * Performance improvement
> ** Loading of repositories
> ** Advisory operations
> ** RPM queries
> *** Name filters with a case-insensitive search (the `repoquery` command)
> ** Smart sharing of metadata between dnf5 and daemon
> *** Reduce disk and downloads requirements
> *** Currently, DNF, Microdnf, and PackageKit use their own cache
> *** Optional, may be not available for Fedora 39
>
> * Decrease of a maintenance cost in the long term
> ** Shared plugins
> ** Removal of functional duplicates
>
> * Fully integrated Modularity in LIBDNF5 workflows
> ** The Modularity is supported in DNF and LIBDNF but it is not fully
> integrated. Integration was not possible due to limitation of
> compatibility with other tools (PackageKit)
> ** Fully integrated Modularity required changes in the library workflow
>
> === Major codebase improvements ===
>
> *Reports in structure
> ** DNF reports a lot of important information only in logs
>
> * Removal of duplicated implementation
> ** LIBDNF evolved from LIBHIF (PackageKit library) and HAWKEY (DNF
> library). The integration was never finished, therefore LIBDNF still
> contains duplicated functionality.
> ** decrease of the code maintenance cost in future

Do we have some statistics on the consolidated installation size of
DNF5 vs. dnf4?

Any performance comparisons?

josh

> * Unify Python bindings
> ** Formal Libdnf provides two types of Python bindings
> *** CPython (hawkey)
> *** SWIG (libdnf)
> ** Maintaining and communication between both bindings requires a lot
> of resources
> ** Binding unification was not possible without breaking API compatibility
>
> * SWIG bindings
> ** With SWIG we can generate additional bindings without spending huge 
> resources
> ** Code in particular languages will be very similar to each other
>
> * Separation of system state from history DB and `/etc/dnf/module.d`
> ** In dnf-4 the list of userinstalled packages and list of installed
> groups along with the lists of packages installed from them is
> computed as an aggregation of transaction history. In dnf5 it will be
> stored separately, having multiple benefits, among them that the
> history database will serve 

Re: proposal idea: EOL notifications

[Josh Boyer]

On Wed, Jul 13, 2022 at 6:29 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sun, Jul 10, 2022 at 06:34:16PM +0200, Miroslav Suchý wrote:
> > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a):
> > > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS,
> > > > which have their own somewhat different release/life cycles? What about
> > > > module lifecycles? What is it about*lifecycles*  that's important,
> > > > anyway? Don't we maybe want to just have a sort of generic system for
> > > > "important events"?
> > > I view it as a mechanism to communicate well in advance of when someone
> > > is going to have to do work.
> > >
> > > Fedora is the simple case: every 6-12 months you're going to have to
> > > upgrade the version of the OS.
> >
> > And when implementing this for Fedora, can you bear RHEL in mind too? 
> > Because it has several levels of EOL
> >
> > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel
>
> RHEL is indeed more complicated. But RHEL already has its own subscription
> manager that knows when and to what extent a given installation has support.
> The two main ways to support SUPPORT_END= on such systems:
>
> 1. let the subscription management system fill out a date in os-release,
>based on the information it has. If appropriate, the date can be adjusted
>over time.

I'm not aware of any plans to do that.

> 2. leave SUPPORT_END= unset, so that the existing mechanisms are used.
>
> Option 1. has the advantage that over time generic tools might learn
> to look at SUPPORT_END=. But if SUPPORT_END= is not a good fit for some
> reason, existing mechanisms can continue to be used, i.e. option 2.

Right.

> Which way is better will depend on the installation type and other details.
>
> I don't think we should try encode multiple levels of support in os-release.
> That file by design is simple: simple to write and simple to read and simple
> to interpret. More complicated state can stay external and be a source
> for the simplified information in os-release.

I agree.  And RHEL's lifecycle(s) are fairly complex, depending on
exactly what you want to know and what your usage scenarios are.  I
don't think SUPPORT_END fits there very well.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: proposal idea: EOL notifications

[Josh Boyer]

On Tue, Jul 12, 2022 at 2:46 PM Adam Williamson
 wrote:
>
> On Mon, 2022-07-11 at 07:02 -0400, Josh Boyer wrote:
> > On Sun, Jul 10, 2022 at 12:34 PM Miroslav Suchý  wrote:
> > >
> > > Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a):
> > >
> > > Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS,
> > > which have their own somewhat different release/life cycles? What about
> > > module lifecycles? What is it about *lifecycles* that's important,
> > > anyway? Don't we maybe want to just have a sort of generic system for
> > > "important events"?
> > >
> > > I view it as a mechanism to communicate well in advance of when someone
> > > is going to have to do work.
> > >
> > > Fedora is the simple case: every 6-12 months you're going to have to
> > > upgrade the version of the OS.
> > >
> > > And when implementing this for Fedora, can you bear RHEL in mind too? 
> > > Because it has several levels of EOL
> > >
> > > https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel
> >
> > RHEL is already implementing it's own scheme for lifecycle metadata.
>
> How does it work, and is it F/OSS? Is it integrated with the actual
> release processes or just updated manually?

It's a work in progress and will likely be tied to the Insights
service that comes with a RHEL subscription.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: proposal idea: EOL notifications

[Josh Boyer]

On Sun, Jul 10, 2022 at 12:34 PM Miroslav Suchý  wrote:
>
> Dne 08. 07. 22 v 4:59 Stewart Smith via devel napsal(a):
>
> Another - what do we do about, e.g., Fedora IoT and Fedora CoreOS,
> which have their own somewhat different release/life cycles? What about
> module lifecycles? What is it about *lifecycles* that's important,
> anyway? Don't we maybe want to just have a sort of generic system for
> "important events"?
>
> I view it as a mechanism to communicate well in advance of when someone
> is going to have to do work.
>
> Fedora is the simple case: every 6-12 months you're going to have to
> upgrade the version of the OS.
>
> And when implementing this for Fedora, can you bear RHEL in mind too? Because 
> it has several levels of EOL
>
> https://endoflife.software/operating-systems/linux/red-hat-enterprise-linux-rhel

RHEL is already implementing it's own scheme for lifecycle metadata.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: proposal idea: EOL notifications

[Josh Boyer]

On Wed, Jul 6, 2022 at 12:21 PM Lennart Poettering  wrote:
>
> On Mi, 06.07.22 18:15, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > I'm aware of the release schedule ;)
> > The date would only need to be set (at most) twice:
> > - once before the release of Fn
> > - after Fn+2 is released and Fn has 1 month left
> >   (only if Fn+2 slipped)

Or you could just move to fixed-time lifecycles and avoid that
entirely.  As you said below, what's a week or two? :)

> > And it's true that you will not get the update of the date if no
> > updates are installed… But if you don't update ever, does it really
> > matter that you have the EOL date off by a week or two? This date is
> > meaningful for systems that are _maintained_, i.e. at least get
> > updates every few weeks.

People update systems in odd ways, not always wholesale.  Think of the
common case of "I want CVE fixes only".  There is almost never a CVE
fix for fedora-release, so using that filter will mean they continue
to have stale info.  Anyway, as I said earlier, I don't think these
corner cases are big deals.

We actually already did the overall idea in a different way long ago.
There used to be a package called "system-autodeath" that would
basically start logging impending EOL a week before it happened, then
daily after it happened:

https://koji.fedoraproject.org/koji/buildinfo?buildID=732174

I can't remember why it was retired to be honest.

> Maybe our os-release docs should mention that this is the latest
> *known* support date, and suggest that people refresh the OS to newest
> set of relevant package to get newer info.

Reasonable.  I'd love it if we had a real telemetry service that could
do a bunch of things including this, but I believe the community would
likely reject that so I'm not even going to propose it.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: proposal idea: EOL notifications

[Josh Boyer]

On Wed, Jul 6, 2022 at 11:49 AM Neal Gompa  wrote:
>
> On Wed, Jul 6, 2022 at 11:45 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Hi,
> >
> > In https://pagure.io/fesco/issue/2803 Artem asked for a user-visible
> > notification when a Fedora stops being supported. Various proposals
> > for online checks were discussed in the bug, but I think we might make
> > do with something much simpler.
> >
> > https://github.com/systemd/systemd/pull/23924 proposes adding
> > SUPPORT_END=-MM-DD to /usr/lib/os-release. My idea would that we'd
> > e.g. pop up a desktop notification when that date is close, and a
> > bigger redder notification once it has been passed. The date could be
> > set to some initial value even on the initial release, and then
> > adjusted through updates to fedora-release.rpm if our schedule slips.
> > I guess we could add a notification during boot in systemd itself, but
> > most users wouldn't see that, so a graphical notification would also
> > be needed.
> >
> > The advantage of this proposal that it is very simple and will work
> > even on machines that don't have network connectivity, and can be easily
> > integrated into various DEs and tools.
> >
> > WDYT?
> >
>
> Wouldn't it make sense to have the start date and the time period
> supported instead?

Fedora release lifecycles are not date or timeframe driven.  They are
driven by the N+2 release, which can and does slip which means you
will have stale information in /etc/os-release every time that
happens.  Issuing updates to document these slips seems like a lot of
work for little gain.  Even if you did, disconnected machines also
wouldn't get updates to this.

I really don't think encoding lifecycle information in the
installation itself is the right approach, but it's perhaps the most
tenable one for Fedora.  However, until Fedora definitively moves to
using independent lifecycles for their releases, this is a game of
whack-a-mole.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Container-sig] About Fedora containers

[Josh Boyer]

On Tue, Jun 21, 2022 at 3:42 PM Matthew Miller  wrote:
>
> On Mon, Jun 20, 2022 at 08:21:48AM +0200, Lumír Balhar wrote:
> > Because we had a lot of troubles with Fedora infra for container
> > images (I can provide more details, if you want), we have decided to
> > move our containers to https://quay.io/organization/fedora.
>
> I wonder if we should just... make this official? It seems like a pretty
> easy way to create and maintain an official library of layered images which
> are made of Fedora packages — like, some language-base ones like golang or
> python, plus nginx, apache, postgresql, etc.

Yes.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo

[Josh Boyer]

On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort  wrote:
>
> On Mon, Jun 13, 2022 at 4:18 PM Chris Adams  wrote:
> >
> > Once upon a time, Josh Boyer  said:
> > > If the dependency is only needed at build time, which is what CRB
> > > content is intended for
> >
> > If that's the intent, then it's not implemented correctly.  For example,
> > there are well over 100 perl modules in CRB 9.  They may only be used
> > _by Red Hat_ in building, but they are not exclusively build-time
> > packages by a long shot.
>
> If it helps, I've updated my CRB scanner and the results (hopefully
> it's accurate) for seeing what EPEL packages depend on CRB packages
> (via "dnf rq --whatdepends ") for both EL8 and EL9. These
> were run against RHEL 8 and 9 repositories with EPEL (so no EPEL
> Next). I don't believe it'll catch everything (such as things in
> epel-modular), but it could be a decent starting point for review.
> Would also be useful to know if this methodology is flawed and
> inaccurate.
>
> https://gitlab.com/omenos/crb-depends

Not fully sure I understand the results, but this looks promising.
Thanks for providing it!

One thing I caught on initial glance, I think it's getting confused on
multilib.  For example, from:
https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json

   "gvfs.i686": [
"lutris-0:0.5.10.1-1.el9.x86_64"
],

That seems to be highlighting that lutris.x86_64 depends on gvfs.i686.
I don't think that's actually the case, because gvfs.x86_64 is shipped
in AppStream and should satisfy the dependency for lutris.x86_64 in
EPEL.

josh
___
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: Thoughts: epel-release auto-enable crb repo

[Josh Boyer]

On Mon, Jun 13, 2022, 4:17 PM Chris Adams  wrote:

> Once upon a time, Josh Boyer  said:
> > If the dependency is only needed at build time, which is what CRB
> > content is intended for
>
> If that's the intent, then it's not implemented correctly.  For example,
> there are well over 100 perl modules in CRB 9.  They may only be used
> _by Red Hat_ in building, but they are not exclusively build-time
> packages by a long shot.
>

I know.  I'm actually looking at squaring this in one way or another, but
whatever that results in doesn't change that content in CRB will have
different considerations to take into account than other repos.  The same
has always been true of RHEL 7 Optional as well, so it's not a new dynamic.

I also know most of those considerations don't matter to users or EPEL
packagers, but I'm trying to avoid surprise in the long run.

josh
___
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: Thoughts: epel-release auto-enable crb repo

[Josh Boyer]

On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto  wrote:
>
> On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote:
> > Let me start with examples that I get *regularly*: Pagure fails to
> > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown
> > is
> > not available. KDE Plasma fails to install because of a mass of
> > missing dependencies.
>
> if epel use  crb to build some package, crb should be enabled when we
> install epel repo, yes , that is my opinion

If the dependency is only needed at build time, which is what CRB
content is intended for, then there is no reason to default to having
CRB enabled because nothing will be installed from CRB anyway.  The
issue that people are running into is that EPEL packages have
developed *runtime* dependencies on CRB content.  For a subset of
users, that is probably fine.  However, if a package needs something
at runtime it would be better to first inquire about putting that
dependency in BaseOS or AppStream rather than just blindly using it
from CRB.

josh
___
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

Re: exploded git tree for kernel-5.17.4-200.fc35

[Josh Boyer]

On Tue, May 31, 2022 at 2:39 AM Laszlo Ersek  wrote:
>
> Hi,
>
> where can I find the exploded git tree for "kernel-5.17.4-200.fc35"?
>
> The tree at
>  is
> no good; it does not have tags beyond .fc33.

I'm going to delete this tree next month.  It's been dead for a long
time and it's causing more confusion than it is helping.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Fri, May 20, 2022 at 1:42 AM Thomas Stephen Lee  wrote:
>
> The package I need is redhat-lsb-core.

We have no plans to add redhat-lsb-core at this time.  Most users are
able to port their software to use the fields in /etc/os-release.

josh

> On Fri, May 20, 2022 at 1:57 AM Josh Boyer  wrote:
> >
> > On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi  wrote:
> > >
> > > On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> > > > Hi,
> > > >
> > > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > > > > under Projects at issues.redhat.com.
> > > > > What is the correct project for RHEL 9 ?
> > > > >
> > > >
> > > > You have to file a bug for "distribution" component in Bugzilla.
> > >
> > > Please don't file it there. :)
> >
> > Small point of clarification.  If you want to add a package to Red Hat
> > Enterprise Linux 9 (the product), then you should likely open a
> > support case via the Customer Portal and request it as an RFE.
> >
> > If you want to request a subpackage of an existing RHEL 9 package that
> > is not included in RHEL, follow this and replace 8 with 9:
> > https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages
> >
> > If you want to add a package to Extra Packages for Enterprise Linux 9
> > (the wonderful community project), then follow what Kevin says below.
> >
> > It really depends on the exact thing you are after.
> >
> > josh
> >
> >
> > > Take a look at the handy doc:
> > >
> > > https://docs.fedoraproject.org/en-US/epel/epel-package-request/
> > >
> > > If anything is unclear there, please do let us know.
> > >
> > > While RHEL may be moving to jira with RHEL10, EPEL is very likely to
> > > stay with whatever Fedora is using (currently bugzilla).
> > >
> > > kevin
> > > ___
> > > CentOS-devel mailing list
> > > centos-de...@centos.org
> > > https://lists.centos.org/mailman/listinfo/centos-devel
> >
> > ___
> > CentOS-devel mailing list
> > centos-de...@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
> ___
> CentOS-devel mailing list
> centos-de...@centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
___
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

Re: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Fri, May 20, 2022 at 1:42 AM Thomas Stephen Lee  wrote:
>
> The package I need is redhat-lsb-core.

We have no plans to add redhat-lsb-core at this time.  Most users are
able to port their software to use the fields in /etc/os-release.

josh

> On Fri, May 20, 2022 at 1:57 AM Josh Boyer  wrote:
> >
> > On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi  wrote:
> > >
> > > On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> > > > Hi,
> > > >
> > > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > > > > under Projects at issues.redhat.com.
> > > > > What is the correct project for RHEL 9 ?
> > > > >
> > > >
> > > > You have to file a bug for "distribution" component in Bugzilla.
> > >
> > > Please don't file it there. :)
> >
> > Small point of clarification.  If you want to add a package to Red Hat
> > Enterprise Linux 9 (the product), then you should likely open a
> > support case via the Customer Portal and request it as an RFE.
> >
> > If you want to request a subpackage of an existing RHEL 9 package that
> > is not included in RHEL, follow this and replace 8 with 9:
> > https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages
> >
> > If you want to add a package to Extra Packages for Enterprise Linux 9
> > (the wonderful community project), then follow what Kevin says below.
> >
> > It really depends on the exact thing you are after.
> >
> > josh
> >
> >
> > > Take a look at the handy doc:
> > >
> > > https://docs.fedoraproject.org/en-US/epel/epel-package-request/
> > >
> > > If anything is unclear there, please do let us know.
> > >
> > > While RHEL may be moving to jira with RHEL10, EPEL is very likely to
> > > stay with whatever Fedora is using (currently bugzilla).
> > >
> > > kevin
> > > ___
> > > CentOS-devel mailing list
> > > centos-de...@centos.org
> > > https://lists.centos.org/mailman/listinfo/centos-devel
> >
> > ___
> > CentOS-devel mailing list
> > centos-de...@centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
> ___
> CentOS-devel mailing list
> centos-de...@centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi  wrote:
>
> On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> > Hi,
> >
> > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> > wrote:
> >
> > > Hi,
> > >
> > > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > > under Projects at issues.redhat.com.
> > > What is the correct project for RHEL 9 ?
> > >
> >
> > You have to file a bug for "distribution" component in Bugzilla.
>
> Please don't file it there. :)

Small point of clarification.  If you want to add a package to Red Hat
Enterprise Linux 9 (the product), then you should likely open a
support case via the Customer Portal and request it as an RFE.

If you want to request a subpackage of an existing RHEL 9 package that
is not included in RHEL, follow this and replace 8 with 9:
https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages

If you want to add a package to Extra Packages for Enterprise Linux 9
(the wonderful community project), then follow what Kevin says below.

It really depends on the exact thing you are after.

josh


> Take a look at the handy doc:
>
> https://docs.fedoraproject.org/en-US/epel/epel-package-request/
>
> If anything is unclear there, please do let us know.
>
> While RHEL may be moving to jira with RHEL10, EPEL is very likely to
> stay with whatever Fedora is using (currently bugzilla).
>
> kevin
> ___
> CentOS-devel mailing list
> centos-de...@centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi  wrote:
>
> On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> > Hi,
> >
> > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee 
> > wrote:
> >
> > > Hi,
> > >
> > > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > > under Projects at issues.redhat.com.
> > > What is the correct project for RHEL 9 ?
> > >
> >
> > You have to file a bug for "distribution" component in Bugzilla.
>
> Please don't file it there. :)

Small point of clarification.  If you want to add a package to Red Hat
Enterprise Linux 9 (the product), then you should likely open a
support case via the Customer Portal and request it as an RFE.

If you want to request a subpackage of an existing RHEL 9 package that
is not included in RHEL, follow this and replace 8 with 9:
https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages

If you want to add a package to Extra Packages for Enterprise Linux 9
(the wonderful community project), then follow what Kevin says below.

It really depends on the exact thing you are after.

josh


> Take a look at the handy doc:
>
> https://docs.fedoraproject.org/en-US/epel/epel-package-request/
>
> If anything is unclear there, please do let us know.
>
> While RHEL may be moving to jira with RHEL10, EPEL is very likely to
> stay with whatever Fedora is using (currently bugzilla).
>
> kevin
> ___
> CentOS-devel mailing list
> centos-de...@centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
___
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: Rhel 9 + Epel 9 - Amavis can't install

[Josh Boyer]

On Wed, May 18, 2022 at 6:21 AM Filip Bartmann  wrote:
>
> Hello,
> I try to install amavis in epel for RedHat 9 Stable:
>
> dnf install amavis
> Updating Subscription Management repositories.
> Last metadata expiration check: 0:02:16 ago on Wed 18 May 2022 12:16:52 PM 
> CEST.
> Error:
>  Problem: conflicting requests
>   - nothing provides perl(Net::LibIDN) needed by amavis-2.12.2-3.el9.noarch
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to 
> use not only best candidate packages)
> It want's package Net::LibIDN, but it was not found. How can I install amavis 
> for RHEL 9?

The perl-Net-LibIDN package will need to be built for EPEL 9.

josh
___
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: python-passlib for python38 module

[Josh Boyer]

On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel
 wrote:
>
> Hi all,
>
> with the "upcoming" ansible-core migration, I wonder if its possible to
> provide a python-passlib package (or stream) for the python38
> environment (ansible-core dependency).
>
> The current status:
>
> # rpm -q python3-passlib --requires |head -1
> python(abi) = 3.6
>
> Whats the best approach. Upgrade the ABI compat or provide a module build?

Modular build against the python38 module.

josh
___
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: RHEL 9 packages available in EPEL 9 (in different versions as well)

[Josh Boyer]

On Wed, May 4, 2022 at 4:00 PM Miro Hrončok  wrote:
>
> On 04. 05. 22 15:40, Troy Dawson wrote:
> > I just want to make sure that you are querying RHEL 9.0 and not 9.1.
>
> Well, I was querying 9.1, so you have a point. However, with 9.0 it is almost
> the same:
>
> $ comm -12 <(repoquery -q
> --repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability} -a | pkgname | sort |
> uniq ) <(repoquery -q --repo=epel9 -a | pkgname | sort | uniq)
>
> libwmf
> libwmf-lite
> pybind11-devel
> python3-pybind11
> tesseract
> tesseract-devel
> tesseract-langpack-eng
> tesseract-tessdata-doc
>
> $ comm -12 <(repoquery -q
> --repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability}-source -a | pkgname |
> sort | uniq ) <(repoquery -q --repo=epel9-source -a | pkgname | sort | uniq)
>
> libwmf
> pybind11
> tesseract
> tesseract-tessdata
>
>
> The only difference I can spot is anthy-unicode-devel and
> double-conversion-devel, which apparently might be allowed in EPEL 9 for now.

Both of those were requested and added in the last month
(anthy-unicode-devel just this week).  That should be reflected in
CentOS Stream 9 now(ish) and a future version of RHEL 9 at some point.

josh
___
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

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

[Josh Boyer]

On Wed, Apr 6, 2022 at 7:08 AM Richard Hughes  wrote:
>
> On Wed, 6 Apr 2022 at 11:20, Dominik 'Rathann' Mierzejewski
>  wrote:
> > > and on its way out.  As it ages, maintainability has decreased, and
> > > the status quo of maintaining both stacks in perpetuity is not viable
> > > for those currently doing that work.
> > Have you tried getting more people involved?
>
> I don't think that's how Open Source works. Realistically the way I
> see this playing out is that the people responsible for maintaining
> the legacy boot stack will retire the packages, some well meaning
> community people take them over, then everything breaks in an
> unexpected way before a Fedora release for some technical reason and
> the new package maintainers have no idea how to fix the underlying
> issue. Then Fedora QA needs to decide if the legacy boot failure is
> actually release blocking. I'm happy to be proved wrong, but asking
> someone "have you tried getting more people involved" is neither
> helpful nor realistic.

I agree 100%.  I think this is actually getting to the crux of the
issue, which is that while we have a lot of people that want BIOS
support to continue, we effectively have nobody that wants to do the
work to make it happen.  We saw this with i686 installations and
kernels, and I suspect the same will happen here.  Even if Fedora QA
decided it was release blocking, if there's nobody to do the work what
does that actually mean?  Fedora doesn't release indefinitely?

The one positive thing that comes from this is that it will create an
opportunity for people to learn about a new tech stack to scratch
their own itch.  That doesn't mean it will be successful in the end,
but the community has always surprised me in many ways.  It could lead
to a Fedora Remix or Spin, for example.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Josh Boyer]

On Wed, Mar 23, 2022 at 7:05 AM Alexander Sosedkin  wrote:
>
> On Wed, Mar 23, 2022 at 12:51 AM Josh Boyer  wrote:
> >
> > On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin  
> > wrote:
> > >
> > > Hello, community, I need your wisdom for planning a disruptive change.
> > >
> > > Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> > > Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> > > I believe we should start planning
> > > for the next cryptographic defaults tightening.
> > > And next time it's gonna be even more disruptive because of SHA-1 (again).
> > >
> > > SHA-1 is a hash function from 1995,
> > > which collision resistance is no longer to be relied upon for security 
> > > [1].
> > > At the same time, it's not like software has successfully migrated off it,
> > > not even close.
> > > It's not a question of "if" the world should migrate from it,
> > > sooner or later we must part ways with it.
> > > (Technically, some acute energy crisis or a collapse of civilization
> > >  forever raising the costs of computations thousandfold would also do,
> > >  but let's agree that migrating to a more modern hash is the way =)
> > >
> > > We've been disabling it in TLS, but its usage is much wider than TLS.
> > > The next agonizing step is to restrict its usage for signatures
> > > on the cryptographic libraries level, with openssl being the scariest one.
> > >
> > > Good news is, RHEL-9 is gonna lead the way
> > > and thus will take a lot of the hits first.
> > > Fedora doesn't have to pioneer it.
> > > Bad news is, Fedora has to follow suit someday anyway,
> > > and this brings me to how does one land such a change.
> >
> > Given that RHEL 9 already switched the crypto-policy defaults, and we
> > presume that future RHEL releases will not deviate from that, is this
> > change already made in ELN?  I honestly can't tell because it looks
> > like it is, but I don't see any conditionalization in the spec file
> > that would lead me to believe the same default isn't already flipped
> > in Rawhide.  That leaves me wondering what needs to be changed and
> > where at this point.
> >
> > josh
>
> No, it's neither in ELN nor in Rawhide yet.

Could you please make this change in ELN?  It might actually prove
fruitful for the broader Fedora activity because it gives you an
isolated base to see what happens.

If we already know there are other similar changes for future RHEL
releases, making those in ELN now would go a long way towards sorting
those out as well.  That can be a follow-on after SHA-1 though, which
is certainly more pressing.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Landing a larger-than-release change (distrusting SHA-1 signatures)

[Josh Boyer]

On Tue, Mar 8, 2022 at 1:40 PM Alexander Sosedkin  wrote:
>
> Hello, community, I need your wisdom for planning a disruptive change.
>
> Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
> Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
> I believe we should start planning
> for the next cryptographic defaults tightening.
> And next time it's gonna be even more disruptive because of SHA-1 (again).
>
> SHA-1 is a hash function from 1995,
> which collision resistance is no longer to be relied upon for security [1].
> At the same time, it's not like software has successfully migrated off it,
> not even close.
> It's not a question of "if" the world should migrate from it,
> sooner or later we must part ways with it.
> (Technically, some acute energy crisis or a collapse of civilization
>  forever raising the costs of computations thousandfold would also do,
>  but let's agree that migrating to a more modern hash is the way =)
>
> We've been disabling it in TLS, but its usage is much wider than TLS.
> The next agonizing step is to restrict its usage for signatures
> on the cryptographic libraries level, with openssl being the scariest one.
>
> Good news is, RHEL-9 is gonna lead the way
> and thus will take a lot of the hits first.
> Fedora doesn't have to pioneer it.
> Bad news is, Fedora has to follow suit someday anyway,
> and this brings me to how does one land such a change.

Given that RHEL 9 already switched the crypto-policy defaults, and we
presume that future RHEL releases will not deviate from that, is this
change already made in ELN?  I honestly can't tell because it looks
like it is, but I don't see any conditionalization in the spec file
that would lead me to believe the same default isn't already flipped
in Rawhide.  That leaves me wondering what needs to be changed and
where at this point.

josh

>
> ---
>
> Fedora is a large distribution with short release cycles, and
> the only realistic way to weed out its reliance on SHA-1 signatures
> from all of its numerous dark corners is to break them.
> Make creation and verification fail in default configuration.
> But it's unreasonable to just wait for, say, Fedora 37 branch-off
> and break it in Rawhide for Fedora 38.
> The fallout will just be too big.
>
> Maintainers need time to get bugs, look into them, think,
> analyze, react and test --- and that's just if it fails correctly!
> Unfortunately, it's not just that the error paths are as dusty as they get
> because the program counter has never set foot on them before.
> Some maintainers might even find that
> picking a different hash function renders their code non-interoperable,
> or even that protocols they implement have SHA-1 hardcoded in the spec.
> Or that everything is ready, but real world deployments need another decade.
> Or that on-disk formats are just hard to change and migrate.
> Took git years to migrate from SHA-1, and some others haven't even started.
> There are gonna be investigations, planning, exceptions, upstream changes,
> opt-out mechanisms, arguing, compromises, waiting out, all kinds of things.
> It's gonna be big. Too big for a single release cycle.
>
> ---
>
> But how does one land something and give the distribution
> the extra cycles needed to react? That's not really clear to me.
>
> An obvious thing is to announce it in one cycle and land in another one.
> The downsides are well-documented
> in "The Hitchhiker's Guide to the Galaxy":
> announcements are one weak measure, and then it's too late.
>
> A second scheme I can come up with is a "jump scare".
> Break the functionality in Fedora 37 Rawhide,
> make most of the affected people realize the depth of the problem,
> then unbreak it. Break again for Fedora 38 and never fix.
>
> This could also be extended into "let one stable release slide'.
> Break in 37 Rawhide, unbreak on branched off 37,
> but never in Rawhide.
>
> But these are all rather... crude?
> Sure there should be better ways,
> preferably something explored before.
> I'm all for pulling this tooth out smoothly,
> but I need hints on how to do it.
> I hope that together we can devise a better plan than these.
>
> So, how does one land a change that's bigger than a release cycle?
>
> [1] https://eprint.iacr.org/2020/014
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: [CentOS-devel] KDE ready for testing in RHEL9Beta / CentOS Stream 9

[Josh Boyer]

On Tue, Mar 22, 2022 at 11:01 AM Simon Matter  wrote:
>
> Hi Troy and all,
>
> > For those of you who want to use KDE on RHEL9 Beta, or CentOS Stream 9, it
> > is available via EPEL.  It is currently plasma 5.23.5, kf5 5.90.0, qt5
> > 5.15.2.  There might be an update before RHEL 9.0 is released.
>
> This is something I may want to try as I'm not happy with GNOME and I
> can't use it with our nx-libs based remote desktop solution.
>
> Since you mention both RHEL9 Beta and CentOS Stream 9 a question comes up
> and I don't remember if this has already been discussed:
>
> Consider I'm running CentOS Stream 9 on a host and RHEL9 is being
> released, will there be a clean way to move a CentOS Stream 9 system over
> to RHEL9?

Not in a supported manner.

> Will/should it be possible to use dnf distro-sync for this?

It may be possible, but Red Hat recommends fresh installation for Red
Hat Enterprise Linux systems.

josh
___
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

Re: FESCo wants to know what you use i686 packages for

[Josh Boyer]

On Wed, Mar 16, 2022 at 1:37 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Mar 16, 2022 at 12:54:23PM -0400, Josh Boyer wrote:
> > On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
> > > > If you use i686 packages for something now, please respond to this 
> > > > thread.
> > >
> > > I use i686 versions of libraries to do local 32-bit builds of C
> > > software I'm developing. (Something like 'sudo dnf install 
> > > lib{one,two}-devel.i686 &&
> > > meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 
> > > -Dcpp_link_args=-m32
> > > --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
> > >
> > > So I'd be interesting in keeping 32-bit versions of all BuildRequires for
> > > systemd.
> >
> > Who uses those builds and what do they use them for?
>
> They are purely local. I use them to compile and run tests locally so
> I know that the code works correctly on 32-bit. I'll also do test
> builds on arm/arm64/ppc64/riscv/anything-else-that-I-can-lay my hand on.

Are you aware of any upstream users of 32-bit systemd?  Or some other
distro that requires it?

I ask because I see several responses along the same lines (I use it
to build 32-bit packages), but unless *Fedora* uses those resulting
32-bit builds it seems like an odd reason to keep i686 around.  Yes,
being able to build for i686 means you need i686 but the root of the
question is why do you need to build for i686?

If there are other distros that still support 32-bit systemd, could
you do your 32-bit build and test against those instead?

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Josh Boyer]

On Wed, Mar 16, 2022 at 11:55 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
> > If you use i686 packages for something now, please respond to this thread.
>
> I use i686 versions of libraries to do local 32-bit builds of C
> software I'm developing. (Something like 'sudo dnf install 
> lib{one,two}-devel.i686 &&
> meson build-32 -Dc_args=-m32 -Dc_link_args=-m32 -Dcpp_args=-m32 
> -Dcpp_link_args=-m32
> --pkg-config-path=/usr/lib/pkgconfig && ninja -C build-32' .)
>
> So I'd be interesting in keeping 32-bit versions of all BuildRequires for
> systemd.

Who uses those builds and what do they use them for?

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Mon, Mar 14, 2022 at 2:59 PM Dan Čermák
 wrote:
>
> Hi Adam,
>
> Adam Williamson  writes:
>
> > snip
>
> > That could obviously have pretty significant consequences for Fedora.
> > Bugzilla isn't only an issue tracker for Fedora; we run some
> > significant processes through it, notably the Change process, the
> > blocker/FE bug process, and the prioritized bug process. In A World
> > Without Bugzilla all of those would need adapting (and their
> > documentation updating). There's fairly tight integration between Bodhi
> > and Bugzilla, which would need to be redesigned. Those are just things
> > I can think of off the top of my head. There are also a couple of
> > decades worth of internet links to Fedora issues on RH Bugzilla, of
> > course.
> >
> > I guess the two big choices for Fedora if RH said "we're not
> > maintaining Bugzilla any more" would be 1) take over maintaining
> > Bugzilla or 2) switch to something else. 1) would probably be the path
> > of least resistance, I guess.
>
> Short term it is the path of the least resistance, but at least what
> I've heard from $dayjob, maintaining a Bugzilla instance is no easy
> task, as they are often customized (via non-upstream patches) and this
> all needs to be maintained. I cannot speak for our infra team, but I
> really don't know if they'd like yet another huge service, because this
> effectively means they'd have to take over maintenance of
> bugzilla.redhat.com...
>
> >
> > This does also kinda lead to a larger question for me, trying to wear
> > both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> > kind of lacking a...mechanism, for want of a better word, to handle the
> > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> > project" first started. At that point Fedora and Red Hat shared a lot
> > of tooling and infrastructure, and this was useful to both sides in
> > many ways; it saves on development costs and it makes it easy for
> > people to work in both worlds. With my Red Hat on, I think I'm allowed
> > to say that internally we often talk about this being desirable -
> > having consistency between how X is done in Fedora and how it's done
> > for RHEL - and it obviously has benefits to Fedora too (it means we
> > don't have to find the resources to do that same work at Fedora level).
> >
> > However, situations like this make me wonder if we might have an issue
> > with keeping shared infra/tooling where it's desirable. It seems like
> > this is a decision/conversation that's been happening within RH, about
> > what makes sense for RH in terms of RHEL development. AFAIK this is the
> > first time it's been formally talked about in a Fedora context, and the
> > messaging is "RH has already decided to stop using Bugzilla for RHEL
> > after 9". In other words, RH has decided on its own to move away from
> > something that is part of the shared RH/Fedora "heritage way of doing
> > things".
> >
> > I'm not saying that's wrong, but as I said it does make me wonder
> > whether, if both sides do find shared tooling/approaches beneficial, we
> > might want to approach this kind of potential change differently in
> > future. Otherwise it does seem like we could sort of gradually drift
> > apart, with no explicit intention to do so, and lose the benefits of
> > shared tooling and process. Unless the ultimate outcome of this is
> > "Fedora adopts issues.redhat.com for bug tracking" - which would be a
> > possibility, but doesn't seem like a certainty - the result will be
> > that we go from having a shared bug tracker, with the benefits of
> > shared maintenance and being able to easily clone or reference bugs
> > between Fedora and RHEL, to each maintaining our own bug tracker and
> > not having those benefits.
> >
> > Of course, there would be sensitivities in developing such a process -
> > it could look a lot like Red Hat telling Fedora how to do stuff, which
> > I think isn't exactly the relationship we want to have. But at the same
> > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop
> > using this thing they'd previously both used" is always the best choice
> > either.
>
> No, certainly not. I think it would have been nice if the tooling
> discussion happened before RH decided to drop Bugzilla so that we can
> all use a common tooling. However, I also know that in a business

RHEL is choosing not to use Bugzilla for future versions of RHEL.  I
need to be clear in wording there, because Red Hat is a company, RHEL
is one of its products, and we're only talking about newer versions of
that product.  I am not aware of any plans for Red Hat to drop
Bugzilla.  I am aware of plans for newer versions of RHEL to no longer
use Bugzilla.

> sometimes reaching such a consensus is everything but easy. It would
> have been nice if someone at least tried though.

Tried what, to be precise?  If you mean try to find common tooling
between Fedora and RHEL, well we have off and on for years.  

Re: RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Mon, Mar 14, 2022 at 2:59 PM Dan Čermák
 wrote:
>
> Hi Adam,
>
> Adam Williamson  writes:
>
> > snip
>
> > That could obviously have pretty significant consequences for Fedora.
> > Bugzilla isn't only an issue tracker for Fedora; we run some
> > significant processes through it, notably the Change process, the
> > blocker/FE bug process, and the prioritized bug process. In A World
> > Without Bugzilla all of those would need adapting (and their
> > documentation updating). There's fairly tight integration between Bodhi
> > and Bugzilla, which would need to be redesigned. Those are just things
> > I can think of off the top of my head. There are also a couple of
> > decades worth of internet links to Fedora issues on RH Bugzilla, of
> > course.
> >
> > I guess the two big choices for Fedora if RH said "we're not
> > maintaining Bugzilla any more" would be 1) take over maintaining
> > Bugzilla or 2) switch to something else. 1) would probably be the path
> > of least resistance, I guess.
>
> Short term it is the path of the least resistance, but at least what
> I've heard from $dayjob, maintaining a Bugzilla instance is no easy
> task, as they are often customized (via non-upstream patches) and this
> all needs to be maintained. I cannot speak for our infra team, but I
> really don't know if they'd like yet another huge service, because this
> effectively means they'd have to take over maintenance of
> bugzilla.redhat.com...
>
> >
> > This does also kinda lead to a larger question for me, trying to wear
> > both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> > kind of lacking a...mechanism, for want of a better word, to handle the
> > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> > project" first started. At that point Fedora and Red Hat shared a lot
> > of tooling and infrastructure, and this was useful to both sides in
> > many ways; it saves on development costs and it makes it easy for
> > people to work in both worlds. With my Red Hat on, I think I'm allowed
> > to say that internally we often talk about this being desirable -
> > having consistency between how X is done in Fedora and how it's done
> > for RHEL - and it obviously has benefits to Fedora too (it means we
> > don't have to find the resources to do that same work at Fedora level).
> >
> > However, situations like this make me wonder if we might have an issue
> > with keeping shared infra/tooling where it's desirable. It seems like
> > this is a decision/conversation that's been happening within RH, about
> > what makes sense for RH in terms of RHEL development. AFAIK this is the
> > first time it's been formally talked about in a Fedora context, and the
> > messaging is "RH has already decided to stop using Bugzilla for RHEL
> > after 9". In other words, RH has decided on its own to move away from
> > something that is part of the shared RH/Fedora "heritage way of doing
> > things".
> >
> > I'm not saying that's wrong, but as I said it does make me wonder
> > whether, if both sides do find shared tooling/approaches beneficial, we
> > might want to approach this kind of potential change differently in
> > future. Otherwise it does seem like we could sort of gradually drift
> > apart, with no explicit intention to do so, and lose the benefits of
> > shared tooling and process. Unless the ultimate outcome of this is
> > "Fedora adopts issues.redhat.com for bug tracking" - which would be a
> > possibility, but doesn't seem like a certainty - the result will be
> > that we go from having a shared bug tracker, with the benefits of
> > shared maintenance and being able to easily clone or reference bugs
> > between Fedora and RHEL, to each maintaining our own bug tracker and
> > not having those benefits.
> >
> > Of course, there would be sensitivities in developing such a process -
> > it could look a lot like Red Hat telling Fedora how to do stuff, which
> > I think isn't exactly the relationship we want to have. But at the same
> > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop
> > using this thing they'd previously both used" is always the best choice
> > either.
>
> No, certainly not. I think it would have been nice if the tooling
> discussion happened before RH decided to drop Bugzilla so that we can
> all use a common tooling. However, I also know that in a business

RHEL is choosing not to use Bugzilla for future versions of RHEL.  I
need to be clear in wording there, because Red Hat is a company, RHEL
is one of its products, and we're only talking about newer versions of
that product.  I am not aware of any plans for Red Hat to drop
Bugzilla.  I am aware of plans for newer versions of RHEL to no longer
use Bugzilla.

> sometimes reaching such a consensus is everything but easy. It would
> have been nice if someone at least tried though.

Tried what, to be precise?  If you mean try to find common tooling
between Fedora and RHEL, well we have off and on for years.  

[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Mon, Mar 14, 2022 at 11:12 AM Adam Williamson
 wrote:
>
> On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote:
> > Hi Fedora, CentOS, and EPEL Communities!
> >
> > As part of our continued 3 year major Red Hat Enterprise Linux release
> > cadence, RHEL 9 development is starting to wrap up with the spring
> > 2022 release coming soon.  That means planning for the next release
> > will start in earnest in the very near future.  As some of you may
> > know, Red Hat has been using both Bugzilla and Jira via
> > issues.redhat.com for RHEL development for several years.  Our
> > intention is to move to using issues.redhat.com only for the major
> > RHEL releases after RHEL 9.
> >
> > What does this mean for Fedora and CentOS?  This discussion is in part
> > to figure that out.  Based on some very brief analysis, the following
> > should hold:
> >
> > - RHEL customers should continue to file support cases through the Red
> > Hat Customer portal, which will remain consistent regardless of the
> > backend tooling used.
> >
> > - There is no imminent retirement of the Red Hat Bugzilla instance
> > being planned at this time.  RHEL 7, 8, and 9 will continue to use
> > bugzilla in some form and RHEL 9 has a very long lifecycle.
> >
> > - Fedora Linux and EPEL have their own Bugzilla product families and
> > are not directly impacted in their own workflows by the choice to use
> > only issues.redhat.com for RHEL.
> > - There will be impacts on existing documentation that provide
> > guidance on requesting things from RHEL in various places like EPEL.
> > We will be happy to help adjust these.
> >
> > - CentOS Stream contribution and bug reporting workflows will be
> > adjusted to use issues.redhat.com instead of bugzilla in the relevant
> > places.  This should apply to all versions of CentOS Stream for a
> > unified contributor workflow.  This will happen gradually as we
> > discover the best workflow to use.
> >
> > If there are other impacts that you can think of, please raise them on
> > this thread.  We’d like to ensure we’re covering as much as possible
> > as this rolls out.
>
> So if I'm understanding this correctly, the ultimate consequence here
> is "Red Hat Bugzilla might go away, or stop being maintained, at
> whatever point it's no longer needed for RHEL 9", right?

I have no idea, to be honest.  There's a lot of assumption in that
statement and it certainly could be an outcome, but I'm not aware of
any plans towards that directly.

> That could obviously have pretty significant consequences for Fedora.
> Bugzilla isn't only an issue tracker for Fedora; we run some
> significant processes through it, notably the Change process, the
> blocker/FE bug process, and the prioritized bug process. In A World
> Without Bugzilla all of those would need adapting (and their
> documentation updating). There's fairly tight integration between Bodhi
> and Bugzilla, which would need to be redesigned. Those are just things
> I can think of off the top of my head. There are also a couple of
> decades worth of internet links to Fedora issues on RH Bugzilla, of
> course.

Those all sound like the things I'm familiar with.

> I guess the two big choices for Fedora if RH said "we're not
> maintaining Bugzilla any more" would be 1) take over maintaining
> Bugzilla or 2) switch to something else. 1) would probably be the path
> of least resistance, I guess.
>
> This does also kinda lead to a larger question for me, trying to wear
> both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> kind of lacking a...mechanism, for want of a better word, to handle the
> *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> project" first started. At that point Fedora and Red Hat shared a lot
> of tooling and infrastructure, and this was useful to both sides in
> many ways; it saves on development costs and it makes it easy for
> people to work in both worlds. With my Red Hat on, I think I'm allowed
> to say that internally we often talk about this being desirable -
> having consistency between how X is done in Fedora and how it's done
> for RHEL - and it obviously has benefits to Fedora too (it means we
> don't have to find the resources to do that same work at Fedora level).

Fedora and RHEL process and tooling has deviated significantly over
the years.  So much so that by the time I joined the RHEL team, it was
already very different.  That was almost 5 years ago, which means the
individual decisions that led to it were even earlier.  I don't really
want to revisit those decisions because I wasn't around and can't
speak to why they were 

Re: RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Mon, Mar 14, 2022 at 11:12 AM Adam Williamson
 wrote:
>
> On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote:
> > Hi Fedora, CentOS, and EPEL Communities!
> >
> > As part of our continued 3 year major Red Hat Enterprise Linux release
> > cadence, RHEL 9 development is starting to wrap up with the spring
> > 2022 release coming soon.  That means planning for the next release
> > will start in earnest in the very near future.  As some of you may
> > know, Red Hat has been using both Bugzilla and Jira via
> > issues.redhat.com for RHEL development for several years.  Our
> > intention is to move to using issues.redhat.com only for the major
> > RHEL releases after RHEL 9.
> >
> > What does this mean for Fedora and CentOS?  This discussion is in part
> > to figure that out.  Based on some very brief analysis, the following
> > should hold:
> >
> > - RHEL customers should continue to file support cases through the Red
> > Hat Customer portal, which will remain consistent regardless of the
> > backend tooling used.
> >
> > - There is no imminent retirement of the Red Hat Bugzilla instance
> > being planned at this time.  RHEL 7, 8, and 9 will continue to use
> > bugzilla in some form and RHEL 9 has a very long lifecycle.
> >
> > - Fedora Linux and EPEL have their own Bugzilla product families and
> > are not directly impacted in their own workflows by the choice to use
> > only issues.redhat.com for RHEL.
> > - There will be impacts on existing documentation that provide
> > guidance on requesting things from RHEL in various places like EPEL.
> > We will be happy to help adjust these.
> >
> > - CentOS Stream contribution and bug reporting workflows will be
> > adjusted to use issues.redhat.com instead of bugzilla in the relevant
> > places.  This should apply to all versions of CentOS Stream for a
> > unified contributor workflow.  This will happen gradually as we
> > discover the best workflow to use.
> >
> > If there are other impacts that you can think of, please raise them on
> > this thread.  We’d like to ensure we’re covering as much as possible
> > as this rolls out.
>
> So if I'm understanding this correctly, the ultimate consequence here
> is "Red Hat Bugzilla might go away, or stop being maintained, at
> whatever point it's no longer needed for RHEL 9", right?

I have no idea, to be honest.  There's a lot of assumption in that
statement and it certainly could be an outcome, but I'm not aware of
any plans towards that directly.

> That could obviously have pretty significant consequences for Fedora.
> Bugzilla isn't only an issue tracker for Fedora; we run some
> significant processes through it, notably the Change process, the
> blocker/FE bug process, and the prioritized bug process. In A World
> Without Bugzilla all of those would need adapting (and their
> documentation updating). There's fairly tight integration between Bodhi
> and Bugzilla, which would need to be redesigned. Those are just things
> I can think of off the top of my head. There are also a couple of
> decades worth of internet links to Fedora issues on RH Bugzilla, of
> course.

Those all sound like the things I'm familiar with.

> I guess the two big choices for Fedora if RH said "we're not
> maintaining Bugzilla any more" would be 1) take over maintaining
> Bugzilla or 2) switch to something else. 1) would probably be the path
> of least resistance, I guess.
>
> This does also kinda lead to a larger question for me, trying to wear
> both Red Hat and Fedora hats at the same time[0]. I wonder if we're
> kind of lacking a...mechanism, for want of a better word, to handle the
> *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora
> project" first started. At that point Fedora and Red Hat shared a lot
> of tooling and infrastructure, and this was useful to both sides in
> many ways; it saves on development costs and it makes it easy for
> people to work in both worlds. With my Red Hat on, I think I'm allowed
> to say that internally we often talk about this being desirable -
> having consistency between how X is done in Fedora and how it's done
> for RHEL - and it obviously has benefits to Fedora too (it means we
> don't have to find the resources to do that same work at Fedora level).

Fedora and RHEL process and tooling has deviated significantly over
the years.  So much so that by the time I joined the RHEL team, it was
already very different.  That was almost 5 years ago, which means the
individual decisions that led to it were even earlier.  I don't really
want to revisit those decisions because I wasn't around and can't
speak to why they were 

[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Wed, Mar 9, 2022 at 5:05 PM Davide Cavalca via CentOS-devel
 wrote:
>
> On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote:
> > Hi Fedora, CentOS, and EPEL Communities!
> >
> > As part of our continued 3 year major Red Hat Enterprise Linux
> > release
> > cadence, RHEL 9 development is starting to wrap up with the spring
> > 2022 release coming soon.  That means planning for the next release
> > will start in earnest in the very near future.  As some of you may
> > know, Red Hat has been using both Bugzilla and Jira via
> > issues.redhat.com for RHEL development for several years.  Our
> > intention is to move to using issues.redhat.com only for the major
> > RHEL releases after RHEL 9.
>
> Thanks for sharing this Josh. Would you be able to expand on why Red
> Hat chose to use Jira specifically here, and what benefits do you
> forsee this switch will bring to CentOS down the road?

Red Hat has long used Jira in various parts of the company, with JBoss
and other products being heavy users for quite some time.  Within the
past few years we've consolidated a number of different instances into
the single issues.redhat.com instance.  That has enabled us to more
easily plan and coordinate across our product portfolio.

RHEL's decision is certainly informed by that same overall direction,
but also specifically influenced by the limiting factors of using
multiple tools to accomplish similar things.  We've been using
Bugzilla since Red Hat Linux days, and while it has served us well as
a defect tracking backend, it was never designed to handle the
complexity we have for planning and coordinating the varying scope of
work we have.  Aligning to a single tool will help us refine our
processes internally.

As for benefits to CentOS, or any of the other upstream projects we
interact with, we'll have to see.  I think the intention is to
minimize overall impact to start with, and then evolve our workflows
to bring further benefit where we can.  That being said, we are
certainly aware that we need to default to open issues to allow us to
collaborate directly in the open source manner we've long held to be
fundamental to our communities.  I expect that approach to behave very
similarly to how Bugzilla is used today.

josh
___
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

Re: [CentOS-devel] [EPEL-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

On Wed, Mar 9, 2022 at 5:05 PM Davide Cavalca via CentOS-devel
 wrote:
>
> On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote:
> > Hi Fedora, CentOS, and EPEL Communities!
> >
> > As part of our continued 3 year major Red Hat Enterprise Linux
> > release
> > cadence, RHEL 9 development is starting to wrap up with the spring
> > 2022 release coming soon.  That means planning for the next release
> > will start in earnest in the very near future.  As some of you may
> > know, Red Hat has been using both Bugzilla and Jira via
> > issues.redhat.com for RHEL development for several years.  Our
> > intention is to move to using issues.redhat.com only for the major
> > RHEL releases after RHEL 9.
>
> Thanks for sharing this Josh. Would you be able to expand on why Red
> Hat chose to use Jira specifically here, and what benefits do you
> forsee this switch will bring to CentOS down the road?

Red Hat has long used Jira in various parts of the company, with JBoss
and other products being heavy users for quite some time.  Within the
past few years we've consolidated a number of different instances into
the single issues.redhat.com instance.  That has enabled us to more
easily plan and coordinate across our product portfolio.

RHEL's decision is certainly informed by that same overall direction,
but also specifically influenced by the limiting factors of using
multiple tools to accomplish similar things.  We've been using
Bugzilla since Red Hat Linux days, and while it has served us well as
a defect tracking backend, it was never designed to handle the
complexity we have for planning and coordinating the varying scope of
work we have.  Aligning to a single tool will help us refine our
processes internally.

As for benefits to CentOS, or any of the other upstream projects we
interact with, we'll have to see.  I think the intention is to
minimize overall impact to start with, and then evolve our workflows
to bring further benefit where we can.  That being said, we are
certainly aware that we need to default to open issues to allow us to
collaborate directly in the open source manner we've long held to be
fundamental to our communities.  I expect that approach to behave very
similarly to how Bugzilla is used today.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RHEL moving to issues.redhat.com only long term

[Josh Boyer]

Hi Fedora, CentOS, and EPEL Communities!

As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon.  That means planning for the next release
will start in earnest in the very near future.  As some of you may
know, Red Hat has been using both Bugzilla and Jira via
issues.redhat.com for RHEL development for several years.  Our
intention is to move to using issues.redhat.com only for the major
RHEL releases after RHEL 9.

What does this mean for Fedora and CentOS?  This discussion is in part
to figure that out.  Based on some very brief analysis, the following
should hold:

- RHEL customers should continue to file support cases through the Red
Hat Customer portal, which will remain consistent regardless of the
backend tooling used.

- There is no imminent retirement of the Red Hat Bugzilla instance
being planned at this time.  RHEL 7, 8, and 9 will continue to use
bugzilla in some form and RHEL 9 has a very long lifecycle.

- Fedora Linux and EPEL have their own Bugzilla product families and
are not directly impacted in their own workflows by the choice to use
only issues.redhat.com for RHEL.
- There will be impacts on existing documentation that provide
guidance on requesting things from RHEL in various places like EPEL.
We will be happy to help adjust these.

- CentOS Stream contribution and bug reporting workflows will be
adjusted to use issues.redhat.com instead of bugzilla in the relevant
places.  This should apply to all versions of CentOS Stream for a
unified contributor workflow.  This will happen gradually as we
discover the best workflow to use.

If there are other impacts that you can think of, please raise them on
this thread.  We’d like to ensure we’re covering as much as possible
as this rolls out.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] RHEL moving to issues.redhat.com only long term

[Josh Boyer]

Hi Fedora, CentOS, and EPEL Communities!

As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon.  That means planning for the next release
will start in earnest in the very near future.  As some of you may
know, Red Hat has been using both Bugzilla and Jira via
issues.redhat.com for RHEL development for several years.  Our
intention is to move to using issues.redhat.com only for the major
RHEL releases after RHEL 9.

What does this mean for Fedora and CentOS?  This discussion is in part
to figure that out.  Based on some very brief analysis, the following
should hold:

- RHEL customers should continue to file support cases through the Red
Hat Customer portal, which will remain consistent regardless of the
backend tooling used.

- There is no imminent retirement of the Red Hat Bugzilla instance
being planned at this time.  RHEL 7, 8, and 9 will continue to use
bugzilla in some form and RHEL 9 has a very long lifecycle.

- Fedora Linux and EPEL have their own Bugzilla product families and
are not directly impacted in their own workflows by the choice to use
only issues.redhat.com for RHEL.
- There will be impacts on existing documentation that provide
guidance on requesting things from RHEL in various places like EPEL.
We will be happy to help adjust these.

- CentOS Stream contribution and bug reporting workflows will be
adjusted to use issues.redhat.com instead of bugzilla in the relevant
places.  This should apply to all versions of CentOS Stream for a
unified contributor workflow.  This will happen gradually as we
discover the best workflow to use.

If there are other impacts that you can think of, please raise them on
this thread.  We’d like to ensure we’re covering as much as possible
as this rolls out.

josh
___
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

Re: Dropping 32bit arches from pypy2.7?

[Josh Boyer]

On Thu, Mar 3, 2022, 1:21 PM Miro Hrončok  wrote:

> Hello.
>
> pypy 2.7 fails to build with GCC 12 on 32 bit arches.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2046857
>
> Instead of investigating this and trying to fix this, I wonder if I can
> just
> excludearch %ix86 and %arm32. No other Fedora package really requires
> pypy,
> (asv uses it in %check but it already excludes some arches).
>
> I am not aware of any multilib i686 use cases and we retired arm32 anyway.
>
> I would probably do this in Fedora 37 only, but if we need to rebuild the
> package in the future e.g. for a CVE fix or upgrade, excluding the arches
> on
> F36 would also help me.
>
> Any thoughts?
>

Yes, please.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Josh Boyer]

On Thu, Mar 3, 2022 at 12:27 PM Richard W.M. Jones  wrote:
>
> On Wed, Mar 02, 2022 at 09:04:04AM -0500, Neal Gompa wrote:
> > So why not have the OCaml toolchain exposed in RHEL CRB? It sounds
> > like it would be very beneficial to have it there.
>
> It's a good question.  I think we chose not to do that simply because
> we were worried about handling CVEs in a timely way and general
> support (I'm not sure if CRB is officially supported or not, but there
> may be some "implicit" support if we're shipping stuff).  I would not
> be opposed to it though.

This requires a Customer Portal account

https://access.redhat.com/solutions/4180391

The CRB repo is documented heavily internally as well.

josh
___
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: Missing RHEL 9 buildroot packages in EPEL 9 buildroot

[Josh Boyer]

On Tue, Mar 1, 2022 at 8:45 AM Stephen John Smoogen  wrote:
>
>
>
> On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones  wrote:
>>
>> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
>> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones  
>> > wrote:
>> > >
>> > >
>> > >   https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>> > >
>> > > fails to build with:
>> > >
>> > >   DEBUG util.py:444:  No matching package to install: 'ocaml-dune >= 1.0'
>> > >
>> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>> > >
>> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
>> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
>> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
>> > > This seems crazy, is it really correct?
>> > >
>> >
>> > It's not crazy. EPEL is intended to build on RHEL content, which means
>> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
>> > publish their buildroot repo, then sure, we could use it.
>>
>> I wasn't very clear, but I was addressing my remark at Red Hat.
>> There's really no reason why we (Red Hat) don't publish buildroot, in
>> fact my personal view is we ought to for open source reasons.
>>
>
> I do not think you will find much disagreement here.. but after 3+ years of 
> saying it and nothing changing, many of us have made our peace.

To be a bit more fair, we have not blindly added all buildroot content
to RHEL.  However, we have made progress on coming up with a way to
request these packages be added and worked to help teams internally
understand the implications of this.  We continue to add content to
every RHEL minor release.

That's not nothing.  It's just not everything.

josh
___
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

Re: Workflow and other problems with the Fedora container infrastructure

[Josh Boyer]

On Tue, Jan 18, 2022 at 8:40 AM Pierre-Yves Chibon  wrote:
>
> On Sun, Jan 16, 2022 at 08:42:30AM -0500, Josh Boyer wrote:
> >On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi <[1]ke...@scrye.com> wrote:
> >
> >  On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> >  >
> >  > One of the things that has recently happened in the Koji space is the
> >  > addition of a kiwi-build task to build images using the KIWI tool[1].
> >  >
> >  > KIWI supports building all kinds of operating system images, 
> > including
> >  > OCI containers. The Fedora Cloud WG is poking at the idea of using
> >  > KIWI for the cloud image to replace the unmaintained and brittle
> >  > ImageFactory, and we could also look at doing container builds with
> >  > KIWI to replace the OpenShift Atomic Reactor system. That would
> >  > drastically simplify the architecture and make container image builds
> >  > considerably more reasonable for the Container SIG and any other
> >  > stakeholders.
> >
> >  Yeah, thats quite interesting. I would be happy to move to a pipeline
> >  thats less fragile here. :)
> >
> >  There's also talk about moving things to use ImageBuilder, but I don't
> >  think it does containers.
> >
> >We can, and should, have RFEs for Image Builder to do containers.  I know
> >we need this internally as well.  It may farm that out to buildah in the
> >background or something, but that remains to be determined.
> >In the interest of commonality across the Fedora/CentOS/RHEL ecosystem, I
> >really think using Image Builder as the tool to build images is the best
> >approach.
>
> The underlying tool, osbuild, can already build container. They can be made
> available as tarball which one can just `podman import` afterward :)

Yes.  Why make people do that instead of just publishing an OCI
compliant image?  I know why, but that's the RFE :)

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Workflow and other problems with the Fedora container infrastructure

[Josh Boyer]

On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi  wrote:

> On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> >
> > One of the things that has recently happened in the Koji space is the
> > addition of a kiwi-build task to build images using the KIWI tool[1].
> >
> > KIWI supports building all kinds of operating system images, including
> > OCI containers. The Fedora Cloud WG is poking at the idea of using
> > KIWI for the cloud image to replace the unmaintained and brittle
> > ImageFactory, and we could also look at doing container builds with
> > KIWI to replace the OpenShift Atomic Reactor system. That would
> > drastically simplify the architecture and make container image builds
> > considerably more reasonable for the Container SIG and any other
> > stakeholders.
>
> Yeah, thats quite interesting. I would be happy to move to a pipeline
> thats less fragile here. :)
>
> There's also talk about moving things to use ImageBuilder, but I don't
> think it does containers.


We can, and should, have RFEs for Image Builder to do containers.  I know
we need this internally as well.  It may farm that out to buildah in the
background or something, but that remains to be determined.

In the interest of commonality across the Fedora/CentOS/RHEL ecosystem, I
really think using Image Builder as the tool to build images is the best
approach.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: The incredibly shrinking RHEL

[Josh Boyer]

On Sat, Jan 15, 2022 at 1:29 PM Orion Poplawski  wrote:
>
> On 1/14/22 05:02, Josh Boyer wrote:
> > On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok  wrote:
> >>
> >> On 14. 01. 22 5:11, Orion Poplawski wrote:
> >>> While working on EPEL9, it seems that even more packages are missing from 
> >>> RHEL9
> >>> than were in RHEL8.  The latest I found was cppunit, which appears to be
> >>> completely missing from the CS9 repos despite having been built (See
> >>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
> >>> presumably in the CS9/RHEL9 buildroot.
> >>>
> >>> So I scraped some screens from pkgs.org:
> >>>
> >>> Stream 9:
> >>>
> >>> CentOS AppStream Official   x86_64 8882
> >>> CentOS BaseOS Official  x86_64 2357
> >>> CentOS CRB Official x86_64 1856
> >>>
> >>> Stream 8:
> >>>
> >>> CentOS AppStream Official   x86_64 15008
> >>> CentOS BaseOS Official  x86_64 6721
> >>> CentOS PowerTools Official  x86_64 3771
> >>>
> >>> That's a pretty big difference.  Now, I don't know how many were dropped
> >>> completely and how many are of the "buildroot only" variety.  But I 
> >>> suspect
> >>> there is a fair amount of the latter and so a lot of make-work ahead of 
> >>> us for
> >>> EPEL9.
> >
> > A fairly accurate list of packages removed in RHEL 9 can be found in
> > our RHEL 9 Adoption documentation:
> >
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages
>
> Thanks for that.
>
> >>> Packaging for EPEL9 is starting to feel more and more like cleaning the 
> >>> Augean
> >>> stables with RedHat piling up more manure.
> >>
> >> If there is any Python stuff that's in Buildroot only, let me know and 
> >> I'll do
> >> my best to persuade the maintainers to move it to CRB (but my powers are 
> >> limited).
> >
> > I will politely point out two things.
> >
> > 1) The entirety of the RHEL buildroot is available in the CentOS
> > Stream koji buildroots.  I know the EPEL stewards have qualms about
> > using it, but they are there and the technical hurdles to consume them
> > are not large.
>
> Well, we are making use of it via epel-next.  But it's the "Stream"
> buildroot.  Once that diverges from the current released RHEL there
> could be issues with trying to do updated builds for the current release
> of RHEL.

"...could be issues...".  Yes, I agree it is possible to have issues.
I do not believe the number that may be found is large enough to
cripple EPEL or cause the community to have to request dozens of
-devel packages be added to product repos just to build things.  It is
my hope that EPEL-next proves this out and EPEL proper can benefit
from it in a similar manner.  I can appreciate the caution the EPEL
community is taking.

> > 2) Moving content to CRB in RHEL is not a silver bullet solution in
> > many scenarios.  If it's strictly for build dependencies, CRB works
> > well.  If an EPEL package has a runtime requires on CRB content, that
> > is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
> > unsupported, not enabled by default, and not intended to be used at
> > runtime in production.  EPEL itself is clearly in the same unsupported
> > category, but requiring another unsupported repo at runtime may lead
> > to unintentional surprises for many users.
> >
> > josh
>
> I don't buy any of these arguments, and it doesn't really address the
> situation of "missing -devel" packages.  E.g. utf8proc - it's in

I'm sorry, I did not mean to intend an argumentative tone.  What I
wrote is a factual statement from a product perspective, based on
feedback we've heard directly from some customers.  It's ok for you to
not share the same view, of course.  Feedback from some of our other
customers highlights they don't share it either.

> "AppStream" - so it's presumably "supported" and "intended to be used at
> runtime in production".  But without the -devel package available we
> can't build anything in EPEL that uses it.  So we have to go through
> contortions to make sure we build the proper version of utf8proc-devel
> and keep it in sync with RHEL.

This is difficult to describe, both in approach and in actual customer
facing documentation, even though we try.  Conte

[EPEL-devel] Re: The incredibly shrinking RHEL

[Josh Boyer]

On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok  wrote:
>
> On 14. 01. 22 5:11, Orion Poplawski wrote:
> > While working on EPEL9, it seems that even more packages are missing from 
> > RHEL9
> > than were in RHEL8.  The latest I found was cppunit, which appears to be
> > completely missing from the CS9 repos despite having been built (See
> > https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and
> > presumably in the CS9/RHEL9 buildroot.
> >
> > So I scraped some screens from pkgs.org:
> >
> > Stream 9:
> >
> > CentOS AppStream Official   x86_64 8882
> > CentOS BaseOS Official  x86_64 2357
> > CentOS CRB Official x86_64 1856
> >
> > Stream 8:
> >
> > CentOS AppStream Official   x86_64 15008
> > CentOS BaseOS Official  x86_64 6721
> > CentOS PowerTools Official  x86_64 3771
> >
> > That's a pretty big difference.  Now, I don't know how many were dropped
> > completely and how many are of the "buildroot only" variety.  But I suspect
> > there is a fair amount of the latter and so a lot of make-work ahead of us 
> > for
> > EPEL9.

A fairly accurate list of packages removed in RHEL 9 can be found in
our RHEL 9 Adoption documentation:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages

> > Packaging for EPEL9 is starting to feel more and more like cleaning the 
> > Augean
> > stables with RedHat piling up more manure.
>
> If there is any Python stuff that's in Buildroot only, let me know and I'll do
> my best to persuade the maintainers to move it to CRB (but my powers are 
> limited).

I will politely point out two things.

1) The entirety of the RHEL buildroot is available in the CentOS
Stream koji buildroots.  I know the EPEL stewards have qualms about
using it, but they are there and the technical hurdles to consume them
are not large.

2) Moving content to CRB in RHEL is not a silver bullet solution in
many scenarios.  If it's strictly for build dependencies, CRB works
well.  If an EPEL package has a runtime requires on CRB content, that
is less desirable.  RHEL CodeReady Linux Builder (CRB) content is
unsupported, not enabled by default, and not intended to be used at
runtime in production.  EPEL itself is clearly in the same unsupported
category, but requiring another unsupported repo at runtime may lead
to unintentional surprises for many users.

josh
___
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

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Josh Boyer]

On Fri, Dec 3, 2021 at 1:15 PM Davide Cavalca  wrote:
>
> On Thu, 2021-12-02 at 19:10 -0500, Josh Boyer wrote:
> > On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel
> >  wrote:
> >
> > > Correct, XFS doesn't support fs-verity at the moment (though it
> > > could
> > > be implemented if one wanted to).
> >
> > That means it would exclude Fedora Server and ELN as they are XFS
> > based.
>
> There isn't any impact on XFS-based editions by default. Building and
> signing RPMs with fs-verity works fine, as there's no filesystem
> dependency for that. Installing RPMs also works fine, with one caveat:
> if you're running a system with an unsupported filesystem and have rpm-
> plugin-fsverity (which is not installed by default), fs-verity will not
> be enabled for the installed files so there will be no verification
> (but the RPM installation itself should succeed).

Yes, thank you.  I meant it would render those Editions/projects
unable to use this Change.  It's not the end of the world, just an
observation.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: EPEL9 Rollout Proposals

[Josh Boyer]

On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel
 wrote:
>
> Am 02.12.21 um 19:49 schrieb Carl George:
> > On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson  wrote:
> >>
> >> In our last EPEL Steering Committee meeting, Carl brought up a new 
> >> proposal for our epel9 / epel9-next rollout.  Sometimes IRC isn't the best 
> >> way to explain things like that, it got a little confusing.  Carl and I 
> >> had a good video chat to clean up confusion and talk about some pros and 
> >> cons of the various proposals.
> >> Here are the three proposals.
> >>
> >> * PLAN A
> >> Plan A is basically what we've been working towards for the past couple of 
> >> months.
> >> - launch epel9-next now-ish (ideally aligned with c9s launch promotion)
> >> - After RHEL9 goes GA
> >> -- perform a mass branch and mass rebuild to populate epel9
> >> -- launch epel9 after RHEL9 GA is launched.
> >>
> >> ** Plan A Pros:
> >> - epel9-next and epel9 are only set up once, and not changed
> >> - ready to go now
> >>
> >> ** Plan A Cons:
> >> - complexity and added work of mass branch and mass rebuild
> >> - mass rebuild will have a moderate rate of failure due to buildroot 
> >> differences (unshipped devel packages)
> >> - epel9 not available at rhel9 ga
> >> - confusing messaging to packagers:
> >> -- target epel9-next for ~6 months
> >> -- after epel9 exists target that instead, only use epel9-next when needed
> >> - confusing messaging to users:
> >> -- use epel9-next now for c9s and rhel9 beta
> >> -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
> >> -- use epel9 primarily once it exists
> >>
> >>
> >> * PLAN B
> >> - epel9-next stays the way it is currently setup.
> >> - Setup epel9 using RHEL9 Beta for the buildroot.
> >> -- Pull in any errata as it comes.
> >> -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
> >> - Launch epel9 and epel9-next together (In 1-2 weeks).
> >> - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to 
> >> RHEL9 GA
> >>
> >> ** Plan B Pros:
> >> - simple messaging to packagers:
> >> -- epel9 is the primary target, use epel9-next only when needed (same as 
> >> epel8-next)
> >> - simple messaging to users:
> >> -- use epel9 everywhere (epel-next-release is a recommends on c9s)
> >> - no mass branching
> >> - no mass rebuild
> >> - No confusion from using the full CentOS Stream buildroot
> >> -- epel9 buildroot will only have AppStream, BaseOS and CRB
> >>
> >> ** Plan B Cons:
> >> - potential for large divergence between rhel9 beta and ga
> >> - changing our messaging right before the launch
> >>
> >>
> >> * PLAN C
> >> - epel9-next stays the way it is currently setup.
> >> - setup up epel9 using c9s for the buildroot
> >> -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
> >> - freeze epel9 buildroot before c9s switches to 9.1 content
> >> - launch epel9 and epel9-next together (1-2 weeks)
> >> - switch epel9 buildroot from frozen c9s to rhel9 ga later
> >>
> >> ** Plan C Pros:
> >> - simple messaging to packagers:
> >> -- epel9 is the primary target, use epel9-next only when needed (same as 
> >> epel8-next)
> >> - simple messaging to users:
> >> -- use epel9 everywhere (epel-next-release is a recommends on c9s)
> >> - no mass branching
> >> - no mass rebuild
> >> - No confusion from using the full CentOS Stream buildroot
> >> -- epel9 buildroot will only have AppStream, BaseOS and CRB
> >>
> >> ** Plan C Cons:
> >> - potential infrastructure complexity of freezing the epel9 buildroot
> >> - changing our messaging right before the launch
> >>
> >>
> >> Please let us know what you think.
> >> If we do choose to go with Plan B or C we will need to make the decision 
> >> fairly quickly.
> >>
> >> Troy
> >
> > Closing the loop here, at the 2021-11-24 EPEL Steering Committee
> > meeting we voted and selected plan C.
> >
> > https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html
> >
> > We are in the process of finishing up the EPEL9 implementation and
> > plan to launch EPEL9 and EPEL9 Next together with a formal
> > announcement very soon.  Until then you may notice parts of that
> > implementation coming online (repositories, release packages, etc.)
> > but we recommend waiting until the announcement for official
> > instructions.
> >
>
>
> That sounds nice! Just curious - what indicates the switch to 9.1
> content? Any sample point(s) that indicates such "branch"?

There are none.  C9S is a continuously delivered distribution which
RHEL is derived from.  Equivalency to distinct RHEL minor releases at
point-in-time intervals isn't something that Stream does.

In talking with Carl directly, he was using this as shorthand for
instituting a freeze of the EPEL buildroot in preparation of
solidifying it for a RHEL GA.  RHEL's release cadence is publicly
documented, so my understanding is that the EPEL team will do some of
their own projections from the spring/fall RHEL release cadence
(typically May and Nov) and work 

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Josh Boyer]

On Thu, Dec 2, 2021 at 7:27 PM Michel Alexandre Salim
 wrote:
>
> Hello,
>
> On Thu, Dec 02, 2021 at 07:10:32PM -0500, Josh Boyer wrote:
> > On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel <
> > devel@lists.fedoraproject.org> wrote:
> >
> > > On Thu, 2021-12-02 at 13:09 -0800, Kevin Fenzi wrote:
> > > > On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote:
> > > > ...snip...
> > > > >
> > > > > In the context of rpm, there are two parts to this:
> > > > > * at build time, we compute the Merkle tree for the files within a
> > > > > package, then sign it and ship it as part of the rpm metadata;
> > > >
> > > > This is some kind of seperate signing that happens at build time?
> > > >
> > > > Or it's added to the rpm metadata and covered by the normal package
> > > > signing if/when the package is signed?
> > >
> > > As part of the signing flow (e.g. via rpmsign), the Merkle tree is
> > > generated and a signature is computed from it, which is then added to
> > > the rpm metadata.
> > >
> >
> > IMA received significant pushback on the impact to RPMs and signing
> > implications in Fedora.  How does fs-verity compare here?
> We wrote up a comparison here: 
> https://fedoraproject.org/wiki/Changes/FsVerityRPM#Relationship_with_IMA

Yes, I saw that and I appreciate it.  That's a comparison between the
two implementations.  I am asking about what benefits and use cases
fs-verity solves in Fedora.  Right now, the change simply says:

"The main benefit is the ability to do block-level verification of
RPM-installed files. In turn, this can be used to implement
usecase-specific validation and verification policies depending on the
environment requirements."

which is also largely true of IMA.  The IMA change went into more
detailed use cases, which perhaps may have been it's downfall.  So can
you describe what most Fedora users would use this for or benefit from
it?  Or if "most users" is not an applicable qualifier, can you at
least give some more detailed use cases that you would expect people
to use it for?

> > Alternatively/additionally, why is fs-verity worth the hit for Fedora where
> > IMA was not.
>
> The hit is much smaller; per 
> https://fedoraproject.org/wiki/Changes/FsVerityRPM#Merkle_tree_cost
> - if the plugin is installed, the Merkle tree is stored but it's 1/127th
>   the original file size
> - the RPM only ships the signature, not the tree itself; per
> https://fedoraproject.org/wiki/Changes/FsVerityRPM#Signature_overhead_cost
>   in practice we see a minimal to no increase in the size of the RPM
>
> So as proposed in this Change, users can opt in by installing the
> plugin, otherwise they will be mostly unimpacted.

OK.  I guess I was looking for some side-by-side data comparisons in
the overhead between IMA metadata and fs-verity.  "1/127th of the
original Merkel tree size" doesn't tell me much.

Are there some test runs with numbers to show before/after data for
both the RPM size and installed FS usage?  Perhaps with an example
install.  The IMA change attempted to document this and seeing a 1.1%
average increase in RPM size was easier to understand.

josh

> As discussed in the write-up - IMA does have a richer policy system, and
> could potentially be integrated (so we use IMA but with a fsverity
> backend) to get the best of both worlds.
>
> Best regards,
>
> --
> Michel Alexandre Salim
> profile: https://keyoxide.org/mic...@michel-slm.name
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Josh Boyer]

On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Thu, 2021-12-02 at 13:09 -0800, Kevin Fenzi wrote:
> > On Thu, Dec 02, 2021 at 02:36:51PM -0500, Ben Cotton wrote:
> > ...snip...
> > >
> > > In the context of rpm, there are two parts to this:
> > > * at build time, we compute the Merkle tree for the files within a
> > > package, then sign it and ship it as part of the rpm metadata;
> >
> > This is some kind of seperate signing that happens at build time?
> >
> > Or it's added to the rpm metadata and covered by the normal package
> > signing if/when the package is signed?
>
> As part of the signing flow (e.g. via rpmsign), the Merkle tree is
> generated and a signature is computed from it, which is then added to
> the rpm metadata.
>

IMA received significant pushback on the impact to RPMs and signing
implications in Fedora.  How does fs-verity compare here?
Alternatively/additionally, why is fs-verity worth the hit for Fedora where
IMA was not.
I'm not looking to create a false equivalence or compare apples to oranges,
but I want to better understand why this is a more acceptable approach for
Fedora.

As an aside, a few people have asked why RHEL didn't get IMA into Fedora
first.  Frankly, we tried and got feedback that it didn't apply to Fedora's
needs and use cases.  As of right now, we have no plans to force something
into Fedora that the community doesn't want.  If fs-verity is more
acceptable or is described in a way that is better understood with enough
similarities to IMA, we may try again.

> > * at run time, if the fsverity rpm plugin is enabled, rpm will
> > > install
> > > the fsverity signature key and enable fsverity on files that are
> > > installed.
> >
> > Is this signature key the fedora rpm package signing key?
> > Or some seperate fsverity key?
>
> fs-verity needs a RSA key/cert pair for file signing at package
> signature time. At package install time, the cert needs to be loaded in
> the appropriate kernel keyring. We've always used a dedicated keypair
> during testing -- I'm not actually sure if the package signing key
> could be reused for this, as it's a GPG key, but this is something we
> should follow up on.
>
> > > fs-verity works by using a Merkle tree to generate a checksum for
> > > every data block in the system, and reads will fail if a single
> > > data
> >
> > every data block? or every packaged in rpms data block?
>
> fs-verity only operates on files where it has been enabled via its
> ioctl (which, if you install the RPM plugin, is taken care of by RPM on
> your behalf). For those, fs-verity will checksum every data block
> whenever it's accessed and validate it still matches.
>
> > > block read fails it’s checksum. The signature of the the file is
> > > validated against a public key loaded into the kernel keyring.
> > > Because
> > > fsverity operates on block reads, its runtime cost is small (as it
> > > only needs to verify the block that is being accessed), and it can
> > > protect from alterations at any point in time.
> >
> > Is this via dm_verity kernel module? Or thats a completely seperate
> > thing?
>
> It's somewhat inspired by dm-verity, but it's a separate
> implementation, the only shared logic is the hash computation code in
> the kernel.
>
> > > == Scope ==
> > >
> > > * Proposal owners
> > > ** btrfs kernel enablement work
> > > ([
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=146054090b0859b28fc39015c7704ccc3c3a347f
> > > landed in 5.15]); see this
> > > [
> > >
> https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in-btrfs/
> > > blog post] for more details
> >
> > What does this mean for all the other filesystems? They would just be
> > slower since btrfs is computing the trees as part of it's normal
> > checksumming?
>
> fs-verity requires support in the underlying filesystem. If you're
> using a filesystem that doesn't support it and attempt to enable fs-
> verity on a file, the ioctl will fail. Note that this is only a concern
> at runtime, not at build time.
>
> > > ** koji integration: koji will need to add the fs-verity metadata
> > > to
> > > packages when signing them
> >
> > Well, koji doesn't sign packages. robosignatory listens for messages
> > on
> > the message bus for koji tagging and based on it's config, it asks
> > sigul
> > to sign rpms and import the signatures into koji.
> >
> > There's support in robosignatory to ask to sign files (used for the
> > short lived IMA stuff), but I suspect it would need a new ability for
> > this.
> >
> > Finally who is going to write this? Change owners?
> > Or do you expect robosignatory maintainers to do so?
>
> Thanks for clarifying! Yes, I think robosignatory is likely what we
> want here. We (the Change owners) expect to do the work, though we'll
> likely need some advice/help around code review, testing and
> deployment.
>
> > > * fs-verity requires filesystem support; currently 

Re: Onboarding package

[Josh Boyer]

On Tue, Oct 5, 2021 at 11:27 AM Matthew Miller  wrote:
>
> On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote:
> > >Is this really necessary?
> >
> > Yes. Because anyone can add something like this:
> > %post
> > rm -rf /
> >
> > And it will destroy the installed system or even the hardware.
>
> Yeah, but... that's not going get through the PR process? In fact, that
> specific thing should fail in CI before a human gets to it even.

So you're going to ensure that the people using this package to
experiment/learn can *only* submit via PR?  I like that.  I find it to
be better, but not sufficient depending on how that works.

> Overall, we put a lot of trust in maintainers. I don't see this _particular_
> route as a likely one for violating that trust.

I think I'd like to see a more sketched out flow.  This isn't for
maintainers, it's for people trying to learn to be maintainers.
They're still building that trust via this whole thing, right?

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Onboarding package

[Josh Boyer]

On Mon, Oct 4, 2021 at 1:10 PM Kevin Fenzi  wrote:
>
> On Mon, Oct 04, 2021 at 10:57:42AM +0200, Vít Ondruch wrote:
> > Thoughts?
>
> I like the idea!

It's indeed a good idea.

> We can block such a package from ever appearing in a compose in pungi.

You'd need to block it from ever appearing in the buildroots.  You
wouldn't want someone adding something to it that injected code that
impacted the builds of other packages.

josh

> So, perhaps we seperate it into:
>
> 
> open a bug, submit a pr, do a scratch build, look at ci
>
> 
> get added as commit to onboarding package
> create pr, merge pr, do official build, submit update, etc
>
> Another possible way we could do this is have this setup in our staging
> env. ie, they do the same things, but it's in staging (which we never
> compose anyhow). That has the danger of something being broken in stg
> without us realizing it, or them diverging.
>
> Great idea tho, I like it.
>
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: python-gevent and pytest-cov in el9

[Josh Boyer]

On Fri, Sep 24, 2021 at 4:09 PM Neal Gompa  wrote:
>
> On Fri, Sep 24, 2021 at 4:03 PM Josh Boyer  wrote:
> >
> > On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa  wrote:
> > >
> > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer  wrote:
> > > >
> > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer  
> > > > wrote:
> > > > >
> > > > > Hi folks,
> > > > >
> > > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> > > > > cannot build python-gevent on EPEL 9 easily.
> > > >
> > > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
> > > >
> > > > You could request libev-devel in the composes.  I remain confused why
> > > > it has to be in the compose though, because libev and it's devel
> > > > package are accessible in the CentOS Stream 9 buildroots today.
> > > >
> > >
> > > We can't use them in EPEL if they're not in CRB.
> >
> > Yes, that's what everyone keeps telling me.  I don't understand why.
> >
>
> Well, because outside of RHEL, everyone wants remote and local builds
> to have access to the same resources and not crush the servers. Since
> buildroot stuff isn't going out on the mirror network (otherwise, why
> would it be separate from CRB?), it's obvious we shouldn't rely on it
> for packages that people should expect to be able to build and rebuild
> for RHEL.

So you have access to what you want, you have a way to pull it down
and get it locally, but you can't depend on it because... you're
worried a multi-billion dollar company can't pay it's server and CDN
bills?

As to why it's separate from CRB, that's because CRB is a reflection
of what is provided as part of the product.  It's that simple.

> And again, by Red Hat's own sword (policy), RHEL doesn't want to ship
> everything needed to build stuff, so if EPEL is intended to provide
> the requisite community guarantees (reproducibly buildable), we have
> to work with what RHEL gives us.

I think that is also EPEL falling on EPEL's own sword a bit.  I think
it fails to recognize that building and distributing software can be
separate things.  I can see the need for a developer community to be
able to build, update, and rebuild software it distributes.  Access to
the buildroots facilitates this.  We could even point mock configs at
it, or propose a buildroot repo for it if people are really worried
about "servers".

However, in the context of something like python-gevent, an EPEL *end
user* isn't going to want libuv-devel or libev-devel to be installed
on their system at runtime.  They have no need for it to be available
in a compose.  They only need python-gevent and the requisite runtime
libraries, which are already provided.  I think separating the
personas and thinking about the requirements for each might be worth
doing.

I understand this is a different approach and something that looks
different from the past.  It's been 2+ years since the OS EPEL8 is
based on has shipped and it is taking a different approach than
previous releases.  Every indication we have shows the next major
version will continue this.  I'm worried that sticking with past
policies precludes EPEL from making progress on a project that we all
want to see succeed.

josh
___
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: python-gevent and pytest-cov in el9

[Josh Boyer]

On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa  wrote:
>
> On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer  wrote:
> >
> > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer  wrote:
> > >
> > > Hi folks,
> > >
> > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> > > cannot build python-gevent on EPEL 9 easily.
> >
> > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
> >
> > You could request libev-devel in the composes.  I remain confused why
> > it has to be in the compose though, because libev and it's devel
> > package are accessible in the CentOS Stream 9 buildroots today.
> >
>
> We can't use them in EPEL if they're not in CRB.

Yes, that's what everyone keeps telling me.  I don't understand why.

josh
___
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: python-gevent and pytest-cov in el9

[Josh Boyer]

On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer  wrote:
>
> Hi folks,
>
> The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> cannot build python-gevent on EPEL 9 easily.

https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm

You could request libev-devel in the composes.  I remain confused why
it has to be in the compose though, because libev and it's devel
package are accessible in the CentOS Stream 9 buildroots today.

josh

> (It's possible to package the missing -devel packages separately, and
> I've been doing this by automatically following the NVR changes in
> Stream 9's Koji for several weeks with scripts at
> https://github.com/ktdreyer/ceph-el9. My conclusion is that it is so
> painful that it's not sustainable to do this for years.)
>
> This means that python-pytest-cov and python-pytest-xdist won't be
> available on epel9, since those require gevent.
>
> Several Python packages require python-pytest-cov because upstream
> lists it in requirements.txt or tests-requirements.txt. I think we
> should just patch these out in Fedora. Even apart from RHEL's
> restrictions, it's not a good use of resources to run pytest-cov when
> no one reviews coverage reports in the Koji logs, and we'll speed up
> builds when mock doesn't have to install this spurious BuildRequires.
>
> Here are a list of packages where I've removed pytest-cov:
>
> https://src.fedoraproject.org/rpms/python-watchdog/pull-request/4
> https://src.fedoraproject.org/rpms/python-cheroot/pull-request/15
> https://src.fedoraproject.org/rpms/python-portend/pull-request/5
> https://src.fedoraproject.org/rpms/python-typing-extensions/pull-request/3
>
> - Ken
> ___
> 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 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: ansible-core-2.11.x in CentOS stream 9

[Josh Boyer]

On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster
 wrote:
>
> On 16.09.21 14:22, Josh Boyer wrote:
> > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
> >>
> >> Just a heads up that ansible-core (the engine part of ansible) is now in
> >> CentOS stream 9:
> >>
> >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
> >>
> >> Note that this is the engine, you will likely want to install
> >> collections for modules and roles, etc.
> >
> > For those that might not have followed how Ansible has been
> > refactored, take a look at
> > https://www.ansible.com/blog/ansible-3.0.0-qa
> >
> > ansible-core is the lowest level of the ansible stack and does not
> > include many of the modules and plugins that those using ansible
> > engine (ansible-2.9) might be used to.  As Kevin said, you will almost
> > certainly need additional modules/plugins not provided by
> > ansible-core.
>
>
> Out of curiosity
>
> Does CS9 provide additional (sub)packages to extend the functionality?

Not generally.  ansible-core has been added to CS9 in support of
System Roles only.  This is analogous to how ansible is made available
in RHEL 8.  System Roles will include the modules/plugins it needs to
manage the various areas of the OS, but they are not general purpose
ansible packages.

> Right now EPEL8 provide the the full stack based on ansible 2.9.
>
> Will EPEL9 provide such packages to provide additional modules/plugins?
>
> And more a ansible question: Does ansible3 provide a dependencies
> manager as consequence now?

I'll leave these for Kevin or someone else to answer in terms of EPEL 9 plans.

josh
___
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: ansible-core-2.11.x in CentOS stream 9

[Josh Boyer]

On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
>
> Just a heads up that ansible-core (the engine part of ansible) is now in
> CentOS stream 9:
>
> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
>
> Note that this is the engine, you will likely want to install
> collections for modules and roles, etc.

For those that might not have followed how Ansible has been
refactored, take a look at
https://www.ansible.com/blog/ansible-3.0.0-qa

ansible-core is the lowest level of the ansible stack and does not
include many of the modules and plugins that those using ansible
engine (ansible-2.9) might be used to.  As Kevin said, you will almost
certainly need additional modules/plugins not provided by
ansible-core.

josh
___
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

Re: I think we should stop building i686 packages we're not shipping

[Josh Boyer]

On Tue, Aug 31, 2021 at 12:54 PM Matthew Miller
 wrote:
>
> This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> build stuff like libreoffice for i686, but then (mostly) don't ship it.
> This seems like a waste of resources and time.
>
> I know it's somewhat complicated (for example, there's actually a library
> package in libreoffice, libreofficekit, so that gets plucked in to
> multilib), and there's quite a lot to work out, but ... does this seem like
> a good intended direction?

Are you looking to save people resources or machine resources?

If you're worried about people spending excessive amounts of time
debugging and fixing i686 build failures, then your solution might not
be a bad one.  We wouldn't have to maintain an exception list as
Florian implied.  We'd just empower maintainers to disable i686 builds
via ExcludeArch for leaf packages.  That has potential to be
disruptive to users, but there's no graceful path in stopping
something.  The largest concern would be if a maintainer did that for
a non-leaf package, because that has implications for other
maintainers.

If things are mostly building fine and you're worried about storage or
builder capacity, I'd ask if there are actual concerns or just a "this
seems wasteful" perspective.  If there is no inherent bottleneck or
capacity limits we're pushing against, wasting a machine's time seems
fine.  It's why we invented them.  If the cumulative effect there is
that it's taking a LOT of resources even if there isn't a capacity
problem, then scale can indeed be a concerning factor.

In either case, it seems like what you're actually trying to calculate
is cost/benefit ratio.  I think we've long passed the time when i686
builds were worth it, but we keep doing it because we can think of
cases where it might be useful.  It's the same reason I have a cabinet
full of DVDs but no functional DVD player and stream everything
anyway.  Maybe someday I'd want to watch a DVD?  Might as well keep
them.

/me writes down "rip all my DVDs" on the todo list he'll never read again

josh

> One immediate way to do this is to start adding `ExcludeArch: i686` to
> "leaf" packages (I mean: to allow / encourage people to do that). But I
> don't want to add _more_ cruft to the standard minimal spec file, so this
> seems like the wrong direction. And I still think we want to keep multilib
> for compatibility (hello, old games!). Could we do something clever in koji
> instead?
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Where has the kernel-doc package gone?

[Josh Boyer]

On Mon, Aug 30, 2021 at 1:44 PM Stephen John Smoogen  wrote:
>
> On Mon, 30 Aug 2021 at 13:07, Nils K  wrote:
> >
> > I recently had to perform a bit of development/research where I often had 
> > to take a look in the kernel documentation.
> >
> > Most of the time was spend offline so I wanted to download the `kernel-doc` 
> > package however it does not seem to exist.
> > Some old fedora documentations still refer to it however somewhere in the 
> > 2x iteration of fedora it seems to have gone missing.
> > CentOS 8 also still has it.
> > Would it be possible to add this back to the repos?
>
> It isn't that we aren't shipping it, it is that the Kernel spec file
> does not generate any documentation anymore. It looks like Fedora 20
> made this change but I don't know why beyond
> https://bugzilla.redhat.com/show_bug.cgi?id=1223200 .  While EL-8 is

It required koji hacks to build at the time, and the Fedora kernel
revved daily.  The value of producing the docs package when the same
docs are available on kernel.org was very low.  We removed it.

> based on Fedora-28, the kernel team for RHEL uses a different spec
> file. It also did not start shipping with the kernel-doc but looks to
> have been added with
> https://bugzilla.redhat.com/show_bug.cgi?id=1659636
>
> At this point I suggest you file a bug against the kernel and cite
> those two bugs. The current kernel team can work out what work it
> would be needed and if it could be added.

The move to ARK changed the dynamics a bit.  I think there was a
request elsewhere to build it as well.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: modular bugzilla components

[Josh Boyer]

On Tue, Aug 24, 2021 at 9:22 AM Troy Dawson  wrote:
>
>
>
> On Mon, Aug 23, 2021 at 6:41 PM Orion Poplawski  wrote:
>>
>> The "zabbix" package exists in EPEL8 in two forms:
>>
>> zabbix40 - non-module 4.0 package.
>> zabbix - module with 5.0 stream.
>>
>> Because the "zabbix" dist-git does not have a epel8 branch, there is no
>> "zabbix" component in bugzilla for EPEL8.  Should I create an epel8
>> branch but then retire it just to create a bugzilla component?  Or
>> something else?
>
>
> My opinion, yes.
> This does two things.
> 1 - creates an EPEL zabbix bugzilla component
> 2 - creates a dead.package file in the dist-git branch, that if people read, 
> will point them to the right place.
>
> But that is my opinion.  If others know of a good way to get a bugzilla 
> component in, there might be better ways.

That seems rather complicated.  Perhaps Ben could just add the
component to the EPEL product in bugzilla directly.

Ben, can you do this via the Program Management interfaces?

josh
___
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

Re: building against epel8 modules

[Josh Boyer]

On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia  wrote:

> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek  wrote:
> >
> >
> >
> > On 6/22/21 7:08 PM, Stephen John Smoogen wrote:
>
> > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to
> > > port software to 8. The problem is not with EPEL but with the way
> >
> > hmm.  Thanx a lot of for a bt of light in darknes.. or mayb emore
> darkness in twilight :-)
>
> I can't find *anyone* who likes modularity. I'm devoutly hoping that
> it is discarded for RHEL 9.
>

For the record, it is not being discarded in RHEL 9.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Source-git SIG report #1 (June 2021)

[Josh Boyer]

On Fri, Jun 25, 2021, 8:52 AM Neal Gompa  wrote:

> On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote:
> > >
> > >
> > > On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" 
> wrote:
> > > >On 24. 06. 21 23:07, Miroslav Suchý wrote:
> > > >> Dne 24. 06. 21 v 15:48 Tomas Tomecek napsal(a):
> > >  One thing to consider is that the upstream tarballs might be
> > > >cryptographically
> > >  signed and packages should verify the signature in %prep.
> > > >>> This is a very good point - in such a case, we should always pull
> > > >the
> > > >>> official upstream tarball instead of generating a new one
> downstream
> > > >>
> > > >> Does it matter? If you are able to generate byte2byte identical
> > > >tarball then
> > > >> you can choose any of them.
> > > >
> > > >AFAIK git does not grantee to produce byte2byte identical archives
> > > >across
> > > >different versions of git, zlib, gzip etc. So even if upstream signs
> > > >the git
> > > >generated archive, generating a byte2byte identical one might be
> > > >tricky.
> > >
> > > Especially with xz, which iirc has reproducibility issues in parallel
> mode.
> >
> > I think we should try to push upstream to sign git tags, instead or in
> > addition to tarballs. For upstreams, this is actually much easier
> > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing
> > a tarball on github which requires some interaction with the web service.
> >
>
> As an upstream, I would literally *never* GPG sign git tags. If you
> ask me to do that, I won't. It's far too annoying to deal with for me
> to be willing to suffer through that.
>

I don't get it.  I sign every commit and every tag for the upstream
linux-firmware repo.  It is not onerous.

What issues do you have?

josh


> I'm not going to ask people to do something I would be unwilling to do
> myself.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB

[Josh Boyer]

On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson  wrote:
>
> During our last round of proposals for solutions to missing devel packages, 
> it was noted that EPEL and CentOS has very different documentation for 
> requesting a package be put into RHEL 8.[1][2]
>
> I am betting that CentOS's documentation is correct.  It was written after 
> ours.
>
> When I was talking to the Red Hat people who know, it was noted that Red Hat 
> has much better communication with the Fedora and CentOS communities than the 
> EPEL community.[3]  They wanted to start fixing that communication gap, and 
> figured this would be a good way to start.  So I'm asking Josh Boyer to 
> answer this question on behalf of Red Hat.

Thanks, Troy!

>
> How would Red Hat like us, EPEL maintainers and developers, to request 
> missing devel packages?  (devel packages that are built at the same time as a 
> released library in RHEL8, but not released in RHEL8.  Such as lmdb-devel)

The process as documented on the CentOS wiki page is the best route.
Filing a bug against the package in the Red Hat Enterprise Linux
product family with the CentOS Stream version set will ensure that
both the team maintaining the package in RHEL and some from the CentOS
Stream team are looped in.  Getting the request in front of the owning
RHEL team is key, as they will need to evaluate the request and
consider the implications of providing the devel package.

I would like to make sure and clarify that this is the best approach
for devel packages from SRPMs that are already part of RHEL.
Completely new package requests for things that are not in RHEL at all
are RFEs that should likely come through a case filed in the Customer
Portal for those that have a valid subscription.

> If we follow Red Hat's procedure, what are the odds that the package will 
> make it into RHEL 8 CRB?

This one is harder to answer in a general sense.  I don't want to be
misleading, so I won't give odds because it will vary depending on the
package.  I'll certainly say the odds are better if the requests are
made than if they aren't :)  We have grown the CRB content set by over
100 packages since the initial RHEL 8.0 release, and continue to add
packages even today.  I'd like to also describe some of the
considerations at play as we work on this.

Essentially, the team that owns the package will evaluate the request
to ensure it's consistent with the manner in which the package is
intended to be used as part of RHEL.  Often enabling other software to
build against a RHEL package, particularly for things like EPEL
enablement, is a perfectly valid use case.  Once a valid use case has
been established the team will ensure they can meet any obligations
required by adding it as part of the RHEL product and sign off.  After
the team has agreed, the package will first appear in CentOS Stream
PowerTools (or occasionally AppStream), and then in a future RHEL
minor release.

At times, we have included a library or package as an internal
implementation detail and do not encourage wider use of that package
for other software.  This is a relatively rare case.  I can only think
of one stand-out package that comes to mind thus far.  If it does
happen the team may decide not to provide the devel package.  Filing
the request is often the best way to begin that dialog.  This helps us
understand how a package is being used and take that into
consideration for future RHEL releases, and also allows discussion and
suggestions for alternative packages that may be more suitable in the
long term.

I'm sure there are many that would simply like all subpackages of all
SRPMs to be shipped, however that is not the approach RHEL is taking
from a product perspective.  Blanket requests for everything are not
likely to go far.  It's simply not actionable at the same level as
targeted requests.

As an aside, I am particularly encouraged to see EPEL-Next come to
fruition and combined with CentOS Stream and the broader set of
packages available in that project buildroot I think there is a lot of
potential to grow the overall ecosystem.  I believe EPEL has discussed
this recently with some hesitation, but I would encourage you to
consider if and how EPEL-Next and CentOS Stream might be leveraged to
help EPEL proper as well.  From what I've seen, this community is
amazing and I think there are opportunities there.

Thanks again Troy, for giving me the opportunity to interact with the
EPEL community.  This is quite overdue.

josh

>
> Thanks
> Troy Dawson
>
> [1] - 
> https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
> [2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages
> [3] - Yes, I write my emails here from my redhat email address, but I do not 
> represent Red Hat in my EPEL capacities.
_

Re: What are https://src.fedoraproject.org/container ?

[Josh Boyer]

On Sat, Jun 12, 2021, 8:01 AM Neal Gompa  wrote:

> On Sat, Jun 12, 2021 at 7:54 AM Josh Boyer 
> wrote:
> >
> >
> >
> > On Thu, Jun 10, 2021, 8:35 AM Stephen Gallagher 
> wrote:
> >>
> >> On Thu, Jun 10, 2021 at 5:51 AM Richard W.M. Jones 
> wrote:
> >> >
> >> > On Thu, Jun 10, 2021 at 09:39:38AM +0100, Ankur Sinha wrote:
> >> > > On Thu, Jun 10, 2021 09:02:47 +0100, Richard W.M. Jones wrote:
> >> > > >
> >> > > > This appeared yesterday:
> >> > > > https://src.fedoraproject.org/container/libguestfs
> >> > > >
> >> > > > I'm wondering what it is?
> >> > >
> >> > > That should be the container image generated from the Fedora
> package for
> >> > > the Fedora registry:
> >> > >
> >> > > https://docs.fedoraproject.org/en-US/containers/
> >> >
> >> > So it would be a container built on top of Fedora Rawhide containing
> >> > libguestfs?  Do we intend to build containers like this from other
> >> > Fedora packages?  I'm curious what the use case is.
> >> >
> >> > (NB: this is not an objection to anything, people can build containers
> >> > for whatever they want for all I care)
> >> >
> >>
> >> This specific example is to address one of the FESCo concerns about
> >> the cloud VM images using btrfs by default. Since RHEL VM host systems
> >> cannot read the btrfs filesystem, we want to ship a containerized
> >> version of libguestfs that CAN.
> >
> >
> > That can what?  As far as I know, libguestfs relies on the host to mount
> the filesystem.  A container still depends on the host kernel, which means
> a rhel VM still isn't going to be able to mount the guest btrfs disk...
> >
>
> At build-time, libguestfs copies the content of the kernel package
> along with binaries of various filesystem tools into itself to run a
> custom appliance for manipulating VMs. The Fedora-based libguestfs
> package can handle Btrfs even on RHEL because it relies on the
> binaries of the Fedora kernel and filesystem utilities instead of the
> RHEL ones. It will run QEMU and boot up *its* VM to manipulate VM
> stuff. That's even how guestfish works for mounting VM disks on the host.
>

Gotcha.  Thanks.

josh
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure