[Test-Announce] 2024-04-29 @ 15:00 UTC - Fedora Quality Meeting

2024-04-28 Thread Adam Williamson 
# Fedora Quality Assurance Meeting
# Date: 2024-04-29
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location:
https://matrix.to/#/#meeting:fedoraproject.org?web-instance[element.io]=chat.fedoraproject.org

Greetings testers! It's meeting time again.

Here is a handy link which should show you the meeting time
in your local time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+quality+meeting&iso=20240415T15&p1=1440&ah=1

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 40 post-release status and recap
3. Fedora 41 Change preview
4. Test Day / community event status
5. Open floor
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

Re: how to do minor bump using %autorelease?

2024-04-28 Thread Kevin Kofler via devel 
Julian Sikorski wrote:
> I need to rebuild mame on F40 only for qt-6.7. On rawhide,
> mame-0.265-1.fc41 is already built against it so I only need to build
> mame-0.265-1.fc40.1. Can it be done using %autorelease?

No, which is why you should not be using %autorelease.

I would just replace %autorelease with a correctly manually bumped Release 
in the specfile as part of doing the rebuild.

Just letting %autorelease do its thing and ending up with a full bump would 
be incorrect, so it should not even be considered as an option.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: systemd 256~rc1 in rawhide

2024-04-28 Thread Kevin Kofler via devel 
Adam Williamson wrote:
> Well, it really wants to write to /lib , not to /usr. But of course, on
> Fedora, /lib is /usr/lib .

Sigh… Time for a UsrUnmerge? :-)

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there a policy for branches being merged or not

2024-04-28 Thread Kevin Kofler via devel 
Julian Sikorski wrote:
> In this case defaulting to cherry-picking would be a safer bet. Branches
> unintentionally separated can be merged, but branches unintentionally
> merged cannot be unmerged.

This is only true if you are talking about merge-commit merges. Not if we 
are keeping the branches fast-forwarded (and using %{?fedora} conditionals 
in the rare event something really needs to differ between the releases). A 
linear history cannot be remade truly linear once it was diverged by a 
cherry-pick (or simply a separate bump from running rpmdev-bumpspec 
separately on each branch, as scripted rebuilds often do). The best we can 
do to restore fast-forwardability is to merge one way and then "merge back", 
which will fast-forward the other branch to the same merge commit. This 
still leaves an ugly knot in the history, but at least the branches can then 
be fast-forwarded again. But a clean linear history is no longer possible 
after someone did an unwanted cherry pick instead of a fast-forward merge.

Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F41 Change Proposal: Node.js 22.x by default (system-wide)

2024-04-28 Thread Aoife Moloney 
Wiki - https://fedoraproject.org/wiki/Changes/Nodejs22
Discussion thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-node-js-22-x-by-default-system-wide/114740

This is a proposed Change for Fedora Linux.
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 ==
The latest release of Node.js to carry a 30-month lifecycle is the
22.x series. As with 20.x, 18.x 16.x, 14.x, 12.x, 10.x and 8.x before
it, Fedora 41 will carry 22.x as the default Node.js interpreter for
the system. The 20.x, and 18.x interpreters will remain available as
parallel-installable options.


== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgall...@fedoraproject.org
* Responsible SIG: Node.js SIG


== Detailed Description ==
Fedora 41 will ship with the latest LTS version of Node.js. '''dnf
install nodejs''' will give users Node.js 22.x and the matching npm
package.

== Benefit to Fedora ==
Node.js is a popular server-side JavaScript engine. Keeping Fedora on
the latest release allows us to continue tracking the state-of-the-art
in that space. For those whose applications do not yet work with the
22.x release, Fedora 41 will also have the 20.x and 18.x releases
available as selectable module streams.


== Scope ==
* Proposal owners:

We will build Node.js 22.x in Rawhide over the next few days as a
non-default version (similar to 18.x in Fedora 40). Once this is done,
we will announce that the switch will occur on or soon after May 27th,
2024. At that time, we will rebuild Node.js 20.x in non-default mode
and rebuild Node.js 22.x as the default "nodejs" package with the
appropriate upgrade path.

* Other developers:
Any developer with a package that depends on Node.js at run-time or
build-time should test with the 22.x alternative package as soon as
possible. Issues should be reported to nod...@lists.fedoraproject.org.

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
Users running Fedora 39 or Fedora 40 with the nodejs-20 packages will
be automatically upgraded to the 22.x packages when they upgrade to
Fedora 41, which may cause compatibility issues. If users are running
software known not to support Node.js 22.x yet, they will need to
install the nodejs18 compatibility packages and possibly modify their
startup scripts to call `/usr/bin/node-18` rather than
`/usr/bin/node`.


