Broken link

[Mikhail Gorsky via devel]

Hello! Please pay attention that ISO for x86_64 from 
https://fedoraproject.org/workstation/download/ is not available. ___
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: Koji builders cannot build Wine Mono

[Michael Cronenworth]

On 6/20/23 12:21 AM, Michael Cronenworth wrote:
The builds fail in similar ways but in different places. If anyone has a minute 
could they review the build logs and offer a clue as to what may be the cause? 


I had some time to debug today and came up with a possible answer I feel is the 
solution.


I was able to locally reproduce the issue seen on the Koji builders.

Working local system:
AMD 5800X3D
Fedora 38 - Kernel 6.3.7-200.fc38.x86_64

Broken local system:
Intel Xeon E-2288G
Fedora 38 - Kernel 6.2.15-300.fc38.x86_64

I was able to "coax" the broken system along by running "make" multiple times. It 
would error, but a second make run would succeed but error later in the compile.


I upgraded the "broken" system to kernel 6.3.9-200.fc38.x86_64 and now it 
successfully builds Wine Mono on the first try. It appears there is a kernel bug in 
6.2 that is fixed in 6.3.


I noticed the Koji builders are running kernel 6.2.x... When will the Koji builders 
be upgraded next? :)


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

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8f0f0d103a   
chromium-114.0.5735.133-1.el9
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-534fc4dfaa   
suricata-6.0.13-1.el9
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b19b890d2f   
dav1d-1.2.1-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

mlpack-4.2.0-1.el9
python-cloudflare-2.11.6-2.el9
python-dulwich-0.21.3-1.el9
python-tldextract-3.4.4-1.el9
radicale-3.1.8-53.el9
rbldnsd-0.998b-11.el9
rust-aes-0.8.3-1.el9
rust-anstyle-1.0.1-1.el9
rust-anstyle-parse-0.2.1-1.el9
rust-arrayvec-0.7.4-1.el9
rust-cfg-expr-0.15.3-1.el9
rust-cpufeatures-0.2.8-1.el9
rust-crossbeam-utils-0.8.16-1.el9
rust-gimli-0.27.3-1.el9
rust-net2-0.2.39-1.el9
rust-polyval-0.6.1-1.el9
rust-scroll_derive-0.11.1-1.el9
rust-serde_json-1.0.97-1.el9
rust-sha2-0.10.7-1.el9
rust-streebog-0.10.2-1.el9
rust-system-deps-6.1.1-1.el9
rust-target-lexicon-0.12.8-1.el9
rust-tracing-attributes-0.1.26-1.el9
rust-uuid-1.3.4-1.el9
rust-want-0.3.1-1.el9
rust-winnow-0.4.7-1.el9

Details about builds:



 mlpack-4.2.0-1.el9 (FEDORA-EPEL-2023-7782d94fe6)
 Fast, header-only C++ machine learning library

Update Information:

Update to latest stable version.

ChangeLog:

* Thu Jun 22 2023 Ryan Curtin  - 4.2.0-1
- Update to latest stable version.
* Thu Apr 27 2023 Benson Muite  - 4.1.0-1
- Update to new version
* Sat Feb 25 2023 Benjamin A. Beasley  - 4.0.1-4
- Update min. stb_image versions for nullptr deref. bug
- Add stb license to the License field
* Mon Feb 13 2023 Benson Muite  - 4.0.1-3
- Use SPDX identifiers
- Update license information to include Apache-2.0
* Thu Jan 19 2023 Fedora Release Engineering  - 
4.0.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild




 python-cloudflare-2.11.6-2.el9 (FEDORA-EPEL-2023-d23b90d73a)
 Python wrapper for the Cloudflare Client API v4

Update Information:

Update to 2.11.6

ChangeLog:

* Fri Jun 16 2023 Python Maint  - 2.11.6-2
- Rebuilt for Python 3.12
* Wed Jun 14 2023 Nick Bebout  - 2.11.6-1
- Update to 2.11.6
* Wed Jun 14 2023 Python Maint  - 2.11.1-3
- Rebuilt for Python 3.12
* Fri Jan 20 2023 Fedora Release Engineering  - 
2.11.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild

References:

  [ 1 ] Bug #2208614 - python-cloudflare-2.11.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2208614




 python-dulwich-0.21.3-1.el9 (FEDORA-EPEL-2023-54ceb677d0)
 Python implementation of the Git file formats and protocols

Update Information:

Latest build for EPEL 9

ChangeLog:

