[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-10430622fd syncthing-1.27.3-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-0b7ba715af pdns-recursor-4.8.6-1.el8 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-aa663fed4a python-treq-20.4.1-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-19fff4a604 dhcpcd-10.0.6-2.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing c-icap-0.6.2-1.el8 c-icap-modules-0.5.7-1.20240112git56d0179.el8 chromium-121.0.6167.184-1.el8 objfw-1.0.9-1.el8 plantuml-1.2024.3-1.el8 Details about builds: c-icap-0.6.2-1.el8 (FEDORA-EPEL-2024-6acfc9af51) An implementation of an ICAP server Update Information: Update to 0.6.2 release. ChangeLog: * Mon Jan 29 2024 Frank Crawford - 0.6.2-1 - Update to 0.6.2 release. - Drop perl RPM as removed upstream. * Tue Jan 23 2024 Fedora Release Engineering - 0.6.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 0.6.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Wed Nov 29 2023 Florian Weimer - 0.6.0-3 - Fix C compatibility issue in the configure script c-icap-modules-0.5.7-1.20240112git56d0179.el8 (FEDORA-EPEL-2024-e1202b532b) Services for the c-icap server Update Information: Updated to equivalent to 0.5.7 release. ChangeLog: * Sat Feb 17 2024 Frank Crawford - 0.5.7-1.20240112gite50f3c2 - Updated to equivalent to 0.5.7 release. * Tue Jan 23 2024 Fedora Release Engineering - 0.5.6-6.20230212gitfd1a1b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 0.5.6-5.20230212gitfd1a1b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild chromium-121.0.6167.184-1.el8 (FEDORA-EPEL-2024-7c698ee786) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 121.0.6167.184 ChangeLog: * Wed Feb 14 2024 Than Ngo - 121.0.6167.184-1 - update to 121.0.6167.184 objfw-1.0.9-1.el8 (FEDORA-EPEL-2024-6a16a4e3cd) Portable, lightweight framework for the Objective-C language Update Information: Update to 1.0.9 ChangeLog: * Sun Feb 18 2024 Jonathan Schleifer - 1.0.9-1 - Update to 1.0.9 * Thu Jan 25 2024 Fedora Release Engineering - 1.0.8-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild plantuml-1.2024.3-1.el8 (FEDORA-EPEL-2024-c64bc97cb9) Program to generate UML diagram from a text description Update Information: Update to version 1.2024.3 ChangeLog: * Sun Feb 18 2024 blinxen - 1:1.2024.3-1 - Update to version 1.2024.0 (rhbz#2263433) -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following builds have been pushed to Fedora EPEL 7 updates-testing c-icap-0.6.2-1.el7 c-icap-modules-0.5.7-1.20240112git56d0179.el7 chromium-121.0.6167.184-1.el7 Details about builds: c-icap-0.6.2-1.el7 (FEDORA-EPEL-2024-7e27d96cc8) An implementation of an ICAP server Update Information: Update to 0.6.2 release. ChangeLog: * Mon Jan 29 2024 Frank Crawford - 0.6.2-1 - Update to 0.6.2 release. - Drop perl RPM as removed upstream. * Tue Jan 23 2024 Fedora Release Engineering - 0.6.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 0.6.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Wed Nov 29 2023 Florian Weimer - 0.6.0-3 - Fix C compatibility issue in the configure script c-icap-modules-0.5.7-1.20240112git56d0179.el7 (FEDORA-EPEL-2024-f6b3b254dd) Services for the c-icap server Update Information: Updated to equivalent to 0.5.7 release. ChangeLog: * Sat Feb 17 2024 Frank Crawford - 0.5.7-1.20240112gite50f3c2 - Updated to equivalent to 0.5.7 release. * Tue Jan 23 2024 Fedora Release Engineering - 0.5.6-6.20230212gitfd1a1b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 0.5.6-5.20230212gitfd1a1b7 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild chromium-121.0.6167.184-1.el7 (FEDORA-EPEL-2024-9b2201a9e7) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 121.0.6167.184 ChangeLog: * Wed Feb 14 2024 Than Ngo - 121.0.6167.184-1 - update to 121.0.6167.184 -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-4a6bba707d libmodsecurity-3.0.12-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing anope-2.1.2-1.el7 bgpq4-1.12-1.el7 Details about builds: anope-2.1.2-1.el7 (FEDORA-EPEL-2024-897b264829) IRC services designed for flexibility and ease of use Update Information: Anope 2.1.2 Added module:tlsv10 to m_ssl_openssl for configuring whether TLSv1.0 is usable (defaults to no). Added module:tlsv11 to m_ssl_openssl for configuring whether TLSv1.1 is usable (defaults to yes). Added module:tlsv12 to m_ssl_openssl for configuring whether TLSv1.2 is usable (defaults to yes) Bumped the minimum OpenSSL version to 1.1.0. Bumped the minimum GnuTLS version to 3.0.0. Modernized mutex and thread code to use Modern C++. Normalised the program exit codes. Removed module:sslv3 from m_ssl_openssl. Removed the m_ prefix from the names of the chanstats, dns, dnsbl, helpchan, httpd, ldap, ldap_oper, mysql, proxyscan, redis, regex_pcre2, regex_posix, regex_stdlib, regex_tre, rewrite, sasl, sql_log, sql_oper, sqlite, ssl_gnutls, ssl_openssl, xmlrpc, and xmlrpc_main modules. Updated the Dutch translation. Updated the French translation. ChangeLog: * Sat Feb 17 2024 Robert Scheck 2.1.2-1 - Upgrade to 2.1.2 (#2264678) * Mon Jan 22 2024 Fedora Release Engineering - 2.1.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 2.1.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild References: [ 1 ] Bug #2264678 - anope-2.1.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=2264678 bgpq4-1.12-1.el7 (FEDORA-EPEL-2024-de802bd6d9) Automate BGP filter generation based on routing database information Update Information: bgpq4 1.12 Fix a bug in the MikroTik printer ChangeLog: * Sat Feb 17 2024 Robert Scheck 1.12-1 - Upgrade to 1.12 (#2263974) * Tue Jan 23 2024 Fedora Release Engineering - 1.11-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Fri Jan 19 2024 Fedora Release Engineering - 1.11-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Wed Jul 19 2023 Fedora Release Engineering - 1.11-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild References: [ 1 ] Bug #2263974 - bgpq4-1.12 is available https://bugzilla.redhat.com/show_bug.cgi?id=2263974 -- ___ 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: Feedback wanted - pruning old rawhide chroots in Copr
On Sun, 2024-02-18 at 23:45 +0100, Fabio Valentini wrote:
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber
> wrote:
> >
>
> (snip)
>
> >
> > I see this somehow connected to the discussion about signing keys
> > that
> > we had recently. A radical solution would be: branch rawhide, not
> > from
> > rawhide. So, at the "F40 branch point we had last week", we would:
> > - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> > - rename rawhide chroots to f40 in copr
> > - set up new rawhide chroots ("follow [up] fedora branching")
> >
> > In most cases, "forked" packages in copr are misleading - they are
> > in
> > a chroot without having been built against any version of it.
> >
> > copr users would have to hit "rebuild", which should be OK.
>
> I like this idea. Move things that were built for "rawhide" into the
> "fedora-40" chroot, and start Rawhide empty, requiring fresh builds
> of
> things.
> Since there is no equivalent to the mass rebuild in COPR, that would
> also solve the problem of "stale" packages in Rawhide chroots.
I like the idea , instead Fedora 40 have the fork of rawhide build, it
became rawhide that have the fork of Fedora 40 build ...
I realize if build have {?dist} macro is easy if it is 3 or 4 release
old can be deleted .
And if not have {?dist} macro , they have the build date ...
for example
https://download.copr.fedorainfracloud.org/results/sergiomb/SambaAD/fedora-rawhide-x86_64/01177931-samba/
> Fabio
> --
> ___
> 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: Feedback wanted - pruning old rawhide chroots in Copr
On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber wrote:
>
(snip)
>
> I see this somehow connected to the discussion about signing keys that
> we had recently. A radical solution would be: branch rawhide, not from
> rawhide. So, at the "F40 branch point we had last week", we would:
> - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> - rename rawhide chroots to f40 in copr
> - set up new rawhide chroots ("follow [up] fedora branching")
>
> In most cases, "forked" packages in copr are misleading - they are in
> a chroot without having been built against any version of it.
>
> copr users would have to hit "rebuild", which should be OK.
I like this idea. Move things that were built for "rawhide" into the
"fedora-40" chroot, and start Rawhide empty, requiring fresh builds of
things.
Since there is no equivalent to the mass rebuild in COPR, that would
also solve the problem of "stale" packages in Rawhide chroots.
Fabio
--
___
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
Upgrade to Sundials-6.7.0
Hi all. Next release of Sundials is coming in Rawhide in some days. Related dependent packages are: cantera octave bout++ Probably, the following one will be a major release (the 7.0) Best regards. -- --- Antonio Trande Fedora Project https://fedoraproject.org/wiki/User:Sagitter mailto: sagit...@fedoraproject.org GPG key: 0x40FDA7B70789A9CD GPG keys server: https://keys.openpgp.org/ OpenPGP_signature.asc 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: Feedback wanted - pruning old rawhide chroots in Copr
On 18. 02. 24 13:54, Miroslav Suchý wrote: In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never EOLed. We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what will be convenient for you? The problem is described here https://github.com/fedora-copr/copr/issues/2933 tl;dr version is: * when you build into fedora-39 chroot then the chroot is one day declared as EOLed and if you did not act, then the chroot from the project is deleted and we reclaim the storage space. * when you build into rawhide chroot, then we keep last builds. Even if you do not submit to this project anything for years, we still keep this chroot. And such chroots can occupy gigabytes of storage. The problem is that builds in the rawhide can be packaged configs, and they can be still usable despite the fact that no one rebuilds the RPM for years. Or it can be forgotten build that is not even installable in current chroot. We do not know. And testing installability of package regularly will be expensive task. What **you** would find as acceptable policy for pruning rawhide chroots? If a build wasn't done in the copr chroot for long time, I would consider it acceptable to get a notification that my chroot will be purged unless I take an action. I think the EOLed chroots behave similarly, correct? A long time could be defined as a fixed period (e.g. 1 year, 2 years), or by the meaning of rawhide (e.g. when the last build was done when rawhide was the Fedora that goes EOL now, consider this rawhide chroot for purging). Are there other chroots with the same problems? opensuse-tumbleweed, openmandriva-cooker, openmandriva-rolling, mageia-cauldron... -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Feedback wanted - pruning old rawhide chroots in Copr
Am So., 18. Feb. 2024 um 13:54 Uhr schrieb Miroslav Suchý :
>
> In Copr build system, we noticed that Fedora rawhide chroots can became large
> and they stay forever as rawhide is never
> EOLed.
> We plan to work on this soon, but we are not sure what is best approach. I
> want to ask you - the users of Copr - what
> will be convenient for you?
>
> The problem is described here https://github.com/fedora-copr/copr/issues/2933
>
> tl;dr version is:
>
> * when you build into fedora-39 chroot then the chroot is one day declared
> as EOLed and if you did not act, then the
> chroot from the project is deleted and we reclaim the storage space.
>
> * when you build into rawhide chroot, then we keep last builds. Even if you
> do not submit to this project anything for
> years, we still keep this chroot. And such chroots can occupy gigabytes of
> storage.
>
>
> The problem is that builds in the rawhide can be packaged configs, and they
> can be still usable despite the fact that no
> one rebuilds the RPM for years. Or it can be forgotten build that is not even
> installable in current chroot. We do not
> know. And testing installability of package regularly will be expensive task.
>
> What **you** would find as acceptable policy for pruning rawhide chroots?
I see this somehow connected to the discussion about signing keys that
we had recently. A radical solution would be: branch rawhide, not from
rawhide. So, at the "F40 branch point we had last week", we would:
- switch the "alias" rawhide from "meaning f40" to "meaning f41"
- rename rawhide chroots to f40 in copr
- set up new rawhide chroots ("follow [up] fedora branching")
In most cases, "forked" packages in copr are misleading - they are in
a chroot without having been built against any version of it.
copr users would have to hit "rebuild", which should be OK.
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
Feedback wanted - pruning old rawhide chroots in Copr
In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never EOLed. We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what will be convenient for you? The problem is described here https://github.com/fedora-copr/copr/issues/2933 tl;dr version is: * when you build into fedora-39 chroot then the chroot is one day declared as EOLed and if you did not act, then the chroot from the project is deleted and we reclaim the storage space. * when you build into rawhide chroot, then we keep last builds. Even if you do not submit to this project anything for years, we still keep this chroot. And such chroots can occupy gigabytes of storage. The problem is that builds in the rawhide can be packaged configs, and they can be still usable despite the fact that no one rebuilds the RPM for years. Or it can be forgotten build that is not even installable in current chroot. We do not know. And testing installability of package regularly will be expensive task. What **you** would find as acceptable policy for pruning rawhide chroots? -- 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: The semiannual "Transaction failed: Signature verification failed." exercise
On Fri, Feb 16, 2024 at 09:37:25AM -0800, Kevin Fenzi wrote: > On Fri, Feb 16, 2024 at 11:12:07AM +, Zbigniew Jędrzejewski-Szmek wrote: > > In my earlier message I quoted this case: > > > > > [1] From > > > https://github.com/systemd/systemd/actions/runs/7919159325/job/21619276641?pr=31338: > > > > > > Running transaction > > > Importing PGP key 0xA15B79CC: > > > Userid : "Fedora (40) " > > > Fingerprint: 115DF9AEF857853EE8445D0A0727707EA15B79CC > > > From : > > > file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > > The key was successfully imported. > > > > > > Transaction failed: Signature verification failed. > > > PGP check for package "filesystem-3.18-8.fc40.x86_64" > > > (/var/cache/libdnf5/fedora-306b6523e9c8dc02/packages/filesystem-3.18-8.fc40.x86_64.rpm) > > > from > > > repo "fedora" has failed: Import of the key didn't help, wrong key? > > > > /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-rawhide-primary > > points to RPM-GPG-KEY-fedora-40-primary. > > So everythould be fine, no? filesystem-3.18-8.fc40.x86_64 is clearly an F40 > > package, so it should be signed with the RPM-GPG-KEY-fedora-40-primary key. > > Not really no. > > When we branch, the branched release gets all the already signed by > fedora-40 key packages. Rawhide is completely re-signed with the new > fedora-41 key. The dist tag of packages has nothing to do with it. > > So, day X, rawhide is all signed by fedora-40 key. > Day X+1 we branch and get a new rawhide compose and all rawhide is > signed by the fedora-41 key. Oh, OK. So it was a misunderstanding on my side. I thought that since e.g. F41 has a bunch of packages taken from F40 and F39 and earlier, they will be signed by those respective keys. But we resign them, so they are not. (To make this more confusing, on upgraded systems if the package version didn't change, and it doesn't if the package isn't rebuilt, we have the old package signed by the old key, while an "identical" package on a newer install will be signed by a newer key. But that's all OK, once you know about the resigning.) > > 2. How does this even work later on? Wouldn't F40 installations refuse > >packages signed with the F41 key? > > refuse where? dnf/dnf5 use the line in fedora-rawhide.repo that lists > Both keys. I meant that F_40_ installations don't allow the F41 key. (F41/rawhide installations allow both, that is fine.) But now I understand that F40 will get packages signed by the F40 key, and F41/rawhide will get resigned packages. So all is OK. > > 3. If F42 key has already been generated, why isn't it distributed in > >distribution-gpg-keys already, to make it well known and make the > >transition easier in the future? > > It should have been. I am not sure where the process failed. > > I did generate the fedora-42 key. Right. The key is there, and even distribution-gpg-keys package has in on F39. So I think the whole issue can be solved by letting tools use two keys for rawhide. The patch for mkosi was merged [1]. Should we do something similar for mock? [1] https://github.com/systemd/mkosi/commit/f221562c945a48db9384f8521f67b9b02cd71ac1 -- ___ 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 40 compose report: 20240218.n.0 changes
OLD: Fedora-40-20240217.n.0 NEW: Fedora-40-20240218.n.0 = SUMMARY = Added images:3 Dropped images: 2 Added packages: 6 Dropped packages:2 Upgraded packages: 54 Downgraded packages: 0 Size of added packages: 3.97 MiB Size of dropped packages:54.00 KiB Size of upgraded packages: 10.41 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -426.30 KiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-40-20240218.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-40-20240218.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-40-20240218.n.0.iso = DROPPED IMAGES = Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-40-20240217.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-40-20240217.n.0.iso = ADDED PACKAGES = Package: config-kernel-0.3-1.fc40 Summary: An easy way to edit kernel configuration files and templates RPMs:config-kernel Size:275.81 KiB Package: pkcs11test-0~20230418git2cbe462-1.fc40 Summary: PKCS#11 Test Suite RPMs:pkcs11test Size:1.05 MiB Package: rust-app_dirs2-2.5.5-1.fc40 Summary: Put your app's data in the right place on every platform RPMs:rust-app_dirs2+default-devel rust-app_dirs2-devel Size:26.58 KiB Package: rust-num-conv-0.1.0-1.fc40 Summary: Num_conv is a crate to convert between integer types without using as casts RPMs:rust-num-conv+default-devel rust-num-conv-devel Size:22.30 KiB Package: rust-oxipng-9.0.0-1.fc40 Summary: Lossless PNG compression optimizer RPMs:oxipng rust-oxipng+binary-devel rust-oxipng+clap-devel rust-oxipng+crossbeam-channel-devel rust-oxipng+default-devel rust-oxipng+env_logger-devel rust-oxipng+filetime-devel rust-oxipng+freestanding-devel rust-oxipng+image-devel rust-oxipng+parallel-devel rust-oxipng+rayon-devel rust-oxipng+sanity-checks-devel rust-oxipng+zopfli-devel rust-oxipng-devel Size:2.58 MiB Package: rust-sequoia-keystore-backend-0.1.0-1.fc40 Summary: Private key store for Sequoia RPMs:rust-sequoia-keystore-backend+default-devel rust-sequoia-keystore-backend-devel Size:29.29 KiB = DROPPED PACKAGES = Package: perl-Test-Vars-0.015-9.fc39 Summary: Detects unused variables RPMs:perl-Test-Vars Size:26.17 KiB Package: rust-libssh2-sys0.2-0.2.23-3.fc40 Summary: Native bindings to the libssh2 library RPMs:rust-libssh2-sys0.2+default-devel rust-libssh2-sys0.2-devel Size:27.83 KiB = UPGRADED PACKAGES = Package: adwaita-icon-theme-46~beta-1.fc40 Old package: adwaita-icon-theme-46~alpha-2.fc40 Summary: Adwaita icon theme RPMs: adwaita-cursor-theme adwaita-icon-theme adwaita-icon-theme-devel Size: 932.61 KiB Size change: 8.73 KiB Changelog: * Wed Feb 14 2024 David King - 46~beta-1 - Update to 46.beta Package: anope-2.1.2-1.fc40 Old package: anope-2.1.1-3.fc40 Summary: IRC services designed for flexibility and ease of use RPMs: anope anope-gnutls anope-ldap anope-mysql anope-openssl anope-pcre2 anope-sqlite anope-tre Size: 15.47 MiB Size change: 194.62 KiB Changelog: * Sat Feb 17 2024 Robert Scheck 2.1.2-1 - Upgrade to 2.1.2 (#2264678) Package: apvlv-0.5.0-4.fc40 Old package: apvlv-0.5.0-2.fc40 Summary: PDF viewer which behaves like Vim RPMs: apvlv Size: 623.84 KiB Size change: 826 B Changelog: * Fri Jan 19 2024 Fedora Release Engineering - 0.5.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Mon Jan 22 2024 Fedora Release Engineering - 0.5.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild Package: ark-24.01.95-2.fc40 Old package: ark-24.01.95-1.fc40 Summary: Archive manager RPMs: ark ark-libs Size: 6.90 MiB Size change: -5.42 KiB Changelog: * Sat Feb 17 2024 Jan Grulich - 24.01.95-2 - Rebuild (qt6) Package: at-spi2-core-2.51.90-1.fc40 Old package: at-spi2-core-2.51.0-2.fc40 Summary: Protocol definitions and daemon for D-Bus at-spi RPMs: at-spi2-atk at-spi2-atk-devel at-spi2-core at-spi2-core-devel atk atk-devel Size: 7.61 MiB Size change: 1.19 MiB Changelog: * Wed Feb 14 2024 David King - 2.51.90-1 - Update to 2.51.90 Package: bgpq4-1.12-1.fc40 Old package: bgpq4-1.11-4.fc40 Summary: Automate BGP filter generation based on routing database information RPMs: bgpq4 Size: 245.25 KiB Size change: 719 B Changelog: * Sat Feb 17 2024 Robert Scheck 1.12-1 - Upgrade to 1.12 (#2263974) Package: boxes-2.3.0-1.fc40 Old package: boxes-2.2.1-5.fc40 Summary: Command line ASCII boxes unlimited! RPMs: boxes boxes-vim Size
Fedora rawhide compose report: 20240218.n.0 changes
OLD: Fedora-Rawhide-20240217.n.2 NEW: Fedora-Rawhide-20240218.n.0 = SUMMARY = Added images:4 Dropped images: 2 Added packages: 0 Dropped packages:1 Upgraded packages: 12 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:27.83 KiB Size of upgraded packages: 9.54 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -2.75 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20240218.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240218.n.0.iso Image: Budgie live x86_64 Path: Spins/x86_64/iso/Fedora-Budgie-Live-x86_64-Rawhide-20240218.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20240218.n.0.iso = DROPPED IMAGES = Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240217.n.2.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240217.n.2.iso = ADDED PACKAGES = = DROPPED PACKAGES = Package: rust-libssh2-sys0.2-0.2.23-3.fc40 Summary: Native bindings to the libssh2 library RPMs:rust-libssh2-sys0.2+default-devel rust-libssh2-sys0.2-devel Size:27.83 KiB = UPGRADED PACKAGES = Package: anope-2.1.2-1.fc41 Old package: anope-2.1.1-3.fc40 Summary: IRC services designed for flexibility and ease of use RPMs: anope anope-gnutls anope-ldap anope-mysql anope-openssl anope-pcre2 anope-sqlite anope-tre Size: 15.47 MiB Size change: 192.88 KiB Changelog: * Sat Feb 17 2024 Robert Scheck 2.1.2-1 - Upgrade to 2.1.2 (#2264678) Package: apvlv-0.5.0-4.fc41 Old package: apvlv-0.5.0-2.fc40 Summary: PDF viewer which behaves like Vim RPMs: apvlv Size: 623.86 KiB Size change: 842 B Changelog: * Fri Jan 19 2024 Fedora Release Engineering - 0.5.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild * Mon Jan 22 2024 Fedora Release Engineering - 0.5.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild Package: boxes-2.3.0-1.fc41 Old package: boxes-2.2.1-5.fc40 Summary: Command line ASCII boxes unlimited! RPMs: boxes boxes-vim Size: 394.33 KiB Size change: 46.15 KiB Changelog: * Sat Feb 17 2024 Artem Polishchuk - 2.2.1-6 - packit: Update config * Sat Feb 17 2024 Artem Polishchuk - 2.3.0-1 - [packit] 2.3.0 upstream release Package: byobu-6.12-1.fc41 Old package: byobu-5.133-11.fc40 Summary: Light-weight, configurable window manager built upon GNU screen RPMs: byobu Size: 173.88 KiB Size change: 1.53 KiB Changelog: * Sun Feb 18 2024 Filipe Rosset - 6.12-1 - Update byobu to 6.12 Package: cpeditor-7.0.1-2.fc41 Old package: cpeditor-6.10.3-4.fc40 Summary: The Missing Editor for Competitive Programmers RPMs: cpeditor Size: 3.86 MiB Size change: 317.15 KiB Changelog: * Sun Feb 18 2024 Felix Wang - 7.0.1-1 - update to 7.0.1 * Sun Feb 18 2024 Felix Wang - 7.0.1-2 - license correction; remove unneeded source code Package: dgit-11.6-1.fc41 Old package: dgit-11.3-3.fc40 Summary: Integration between git and Debian-style archives RPMs: dgit Size: 199.23 KiB Size change: 954 B Changelog: * Sun Feb 18 2024 Filipe Rosset - 11.6-1 - update dgit to 11.6 fixes rbhz#2246899 Package: golang-bug-serial-1-1.6.2-1.fc41 Old package: golang-bug-serial-1-1.6.1-3.fc40 Summary: Cross-platform serial library for Golang RPMs: golang-bug-serial-1 golang-bug-serial-devel Size: 2.71 MiB Size change: 94.32 KiB Changelog: * Sun Feb 11 2024 Maxwell G - 1.6.1-4 - Rebuild for golang 1.22.0 * Sun Feb 18 2024 Elliott Sales de Andrade - 1.6.2-1 - Update to latest version (#2264655) Package: java-latest-openjdk-portable-1:22.0.0.0.36-0.2.ea.rolling.fc41 Old package: java-latest-openjdk-portable-1:22.0.0.0.32-0.2.ea.rolling.fc40 Summary: OpenJDK 22 Runtime Environment portable edition RPMs: java-latest-openjdk-portable java-latest-openjdk-portable-devel java-latest-openjdk-portable-devel-fastdebug java-latest-openjdk-portable-devel-slowdebug java-latest-openjdk-portable-docs java-latest-openjdk-portable-fastdebug java-latest-openjdk-portable-misc java-latest-openjdk-portable-slowdebug java-latest-openjdk-portable-sources java-latest-openjdk-portable-static-libs java-latest-openjdk-portable-static-libs-fastdebug java-latest-openjdk-portable-static-libs-slowdebug java-latest-openjdk-portable-unstripped Size: 9.51 GiB Size change: -3.37 MiB Changelog: * Fri Feb 16 2024 Jiri Vanek - 1:22.0.0.0.36-1.rolling - updated to 22+36 - tmp comment out of ea exit 17
Re: Help with creating first PR for a package
I created this post based on my own experience: https://dev.to/prinewgirl/a-recipe-made-to-create-your-first-pr-for-the-fedora-project-21be Hope it helps. Em dom., 18 de fev. de 2024 às 05:32, Ondrej Mosnáček escreveu: > On Sun, 18 Feb 2024 at 09:23, Kan-Ru Chen wrote: > > > > Hi, > > > > On Sun, Feb 18, 2024, at 10:52 AM, Loren M. Lang wrote: > > > I've cloned it down and worked on bringing it more up-to-date. Now that > > > I have something passing the test suite, I thought I'd file a PR and > > > start a discussion. I forked the project on Pagure.io, but found that > > > even with my own personal fork, I don't seem to have commit access to > it > > > without being in the Packagers group. Is that standard? I thought the > > > point of the fork was to allow non-packagers to use the PR mechanism as > > > an easy mechanism for sponsors to view proposals. > > > > > > In any case, I decided to through it up on GitHub temporarily so I > could > > > at least create a Remote PR. > > > > > > https://src.fedoraproject.org/rpms/python-cachelib/pull-request/6 > > > > I have recently done this. You need to use fedpkg to clone the > repository then > > it will setup the hook for authentication with FAS. > > > > For example if you have fork at `fork/penguin359/rpms/python-cachelib` > then use > > this command to clone > > > > fedpkg clone -a forks/penguin359/rpms/python-cachelib > > > > then in the cloned repo you can push normally. > > FWIW. it is documented here: > > https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager > -- > ___ > 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: Help with creating first PR for a package
On Sun, 18 Feb 2024 at 09:23, Kan-Ru Chen wrote: > > Hi, > > On Sun, Feb 18, 2024, at 10:52 AM, Loren M. Lang wrote: > > I've cloned it down and worked on bringing it more up-to-date. Now that > > I have something passing the test suite, I thought I'd file a PR and > > start a discussion. I forked the project on Pagure.io, but found that > > even with my own personal fork, I don't seem to have commit access to it > > without being in the Packagers group. Is that standard? I thought the > > point of the fork was to allow non-packagers to use the PR mechanism as > > an easy mechanism for sponsors to view proposals. > > > > In any case, I decided to through it up on GitHub temporarily so I could > > at least create a Remote PR. > > > > https://src.fedoraproject.org/rpms/python-cachelib/pull-request/6 > > I have recently done this. You need to use fedpkg to clone the repository then > it will setup the hook for authentication with FAS. > > For example if you have fork at `fork/penguin359/rpms/python-cachelib` then > use > this command to clone > > fedpkg clone -a forks/penguin359/rpms/python-cachelib > > then in the cloned repo you can push normally. FWIW. it is documented here: https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Help with creating first PR for a package
Hi, On Sun, Feb 18, 2024, at 10:52 AM, Loren M. Lang wrote: > I've cloned it down and worked on bringing it more up-to-date. Now that > I have something passing the test suite, I thought I'd file a PR and > start a discussion. I forked the project on Pagure.io, but found that > even with my own personal fork, I don't seem to have commit access to it > without being in the Packagers group. Is that standard? I thought the > point of the fork was to allow non-packagers to use the PR mechanism as > an easy mechanism for sponsors to view proposals. > > In any case, I decided to through it up on GitHub temporarily so I could > at least create a Remote PR. > > https://src.fedoraproject.org/rpms/python-cachelib/pull-request/6 I have recently done this. You need to use fedpkg to clone the repository then it will setup the hook for authentication with FAS. For example if you have fork at `fork/penguin359/rpms/python-cachelib` then use this command to clone fedpkg clone -a forks/penguin359/rpms/python-cachelib then in the cloned repo you can push normally. Cheers, Kan-Ru -- ___ 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