== How To Test ==
* Confirm that `dnf install nodejs` results in Node.js 22.x being installed.
* Confirm that upgrading from Fedora 39 or Fedora 40 with nodejs-20.x
installed results in an upgrade to nodejs-22.x
* Confirm that upgrading from Fedora 39 or Fedora 40 with the nodejs22
package installed results in an upgrade to the nodejs-22.x package,
obsoleting the nodejs22 package.

== User Experience ==
Users will have the 22.x release of Node.js available by default. See
the "Upgrade/compatibility impact" section for specific details.


== Dependencies ==
All packages prefixed with `nodejs-` depend on this package. If they
do not work with Node.js 22.x, they will need to be updated, or made
explicitly dependent upon the `nodejs20` compatibility package or else
removed from Fedora 41.

Prior to the switchover date to Node.js 22.x as the default, packagers
are strongly encouraged to test their existing Node modules with 22.x
by installing the nodejs22 forward-compatibility package (which
provides `/usr/bin/node-22`


== Contingency Plan ==
* Contingency mechanism: Revert to Node.js 20.x as the default Node.js
interpreter. This will require bumping epoch.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No

== Documentation ==
* https://nodejs.org/dist/latest-v22.x/docs/api/
* https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V22.md
* https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/

== Release Notes ==
Fedora 41 now ships with Node.js 22.x as the default Node.js
JavaScript server-side engine. If your applications are not yet ready
for this newer version, they will need to be modified to depend on the
compatibility package nodejs20 and to rely on `/usr/bin/node20` rather
than `/usr/bin/node` for operation.


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
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.f

F41 Change Proposal: Perl 5.40 (system-wide)

2024-04-28 Thread Aoife Moloney 
Wiki - https://fedoraproject.org/wiki/Changes/perl5.40
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-perl-5-38-system-wide/114739

This is a proposed Change for Fedora Linux.
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 ==
A new ''perl 5.40'' version brings a lot of changes done over a year
of development. Perl 5.40 should be released on May 20th 2024. See
[https://metacpan.org/release/PEVANS/perl-5.39.9/view/pod/perldelta.pod
perldelta for 5.39.9] for more details about new release.

== Owner ==
* Name: [[User:Jplesnik| Jitka Plesníková]], [[User:Mspacek| Michal
Josef Špaček]]
* Email: , 


=== Completed Items ===

=== Items in Progress ===

=== Items to Be Done ===
* Get dedicated build-root from rel-engs ''f41-perl''
* Upstream to release Perl 5.40
* Define perl_bootstrap in perl-srpm-macros
* Rebase perl to 5.40.0
* Rebuild all dual-lived packages (83) - otherwise dnf recommends
--skip-broken and fails
* Rebuild packages needed for minimal build-root
* Rebuild packages needed for building source packages from git repository
* Rebuild packages requiring ''libperl.so'' or versioned
''perl(MODULE_COMPAT)'': Use Fedora::Rebuild dependency solver
* Undefine perl_bootstrap
* Rebuild packages having perl_bootstrap condition in spec file (51 packages)
* Rebuild all updated packages
* [https://jplesnik.fedorapeople.org/5.40/ Final lists of results]
* Merge dedicated build-root to rawhide and remove the dedicated one by rel-engs
* Synchronize packages upgraded in ''f41'' build root
* Rebuild Perl packages: 0 of 606 done (0.00 %)
* Failed packages (0):

== Detailed Description ==
New perl is released every year and updates containing mainly bug
fixes follow during the year. The 5.40.0 version is stable release
this year.

== Benefit to Fedora ==
Up-to-date and latest perl release will be delivered to Fedora users.

== Scope ==
Every Perl package will be rebuilt in a dedicated ''f41-perl''
build-root against perl 5.40.0 and then if no major problem emerges
the packages will be merged back to ''f41'' build-root.

* Proposal owners: New perl and all packages requiring ''libperl.so''
or versioned ''perl(MODULE_COMPAT)'' will be rebuilt into ''f41-perl''
build-root.

* Other developers: Owners of packages that fail to rebuild, mainly
perl-sig users, will be asked using Bugzilla to fix or remove their
packages from the distribution.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] 
Release engineers will be asked for new ''f41-perl'' build-root
inheriting from ''f41'' build-root. After successful finishing the
rebuild, they will be asked to merge ''f41-perl'' packages back to
''f41'' build-root.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
Vast majority of functionality will be preserved. Only the packages
that failed to build against perl 5.40 will be removed from the
distribution. That will require to remove those packages from the
existing systems otherwise a package manager will encounter
unsatisfied dependencies. The developers in Perl language are advised
to install ''perl-doc'' and ''perl-debugger'' packages.

== How To Test ==
Try upgrading from Fedora 40 to 41. Try some Perl application to
verify they work as expected. Try embedded perl in
[https://src.fedoraproject.org/rpms/openldap slapd] or
[https://src.fedoraproject.org/rpms/net-snmp snmpd].

== User Experience ==
There should not be any remarkable change in user experience. With the
exception that previously locally installed modules with a CPAN
clients will need a reinstallation.

== Dependencies ==
There is more than 3500 packages depending on perl. We will rebuild
only all dual-lived packages and packages which require ''libperl.so''
or versioned ''perl(MODULE_COMPAT)''. It means only about 600 packages
needs to rebuild. Most of them are expected not to break. Finishing
this change can be endangered only by critical changes in a toolchain.
''noarch'' packages don't need to be rebuilt now.

== Contingency Plan ==
* Contingency mechanism: If we find perl 5.40 is not suitable for
Fedora 41, we will revert back to perl 5.38 and we drop the temporary
build-root with already rebuilt packages.
* Contingency deadline: branching Fedora 41 from Rawhide.
* Blocks release? No.

== Documentation ==
* 5.40.0 perldelta
* An announcement on perl-devel mailing list
* An announcement on fedora-devel mailing list

== Release Notes ==
TBD, when release candidate appears.

--
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -

Re: Is there a policy for branches being merged or not

2024-04-28 Thread Julian Sikorski 

Am 28.04.24 um 10:36 schrieb Peter Robinson:



On Sun, 28 Apr 2024, 09:28 Julian Sikorski, > wrote:


Hello,

is there a general recommendation regarding keeping git release
branches
separate vs merged? I have been keeping mine separate. Originally to
avoid release and changelog conflicts when cherry-picking, but I got
used to it and kept doing it after converting to %autorelase and
%autochangelog.
Recently one of my packages got it branches merged by a provenpackager
doing a deps rebuild. If there is no policy to merge, this is
disappointing as force-pushes as not allowed and branches once merged
cannot be unmerged. I know this is just a cosmetic issue, but choices
made by the primary maintainers should be respected IMO.


It's up to the maintainers, but it's also hard to determine what the 
maintainer's intentions are for those sorts of things, especially if 
you're scripting a rebuild across 100s of packages for a bump.


As both a maintainer and a proven packagers I tend to just assume the 
person has the best intentions of the project in mind.




In this case defaulting to cherry-picking would be a safer bet. Branches 
unintentionally separated can be merged, but branches unintentionally 
merged cannot be unmerged.


Best regards,
Julian
--
___
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: Is there a policy for branches being merged or not

2024-04-28 Thread Peter Robinson 
On Sun, 28 Apr 2024, 09:28 Julian Sikorski,  wrote:

> Hello,
>
> is there a general recommendation regarding keeping git release branches
> separate vs merged? I have been keeping mine separate. Originally to
> avoid release and changelog conflicts when cherry-picking, but I got
> used to it and kept doing it after converting to %autorelase and
> %autochangelog.
> Recently one of my packages got it branches merged by a provenpackager
> doing a deps rebuild. If there is no policy to merge, this is
> disappointing as force-pushes as not allowed and branches once merged
> cannot be unmerged. I know this is just a cosmetic issue, but choices
> made by the primary maintainers should be respected IMO.
>

It's up to the maintainers, but it's also hard to determine what the
maintainer's intentions are for those sorts of things, especially if you're
scripting a rebuild across 100s of packages for a bump.

As both a maintainer and a proven packagers I tend to just assume the
person has the best intentions of the project in mind.

Best regards,
> Julian
> --
> ___
> 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

Is there a policy for branches being merged or not

2024-04-28 Thread Julian Sikorski 

Hello,

is there a general recommendation regarding keeping git release branches 
separate vs merged? I have been keeping mine separate. Originally to 
avoid release and changelog conflicts when cherry-picking, but I got 
used to it and kept doing it after converting to %autorelase and 
%autochangelog.
Recently one of my packages got it branches merged by a provenpackager 
doing a deps rebuild. If there is no policy to merge, this is 
disappointing as force-pushes as not allowed and branches once merged 
cannot be unmerged. I know this is just a cosmetic issue, but choices 
made by the primary maintainers should be respected IMO.


Best regards,
Julian
--
___
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