* Sun Feb 19 2023 Fabian Affolter  - 0.21.3-1
- Upgrade to latest upstream release 0.21.3 (closes rhbz#2170942)
* Wed Jan 25 2023 Fabian Affolter  - 0.21.2-1
- Upgrade to latest upstream release 0.21.2 (closes rhbz#2138585)
* Fri Jan 20 2023 Fedora Release Engineering  - 
0.20.46-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Tue Sep 13 2022 Fabian Affolter  - 0.20.46-1
- Update to latest upstream release 0.20.46 (closes rhbz#2124623)
* Fri Aug 19 2022 Fabian Affolter  - 0.20.45-1
- Update to latest upstream release 0.20.45 (closes rhbz#2107737)
* Fri Jul 22 2022 Fedora Release Engineering  - 
0.20.44-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Fri Jul  8 2022 Fabian Affolter  - 0.20.44-1
- Update to latest upstream release 0.20.44 (closes rhbz#2102830)
* Mon Jun 13 2022 Python Maint  - 0.20.43-2
- Rebuilt for Python 3.11
* Tue Jun  7 2022 Fabian Affolter  - 0.20.43-1
- Update to latest upstream release 0.20.43 (closes rhbz#2089721)
* Thu May 19 2022 Fabian Affolter  - 0.20.40-1
- Update to latest upstream release 0.20.40 (closes rhbz#2086840)
* Sun May 15 2022 Fabian Affolter  - 0.20.36-1
- Update to latest upstream release 0.20.36 (closes rhbz#2086300)
* Sun Mar 20 2022 Fabian Affolter  - 

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-3947e434d2   
chromium-114.0.5735.133-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-2ca43aa1cf   
suricata-6.0.13-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

radicale-3.1.8-53.el8

Details about builds:



 radicale-3.1.8-53.el8 (FEDORA-EPEL-2023-0146dbd11d)
 A simple CalDAV (calendar) and CardDAV (contact) server

Update Information:

Update patch release/upstream to d7ce2f0b (2023-04-22) Add radicale-3.1.8-fix-
main-component-PR-1252.patch Partially align spec file with Fedora variant

ChangeLog:

* Wed Jun 21 2023 Peter Bieringer  - 3.1.8-53
- Update patch release/upstream to d7ce2f0b (2023-04-22)
- Add radicale-3.1.8-fix-main-component-PR-1252.patch
- Partially align spec file with Fedora variant


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

Re: What is Fedora?

[Neil Hanlon]

On Fri, Jun 23, 2023, 18:41 Josh Boyer  wrote:

>
>
> On Fri, Jun 23, 2023, 3:20 PM Michael Catanzaro 
> wrote:
>
>> On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer
>>  wrote:
>> > Which means equivalent fixes are in CentOS Stream and anyone wanting
>> > to recreate exactly what is in RHEL is welcome to backport that code
>> > from CentOS Stream or upstream.
>>
>> Yes, but that's going to be pretty hard to do if you cannot see what
>> needs to be backported because you don't have a Customer Portal
>> subscription. :)
>>
>
> Yes, the work you do is not easy.
>
> In this particular case, there are two CVEs fixed somewhere in the
>> middle of maybe 100 other upstream changes, and the correspondence
>> between CVE vs. upstream commit is intentionally not public to
>> discourage distros from backporting individual security fixes. (It's
>> not a smart idea. Only 5% of WebKit security bugs get CVEs. I sometimes
>> do security backports for RHEL anyway for regulatory rather than
>> security reasons.) Anyway, to figure out what to backport in order to
>> match what's in RHEL, you'd have to either somehow get access to the
>> RHEL SRPM, or else email me and ask what to do.
>>
>
> Or build up a knowledge of the code base that allows one to do it
> themselves.
>
> I don't really have any strong opinion about this change. Just pointing
>> out that it's going to be effectively impossible to reverse-engineer
>> RHEL from CentOS Stream. Let's not pretend that's realistic. Rebuilders
>> are going to need to get copies of the RHEL SRPMs somehow if they want
>> to match RHEL, and they do.
>>
>
> I don't think it's impossible.  I think it requires work, skill, and
> investment.
>

if only that time, skill, and investment wasn't doing useless re-work, and
could be spent on contributing to Stream.


> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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: Towards enabling rpm sysusers integration

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> getservbyname would use /etc/services, but I'm not sure how widely it is used.
> A lot of code just hardcodes a specific number… Local configuration for
> port numbers is a concept that only works if somebody synchronizes the
> file across machines, which is unlikely to happen.
> 
> Similarly for /etc/protocols… Code would generally use a define, not
> resolve the protocol number from a string.
> 
> I removed both files on a machine and rebooted and there are no
> messages or any other indiciation that this makes a difference.
> 
> And in particular in the initrd, they are just not neeed.

Just checking one thing, NFS uses getservbyname, so they are needed, and
needed in the initrd for NFS root.

-- 
Chris Adams 
___
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

[Bug 2214989] perl-HTTP-Tiny-0.084 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2214989

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version||perl-HTTP-Tiny-0.084-1.fc38
Last Closed||2023-06-24 01:21:16



--- Comment #5 from Fedora Update System  ---
FEDORA-2023-bceb1cb5c8 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2214989

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202214989%23c5
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Towards enabling rpm sysusers integration

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jun 23, 2023 at 08:20:58PM +0200, Michal Domonkos wrote:
> On Thu, Jun 22, 2023 at 01:18:27PM +0300, Panu Matilainen wrote:
> > Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's
> > time to start looking towards enabling the sysusers integration:
> > https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
> 
> [...]
> 
> > 3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased
> > out. As it'll be a long time before the sysusers feature is in all Fedora
> > versions, it needs a longer term plan. One simple possibility is do what was
> > done with all those ldconfig from %post back then: change the %sysusers_()
> > macros to no-ops in rawhide to let rpm handle it, and only actually bother
> > updating packages once all relevant versions have the sysusers feature.
> 
> This proposal would effectively move all existing packages that create users 
> or
> groups from useradd/groupadd (called by those %sysuser* macros underneath) to
> systemd-sysusers(8).
> 
> I wonder if we shouldn't first just move those macros over to systemd-sysusers
> to test-drive this utility at a larger scale and catch any potential bugs or
> issues before actually proceeding with the remaining steps as outlined in the
> email.

I don't think so. Either way, the actual implementation is going to be a call to
systemd-sysusers. But the rpm-internal approach is quite different in how the
call is constructed from the macro-based approach, so the failure modes are
likely to be different. If were to switch to the macro-based approach
temporarily, we'd create quite a lot of churn and _different_ failure modes. So
I think that if we're switching to sysusers as the implementation, we should go
for the intended final approach immediately.

Zbyszek
___
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: Towards enabling rpm sysusers integration

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jun 22, 2023 at 10:25:10AM -0500, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> > I was hoping we would be make the dependency on setup optional.
> > It is a fairly heavyweight package (700+ kb) and with lots of
> > not-that-useful-on-a-typical-modern-installation stuff (mail alias support,
> > csh profile, /etc/hosts, nfs exports, etc.). Most of this is tiny, but it
> > clutters /etc, which ideally would be empty, and also /etc/services is 700 
> > kb.
> 
> /etc/services and /etc/protocols are AFAIK mandatory if you want to have
> network services (either client or server).  I don't think there's
> anything else providing that information.

getservbyname would use /etc/services, but I'm not sure how widely it is used.
A lot of code just hardcodes a specific number… Local configuration for
port numbers is a concept that only works if somebody synchronizes the
file across machines, which is unlikely to happen.

Similarly for /etc/protocols… Code would generally use a define, not
resolve the protocol number from a string.

I removed both files on a machine and rebooted and there are no
messages or any other indiciation that this makes a difference.

And in particular in the initrd, they are just not neeed.

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

[Bug 2217108] New: perl-CPAN-Perl-Releases-5.20230623 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2217108

Bug ID: 2217108
   Summary: perl-CPAN-Perl-Releases-5.20230623 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 5.20230623
Upstream release that is considered latest: 5.20230623
Current version/release in rawhide: 5.20230616-1.fc39
URL: https://metacpan.org/dist/CPAN-Perl-Releases/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5881/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2217108

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202217108%23c0
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Clean Systemd-boot installs (Self-Contained_

[Jeremy Linton]

Hi,

On 6/23/23 05:27, Gerd Hoffmann wrote:

== Detailed Description ==
As a first pass, the 'inst.sdboot' option already in anaconda should
work. As it stands, that replaces grub+shim with the systemd-boot
loader, and moves the kernel + initrd to the EFI system partition
(ESP). It doesn't attempt to create unified kernel images, so the
existing `dnf update`, `kdumpctl`, and `make install` in a kernel
source directory should all work.


What is the plan for existing UKIs, for example kernel-uki-virt.rpm?

I'd expect they should work fine without extra work (i.e. try a
kickstart file with '-kernel' + '-kernel-core' + 'kernel-uki-virt' in
the file list).


Since no one else said anything, I will comment that I've not tested the 
uki package on top of systemd-boot + normal kernel flow. But the 
knowledge of where to put the kernels (/boot or ESP) is autodetected by 
the kernel-install script sorta automatically, and when grub isn't in 
the picture its happy to put them on the ESP alongside the BLS entries.


Presumably as you note below kernel-install should be able to do this 
for UKI kernels as well, removing the need to move them. Although the 
BLS type is set to "type1" and puts the kernel + initrd in 
/boot/efi/`cat /etc/machine-id`/`uname -r`/. So, setting the 
KERNEL_INSTALL_LAYOUT=uki should override the entries.srel and get them 
in the right place.


So, in theory it should work, but probably needs tweaking here/there.

Something else to test is what happens if both UKIs and traditional 
kernel + initrd exist on the ESP as the docs seem to want one or the 
other tied to "type1"/"type2"





[ Side node: Right now the kernel-uki-virt %postinstall just does a copy
   to /boot/efi/EFI/Linux where systemd-boot should find them just fine.
   After systemd v254 release we which brings some kernel-install
   improvements for UKIs we should be able to switch over to use
   kernel-install instead ].

take care,
   Gerd
___
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: What is Fedora?

[Josh Boyer]

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

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

Yes, the work you do is not easy.

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

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

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

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

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

Fw: Two Years of Fedora Releases

[Leslie Satenstein via devel]

Hello from Montreal, Canada
I have been a Fedora user for about 20 years.  In all that time, it was known 
that the frequency of Fedora updates are as you described.
However, I just want to remind you that when a new release of Fedora is 
published, that Fedora also provides a utility (a dnf release upgrade) that 
will perform the necessary changes to easily move you to the next Fedora 
version,
In the past, for very long periods between upgrades, there was available 
"Centos". Centos was used for servers and for desktop applications that were 
"frozen in time". Open CentOS is no more. Perhaps you should explore using 
RedHat and/or CentOS for your very long-term needs.  
 Fedora is a community distribution generally targeting single independent 
users or families, where we Linux devotees look for product improvements along 
with good stability, and in return, we report technical issues hat are 
encountered  and often, solutions or work-arounds.  Some of us use Fedora as a 
home-server, supporting the family needs. 

In closing, as a community edition, Fedora is not meant to be supported for 
more than 18 months, beginning from the date of release of that version.
I wish you well in your search for a long-term solution for your needs.

Yours truly,
Leslie Satenstein
 

   - Forwarded Message - From: مصعب الزعبي To: 
devel@lists.fedoraproject.org Sent: Friday, June 
23, 2023 at 06:41:22 a.m. EDTSubject: Two Years of Fedora Releases
  Dear Fedora development community,
As you know Fedora releases every 6 months for one year of lifetime. This is 
good for development and new features implementation. 
But it is not good for stability and sustainability. 

When upgrading the system every 6 months, alot of resources will be trashed!! 
For Fedora users and Fedora itself.
It will be more stable, effective,  natural-friendly and feasible if we make 
Fedora lifetime as:
- One year between releases. - Two year of release lifetime. 

Kind Regards, MOSAAB___
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: CentOS Stream, RHEL, and Fedora [was Re: What is Fedora?]

[Kevin Kofler via devel]

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

The *development process* is more open, but the production releases, which 
is the only thing end users are interested in, are less open!

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: What is Fedora?

[Michael Catanzaro]

On Fri, Jun 23 2023 at 01:27:24 PM -0400, Josh Boyer 
 wrote:

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


Yes, but that's going to be pretty hard to do if you cannot see what 
needs to be backported because you don't have a Customer Portal 
subscription. :)


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


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


Michael

___
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: Red Hat Stream ONLY, Orphaning packages

[Sérgio Basto]

On Wed, 2023-06-21 at 18:26 +0100, Philip Wyett wrote:
> Hi all,
> 
> After the announcement below today.
> 
> https://www.redhat.com/en/blog/furthering-evolution-centos-stream
> 

can you elaborate ? centos Stream will be the same source of RHEL , or
RHEL will have the same source of Centos Stream , what is the problem ?

> I will be in 5 days detaching myself and orphaning all packages I
> have involvement with.
> 
> Regards
> 
> Phil
> 
> ___
> 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

-- 
Sérgio M. B.
___
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: Towards enabling rpm sysusers integration

[Michal Domonkos]

On Thu, Jun 22, 2023 at 01:18:27PM +0300, Panu Matilainen wrote:
> Now that the initial hurdle of getting rpm 4.19 into rawhide is over, it's
> time to start looking towards enabling the sysusers integration:
> https://rpm-software-management.github.io/rpm/manual/users_and_groups.html

[...]

> 3. The various %sysuser_()* macros in systemd-rpm-macros need to be phased
> out. As it'll be a long time before the sysusers feature is in all Fedora
> versions, it needs a longer term plan. One simple possibility is do what was
> done with all those ldconfig from %post back then: change the %sysusers_()
> macros to no-ops in rawhide to let rpm handle it, and only actually bother
> updating packages once all relevant versions have the sysusers feature.

This proposal would effectively move all existing packages that create users or
groups from useradd/groupadd (called by those %sysuser* macros underneath) to
systemd-sysusers(8).

I wonder if we shouldn't first just move those macros over to systemd-sysusers
to test-drive this utility at a larger scale and catch any potential bugs or
issues before actually proceeding with the remaining steps as outlined in the
email.

That's a lower-risk first step that should be fairly easy to implement right
away, as mentioned in:

https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format

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

Re: What is Fedora?

[Josh Boyer]

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

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

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

Re: [Fedocal] Reminder meeting : ELN SIG

[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?

[Michael Catanzaro]

On Fri, Jun 23 2023 at 06:16:52 PM +0200, Vít Ondruch 
 wrote:

Ah, there is actually webkit2gtk3-2.38.5-1.el9_2.2 not
webkit2gtk3-2.38.5-1.el9.2. I got it now.


Oh sorry, I mentally expanded the dist tag incorrectly. My bad.

Anyway, in this example, CentOS Stream is on 2.40 while RHEL 9.2 is on 
2.38. The RHEL security update is never visible in CentOS Stream 
because it's not needed there.


Hopefully 2.40 is better overall than 2.38 (and certainly much more 
secure), but certainly there are always plenty of new regressions and 
bugs that were not there before. No way to pretend you're 
bug-compatible with RHEL if you're pulling sources from 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: Two Years of Fedora Releases

[stan via devel]

On Fri, 23 Jun 2023 10:41:00 +
مصعب الزعبي  wrote: 
> - One year between releases.

This is easy to attain under the current system.  Just don't upgrade
every 6 months.  The upgrade process is tested to upgrade 2 fedora
versions, so, for example, from f38 to f40.  This is a one year
cadence.  You'll miss some changes, those that are not backward
compatible, but you will still receive security updates.

Incidentally, I'm not in favor of lengthening release and lifetime.  If
I wanted that, I would look for a distro that did that.

As someone else suggested, in the past I have run rawhide for a few
years, and it was just fine, with occasional glitches, but nothing like
'it eats babies'.  I wouldn't recommend it to someone who just came
from windows, but anyone who has worked through issues for a few
releases of fedora should be fine.  And, there are the forums and
lists, so it is possible to get help.  I *do* recommend that if you run
rawhide continuously, that you leave a working stable fedora install on
your machine that you can boot to access the web for help and essential
services in case something goes wrong.  Insurance.
___
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?

[Vít Ondruch]

Dne 23. 06. 23 v 18:14 Vít Ondruch napsal(a):


Dne 23. 06. 23 v 18:00 Vít Ondruch napsal(a):


Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
 wrote:

Please understand that (speaking of the user space packages, I cannot
speak for kernel) there are no other sources then the sources in 
GitLab,

which is publicly accessible (AFAIK).


The sources that are actually used for RHEL releases are certainly 
not available on GitLab. E.g. the latest released version of 
webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the 
source for that on GitLab, but it's not there because we don't have 
stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 
2.40.1-1.el9.





Or actually. What is the difference between 2.38.5-1.el9.2 and 
2.38.5-1.el9 except the dist tag? I probably don't understand.



Ah, there is actually webkit2gtk3-2.38.5-1.el9_2.2 not 
webkit2gtk3-2.38.5-1.el9.2. I got it now.



Vít


And that might be problem that neither others understand. But I'd 
assume that only the disttag differs.


Vít



Ok, you are right. But there are two things:

1) This was deliberate choice of maintainer, nothing else. Maintainer 
chosen to skip the 2.38.5 whatever the reason was


2) Does it harm anything to have the 9.3 package sooner the having 
RHEL 9.3 out? Is it really less stable as was claimed elsewhere in 
the thread?



Vít



OpenPGP_signature
Description: OpenPGP digital 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: What is Fedora?

[Vít Ondruch]

Dne 23. 06. 23 v 18:00 Vít Ondruch napsal(a):


Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
 wrote:

Please understand that (speaking of the user space packages, I cannot
speak for kernel) there are no other sources then the sources in 
GitLab,

which is publicly accessible (AFAIK).


The sources that are actually used for RHEL releases are certainly 
not available on GitLab. E.g. the latest released version of 
webkit2gtk3 is currently 2.38.5-1.el9.2. You can try finding the 
source for that on GitLab, but it's not there because we don't have 
stable branches on GitLab. CentOS Stream went from 2.38.5-1.el9 to 
2.40.1-1.el9.





Or actually. What is the difference between 2.38.5-1.el9.2 and 
2.38.5-1.el9 except the dist tag? I probably don't understand. And that 
might be problem that neither others understand. But I'd assume that 
only the disttag differs.


Vít



Ok, you are right. But there are two things:

1) This was deliberate choice of maintainer, nothing else. Maintainer 
chosen to skip the 2.38.5 whatever the reason was


2) Does it harm anything to have the 9.3 package sooner the having 
RHEL 9.3 out? Is it really less stable as was claimed elsewhere in the 
thread?



Vít



OpenPGP_signature
Description: OpenPGP digital 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

Fedora rawhide compose report: 20230623.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230622.n.1
NEW: Fedora-Rawhide-20230623.n.0

= SUMMARY =
Added images:0
Dropped images:  9
Added packages:  3
Dropped packages:0
Upgraded packages:   22
Downgraded packages: 0

Size of added packages:  128.36 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.23 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   6.43 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230622.n.1.ppc64le.qcow2
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20230622.n.1.iso
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20230622.n.1.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20230622.n.1.iso
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20230622.n.1.ppc64le.tar.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230622.n.1.ppc64le.qcow2
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20230622.n.1.iso
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20230622.n.1.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230622.n.1.ppc64le.raw.xz

= ADDED PACKAGES =
Package: rust-pem1-1.1.1-1.fc39
Summary: Parse and encode PEM-encoded data
RPMs:rust-pem1+default-devel rust-pem1+serde-devel rust-pem1-devel
Size:32.53 KiB

Package: rust-serial_test1-1.0.0-1.fc39
Summary: Allows for the creation of serialised Rust tests
RPMs:rust-serial_test1+async-devel rust-serial_test1+default-devel 
rust-serial_test1+file_locks-devel rust-serial_test1+fslock-devel 
rust-serial_test1+futures-devel rust-serial_test1+log-devel 
rust-serial_test1+logging-devel rust-serial_test1-devel
Size:67.80 KiB

Package: rust-serial_test_derive1-1.0.0-1.fc39
Summary: Helper crate for serial_test
RPMs:rust-serial_test_derive1+async-devel 
rust-serial_test_derive1+default-devel rust-serial_test_derive1-devel
Size:28.04 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  awscli-1.27.159-1.fc39
Old package:  awscli-1.27.158-1.fc39
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 3.32 MiB
Size change:  356 B
Changelog:
  * Thu Jun 22 2023 Gwyn Ciesla  - 1.27.159-1
  - 1.27.159


Package:  bgpq4-1.11-1.fc39
Old package:  bgpq4-1.10-1.fc39
Summary:  Automate BGP filter generation based on routing database 
information
RPMs: bgpq4
Size: 245.38 KiB
Size change:  1.26 KiB
Changelog:
  * Thu Jun 22 2023 Robert Scheck  1.11-1
  - Upgrade to 1.11 (#2216590)


Package:  bird-2.13.1-1.fc39
Old package:  bird-2.13-1.fc39
Summary:  BIRD Internet Routing Daemon
RPMs: bird bird-doc
Size: 2.92 MiB
Size change:  3.09 KiB
Changelog:
  * Thu Jun 22 2023 Robert Scheck  - 2.13.1-1
  - Upgrade to 2.13.1 (#2190169)


Package:  cppcheck-2.11-1.fc39
Old package:  cppcheck-2.9-4.fc38
Summary:  Tool for static C/C++ code analysis
RPMs: cppcheck cppcheck-gui cppcheck-htmlreport
Size: 18.10 MiB
Size change:  688.93 KiB
Changelog:
  * Thu Jun 22 2023 Steve Grubb  - 2.11-1
  - Update to 2.11
  - Disable tests (2 style tests failing)


Package:  dav1d-1.2.1-1.fc39
Old package:  dav1d-1.1.0-1.fc39
Summary:  AV1 cross-platform Decoder
RPMs: dav1d libdav1d libdav1d-devel
Size: 2.20 MiB
Size change:  26.94 KiB
Changelog:
  * Thu Jun 22 2023 Fabio Valentini  - 1.2.1-1
  - Update to version 1.2.1; Fixes RHBZ#2192725


Package:  flatpak-1.15.4-2.fc39
Old package:  flatpak-1.15.4-1.fc39
Summary:  Application deployment framework for desktop apps
RPMs: flatpak flatpak-devel flatpak-libs flatpak-selinux 
flatpak-session-helper flatpak-tests
Size: 12.65 MiB
Size change:  4.08 KiB
Changelog:
  * Thu Jun 22 2023 Tomas Popela  - 1.15.4-2
  - Disable parental control support (through malcontent) on RHEL


Package:  gnome-control-center-44.2-2.fc39
Old package:  gnome-control-center-44.2-1.fc39
Summary:  Utilities to configure the GNOME desktop
RPMs: gnome-control-center gnome-control-center-filesystem
Size: 26.77 MiB
Size change:  5.83 KiB
Changelog:
  * Thu Jun 22 2023 Tomas Popela  - 44.2-2
  - Disable parental control (through malcontent) on RHEL


Package:  gnome-software-44.2-2.fc39
Old package:  gnome-software-44.2-1.fc39
Summary:  A software center for GNOME
RPMs: gnome-software gnome-software-devel gnome-software-rpm-ostree
Size: 10.38 MiB
Size change:  -9.68 KiB
Changelog:
  * Thu Jun 22 2023 Tomas Popela  - 44.2-2
  - Disable

Re: What is Fedora?

[Vít Ondruch]

Dne 23. 06. 23 v 15:34 Michael Catanzaro napsal(a):
On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
 wrote:

Please understand that (speaking of the user space packages, I cannot
speak for kernel) there are no other sources then the sources in GitLab,
which is publicly accessible (AFAIK).


The sources that are actually used for RHEL releases are certainly not 
available on GitLab. E.g. the latest released version of webkit2gtk3 
is currently 2.38.5-1.el9.2. You can try finding the source for that 
on GitLab, but it's not there because we don't have stable branches on 
GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.



Ok, you are right. But there are two things:

1) This was deliberate choice of maintainer, nothing else. Maintainer 
chosen to skip the 2.38.5 whatever the reason was


2) Does it harm anything to have the 9.3 package sooner the having RHEL 
9.3 out? Is it really less stable as was claimed elsewhere in the thread?



Vít



OpenPGP_signature
Description: OpenPGP digital 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: Two Years of Fedora Releases

[Barry]

> On 23 Jun 2023, at 11:41, مصعب الزعبي  wrote:
> 
> When upgrading the system every 6 months, alot of resources will be trashed!! 
> For Fedora users and Fedora itself.

My experience supporting a commercial product on top of fedora is that it
is cheaper then using LTS distros.

The incremental engineering is also less resource intensive for devs and qa.

One reason is because you have access to people
that remember why things have changed and can help with upgrade issues.

Barry


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

[Michael Catanzaro]

On Fri, Jun 23 2023 at 01:07:39 PM +0200, Vít Ondruch 
 wrote:

Please understand that (speaking of the user space packages, I cannot
speak for kernel) there are no other sources then the sources in 
GitLab,

which is publicly accessible (AFAIK).


The sources that are actually used for RHEL releases are certainly not 
available on GitLab. E.g. the latest released version of webkit2gtk3 is 
currently 2.38.5-1.el9.2. You can try finding the source for that on 
GitLab, but it's not there because we don't have stable branches on 
GitLab. CentOS Stream went from 2.38.5-1.el9 to 2.40.1-1.el9.


___
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: Two Years of Fedora Releases

[Miroslav Suchý]

Dne 23. 06. 23 v 12:41 مصعب الزعبي napsal(a):

It will be more stable, effective, natural-friendly and feasible if we make 
Fedora lifetime as:

- One year between releases.
- Two year of release lifetime.


Why do you think this cadence is more effective, natural-friendly and feasible? Do you have data for that? Have you 
asked other developers? Users?


This idea of Fedora with longer release life appears every few months/years. Usually called Fedora LTS. What we have now 
is compromise of "we need to have fresh code" and "we need to have stable code" and "we need to have time to maintain it 
all".


Nothing stops you from organize people who share similar idea, create SIG. Gather the data about impact on 
infrastructure (that means money), impact on maintainers (are they willing to maintain packages two times longer?), and 
then you may ask FESCO to vote about it.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
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

xmlsec1 broken update in rawhide

[Tomas Halman]

Hi

Recently I prepared an update of xmlsec1 package to version 1.3 in rawhide
but by this step I broke other packages like lasso (I'm sorry for that my
mistake).

Since I did not manage to fix (Simo also tried with help from the upstream
community - thanks for the effort) and it is blocking others work I
reverted the change today and we are back to 1.2.

The update to 1.3 will come later once the issues are resolved.

Once again, sorry for the inconvenience.

-- 

Tomáš Halman

thal...@redhat.com

T: +420 727 830 769 <+420727830769>
*../``\..* Red Hat 
___
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: Two Years of Fedora Releases

[Michal Schorm]

That depends on what you are looking for.
There are a lot of distributions out there, each with different goals.
Pick one which goals are closest to yours.

However if you really want Fedora without upgrading often, try to run
Fedora Rawhide - our development branch.
You will have to deal with some downgrading of bugged package updates
from time to time, but in the last few years, it's stability is quite
good and I heard of a number of people using it on a daily basis.
That should feel like a rolling release - without ever upgrading, just updating.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Fri, Jun 23, 2023 at 12:59 PM Arthur Bols  wrote:
>
> On 23/06/2023 12:41, مصعب الزعبي wrote:
> > It will be more stable, effective, natural-friendly and feasible if we
> > make Fedora lifetime as:
> >
> > - One year between releases.
> > - Two year of release lifetime.
> >
> >
> That doesn't really work with our "First" goal [0]. Then we're just
> another Ubuntu.
>
> [0]: https://docs.fedoraproject.org/en-US/project/#_first
>
> --
> Arthur Bols
> fas/irc: principis
> ___
> 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: What is Fedora?

[Vít Ondruch]

Dne 23. 06. 23 v 12:46 Leon Fauster via devel napsal(a):

3) So what happened?

- CentOS Engineers will not be producing that git repo of exploded SRPMs
anymore because there is no need for them in CentOS project.

- Red Hat recommends to take RHEL sources from CentOS Stream
repositories because that is the actual source from which RHEL packages
are built by RHEL Engineers.

How to interpret it this way; "Red Hat recommends"? Its the other way around!
RH does want minimize the source availability by putting stones in the way!
This is in line with other activities (kernel patches).

Regarding Dev Account - that can be also disappear in the future!

Furthermore:

Take a look at the Unauthorized Use section

https://www.redhat.com/licenses/Appendix_1_Global_English_20230309.pdf

and "Partner will not use Red Hat Products or >>>Services to create an offering 
competitive with Red Hat,"

from

https://www.redhat.com/licenses/Partner_Agreement_Webversion_North_America_English_20220308.pdf

The tactic here - not the sources are used against the community its the road to them 
("Services")!

This is the cathedral method.


BTW; The sources "state" in gitlab is not stable and "far" away from RH GA 
releases!



Please understand that (speaking of the user space packages, I cannot 
speak for kernel) there are no other sources then the sources in GitLab, 
which is publicly accessible (AFAIK).




Vít



OpenPGP_signature
Description: OpenPGP digital 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: Two Years of Fedora Releases

[Arthur Bols]

On 23/06/2023 12:41, مصعب الزعبي wrote:
It will be more stable, effective, natural-friendly and feasible if we 
make Fedora lifetime as:


- One year between releases.
- Two year of release lifetime.


That doesn't really work with our "First" goal [0]. Then we're just 
another Ubuntu.


[0]: https://docs.fedoraproject.org/en-US/project/#_first

--
Arthur Bols
fas/irc: principis
___
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?

[Leon Fauster via devel]

> 3) So what happened?
> 
> - CentOS Engineers will not be producing that git repo of exploded SRPMs 
> anymore because there is no need for them in CentOS project.
> 
> - Red Hat recommends to take RHEL sources from CentOS Stream 
> repositories because that is the actual source from which RHEL packages 
> are built by RHEL Engineers.

How to interpret it this way; "Red Hat recommends"? Its the other way around!
RH does want minimize the source availability by putting stones in the way! 
This is in line with other activities (kernel patches).

Regarding Dev Account - that can be also disappear in the future!

Furthermore:

Take a look at the Unauthorized Use section

https://www.redhat.com/licenses/Appendix_1_Global_English_20230309.pdf

and "Partner will not use Red Hat Products or >>>Services to create an 
offering competitive with Red Hat," 

from 

https://www.redhat.com/licenses/Partner_Agreement_Webversion_North_America_English_20220308.pdf

The tactic here - not the sources are used against the community its the road 
to them ("Services")!

This is the cathedral method. 


BTW; The sources "state" in gitlab is not stable and "far" away from RH GA 
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

Two Years of Fedora Releases

[مصعب الزعبي]

Dear Fedora development community,

As you know Fedora releases every 6 months for one year of lifetime. This is 
good for development and new features implementation.

But it is not good for stability and sustainability.


When upgrading the system every 6 months, alot of resources will be trashed!! 
For Fedora users and Fedora itself.

It will be more stable, effective,  natural-friendly and feasible if we make 
Fedora lifetime as:

- One year between releases.
- Two year of release lifetime.


Kind Regards,
MOSAAB
___
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-Rawhide testing blocked in Testing Farm (partially)

[Miroslav Vadkerti]

Rawhide testing with Zuul was disabled until the issue is fixed.

Please use, the testing results from Fedora CI PR testing until it the dnf5
issues are resolved.

Best regards,
/M



On Thu, Jun 22, 2023 at 11:45 PM Miroslav Vadkerti 
wrote:

> To mitigate errors, I am proposing to disable Rawhide testing via Zull in
> dist-git PRs:
>
> https://pagure.io/fedora-zuul-jobs-config/pull-request/180
>
> /M
>
> On Thu, Jun 22, 2023 at 11:19 PM Miroslav Vadkerti 
> wrote:
>
>> Hi,
>>
>> A small update, Zuul testing is still blocked, please use the results
>> `Fedora CI - dist-git test` in the PR testing.
>>
>> The upstream bug that will need to be fixed to unblock Zuul testing:
>>
>> https://github.com/rpm-software-management/dnf5/issues/549
>>
>> Other problems are hopefully resolved.
>>
>> Best regards,
>> /M
>>
>> On Thu, Jun 22, 2023 at 11:16 AM Miroslav Vadkerti 
>> wrote:
>>
>>> Hi,
>>>
>>> a few more issues appeared:
>>>
>>> 1. Testing PRs via Zuul is broken due to missing feature in dnf5
>>>https://github.com/rpm-software-management/dnf5/issues/549
>>>
>>>No ETA for fixing this one 
>>> 2. Packit's sanity copr installation test fails due to to dnf5-plugins
>>> needed for copr plugin.
>>>
>>>ETA 30 min.
>>>
>>> Best regards,
>>> /M<
>>>
>>>
>>> On Wed, Jun 21, 2023 at 7:39 PM Miroslav Vadkerti 
>>> wrote:
>>>
 Both issues were hot patched, and testing against Rawhide is unblocked
 again \o/

 Thanks to all who helped!

 /M

 On Wed, Jun 21, 2023 at 2:51 PM Miroslav Vadkerti 
 wrote:

> Hi,
>
> Fedora Rawhide testing blocked on dnf5 update, which broke Testing
> Farm.
>
> We are trying to hotpatch the problems to bring back testing against
> Rawhide.
>
> ETA 2 hours.
>
> For updates watch:
> https://status.testing-farm.io/issues/2023-06-21-rawhide-outage/
>
> Best regards,
> /M
>
> --
> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
> Remote Czech Republic :: Red Hat Czech s.r.o
>
>
>

 --
 Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
 IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
 Remote Czech Republic :: Red Hat Czech s.r.o



>>>
>>> --
>>> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
>>> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
>>> Remote Czech Republic :: Red Hat Czech s.r.o
>>>
>>>
>>>
>>
>> --
>> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
>> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
>> Remote Czech Republic :: Red Hat Czech s.r.o
>>
>>
>>
>
> --
> Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
> IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
> Remote Czech Republic :: Red Hat Czech s.r.o
>
>
>

-- 
Miroslav Vadkerti :: Senior Principal QE :: Testing Farm / Linux QE
IRC mvadkert #tft #tmt #osci :: Mobile +420 773 944 252
Remote Czech Republic :: Red Hat Czech s.r.o
___
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: Clean Systemd-boot installs (Self-Contained_

[Gerd Hoffmann]

> == Detailed Description ==
> As a first pass, the 'inst.sdboot' option already in anaconda should
> work. As it stands, that replaces grub+shim with the systemd-boot
> loader, and moves the kernel + initrd to the EFI system partition
> (ESP). It doesn't attempt to create unified kernel images, so the
> existing `dnf update`, `kdumpctl`, and `make install` in a kernel
> source directory should all work.

What is the plan for existing UKIs, for example kernel-uki-virt.rpm?

I'd expect they should work fine without extra work (i.e. try a
kickstart file with '-kernel' + '-kernel-core' + 'kernel-uki-virt' in
the file list).

[ Side node: Right now the kernel-uki-virt %postinstall just does a copy
  to /boot/efi/EFI/Linux where systemd-boot should find them just fine.
  After systemd v254 release we which brings some kernel-install
  improvements for UKIs we should be able to switch over to use
  kernel-install instead ].

take care,
  Gerd
___
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

[rpms/perl-Devel-CheckLib] PR #3: Requires: redhat-rpm-config for tests

[Petr Pisar]

ppisar commented on the pull-request: `Requires: redhat-rpm-config for tests` 
that you are following:
``
I think the dependency should go to perl-Devel-CheckLib package. 
Devel::Checklib::_findcc() defaults compiler flags to $Config(cflags).
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Devel-CheckLib/pull-request/3
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Towards enabling rpm sysusers integration

[Miroslav Suchý]

Dne 22. 06. 23 v 17:01 Zbigniew Jędrzejewski-Szmek napsal(a):

I don't remember seeing an actual Fedora Change for either file-trigger
enablement or current %sysuser_* macros so I'm not sure it's needed here
either?

https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format


Please create a Change. It will helps to track the progress and works great as single point to gather the knowledge how 
to do the conversion.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Jonathan Steffan]

