[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-de51ed6706 drupal7-uuid-1.3-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d5dca753d6 GraphicsMagick-1.3.32-1.el6 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-12f1eb1b1f tomcat-7.0.94-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing cc1541-2.0-1.el6 php-phpseclib-2.0.19-1.el6 qpid-dispatch-1.8.0-1.el6 Details about builds: cc1541-2.0-1.el6 (FEDORA-EPEL-2019-ec0e554811) Tool for creating Commodore 1541 Floppy disk images in D64, G64 or D71 format Update Information: - Initial rpm release. References: [ 1 ] Bug #1722942 - Review Request: cc1541 - Tool for creating Commodore 1541 Floppy disk images in D64, G64 or D71 format https://bugzilla.redhat.com/show_bug.cgi?id=1722942 php-phpseclib-2.0.19-1.el6 (FEDORA-EPEL-2019-b4b6b0c984) PHP Secure Communications Library Update Information: **Version 2.0.19** - 2019-06-20 - BigInteger: fix issues with divide method **Version 2.0.18** - 2019-06-13 - SSH2: close channel when a timeout occurs (#1378) - SFTP: improve handling of malformed packets (#1371) - RSA: add support for OpenSSH private keys (#1372) ChangeLog: * Fri Jun 21 2019 Remi Collet - 2.0.19-1 - update to 2.0.19 - add patch for PHP 5.3 from https://github.com/phpseclib/phpseclib/pull/1382 * Thu Jun 13 2019 Remi Collet - 2.0.18-1 - update to 2.0.18 qpid-dispatch-1.8.0-1.el6 (FEDORA-EPEL-2019-be016a7515) Dispatch router for Qpid Update Information: Rebased to 1.8.0. ChangeLog: * Thu Jun 20 2019 Irina Boverman - 1.8.0-1 - Rebased to 1.8.0 ___ 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
[Bug 1718806] Upgrade perl-Cookie-Baker to 0.11
https://bugzilla.redhat.com/show_bug.cgi?id=1718806 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Cookie-Baker-0.11-1.fc |perl-Cookie-Baker-0.11-1.fc |30 |30 ||perl-Cookie-Baker-0.11-1.fc ||29 --- Comment #5 from Fedora Update System --- perl-Cookie-Baker-0.11-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722667] perl-CPAN-Perl-Releases-4.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722667 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-CPAN-Perl-Releases-4.08-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e8bad3225c -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722669] perl-Module-CoreList-5.20190620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722669 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System --- perl-Module-CoreList-5.20190620-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d9c631c42 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1721471] Upgrade perl-Test-Taint to 1.08
https://bugzilla.redhat.com/show_bug.cgi?id=1721471 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System --- perl-Test-Taint-1.08-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fe56ef11e6 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 311 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 119 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f8311ec8a2 tor-0.3.5.8-1.el7 86 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-d2c1368294 cinnamon-3.6.7-5.el7 79 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-50a6a1ddfd afflib-3.7.18-2.el7 52 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 50 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 22 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fc63c75ab1 hostapd-2.8-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-24edff97c6 php-brumann-polyfill-unserialize-1.0.3-1.el7 php-typo3-phar-stream-wrapper2-2.1.2-1.el7 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f428efb17c drupal7-uuid-1.3-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-193cafec2e GraphicsMagick-1.3.32-1.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-7a3942050d nodejs-6.17.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing beakerlib-libraries-0.4-2.el7 cc1541-2.0-1.el7 certbot-0.35.1-1.el7 dahdi-tools-2.11.1-13.el7 pdns-4.1.10-1.el7 php-phpseclib-2.0.19-1.el7 python-acme-0.35.1-1.el7 python-certbot-apache-0.35.1-1.el7 python-certbot-dns-cloudflare-0.35.1-1.el7 python-certbot-dns-cloudxns-0.35.1-1.el7 python-certbot-dns-digitalocean-0.35.1-1.el7 python-certbot-dns-dnsimple-0.35.1-1.el7 python-certbot-dns-dnsmadeeasy-0.35.1-1.el7 python-certbot-dns-gehirn-0.35.1-1.el7 python-certbot-dns-google-0.35.1-1.el7 python-certbot-dns-linode-0.35.1-1.el7 python-certbot-dns-luadns-0.35.1-1.el7 python-certbot-dns-nsone-0.35.1-1.el7 python-certbot-dns-ovh-0.35.1-1.el7 python-certbot-dns-rfc2136-0.35.1-1.el7 python-certbot-dns-route53-0.35.1-1.el7 python-certbot-dns-sakuracloud-0.35.1-1.el7 python-certbot-nginx-0.35.1-1.el7 python-neovim-0.3.2-1.el7 python3-lxml-4.2.5-3.el7 qpid-dispatch-1.8.0-1.el7 Details about builds: beakerlib-libraries-0.4-2.el7 (FEDORA-EPEL-2019-d441cc2e61) Beakerlib libraries Update Information: Change .spec ChangeLog: * Thu Jun 20 2019 Andrei Stepanov - 0.4-2 - Build with AutoReq: no * Fri Mar 22 2019 Andrei Stepanov - 0.4-1 - Build with the latest merged PRs. * Thu Jan 31 2019 Fedora Release Engineering - 0.3-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild cc1541-2.0-1.el7 (FEDORA-EPEL-2019-61698b2fae) Tool for creating Commodore 1541 Floppy disk images in D64, G64 or D71 format Update Information: - Initial rpm release. References: [ 1 ] Bug #1722942 - Review Request: cc1541 - Tool for creating Commodore 1541 Floppy disk images in D64, G64 or D71 format https://bugzilla.redhat.com/show_bug.cgi?id=1722942 certbot-0.35.1-1.el7 (FEDORA-EPEL-2019-9fc680cc02) A free, automated certificate authority client Update Information: Update to 0.35.1. ChangeLog: * Fri Jun 21 2019 Eli Young - 0.35.1-1 - Update to 0.35.1 (#1717677) References: [ 1 ] Bug #1717677 - certbot-0.35.1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1717677 dahdi-tools-2.11.1-13.el7 (FEDORA-EPEL-2019-6f1f17fce3) Userspace tools to configure the DAHDI kernel modules Update Information: Perl 5.30 rebuild pdns-4.1.10-1.el7
[Bug 1716020] perl-podlators-4.12 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1716020 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-podlators-4.12-1.fc31 |perl-podlators-4.12-1.fc31 |perl-podlators-4.12-1.fc29 |perl-podlators-4.12-1.fc29 ||perl-podlators-4.12-1.fc30 --- Comment #7 from Fedora Update System --- perl-podlators-4.12-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1718806] Upgrade perl-Cookie-Baker to 0.11
https://bugzilla.redhat.com/show_bug.cgi?id=1718806 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Cookie-Baker-0.11-1.fc ||30 Resolution|--- |ERRATA Last Closed||2019-06-22 01:02:48 --- Comment #4 from Fedora Update System --- perl-Cookie-Baker-0.11-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
Re: HEADS UP: DynamicBuildRequires are available
> "MC" == Michael Cronenworth writes: MC> Yes, something would have to be invented, and I guess that's why no MC> one replied. Well I replied, bit I'm behind on email so... MC> However, the data exists it is just not available in a standard, MC> parsable format. And that was really my question: what data exists and what format is it in? Honestly, I don't know; that's why I'm asking. There's a lot that could be done, and it doesn't have to be perfect. (Certainly it's better if it misses things because you can always just add them as regular BuildRequires:, but it's tougher to deal with things added erroneously.) This can easily be offloaded to a separate tool; RPM only cares about the output. - J< ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
On 6/21/19 6:32 PM, Jason L Tibbitts III wrote: Well, how do those list build dependencies? How would you extract them and convert them to package names (or something else which is provided by the target packages)? Yes, something would have to be invented, and I guess that's why no one replied. However, the data exists it is just not available in a standard, parsable format. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: HEADS UP: DynamicBuildRequires are available
> "MC" == Michael Cronenworth writes: MC> Any long term plans to support C/C++ apps? Depends on what you mean by "support", really. Really there's just a new spec section that gets run and it just needs to echo a list of build dependencies. That's really all this does; the existing Rust support just hides the script within %cargo_generate_buildrequires. (Honestly I'm disappointed that the macro doesn't emit the %generate_buildrequires line as well; the pattern used by Rust currently builds in the assumption that the generator will be a shell script.) If there are more general methods for extracting build dependencies from various build systems which can be stuffed into macros, then by all means we should be adding them. MC> I know those are all over the map with regards to build tools, but MC> maybe cmake/meson could be supported? Well, how do those list build dependencies? How would you extract them and convert them to package names (or something else which is provided by the target packages)? - J< ___ 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
[389-devel] please review: PR 50463 - Fix CI tests
https://pagure.io/389-ds-base/pull-request/50463 ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
[Test-Announce] Proposal to CANCEL: 2019-06-24 Fedora QA Meeting
Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't have anything urgent for the agenda. If you're aware of anything important we have to discuss this week, please do reply to this mail and we can go ahead and run the meeting. Thanks, everyone! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ 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
Reminder: upcoming F31 Change deadlines
If you have a Change proposal that requires changes to Infrastructure, those proposals must be submitted (i.e. in ChangeReadyForWrangler category) by 26 June. Other deadlines approaching: * 2019-07-02 — Changes requiring mass rebuild * 2019-07-02 — System-Wide changes * 2019-07-23 — Self-contained changes For more development milestones in the F31 schedule, see: https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Reminder: upcoming F31 Change deadlines
If you have a Change proposal that requires changes to Infrastructure, those proposals must be submitted (i.e. in ChangeReadyForWrangler category) by 26 June. Other deadlines approaching: * 2019-07-02 — Changes requiring mass rebuild * 2019-07-02 — System-Wide changes * 2019-07-23 — Self-contained changes For more development milestones in the F31 schedule, see: https://fedorapeople.org/groups/schedule/f-31/f-31-devel-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ 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
Fedora 31 System-Wide Change proposal: No More i686 Kernels
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.
== Owner ==
* Name: [[User:jforbes| Justin Forbes]]
* Email: jfor...@fedoraproject.org
== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing,
and issues frequently appear upstream. These tend to go unnoticed for
long periods of time. When issues are found, it is often a long time
before they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel.
With this proposal, the i686 kernel will no longer be built. A kernel
headers package will still exist, and all 32bit packages should
continue to build as normal. The main difference is there would no
longer be bootable 32bit images.
This was last proposed with Fedora 27, but it was deferred as an i686
SIG was to be created to handle issues going forward. That SIG has
been largely unresponsive. The only thread so far this year has been
a thread starting with "Hello, I noticed that the x86 group hasn't had
any reports in a while. As the absentee sponsor of the group, I would
like to remind people on the list and interested in keeping x86_32 in
Fedora releases that there is general work which needs to be done by
people interested. " And the only response was one person saying they
would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
More testable kernel updates, faster fixes for security bugs, and
lowered exposure.
== Scope ==
* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461]
**
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: Drop i686 based images
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test ==
N/A Nothing to test, we simply stop producing a flavor of the kernel
package. As there is no direct upgrade path from i686 -> x86_64, users
with capable hardware will have to reinstall.
== User Experience ==
The few 32bit users will have the full lifecycle of Fedora 30 to
choose a time to upgrade to a 64bit installation. Some old hardware
will no longer be supported by fedora.
== Dependencies ==
32 bit x86 images can no longer be built.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
* Contingency deadline: As QA requires for image candidates
* Blocks release? Yes
* Blocks product? product Fedora 31
== Documentation ==
The lack of an i686 image will need to be documented.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: The GNU C Library version 2.30
https://fedoraproject.org/wiki/Changes/GLIBC230 == Summary == Switch glibc in Fedora 31 to glibc version 2.30. == Owner == * Name: [[User:fweimer|Florian Weimer]] * Email: fwei...@redhat.com == Detailed Description == The GNU C Library version 2.30 will be released at the beginning of August 2019; we have started closely tracking the glibc 2.30 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 31 will branch after the GLIBC 2.30 upstream release. However, the mass rebuild schedule means Fedora 31 will mass rebuild (if required) after GLIBC 2.30 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes. == Benefit to Fedora == Stays up to date with latest security and bug fixes from glibc upstream. == Scope == * Proposal owners: Update glibc to 2.30. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 31 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. * Release engineering: [https://pagure.io/releng/issue/8462 #8462] * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change == Upgrade/compatibility impact == The library is backwards compatible with the version of glibc that was shipped in Fedora 29. Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.30#Packaging_Changes We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.30. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 5900+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.30 NEWS update will include more details. == Dependencies == All packages do not need to be rebuilt. == Contingency Plan == * Contingency mechanism: Given that Rawhide has started tracking glibc 2.30, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.29 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream ABI freeze deadline of 2019-07-01. * Blocks release? Upgrading glibc does block the release. We should not ship without a newer glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations. == Documentation == == Release Notes == * Release Notes tracking: The GNU C Library version 2.30 will be released at the beginning of August 2019. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Fedora 31 System-Wide Change proposal: No More i686 Kernels
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
everything else.
== Owner ==
* Name: [[User:jforbes| Justin Forbes]]
* Email: jfor...@fedoraproject.org
== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing,
and issues frequently appear upstream. These tend to go unnoticed for
long periods of time. When issues are found, it is often a long time
before they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel.
With this proposal, the i686 kernel will no longer be built. A kernel
headers package will still exist, and all 32bit packages should
continue to build as normal. The main difference is there would no
longer be bootable 32bit images.
This was last proposed with Fedora 27, but it was deferred as an i686
SIG was to be created to handle issues going forward. That SIG has
been largely unresponsive. The only thread so far this year has been
a thread starting with "Hello, I noticed that the x86 group hasn't had
any reports in a while. As the absentee sponsor of the group, I would
like to remind people on the list and interested in keeping x86_32 in
Fedora releases that there is general work which needs to be done by
people interested. " And the only response was one person saying they
would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
More testable kernel updates, faster fixes for security bugs, and
lowered exposure.
== Scope ==
* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461]
**
[[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: Drop i686 based images
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test ==
N/A Nothing to test, we simply stop producing a flavor of the kernel
package. As there is no direct upgrade path from i686 -> x86_64, users
with capable hardware will have to reinstall.
== User Experience ==
The few 32bit users will have the full lifecycle of Fedora 30 to
choose a time to upgrade to a 64bit installation. Some old hardware
will no longer be supported by fedora.
== Dependencies ==
32 bit x86 images can no longer be built.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
* Contingency deadline: As QA requires for image candidates
* Blocks release? Yes
* Blocks product? product Fedora 31
== Documentation ==
The lack of an i686 image will need to be documented.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
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
Fedora 31 System-Wide Change proposal: The GNU C Library version 2.30
https://fedoraproject.org/wiki/Changes/GLIBC230 == Summary == Switch glibc in Fedora 31 to glibc version 2.30. == Owner == * Name: [[User:fweimer|Florian Weimer]] * Email: fwei...@redhat.com == Detailed Description == The GNU C Library version 2.30 will be released at the beginning of August 2019; we have started closely tracking the glibc 2.30 development code in Fedora Rawhide and are addressing any issues as they arise. Given the present schedule Fedora 31 will branch after the GLIBC 2.30 upstream release. However, the mass rebuild schedule means Fedora 31 will mass rebuild (if required) after GLIBC 2.30 upstream freezes ABI for release, but before the actual release, so careful attention must be paid to any last minute ABI changes. == Benefit to Fedora == Stays up to date with latest security and bug fixes from glibc upstream. == Scope == * Proposal owners: Update glibc to 2.30. * Other developers: Developers need to ensure that rawhide is stable and ready for the Fedora 31 branch. Given that glibc is backwards compatible and we have been testing the new glibc in rawhide it should make very little impact when updated, except for the occasional deprecation warnings and removal of legacy interfaces from public header files. * Release engineering: [https://pagure.io/releng/issue/8462 #8462] * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: Not needed for this change == Upgrade/compatibility impact == The library is backwards compatible with the version of glibc that was shipped in Fedora 29. Some packaging changes required, see: https://sourceware.org/glibc/wiki/Release/2.30#Packaging_Changes We fully expect to fix all packaging changes in Fedora Rawhide given that glibc in Rawhide is tracking what will become glibc 2.30. == How To Test == The GNU C Library has its own testsuite, which is run during the package build and examined by the glibc developers before being uploaded. This test suite has 5900+ tests that run to verify the correct operation of the library. In the future we'll also be running the microbenchmark to look for performance regressions as well as behavioural ones. == User Experience == Users will see improved performance, many bugfixes and improvements to POSIX compliance, additional locales, etc. The glibc 2.30 NEWS update will include more details. == Dependencies == All packages do not need to be rebuilt. == Contingency Plan == * Contingency mechanism: Given that Rawhide has started tracking glibc 2.30, no show-stopper problems are expected. At this point, we can still revert to upstream version 2.29 if insurmountable problems appear, but to do so may require a mass rebuild to remove new symbols from the ABI/API. * Contingency deadline: Upstream ABI freeze deadline of 2019-07-01. * Blocks release? Upgrading glibc does block the release. We should not ship without a newer glibc, there will be gcc and language features that depend on glibc being upgraded. Thus without the upgrade some features will be disabled or fall back to less optimal implementations. == Documentation == == Release Notes == * Release Notes tracking: The GNU C Library version 2.30 will be released at the beginning of August 2019. The current NEWS notes can be seen here as they are added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ABRT CLI rework
On Fri, Jun 21, 2019 at 9:47 AM Adam Williamson wrote: > > On Fri, 2019-06-21 at 13:39 +0200, Ernestas Kulik wrote: > > Hi, > > > > As we are all well aware, ABRT has two CLI tools (abrt-cli, from > > abrt-tui and abrt, from abrt-cli-ng). > > Are we? I wasn't... I only ever use abrt-cli. I don't even have abrt on Fedora Workstation (or Server). This is a lot of abrt stuff... abrt-java-connector-1.1.1-2.fc29.x86_64 abrt-cli-2.12.0-2.fc30.x86_64 abrt-addon-kerneloops-2.12.0-2.fc30.x86_64 abrt-desktop-2.12.0-2.fc30.x86_64 abrt-dbus-2.12.0-2.fc30.x86_64 gnome-abrt-1.2.7-2.fc30.x86_64 abrt-addon-vmcore-2.12.0-2.fc30.x86_64 abrt-gui-libs-2.12.0-2.fc30.x86_64 abrt-tui-2.12.0-2.fc30.x86_64 python3-abrt-addon-2.12.0-2.fc30.x86_64 abrt-plugin-bodhi-2.12.0-2.fc30.x86_64 abrt-addon-pstoreoops-2.12.0-2.fc30.x86_64 python3-abrt-2.12.0-2.fc30.x86_64 abrt-addon-xorg-2.12.0-2.fc30.x86_64 abrt-libs-2.12.0-2.fc30.x86_64 abrt-retrace-client-2.12.0-2.fc30.x86_64 abrt-gui-2.12.0-2.fc30.x86_64 abrt-2.12.0-2.fc30.x86_64 abrt-addon-ccpp-2.12.0-2.fc30.x86_64 abrt-addon-coredump-helper-2.12.0-2.fc30.x86_64 -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity vs. libgit
On Fri, Jun 21, 2019 at 5:47 PM Adam Williamson wrote: > On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote: > > To keep the expectations of Fedora's stable ABI within a release, we > can't > > change the default stream of a module mind-release. I know, that's > probably > > clear and that's not the issue here. But building on that, at the same > > time, we can't let "dnf update" to change streams on your system > > mid-release, because that would be basically breaking the ABI > expectations > > as well — different mechanics, same problem. > > OK, so, this is one I've been sitting on for a while with this. The > "within a release" thing keeps coming up here. But did you sufficiently > consider the fact that Rawhide is "a release", and needs to change like > this? If your position is "we can't change the default stream of a > module mid-release", that implies "...but we can change it between > releases". But how is a 'between releases' change ever going to happen > if it doesn't happen in Rawhide first...which is technically "mid- > release"? > > AFAICS even if as a matter of policy something shouldn't be done within > a stable release, anything that can be done between releases needs to > be *technically* possible 'within a release' (i.e. within Rawhide), or > else we can't possibly do development properly, no? > Very good point! Yes, we definitely need a mechanism to potentially change streams between releases. This is to make it the same as when major software versions change during a distribution upgrade. Even though Modularity respects your choices of a specific stream, it also need to respect your choices not to make a choice (if that makes sense). Basically, when you install a package the way you'd always do by "dnf install package" and it happens to be in a default module stream, that stream gets automatically enabled and the package installed. But what happens when there is a new major Fedora release with a different default stream of that package? Without Modularity, your package would get upgraded to the new version automatically when performing the system upgrade. We need to keep the same behaviour with Modularity as well. So the stream needs to be switched automatically during the upgrade. A very different story of course would be you choosing a specific module stream by "dnf module enable module:stream" and then installing the package from it. In that case, the stream should not be switched because you've made an explicit choice. And to be clear, we don't have an existing mechanism for that — but we have discussed it extensively [0] and I have documented a specific proposal [1] based on those discussions for that behaviour, discussed that with the DNF team, and opened a bug [2] based on what we agreed on. However, there was no progress on it. To your second point about rawhide, yes, you're absolutely right. The way we think will be the best to deal with rawhide was to treat it as a special case, and use a similar mechanism to the one mentioned above to — unless you chose a specific stream explicitly — keep you on the default stream with every dnf update, even if it means switching streams. And there are probably other aspects to take into account before making this a reality. But again, not much progress there... [0] https://pagure.io/modularity/issue/108 [1] https://pagure.io/modularity/working-documents/blob/master/f/lifecycles-upgrades-ownership/upgrades-and-modules.md [2] https://bugzilla.redhat.com/show_bug.cgi?id=1664427 > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > 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 > -- Adam Šamalík --- Senior Software Engineer 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
Summary/Minutes from today's FESCo Meeting (2019-06-21)
=== #fedora-meeting: FESCO (2019-06-21) === Meeting started by jforbes at 15:00:42 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2019-06-21/fesco.2019-06-21-15.00.log.html . Meeting summary --- * init process (jforbes, 15:00:42) * #2133 F31 System-Wide Change: Disable Root Password Login in SSH (jforbes, 15:05:16) * LINK: https://pagure.io/fesco/issue/2133 (jforbes, 15:05:17) * AGREED: 31 System-Wide Change: Disable Root Password Login in SSH is approved (+6,0,0) (jforbes, 15:18:14) * #2149 Proposal to change non-responsive maintainer policy (jforbes, 15:19:19) * LINK: https://pagure.io/fesco/issue/2149 (jforbes, 15:19:19) * AGREED: The proposal to change non-responsive maintainer policy is deferred while wording is fine tuned and it is discussed on devel list (jforbes, 15:24:09) * ACTION: ignatenkobrain to start a thread on the non-responsive maintainer policy (jforbes, 15:24:28) * #2151 F31 Self-Contained Change: Include several modules in the EFI build of Grub2 for security use-cases (jforbes, 15:24:52) * LINK: https://pagure.io/fesco/issue/2151 (jforbes, 15:24:53) * AGREED: 31 Self-Contained Change: Include several modules in the EFI build of Grub2 for security use-cases is approved (+6,1,-0) (jforbes, 15:34:22) * #2152 "backport" branches in src.fp.o for backports to coreos stable streams (jforbes, 15:34:54) * LINK: https://pagure.io/fesco/issue/2152 (jforbes, 15:34:54) * ACTION: mhroncok to draft some more ideas next week, will put everything in the ticket (mostly based on what was said here) (mhroncok, 15:50:49) * AGREED: voting on backport branches is deferred and will be further discussed in ticket (jforbes, 15:51:52) * Next week's chair (jforbes, 15:52:09) * ACTION: contyk will chair next meeting (jforbes, 15:53:37) * Open Floor (jforbes, 15:53:43) * LINK: https://docs.fedoraproject.org/en-US/fesco/Updating_Fedora_Engineering_Steering_Committee_Members/ (mhroncok, 15:55:33) * LINK: https://pagure.io/flock/issue/192 (jforbes, 15:57:05) * ACTION: ignatenkobrain to open FESCo Panel ticket for Flock (ignatenkobrain, 16:05:40) * AGREED: the FPgM is authorized to update membership of FESCo mailing lists, Pagure groups, etc. (+5,0,-0) (jforbes, 16:07:12) Meeting ended at 16:07:43 UTC. Action Items * ignatenkobrain to start a thread on the non-responsive maintainer policy * mhroncok to draft some more ideas next week, will put everything in the ticket (mostly based on what was said here) * contyk will chair next meeting * ignatenkobrain to open FESCo Panel ticket for Flock Action Items, by person --- * contyk * contyk will chair next meeting * ignatenkobrain * ignatenkobrain to start a thread on the non-responsive maintainer policy * ignatenkobrain to open FESCo Panel ticket for Flock * mhroncok * mhroncok to draft some more ideas next week, will put everything in the ticket (mostly based on what was said here) * **UNASSIGNED** * (none) People Present (lines said) --- * jforbes (65) * mhroncok (41) * nirik (24) * dustymabe (23) * ignatenkobrain (21) * zodbot (21) * bcotton (17) * contyk (17) * bookwar (15) * bgilbert (11) * otaylor (11) * sgallagh (0) * bowlofeggs (0) * zbyszek (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: ABRT CLI rework
On Fri, 2019-06-21 at 13:39 +0200, Ernestas Kulik wrote: > Hi, > > As we are all well aware, ABRT has two CLI tools (abrt-cli, from > abrt-tui and abrt, from abrt-cli-ng). Are we? I wasn't... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity vs. libgit
On Fri, 2019-06-21 at 13:28 +0200, Adam Samalik wrote: > To keep the expectations of Fedora's stable ABI within a release, we can't > change the default stream of a module mind-release. I know, that's probably > clear and that's not the issue here. But building on that, at the same > time, we can't let "dnf update" to change streams on your system > mid-release, because that would be basically breaking the ABI expectations > as well — different mechanics, same problem. OK, so, this is one I've been sitting on for a while with this. The "within a release" thing keeps coming up here. But did you sufficiently consider the fact that Rawhide is "a release", and needs to change like this? If your position is "we can't change the default stream of a module mid-release", that implies "...but we can change it between releases". But how is a 'between releases' change ever going to happen if it doesn't happen in Rawhide first...which is technically "mid- release"? AFAICS even if as a matter of policy something shouldn't be done within a stable release, anything that can be done between releases needs to be *technically* possible 'within a release' (i.e. within Rawhide), or else we can't possibly do development properly, no? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ 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
Fedora 30 FESCo Elections Results
Greetings, all! The elections for FESCo election for Fedora 30 have concluded, and the results are shown below. FESCo is electing 4 seats this time. A total of 205 ballots were cast, meaning a candidate could accumulate up to 1230 votes (205 * 6). The results for the elections are as follows: # votes | name - +-- 695 | Stephen Gallagher 687 | Igor Gnatenko 615 | Aleksandra Fedorova 569 | Petr Šabata - +-- 525 | Jeremy Cline 444 | Fabio Valentini Congratulations to the winning candidates, and thank you all candidates for running this elections! Full election results for all three elections are posted to the Fedora Community Blog[1] [1] https://communityblog.fedoraproject.org/fedora-30-elections-results/ -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org ___ 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
ABRT CLI rework
Hi, As we are all well aware, ABRT has two CLI tools (abrt-cli, from abrt-tui and abrt, from abrt-cli-ng). For a long while now, we in the team have been pondering doing something that would result in only one surviving. In that vein, I would like to invite you to share your gripes, use cases, wishes as comments on https://github.com/abrt/abrt/issues/1394, as new issues or otherwise. Some topic suggestions: - Language choice (Python-less environments? Preference for NIH to have minimal dependencies?) - Package separation (bundle with ABRT / as a subpackage / as a separate package/project) - Command compatibility for whatever automation there may be - bash completions (abrt-cli-ng uses argcomplete, but it doesn’t work on zsh for me OOTB) - pls fix - Something something containers -- Ernestas Kulik Associate Software Engineer - Base Operating Systems (Core Services/ABRT) 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
Re: Modularity vs. libgit
On Fri, Jun 21, 2019 at 1:28 PM Adam Samalik wrote: > > > On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote: >> > Hello, >> > >> > I just wanted to give you an update from my last discussions on >> > #fedora-modularity and other places. >> > >> > # Problems definition >> > >> > * Default modules can't have conflicting dependenices >> > * Changing dependencies in a stream is not supported >> > >> > # Why does libgit2 has to be a module? >> > >> > libgit2 is not just one package. It is an ecosystem. >> > >> > Right now libgit2 module provides libgit2 itself and python bindings. >> > While we can obviously provide libgit2_0.26, libgit2_0.27 and such, >> > this does not help us with python packages. Nobody in sane mind will >> rename them >> > and make them conflict (because they are not parallel-installable). >> > >> > I wanted to also add ruby bindings to a module, but I never got time >> > to actually do it. >> > >> > # What about dependencies change? >> > >> > Let's not lock ourselves into libgit2 story, just take an abstract >> names. >> > >> > Module foo:rolling depends on bar:1. Name of stream "rolling" means to >> serve >> > purpose of "user-focused content meant for general use". That means, >> > if foo's upstream decided to update their bar dependency to a new >> version, >> > foo:rolling maintainer would just switch dependency to bar:2. >> >> AIUI, the issue here is that *there should not be* bar:1 and bar:2. >> Module streams are supposed to be 'functional' (as in your 'rolling' >> example). They are not supposed to be version numbers. This needs to be >> more clearly explained in the guidelines and enforced, but the way the >> modularity concept turned out, version-based module streams are *wrong* >> and should not exist. I recall earlier designs along the way actually >> sort of envisaged version-based module streams, but that is not how >> it's supposed to work in the final design. >> > > Versioned module streams should definitely exist, that's one of the main > points of Modularity. But there are certainly exceptions. > > To keep the expectations of Fedora's stable ABI within a release, we can't > change the default stream of a module mind-release. I know, that's probably > clear and that's not the issue here. But building on that, at the same > time, we can't let "dnf update" to change streams on your system > mid-release, because that would be basically breaking the ABI expectations > as well — different mechanics, same problem. > > So in this specific example — where upstream is changing the ABI very > often — freezing that package to one major version per Fedora release > doesn't work. Especially when different packages need a different version > at the same time. So streams are probably not the right way to deal with > this specific case. Streams are a great way to provide our users a choice. > A choice of one of multiple versions of software (mostly leaf applications) > that are natively built and maintained for their fedora release (as opposed > to enabling rawhide repos and I don't know what to get a different > version). But it's not a solution for providing multiple versions of > libraries that need to be installed at the same time. > > When different packages require different version of a library at the same > time, we can definitely use existing mechanisms for parallel installation > such as providing different packages with different names, installing the > library into different places, like compat-packages. > > What Modularity could help you with — in an arbitrary case when there is > bar:1 and bar:2 — is to build your "rolling" module (and other modules) > against both of those using stream expansion, providing two different > binaries of the same module stream (with different context), and letting > DNF to install the right one based on what is on your system, or based on > defaults. This is one of the new capabilities Modularity brings to the > table. Of course, that only works if your "rolling" module can be actually > built against both. > > But for cases when your "rolling" module can't be built against both > versions, existing mechanisms for parallel installation should be used > instead. Modularity doesn't reimplement those existing mechanisms. > > To be fair, I don't think our docs say this in this form anywhere. There are probably hints that could draw the potential reader to this conclusion, but we probably need to be more explicit than that — by providing specific guidance for some model cases, demonstrating where Modularity can help (and how) and where it can't. I (or anyone) should probably fix that! > > > > >> -- >> Adam Williamson >> Fedora QA Community Monkey >> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net >> http://www.happyassassin.net >> ___ >> devel mailing list --
Re: Modularity vs. libgit
On Fri, Jun 21, 2019 at 12:08 AM Adam Williamson wrote: > On Thu, 2019-06-20 at 23:48 +0200, Igor Gnatenko wrote: > > Hello, > > > > I just wanted to give you an update from my last discussions on > > #fedora-modularity and other places. > > > > # Problems definition > > > > * Default modules can't have conflicting dependenices > > * Changing dependencies in a stream is not supported > > > > # Why does libgit2 has to be a module? > > > > libgit2 is not just one package. It is an ecosystem. > > > > Right now libgit2 module provides libgit2 itself and python bindings. > > While we can obviously provide libgit2_0.26, libgit2_0.27 and such, > > this does not help us with python packages. Nobody in sane mind will > rename them > > and make them conflict (because they are not parallel-installable). > > > > I wanted to also add ruby bindings to a module, but I never got time > > to actually do it. > > > > # What about dependencies change? > > > > Let's not lock ourselves into libgit2 story, just take an abstract names. > > > > Module foo:rolling depends on bar:1. Name of stream "rolling" means to > serve > > purpose of "user-focused content meant for general use". That means, > > if foo's upstream decided to update their bar dependency to a new > version, > > foo:rolling maintainer would just switch dependency to bar:2. > > AIUI, the issue here is that *there should not be* bar:1 and bar:2. > Module streams are supposed to be 'functional' (as in your 'rolling' > example). They are not supposed to be version numbers. This needs to be > more clearly explained in the guidelines and enforced, but the way the > modularity concept turned out, version-based module streams are *wrong* > and should not exist. I recall earlier designs along the way actually > sort of envisaged version-based module streams, but that is not how > it's supposed to work in the final design. > Versioned module streams should definitely exist, that's one of the main points of Modularity. But there are certainly exceptions. To keep the expectations of Fedora's stable ABI within a release, we can't change the default stream of a module mind-release. I know, that's probably clear and that's not the issue here. But building on that, at the same time, we can't let "dnf update" to change streams on your system mid-release, because that would be basically breaking the ABI expectations as well — different mechanics, same problem. So in this specific example — where upstream is changing the ABI very often — freezing that package to one major version per Fedora release doesn't work. Especially when different packages need a different version at the same time. So streams are probably not the right way to deal with this specific case. Streams are a great way to provide our users a choice. A choice of one of multiple versions of software (mostly leaf applications) that are natively built and maintained for their fedora release (as opposed to enabling rawhide repos and I don't know what to get a different version). But it's not a solution for providing multiple versions of libraries that need to be installed at the same time. When different packages require different version of a library at the same time, we can definitely use existing mechanisms for parallel installation such as providing different packages with different names, installing the library into different places, like compat-packages. What Modularity could help you with — in an arbitrary case when there is bar:1 and bar:2 — is to build your "rolling" module (and other modules) against both of those using stream expansion, providing two different binaries of the same module stream (with different context), and letting DNF to install the right one based on what is on your system, or based on defaults. This is one of the new capabilities Modularity brings to the table. Of course, that only works if your "rolling" module can be actually built against both. But for cases when your "rolling" module can't be built against both versions, existing mechanisms for parallel installation should be used instead. Modularity doesn't reimplement those existing mechanisms. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > 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 > -- Adam Šamalík --- Senior Software Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Rawhide-20190621.n.0 compose check report
Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 12 of 47 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 20/137 (x86_64), 4/22 (i386), 1/2 (arm) ID: 414460 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/414460 ID: 414461 Test: x86_64 Server-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/414461 ID: 414488 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/414488 ID: 414491 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/414491 ID: 414493 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/414493 ID: 414494 Test: x86_64 Everything-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/414494 ID: 414495 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/414495 ID: 414497 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/414497 ID: 414505 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/414505 ID: 414507 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/414507 ID: 414509 Test: x86_64 Workstation-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/414509 ID: 414512 Test: x86_64 Workstation-boot-iso install_default **GATING** URL: https://openqa.fedoraproject.org/tests/414512 ID: 414513 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/414513 ID: 414515 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/414515 ID: 414516 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/414516 ID: 414517 Test: x86_64 KDE-live-iso install_no_user **GATING** URL: https://openqa.fedoraproject.org/tests/414517 ID: 414529 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/414529 ID: 414568 Test: x86_64 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/414568 ID: 414580 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/414580 ID: 414584 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/414584 ID: 414586 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/414586 ID: 414595 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/414595 ID: 414596 Test: x86_64 universal install_kickstart_firewall_disabled **GATING** URL: https://openqa.fedoraproject.org/tests/414596 ID: 414603 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/414603 ID: 414611 Test: i386 universal install_package_set_kde URL: https://openqa.fedoraproject.org/tests/414611 Soft failed openQA tests: 2/22 (i386), 8/137 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 414492 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/414492 ID: 414503 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/414503 ID: 414510 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/414510 ID: 414511 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/414511 ID: 414514 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/414514 ID: 414536 Test: x86_64 universal install_mirrorlist_graphical URL: https://openqa.fedoraproject.org/tests/414536 ID: 414541 Test: x86_64 universal install_kickstart_user_creation URL: https://openqa.fedoraproject.org/tests/414541 ID: 414581 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/414581 ID: 414582 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/414582 ID: 414593 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/414593 Passed openQA tests: 99/137 (x86_64), 16/22 (i386) Skipped gating openQA tests: 4/137 (x86_64) ID: 414521 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/414521 ID: 414522 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/414522
[Test-Announce] Fedora 31 Rawhide 20190621.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 31 Rawhide 20190621.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://www.happyassassin.net/testcase_stats/31 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190621.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Modularity vs. libgit
20.06.2019, 22:50, "Igor Gnatenko" : > Hello, > > I just wanted to give you an update from my last discussions on > #fedora-modularity and other places. > > # Problems definition > > * Default modules can't have conflicting dependenices > * Changing dependencies in a stream is not supported > > # Why does libgit2 has to be a module? > > libgit2 is not just one package. It is an ecosystem. > > Right now libgit2 module provides libgit2 itself and python bindings. > While we can obviously provide libgit2_0.26, libgit2_0.27 and such, > this does not help us with python packages. Nobody in sane mind will rename > them > and make them conflict (because they are not parallel-installable). > > I wanted to also add ruby bindings to a module, but I never got time > to actually do it. I'm the python-pygit2 maintainer (libgit2 python bindings) and I'm very much opposed to what you are doing with libgit2 and modules. It's a huge mess right now. Please go back to a known libgit2 version shipped in one Fedora, so I know which version to target with the python bindings (and so that apps have a clear story as well what to expect). Also, I'd like you to stop shipping the python bindings inside the libgit2 module. They are working very well as a regular package. Thanks. The parallel installable libgit2 non-modular packages that were proposed earlier sounds like a nice solution. I'd be happy to help implement that. Pete ___ 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
[Bug 1722667] perl-CPAN-Perl-Releases-4.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722667 --- Comment #1 from Fedora Update System --- FEDORA-2019-6c63a705ef has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6c63a705ef -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722667] perl-CPAN-Perl-Releases-4.08 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722667 Jitka Plesnikova changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-CPAN-Perl-Releases-4.0 ||8-1.fc31 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722669] perl-Module-CoreList-5.20190620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722669 --- Comment #3 from Fedora Update System --- FEDORA-2019-6d9c631c42 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d9c631c42 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722669] perl-Module-CoreList-5.20190620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722669 --- Comment #2 from Fedora Update System --- FEDORA-2019-36d63f0775 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-36d63f0775 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
[Bug 1722669] perl-Module-CoreList-5.20190620 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1722669 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Module-CoreList-5.2019 ||0620-1.fc31 --- Comment #1 from Petr Pisar --- An enhancement release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
