from:"Stephen Gallagher"

On Mon, Jan 22, 2024 at 2:11 PM Miro Hrončok  wrote:
>
> On 22. 01. 24 20:04, Stephen Gallagher wrote:
> > On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok  wrote:
> >>
> >> On 22. 01. 24 19:07, Stephen Gallagher wrote:
> >>> I am unaware of any remaining use cases for buildroot overrides that
> >>> are not covered by side tags. If you know of any, please speak up.
> >>
> >> Every time somebody asks this, I say: Pull Requests CI
> >>
> >> I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
> >>
> >> It works in CentOS Stream, but not in Fedora.
> >>
> >> Without that, I sometimes need to create a buildroot override to be able to
> >> test the the second package change before merging it.
> >>
> >
> > This sounds a lot more like a workaround than a use-case, but it's
> > good to know about. So thank you.
>
> Yes, it is.
>
> > Unfortunately, I feel like that workaround is dangerous, since it is
> > putting untested code into the buildroot.
>
> In this case the PR-based CI has already passed for the build I add as a
> buidlroot override.
>
> > I would like to see that get
> > fixed properly with support for the side tags.
>
> I would like that very much. However, it seems it has not been a priority.
>
> > In the meantime, if we
> > otherwise disabled free-access buildroot overrides, this would
> > definitely be grounds for granting an exception.
>
> How would that work? Would I ask FESCo every time I need to do it?

If it's something that a specific packager has justifiable cause to do
on a regular basis, I think we could potentially grant them that
privilege (at least until we get a proper solution in place). Or do
you think this is the sort of thing where the number of people needing
this access would be prohibitively high?
--
___
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: Proposal: Eliminate buildroot overrides

On Mon, Jan 22, 2024 at 1:55 PM Miro Hrončok  wrote:
>
> On 22. 01. 24 19:07, Stephen Gallagher wrote:
> > I am unaware of any remaining use cases for buildroot overrides that
> > are not covered by side tags. If you know of any, please speak up.
>
> Every time somebody asks this, I say: Pull Requests CI
>
> I opened https://pagure.io/fedora-ci/general/issue/240 almost 3 years ago.
>
> It works in CentOS Stream, but not in Fedora.
>
> Without that, I sometimes need to create a buildroot override to be able to
> test the the second package change before merging it.
>

This sounds a lot more like a workaround than a use-case, but it's
good to know about. So thank you.

Unfortunately, I feel like that workaround is dangerous, since it is
putting untested code into the buildroot. I would like to see that get
fixed properly with support for the side tags. In the meantime, if we
otherwise disabled free-access buildroot overrides, this would
definitely be grounds for granting an exception.
--
___
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: Proposal: Eliminate buildroot overrides

On Mon, Jan 22, 2024 at 1:55 PM Florian Weimer  wrote:
>
> * Stephen Gallagher:
>
> > I am unaware of any remaining use cases for buildroot overrides that
> > are not covered by side tags. If you know of any, please speak up.
>
> The overrides are more discoverable:
>
>   <https://bodhi.fedoraproject.org/overrides/?expired=False>
>

> With side tags, you really have to know the name, or you won't be able
> to find it.  On the other hand, you can just make your own and tag the
> builds into it, so creating yet another one isn't that much of a problem
> because they expire evenutally, just like overrides.
>


What does that gain you, though? I'm not clear on the use-case here.
Generally when there's a multi-packager effort going on for a
side-tag, it's coordinated by mail or IRC between people. I'm not sure
when you'd need to "discover" it.
--
___
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: Proposal: Eliminate buildroot overrides

On Mon, Jan 22, 2024 at 1:53 PM Florian Weimer  wrote:
>
> * blinxen:
>
> >> I am unaware of any remaining use cases for buildroot overrides that
> >   are not covered by side tags
> >
> > One use case that I sometimes encounter is requiring a newer version
> > for a dependency, that is submitted to Bodhi with a side-tag. Since
> > the build is in a side-tag, I can't access it without building into
> > that specific side-tag. Also I can't stop the Bodhi Update just to add
> > my own build. In this case, I need to create a buildroot override to
> > be able to build my package in my own side-tag.
>
> I think you can tag that build into your side tag?  This should require
> provenpackager privileges, as far as I understand it.
>

Yes, if you have privileges on the other package, I think you can just
do `koji tag  N-V-R`
--
___
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

Proposal: Eliminate buildroot overrides

tl;dr: Buildroot overrides should be restricted to releng members and
packagers should use on-demand side-tags instead.

I'd like to ascertain whether there are any remaining use-cases for
which buildroot overrides are preferable to (or necessary instead of)
on-demand side-tags. We've had support for side-tags for some years
now (my history-spelunking suggests 2020, but it might be longer).

Some of the advantages of side-tags over the old buildroot override approach:

1) The common buildroot for packages is not polluted.
Historically, one would build a new library package, tag it into a
buildroot override, then build the packages that depend upon it.
During this time, the (possibly backwards-incompatible) package would
remain in the common buildroot, potentially impacting other packages'
builds. With side-tags, the updated libraries don't affect other
builds until the side tag has completed and been merged into the main
release. This action also ensures that the contents of the side-tag go
through Bodhi and are properly reviewed, which helps avoid cases where
the packager may not have been aware of other potential breakage.

2) Side tags are easy to abandon.
If, in the middle of a large update, a major issue occurs (the change
needs to be backed out or priorities shift and it cannot be completed
in time), the side-tag can be either aborted or ignored until later.
It doesn't require going through any effort to revert changes the way
that buildroot overrides would.

3) Side tags make it much easier to submit multiple, related package
updates together.
Prior to side-tag support, including multiple packages in a single
Bodhi update was a highly manual effort. Now, as long as they were
built together in the side tag, they can be easily submitted together
as a single update.

I am unaware of any remaining use cases for buildroot overrides that
are not covered by side tags. If you know of any, please speak up.
Otherwise, my proposal that I plan to take to FESCo is to disallow the
general use of buildroot overrides in favor of side tags. Buildroot
overrides themselves wouldn't go away, but they'd be restricted to
members of Fedora Release Engineering in exceptional situations.

Thank you in advance for your input.

Documentation on side-tags and multiple-package updates:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages
--
___
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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

2024-01-19 Thread Stephen Gallagher

On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher  wrote:
>
> On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik  wrote:
> >
> > Hello,
> > I just wanted to quickly announce a small project I did in collaboration 
> > with the Packit folks.
> >
> > Do you have some tools or services that perform actions on all currently 
> > active Fedora releases? And do you have to manually update their list every 
> > time a new Fedora release is branched or EOLed? The fedora-distro-aliases 
> > will make your life easier.
> >
> > https://github.com/rpm-software-management/fedora-distro-aliases
> >
> > It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, 
> > etc. To evaluate them, it queries Bodhi, so they are always up-to-date (but 
> > the tradeoff is that it requires an internet connection). There are 
> > multiple examples in the project README but the usage is simple, e.g.:
> >
> > >>> from fedora_distro_aliases import get_distro_aliases
> > >>> aliases = get_distro_aliases()
> > >>> [x.namever for x in aliases["fedora-all"]]
> > ['fedora-38', 'fedora-39', 'fedora-rawhide']
> >
> > The package is already in Fedora, give it a shot,
>
> Thanks! I'll look into updating
> https://github.com/sgallagher/get-fedora-releases-action with this.

Scratch that, it appears that `pip3 install fedora_distro_aliases`
requires installing krb5 devel packages (and compiling it) on the
target system before it can be used. This had the effect in my testing
of increasing the time spent running my Action from ~10s to ~240s,
which is too big of an increase. Is there a good reason why you're
using the complete BodhiClient interface instead of just doing simple
HTTP requests against https://bodhi.fedoraproject.org/releases ?
--
___
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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

2024-01-18 Thread Stephen Gallagher

On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik  wrote:
>
> Hello,
> I just wanted to quickly announce a small project I did in collaboration with 
> the Packit folks.
>
> Do you have some tools or services that perform actions on all currently 
> active Fedora releases? And do you have to manually update their list every 
> time a new Fedora release is branched or EOLed? The fedora-distro-aliases 
> will make your life easier.
>
> https://github.com/rpm-software-management/fedora-distro-aliases
>
> It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, etc. 
> To evaluate them, it queries Bodhi, so they are always up-to-date (but the 
> tradeoff is that it requires an internet connection). There are multiple 
> examples in the project README but the usage is simple, e.g.:
>
> >>> from fedora_distro_aliases import get_distro_aliases
> >>> aliases = get_distro_aliases()
> >>> [x.namever for x in aliases["fedora-all"]]
> ['fedora-38', 'fedora-39', 'fedora-rawhide']
>
> The package is already in Fedora, give it a shot,

Thanks! I'll look into updating
https://github.com/sgallagher/get-fedora-releases-action with this.
--
___
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: dnsmasq default configuration changed

2024-01-15 Thread Stephen Gallagher

On Mon, Jan 15, 2024 at 11:32 AM Kevin Kofler via devel
 wrote:
>
> Petr Menšík wrote:
> > systemd-resolved is unfortunately known to broken.
> [snip]
> > Dnsmasq does not break DNSSEC, systemd-resolved does.
> [snip]
> > Unfortunately broken are clients having systemd-resolved enabled.
>
> How exactly is it broken? If you refer to:
> https://github.com/systemd/systemd/issues/25676
> fixes for that are finally coming in now (as of 3 weeks ago).
>
> > I would recommend having systemd-resolved forwarded to dnsmasq, which can
> > then be forwarded further.
>
> If you think dnsmasq should replace systemd-resolved by default, then please
> propose that through the Changes process, which will also ensure the glibc
> resolver, NetworkManager, and the like get configured properly for it.
> Simply shipping dnsmasq with a default configuration that conflicts with
> systemd-resolved is not a productive approach.
>
> If systemd-resolved is really broken, then it either needs to be fixed or
> replaced. The former needs to be handled through systemd upstream, the
> latter through the Fedora Changes process.
>
> > But this change should create conflict with systemd-resolved only in case
> > it was improperly configured.
>
> But the default configuration you ship will conflict.
>
> > Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard
> > resolver does. You can use listen-address=127.0.0.53 if you like, but
> > then it will conflict with systemd-resolved.
>
> You just wrote that you make it listen by default on all interfaces, and
> then filter. This means it will conflict over the port 53. That said,
> listening on the lo interface only will also conflict with systemd-resolved
> or any other local resolver, so you are probably right that your change does
> not change much for the default configuration, it just makes it harder (more
> settings to change) to set up coexistence. 127.0.0.53 is unfortunately not
> an independent interface, it is still the lo interface.
>
> > On 14. 01. 24 1:57, Kevin Kofler via devel wrote:
> >> On a server I administer for work, I have dnsmasq serving the DNS for an
> >> ocserv (OpenConnect) VPN, listening only on the VPN interface. Any
> >> request for a host not within the VPN network (coming in from clients
> >> with no or broken split DNS support, e.g., old GNU/Linux distros without
> >> systemd- resolved, or Windows, where the OpenConnect client is still
> >> unable to set up split DNS) is forwarded to systemd-resolved, which in
> >> turn forwards it to the upstream DNS from the datacenter. Relying instead
> >> on the filtering would not have worked exactly for the reason you
> >> describe above. But that server is not running Fedora anyway.
> >
> > I would recommend to skip systemd-resolved stub and using
> > resolv-file=/run/systemd/resolve/resolv.conf
> >
> > in such case. It would use servers configured by systemd-resolved, but
> > without using broken port domain at address 127.0.0.53. Alternatively
> > use server=127.0.0.54, which should not break incoming queries so much.
>
> Well, I do not see a good reason to disable systemd-resolved for the
> server's own queries (which includes the forwarding queries from dnsmasq, if
> the domain is not one it knows). It just works.
>
> > Consider using unbound as a cache for other VPN clients. dnsmasq is
> > great for its integration with DHCP server, but is targeted to use
> > minimal resources. Unfortunately at cost of some design issues. Unbound
> > is a high quality cache, while still relatively small compared to bind's
> > named.service.
>
> Using minimal resources is exactly what I want here. Which is why I do not
> want to use dnsmasq for what systemd-resolved can do, nor unbound for what
> dnsmasq can do.
>
> And sending the server's own queries through dnsmasq is not going to work
> (not without a second instance, at least), because the VPN server is not a
> VPN client, so I have the server's /etc/hosts resolve its own domain to
> 127.0.0.1 (not the public IP, because services listen only on localhost and
> the VPN, that is what the VPN is for), which is honored by systemd-resolved,
> whereas my dnsmasq configuration overrides this to return the VPN IP to the
> VPN clients querying that same domain. Sounds hackish, but works great.
>