Matthew,

Thanks for sending this out. There is a lot of FUD right now and this plan
is what I had hoped was going on. The FPO/RH/IBM should do some additional
community engagement to clear this up. A very clear diagram of the
development/packaging flow would go a long way and give the community a
simple artifact to share in place of all of the FUD.

I was worried after reading some of the misinformation/misunderstanding. I
was getting concerned we'd have to start up FUDCons again and fork the
project. Thankfully, that does not at all seem to be the case.

Cheers,


On Fri, Jun 23, 2023 at 12:47 AM Simon de Vlieger  wrote:

> On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:
>
> > 1. Fedora Rawhide continually updated
> > 2. ELN maintained in parallel, as part of Fedora
> > 3. At some point, ELN branched to new CentOS Stream
> > 4. ... a year or so of CentOS Stream development in public ...
> > 5. RHEL Beta forked from that, released
> > 6. Work on RHEL updates visible in CentOS Stream
> > 7. Updates appear in CentOS Stream
> > 8. Updates released to RHEL
> >
> > Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git
> > history from Fedora, which is a big improvement in preserving all of the
> > incredible, valuable work from Fedora contributors.
> >
> > All of this is the exact opposite of Red Hat preparing to make some new
> base
> > for RHEL. Additionally, this model provides a clean path for
> > Red-Hat-opinionated decisions to differ from those we make from Fedora.
> Take
> > BTRFS as an example. Or, the increase in CPU baseline. Like this:
>
> Matthew, this is a great summary and also the understanding I currently
> have. It might be a good thing if this information lives in a more
> permanent place that I can refer people to. Perhaps something on Fedora's
> documentation about the Enterprise Linux ecosystem or a blogpost on either
> the Fedora or RedHat blogs?
>
> Regards,
>
> Simon
> ___
> 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
>


-- 
Jonathan Steffan
jonathanstef...@gmail.com
___
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?

[Benson Muite]

> 
> This doesn't impact Fedora, but will certainly impact the various
> RHEL rebuilds whether community based (AlmaLinux, Rocky Linux),
> or fully commercial (Oracle OEL). Those distros can still provide
> the initial point releases, but will have to do all the work to
> figure out backports for bug fixes/CVEs/etc within the release.
> This is going to be a serious burden for those distros.
> 
At present Red Hat is the primary sponsor for Fedora.  RHEL is one
downstream of Fedora, but there are others including Amazon Linux, Alma,
Rocky, CentOS, Miracle Linux, Qubes OS, Open Euler, Linpux etc. As a
result, Fedora development is healthy and robust, and may cost Red Hat
less than other development models. It may be good to evolve the Fedora
governance model to recognize other significant contributors (both
resources and time), either individually or corporate and provide a
means for these contributors to also contribute to the governance of the
project should they want to do so.
> With regards,
> Daniel
___
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 packages

[Vitaly Zaitsev via devel]

Hello.

I orphaned the following packages:

rpms/axc
rpms/git-subrepo
rpms/jdns
rpms/maddy
rpms/mdns
rpms/pidgin-groupchat-typing-notifications
rpms/pidgin-privacy-please
rpms/pidgin-toobars
rpms/psi
rpms/psi-plus
rpms/purple-discord
rpms/purple-googlechat
rpms/purple-libsteam
rpms/purple-lurch
rpms/purple-matrix
rpms/purple-plugin_pack
rpms/purple-skypeweb
rpms/python-wloc
rpms/python-networkmanager
rpms/python-pytelegrambotapi
rpms/python-emoji

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

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