Based on my reading of this thread, this change is going to break the
default configuration and needs to be reverted immediately. Petr,
please file a Change Proposal for Fedora *41*. You have missed the
deadline for F40 System-Wide Changes (Dec. 26th) and this is
absolutely NOT a self-contained Change.
--
___
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:

Re: auditd systemd preset

2024-01-15 Thread Stephen Gallagher

On Mon, Jan 15, 2024 at 12:01 PM Steve Grubb  wrote:
>
> Hello,
>
> I have a procedural question. Auditd-4.0 is ready for release. One of the
> major changes is splitting rule loading from logging in the service. IOW, it
> was one service doing both and now would be two services. Auditd would depend
> on the rule loader, but the rule loader would not depend on auditd in case
> you wanted to log to journald only.
>
> Auditd is one of the few programs that has a preset such that if it is
> installed, it is automatically enabled. I think we'd need the same thing for
> the rule loading service. I have been testing it with an addition to /usr/
> lib/systemd/system-preset/90-default.preset and it seems to work as expected.
>
> Would this update require just a FESCO ticket asking for the preset or does
> this need both a FESCO ticket and a self-contained change notice?
>

The official docs are here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/

There's a link in that doc above to create a Bugzilla ticket with
boilerplate questions that gets forwarded to the fedora-release
maintainers to review the request. (Usually, me). Based on those
questions, I will either go ahead and make the change if it meets the
requirements or else raise it to FESCo for approval if it isn't
eligible to be auto-approved.
--
___
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: [Fedocal] Reminder meeting : ELN SIG

2024-01-12 Thread Stephen Gallagher

On Thu, Jan 11, 2024 at 7:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2024-01-12 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:

The upcoming inheritance break for CentOS Stream 10 at the Fedora 40
Branch event.

>
> Source: https://calendar.fedoraproject.org//meeting/10568/
>
> --
> ___
> 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: Heads up: libgweather4 to libgweather rename in rawhide

2024-01-10 Thread Stephen Gallagher

On Wed, Jan 10, 2024 at 1:38 PM Yaakov Selkowitz  wrote:
>
> On Wed, 2024-01-10 at 19:13 +0100, Kalev Lember wrote:
> > On Wed, Jan 10, 2024 at 6:47 PM Yaakov Selkowitz
> > 
> > wrote:
> >
> > > Since the previous libgweather versions were 40.y and the new
> > > versions
> > > are 4.4.z, shouldn't there be an Epoch?
> > >
> >
> > I was thinking about this hard as well and I managed to convince
> > myself
> > that it should be fine without an epoch, for two reasons:
> >
> > 1) The libgweather package was last part of the F38 package set, and
> > has
> > been retired ever since (in F39+). Because of that, new F39 installs
> > don't
> > have the package, and people who have updated from F38 to either F39
> > or
> > current rawhide (F40) don't have the package either (it was obsoleted
> > in
> > fedora-obsolete-packages).
> >
> > 2) This only leaves people who would do F38->F40 distro upgrade in
> > the
> > future, but I think this case should be fine as well because AFAIK
> > both dnf
> > and PackageKit use distro-sync for distro upgrades, so they handle
> > downgrades just fine.
> >
> > Normally this should have definitely warranted an epoch, but because
> > it was
> > retired for a long time, I believe it should be fine without. We can
> > also
> > always add an epoch in the future if it turns out we missed some
> > case.
> >
> > What do you think?
> > >
>
> Still concerned.  You've mentioned those who have already upgraded 38-
> >rawhide, but what about those who *will* upgrade (e.g. post-branching)
> 38->40?  Since that is a supported upgrade path, and 38 had 40.0, this
> will be a downgrade.  If this wasn't landing until F41 the answer could
> be different, but it really hasn't been out long enough.  After all,
> the fedora-obsolete-packages entry was set to be removed for F41 for a
> reason.

I agree with Yaakov here.

While you're correct that the standard upgrade mechanism now defaults
to using `dnf distro-sync`, it's not the ONLY upgrade path that people
take. There are a huge number of users who still insist on doing a
basic DNF upgrade, no matter how much documentation we write. This
WILL cause issues for them and will translate into bug reports that
need to be at least triaged. So please, just support a clean upgrade
path with the epoch bump.

> Also, what about RHEL upgrades?  c9s has libgweather-40.0, this will
> cause c10s to have 4.4.0.
>

RHEL major upgrades have special tooling, so I wouldn't worry about that.

> 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

F40 Approved Change Announcement (2024-01-08)

2024-01-08 Thread Stephen Gallagher

There is no FESCo meeting scheduled for today due to the close
proximity to the previous meeting. However, we have two approved
Changes to announce:

= Discussed and Voted in the Ticket =

Change: Boost 1.83 Upgrade
https://pagure.io/fesco/issue/3127
APPROVED (+7, 0, -0)

Change: Podman 5
https://pagure.io/fesco/issue/3126
APPROVED (+6, 0, -0)
--
___
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: rawhide missing xgettext: command not found

2024-01-05 Thread Stephen Gallagher

On Fri, Jan 5, 2024 at 8:16 AM Martin Gansser  wrote:
>
> I'm just wondering why my packages under rawhide suddenly need gettext as a 
> dependency ?
>
> should i set an if condition for rawhide ?
>
> %if 0%{?fedora} >= 40
> BuildRequires:  gettext
> %endif

This shouldn't be conditional. If you require gettext, you should
`BuildRequires: gettext`.

If it worked before, it was accidental (something else you had a BR on
must have pulled it in). That subsequently changed. You can't rely on
that behavior even to remain in released Fedoras, so just add the
requirement explicitly to your specfile.
--
___
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: F40 Change Proposal: LLVM 18 (System-Wide)

2024-01-05 Thread Stephen Gallagher

On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney  wrote:
>
> Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18
>
> 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 ==
> Update all llvm sub-projects in Fedora Linux to version 18.
>
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
>
> == Detailed Description ==
> All llvm sub-projects in Fedora will be updated to version 18, and
> there will be a soname version change for the llvm libraries.
> Compatibility packages clang17, llvm17, and lld17 will be added to
> ensure that packages that currently depend on clang and llvm version
> 17 libraries will continue to work.  We may add other compatibility
> packages too if they're determined to be necessary to maintain
> functionality in other RPMS that use llvm/clang.  We also plan to
> retire these older compatibility packages (that we own):
>
> * llvm14
> * llvm15
> * llvm16
> * clang14
> * clang15
> * clang16
> * lld14
> * lld15
> * lld16
>
> We will also be asking the maintainers of the following packages to
> retire them if possible:
>
> * llvm7.0
> * llvm8.0
> * llvm11
> * llvm12
> * llvm13
>
> Other notable changes:
>
> * clang will emit DWARF-5 by default instead of DWARF-4.  This matches
> the upstream default.  We have been using DWARF-4 as the default for
> the last few releases due to:
> https://bugzilla.redhat.com/show_bug.cgi?id=2064052
> * The compatibility packages will now include the same content as the
> main package.  In previous releases, the compatibility packages
> contained only libraries and headers, and the binaries and other
> content was stripped out.  These packages will be supported for use as
> dependencies for other RPM packages, but not for general purpose usage
> by end users.  Fedora users should use Clang/LLVM 18.
> * The compatibility packages added for Fedora 40 will be retired prior
> to the Fedora 41 branch.
> * We will be enabling Fat LTO in redhat-rpm-config if this feature is
> complete in time for the upstream LLVM 18 release.  Fat LTO is a
> feature that allows the compiler to produce libraries that contain LTO
> bitcode along side the traditional ELF binary code so that the
> libraries can be linked in both LTO mode and non-LTO mode.  gcc also
> supports this feature and has it enabled in Fedora.  In Fedora 39 and
> older, with LTO enabled, clang produces binaries with only LTO
> bitcode, so we need to run a post-processing script
> (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code
> so they can be used by other packages.  Enabling Fat LTO will allow us
> to remove this script and simplify the build process.
>
> ===LLVM Build Schedule===
>
> Important Dates
>
> * Jan  26: Upstream: 18.0.0-rc1 Release
> * Feb   6: Fedora: f40 branch created
> * Feb   6: Upstream: 18.0.0-rc2 Release
> * Feb  20: Fedora: f40 Beta Freeze
> * Feb  20: Upstream: 18.0.0-rc3 Release
> * Mar   5: Upstream: 18.0.0 Release
> * Apr   2: Fedora: f40 Final Freeze
>
> Plan
> # Build nightly trunk (LLVM 18) snapshots in
> [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots/packages/
> copr].
> # Build LLVM 18.0.0-rc1 in COPR.
> # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
> # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
> # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
> # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
> # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
> # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
> # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not
> ready) as a Beta Freeze exception.
> # Continue building new release candidates and pushing them to stable
> until the Final Freeze.
>
> We are not planning to push 18.0.0-rc1 into rawhide because the
> library ABI is not stabilized at that point. Typically, the ABI
> stabilizes after -rc3, but there are no guarantees from upstream about
> this.  Given the history of minimal ABI changes after -rc3, we feel
> like it's safe to push -rc3 into rawhide.  The worst case scenario
> would be an ABI change -rc4 or the final release that we force us to
> patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario
> would not require rebuilding LLVM library users in Fedora, so this
> would not require much extra work from our team.
>
> Updates after 18.0.0-rc3 will generally be very small and can be done
> after the Final Freeze is over.  If we are late packaging release
> candidates after -rc3 or the final release, we will not ask for a
> Final Freeze exception, unless they contain a fix for a critical
> release blocking bug.
>
> == Feedback ==
>

This came in while I was on PTO, so my apologies for the late reply on it.

My concern here is with the timing and its inclusion

Re: Schedule for Thursday's FESCo Meeting (2024-01-04)

2024-01-04 Thread Stephen Gallagher

=
#fedora-meeting-2: FESCO (2024-01-04)
=


Meeting started by sgallagh at 17:00:18 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2024-01-04/fesco.2024-01-04-17.00.log.html
.



Meeting summary
---
* Init Process  (sgallagh, 17:00:34)

* #3101 Change: Remove OpenSSL Compat  (sgallagh, 17:09:26)
  * AGREED: The Change is approved, any package still depending on
openssl-compat at Beta Freeze will be dropped from Fedora at that
time. (+7, 0, -1)  (sgallagh, 17:26:11)

* New Meeting Time  (sgallagh, 17:26:47)
  * LINK: https://whenisgood.net/agyhckd/results/sxn8wpk   (sgallagh,
17:27:11)
  * The new FESCo meeting time will be at 1930 UTC, beginning on
2024-01-16  (sgallagh, 17:41:35)

* Next Week's Chair  (sgallagh, 17:43:23)
  * ACTION: sgallagh to send out the voting announcements on 2024-01-08
(sgallagh, 17:44:02)
  * ACTION: tstellar will chair the 2024-01-15 meeting and offers to
mentor jistone at the same time  (sgallagh, 17:49:40)

* Open Floor  (sgallagh, 17:49:52)
  * ACTION: sgallagh to update the FESCo Meeting Process with new
bat-time, new bat-location  (sgallagh, 17:57:15)

Meeting ended at 18:01:26 UTC.




Action Items

* sgallagh to send out the voting announcements on 2024-01-08
* tstellar will chair the 2024-01-15 meeting and offers to mentor
  jistone at the same time
* sgallagh to update the FESCo Meeting Process with new bat-time, new
  bat-location




Action Items, by person
---
* jistone
  * tstellar will chair the 2024-01-15 meeting and offers to mentor
jistone at the same time
* sgallagh
  * sgallagh to send out the voting announcements on 2024-01-08
  * sgallagh to update the FESCo Meeting Process with new bat-time, new
bat-location
* tstellar
  * tstellar will chair the 2024-01-15 meeting and offers to mentor