[Simon de Vlieger]

On Thu, Jun 22, 2023, at 11:01 AM, Matthew Miller wrote:

> 1. Fedora Rawhide continually updated
> 2. ELN maintained in parallel, as part of Fedora
> 3. At some point, ELN branched to new CentOS Stream
> 4. ... a year or so of CentOS Stream development in public ...
> 5. RHEL Beta forked from that, released
> 6. Work on RHEL updates visible in CentOS Stream
> 7. Updates appear in CentOS Stream
> 8. Updates released to RHEL
>
> Note that with CentOS Stream 10 / RHEL 10, step 3 here will _maintain git
> history from Fedora, which is a big improvement in preserving all of the
> incredible, valuable work from Fedora contributors.
>
> All of this is the exact opposite of Red Hat preparing to make some new base
> for RHEL. Additionally, this model provides a clean path for
> Red-Hat-opinionated decisions to differ from those we make from Fedora. Take
> BTRFS as an example. Or, the increase in CPU baseline. Like this:

Matthew, this is a great summary and also the understanding I currently have. 
It might be a good thing if this information lives in a more permanent place 
that I can refer people to. Perhaps something on Fedora's documentation about 
the Enterprise Linux ecosystem or a blogpost on either the Fedora or RedHat 
blogs?

Regards,

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