jistone at the same time
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (80)
* Son_Goku (39)
* nirik (21)
* dcantrell (20)
* zbyszek (18)
* zodbot (17)
* jistone (17)
* jednorozec (17)
* tstellar (8)
* michel-slm (7)
* smooge (6)
* decathorpe (4)
* jonathanspw (2)
* humaton (0)
* mhayden (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)
* Eighth_Doctor (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
--
___
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

Schedule for Thursday's FESCo Meeting (2024-01-04)

2024-01-03 Thread Stephen Gallagher

Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2024-01-04 17:00 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Change: Wget2 as wget
https://pagure.io/fesco/issue/3118
APPROVED (+5, 0, -0)

Change: 389 Directory Server 3.0.0
https://pagure.io/fesco/issue/3120
APPROVED (+4, 0, -0)

Change: Systemd Security Hardening
https://pagure.io/fesco/issue/3117
APPROVED (+4, 0, -0)

Change: Linker Error On Security Issues
https://pagure.io/fesco/issue/3110
APPROVED (+4, 0, -0)


= Followups =

#3101 Change: Remove OpenSSL Compat
https://pagure.io/fesco/issue/3101

= New business =

#topic New Meeting Time

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
--
___
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: Are package-owner mail addresses working?

2024-01-03 Thread Stephen Gallagher

On Wed, Jan 3, 2024 at 8:15 AM Sergio Pascual  wrote:
>
> El lun, 1 ene 2024 a las 13:49, Mamoru TASAKA
> () escribió:
> >
> > Sergio Pascual wrote on 2024/01/01 21:36:
> > > Hello and happy new year.
> > >
> > > Are package-owner mail addresses working? I have send mails to several
> > > and they return a 550 error message, for example:
> > >
> > > 550 5.1.1 : Recipient address
> > > rejected: User unknown in local recipient table
> > >
> > > Best, Sergio
> > > --
> >
> > Currently it is -maintain...@fedoraproject.org :
> >
> > https://fedoraproject.org/wiki/EmailAliases
> >
>
> Great, thank you. In that case, the "senmail.to" property in the rpm
> git repositories should be updated to point to the correct address. I
> have checked several repositories and all have -owner addresses there.
>
> For example:
>
> $ git config sendemail.to
> cfitsio-ow...@fedoraproject.org
>


Please file a report with Fedora Infrastructure at
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: [Fedocal] Reminder meeting : ELN SIG

2023-12-15 Thread Stephen Gallagher

I’m canceling the meeting today as we don’t have anything urgent to discuss.

The next meeting will be in January.

On Thu, Dec 14, 2023 at 7:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-12-15 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/10568/
>
> --
> ___
> 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: Proven to be sickened

2023-12-11 Thread Stephen Gallagher

On Sun, Dec 10, 2023 at 9:49 PM Gary Buhrmaster
 wrote:
...
>
> FTBFS issues are, admittedly, complicated, but
> such updates SHOULD be via a PR.  If a PP wants
> to claim they cannot follow that process, they need
> to demonstrate that a particular packager is not
> responsive (there is a process for that) rather
> then just deciding themselves it is too much trouble.

While I generally agree that a merge request is a more polite and
elegant solution, if a package is listed as FTBFS (having had a bug
automatically opened) and some reasonable amount of time (two, three
weeks?) has passed, then I think it's perfectly reasonable to assume
that the maintainer is vacant (either entirely or because they lack
the available time to deal with it at this point). In that case, I
don't see it as a problem to jump in and fix the package as a
provenpackager if the fix is relatively minor (yes, this is
subjective). I'd hesitate at rebasing to a new version, but if the
issue is that a dependency changed its name or the newest gcc made a
warning into an error, I think that's a perfectly acceptable fix to
make. The ideal case is for it to go through a merge request, but if
the package happens to be blocking other work, I think expediency is
completely warranted.
--
___
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: goal: booting with an empty /etc

2023-12-08 Thread Stephen Gallagher

On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> There is a long-term goal of moving packaged files out of /etc, so that
> only actual local configuration remains in /etc. This has some advantages:
>
> - Local configuration, i.e. the result of local administrative actions,
>   is nicely split from static configuration that is part of package payload.
>   'find /etc' will show what is special to this local system, while
>   'find /usr' lists stuff that is part of packages and the same between
>   systems.
> - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
>   to return everything to distro defaults. We're not there _yet_, but it
>   works with a surprisingly large subset of packages.
> - We can support "factory reset" at a package level, by removing all the
>   configuration and state of an individual package, without reinstalling it
>   (possibly combined with some tmpfiles.d config to recreate things
>   automatically.)
> - It becomes easier to build systems which are delivered as a stand-alone
>   /usr-partition. This could be ostree-style systems, or image-based systems
>   with the /usr-partition read-only and protected by dm-verity. We're not
>   there _yet_, but many people are experimenting with this.
>
> When one looks in /etc, many of the files there are not "configuration".
> For example, /etc/services is a list of port:service mappings, and people
> maybe used to edit that twenty years ago, but now it's just a static file
> that just as well may be somewhere under /usr/lib/. The same is also
> true for /etc/bash_completion.d/ — people do not edit completion scripts.
> Most of those have been moved to /usr/share/bash-completion/completions/,
> but there's still a dozen or so in /etc.
>

One thing that is becoming much more common is for us to ship such
static files in /usr/lib and include a default symlink in /etc for
those packages whose presence there is effectively API (for example
/etc/os-release is a symlink to /usr/lib/os-release, similarly
/etc/resolv.conf). I think this is a very good approach and one that
we should probably look at formalizing in the packaging guidelines.

That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/*
and /etc/fstab which are both API *and* sometimes see manual updates.
These are some of the cases that are going to make getting to an empty
/etc very hard to finish off. There's a lot of low-hanging fruit we
can take care of in the meantime, but getting the last 1% of packages
done is going to take a lot of inter-distro conversations.
--
___
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: [ELN] Mass-rebuild to import packages to CentOS Stream 10 starts today

2023-12-08 Thread Stephen Gallagher

Re-adding Fedora Devel for awareness.


On Fri, Dec 8, 2023 at 7:35 AM Michal Pospíšil (he / him) <
mposp...@redhat.com> wrote:

> Hello Stephen,
>
> Does this mean that any changes in rawhide after the rebuild will not get
> into CentOS Stream 10? I wanted to add a new subpackage to pcs next week so
> that it can be imported to CentOS Stream 10.
>
>
> Kind regards
> Michal
>
> On Thu, 7 Dec 2023 at 15:46, Stephen Gallagher 
> wrote:
>
>> First, let me apologize for the short notice on this. We've been
>> discussing it at the public ELN meetings over the last month, but I
>> only just now realized that I forgot to send out one of these general
>> announcements.
>>
>> Over the last few months, you've probably seen a number of Fedora ELN
>> packages preliminarily imported into Gitlab for CentOS Stream 10 as we
>> get the machinery working. As of today, we've finally cleared the
>> remaining blockers to perform the full import of both runtime and
>> buildroot-only packages.
>>
>> We are going to trigger a mass-rebuild of those packages included in
>> Fedora ELN later today in a side-tag, which will likely continue
>> through the weekend. All of the packages that successfully rebuild
>> will be automatically imported into CentOS Stream 10 via automation
>> and we will look into any and all failures over the course of next
>> week. This mass-rebuild will be performed with "background" priority
>> in Koji to minimize the impact on other builds, but there is still a
>> high likelihood that you may have a longer-than-usual waiting time for
>> your package builds. Fortunately, Fedora ELN is a relatively small
>> subset of Fedora packages (~2,500 vs Fedora's ~37,000), so it
>> shouldn't be too bad.
>>
>> This mass-rebuild will automatically retry failed builds at least once
>> (to help rule out test-flakes/infra hiccoughs) and possibly numerous
>> times, since they are all being submitted to the automation as a
>> single, large batch. Please do not panic if you see your package being
>> submitted and failing repeatedly. For more information on the rebuild
>> strategy we use, please see
>>
>> https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/
>>
> --
>> ___
>> 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
>>
>
>
> --
>
> MICHAL POSPÍŠIL
> He / Him / His
>
> Software Engineer
>
> RHEL HA Cluster - PCS
>
> Red Hat Czech, s.r.o. <https://www.redhat.com>
> Purkyňova 97b, 612 00 Brno
> <https://www.google.com/maps/search/Purky%C5%88ova+97b,+612+00+Brno?entry=gmail=g>
>
> mposp...@redhat.comIRC: mpospisi
> <https://www.redhat.com>
>

No, the sync from Rawhide to CentOS Stream continues until the Fedora 40
branching event on February 6th. The purpose of this mass rebuild is to get
the remaining pieces in place and ensure that the sync is properly set up
for all of the packages.

There will be additional announcements made as we get closer to February.
--
___
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

[ELN] Mass-rebuild to import packages to CentOS Stream 10 starts today

2023-12-07 Thread Stephen Gallagher

First, let me apologize for the short notice on this. We've been
discussing it at the public ELN meetings over the last month, but I
only just now realized that I forgot to send out one of these general
announcements.

Over the last few months, you've probably seen a number of Fedora ELN
packages preliminarily imported into Gitlab for CentOS Stream 10 as we
get the machinery working. As of today, we've finally cleared the
remaining blockers to perform the full import of both runtime and
buildroot-only packages.

We are going to trigger a mass-rebuild of those packages included in
Fedora ELN later today in a side-tag, which will likely continue
through the weekend. All of the packages that successfully rebuild
will be automatically imported into CentOS Stream 10 via automation
and we will look into any and all failures over the course of next
week. This mass-rebuild will be performed with "background" priority
in Koji to minimize the impact on other builds, but there is still a
high likelihood that you may have a longer-than-usual waiting time for
your package builds. Fortunately, Fedora ELN is a relatively small
subset of Fedora packages (~2,500 vs Fedora's ~37,000), so it
shouldn't be too bad.

This mass-rebuild will automatically retry failed builds at least once
(to help rule out test-flakes/infra hiccoughs) and possibly numerous
times, since they are all being submitted to the automation as a
single, large batch. Please do not panic if you see your package being
submitted and failing repeatedly. For more information on the rebuild
strategy we use, please see
https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[ELN] Mass-rebuild to import packages to CentOS Stream 10 starts today

2023-12-07 Thread Stephen Gallagher

First, let me apologize for the short notice on this. We've been
discussing it at the public ELN meetings over the last month, but I
only just now realized that I forgot to send out one of these general
announcements.

Over the last few months, you've probably seen a number of Fedora ELN
packages preliminarily imported into Gitlab for CentOS Stream 10 as we
get the machinery working. As of today, we've finally cleared the
remaining blockers to perform the full import of both runtime and
buildroot-only packages.

We are going to trigger a mass-rebuild of those packages included in
Fedora ELN later today in a side-tag, which will likely continue
through the weekend. All of the packages that successfully rebuild
will be automatically imported into CentOS Stream 10 via automation
and we will look into any and all failures over the course of next
week. This mass-rebuild will be performed with "background" priority
in Koji to minimize the impact on other builds, but there is still a
high likelihood that you may have a longer-than-usual waiting time for
your package builds. Fortunately, Fedora ELN is a relatively small
subset of Fedora packages (~2,500 vs Fedora's ~37,000), so it
shouldn't be too bad.

This mass-rebuild will automatically retry failed builds at least once
(to help rule out test-flakes/infra hiccoughs) and possibly numerous
times, since they are all being submitted to the automation as a
single, large batch. Please do not panic if you see your package being
submitted and failing repeatedly. For more information on the rebuild
strategy we use, please see
https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/
--
___
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: Obsoleting zlib in Fedora Rawhide

2023-12-05 Thread Stephen Gallagher

On Tue, Dec 5, 2023 at 1:28 PM Yaakov Selkowitz  wrote:
>
> On Mon, 2023-12-04 at 16:10 -0300, Tulio Magno Quites Machado Filho
> wrote:
> > Following the recent approval from Fesco, I'm planning to distribute
> > zlib-ng-compat packages for Rawhide later this week.
> > I hope this will give us enough time to work on the issues before
> > Fedora 40 is released. 爛
> >
> > So, keep in mind this will *obsolete zlib in Rawhide*.
> >
> > This update is also known to trigger test failures in the following
> > packages:
> >
> >  - binutils
> >  - cpp-httplib
> >  - git
> >  - jose
> >  - libpng
> >  - openexr1
> >  - openms
> >  - python-3.12
> >  - qpdf
> >
> > In general, the failing tests expect that libz will always have the
> > same
> > behavior, e.g.
> >  - same output length
> >  - identical output
> >  - same version string format
> >
> > This will require changes in order to guarantee the tests do succeed.
> >
> > If you have any questions or need help with these issues, let me
> > know.
>
> I would expect these build/test issues to be fixed *BEFORE* the
> obsoletion takes place, through COPR test builds and PRs etc.  Please
> tell me that FESCo didn't give permissions to break such key packages?
>
> Also, since this is essentially an SONAME change wrt zlib, the initial
> build and mini-mass-rebuild of all dependents should occur in a side-
> tag.  You're announcement doesn't mention this occurring.
>

*Puts on FESCo Hat*
Yaakov is exactly right here; this all MUST be worked out in a side
tag before it lands in Rawhide.
--
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-12-01 Thread Stephen Gallagher

On Thu, Nov 30, 2023 at 9:30 AM Stephen Gallagher  wrote:
>
> On Thu, Nov 30, 2023 at 7:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2023-12-01 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
> >
>
> * Preparing for the fork to CentOS Stream 10 and the launch of Fedora ELN 11
> ** Upcoming mini-mass-rebuild for CentOS Stream 10 mass-import

=
#fedora-meeting: ELN (2023-12-01)
=

Meeting started by sgallagh at 17:01:57 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-12-01/eln.2023-12-01-17.01.log.html
.

Meeting summary
---
* Init Process  (sgallagh, 17:02:03)

* Agenda  (sgallagh, 17:06:41)
  * Agenda Item: CentOS Stream 10 import and ELN mass-rebuild
(sgallagh, 17:06:58)
  * Agenda Item: Strategy for importing packages whose git history fails
git-fsck  (sgallagh, 17:07:18)

* CentOS Stream 10 import and ELN mass-rebuild  (sgallagh, 17:10:22)
  * CentOS Stream 10 will break inheritance from Fedora ELN on
2024-02-06, co-incident with the Fedora 40 Branch from Rawhide.
(sgallagh, 17:12:27)
  * There will be a separate announcement made to identify when public
contributions to CentOS Stream 10 will begin.  (sgallagh, 17:14:28)
  * LINK: https://github.com/rpm-software-management/mock/pull/1253
(sgallagh, 17:26:07)

* Strategy for importing packages whose git history fails git-fsck
  (sgallagh, 17:29:18)
  * LINK: https://gitlab.com/gitlab-org/gitlab/-/issues/246750
(sgallagh, 17:33:11)
  * AGREED: We will ask Fedora Infra/Releng if we can rewrite the
history of these sixteen packages and archive the old branch.
(sgallagh, 18:00:24)
  * AGREED: Failing that, we will rewrite the history manually for
import to CS 10 and maintain it by hand until the handoff.
(sgallagh, 18:00:29)

* Open Floor  (sgallagh, 18:02:06)
  * We need to revisit the way that Content Resolver workloads are
broken up. Currently they are more aligned to "who owns it" than
"where the package belongs".  (sgallagh, 18:11:15)

Meeting ended at 18:23:26 UTC.

Action Items

Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* sgallagh (119)
* Son_Goku (101)
* neil (25)
* zodbot (14)
* tdawson (13)
* smooge (10)
* yselkowitz (6)
* decathorpe (1)
* nils (1)

Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
--
___
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 Thursday's FESCo Meeting (2023-11-30)

2023-11-30 Thread Stephen Gallagher

This meeting had to be canceled due to lack of quorum.

On Thu, Nov 30, 2023 at 9:41 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Following is the list of topics that will be discussed in the
> FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
> irc.libera.chat.
>
> To convert UTC to your local time, take a look at
>   http://fedoraproject.org/wiki/UTCHowto
>
> or run:
>   date -d '2023-11-30 17:00 UTC'
>
> Links to all issues to be discussed can be found at:
> https://pagure.io/fesco/report/meeting_agenda
>
> = Discussed and Voted in the Ticket =
>
> #3111 Change: Python3.13
> https://pagure.io/fesco/issue/3111
> APPROVED (+6, 0, 0)
>
> #3109 Change: Transitioning to Zlib-ng as compatible replacement for Zlib
> https://pagure.io/fesco/issue/3109
> APPROVED (+5, 0, 0)
>
> #3108 Change: Transitioning to Minizip-ng as compatible replacement for 
> Minizip
> https://pagure.io/fesco/issue/3108
> APPROVED (+4, 0, 0)
>
> #3107 Change: Removing SSSD 'files provider'
> https://pagure.io/fesco/issue/3107
> APPROVED (+5, 0, 0)
>
> #3106 Updates policy exception request for llhttp in F39 and F38
> https://pagure.io/fesco/issue/3106
> APPROVED (+4, 0, 0)
>
> #3102 Change: Ruby 3.3
> https://pagure.io/fesco/issue/3102
> APPROVED (+8,0,-0)
>
> #3100 Change: PostgreSQL 16
> https://pagure.io/fesco/issue/3100
> APPROVED (+7, 0, 0)
>
> #3099 Change: Modernize TBB
> https://pagure.io/fesco/issue/3099
> APPROVED(+9,0,-0)
>
> #3096 Change: Build Fedora with DNF 5
> https://pagure.io/fesco/issue/3096
> APPROVED: (+6, 0, 0)
>
> #3085 Nonresponsive maintainer: Karsten Hopp @karsten
> https://pagure.io/fesco/issue/3085
> APPROVED (+2, 0, -0)
>
>
> = Followups =
>
> #3097 Change: DNF Conditional File Lists
> https://pagure.io/fesco/issue/3097
>
> #3098 Change: Drop sshd Socket
> https://pagure.io/fesco/issue/3098
>
>
> = New business =
>
> #3101 Change: Remove OpenSSL Compat
> https://pagure.io/fesco/issue/3101
>
> #3103 Change: Tuned Replaces Power-profiles-daemon
> https://pagure.io/fesco/issue/3103
>
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue.  The report of the agenda items can be found at
> https://pagure.io/fesco/report/meeting_agenda
>
> If you would like to add something to this agenda, you can
> reply to this e-mail, file a new issue at
> https://pagure.io/fesco, e-mail me directly, or bring it
> up at the end of the meeting, during the open floor topic. Note
> that added topics may be deferred until the following meeting.
> --
> ___
> 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: [Fedocal] Reminder meeting : ELN SIG

2023-11-30 Thread Stephen Gallagher

On Thu, Nov 30, 2023 at 7:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-12-01 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>

* Preparing for the fork to CentOS Stream 10 and the launch of Fedora ELN 11
** Upcoming mini-mass-rebuild for CentOS Stream 10 mass-import
--
___
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

CANCELED [Fedocal] Reminder meeting : ELN SIG

2023-11-17 Thread Stephen Gallagher

On Thu, Nov 16, 2023 at 7:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-11-17 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>
This meeting is canceled due to lack of agenda.
--
___
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 Thursday's FESCo Meeting (2023-11-16)

2023-11-16 Thread Stephen Gallagher

On Thu, Nov 16, 2023 at 7:43 AM Major Hayden  wrote:
>
> On Thu, Nov 16, 2023, at 05:59, Zbigniew Jędrzejewski-Szmek wrote:
> > Following is the list of topics that will be discussed in the
> > FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
> > irc.libera.chat.
>
> I won't be able to attend today's meeting as I have two other meetings in the 
> same slot. 
>
> As soon as I figure out how to put myself in the copier... 樂
>

Didn't you do exactly that at last year's holiday party? 浪
___
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: Becoming a member of the Fedora Packager GIT Commit Group (packager)

2023-11-08 Thread Stephen Gallagher

On Wed, Nov 8, 2023 at 6:35 AM James Chapman  wrote:
>
> Hi All,
>
> I need to become a member of the packager group in order to help with some 
> Fedora, 389 Directory Server builds.
>
> Can any sponsor of the "packager" group do me the honour of making me a 
> member of this group.
>

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-11-03 Thread Stephen Gallagher

On Fri, Nov 3, 2023 at 10:34 AM Stephen Gallagher  wrote:
>
> On Thu, Nov 2, 2023 at 8:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2023-11-03 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
>
> * Sysprof, frame-pointers and divergence between Fedora Linux and Fedora ELN
> * Content Resolver Workloads: what do they mean?

=
#fedora-meeting: ELN (2023-11-03)
=

Meeting started by sgallagh at 16:00:07 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-11-03/eln.2023-11-03-16.00.log.html
.

Meeting summary
---
* init process  (sgallagh, 16:00:07)

* Agenda  (sgallagh, 16:05:19)
  * Agenda Item: Sysprof, frame-pointers and divergence between Fedora
Linux and Fedora ELN  (sgallagh, 16:05:44)
  * Agenda Item: Content Resolver Workloads: what do they mean?
(sgallagh, 16:05:57)

* Sysprof, frame-pointers and divergence between Fedora Linux and Fedora
  ELN  (sgallagh, 16:09:59)
  * LINK:
https://github.com/minimization/content-resolver-input/pull/1007
(sgallagh, 16:10:36)
  * LINK:
https://fedorapeople.org/groups/schedule/f-40/f-40-all-tasks.html
(Son_Goku, 16:26:22)
  * AGREED: Fedora ELN will enable frame pointers in February, following
the branching from Fedora for RHEL 10. We will re-evaluate the
inclusion of frame pointers at the start of the Fedora release from
which RHEL 11 will branch (giving us six months to test without
them, if that is the decision).  (sgallagh, 16:36:18)

* Content Resolver Workloads: what do they mean?  (sgallagh, 16:36:49)

* Open Floor  (sgallagh, 16:55:04)

Meeting ended at 16:57:26 UTC.

Action Items

Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* Son_Goku (67)
* sgallagh (61)
* tdawson (12)
* dcavalca (10)
* zodbot (9)
* yselkowitz (6)
* neil (1)

Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-11-03 Thread Stephen Gallagher

On Thu, Nov 2, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-11-03 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:

* Sysprof, frame-pointers and divergence between Fedora Linux and Fedora ELN
* Content Resolver Workloads: what do they mean?
___
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: Help running centpkg

2023-10-25 Thread Stephen Gallagher

On Wed, Oct 25, 2023 at 4:48 PM Michael Dawson  wrote:
>
> Thanks to the help and suggestions so far. I've gotten farther based on the 
> suggestion to use toolbox. Using the following I can get further
>
> toolbox create -i quay.io/rhel-devel-tools/rhel-developer-toolbox:latest
> toolbox enter rhel-developer-toolbox-latest
> git clone https://gitlab.com/redhat/centos-stream/rpms/nodejs
> cd ndoejs
> centpkg mockbuild --with=bundled
>
> I'm not as far are getting the rpms built but it has helped me get over the 
> initial issue I was asking for help with.

At that point, you're firmly into nodejs-specific packaging issues. In
particular, could you talk to why you're using `--with=bundled`?
That's a vestigial option that I should probably have excised years
ago. I haven't maintained it and it almost certainly doesn't work
these days due to bit-rot. If you could walk me through the issues
you're having with it, I can try to help.
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-10-20 Thread Stephen Gallagher

On Fri, Oct 20, 2023 at 8:46 AM Stephen Gallagher  wrote:
>
> On Thu, Oct 19, 2023 at 8:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2023-10-20 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
> >
>
> No agenda set for today, but I'll hold an Open Floor meeting if anyone
> has any topics.

This week's meeting involved a long discussion of how to resolve LLVM
major update and OCAML rebuild issues.

=
#fedora-meeting: ELN (2023-10-20)
=

Meeting started by sgallagh at 16:07:11 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-10-20/eln.2023-10-20-16.07.log.html
.

Meeting summary
---
* Init Process  (sgallagh, 16:07:24)

* Agenda Topics  (sgallagh, 16:09:56)

* ELNBuildSync  (sgallagh, 16:12:05)
  * LINK:

https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/
(sgallagh, 16:12:27)

Meeting ended at 17:16:11 UTC.

Action Items

Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* sgallagh (84)
* yselkowitz (70)
* tdawson (15)
* jforbes (9)
* zodbot_ (8)
* zodbot (8)

Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-10-20 Thread Stephen Gallagher

On Thu, Oct 19, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-10-20 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>

No agenda set for today, but I'll hold an Open Floor meeting if anyone
has any topics.
___
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: ELN build order (was: Re: OCaml 5.1 rebuild)

2023-10-18 Thread Stephen Gallagher

On Fri, Oct 6, 2023 at 11:16 AM Stephen Gallagher  wrote:
...
> So, as we all know, build ordering is hard (and, despite intuitive
> belief, not actually deterministic).
>
> ELN actually "cheats" somewhat when we do our builds. When we process
> a batch of builds (triggered by a set of tag events that come in all
> at the same time, such as when a side-tag is merged), we create a new
> ELN side-tag, tag all of the new *Rawhide* builds into this side tag,
> then trigger a rebuild of all of those builds for ELN. The result here
> is that we use the Fedora build in the buildroot to avoid
> bootstrapping issues. Now, there are some special-case packages for
> which we do *NOT* automatically tag in the Fedora builds because they
> have known incompatibilities. All OCAML packages fall into this
> category, since we discovered about 9 months ago that we absolutely
> cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact
> reason).
>
> Our other "cheat" when we rebuild a batch is that we automatically do
> rebuilds at least once for any failure, to account for things like
> build ordering and test flakes. In the case you're describing,
> unforunately, we had a situation where 1) it was OCAML, and therefore
> the Fedora packages weren't in the buildroot and 2) ocaml built
> successfully against the older version of the macros. If the
> BuildRequires: had been in play there, it would have failed, the batch
> would have finished building whatever else was able to succeed (such
> as the macros) and then the second pass would have succeeded.
>
> I'm sorry you got hit by this, Richard. It's an unfortunate confluence
> of limitations in our rebuild approach.

I thought I'd responded here the other day with the link, but I forgot:
https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/

I've put together a blog post describing our ELN rebuild strategy,
which I'll copy below (but clarifications or additional content may be
added later, so consider that link the most up-to-date version).

---

# Fedora ELN Rebuild Strategy: The Rebuild Algorithm (2023 Edition)

## Slow and Steady Wins the Race

The Fedora ELN SIG maintains a tool called ELNBuildSync[1] (or EBS)
which is responsible for monitoring traffic on the Fedora Messaging
Bus and listening for Koji tagging events. When a package is tagged
into Rawhide (meaning it has passed Fedora QA Gating and is headed to
the official repositories), EBS checks whether it’s on the list of
packages targeted for Fedora ELN or ELN Extras and enqueues it for the
next batch of builds.

A batch begins when there are one or more enqueued builds and at least
five wallclock seconds have passed since a build has been enqueued.
This allows EBS to capture events such as a complete side-tag being
merged into Rawhide at once; it will always rebuild those together in
a batch. Once a batch begins, all other messages are enqueued for the
following batch. When the current batch is complete, a new batch will
begin.

The first thing that is done when processing a batch is to create a
new side-tag derived from the ELN buildroot. Into this new target, EBS
will tag most of the Rawhide builds. It will then wait until Koji has
regenerated the buildroot for the batch tag before triggering the
rebuild of the batched packages. This strategy avoids most of the
ordering issues (particularly bootstrap loops) inherent in rebuilding
a side-tag, because we can rely on the Rawhide builds having already
succeeded.

Once the rebuild is ready to begin, EBS interrogates Koji for the
original git commit used to build each Rawhide package (in case git
has seen subsequent, unbuilt changes). The builds are then triggered
in the side tag concurrently. EBS monitors these builds for
completion. If one or more builds in a batch fails, EBS will re-queue
it for another rebuild attempt. This repeats until the same set of
failures occurs twice in a row. Once all of the rebuild attempts have
concluded, EBS tags all successful builds back to ELN and removes the
side tag. Then it moves on to preparing another batch, if there are
packages waiting.

## History

In its first incarnation, ELNBuildSync (at the time known as
DistroBuildSync) was very simplistic. It listened for tag events on
Rawhide, checked them against its list and then triggered a build in
the ELN target. Very quickly, the ELN SIG realized that this had
significant limitations, particularly in the case of packages building
in side-tags (which was becoming more common as the era of on-demand
side-tags began). One of the main benefits of side-tags is the ability
to rebuild packages that depend on one another in the proper order;
this was lost in the BuildSync process and many times builds were
happening out of order, resulting in packages with the same NVR as
Rawhide but incorrectly built against older versions of their
dep

Re: [Test-Announce] Fedora Linux 39 Final is NO-GO

2023-10-11 Thread Stephen Gallagher

On Wed, Oct 11, 2023 at 6:14 AM Kamil Paral  wrote:
>
> On Wed, Oct 11, 2023 at 11:06 AM Michael J Gruber  
> wrote:
>>
>> I noticed that we switched off updates-testing by default for F39
>> installs very recently. Is that something that is tied to the release
>> date or the final freeze date?
>
>
> There's no exact time defined, but usually this happens shortly before we 
> start producing Final RC images. Pre-release testers are expected to be able 
> to configure it. But it's true that giving it more visibility (announce when 
> we disable updates-testing) would be beneficial for testing purposes 
> (interested people could toggle it back to enabled right away).

If the users have not modified the
/etc/yum.repos.d/fedora-updates-testing.repo manually, then the file
is automatically disabled for them when the GA fedora-repos package
gets to their system. It doesn't downgrade any packages they have
installed from u-t, though. So early adopters *may* want to `dnf
distro-sync` at this point, but in most cases that isn't necessary. It
probably wouldn't hurt to add "At some point during this Freeze, an
update to `fedora-release` and `fedora-repos` will be pushed out,
disabling updates-testing by default and identifying the system as a
GA release" to the Final Freeze announcement.
___
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: ELN build order (was: Re: OCaml 5.1 rebuild)

On Fri, Oct 6, 2023 at 3:45 PM Richard W.M. Jones  wrote:

> On Fri, Oct 06, 2023 at 11:16:17AM -0400, Stephen Gallagher wrote:
> > So, as we all know, build ordering is hard (and, despite intuitive
> > belief, not actually deterministic).
> >
> > ELN actually "cheats" somewhat when we do our builds. When we process
> > a batch of builds (triggered by a set of tag events that come in all
> > at the same time, such as when a side-tag is merged), we create a new
> > ELN side-tag, tag all of the new *Rawhide* builds into this side tag,
> > then trigger a rebuild of all of those builds for ELN. The result here
> > is that we use the Fedora build in the buildroot to avoid
> > bootstrapping issues. Now, there are some special-case packages for
> > which we do *NOT* automatically tag in the Fedora builds because they
> > have known incompatibilities. All OCAML packages fall into this
> > category, since we discovered about 9 months ago that we absolutely
> > cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact
> > reason).
>
> It's probably because the build flags are different and
> (unnecessarily) OCaml encodes the build flags into the hashes of one
> of the base modules.  I forget the exact details but there's an email
> on this list about it somewhere.  Anyway the upshot is that if the
> build flags change at all, as they obviously do in Fedora vs RHEL,
> then the hashes change.  We ought to fix this upstream ...
>
> Anyway I was going to say why not order the packages by their original
> build date in Koji?



For one, this doesn’t actually mean that it’ll happen in order, since if we
are merging a side tag with a low-level package getting bootstrapped, it’s
possible that the packages getting tagged back to Rawhide are not in the
correct order.

For another, the only way then to ensure that they all build in the same
order is to serialize them. That adds so much latency to the build process
that after a few weeks, rebuilds would lag by days or more.

So, we cheat. We take a couple shortcuts that results in about 99% of our
builds working properly and then we deal with the remainder. Usually this
is in the form of build failures which are easy to spot. Sometimes we have
issues like this one where the build succeeds but the built package is
wrong, which we really only find out about when someone tells us.

>
___
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: Specify koji build machine mem req via. spec file

On Thu, Oct 5, 2023 at 2:04 AM Adam Williamson
 wrote:
>
> On Wed, 2023-10-04 at 12:19 +0200, Kalev Lember wrote:
> > On Wed, Oct 4, 2023 at 11:44 AM Martin Stransky  wrote:
> >
> > > Hello guys,
> > >
> > > Is there's a way how to set requested amount of ram for koji builders?
> > >
> > > I'd like to use it as Firefox builds fail recently due low memory, like
> > > https://bugzilla.redhat.com/show_bug.cgi?id=2241690
> >
> >
> > I looked at the first linked build log in the ticket and it looks like the
> > build failed in the debuginfo extraction step. In that log, find-debuginfo
> > is called with -j3, and it could be that it ran out of memory because it
> > was trying to do 3 debuginfo extractions in parallel. You could try to
> > stick something like this in the spec file to tune it down:
> >
> > # Require 32 GB of RAM per CPU core for debuginfo processing
> > %global _find_debuginfo_opts %limit_build -m 32768
>
> Thanks for the idea, Kalev. I went ahead and applied this, and builds
> for F38 and F39 succeeded. Let's hope it really helps and this wasn't
> just luck!

Looks like probably not, since the follow-up ELN build *also*
succeeded for the first time in quite a while!
___
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: [Fedocal] Reminder meeting : ELN SIG

On Thu, Oct 5, 2023 at 1:52 PM Stephen Gallagher  wrote:
>
>
>
> On Thu, Oct 5, 2023 at 8:00 AM  wrote:
>>
>> Dear all,
>>
>> You are kindly invited to the meeting:
>>ELN SIG on 2023-10-06 from 12:00:00 to 13:00:00 US/Eastern
>>At fedora-meet...@irc.libera.chat
>>
>> The meeting will be about:
>
>
>
> * Should ELN stop carrying enabled Rawhide repos?
> https://src.fedoraproject.org/rpms/fedora-release/pull-request/284

=
#fedora-meeting: ELN (2023-10-06)
=

Meeting started by sgallagh at 16:00:17 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-10-06/eln.2023-10-06-16.00.log.html
.

Meeting summary
---
* init process  (sgallagh, 16:00:18)

* Agenda  (sgallagh, 16:02:21)
  * Agenda Item: Should ELN continue to be backed by Rawhide repos?
(sgallagh, 16:02:43)
  * Agenda Item: ELN and ODCS: Are they headed for a divorce?
(sgallagh, 16:05:52)
  * Agenda Item: ELN Docs need an overhaul  (sgallagh, 16:06:23)

* Should ELN continue to be backed by Rawhide repos?  (sgallagh,
  16:09:04)
  * LINK:
https://src.fedoraproject.org/rpms/fedora-release/pull-request/284
(tdawson, 16:09:51)
  * AGREED: We will remove the requirement for Rawhide repos to be
installed alongside ELN repos. They remain available to install
manually. (+3, 3, -1)  (sgallagh, 16:48:31)

* ODCS and ELN  (sgallagh, 16:48:49)

* ELN Docs  (sgallagh, 16:58:49)

Meeting ended at 17:00:31 UTC.

Action Items

Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* sgallagh (72)
* Son_Goku (50)
* michel-slm (41)
* tdawson (26)
* dcavalca (20)
* nirik (16)
* zodbot (11)
* neil (5)

Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: ELN build order (was: Re: OCaml 5.1 rebuild)

On Fri, Oct 6, 2023 at 7:38 AM Richard W.M. Jones  wrote:
>
>
> On Fri, Oct 06, 2023 at 12:23:09PM +0100, Richard W.M. Jones wrote:
> > On Fri, Oct 06, 2023 at 10:19:22AM +0100, Richard W.M. Jones wrote:
> > > On Fri, Oct 06, 2023 at 08:48:52AM +0100, Richard W.M. Jones wrote:
> > > > On Thu, Oct 05, 2023 at 10:03:59AM +0100, Richard W.M. Jones wrote:
> > > > > Over the next few days I'm going to rebuild all OCaml packages in
> > > > > Rawhide for OCaml 5.1, plus some non-OCaml packages that have OCaml
> > > > > bindings.
> > > > >
> > > > > OCaml 5.1 is basically a small point release, but it does add back
> > > > > native code support for riscv64 and s390x.  The only remaining
> > > > > architecture that hasn't been updated for OCaml 5 (and is therefore
> > > > > still using the bytecode interpreter) is ppc64le.
> > > >
> > > > I think the builds are complete, except one which is running now.
> > > >
> > > > Only swig failed to build but that appears to be a general FTBFS bug:
> > > >   https://bugzilla.redhat.com/show_bug.cgi?id=2242372
> > > >
> > > > I'll submit an update later today once I've done a few more checks.
> > >
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-f0270d1637
> >
> > ELN builds are failing because they need to be done in build order,
> > not in random or alphabetical order or whatever ELN uses, so that's a
> > thing ...
>
> Actually it's worse.  Because this build of ocaml:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=107128822
>
> was built before ocaml-srpm-macros was updated, it is being built
> wrongly.  The s390x build.log contains "--disable-native-compiler" but
> it should be the opposite since native compilation is now supported.
>
> Now partly this is a mistake in the spec file which should BR
> ocaml-srpm-macros >= 9 (I'll fix that shortly), but partly this is
> caused by the wrong build ordering of ELN.
>

So, as we all know, build ordering is hard (and, despite intuitive
belief, not actually deterministic).

ELN actually "cheats" somewhat when we do our builds. When we process
a batch of builds (triggered by a set of tag events that come in all
at the same time, such as when a side-tag is merged), we create a new
ELN side-tag, tag all of the new *Rawhide* builds into this side tag,
then trigger a rebuild of all of those builds for ELN. The result here
is that we use the Fedora build in the buildroot to avoid
bootstrapping issues. Now, there are some special-case packages for
which we do *NOT* automatically tag in the Fedora builds because they
have known incompatibilities. All OCAML packages fall into this
category, since we discovered about 9 months ago that we absolutely
cannot mix Fedora's OCAML builds with ELN's (I don't recall the exact
reason).

Our other "cheat" when we rebuild a batch is that we automatically do
rebuilds at least once for any failure, to account for things like
build ordering and test flakes. In the case you're describing,
unforunately, we had a situation where 1) it was OCAML, and therefore
the Fedora packages weren't in the buildroot and 2) ocaml built
successfully against the older version of the macros. If the
BuildRequires: had been in play there, it would have failed, the batch
would have finished building whatever else was able to succeed (such
as the macros) and then the second pass would have succeeded.

I'm sorry you got hit by this, Richard. It's an unfortunate confluence
of limitations in our rebuild approach.
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-10-05 Thread Stephen Gallagher

On Thu, Oct 5, 2023 at 8:00 AM  wrote:

> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-10-06 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:



* Should ELN stop carrying enabled Rawhide repos?
https://src.fedoraproject.org/rpms/fedora-release/pull-request/284

>
___
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: Orphaning all my packages

2023-10-03 Thread Stephen Gallagher

On Tue, Oct 3, 2023 at 2:14 PM Michael Catanzaro  wrote:
>
> On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce 
> wrote:
> > Additionally *all* of the code is fully available in git form on
> > gitlab
> > as part of CentOS Stream.
>
> We all know or should know that this is false. It's easy enough to
> disprove with a counterexample:
>
> https://access.redhat.com/errata/RHSA-2023:1918
>
> Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
> CentOS Stream. It isn't there, and never will be.
>

The *exact* set of source code that the package was built for is
included in the Source RPM and all of the individual changes that
comprised it are part of the c9s branch in CentOS Stream (or the
maintainer has been regressing code, in which case that should be
addressed). No, the git repo might not contain a specific git
reference that directly matches the SRPM you cite, but that's not at
all the same thing as "the code isn't available in git".
___
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 Thursday's FESCo Meeting (2023-09-28)

2023-09-28 Thread Stephen Gallagher

=
#fedora-meeting-2: FESCO (2023-09-28)
=


Meeting started by sgallagh at 17:00:22 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2023-09-28/fesco.2023-09-28-17.00.log.html
.



Meeting summary
---
* init process  (sgallagh, 17:00:24)

* #3059 F39 incomplete changes: 100% complete deadline  (sgallagh,
  17:07:32)
  * https://src.fedoraproject.org/rpms/fedora-release/pull-request/279
has been merged.  (zbyszek, 17:08:49)
  * LINK:

https://src.fedoraproject.org/rpms/fedora-release/pull-request/279#comment-159648
(zbyszek, 17:09:27)
  * ACTION: sgallagh to backport the fwupd patch to F39 in
fedora-release  (sgallagh, 17:18:02)

* #3065 New workstation WebUI is enforcing a requirement for a separate
  /boot  (sgallagh, 17:20:40)
  * AGREED: If a separate /boot partition is to become a hard
requirement in the Anaconda UI, we would like this to go through the
Change Process for Fedora 40 (+6, 0, -0)  (sgallagh, 17:51:29)

* #3067 Change: Restructure Kubernetes Packages  (sgallagh, 17:51:44)
  * AGREED: This Change is approved. (+5, 0, -0)  (sgallagh, 17:57:18)

* Open Floor  (sgallagh, 17:57:23)

* Next Week's Chair  (sgallagh, 18:00:38)
  * ACTION: mhayden to chair the 2023-10-05 meeting  (sgallagh,
18:02:28)

Meeting ended at 18:03:56 UTC.




Action Items

* sgallagh to backport the fwupd patch to F39 in fedora-release
* mhayden to chair the 2023-10-05 meeting




Action Items, by person
---
* mhayden
  * mhayden to chair the 2023-10-05 meeting
* sgallagh
  * sgallagh to backport the fwupd patch to F39 in fedora-release
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (77)
* nirik (42)
* zbyszek (29)
* zodbot (19)
* Son_Goku (19)
* mhayden (16)
* decathorpe (15)
* michel-slm (14)
* tstellar (2)
* mhroncok (0)
* dcantrell (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)
* Eighth_Doctor (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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

Schedule for Thursday's FESCo Meeting (2023-09-28)

2023-09-27 Thread Stephen Gallagher

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Following is the list of topics that will be discussed in the
FESCo meeting Thursday at 17:00UTC in #fedora-meeting-2 on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2023-09-28 17:00 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

No pending announcements this week, several Changes are close to
approval but won't cross the threshold until tomorrow, so they will be
part of next week's announcement.

= Followups =

#3059 F39 incomplete changes: 100% complete deadline
https://pagure.io/fesco/issue/3059

= New business =

#3065 New workstation WebUI is enforcing a requirement for a separate /boot
https://pagure.io/fesco/issue/3065

#3067 Change: Restructure Kubernetes Packages
https://pagure.io/fesco/issue/3067

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAmUUwvAACgkQRduFpWgo
bREnNAwAwL1y54HDQsOmji6JAOK1O5V5xNrCerJ8OcDDNZ/l5ozhbHnRn3qOqmHO
XRR6Arxu55Xpo9afaP2sPbIwxSb7XoK+SztEZpecn8kw6CyNIbNLl5RoiE8FCe5b
WDiA4WLODLPwE/BMvQU4zIPNDZkOCFpTA4SE6it1oMM2k33CYMoPcb+sQBryYoQQ
cYnxBJODiuI3pQGSvLIc59CXvDgjzV9Z6MwrngBFCWOAXCM0q7HLAT0gvR0jZObG
ICl4hUyyIigvrsNkUAmC8sNZZKoIa/+4xrRPAp1HhLI3wlr1vC6n+R3j2Bh/TUvg
8MRSBiCnV11C7BPaASuCznK/SwouVqnDbAciIHjrY3MuV104/yYUtwicITgBlb0Q
hc0aCastbYsvjUjnkGeNGfPV1o1i/BdY4XrpSX2gWgPaFRGjQobplAUf5r0xBsPh
mru3KNCPQa+aAPgbFxdripiR/hQzt1TBSBpBNAW6jutkPLwC8fvCZywCCO6wyE0L
y1yunFEe
=QJX1
-END PGP SIGNATURE-
___
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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

2023-09-27 Thread Stephen Gallagher

On Wed, Sep 27, 2023 at 12:59 PM Ron Olson  wrote:
>
> I mean this sincerely: Where is the excellent documentation? I admit that 
> I’ve been frustrated that web searches leads me all over the place, sometimes 
> the documentation is obsolete, or it’s someone’s blog post, etc. I’ve been 
> surprised again and again there’s a macro for this or that which could have 
> made the job much easier, but I had no idea until I asked here or in IRC.
>

The documentation he's referring to is the
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md

Indeed, we probably should figure out a way to make that link more
prominent on the Packaging Guidelines pages, though.
___
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: Intention to tighten RPM crypto-policy back

2023-09-27 Thread Stephen Gallagher

On Wed, Sep 27, 2023 at 7:06 AM Alexander Sosedkin  wrote:
...
> Feel free to strike down these proposals
> using whatever mechanisms Fedora governance offers.
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3
> rejection suggests they do work.

To be clear, that one was rejected primarily because of Chrome and
VSCode (both extremely important to our user-base), which appear to
have been resolved since then. I'm definitely in favor of tightening
things up at this point.
___
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

[ELN] Policy Updates from ELN SIG Weekly Meeting Minutes (2023-09-22)

2023-09-22 Thread Stephen Gallagher

=
#fedora-meeting: ELN (2023-09-08)
=


Meeting started by sgallagh at 16:00:58 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-09-22/eln.2023-09-22-16.00.log.html
.



Meeting summary
---
* Init Process  (sgallagh, 16:00:59)

* ELN Packaging Policies  (sgallagh, 16:06:23)
  * Proposal 1: Fedora ELN will follow all published Fedora Packaging
Guidelines, except where explicitly documented otherwise.
(sgallagh, 16:16:47)
  * Proposal 2: Exceptions will be decided on by a majority vote of ELN
SIG members at a regularly-scheduled ELN SIG meeting comprised of a
quorum of at least five members.  (sgallagh, 16:40:13)
  * Proposal 3: Members who have not attended a regularly-scheduled ELN
SIG meeting in six months or more will be removed as active members.
They may re-request membership following the normal process.
(sgallagh, 16:44:05)
  * AGREED: Proposal 3: Members who have not attended a
regularly-scheduled ELN SIG meeting in six months or more will be
removed as active members. They may re-request membership following
the normal process. (+4, 1, -0)  (sgallagh, 16:53:24)
  * AGREED: Proposal 2: Exceptions will be decided on by a majority vote
of ELN SIG members at a regularly-scheduled ELN SIG meeting
comprised of a quorum of at least five members. (+4, 0, -1)
(sgallagh, 16:57:30)
  * AGREED: Proposal 1: Fedora ELN will follow all published Fedora
Packaging Guidelines, except where explicitly documented otherwise.
(+4, 0, 0)  (sgallagh, 17:00:51)
  * Proposal 4: Packaging Guidelines Exception: ELN may opt to bundle
content more freely than in Rawhide. If we do so, we must follow the
Fedora bundling policy.  (sgallagh, 17:09:00)
  * Proposal 5: Packaging Guidelines Exception: ELN may opt to exclude
(or bundle deps of) certain tests if running them would cause
unwanted dependencies to end up in the RHEL content set.  (sgallagh,
17:09:01)
  * Proposal 5v2: Packaging Guidelines Exception: ELN may opt to exclude
(or preferably bundle deps of) certain tests if running them would
cause unwanted dependencies to end up in the RHEL content set.
(sgallagh, 17:13:42)
  * AGREED: Proposal 4: Packaging Guidelines Exception: ELN may opt to
bundle content more freely than in Rawhide. If we do so, we must
follow the Fedora bundling policy. (+4, 0, -0)  (sgallagh, 17:16:37)
  * AGREED: Proposal 5v2: Packaging Guidelines Exception: ELN may opt to
exclude (or preferably bundle deps of) certain tests if running them
would cause unwanted dependencies to end up in the RHEL content set.
(+4, 0, -0)  (sgallagh, 17:16:37)
  * Additional Exceptions may be proposed by filing a ticket at
https://github.com/fedora-eln/eln/issues and will be discussed at
the next meeting (2023-10-06)  (sgallagh, 17:20:51)

Meeting ended at 17:21:18 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (111)
* Son_Goku (74)
* dcavalca (42)
* yselkowitz (24)
* tdawson (21)
* zodbot (12)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-09-21 Thread Stephen Gallagher

On Thu, Sep 21, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-09-22 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>

FESCo has requested that the ELN SIG document some of its policies
more fully, so let's use this week's meeting to work through those.
___
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: Will noarch packages "inherit" ExcludeArch from another noarch package

2023-09-12 Thread Stephen Gallagher

On Tue, Sep 12, 2023 at 1:11 PM Lyes Saadi  wrote:
>
> Oh woops, answered to Jerry James privately instead to the whole devel
> mailing list. It's indeed about blueprint-compiler.
>
> Le 12/09/2023 à 19:03, Dan Horák a écrit :
> > On Tue, 12 Sep 2023 10:08:57 -0600
> > Jerry James  wrote:
> >
> >> On Tue, Sep 12, 2023 at 10:03 AM Lyes Saadi  
> >> wrote:
> >>> I have a noarch package which faces an issue with one of its arches
> >>> (s390x), and which happens to have multiple noarch packages depending on
> >>> it, and they won't build either if they were built on that same arch
> >>> (but, they will still work normally when installed on that arch). And
> >>> so, I plan on adding an ExcludeArch, as per
> >>> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies.
> >>>
> >>> But, I don't know if I need to also ask maintainers of every dependency
> >>> to add ExcludeArch themselves. Indeed, the guideline says :
> >>>   > You can limit both the architectures used to build a noarch package,
> >>> *and the repositories to which the built noarch package will be added*
> >>>
> >>> So, am I correct in assuming that if my noarch package uses ExcludeArch,
> >>> every other dependent package, when building, will not build on that
> >>> Arch as well ?
> >> You will indeed have to ask the maintainers of consuming packages to
> >> add that ExcludeArch too.  What package is it and what is the nature
> >> of the problem on s390x?  Maybe it can be fixed.
> > I believe it's about blueprint-compiler, which has some big endian
> > issues, please see https://bugzilla.redhat.com/show_bug.cgi?id=2169892

The classic way to do this is to request a macro like
`%{blueprint_arches}` which can be passed to any package requiring the
blueprint compiler. We have several interpreted languages that do
this, if the interpreter isn't available on all arches.


```
$ rpm --showrc|grep _arches
-13: GNAT_arches %{GPRbuild_arches} ia64 ppc alpha %{arm} riscv64
-13: GPRbuild_arches %{ix86} x86_64 %{power64} s390x aarch64
-13: fpc_arches %{ix86} %{arm} x86_64 ppc64le aarch64
-13: gap_arches aarch64 ppc64le s390x x86_64
-13: gccgo_arches mips mipsel mipsr6 mipsr6el mips64 mips64el mips64r6
mips64r6el
-13: ghc_arches %{ix86} x86_64 armv7hl ppc64le aarch64 s390x
-13: go_arches %{golang_arches} %{gccgo_arches}
-13: golang_arches i386 i486 i586 i686 pentium3 pentium4 athlon geode
x86_64 armv3l armv4b armv4l armv4tl armv5tl armv5tel armv5tejl armv6l
armv6hl armv7l armv7hl armv7hnl armv8l armv8hl armv8hnl armv8hcnl
aarch64 ppc64le s390x
-13: golang_arches_future x86_64 armv3l armv4b armv4l armv4tl armv5tl
armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl armv8l
armv8hl armv8hnl armv8hcnl aarch64 ppc64le s390x
  exclusive_arches = "%{golang_arches}"
  exclusive_arches = "%{golang_arches_future}"
print(rpm.expand("ExclusiveArch: " .. exclusive_arches .. "\n"))
-13: java_arches aarch64 ppc64le s390x x86_64
-13: kernel_arches x86_64 s390x ppc64le aarch64 %{arm}
-13: ldc_arches %{ix86} x86_64 %{arm} aarch64
-13: mono_arches %{ix86} x86_64 sparc sparcv9 ia64 %{arm} aarch64
alpha s390x ppc ppc64 ppc64le
-13: nodejs_arches %{ix86} x86_64 %{arm} aarch64 %{power64} s390x
-13: openblas_arches x86_64 %{ix86} armv7hl %{power64} aarch64 s390x
-13: qt5_qtwebengine_arches %{ix86} x86_64 %{arm} aarch64 mips mipsel mips64el
-13: rust_arches x86_64 %{ix86} armv7hl aarch64 ppc64 ppc64le riscv64 s390x
-13: valgrind_arches %{ix86} x86_64 ppc ppc64 ppc64le s390x armv7hl aarch64
```

When relying on e.g. Node.js, one is expected to do:
ExclusiveArch: %{nodejs_arches}
___
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: checksec: Problem: conflicting requests in s390x

2023-09-08 Thread Stephen Gallagher

On Fri, Sep 8, 2023 at 12:51 PM Jun Aruga (he / him)  wrote:
>
> On Fri, Sep 8, 2023 at 6:06 PM Yaakov Selkowitz  wrote:
> >
> > On Fri, 2023-09-08 at 17:53 +0200, Jun Aruga wrote:
> > > I am running the scratch build for rpms/ruby [1] rawhide branch right
> > > now, and I see the following error in the root.log on only s390x CPU
> > > architecture. Do you know what's wrong?
> > >
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=105910607
> > >
> > > s390x:
> > > https://kojipkgs.fedoraproject.org//work/tasks/753/105910753/root.log
> > [snip[
> > > DEBUG util.py:442:   Problem: conflicting requests
> > > DEBUG util.py:442:- nothing provides nm needed by
> > > checksec-2.6.0-5.fc40.noarch from build
> >
> > This is a result of
> > https://src.fedoraproject.org/rpms/checksec/c/7e260a6c3f4d6f17f02f9c40ff2308919670a50d?branch=rawhide
> >
> > AFAICS that change is wrong, as nothing provides "nm".  That should be
> > either Requires: /usr/bin/nm (literally, not %{_bindir}/nm !!) or
> > Requires: binutils.  Or maybe not at all, if one can still (hopefully?)
> > safely presume that binutils is a necessary part of the base buildroot.
>
> Thanks for your investigation! For the checksec RPM, I reported the
> issue to the following bugzilla ticket.
> https://bugzilla.redhat.com/show_bug.cgi?id=2235760#c12
>
> Why is the following one not a proper solution? I don't understand it.
>
> ```
> Requires: %{_bindir}/nm
> ```

RPM cannot evaluate the %{_bindir} in Requires:. So it's essentially
looking for a virtual provides with those literal characters, which it
won't find.
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-09-08 Thread Stephen Gallagher

=
#fedora-meeting: ELN (2023-09-08)
=


Meeting started by sgallagh at 16:00:43 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-09-08/eln.2023-09-08-16.00.log.html
.



Meeting summary
---
* Init Process  (sgallagh, 16:00:43)

* Agenda  (sgallagh, 16:05:34)
  * Agenda Item: Status Update  (sgallagh, 16:05:50)
  * Agenda Item: grub2-efi issues  (sgallagh, 16:08:21)

* grub2-efi issues  (sgallagh, 16:09:36)
  * LINK:

https://tiny.distro.builders/view-rpm--view-eln-extras--grub2-efi-x64-modules.html
(sgallagh, 16:12:06)
  * LINK: https://pagure.io/pungi-fedora/pull-request/1196#request_diff
(sgallagh, 16:16:10)
  * LINK:

https://gitlab.com/redhat/centos-stream/rpms/tboot/-/commit/26f7e15a839997e9daf0c2a85393fdfa12a7650b
(yselkowitz, 16:23:48)
  * There's a disconnect between CentOS Stream and ELN; tboot depends on
grub2-efi-x64-modules in CS9  (sgallagh, 16:26:12)
  * ACTION: yselkowitz will contact the maintainers to find out what
should happen in ELN  (sgallagh, 16:26:35)
  * The grub2-efi-x64-modules package was removed from ELN because it is
not present in the Content Resolver output.  (sgallagh, 16:27:24)

* Status Update  (sgallagh, 16:46:09)
  * First packages will be synced to CentOS Stream 10 next week.
Composes to come later.  (sgallagh, 16:50:23)
  * Direct CentOS Stream development is still not going to start; all
work should continue to happen on ELN until further notice.
(sgallagh, 16:50:55)

Meeting ended at 16:59:50 UTC.




Action Items

* yselkowitz will contact the maintainers to find out what should happen
  in ELN




Action Items, by person
---
* yselkowitz
  * yselkowitz will contact the maintainers to find out what should
happen in ELN
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* sgallagh (78)
* dcavalca (38)
* neil (24)
* yselkowitz (17)
* zodbot (11)
* sgallagh33 (7)
* tdawson (4)
* michel-slm (2)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-09-07 Thread Stephen Gallagher

On Thu, Sep 7, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-09-08 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:

Open Floor
___
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

[CANCELED] Re: [Fedocal] Reminder meeting : ELN SIG

2023-08-24 Thread Stephen Gallagher

No meeting this week.

On Thu, Aug 24, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-08-25 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
___
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

Orphaning cockpit-file-sharing (Was Re: cockpit-file-sharing-2.4.5-2.el9 update to 3.3.4 please)

2023-08-11 Thread Stephen Gallagher

This is a useful extension to the Cockpit project developed by
45Drives, a storage company. Unfortunately, when they jumped from 2.x
to 3.x, they completely redesigned their build environment and made it
much more complicated. I don't have the time right now to rework this
package (and package the numerous additional dependencies that 3.x now
has), so I'm orphaning it. I do hope someone else will pick it up.

On Sat, Jul 29, 2023 at 6:29 PM Wang Yugui  wrote:
>
> Hi,
>
> cockpit-file-sharing-2.4.5-2.el9 update to 3.3.4 please
>
> https://kojipkgs.fedoraproject.org/packages/cockpit-file-sharing/
>
> Best Regards
> Wang Yugui (wangyu...@e16-tech.com)
> 2023/07/30
>
>
___
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: [Fedocal] Reminder meeting : ELN SIG

2023-08-11 Thread Stephen Gallagher

On Thu, Aug 10, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-08-11 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>

* General status post-Fedora 39 Branching
* ELNBuildSync rewrite progress
___
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 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)

2023-07-25 Thread Stephen Gallagher

On Tue, Jul 25, 2023 at 10:39 AM Timothée Ravier
 wrote:
>
> > Would these messages show up, for example, if they opened the terminal app?
>
> They only show up on the console / ssh login prompt if I'm not mistaken: 
> https://github.com/fwupd/fwupd/tree/main/data/motd

That means they will show up anywhere that pam_motd is in the session
stack. Currently, that's only sshd logins, but that's a discussion we
could have.
___
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: Immutable Variants & Persistence

2023-07-11 Thread Stephen Gallagher

On Tue, Jul 11, 2023 at 12:01 PM Jonathan Steffan
 wrote:
>
> On Tue, Jul 11, 2023 at 6:55 AM Richard W.M. Jones  wrote:
>>
>>
>> Isn't this what Silverblue is for?
>>
>> https://fedoraproject.org/silverblue/
>
>
> Yes, close.
>
> Could it be possible that all changes are only recorded COW and after reboot 
> they are discarded?
>

Sounds like "ostree native containers" to me...
https://coreos.github.io/rpm-ostree/container/
___
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: ELN: Mass-rebuild has started

2023-06-27 Thread Stephen Gallagher

On Mon, Jun 26, 2023 at 8:51 PM Maxwell G  wrote:
>
> On Mon Jun 26, 2023 at 17:19 -0400, Stephen Gallagher wrote:
> > On Mon, Jun 26, 2023 at 5:08 PM Maxwell G  wrote:
> > >
> > > 2023-06-26T20:21:06Z Stephen Gallagher :
> > >
> > > > Just a heads-up that we've begun the targeted mass-rebuild for Fedora
> > > > ELN. It's running in Koji's "background" priority, so it should
> > > > hopefully not significantly impact other builds. My estimate is that
> > > > it will be running for about the next two days, followed up by manual
> > > > rebuilds for flaky tests/network hiccoughs, etc.
> > >
> > > Is that going to conflict with the ongoing Python 3.12 rebuild?
> >
> > It should not. I triggered the builds from the git hash of whatever
> > was current in the `eln` tag.
>
> Ah, do you just bump the eln disttag and not touch packages' Release
> fields and changelogs at all?

Yes, exactly this.
___
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: ELN: Mass-rebuild has started

2023-06-26 Thread Stephen Gallagher

On Mon, Jun 26, 2023 at 5:08 PM Maxwell G  wrote:
>
> 2023-06-26T20:21:06Z Stephen Gallagher :
>
> > Just a heads-up that we've begun the targeted mass-rebuild for Fedora
> > ELN. It's running in Koji's "background" priority, so it should
> > hopefully not significantly impact other builds. My estimate is that
> > it will be running for about the next two days, followed up by manual
> > rebuilds for flaky tests/network hiccoughs, etc.
>
> Is that going to conflict with the ongoing Python 3.12 rebuild?

It should not. I triggered the builds from the git hash of whatever
was current in the `eln` tag.
___
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

ELN: Mass-rebuild has started

2023-06-26 Thread Stephen Gallagher

Just a heads-up that we've begun the targeted mass-rebuild for Fedora
ELN. It's running in Koji's "background" priority, so it should
hopefully not significantly impact other builds. My estimate is that
it will be running for about the next two days, followed up by manual
rebuilds for flaky tests/network hiccoughs, etc.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@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

ELN: Mass-rebuild has started

2023-06-26 Thread Stephen Gallagher

Just a heads-up that we've begun the targeted mass-rebuild for Fedora
ELN. It's running in Koji's "background" priority, so it should
hopefully not significantly impact other builds. My estimate is that
it will be running for about the next two days, followed up by manual
rebuilds for flaky tests/network hiccoughs, etc.
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Fedocal] Reminder meeting : ELN SIG

2023-06-23 Thread Stephen Gallagher

On Thu, Jun 22, 2023 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2023-06-23 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
> * x86_64-v3 baseline and dropping i686 multilib
> * Plans for the next 3-6 months

=
#fedora-meeting: ELN (2023-06-23)
=

Meeting started by sgallagh at 16:00:52 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-06-23/eln.2023-06-23-16.00.log.html
.

Meeting summary
---
* init process  (sgallagh, 16:00:52)

* ELN runtime mass-rebuild  (sgallagh, 16:07:39)
  * AGREED: We will take the conservative approach to the mass-rebuild.
This means rebuilding the packages from the git hash matching the
current latest-tagged package in ELN.  (sgallagh, 16:17:14)

* Processor baselines  (sgallagh, 16:19:54)

* Open Floor  (sgallagh, 16:41:31)
  * LINK: https://pagure.io/releng/issue/11475   (yselkowitz[m],
16:41:43)

Meeting ended at 16:56:35 UTC.

Action Items

Action Items, by person
---
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* sgallagh (50)
* tdawson (18)
* zodbot (14)
* bstinson (12)
* yselkowitz[m] (9)
* decathorpe (5)

Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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?

2023-06-22 Thread Stephen Gallagher

On Wed, Jun 21, 2023 at 5:46 PM Philip Wyett  wrote:
>
> On Wed, 2023-06-21 at 17:39 -0400, Ben Cotton wrote:
> > On Wed, Jun 21, 2023 at 5:09 PM Philip Wyett  
> > wrote:
> >
> > > It has much to do. Fedora is a community apparently Red Hat no longer 
> > > needs. The now ELN
> > > backend
> > > can satisfy pre testing and could make fedora redundant.
> >
> > 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.

Literally anything CAN happen. However Fedora ELN without Fedora
Rawhide would be just CentOS Stream and therefore redundant. The fact
that Fedora ELN continues to see significant support from Red Hat
(they essentially pay several people to work on it full-time) should
make it clear that it has value.
___
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?

2023-06-22 Thread Stephen Gallagher

On Wed, Jun 21, 2023 at 4:26 PM Gerald Henriksen  wrote:
>
> On Wed, 21 Jun 2023 21:06:40 +0100, you wrote:
>
> >Hi all,
> >
> >Obviously many will have seen:
> >
> >https://www.redhat.com/en/blog/furthering-evolution-centos-stream
> >
> >and see, where EL (contributors like you of fedora/EPEL) have been knocked 
> >down:
> >
> >https://bugzilla.redhat.com/show_bug.cgi?id=2215299
> >
> >Let us face it our efforts with the Fedora project are not valued and it is 
> >a means nothing to the
> >new corporate IBM/Red Hat enterprise systems that we have to struggle to get 
> >access to srpms, to
> >make a community. What is community now to Red Hat?
>
> My interpretation of the blog post, combined with recent actions
> towards Fedora by Red Hat, is that Red Hat now views CentOS Stream as
> the new "Fedora" for basing future versions of RHEL.

Just to interject, this is an incorrect interpretation. Red Hat is
still highly committed to Fedora (as evidenced by the continued
support for Fedora ELN as the integration path from Rawhide to CentOS
Stream).
___
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: [Fedocal] Reminder meeting : ELN SIG

On Fri, Jun 16, 2023 at 9:46 AM Stephen Gallagher  wrote:
>
> On Thu, Jun 15, 2023 at 9:45 AM Stephen Gallagher  wrote:
> >
> > On Thu, Jun 15, 2023 at 8:00 AM  wrote:
> > >
> > > Dear all,
> > >
> > > You are kindly invited to the meeting:
> > >ELN SIG on 2023-06-16 from 12:00:00 to 13:00:00 US/Eastern
> > >At fedora-meet...@irc.libera.chat
> > >
> > > The meeting will be about:
> >
> > * x86_64-v3 baseline and dropping
> > i686 multilib
> > * Plans for the next 3-6 months
>
>
> I've just sent out a message[1] to devel-announce describing our plans
> in broad strokes. Anyone who has questions or wants to help is welcome
> to join us for our meeting today.
>
> == tl;dr ==
> * We'll do an ELN mass rebuild to see how many builds will fail
> * We'll import ELN packages to c10s gradually, starting with just the
> runtime set. We'll use ELN as the buildroot at the start.
> * We'll import the buildroot set to c10s when it gets small enough.
> * You’ll see activity in CentOS Stream 10, but it’s not yet time to
> get involved. A general availability announcement will follow sometime
> in the first half of 2024.
> == tl;dr ==
>
> [1] 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/IXNTPGKHWTW7H7XVMZICSJRUDOHO2KJC/

Due to failure to reach quorum again this week, I'm going to
reschedule this meeting for next Friday, June 23rd. This will NOT
impact the schedule for the June 30th meeting.
___
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: Fedora ELN Plans for Summer 2023

On Fri, Jun 16, 2023 at 11:46 AM Florian Weimer  wrote:
>
> * Stephen Gallagher:
>
> > First, as the cleanup of unnecessary dependencies in the Fedora ELN
> > has not yet completed, we are revising our plan of performing a
> > mass-import of *all* Fedora ELN content to CentOS Stream 10 in July.
> > Instead, we plan to move to a phased approach wherein we will first
> > import, build and test only the portions of CentOS Stream 10 that we
> > currently have slated for inclusion in the delivered "runtime". As a
> > necessary side-effect of this, it means that we will NOT be
> > transitioning directly to CentOS Stream 10 as a self-hosted
> > environment.
>
> A bit related to the CentOS 10 bringup, the CentOS ISA SIG is currently
> porting CentOS 9 Stream to the x86-64-v3 ISA level.  I believe there are
> some failures that are not yet fixed in ELN/upstream, and we'll be
> sharing our workarounds with rawhide/ELN as appropriate.

Much appreciated. I know Yaakov Selkowitz has stumbled across at least
one v3-specific issue that he's sent your way. We'll do whatever we
can to help.
___
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: Fedora ELN Plans for Summer 2023

On Fri, Jun 16, 2023 at 11:53 AM Miro Hrončok  wrote:
>
> On 16. 06. 23 15:39, Stephen Gallagher wrote:
> > This leads me to my next schedule announcement: we will be performing
> > the initial CentOS Stream 10 branch creation in Gitlab for all
> > packages in the Fedora ELN runtime package set[1]  during the week of
> > July 19th, coincident with the Fedora 39 mass-rebuild.
>
> Will you please, please, please, please import the packages with git history
> and not via fepdkg srpm -> centpkg import?

YES!
___
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: [Fedocal] Reminder meeting : ELN SIG

On Thu, Jun 15, 2023 at 9:45 AM Stephen Gallagher  wrote:
>
> On Thu, Jun 15, 2023 at 8:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2023-06-16 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
>
> * x86_64-v3 baseline and dropping
> i686 multilib
> * Plans for the next 3-6 months

I've just sent out a message[1] to devel-announce describing our plans
in broad strokes. Anyone who has questions or wants to help is welcome
to join us for our meeting today.

== tl;dr ==
* We'll do an ELN mass rebuild to see how many builds will fail
* We'll import ELN packages to c10s gradually, starting with just the
runtime set. We'll use ELN as the buildroot at the start.
* We'll import the buildroot set to c10s when it gets small enough.
* You’ll see activity in CentOS Stream 10, but it’s not yet time to
get involved. A general availability announcement will follow sometime
in the first half of 2024.
== tl;dr ==

[1] 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/IXNTPGKHWTW7H7XVMZICSJRUDOHO2KJC/
___
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

Fedora ELN Plans for Summer 2023

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On behalf of the ELN SIG, I'd like to share with you some of our plans
for summer 2023. First, as some of you may know, we will be more
actively beginning the process of launching CentOS Stream 10. We have
made some recent changes to our strategy and schedule and this email
will attempt to cover them both in detail. This will be a long email,
so strap in!

== tl;dr ==
* We'll do an ELN mass rebuild to see how many builds will fail
* We'll import ELN packages to c10s gradually, starting with just the
runtime set. We'll use ELN as the buildroot at the start.
* We'll import the buildroot set to c10s when it gets small enough.
* You’ll see activity in CentOS Stream 10, but it’s not yet time to
get involved. A general availability announcement will follow sometime
in the first half of 2024.
== tl;dr ==

We plan to perform a targeted mass-rebuild of Fedora ELN in a side-tag
beginning on June 26th. We will be bumping the %{dist} value for ELN
(currently .eln126) to avoid rpmdev-bumpspec noise. This rebuild will
be used as a "canary" for how successful the initial import of CentOS
Stream would be if we were to start it on that day. We are making
several changes to our original plan as we do this.

First, as the cleanup of unnecessary dependencies in the Fedora ELN
has not yet completed, we are revising our plan of performing a
mass-import of *all* Fedora ELN content to CentOS Stream 10 in July.
Instead, we plan to move to a phased approach wherein we will first
import, build and test only the portions of CentOS Stream 10 that we
currently have slated for inclusion in the delivered "runtime". As a
necessary side-effect of this, it means that we will NOT be
transitioning directly to CentOS Stream 10 as a self-hosted
environment.

Instead, we will be retaining the Fedora ELN buildroot repository for
use as the CentOS Stream 10 buildroot repository for some time (quite
possibly until as late as February 6th, when Fedora 40 branches from
Rawhide and CentOS Stream ceases syncing builds from Fedora ELN).
During this time, CentOS Stream 10 builds will be superseded in the
buildroot by Fedora ELN builds. While this sounds counterintuitive,
this will actually allow us to take advantage of Fedora ELN to avoid
build-ordering problems, such as those from soname bumps. The reason
for this is that Fedora ELN, unlike when it in turn is synced from
Fedora Rawhide, will functionally contain all of the same intended
build attributes as CentOS Stream, such as build macros, compiler
baseline flags and specfile conditionals. Since Fedora ELN should
already be a preview of what CentOS Stream 10 should look like, we
anticipate that there will be far fewer opportunities for build
environment differences to rear their heads. Note that there will, of
course, be an override option in place should we need to explicitly
tag a CentOS Stream 10 build into the buildroot.

This leads me to my next schedule announcement: we will be performing
the initial CentOS Stream 10 branch creation in Gitlab for all
packages in the Fedora ELN runtime package set[1]  during the week of
July 19th, coincident with the Fedora 39 mass-rebuild. Once the
branches are created, we will also kick off the mass-build of that
package set using Fedora ELN as the buildroot. Given the timing with
the Fedora mass-rebuild, we are looking into whether to have our
CentOS Stream 10 import "piggyback" off of it by carrying our
Rawhide->ELN sync through to the ELN->CS10 sync, or if we would be
better off waiting and performing the import manually.

The last bit of the plan is something of a non-announcement. As of
right now, we do not have a firm date on when we will be importing the
CentOS Stream buildroot-only components into CentOS Stream 10. We're
toying with the idea of not doing this at all until we diverge from
Fedora 40 (2024-02-06) in order to maximize the time we have to trim
down the build dependencies. This way we do not end up importing and
retiring dozens or hundreds of unwanted packages into CentOS Stream
Gitlab, only to retire them shortly thereafter.

A lot of this is new and somewhat experimental. That's why we have
decided on this rather aggressive timeline: if this does not go as
smoothly as we hope, we will have ample time to correct before CentOS
Stream 10 goes live for wider contribution.

Alright, I guess this isn't quite as long as I expected it was going
to be, but it's quite dense. Questions and suggestions are most
welcome.


== Some Expected Questions We Have Answers For ==

Q1: Does this mean that CentOS Stream 10 is opening for contribution soon?
A1: From the geological scale of enterprise software, absolutely! From
the scale of a Fedora cycle, it's still at least six months out. That
said, since we're priming the pump in public this time around, you
will have a much clearer window into how things get rolling.

Q2: Why are the CentOS Stream 10 builds not going to take priority
over the ELN external repo

Fedora ELN Plans for Summer 2023