SPDX Statistics - Berlin edition

[Miroslav Suchý]

Two weeks ago we had:


* 23004 spec files in Fedora

* 29461license tags in all spec files

* 17975 tags have not been converted to SPDX yet

* 6743tags can be trivially converted using `license-fedora2spdx`

* Progress: 38.99% ░░░███ 100%


Today we have:

* 23055 spec files in Fedora

* 29519license tags in all spec files

* 17864 tags have not been converted to SPDX yet

* 6691tags can be trivially converted using `license-fedora2spdx`

* Progress: 39.48% ░░░███ 100%

ELN subset:

* 1229 out of 3074 packages are not converted yet

The list of packages needed to be converted is again here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released.

Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.

I updated the progress the spreadsheet with Burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

New projection when we will be finished is 2024-10-22. Pure linear 
approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.


Why SPDX Berling edition? Because on today's date, in year 1948, Berlin Blockade started. It resulted in amazing 
logistic operation known as "Berlin Air Bridge" and included nice stories like "Candy Bombers" aka "Operation LIttle 
Vittles".


https://en.wikipedia.org/wiki/Berlin_Blockade


Do you hesitate how to proceed with the migration? Please follow

https://docs.fedoraproject.org/en-US/legal/update-existing-packages/

Miroslav


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

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

[Ian Laurie via devel]

On 6/22/23 19:01, Matthew Miller wrote:

Sure, but... that's the _opposite_ of the direction things are going.


Awesome post.

--
Ian Laurie
FAS: nixuser | IRC: nixuser
TZ: Australia/Sydney
___
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