Re: Coq build issues in F32
Jerry James writes: > I think Richard addressed most of the points you raised. Yes, and no new questions, either. So I think I'm done here (well, I'll spectate, but the internals of the OCaml compiler are well beyond my skillset :-). Good luck! Steve -- Associate Professor Division of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN ___ 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 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 --- Comment #6 from Fedora Update System --- FEDORA-2020-1a094b4f91 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1a094b4f91` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a094b4f91 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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 591 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 333 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 331 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 40 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7e106e25f9 timeshift-20.03-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-42d19f5f91 chromium-80.0.3987.149-1.el7 8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-33500a2742 tor-0.3.5.10-1.el7 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7c64d8ca18 ckeditor-4.14.0-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-61faf4c2ff libmodsecurity-3.0.2-6.el7 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-7bc15e9271 coturn-4.5.1.1-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing protonvpn-cli-2.2.2-7.el7 python-cocotb-1.3.1-1.el7 Details about builds: protonvpn-cli-2.2.2-7.el7 (FEDORA-EPEL-2020-370bbcab84) Linux command-line client for ProtonVPN written in Python Update Information: Approved package for official Fedora repositories ChangeLog: References: [ 1 ] Bug #1809814 - Review Request: protonvpn-cli - Linux command-line client for ProtonVPN written in Python https://bugzilla.redhat.com/show_bug.cgi?id=1809814 python-cocotb-1.3.1-1.el7 (FEDORA-EPEL-2020-9970d0d44a) Coroutine Co-simulation Test Bench Update Information: Update to latest upstream release. ChangeLog: * Fri Mar 27 2020 Ben Rosser - 1.3.1-1 - Update to latest upstream release. * Tue Jan 21 2020 Ben Rosser - 1.3.0-1 - Update to latest upstream release. * Tue Sep 24 2019 Ben Rosser - 1.2.0-3 - Move Recommends on iverilog/ghdl into python3 subpackage. ___ 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 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System --- FEDORA-2020-258db49abe has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-258db49abe` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-258db49abe See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- 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: Unsubscribe
On 2020-03-28 08:24, wen rei do wrote: > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- The key to getting good answers is to ask good questions. ___ 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 20 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4 ansible-2.9.6-1.el8 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0316f810ac python-twisted-19.10.0-2.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-79bd0a6b28 chromium-80.0.3987.149-1.el8 7 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f16ad37b5e tor-0.4.2.7-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2cb1029c5a okular-18.12.2-2.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-913d6d1779 coturn-4.5.1.1-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing adb-enhanced-2.5.2-1.el8 goldendict-1.5-0.27.RC2.el8 libssh2-1.9.0-5.el8 protonvpn-cli-2.2.2-7.el8 python-adb-shell-0.1.3-1.el8 python-aiopg-1.0.0-2.el8 python-asysocks-0.0.2-1.el8 python-backlash-0.2.0-1.el8 python-crank-0.8.1-12.el8 python-itanium_demangler-1.0-1.el8 python-mulpyplexer-0.08-1.el8 python-nessus-file-reader-0.2.0-1.el8 python-nine-1.1.0-2.el8 python-transaction-3.0.0-1.el8 python-xpath-expressions-1.0.2-1.el8 rubygem-erubi-1.7.0-1.el8 ser2net-3.5-6.el8 Details about builds: adb-enhanced-2.5.2-1.el8 (FEDORA-EPEL-2020-f184955b3e) Swiss-army knife for Android testing and development Update Information: Initial package for Fedora ChangeLog: goldendict-1.5-0.27.RC2.el8 (FEDORA-EPEL-2020-c57b87e4fb) A feature-rich dictionary lookup program Update Information: Fixed crashes on Wayland. ChangeLog: * Fri Mar 27 2020 Vitaly Zaitsev - 1.5-0.27.RC2 - Rebased to 6ca112b snapshot with Wayland crash fixes. * Sun Mar 15 2020 Vitaly Zaitsev - 1.5-0.26.RC2 - Rebased to a1c7c5b snapshot with a separate desktop action for Wayland. * Sun Mar 15 2020 Vitaly Zaitsev - 1.5-0.25.RC2 - Added a separate desktop icon for Gnome users with workaround. - Updated to 353ea17 snapshot with crash fixes under Qt 5.13+. * Sat Mar 14 2020 Mosaab Alzoubi - 1.5-0.24.RC2 - Workaround #1766935 * Wed Jan 29 2020 Fedora Release Engineering - 1.5-0.23.RC2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild References: [ 1 ] Bug #1766935 - Goldendict crash on Wayland https://bugzilla.redhat.com/show_bug.cgi?id=1766935 libssh2-1.9.0-5.el8 (FEDORA-EPEL-2020-3681ce7474) A library implementing the SSH2 protocol Update Information: This is the first EPEL-8 build of libssh2. ChangeLog: References: [ 1 ] Bug #1792625 - libssh2 needed for EPEL8 https://bugzilla.redhat.com/show_bug.cgi?id=1792625 protonvpn-cli-2.2.2-7.el8 (FEDORA-EPEL-2020-944d23ac95) Linux command-line client for ProtonVPN written in Python Update Information: Approved package for official Fedora repositories ChangeLog: References: [ 1 ] Bug #1809814 - Review Request: protonvpn-cli - Linux command-line client for ProtonVPN written in Python https://bugzilla.redhat.com/show_bug.cgi?id=1809814 python-adb-shell-0.1.3-1.el8 (FEDORA-EPEL-2020-65992d2d2c) Python implementation for ADB shell and file sync Update Information: Initial package for Fedora
[Bug 1814445] perl-Crypt-OpenSSL-EC-1.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814445 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc33 |1.fc33 |perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc32 |1.fc32 |perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc30 |1.fc30 ||perl-Crypt-OpenSSL-EC-1.32- ||1.fc31 --- Comment #8 from Fedora Update System --- FEDORA-2020-6f4441494a has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1814445] perl-Crypt-OpenSSL-EC-1.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814445 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc33 |1.fc33 |perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc32 |1.fc32 ||perl-Crypt-OpenSSL-EC-1.32- ||1.fc30 --- Comment #7 from Fedora Update System --- FEDORA-2020-93df3e0e37 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
On Fri, Mar 27, 2020 at 8:01 PM Kevin Fenzi wrote: > > So, my concern here is timeline vs the upcoming datacenter move. ;( > > Do you have any ideas when rpm 4.16 will be released? I don't see any > dates on the change. Or perhaps I guess the question is when it will > land in rawhide? > Panu tagged the rpm 4.16 alpha earlier this week, so I would hope it'd land in Rawhide next week. > As soon as it lands in rawhide we need to upgrade the builders to the > rawhide rpm and set macros so it uses bdb for everything but rawhide. > It's very likely however that builders will still be Fedora 31 at that > point. (If that matters for rpm any). > You can set the macro now for all targets that this would be a problem with, it'll be a no-op with current rpm. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Unsubscribe
Hi, I would like to unsubscribe. Best Regards, Wen Rei ___ 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 1814445] perl-Crypt-OpenSSL-EC-1.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814445 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Crypt-OpenSSL-EC-1.32- |perl-Crypt-OpenSSL-EC-1.32- |1.fc33 |1.fc33 ||perl-Crypt-OpenSSL-EC-1.32- ||1.fc32 Resolution|--- |ERRATA Last Closed||2020-03-28 00:15:16 --- Comment #6 from Fedora Update System --- FEDORA-2020-c745bc2d38 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
So, my concern here is timeline vs the upcoming datacenter move. ;( Do you have any ideas when rpm 4.16 will be released? I don't see any dates on the change. Or perhaps I guess the question is when it will land in rawhide? As soon as it lands in rawhide we need to upgrade the builders to the rawhide rpm and set macros so it uses bdb for everything but rawhide. It's very likely however that builders will still be Fedora 31 at that point. (If that matters for rpm any). Or I suppose we could try and get mock's bootstrapping working before then. In either case, it may be hard to have cycles for this while datacenter move is happening. It would help if we had a ballpark at least for when it will land / some folks willing to get bootstrapping working in koji. Or what would you think of the idea of landing it in rawhide, but keeping default bdb until after we have the move done and can upgrade builders to f32? kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 4:42 PM Jerry James wrote: > Good idea. Thank you! I got a segfault on s390x on the second build attempt. I'd like to investigate the ephemeron angle a bit, I think. -- Jerry James http://www.jamezone.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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 03:19:01PM -0500, Justin Forbes wrote: > On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > > Stephen Gallagher writes: > > > > It is under discussion whether this snapshot will have its own > > > > installation media. For now the preferred way to test ELN composes > > > > would be to use standard Fedora Rawhide images and then include ELN as > > > > an additional repository. > > > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > > > Yeah, that's something I was trying to figure out too. As discussed > > before, for rpm '.eln < .fc33', so if the same package is available > > from both sources, the rawhide one will win. > > > > Can this be handled with the existing 'priority' directive in > repository config files? I think this is a nice behavior and we should consider not messing with it any. (ie, rawhide is always newer). Since we are not advertising this / marketing / expecting that normal users would use it, why not make it easy for them to go back if they install some eln packages? If you are one of the developers/testers you can use distro-sync, or a composed eln media to test and then just 'dnf update' (or distro-sync) back to rawhide. This also means if someone installs a .eln package on a stable fedora, it will be 'upgraded' away to next time the package updates. Or if they go from say f31 to f32. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
So, in general I think this is a pretty cool idea and I am in favor of it. I do think we are going to have to learn and adjust as we go here somewhat, we can't be 100% sure of how this will pan out. Of course we should plan as best we can now too. :) Some random things in no particular order: * This is the sort of thing that doesn't really fit the change process too well, since it's not really tied to a release or adding some deliverable to a release or whatever. I guess it's the best we have though currently. * So, while you say "we will not be shipping any content produced from ELN directly to the general public", it sounds like ODCS composes and of course packages from koji will be available for those that know where to look for them, which brings up: ** Can you add that you will document how these packages interact somewhere? I guess the ELN wiki page if nothing else. ie, say eln packages are built with different compiler flags, we should have some way to tell people who get a hold of them what hardware will work on them or fail completely. ** If we get a lot of demand we may need to redo stuff around ODCS, as it's currently just a pair of vm's with a nfs mount to serve those composes. If there's a lot of load we may need to put some caching in front of it or put it on a dedicated download server or something. * Might note that this will require a new "release" in bodhi. I don't think thats much work (might just be config), but could be good to check. * Might add in the benifit to fedora that ODCS will get worked on and perhaps someday we can move all our other composes into it. (This would allow us to not have a bodhi-backend machine, it could be all in openshift, and let us let koji do the heavy lifting instead of a rawhide-composer instance) * Suggestion: How about making a ELN tracker bug and require anything that uses %eln or has some failure to build being filed against the package and tracked in the tracker. This would allow people who care to follow along and see how many issues there are, etc. * Depending on when we get this going, timing might be not that great. We have the datacenter move coming up. In late may/early june we will likely have a lot less capacity of builders until we can re-add machines as they arrive from shipping. I think as long as you don't mind things being slow, we could tune it so ELN builds are not as high priority as normal builds (so they will wait until there's capacity for them). They would still finish, just might take longer and not impact other builds. In fact, perhaps we should set this from the start and see if it causes you any issues? * Additionally there will likely be some more disk usage from this (on ODCS and in koji). However, if we only need to keep around the last working eln build and don't keep a bunch of composes I don't think this should be too big an issue. Definitely something to watch tho. Anyhow, those are probibly also a lot of things we can just sort out with releng, but figured I'd throw them out there while I was thinking about them. Overall I think this could be a very nice effort and won't even hopefully cost us much in time and energy. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 4:41 PM Richard W.M. Jones wrote: > I'll run it in a loop overnight and see if I can make it crash. Good idea. Thank you! -- Jerry James http://www.jamezone.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: Coq build issues in F32
On Fri, Mar 27, 2020 at 04:20:16PM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 2:41 PM Richard W.M. Jones wrote: > > Yup, and the stack trace shows the failure happening when creating an > > ephemeron. > > On the other hand, a scratch build with coq upstream's final patch for > ocaml 4.10.0 succeeded on the first try: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42808115 > > Where this is an intermittent problem, I'll have to try more builds to > be sure, but this looks promising. I'll run it in a loop overnight and see if I can make it crash. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 2:41 PM Richard W.M. Jones wrote: > Yup, and the stack trace shows the failure happening when creating an > ephemeron. On the other hand, a scratch build with coq upstream's final patch for ocaml 4.10.0 succeeded on the first try: https://koji.fedoraproject.org/koji/taskinfo?taskID=42808115 Where this is an intermittent problem, I'll have to try more builds to be sure, but this looks promising. -- Jerry James http://www.jamezone.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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 02:20:29PM -0500, Justin Forbes wrote:
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell wrote:
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
>On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote:
>>
>> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
>> >As Ben is on PTO, I'd like to present the System-Wide Change
>> >
>> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
>> [snip]
>>
>> It has taken me some time, but I have read through the entire thread in
>> addition to the change proposal. The idea sounds really interesting to me
and
>> a lot of points have come up on the thread. I decided to group my responses
>> together as this single email after reading through the entire thread to make
>> it a bit easier to read (and to write).
>>
>> TL;DR -- I think this proposal should be broken up in to 2 proposals
>>
>> The turning point for me in the change proposal was the discussion of the RPM
>> spec file macros and getting in to the mechanics of how ELN will work. It
>> looks like a lot of other people had the same reaction because many of the
>> responses get in to the technical details and for some questions, there are
no
>> answers yet. After thinking about it for a while, it would make sense to me
>> to have ELN come up in multiple phases/proposals.
>>
>> Suggested Proposals:
>>
>> 1) ELN buildroot and install media
>>
>> In this proposal, I'd like to see the ELN buildroot defined, the Koji
>> changes implemented, the automated builds implemented, and install media
>> composes happening.
>>
>> The expectation here should be that it is rough around the edges. But
>> doing this gives the community something to see, use, and discuss further
>> when reviewing the next change proposals.
>>
>> We should have some community goals with this proposal to capture a list
of
>> EL vs. Fedora differences and how to address those per package and in the
>> context of ELN.
>>
>> 2) ELN lifecycle
>>
>> This gets in to more of the mechanics of how ELN builds can be handled by
>> the community. I do not think there is a one size fits all and we should
>> give developers control over how best to handle this for the packages
they
>> maintain.
>>
>> The spec file macros, git branch ideas, inheritance, pull request
workflow,
>> what builds block what composes, who is responsible for ELN failures, and
>> other expectations of package maintainers (both Fedora and RHEL) should
be
>> discussed here. This proposal is definitely the policy side of things,
but
>> I think it would be easier to talk about after #1 is done.
>>
>> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
>> rhel-rawhide at one point), the ELN idea is one where the work is being
>> targeted in the right place. As a Fedora contributor, I see RHEL as a
>> customer and if we can make their work easier, I want to do that. As a RHEL
>> package maintainer, I see Fedora as a place where I can make my job easier as
>> a RHEL package maintainer. The more things we get right on the community
side
>> of things, the easier it is to produce RHEL.
>>
>> Various comments from reading the thread:
>>
>> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
>>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
>>that covers all three of those.
>>
>
>The %{?rhel} macro name currently exists and is in use in some
>packages as I recall.
Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
I would prefer a new macro for the ELN work to distinguish it from the
existing macros.
>> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
>>major release. This should be ok in the community since Red Hat
ultimately
>>makes the decision to version RHEL. This is an engineering decision and I
>>think it would help imply that ELN is _not_ meant for current RHEL. This
>>also lets us entertain the idea of multiple ELN major versions
concurrently
>>should we ever want to do that.
>>
>
>I rather equate this to RHELhide, it should be evolving. Once N is
>branched (CentOS?) and moving on, this is N+1. This is the rolling
>development location.
I agree. The 'N' value seen in this dist tag should always be greater than
the latest major version we see for RHEL and CentOS.
Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of
this seems it should carry no number, similar to the rawhide it is
inheriting from. Let them deal with numbers in CentOS and RHEL.
I find it useful to have that information in the dist tag so that you can see
a built package and have an idea of when it was built.
--
David Cantrell
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:54:44AM -0600, Jerry James wrote: > On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > > Jerry, I suggest this bug is real, but is also likely to be a bug in > > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > > You might have more luck asking the upstream developers for help. > > Coq issue: https://github.com/coq/coq/issues/11939 > > I looked around in the ocaml issue tracker and found a possibility: > > https://github.com/ocaml/ocaml/issues/9391 > > Coq uses ephemerons. Yup, and the stack trace shows the failure happening when creating an ephemeron. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ 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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:15:01AM -0600, Jerry James wrote:
> On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote:
> > Okay, I will give that a try.
>
> Except I can't. We're already not using %_smp_mflags. Ugh.
I realized that my build machine has MAKEFLAGS=-j24 which is why it's
building coq in parallel (and quickly). So it seems like you could be
using _smp_mflags.
Another thing I tried today was enabling debugging in the GC (see
patch below). However it also didn't find any problems, so I'm still
at a loss.
Rich.
diff --git a/coq.spec b/coq.spec
index df2a847..1e590cc 100644
--- a/coq.spec
+++ b/coq.spec
@@ -164,6 +164,10 @@ done
%global opt_option -bytecode-compiler yes -byte-only -coqide byte
%endif
+# Use debug runtime.
+sed -i 's/^\(OCAMLC :=.*\)/\1 -runtime-variant d/' Makefile.build
+sed -i 's/^\(OCAMLOPT :=.*\)/\1 -runtime-variant d/' Makefile.build
+
%global coqdocdir %{?_pkgdocdir}%{!?_pkgdocdir:%{_docdir}/coq-%{version}}
%global coqdatadir %{_libdir}/coq
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On Fri, Mar 27, 2020 at 1:56 AM Zbigniew Jędrzejewski-Szmek wrote: > > Where would mock be executing from? The same filesystem it is modifying? > Somehow it seems that this doesn't change much, but just brings > in another layer. Or will a complete copy of the system be made in > memory to execute the upgrade tools from? Snapshot it. If it doesn't work, throw away the snapshot. > > Let's consider a concrete example that came up recently: grub wants to > rewrite something in the bootloader area on disk to help upgrades from > very old installations. In current "offline upgrade" scheme, the upgrade > tools are running on the real system, with udev active. They can query > and touch hardware, can see all the disks as they are, etc. If we > went through mock, it'd be running in an nspawn environment w/o access > to hardware. This particular example affected BIOS GRUB, where the embedded "core.img" isn't ever updated. i.e. grub-install is called once at original install time, and never again. I'm not certain whether installation is, or could be, atomic. On UEFI, the "core.img" makes up most of grubx64.efi, and it's updated anytime grub2-efi-x64 package is updated. Not only system upgrades. I don't know how RPM replaces it. But since it's on FAT, atomicity is limited to the VFS operation. There is a window where it could be interrupted and things wouldn't be in either working state. > (Something like os-tree's atomic replacement of things, that's of > course a completely different story. But so far we're talking about > traditional systems.) Perhaps ironically, rpm-ostree + UEFI systems, don't have the bootloader updated. And it doesn't really want to be responsible for it. GRUB is very cool in many ways, but having a strategy for keeping itself up to date is not one of them; so far upstream GRUB development considers this a distribution problem, not a problem in search of a generic solution. One idea is a service that ensures boot related things are in the proper state, including mirroring the EFI system partition for raid1 sysroot setups. It's not decided if it should be fwupd function or made into a separate boot daemon. -- 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 2:42 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > Stephen Gallagher writes: > > > It is under discussion whether this snapshot will have its own > > > installation media. For now the preferred way to test ELN composes > > > would be to use standard Fedora Rawhide images and then include ELN as > > > an additional repository. > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > Yeah, that's something I was trying to figure out too. As discussed > before, for rpm '.eln < .fc33', so if the same package is available > from both sources, the rawhide one will win. > Can this be handled with the existing 'priority' directive in repository config files? ___ 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 rawhide compose report: 20200327.n.0 changes
OLD: Fedora-Rawhide-20200326.n.0 NEW: Fedora-Rawhide-20200327.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 20 Dropped packages:1 Upgraded packages: 88 Downgraded packages: 0 Size of added packages: 1.34 GiB Size of dropped packages:6.87 MiB Size of upgraded packages: 2.62 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 82.25 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: algobox-1.0.3-1.fc33 Summary: Algorithmic software RPMs:algobox Size:2.77 MiB Package: ghc-8.10.1-93.module_f33+8393+d9235bfb Summary: Glasgow Haskell Compiler RPMs:ghc ghc-Cabal ghc-Cabal-devel ghc-Cabal-doc ghc-Cabal-prof ghc-array ghc-array-devel ghc-array-doc ghc-array-prof ghc-base ghc-base-devel ghc-base-doc ghc-base-prof ghc-binary ghc-binary-devel ghc-binary-doc ghc-binary-prof ghc-bytestring ghc-bytestring-devel ghc-bytestring-doc ghc-bytestring-prof ghc-compiler ghc-containers ghc-containers-devel ghc-containers-doc ghc-containers-prof ghc-deepseq ghc-deepseq-devel ghc-deepseq-doc ghc-deepseq-prof ghc-devel ghc-directory ghc-directory-devel ghc-directory-doc ghc-directory-prof ghc-doc ghc-doc-index ghc-exceptions ghc-exceptions-devel ghc-exceptions-doc ghc-exceptions-prof ghc-filepath ghc-filepath-devel ghc-filepath-doc ghc-filepath-prof ghc-ghc ghc-ghc-boot ghc-ghc-boot-devel ghc-ghc-boot-doc ghc-ghc-boot-prof ghc-ghc-boot-th ghc-ghc-boot-th-devel ghc-ghc-boot-th-doc ghc-ghc-boot-th-prof ghc-ghc-compact ghc-ghc-compact-devel ghc-ghc-compact-doc ghc-ghc-compact-prof ghc-ghc-devel ghc-ghc-doc ghc-ghc-heap ghc-ghc-heap-devel ghc-ghc-heap-doc ghc-ghc-heap-prof ghc-ghc-prof ghc-ghci ghc-ghci-devel ghc-ghci-doc ghc-ghci-prof ghc-haskeline ghc-haskeline-devel ghc-haskeline-doc ghc-haskeline-prof ghc-hpc ghc-hpc-devel ghc-hpc-doc ghc-hpc-prof ghc-libiserv ghc-libiserv-devel ghc-libiserv-doc ghc-libiserv-prof ghc-manual ghc-mtl ghc-mtl-devel ghc-mtl-doc ghc-mtl-prof ghc-parsec ghc-parsec-devel ghc-parsec-doc ghc-parsec-prof ghc-pretty ghc-pretty-devel ghc-pretty-doc ghc-pretty-prof ghc-process ghc-process-devel ghc-process-doc ghc-process-prof ghc-prof ghc-stm ghc-stm-devel ghc-stm-doc ghc-stm-prof ghc-template-haskell ghc-template-haskell-devel ghc-template-haskell-doc ghc-template-haskell-prof ghc-terminfo ghc-terminfo-devel ghc-terminfo-doc ghc-terminfo-prof ghc-text ghc-text-devel ghc-text-doc ghc-text-prof ghc-time ghc-time-devel ghc-time-doc ghc-time-prof ghc-transformers ghc-transformers-devel ghc-transformers-doc ghc-transformers-prof ghc-unix ghc-unix-devel ghc-unix-doc ghc-unix-prof ghc-xhtml ghc-xhtml-devel ghc-xhtml-doc ghc-xhtml-prof Size:1.25 GiB Package: gnome-applets-3.36.1-1.fc33 Summary: Small applications for the GNOME Flashback panel RPMs:gnome-applets Size:40.19 MiB Package: gnome-flashback-3.36.0-1.fc33 Summary: GNOME Flashback session RPMs:gnome-flashback Size:2.76 MiB Package: gnome-panel-3.36.0-1.fc33 Summary: GNOME Flashback panel RPMs:gnome-panel gnome-panel-devel gnome-panel-doc gnome-panel-libs Size:8.44 MiB Package: goloris-0-0.1.20200326gita59fafb.fc33 Summary: Slowloris for NGINX DoS RPMs:golang-github-valyala-goloris-devel goloris Size:7.14 MiB Package: goverlay-0.2.3-1.fc33 Summary: Graphical UI to help manage Linux overlays RPMs:goverlay Size:8.83 MiB Package: home-assistant-cli-0.8.0-2.fc33 Summary: Command-line tool for Home Assistant RPMs:home-assistant-cli Size:79.54 KiB Package: libqmatrixclient-0.5.2-1.fc33 Summary: Qt5 library to write cross-platform clients for Matrix RPMs:libqmatrixclient libqmatrixclient-devel Size:3.41 MiB Package: non-daw-1.2.0-19.20200307gitbbe8386.fc33 Summary: A digital audio workstation for JACK RPMs:non-daw non-mixer non-mixer-doc non-sequencer non-sequencer-doc non-session-manager non-session-manager-doc Size:16.96 MiB Package: python-asysocks-0.0.2-1.fc33 Summary: Socks5/Socks4 client and server library RPMs:python3-asysocks Size:33.69 KiB Package: python-bibtexparser-1.1.0-2.fc33 Summary: A BibTeX parsing library RPMs:python-bibtexparser-doc python3-bibtexparser Size:317.08 KiB Package: python-friendlyloris-1.0.1-1.fc33 Summary: A Slow Loris package for Python RPMs:python3-friendlyloris Size:15.16 KiB Package: python-makeelf-0.3.2-1.fc33 Summary: ELF reader-writer library RPMs:python3-makeelf Size:56.95 KiB Package: python-readability-lxml-0.7.1-2.20200326gitede4d01.fc33 Summary: Fast html to text parser (article readability tool) RPMs:python3-readability-lxml Size:40.23 KiB Package: python-registry-1.3.1-2.fc33 Summary: Read access to Windows Registry files RPMs:python3-registry Size:45.52 KiB Package: python-requests-pkcs12-1.7-1.fc33 Summary: Add PKCS12 support to the requests library RPMs:python3-requests-pkcs12
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 3:42 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > > Stephen Gallagher writes: > > > It is under discussion whether this snapshot will have its own > > > installation media. For now the preferred way to test ELN composes > > > would be to use standard Fedora Rawhide images and then include ELN as > > > an additional repository. > > > > Is there a dnf change that goes with this to prefer ELN content, then? > > Yeah, that's something I was trying to figure out too. As discussed > before, for rpm '.eln < .fc33', so if the same package is available > from both sources, the rawhide one will win. > If there was a "dnf distro-sync --prefer-repo=foo" kind of feature, maybe that'd work? Maybe repo priorities? I'm not sure how this would work... > > > ELN artifacts will be made available for testing and development > > > purposes, but we will not be shipping any content produced from ELN > > > directly to the general public (such as on the standard mirror network > > > or via getfedora.org). > > > ... > > > > > > Though it is a System-Wide Change it has no user-facing component. We > > > may announce it through other channels. > > > > I'm confused. This is going to be installable and testable, but has no > > user-facing component? What's a user-facing component then? > > FWIW, I think it's OK to have to first install rawhide and then to > enable eln repos on top to have a working installation. Or to do > 'dnf --installroot'. Building an an installer image and such doesn't > seem necessary, esp. in the beginning. > I would argue that it is necessary, if it's intended to be as interesting and useful as this Change proposes. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > Stephen Gallagher writes: > > It is under discussion whether this snapshot will have its own > > installation media. For now the preferred way to test ELN composes > > would be to use standard Fedora Rawhide images and then include ELN as > > an additional repository. > > Is there a dnf change that goes with this to prefer ELN content, then? Yeah, that's something I was trying to figure out too. As discussed before, for rpm '.eln < .fc33', so if the same package is available from both sources, the rawhide one will win. > > ELN artifacts will be made available for testing and development > > purposes, but we will not be shipping any content produced from ELN > > directly to the general public (such as on the standard mirror network > > or via getfedora.org). > > ... > > > > Though it is a System-Wide Change it has no user-facing component. We > > may announce it through other channels. > > I'm confused. This is going to be installable and testable, but has no > user-facing component? What's a user-facing component then? FWIW, I think it's OK to have to first install rawhide and then to enable eln repos on top to have a working installation. Or to do 'dnf --installroot'. Building an an installer image and such doesn't seem necessary, esp. in the beginning. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 11:07:41AM -0400, Stephen Gallagher wrote:
> == Summary ==
> ELN is a new buildroot and compose process for Fedora that will take
> Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
> compose. Feedback from this build, compose and integration testing
> will be provided to Fedora packagers so that they can see the
> potential impact of their changes on RHEL development.
Thanks, the new page is much better. Esp. this new summary is
massively better.
Some specific things which are still unclear:
> Setup automation to trigger new ELN build every time there is a new
> update submitted to Fedora Rawhide.
Does "update" in this context mean the automatic bodhi update used for
gating? What does "submitted" mean — the time when the update is
requested, on when the update is pushed to rawhide, or ... ?
> Post build result to Fedora Messaging, so that it appears in Bodhi
> and can be used as a gating test
Continuing with the previous question, is the "gating test" for the
original rawhide update?
> The SIG will [...] maintain infrastructure required to build packages and
> composes;
Does this mean that some new person will join releng?
> we will not be shipping any content produced from ELN directly to
> the general public (such as on the standard mirror network
Hmm, so those packages will be pulled directly from koji? Is the
additional load acceptable?
> Contingency mechanism: If this effort doesn’t land in Fedora 33 we
> review it and decide whether it needs to be moved further to Fedora
> 34 or be cancelled.
OK, and what about the case where it is enabled, and then during the
way it turns out to be too much hassle? Is there some sunset procedure
planned?
> What if there is a feature RHEL wants in a package, how will that go in?
> That is not in the scope of ELN.
Does "not in scope" mean that the question is not answered, or does
it mean that ELN is not relevant to the question?
The latter seems a bit impossible. ELN is all about making rawhide
packages more like the packages in RHEL, and this naturally means
adding and removing features or changing dependencies or configuration
falls into the scope of ELN. I.e. if I'm a RHEL maintainer, opening
a PR against Fedora dist-git with a bunch of '%if %{eln}' conditionals
or not seems the most straightforward way to push towards having a
feature in RHEL...
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On 27. 03. 20 20:20, Justin Forbes wrote: Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of this seems it should carry no number, similar to the rawhide it is inheriting from. Let them deal with numbers in CentOS and RHEL. But rawhide also has a number (currently 33). -- 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
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 2:09 PM David Cantrell wrote:
>
> On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
> >On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote:
> >>
> >> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >> >As Ben is on PTO, I'd like to present the System-Wide Change
> >> >
> >> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> >> [snip]
> >>
> >> It has taken me some time, but I have read through the entire thread in
> >> addition to the change proposal. The idea sounds really interesting to me
> >> and
> >> a lot of points have come up on the thread. I decided to group my
> >> responses
> >> together as this single email after reading through the entire thread to
> >> make
> >> it a bit easier to read (and to write).
> >>
> >> TL;DR -- I think this proposal should be broken up in to 2 proposals
> >>
> >> The turning point for me in the change proposal was the discussion of the
> >> RPM
> >> spec file macros and getting in to the mechanics of how ELN will work. It
> >> looks like a lot of other people had the same reaction because many of the
> >> responses get in to the technical details and for some questions, there
> >> are no
> >> answers yet. After thinking about it for a while, it would make sense to
> >> me
> >> to have ELN come up in multiple phases/proposals.
> >>
> >> Suggested Proposals:
> >>
> >> 1) ELN buildroot and install media
> >>
> >> In this proposal, I'd like to see the ELN buildroot defined, the Koji
> >> changes implemented, the automated builds implemented, and install
> >> media
> >> composes happening.
> >>
> >> The expectation here should be that it is rough around the edges. But
> >> doing this gives the community something to see, use, and discuss
> >> further
> >> when reviewing the next change proposals.
> >>
> >> We should have some community goals with this proposal to capture a
> >> list of
> >> EL vs. Fedora differences and how to address those per package and in
> >> the
> >> context of ELN.
> >>
> >> 2) ELN lifecycle
> >>
> >> This gets in to more of the mechanics of how ELN builds can be handled
> >> by
> >> the community. I do not think there is a one size fits all and we
> >> should
> >> give developers control over how best to handle this for the packages
> >> they
> >> maintain.
> >>
> >> The spec file macros, git branch ideas, inheritance, pull request
> >> workflow,
> >> what builds block what composes, who is responsible for ELN failures,
> >> and
> >> other expectations of package maintainers (both Fedora and RHEL)
> >> should be
> >> discussed here. This proposal is definitely the policy side of
> >> things, but
> >> I think it would be easier to talk about after #1 is done.
> >>
> >> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even
> >> called
> >> rhel-rawhide at one point), the ELN idea is one where the work is being
> >> targeted in the right place. As a Fedora contributor, I see RHEL as a
> >> customer and if we can make their work easier, I want to do that. As a
> >> RHEL
> >> package maintainer, I see Fedora as a place where I can make my job easier
> >> as
> >> a RHEL package maintainer. The more things we get right on the community
> >> side
> >> of things, the easier it is to produce RHEL.
> >>
> >> Various comments from reading the thread:
> >>
> >> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
> >>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el'
> >> macro
> >>that covers all three of those.
> >>
> >
> >The %{?rhel} macro name currently exists and is in use in some
> >packages as I recall.
>
> Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
> I would prefer a new macro for the ELN work to distinguish it from the
> existing macros.
>
> >> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
> >>major release. This should be ok in the community since Red Hat
> >> ultimately
> >>makes the decision to version RHEL. This is an engineering decision
> >> and I
> >>think it would help imply that ELN is _not_ meant for current RHEL.
> >> This
> >>also lets us entertain the idea of multiple ELN major versions
> >> concurrently
> >>should we ever want to do that.
> >>
> >
> >I rather equate this to RHELhide, it should be evolving. Once N is
> >branched (CentOS?) and moving on, this is N+1. This is the rolling
> >development location.
>
> I agree. The 'N' value seen in this dist tag should always be greater than
> the latest major version we see for RHEL and CentOS.
Sorry, I wasn't clear. I mean that the rhelhide/evolving nature of
this seems it should carry no number, similar to the rawhide it is
inheriting from. Let them deal with numbers in CentOS and RHEL.
Justin
___
devel
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 01:48:15PM -0500, Justin Forbes wrote:
On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote:
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
>As Ben is on PTO, I'd like to present the System-Wide Change
>
>https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[snip]
It has taken me some time, but I have read through the entire thread in
addition to the change proposal. The idea sounds really interesting to me and
a lot of points have come up on the thread. I decided to group my responses
together as this single email after reading through the entire thread to make
it a bit easier to read (and to write).
TL;DR -- I think this proposal should be broken up in to 2 proposals
The turning point for me in the change proposal was the discussion of the RPM
spec file macros and getting in to the mechanics of how ELN will work. It
looks like a lot of other people had the same reaction because many of the
responses get in to the technical details and for some questions, there are no
answers yet. After thinking about it for a while, it would make sense to me
to have ELN come up in multiple phases/proposals.
Suggested Proposals:
1) ELN buildroot and install media
In this proposal, I'd like to see the ELN buildroot defined, the Koji
changes implemented, the automated builds implemented, and install media
composes happening.
The expectation here should be that it is rough around the edges. But
doing this gives the community something to see, use, and discuss further
when reviewing the next change proposals.
We should have some community goals with this proposal to capture a list of
EL vs. Fedora differences and how to address those per package and in the
context of ELN.
2) ELN lifecycle
This gets in to more of the mechanics of how ELN builds can be handled by
the community. I do not think there is a one size fits all and we should
give developers control over how best to handle this for the packages they
maintain.
The spec file macros, git branch ideas, inheritance, pull request workflow,
what builds block what composes, who is responsible for ELN failures, and
other expectations of package maintainers (both Fedora and RHEL) should be
discussed here. This proposal is definitely the policy side of things, but
I think it would be easier to talk about after #1 is done.
Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
rhel-rawhide at one point), the ELN idea is one where the work is being
targeted in the right place. As a Fedora contributor, I see RHEL as a
customer and if we can make their work easier, I want to do that. As a RHEL
package maintainer, I see Fedora as a place where I can make my job easier as
a RHEL package maintainer. The more things we get right on the community side
of things, the easier it is to produce RHEL.
Various comments from reading the thread:
* I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
that covers all three of those.
The %{?rhel} macro name currently exists and is in use in some
packages as I recall.
Sorry, what I meant was I'm not crazy about the %{?rhel} macro for this work.
I would prefer a new macro for the ELN work to distinguish it from the
existing macros.
* I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
major release. This should be ok in the community since Red Hat ultimately
makes the decision to version RHEL. This is an engineering decision and I
think it would help imply that ELN is _not_ meant for current RHEL. This
also lets us entertain the idea of multiple ELN major versions concurrently
should we ever want to do that.
I rather equate this to RHELhide, it should be evolving. Once N is
branched (CentOS?) and moving on, this is N+1. This is the rolling
development location.
I agree. The 'N' value seen in this dist tag should always be greater than
the latest major version we see for RHEL and CentOS.
Thanks,
--
David Cantrell
Red Hat, Inc. | Boston, MA | EST5EDT
___
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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 10:47 AM David Cantrell wrote:
>
> On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
> >As Ben is on PTO, I'd like to present the System-Wide Change
> >
> >https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
> [snip]
>
> It has taken me some time, but I have read through the entire thread in
> addition to the change proposal. The idea sounds really interesting to me and
> a lot of points have come up on the thread. I decided to group my responses
> together as this single email after reading through the entire thread to make
> it a bit easier to read (and to write).
>
> TL;DR -- I think this proposal should be broken up in to 2 proposals
>
> The turning point for me in the change proposal was the discussion of the RPM
> spec file macros and getting in to the mechanics of how ELN will work. It
> looks like a lot of other people had the same reaction because many of the
> responses get in to the technical details and for some questions, there are no
> answers yet. After thinking about it for a while, it would make sense to me
> to have ELN come up in multiple phases/proposals.
>
> Suggested Proposals:
>
> 1) ELN buildroot and install media
>
> In this proposal, I'd like to see the ELN buildroot defined, the Koji
> changes implemented, the automated builds implemented, and install media
> composes happening.
>
> The expectation here should be that it is rough around the edges. But
> doing this gives the community something to see, use, and discuss further
> when reviewing the next change proposals.
>
> We should have some community goals with this proposal to capture a list
> of
> EL vs. Fedora differences and how to address those per package and in the
> context of ELN.
>
> 2) ELN lifecycle
>
> This gets in to more of the mechanics of how ELN builds can be handled by
> the community. I do not think there is a one size fits all and we should
> give developers control over how best to handle this for the packages they
> maintain.
>
> The spec file macros, git branch ideas, inheritance, pull request
> workflow,
> what builds block what composes, who is responsible for ELN failures, and
> other expectations of package maintainers (both Fedora and RHEL) should be
> discussed here. This proposal is definitely the policy side of things,
> but
> I think it would be easier to talk about after #1 is done.
>
> Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
> rhel-rawhide at one point), the ELN idea is one where the work is being
> targeted in the right place. As a Fedora contributor, I see RHEL as a
> customer and if we can make their work easier, I want to do that. As a RHEL
> package maintainer, I see Fedora as a place where I can make my job easier as
> a RHEL package maintainer. The more things we get right on the community side
> of things, the easier it is to produce RHEL.
>
> Various comments from reading the thread:
>
> * I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
>instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
>that covers all three of those.
>
The %{?rhel} macro name currently exists and is in use in some
packages as I recall.
> * I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
>major release. This should be ok in the community since Red Hat ultimately
>makes the decision to version RHEL. This is an engineering decision and I
>think it would help imply that ELN is _not_ meant for current RHEL. This
>also lets us entertain the idea of multiple ELN major versions concurrently
>should we ever want to do that.
>
I rather equate this to RHELhide, it should be evolving. Once N is
branched (CentOS?) and moving on, this is N+1. This is the rolling
development location.
___
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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:36:38AM -0600, Jerry James wrote:
> On Fri, Mar 27, 2020 at 11:30 AM Zbigniew Jędrzejewski-Szmek
> wrote:
> > We are. Did you trying putting '%global _smp_mflags -j1' somewhere
> > near the top of the spec file?
>
> We are? Where?
That is what the packaging guidelines say [1]:
> Whenever possible, invocations of make should be done as
> %make_build
(which is defined as
$ rpmbuild --showrc |grep make_build
make_build %{__make} %{_make_output_sync} %{?_smp_mflags} %{_make_verbose}).
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_parallel_make
> The spec file does this to build:
>
> make world VERBOSE=1
So it seems that this particular Makefile enables parallelization
internally. (make defaults -j1 unless told otherwise). But it should
be possible to somehow disable it wherever it is enabled.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-32-20200327.n.0 compose check report
No missing expected images. Failed openQA tests: 3/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-32-20200326.n.0): ID: 558825 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/558825 ID: 558944 Test: x86_64 universal install_kickstart_hdd URL: https://openqa.fedoraproject.org/tests/558944 Old failures (same test failed in Fedora-32-20200326.n.0): ID: 558851 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/558851 ID: 558864 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/558864 Soft failed openQA tests: 19/171 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-32-20200326.n.0): ID: 558785 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558785 ID: 558786 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/558786 ID: 558790 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/558790 ID: 558794 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558794 ID: 558797 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/558797 ID: 558798 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/558798 ID: 558820 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/558820 ID: 558843 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/558843 ID: 558845 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/558845 ID: 558877 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/558877 ID: 558899 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/558899 ID: 558909 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/558909 ID: 558918 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558918 ID: 558927 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/558927 ID: 558943 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/558943 ID: 558951 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/558951 ID: 558952 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558952 ID: 558955 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/558955 ID: 558957 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/558957 Passed openQA tests: 149/171 (x86_64) New passes (same test not passed in Fedora-32-20200326.n.0): ID: 558823 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/558823 Skipped non-gating openQA tests: 1 of 173 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.01 to 0.24 Previous test data: https://openqa.fedoraproject.org/tests/558087#downloads Current test data: https://openqa.fedoraproject.org/tests/558828#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: System load changed from 0.57 to 0.83 Average CPU usage changed from 15.48571429 to 4.51428571 Previous test data: https://openqa.fedoraproject.org/tests/558089#downloads Current test data: https://openqa.fedoraproject.org/tests/558830#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: Used swap changed from 4 MiB to 8 MiB Previous test data: https://openqa.fedoraproject.org/tests/558090#downloads Current test data: https://openqa.fedoraproject.org/tests/558831#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 1.46 to 1.18 Average CPU usage changed from 39.62857143 to 29.05714286 Previous test data: https://openqa.fedoraproject.org/tests/558106#downloads Current test data: https://openqa.fedoraproject.org/tests/558847#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 1.06 to 1.20 Previous test data: https://openqa.fedoraproject.org/tests/558107#downloads Current test data: https://openqa.fedoraproject.org/tests/558848#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 9 MiB to 8 MiB Previous test data:
Fedora-Rawhide-20200327.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed, 4 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/171 (x86_64), 1/2 (arm) New failures (same test not failed in Fedora-Rawhide-20200326.n.0): ID: 558478 Test: x86_64 Server-dvd-iso server_remote_logging_server URL: https://openqa.fedoraproject.org/tests/558478 ID: 558480 Test: x86_64 Server-dvd-iso server_remote_logging_client URL: https://openqa.fedoraproject.org/tests/558480 ID: 558514 Test: x86_64 KDE-live-iso install_default_upload **GATING** URL: https://openqa.fedoraproject.org/tests/558514 ID: 558595 Test: x86_64 universal install_simple_free_space URL: https://openqa.fedoraproject.org/tests/558595 ID: 558601 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/558601 ID: 558613 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/558613 Old failures (same test failed in Fedora-Rawhide-20200326.n.0): ID: 558481 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/558481 ID: 558495 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/558495 ID: 558530 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/558530 Soft failed openQA tests: 21/171 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200326.n.0): ID: 558548 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/558548 ID: 558574 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/558574 Old soft failures (same test soft failed in Fedora-Rawhide-20200326.n.0): ID: 558451 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558451 ID: 558452 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/558452 ID: 558456 Test: x86_64 Server-dvd-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/558456 ID: 558460 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558460 ID: 558463 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/558463 ID: 558464 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/558464 ID: 558486 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart URL: https://openqa.fedoraproject.org/tests/558486 ID: 558509 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/558509 ID: 558511 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/558511 ID: 558543 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/558543 ID: 558565 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/558565 ID: 558575 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/558575 ID: 558584 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558584 ID: 558593 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/558593 ID: 558609 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/558609 ID: 558617 Test: x86_64 universal install_serial_console URL: https://openqa.fedoraproject.org/tests/558617 ID: 558618 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/558618 ID: 558621 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/558621 ID: 558623 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/558623 Passed openQA tests: 128/171 (x86_64) New passes (same test not passed in Fedora-Rawhide-20200326.n.0): ID: 558532 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/558532 ID: 558541 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/558541 ID: 558596 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/558596 Skipped gating openQA tests: 4/171 (x86_64) New skipped gating tests (same test not skipped in Fedora-Rawhide-20200326.n.0): ID: 558522 Test: x86_64 KDE-live-iso base_system_logging **GATING** URL: https://openqa.fedoraproject.org/tests/558522 ID: 558523 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL:
[Bug 1818111] perl-Test-Simple-1.302173 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818111 --- Comment #1 from Upstream Release Monitoring --- An HTTP error occurred downloading the package's new Source URLs: Getting https://cpan.metacpan.org/modules/by-module/Test/Test-Simple-1.302173.tar.gz to ./Test-Simple-1.302173.tar.gz -- 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 1818111] New: perl-Test-Simple-1.302173 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1818111 Bug ID: 1818111 Summary: perl-Test-Simple-1.302173 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Simple Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Latest upstream release: 1.302173 Current version/release in rawhide: 1.302172-1.fc33 URL: http://search.cpan.org/dist/Test-Simple/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/11977/ -- 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: Coq build issues in F32
On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > Jerry, I suggest this bug is real, but is also likely to be a bug in > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > You might have more luck asking the upstream developers for help. Coq issue: https://github.com/coq/coq/issues/11939 I looked around in the ocaml issue tracker and found a possibility: https://github.com/ocaml/ocaml/issues/9391 Coq uses ephemerons. -- Jerry James http://www.jamezone.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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:30 AM Zbigniew Jędrzejewski-Szmek wrote: > We are. Did you trying putting '%global _smp_mflags -j1' somewhere > near the top of the spec file? We are? Where? The spec file does this to build: make world VERBOSE=1 -- Jerry James http://www.jamezone.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: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:15:01AM -0600, Jerry James wrote: > On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote: > > Okay, I will give that a try. > > Except I can't. We're already not using %_smp_mflags. Ugh. We are. Did you trying putting '%global _smp_mflags -j1' somewhere near the top of the spec file? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Coq build issues in F32
On Fri, Mar 27, 2020 at 11:03 AM Jerry James wrote: > Okay, I will give that a try. Except I can't. We're already not using %_smp_mflags. Ugh. -- Jerry James http://www.jamezone.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: Coq build issues in F32
On Wed, Mar 25, 2020 at 10:21 PM Stephen J. Turnbull wrote: > Hi Jerry! Long time no see. Hi Stephen! It's good to hear from yet another person I've worked with via network for years. I think Richard addressed most of the points you raised. > Where is the segfault? Is it in coqc or is it in the generated code > or is it in the OCaml compiler or is it somewhere else? It's in coqc. Richard's evidence seems to point to garbage collector involvement, with weak references possibly playing a role. > Stay healthy! You, too, and likewise for everybody in the Fedora community. -- Jerry James http://www.jamezone.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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 12:02:40PM -0400, Robbie Harwood wrote: > Stephen Gallagher writes: > > > Please see the newly-updated > > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > > for more details[1]. > > This page states: [..] > > Post build result to Fedora Messaging, so that it appears in Bodhi and > > can be used as a gating test. > > So regular package updates are going to be gated on ELN. This doesn't > sound like something non-RHEL maintainers will want. What am I missing? "Can be used as a gating test" is different from "will be used for gating". What this line says is that the results from the tests will flow in with all the other test results and as very every tests at the moment, the packager maintainers can chose to gate on some tests or others, or chose not to gate their packages at all. Pierre signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Coq build issues in F32
On Thu, Mar 26, 2020 at 10:28 AM Richard W.M. Jones wrote: > I don't know, now I can't even get the ‘fedpkg local’ to reproduce it :-( > > Jerry, I suggest this bug is real, but is also likely to be a bug in > Coq (most likely) or the OCaml runtime, possibly in the Weak module. > You might have more luck asking the upstream developers for help. > > As for what to do about Fedora 32, how about disabling _smp_mflags, on > the basis that it might be load-related? That should at least reduce > the non-determinism. Okay, I will give that a try. I'm worried that even if I get a "good" build, that it's going to explode on the hapless Fedora users who install it. Thank you for all the work you put into this, Richard. I appreciate the investigation. I'll keep poking at it, too. -- Jerry James http://www.jamezone.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: proxying fedora mirrors with HTTPS
On Thu, Mar 26, 2020 at 10:54:25AM -0600, Ken Dreyer wrote: > I see pykickstart supports https URLs for --proxy, so I think I can > just do --proxy https://squid.example.com:3128 ? > > I don't understand how I would get the installer to trust my custom CA > to communicate with the HTTPS proxy, though. You should be able to use the new --sslcacert, etc. arguments. https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#url There has been some discussion about replacing them with a way to specify a full repo config file, but that hasn't gone anywhere yet so the arguments should be around at least until there is a suitable replacement for them. -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart ___ 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 32 compose report: 20200327.n.0 changes
OLD: Fedora-32-20200326.n.0 NEW: Fedora-32-20200327.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 --- Comment #3 from Fedora Update System --- FEDORA-2020-258db49abe has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-258db49abe -- 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 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 --- Comment #2 from Fedora Update System --- FEDORA-2020-f85e3cdf82 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f85e3cdf82 -- 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 1814532] perl-Encode-3.05 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814532 --- Comment #4 from Fedora Update System --- FEDORA-2020-1a094b4f91 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a094b4f91 -- 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
[rpms/perl] PR #2: Set macros subpackage noarch
ppisar commented on the pull-request: `Set macros subpackage noarch` that you are following: `` This change was implemented in perl-5.30.2-453.fc33. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl/pull-request/2 ___ 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
[rpms/perl] PR #2: Set macros subpackage noarch
ppisar closed without merging a pull-request against the project: `perl` that you are following. Closed pull-request: `` Set macros subpackage noarch `` https://src.fedoraproject.org/rpms/perl/pull-request/2 ___ 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: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
Stephen Gallagher writes: > Please see the newly-updated > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > for more details[1]. This page states: > The fix will be done via a pull request that states a time limit. We > want the regular maintainers to see / comment / commit, but we also > don't want things to stall for months and get forgotten about. What happens at the end of the time limit? Do you ProvenPackager the PR in? > What if I do not want to have %if's in my spec files? > > As long as your package builds in ELN then just maintain your package > like normal. If there is a build failure, the ELN SIG may provide a PR > as described above or will discuss alternative approaches on an > individual basis with you. So... if we don't want %ifs in our spec files, the ELN SIG will provide us some? > Post build result to Fedora Messaging, so that it appears in Bodhi and > can be used as a gating test. So regular package updates are going to be gated on ELN. This doesn't sound like something non-RHEL maintainers will want. What am I missing? > It is under discussion whether this snapshot will have its own > installation media. For now the preferred way to test ELN composes > would be to use standard Fedora Rawhide images and then include ELN as > an additional repository. Is there a dnf change that goes with this to prefer ELN content, then? > ELN artifacts will be made available for testing and development > purposes, but we will not be shipping any content produced from ELN > directly to the general public (such as on the standard mirror network > or via getfedora.org). > > ... > > Though it is a System-Wide Change it has no user-facing component. We > may announce it through other channels. I'm confused. This is going to be installable and testable, but has no user-facing component? What's a user-facing component then? Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Tue, Mar 24, 2020 at 10:32:26AM +0100, Aleksandra Fedorova wrote:
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
[snip]
It has taken me some time, but I have read through the entire thread in
addition to the change proposal. The idea sounds really interesting to me and
a lot of points have come up on the thread. I decided to group my responses
together as this single email after reading through the entire thread to make
it a bit easier to read (and to write).
TL;DR -- I think this proposal should be broken up in to 2 proposals
The turning point for me in the change proposal was the discussion of the RPM
spec file macros and getting in to the mechanics of how ELN will work. It
looks like a lot of other people had the same reaction because many of the
responses get in to the technical details and for some questions, there are no
answers yet. After thinking about it for a while, it would make sense to me
to have ELN come up in multiple phases/proposals.
Suggested Proposals:
1) ELN buildroot and install media
In this proposal, I'd like to see the ELN buildroot defined, the Koji
changes implemented, the automated builds implemented, and install media
composes happening.
The expectation here should be that it is rough around the edges. But
doing this gives the community something to see, use, and discuss further
when reviewing the next change proposals.
We should have some community goals with this proposal to capture a list of
EL vs. Fedora differences and how to address those per package and in the
context of ELN.
2) ELN lifecycle
This gets in to more of the mechanics of how ELN builds can be handled by
the community. I do not think there is a one size fits all and we should
give developers control over how best to handle this for the packages they
maintain.
The spec file macros, git branch ideas, inheritance, pull request workflow,
what builds block what composes, who is responsible for ELN failures, and
other expectations of package maintainers (both Fedora and RHEL) should be
discussed here. This proposal is definitely the policy side of things, but
I think it would be easier to talk about after #1 is done.
Having seen multiple efforts to do a "RHEL rawhide" in a way (one even called
rhel-rawhide at one point), the ELN idea is one where the work is being
targeted in the right place. As a Fedora contributor, I see RHEL as a
customer and if we can make their work easier, I want to do that. As a RHEL
package maintainer, I see Fedora as a place where I can make my job easier as
a RHEL package maintainer. The more things we get right on the community side
of things, the easier it is to produce RHEL.
Various comments from reading the thread:
* I'm not crazy about the %{?rhel} macro name. I would prefer we use 'el'
instead to cover RHEL and CentOS and EPEL. Or at least have a 'el' macro
that covers all three of those.
* I prefer the '.eln' dist tag carry a number indicating N+1 from the RHEL
major release. This should be ok in the community since Red Hat ultimately
makes the decision to version RHEL. This is an engineering decision and I
think it would help imply that ELN is _not_ meant for current RHEL. This
also lets us entertain the idea of multiple ELN major versions concurrently
should we ever want to do that.
* There has to be a deliverable for ELN. What I would prefer is a live or
install .iso. Something I can install on a spare system or in a virt
guest. If it is only available as a buildroot in Koji, that becomes "black
box" development which makes me less interested in working on it.
* There were a lot of comments about build differences between RHEL and Fedora
where certain features are disabled or build dependencies reduced (e.g.,
docs). I think this is something that the community could even discuss
rearchitecting at the package level in Fedora. Things like vim-minimal, for
instance. Having different packages built with different features
enabled/disabled. Some of these things may be easiest handled with macros
and others might be something we could handle by refactoring the packages
themselves.
* Regardless of the mechanics, there is going to be more work here. We all
need to understand the expectations of the work required of a package
maintainer and how best to coordinate with RHEL downstream. In many cases,
the package maintainers between RHEL and Fedora are the same. But in many
other cases they are not. As a community we should set some clear
guidelines on where the responsibility lies and have the right communication
workflow in place to make sure that's easy for everyone.
* On that same note, RHEL package maintainers should have an expectation to
co-maintain the corresponding package(s) in Fedora if they do not already.
Most of my comments here are on the
Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
On Fri, Mar 27, 2020 at 4:12 PM Stephen Gallagher wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > There has been a lot of (really good!) discussion on the original > proposal thread, but as it has grown too large to follow anymore, I'm > restarting it. I have made numerous changes to the Change Proposal > page to improve the scope of the proposal as well as clarify some of > the questions that have come up repeatedly in the original thread. I still think the only way to resolve conflicts (at least in some cases) will be to have the option of a separate eln branch in dist-git. Multiple people other than myself have voiced this opinion in the original thread, but this option is still not mentioned in the Change Proposal at all. Maybe my suggestions were not clear enough, so let me try again. Proposal: Use an (optional) eln branch in dist-git to resolve conflicts. ## Case 1: Improvements are applicable to both fedora and RHEL-next In this case, there should be no conflict and no need for %if spaghetti, changes can go into the master branch directly, without conditionals. The eln branch can either merge from master directly, or be a symbolic link to it (TIL about symbolic refs in git). ## Case 2: Changes can easily be expressed with %if conditionals and are clear to understand and easy to maintain In this case, I think some maintainers might accept such changes in rawhide. Same result as for Case 1. If maintainers do not accept those changes, "goto Case 3". ## Case 3: Changes are big and/or not accepted for master by the fedora maintainer In this case, conditional-based solutions are probably ugly and need special care. I assume any regular rawhide change will break ELN builds, since the conditionals will not be in effect for rawhide builds, and fedora packages will probably not care. Here, the eln branch can contain "downstream" changes, and it can be rebased on top of master/rawhide automatically. If an automatic rebase does not work, the ELN maintainer would have had to adapt the .spec file manually anyway, so it does not matter to them if this happens in the eln branch, or in the master branch (additionally, this kind of maintenance should be easier, since neither the fedora, nor the ELN maintainer has to deal with %if spaghetti!). Additionally, since you're only going to build a reduced package set for ELN, and I think you mentioned that you expect the number of packages which will require "bigger" changes to be small, this should scale very well. It would also give maintainers an "upgrade path" in the case the eln and master branches are initially the same, but would need to diverge later. I hope this makes it clearer why I think using branches as a conflict resolution tool - like for any other "release stream" - is more general, and superior to "[we] will discuss alternative approaches on an individual basis". Please at least seriously consider this suggestion - up until now, you only dismissed using branches with "this will not work / scale". Fabio > Please see the newly-updated > https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose > for more details[1]. > > == Summary == > ELN is a new buildroot and compose process for Fedora that will take > Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux > compose. Feedback from this build, compose and integration testing > will be provided to Fedora packagers so that they can see the > potential impact of their changes on RHEL development. > > == Owner == > > * Name: [[User:Bookwar| Aleksandra Fedorova]] > * Email: al...@bookwar.info > * Name: [[User:Sgallagh | Stephen Gallagher]] > * Email: sgall...@redhat.com > > > > [1] List of changes between the original and new versions: > https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569655=569549 > -BEGIN PGP SIGNATURE- > > iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo > bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K > jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ > 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D > 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z > Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ > mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg > lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED > pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q > 6DnLPiZt > =42JI > -END PGP SIGNATURE- > ___ > 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: >
Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There has been a lot of (really good!) discussion on the original proposal thread, but as it has grown too large to follow anymore, I'm restarting it. I have made numerous changes to the Change Proposal page to improve the scope of the proposal as well as clarify some of the questions that have come up repeatedly in the original thread. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. == Summary == ELN is a new buildroot and compose process for Fedora that will take Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux compose. Feedback from this build, compose and integration testing will be provided to Fedora packagers so that they can see the potential impact of their changes on RHEL development. == Owner == * Name: [[User:Bookwar| Aleksandra Fedorova]] * Email: al...@bookwar.info * Name: [[User:Sgallagh | Stephen Gallagher]] * Email: sgall...@redhat.com [1] List of changes between the original and new versions: https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569655=569549 -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q 6DnLPiZt =42JI -END PGP SIGNATURE- ___ 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
Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There has been a lot of (really good!) discussion on the original proposal thread, but as it has grown too large to follow anymore, I'm restarting it. I have made numerous changes to the Change Proposal page to improve the scope of the proposal as well as clarify some of the questions that have come up repeatedly in the original thread. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. == Summary == ELN is a new buildroot and compose process for Fedora that will take Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux compose. Feedback from this build, compose and integration testing will be provided to Fedora packagers so that they can see the potential impact of their changes on RHEL development. == Owner == * Name: [[User:Bookwar| Aleksandra Fedorova]] * Email: al...@bookwar.info * Name: [[User:Sgallagh | Stephen Gallagher]] * Email: sgall...@redhat.com [1] List of changes between the original and new versions: https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Compose=revision=569655=569549 -BEGIN PGP SIGNATURE- iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ 6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D 6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q 6DnLPiZt =42JI -END PGP SIGNATURE- ___ 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
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 27. 03. 20 v 12:48 Aleksandra Fedorova napsal(a): > On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch wrote: >> >> Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): >>> On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a): >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): >>> [snip] >> We can come up with guidelines, for example: >> >> 1) Try to find a way to resolve the issue without any conditionals >> first. >> >> There should be a reason why package X needs a dependency Y in Fedora >> and there should be a reason why it is a required dependency and not >> a >> recommended one. So why in that case downstream wants it differently? >> The first approach is just to talk through it. I can assume cases >> where downstream adds a dependency, as well as Fedora package >> removing >> them. >> >> Note that bloated dependency trees is a common problem for all binary >> distributions, it is not an "EL-thing" and we can work on that >> together. >> >> Nicolas has pointed out to another reason why we would get >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have >> this problem with ELN, as we are building Rawhide, and rpm stack is >> going to be the Rawhide rpm stack as well. >> >> 2) Minimize and isolate the conditional, and track the reason. >> >> As ELN SIG we need to have a place where we collect known reasons for >> such conditionals. The overall goal is to reduce this set, not to >> grow >> indefinitely. As Stephen said we expect it to be about couple of >> hundred packages. We will be able to track each one of them. (We have >> rpminspect to run package diffs for us). >> >> 3) In complex cases - bring it to community and FESCo. >> >> We don't know what those complex cases might be, one of the goals is >> to find them. So we keep it as an option to bring individual case to >> a >> wider audience. To ask for help and to decide on it. >> > It seems there are missing real life examples of what we sometimes do > in > RHEL, so please see attached patch. This patch is coming from RHEL > version of the espeak-ng. Now somebody tell me what it does for what > purpose and which scenario from the above three should be applied > here. > > > Vít > And here is another example for the curious. >>> Both of these examples have to do with docs generation and trying to >>> reduce dependencies for that process. "Process the man page using >>> kramdown and remove the ronn dependency." >> The point is that these types of changes are not upstreamable. And the >> conditions would also be awful. Having these changes in separate branch >> would be much preferable IMO, because honestly, I would like every >> Fedora maintainer save from this cruft not because I would like to hide >> something, but for their own sanity. > I disagree actually. > > Disabling docs to reduce dependencies makes sense. And it is not a > RHEL-only thing. I am sorry but you have not passed the test. The test question was "Now somebody tell me what it does for what purpose and which scenario from the above three should be applied here." I would really appreciate, if you could pay attention to the two patches I post and what they do. Including careful analysis why they were applied and why they were not put into Fedora nor upstreamed. Hint: They don't disable any documentation. >>> You put two patches on the thread without context. I assumed that they >>> remove the fancy dependency needed to build the doc, and instead >>> create the doc in a more "old-school" ways. >>> It maybe a wrong assumption. It happens. >>> >>> Could you then explain the context, and what these patches actually do? >> >> There is much more to this. >> >> One think of course is to limit the dependencies. So therefore we didn't >> want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned >> upstream. If Ronn is abandoned upstream, the biggest problem is with its >> dependencies, which are officially deprecated upstream. While it is >> abandoned upstream, it is still valuable tool, which can easily generate >> man pages from markdown. So now on top of the question "should we have >> Ronn in RHEL or not" you have suddenly other issues: >> >> * Should we save
Re: Missing gtk2 library in workrave - build help
On Fri, 27 Mar 2020, Lukas Zapletal wrote: Hey, I am trying to bump version of package named workrave which was not originally added by me, I have been able to fix all the issues so far except one: https://kojipkgs.fedoraproject.org//work/tasks/7540/42797540/build.log error: File not found: /builddir/build/BUILDROOT/workrave-1.10.37-1.fc33.x86_64/usr/lib64/libworkrave-gtk2-private-1.0.so.* Here is the SPEC: https://src.fedoraproject.org/rpms/workrave/blob/master/f/workrave.spec I am trying to find out why autotools is not building this library, can you give me advice how to get there? Thanks. Just from a casual glance, it appears that workrave now supports GTK3 for MATE and XFCE, so it may not build those GTK2 libraries any more if GTK3 is found. See: https://github.com/rcaelers/workrave/commit/49663e583549dccacd60461443cf3651ea0ac9a3 Scott ___ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Hi, Miro,
On Fri, Mar 27, 2020 at 12:35 PM Miro Hrončok wrote:
>
> On 26. 03. 20 16:13, Miro Hrončok wrote:
> > On 25. 03. 20 17:10, Miro Hrončok wrote:
> >>> Finally, of the set of packages that we're going to be including, we
> >>> anticipate around 200-300 of them will have distro conditionals that
> >>> need investigation (with fewer needing actual modification). The ELN
> >>> SIG will be doing this initial investigation and will provide guidance
> >>> (and/or PRs) to affected packagers.
> >>
> >> My concerns still remain, although I am now not so scared that this will
> >> alienate the community. Now the concern is more personal (= previously I
> >> was
> >> worried that everybody will be encouraged to use the conditionals, while
> >> now
> >> I'm mostly concerned they I will be encouraged to use the conditionals).
> >
> > Also, to make this more clear:
> >
> > I am not worried about the conditionals because I would need to maintain
> > them.
> >
> > I am worried that "my" packages will be harder to co-maintain (or generally
> > changed) by people from the community.
> >
> > As an example, I will know the RHEL 9 (10, 11...) plans and I can structure
> > my
> > specs accordingly. However if there is a passionate Fedora contributor who
> > would
> > like so submit a Pull Request for e.g. python-virtualenv to update it to a
> > new
> > fancy version that does things differently, they are not familiar about our
> > RHEL
> > plans and they would not be capable to wrap their head around such
> > conditionals.
> > They would also need to rebase any RHEL-only patches for this to work. At
> > the
> > end, they are more likely to just go away and not do it at all.
>
> Another example. In a corporate meeting with the product owners/managers, we
> decide that the next major RHEL release will include Brainfuck 7 because it an
> LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice
> and
> fine.
>
> Later, Brainfuck 8 is released. The Fedora community wants this new version,
> because it finally has a support for Brainloller and the Ook! stack depends on
> this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL
> perspective, this new feature is not that important. But the Ook! SIG
> obviously
> wants this.
>
> The RHEL maintainer now needs to artificially block the Brainfuck 8 update
> from
> rawhide until next RHEL is branched (they probably cannot even share when this
> is going to be with the Fedora community because NDA). This prevents the
> "First"
> foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer
> is
> actively blocking the Ook SIG here by their (in)action).
>
>
> The conditional approach will only allow this:
>
>%if 0%{?rhel}
>Version: 7.4.5
>%else
>Version: 8.0.0~rc1
>%endif
>
> (And I assume the rest of the spec file would need major %if/%else mess as
> well,
> because Brainfuck 8 is built with meson, while Brainfuck 7 is built with
> autotools. Or the implementation language changed from C to Rust...)
Thank you for bringing this example.
I agree with your point that in case of choices like this,
conditionals do not make sense. It is a branch. But this branch in my
opinion has nothing to do with ELN.
ELN is not RHEL. It is a development tool, which gives us a preview,
so that we can plan the work better. We are not planning to release
RHEL from ELN packages.
Therefore ELN is all about the form, not the content. The goal of this
project is to apply downstream form to Fedora Rawhide content and see
what issues RHEL or downstream in general will have in the future. But
the work itself doesn't always have to happen in Fedora Rawhide. ELN
doesn't bring any new changes here, as you keep working with upstream
and downstream the way you as package maintainer worked before.
So while we may ask for some adjustments to Fedora spec files to fit
into that EL-form, these adjustments are structural. And in the case
you have described I am against branching not because I would like to
have conditional instead, but because I don't want to fork Fedora
Rawhide content into something else in ELN at all.
I think the kind of branching you have described should happen
somewhere down the line, in RHEL(CentOS Stream maybe).
> And trust me, you don't want to maintain that. It is not maintainable. And it
> has problems like this:
>https://pagure.io/copr/copr/issue/1315
If I understand it correctly, this only illustrates the issue which
may happen, not the example itself. As the reasons to have conditional
in that particular spec file are not relevant to ELN.
> Another approach is compat packages, but Brainfuck 8 is backwards compatible
> with 7, so it brings no benefit for Fedora.
>
> Another approach is modularity, but the Ook! SIG doesn't want to use modules
> because they want their Ook-based apps to be easily available to Fedora users.
>
> Sorry for going artificial with the example, but I didn't want you
Missing gtk2 library in workrave - build help
Hey, I am trying to bump version of package named workrave which was not originally added by me, I have been able to fix all the issues so far except one: https://kojipkgs.fedoraproject.org//work/tasks/7540/42797540/build.log error: File not found: /builddir/build/BUILDROOT/workrave-1.10.37-1.fc33.x86_64/usr/lib64/libworkrave-gtk2-private-1.0.so.* Here is the SPEC: https://src.fedoraproject.org/rpms/workrave/blob/master/f/workrave.spec I am trying to find out why autotools is not building this library, can you give me advice how to get there? Thanks. ___ 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 1814708] perl-PAR-Packer needs a rebuild against new perl 5.30.2 that just landed in stable F31 repositories
https://bugzilla.redhat.com/show_bug.cgi?id=1814708 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-PAR-Packer-1.049-5.fc3 |perl-PAR-Packer-1.049-5.fc3 |2 |2 ||perl-PAR-Packer-1.049-4.fc3 ||1 --- Comment #8 from Fedora Update System --- FEDORA-2020-0c6896a3d0 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Encode-3.04-443.fc33 |perl-Encode-3.04-443.fc33 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-13.fc30|perl-Encode-3.04-13.fc30 ||perl-Encode-3.04-442.fc31 --- Comment #8 from Fedora Update System --- FEDORA-2020-6e5d750f08 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1808956] perl-Encode-3.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808956 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Encode-3.03-442.fc33 |perl-Encode-3.03-442.fc33 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-13.fc30|perl-Encode-3.04-13.fc30 ||perl-Encode-3.04-442.fc31 --- Comment #12 from Fedora Update System --- FEDORA-2020-6e5d750f08 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: ActionNotAllowed: policy violation (build_from_srpm)
Facepalm. ___ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On 3/27/20 1:32 PM, Miro Hrončok wrote:
>
The conditional approach will only allow this:
%if 0%{?rhel}
Version: 7.4.5
%else
Version: 8.0.0~rc1
%endif
(And I assume the rest of the spec file would need major %if/%else mess
as well, because Brainfuck 8 is built with meson, while Brainfuck 7 is
built with autotools. Or the implementation language changed from C to
Rust...)
And trust me, you don't want to maintain that. It is not maintainable.
And it has problems like this:
https://pagure.io/copr/copr/issue/1315
Ough.
- Panu -
___
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: Need help from Provenpackager
Thank you! ___ 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
Please keep an eye on AskFedora as we approach F32 release
Hello, Just a general request: could more community folks please spend a few minutes a day to check AskFedora[1]. With the beta release, we're already seeing some users asking questions, which often turn out to be bugs. So, if the package maintainers in the community can please keep an eye on these, that'll be helpful. https://ask.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Need help from Provenpackager
On 27. 03. 20 12:31, Artem Tim wrote: Hello! Lutris broken completely on F32 and many users asking what happens with package. Lutris always up to day in Fedora and i personally doesn't have any issues with it or all this time until this, but seems like this time ' bunnyapocalypse' just busy [1] to fix it and merge my PR [2]. Can we merge PR and build it for F32? It's already tested and it works. [1] https://src.fedoraproject.org/rpms/lutris/pull-request/1#comment-36580 [2] https://src.fedoraproject.org/rpms/lutris/pull-request/2 Done. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5481ea07eb -- 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
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 11:00 AM Vít Ondruch wrote: > > > Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): > > On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: > >> > >> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > >>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: > Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: > >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > > [snip] > We can come up with guidelines, for example: > > 1) Try to find a way to resolve the issue without any conditionals > first. > > There should be a reason why package X needs a dependency Y in Fedora > and there should be a reason why it is a required dependency and not > a > recommended one. So why in that case downstream wants it differently? > The first approach is just to talk through it. I can assume cases > where downstream adds a dependency, as well as Fedora package > removing > them. > > Note that bloated dependency trees is a common problem for all binary > distributions, it is not an "EL-thing" and we can work on that > together. > > Nicolas has pointed out to another reason why we would get > EL-conditionals: the outdated rpm stack in RHEL. But we don't have > this problem with ELN, as we are building Rawhide, and rpm stack is > going to be the Rawhide rpm stack as well. > > 2) Minimize and isolate the conditional, and track the reason. > > As ELN SIG we need to have a place where we collect known reasons for > such conditionals. The overall goal is to reduce this set, not to > grow > indefinitely. As Stephen said we expect it to be about couple of > hundred packages. We will be able to track each one of them. (We have > rpminspect to run package diffs for us). > > 3) In complex cases - bring it to community and FESCo. > > We don't know what those complex cases might be, one of the goals is > to find them. So we keep it as an option to bring individual case to > a > wider audience. To ask for help and to decide on it. > > >>> It seems there are missing real life examples of what we sometimes do > >>> in > >>> RHEL, so please see attached patch. This patch is coming from RHEL > >>> version of the espeak-ng. Now somebody tell me what it does for what > >>> purpose and which scenario from the above three should be applied > >>> here. > >>> > >>> > >>> Vít > >>> > >> And here is another example for the curious. > >> > > Both of these examples have to do with docs generation and trying to > > reduce dependencies for that process. "Process the man page using > > kramdown and remove the ronn dependency." > The point is that these types of changes are not upstreamable. And the > conditions would also be awful. Having these changes in separate branch > would be much preferable IMO, because honestly, I would like every > Fedora maintainer save from this cruft not because I would like to hide > something, but for their own sanity. > >>> I disagree actually. > >>> > >>> Disabling docs to reduce dependencies makes sense. And it is not a > >>> RHEL-only thing. > >> > >> I am sorry but you have not passed the test. The test question was "Now > >> somebody tell me what it does for what > >> purpose and which scenario from the above three should be applied here." > >> I would really appreciate, if you could pay attention to the two > >> patches I post and what they do. Including careful analysis why they > >> were applied and why they were not put into Fedora nor upstreamed. > >> > >> Hint: They don't disable any documentation. > > You put two patches on the thread without context. I assumed that they > > remove the fancy dependency needed to build the doc, and instead > > create the doc in a more "old-school" ways. > > It maybe a wrong assumption. It happens. > > > > Could you then explain the context, and what these patches actually do? > > > There is much more to this. > > One think of course is to limit the dependencies. So therefore we didn't > want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned > upstream. If Ronn is abandoned upstream, the biggest problem is with its > dependencies, which are officially deprecated upstream. While it is > abandoned upstream, it is still valuable tool, which can easily generate > man pages from markdown. So now on top of the question "should we have > Ronn in RHEL or not" you have suddenly other issues: > > * Should we save upstream Ronn? And how to do this if upstream is >
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 27. 03. 20 v 12:32 Miro Hrončok napsal(a): > > And trust me, you don't want to maintain that. It is not maintainable. > And it has problems like this: > https://pagure.io/copr/copr/issue/1315 > Heh, nice one :) Thanks for sharing Vít ___ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On 26. 03. 20 16:13, Miro Hrončok wrote:
On 25. 03. 20 17:10, Miro Hrončok wrote:
Finally, of the set of packages that we're going to be including, we
anticipate around 200-300 of them will have distro conditionals that
need investigation (with fewer needing actual modification). The ELN
SIG will be doing this initial investigation and will provide guidance
(and/or PRs) to affected packagers.
My concerns still remain, although I am now not so scared that this will
alienate the community. Now the concern is more personal (= previously I was
worried that everybody will be encouraged to use the conditionals, while now
I'm mostly concerned they I will be encouraged to use the conditionals).
Also, to make this more clear:
I am not worried about the conditionals because I would need to maintain them.
I am worried that "my" packages will be harder to co-maintain (or generally
changed) by people from the community.
As an example, I will know the RHEL 9 (10, 11...) plans and I can structure my
specs accordingly. However if there is a passionate Fedora contributor who would
like so submit a Pull Request for e.g. python-virtualenv to update it to a new
fancy version that does things differently, they are not familiar about our RHEL
plans and they would not be capable to wrap their head around such conditionals.
They would also need to rebase any RHEL-only patches for this to work. At the
end, they are more likely to just go away and not do it at all.
Another example. In a corporate meeting with the product owners/managers, we
decide that the next major RHEL release will include Brainfuck 7 because it an
LTS release. Fedora rawhide is updated to Brainfuck 7 and everything is nice and
fine.
Later, Brainfuck 8 is released. The Fedora community wants this new version,
because it finally has a support for Brainloller and the Ook! stack depends on
this new feature. The Ook! stack is not planned to be in RHEL, so from RHEL
perspective, this new feature is not that important. But the Ook! SIG obviously
wants this.
The RHEL maintainer now needs to artificially block the Brainfuck 8 update from
rawhide until next RHEL is branched (they probably cannot even share when this
is going to be with the Fedora community because NDA). This prevents the "First"
foundation of Fedora (and TBH it also prevents "Friends", the RHEL maintainer is
actively blocking the Ook SIG here by their (in)action).
The conditional approach will only allow this:
%if 0%{?rhel}
Version: 7.4.5
%else
Version: 8.0.0~rc1
%endif
(And I assume the rest of the spec file would need major %if/%else mess as well,
because Brainfuck 8 is built with meson, while Brainfuck 7 is built with
autotools. Or the implementation language changed from C to Rust...)
And trust me, you don't want to maintain that. It is not maintainable. And it
has problems like this:
https://pagure.io/copr/copr/issue/1315
Another approach is compat packages, but Brainfuck 8 is backwards compatible
with 7, so it brings no benefit for Fedora.
Another approach is modularity, but the Ook! SIG doesn't want to use modules
because they want their Ook-based apps to be easily available to Fedora users.
Sorry for going artificial with the example, but I didn't want you to say "you
are always talking about Python, what you say is Python specific" -- because it
isn't.
--
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
Need help from Provenpackager
Hello! Lutris broken completely on F32 and many users asking what happens with package. Lutris always up to day in Fedora and i personally doesn't have any issues with it or all this time until this, but seems like this time ' bunnyapocalypse' just busy [1] to fix it and merge my PR [2]. Can we merge PR and build it for F32? It's already tested and it works. [1] https://src.fedoraproject.org/rpms/lutris/pull-request/1#comment-36580 [2] https://src.fedoraproject.org/rpms/lutris/pull-request/2 ___ 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
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9190462510 ckeditor-4.14.0-1.el6 3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0c0d9690e1 drupal6-6.38-3.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing R-RInside-0.2.16-1.el6 R-Rcpp-1.0.4-2.el6 Details about builds: R-RInside-0.2.16-1.el6 (FEDORA-EPEL-2020-7400646e03) C++ Classes to Embed R in C++ (and C) Applications Update Information: R-Rcpp 1.0.4 R-RInside 0.2.16 ChangeLog: * Fri Mar 20 2020 Mattias Ellert - 0.2.16-1 - New release 0.2.16 * Tue Jan 28 2020 Fedora Release Engineering - 0.2.15-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Sat Sep 14 2019 Mattias Ellert - 0.2.15-5 - Unify specfile * Mon Aug 12 2019 Elliott Sales de Andrade - 0.2.15-4 - Remove explicit dependencies provided by automatic dependency generator * Mon Aug 12 2019 Elliott Sales de Andrade - 0.2.15-3 - Rebuild with automatic Provides * Wed Jul 24 2019 Fedora Release Engineering - 0.2.15-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild References: [ 1 ] Bug #1815451 - Version 1.0.4 was released, please update it https://bugzilla.redhat.com/show_bug.cgi?id=1815451 R-Rcpp-1.0.4-2.el6 (FEDORA-EPEL-2020-7400646e03) Seamless R and C++ Integration Update Information: R-Rcpp 1.0.4 R-RInside 0.2.16 ChangeLog: * Sat Mar 21 2020 Mattias Ellert - 1.0.4-2 - Fix for linking error seen when using root's R interface: "You are probably missing the definition of Rcpp::demangler_one(char const*)" * Fri Mar 20 2020 Mattias Ellert - 1.0.4-1 - Update to 1.0.4 - The package no longer uses knitr for vignettes, drop --ignore-vignettes * Tue Jan 28 2020 Fedora Release Engineering - 1.0.3-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild * Thu Nov 21 2019 Elliott Sales de Andrade - 1.0.3-2 - Exclude Suggests for unavailable packages References: [ 1 ] Bug #1815451 - Version 1.0.4 was released, please update it https://bugzilla.redhat.com/show_bug.cgi?id=1815451 ___ 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
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On 27. 03. 20 10:59, Vít Ondruch wrote: As you can see, there is much more to this just to "put some conditional somewhere". There are very complex considerations and a lot of work. I would also like to point out the obvious: The RHEL only patch needs to be rebased every time the package is updated to a new version. - RHEL doesn't generally do updates like this - Fedora generally does updates like this often A Fedora contributor will try to build the updated package in mock and it will work, they will submit a PR (better case) or push directly. When the package is attempted to be built in ELN, the patch(es) won't apply. If the update was submitted via a PR and the PR pipeline/CI will provide this kind of feedback, the Fedora contributor will be intimidated by this. If the package will be gated on ELN, the Fedora contributor will be intimidated by this. If there is no gating and there is a direct push, the ELN build will be broken. The RHEL/ELN maintianer will need to push a fixup patch-rebase commit or live with a broken ELN package. This might happen several times between RHEL 8 and 9, while the patch would only be rebased/created once trough 1 major RHEL release lifetime. -- 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
Re: ActionNotAllowed: policy violation (build_from_srpm)
Lukas Zapletal píše v Pá 27. 03. 2020 v 10:30 +: > Hey guys, I am trying to build a SRPM since mockbuild does not work > due to (1). > > # fedpkg srpm > # fedpkg build --srpm /home/lzap/work/fedpkg/workrave/workrave- > 1.10.37-1.fc33.src.rpm Real builds from SRPM are not allowed for Fedora packages (and IMO never were). Use a scratch build for testing: fedpkg scratch-build --srpm ... > But getting %SUBJ%: > https://koji.fedoraproject.org/koji/taskinfo?taskID=42794359 > > What is wrong? I believe my kerberos is correct: > > # kinit > Ticket cache: KEYRING:persistent:1000:1000 > Default principal: l...@fedoraproject.org > > Valid starting Expires Service principal > 27.3.2020 11:19:54 28.3.2020 08:57:58 > HTTP/koji.fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > 27.3.2020 10:21:05 28.3.2020 08:57:58 > HTTP/src.fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > 27.3.2020 08:57:59 28.3.2020 08:57:58 > krbtgt/fedoraproject@fedoraproject.org > renew until 3.4.2020 09:57:58 > > (1) https://bugzilla.redhat.com/show_bug.cgi?id=1812872 > ___ > 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 ___ 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 1808956] perl-Encode-3.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808956 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Encode-3.03-442.fc33 |perl-Encode-3.03-442.fc33 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-443.fc32 ||perl-Encode-3.04-13.fc30 --- Comment #11 from Fedora Update System --- FEDORA-2020-7eb53be2a5 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 Fedora Update System changed: What|Removed |Added Fixed In Version|perl-Encode-3.04-443.fc33 |perl-Encode-3.04-443.fc33 |perl-Encode-3.04-443.fc32 |perl-Encode-3.04-443.fc32 ||perl-Encode-3.04-13.fc30 --- Comment #7 from Fedora Update System --- FEDORA-2020-7eb53be2a5 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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
ActionNotAllowed: policy violation (build_from_srpm)
Hey guys, I am trying to build a SRPM since mockbuild does not work due to (1). # fedpkg srpm # fedpkg build --srpm /home/lzap/work/fedpkg/workrave/workrave-1.10.37-1.fc33.src.rpm But getting %SUBJ%: https://koji.fedoraproject.org/koji/taskinfo?taskID=42794359 What is wrong? I believe my kerberos is correct: # kinit Ticket cache: KEYRING:persistent:1000:1000 Default principal: l...@fedoraproject.org Valid starting Expires Service principal 27.3.2020 11:19:54 28.3.2020 08:57:58 HTTP/koji.fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 27.3.2020 10:21:05 28.3.2020 08:57:58 HTTP/src.fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 27.3.2020 08:57:59 28.3.2020 08:57:58 krbtgt/fedoraproject@fedoraproject.org renew until 3.4.2020 09:57:58 (1) https://bugzilla.redhat.com/show_bug.cgi?id=1812872 ___ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 27. 03. 20 v 10:16 Aleksandra Fedorova napsal(a): > On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: >> >> Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): >>> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: >> Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): >>> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > [snip] We can come up with guidelines, for example: 1) Try to find a way to resolve the issue without any conditionals first. There should be a reason why package X needs a dependency Y in Fedora and there should be a reason why it is a required dependency and not a recommended one. So why in that case downstream wants it differently? The first approach is just to talk through it. I can assume cases where downstream adds a dependency, as well as Fedora package removing them. Note that bloated dependency trees is a common problem for all binary distributions, it is not an "EL-thing" and we can work on that together. Nicolas has pointed out to another reason why we would get EL-conditionals: the outdated rpm stack in RHEL. But we don't have this problem with ELN, as we are building Rawhide, and rpm stack is going to be the Rawhide rpm stack as well. 2) Minimize and isolate the conditional, and track the reason. As ELN SIG we need to have a place where we collect known reasons for such conditionals. The overall goal is to reduce this set, not to grow indefinitely. As Stephen said we expect it to be about couple of hundred packages. We will be able to track each one of them. (We have rpminspect to run package diffs for us). 3) In complex cases - bring it to community and FESCo. We don't know what those complex cases might be, one of the goals is to find them. So we keep it as an option to bring individual case to a wider audience. To ask for help and to decide on it. >>> It seems there are missing real life examples of what we sometimes do in >>> RHEL, so please see attached patch. This patch is coming from RHEL >>> version of the espeak-ng. Now somebody tell me what it does for what >>> purpose and which scenario from the above three should be applied here. >>> >>> >>> Vít >>> >> And here is another example for the curious. >> > Both of these examples have to do with docs generation and trying to > reduce dependencies for that process. "Process the man page using > kramdown and remove the ronn dependency." The point is that these types of changes are not upstreamable. And the conditions would also be awful. Having these changes in separate branch would be much preferable IMO, because honestly, I would like every Fedora maintainer save from this cruft not because I would like to hide something, but for their own sanity. >>> I disagree actually. >>> >>> Disabling docs to reduce dependencies makes sense. And it is not a >>> RHEL-only thing. >> >> I am sorry but you have not passed the test. The test question was "Now >> somebody tell me what it does for what >> purpose and which scenario from the above three should be applied here." >> I would really appreciate, if you could pay attention to the two >> patches I post and what they do. Including careful analysis why they >> were applied and why they were not put into Fedora nor upstreamed. >> >> Hint: They don't disable any documentation. > You put two patches on the thread without context. I assumed that they > remove the fancy dependency needed to build the doc, and instead > create the doc in a more "old-school" ways. > It maybe a wrong assumption. It happens. > > Could you then explain the context, and what these patches actually do? There is much more to this. One think of course is to limit the dependencies. So therefore we didn't want rubygem-ronn in RHEL. But even if we wanted, it is [1] abandoned upstream. If Ronn is abandoned upstream, the biggest problem is with its dependencies, which are officially deprecated upstream. While it is abandoned upstream, it is still valuable tool, which can easily generate man pages from markdown. So now on top of the question "should we have Ronn in RHEL or not" you have suddenly other issues: * Should we save upstream Ronn? And how to do this if upstream is unresponsive. * How to provide the documentation to our users if we don't have Ronn available. * Should I go to Fedora and push the Ronn removal out of the package and possible from all packages, while we still have Ronn in Fedora? * Should I go to all upstreams and convince them, that they should not use Ronn, just
[Bug 1817061] perl-Gnome2-Vte is missing in Fedora V32?
https://bugzilla.redhat.com/show_bug.cgi?id=1817061 Petr Pisar changed: What|Removed |Added Depends On||1817875 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1817875 [Bug 1817875] Review Request: perl-Gnome2-Vte - Perl interface to the Gtk2 Virtual Terminal Emulation library -- 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Thu, Mar 26, 2020 at 3:55 PM Petr Viktorin wrote:
>
> On 2020-03-25 17:33, Aleksandra Fedorova wrote:
> > [Branching] removes community maintainer from the conversation about what
> > downstream is doing. While we want to give community member a voice in
> > that conversation.
>
> I fear that this proposal *forces* the community member to participate
> in the discussion. That is a very different thing than giving them a voice.
>
>
> On 2020-03-25 17:10, Miro Hrončok wrote:
> > On 25. 03. 20 16:47, Stephen Gallagher wrote:
> >> I think we managed to miss a few key points in the Change Proposal
> >> which is directly resulting in a bit of the confusion here.
> >
> > Reading the rest of you e-mail I must agree that this is what happened.
> > Would you mind putting the change back to incomplete state and resend it
> > once more for feedback once this is addressed?
> >
> >> The first and most important of these is that ELN will*not* be
> >> building the complete Fedora package set. We're going to be building a
> >> selected subset of packages (derived from packages in RHEL 8 and
> >> EPEL). Our current expectation is that we are going to be looking at
> >> fewer than 2500 source packages. We are still working up the initial
> >> list of these and we will update the Change Proposal with it (as well
> >> as providing a fedora-devel post breaking down the known owners).
> >
> > Glad to hear that.
> >
> >> Second, from this reduced subset, we expect that the overwhelming
> >> majority of the maintainers are Red Hat employees that already work on
> >> RHEL. With this in mind, we think that the level of concern about how
> >> this will affect non-Red Hat contributors is premature. We will reach
> >> out directly to those non-Red Hat contributors we identify.
>
> This actually worries me very much.
>
> The subset of packages will need to form a working system; it will
> include the most important packages. I hope this doesn't end up limiting
> maintainers of Fedora's most central packages to only Red Hatters or
> those that agree to play by RHEL rules that they have no say in.
>
> I am pretty sure that most packages/packagers will be OK with the ELN
> change. But "most" is not enough. We do need to take the "worst cases"
> into account. Consider a package that:
> - is needed in RHEL, but only as a dependency of something vital; the
> RHEL maintainer doesn't care too much about it outside their work duties
> - has an enthusiastic packager in Fedora, who prefers to leave RHEL work
> to paid developers
>
> (As member of a team that, some time ago, used to be catch-all RHEL
> maintainer for anything that happened to be written in Python, I can
> definitely imagine situations similar to this.)
>
> For such a package, we need to avoid pushing ELN macros into the
> package, otherwise we lose an enthusiastic contributor who does amazing
> work in Fedora.
>
> Such a package might even be hypothetical right now, but the case still
> needs to be adressed. A package can fall into this category at any time
> in the future. It's not enough to identifying packagers that are
> affected now, and work with them. There needs to be a process for cases
> like these, and it can't be "merge these ELN macros now, there's a
> deadline coming; maybe we'll come up with a better process in the
> future". (Especially if Red Hat is unlikely to drive setting up a better
> process.)
>
> IMO, any changes needed in EL need to be opt-in, with the understanding
> that opting in will be (almost always) beneficial for everyone involved.
> They need to feel like a gift ("Hello fedora packager, please accept
> this PR with EL macros; it'll make it easier to work on this together!")
> rather than forced ("Red Hat needs this; merge it or else").
I wonder how we ended up with people feeling like we are proposing
latter rather than the former.
I guess I took couple of wrong turns in this discussion, and I'd like
to step back and try again.
Me, Stephen and Troy are going to update the proposal, and come up
with a better description of how opt-in will look like.
> To borrow Neal Gompa's words, ELN needs to not feel "like it's written
> for Red Hat people to move their sandbox outside of Red Hat into Fedora
> without anyone else to be able to play in the sandbox."
>
>
> For ELN changes to be to be opt-in, there essentially needs to be a
> place to diverge -- a place for ELN hotfixes to live while polishing
> them and debating their usefulness in Fedora and further upstreams.
> Here by "hotfix" I need something required in RHEL that is not yet ready
> for upstream. It is healthy to have a place for such things: it removes
> time pressure from discussions (people from the community very often
> have good ideas but less time), but allows the fix to be used now (so
> the rest of ELN isn't blocked).
> Forks are good if they're not permanent (but, making them not permanent
> needs effort).
>
>
> As Miro Hrončok continues:
> > As a Red employee if I need to
Re: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
On Fri, Mar 27, 2020 at 9:36 AM Vít Ondruch wrote: > > > Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a): > > On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote: > >> > >> Dne 25. 03. 20 v 20:22 James Cassell napsal(a): > >>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote: > Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a): > > Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a): > >>> [snip] > >> We can come up with guidelines, for example: > >> > >> 1) Try to find a way to resolve the issue without any conditionals > >> first. > >> > >> There should be a reason why package X needs a dependency Y in Fedora > >> and there should be a reason why it is a required dependency and not a > >> recommended one. So why in that case downstream wants it differently? > >> The first approach is just to talk through it. I can assume cases > >> where downstream adds a dependency, as well as Fedora package removing > >> them. > >> > >> Note that bloated dependency trees is a common problem for all binary > >> distributions, it is not an "EL-thing" and we can work on that > >> together. > >> > >> Nicolas has pointed out to another reason why we would get > >> EL-conditionals: the outdated rpm stack in RHEL. But we don't have > >> this problem with ELN, as we are building Rawhide, and rpm stack is > >> going to be the Rawhide rpm stack as well. > >> > >> 2) Minimize and isolate the conditional, and track the reason. > >> > >> As ELN SIG we need to have a place where we collect known reasons for > >> such conditionals. The overall goal is to reduce this set, not to grow > >> indefinitely. As Stephen said we expect it to be about couple of > >> hundred packages. We will be able to track each one of them. (We have > >> rpminspect to run package diffs for us). > >> > >> 3) In complex cases - bring it to community and FESCo. > >> > >> We don't know what those complex cases might be, one of the goals is > >> to find them. So we keep it as an option to bring individual case to a > >> wider audience. To ask for help and to decide on it. > >> > > It seems there are missing real life examples of what we sometimes do in > > RHEL, so please see attached patch. This patch is coming from RHEL > > version of the espeak-ng. Now somebody tell me what it does for what > > purpose and which scenario from the above three should be applied here. > > > > > > Vít > > > And here is another example for the curious. > > >>> Both of these examples have to do with docs generation and trying to > >>> reduce dependencies for that process. "Process the man page using > >>> kramdown and remove the ronn dependency." > >> > >> The point is that these types of changes are not upstreamable. And the > >> conditions would also be awful. Having these changes in separate branch > >> would be much preferable IMO, because honestly, I would like every > >> Fedora maintainer save from this cruft not because I would like to hide > >> something, but for their own sanity. > > I disagree actually. > > > > Disabling docs to reduce dependencies makes sense. And it is not a > > RHEL-only thing. > > > I am sorry but you have not passed the test. The test question was "Now > somebody tell me what it does for what > purpose and which scenario from the above three should be applied here." > I would really appreciate, if you could pay attention to the two > patches I post and what they do. Including careful analysis why they > were applied and why they were not put into Fedora nor upstreamed. > > Hint: They don't disable any documentation. You put two patches on the thread without context. I assumed that they remove the fancy dependency needed to build the doc, and instead create the doc in a more "old-school" ways. It maybe a wrong assumption. It happens. Could you then explain the context, and what these patches actually do? > Thank you. > > > Vít > > > P.S. I really thinking if I should write this and if and how much I am > offended, because I typically try to remove my feeling from these > discussions. But really, I and other colleagues have spent quite some > effort to untangle the whole dependency mess, to provide our users as > much as we can, to give back to fedora and upstream as much as we can > and stay sane. That were not easy decisions. > > I spent the time to dig out these specific examples of what we did and > why I think it is important to have branches instead of "just > conditions", but you don't pay enough attention and you dismiss them as > "Disabling docs". I am sorry, but this is not fair. If I were offended every time people don't get my point and the effort I made to make it, I would give up about 15 years ago. But that is what discussions are all about: going through a lot of misunderstanding, trying to actually reach the point where we can
[Bug 1817021] Upgrade perl-Type-Tiny to 1.010001
https://bugzilla.redhat.com/show_bug.cgi?id=1817021 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Type-Tiny-1.010001-1.f ||c33 ||perl-Type-Tiny-1.010001-1.f ||c32 Resolution|--- |RAWHIDE Last Closed||2020-03-27 09:07:14 --- Comment #1 from Jitka Plesnikova --- perl-Type-Tiny-1.010001-1.fc33 and perl-Type-Tiny-1.010001-1.fc32 build by corsepiu -- 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 1817015] Upgrade perl-File-Slurp to 9999.30
https://bugzilla.redhat.com/show_bug.cgi?id=1817015 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-File-Slurp-.30-1.f ||c33 Resolution|--- |RAWHIDE Last Closed||2020-03-27 09:05:25 --- Comment #1 from Jitka Plesnikova --- perl-File-Slurp-.30-1.fc33 build by corsepiu -- 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 1817797] perl-App-cpm-0.990 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817797 --- Comment #1 from Fedora Update System --- FEDORA-2020-2b35f0ffcf has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b35f0ffcf -- 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 1817797] perl-App-cpm-0.990 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817797 Jitka Plesnikova changed: What|Removed |Added Status|NEW |MODIFIED Fixed In Version||perl-App-cpm-0.990-1.fc33 ||perl-App-cpm-0.990-1.fc32 Doc Type|--- |If docs needed, set a value -- 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
Fedora-Cloud-31-20200327.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: Fedora 33 System-Wide Change proposal: ELN Buildroot and Compose
Dne 26. 03. 20 v 12:39 Aleksandra Fedorova napsal(a):
> On Thu, Mar 26, 2020 at 10:34 AM Vít Ondruch wrote:
>>
>> Dne 25. 03. 20 v 20:22 James Cassell napsal(a):
>>> On Wed, Mar 25, 2020, at 1:18 PM, Vít Ondruch wrote:
Dne 25. 03. 20 v 18:06 Vít Ondruch napsal(a):
> Dne 25. 03. 20 v 17:33 Aleksandra Fedorova napsal(a):
>>> [snip]
>> We can come up with guidelines, for example:
>>
>> 1) Try to find a way to resolve the issue without any conditionals first.
>>
>> There should be a reason why package X needs a dependency Y in Fedora
>> and there should be a reason why it is a required dependency and not a
>> recommended one. So why in that case downstream wants it differently?
>> The first approach is just to talk through it. I can assume cases
>> where downstream adds a dependency, as well as Fedora package removing
>> them.
>>
>> Note that bloated dependency trees is a common problem for all binary
>> distributions, it is not an "EL-thing" and we can work on that
>> together.
>>
>> Nicolas has pointed out to another reason why we would get
>> EL-conditionals: the outdated rpm stack in RHEL. But we don't have
>> this problem with ELN, as we are building Rawhide, and rpm stack is
>> going to be the Rawhide rpm stack as well.
>>
>> 2) Minimize and isolate the conditional, and track the reason.
>>
>> As ELN SIG we need to have a place where we collect known reasons for
>> such conditionals. The overall goal is to reduce this set, not to grow
>> indefinitely. As Stephen said we expect it to be about couple of
>> hundred packages. We will be able to track each one of them. (We have
>> rpminspect to run package diffs for us).
>>
>> 3) In complex cases - bring it to community and FESCo.
>>
>> We don't know what those complex cases might be, one of the goals is
>> to find them. So we keep it as an option to bring individual case to a
>> wider audience. To ask for help and to decide on it.
>>
> It seems there are missing real life examples of what we sometimes do in
> RHEL, so please see attached patch. This patch is coming from RHEL
> version of the espeak-ng. Now somebody tell me what it does for what
> purpose and which scenario from the above three should be applied here.
>
>
> Vít
>
And here is another example for the curious.
>>> Both of these examples have to do with docs generation and trying to reduce
>>> dependencies for that process. "Process the man page using kramdown and
>>> remove the ronn dependency."
>>
>> The point is that these types of changes are not upstreamable. And the
>> conditions would also be awful. Having these changes in separate branch
>> would be much preferable IMO, because honestly, I would like every
>> Fedora maintainer save from this cruft not because I would like to hide
>> something, but for their own sanity.
> I disagree actually.
>
> Disabling docs to reduce dependencies makes sense. And it is not a
> RHEL-only thing.
I am sorry but you have not passed the test. The test question was "Now
somebody tell me what it does for what
purpose and which scenario from the above three should be applied here."
I would really appreciate, if you could pay attention to the two
patches I post and what they do. Including careful analysis why they
were applied and why they were not put into Fedora nor upstreamed.
Hint: They don't disable any documentation.
Thank you.
Vít
P.S. I really thinking if I should write this and if and how much I am
offended, because I typically try to remove my feeling from these
discussions. But really, I and other colleagues have spent quite some
effort to untangle the whole dependency mess, to provide our users as
much as we can, to give back to fedora and upstream as much as we can
and stay sane. That were not easy decisions.
I spent the time to dig out these specific examples of what we did and
why I think it is important to have branches instead of "just
conditions", but you don't pay enough attention and you dismiss them as
"Disabling docs". I am sorry, but this is not fair.
>
> I had the conversation at the latest Devconf with people who are
> aiming to build Linux distribution with a reduced buildroot footprint
> for security purposes. So that they can audit the content of the
> buildroot, and get to a certain level of certification with it.
> I think It can not be done directly in Fedora, but if we add the
> flexibility into our builds (with conditionals), then we could
> eventually get a new downstream supported by a certain governmental
> entity.
>
> What we should avoid is using conditionals randomly and inconsistently.
>
> So let's agree that we are not scattering "%if 0%{?rhel} && (!
> 0%{?epel})" all over the spec file, but rather define it once at the
> top of the spec file:
>
> %if 0%{?rhel} && (! 0%{?epel})
> %bcond_with docs
> %else
>
Re: Upgrade tooling
On 3/27/20 9:55 AM, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. Mock has this cool bootstrap image thing now. It seems to me we could use that image to run the system upgrades too [*]. And if/when we get koji to use that, it'll solve a number of ages old problems on the build system, AND that image will get heavily tested 24/7 so it wouldn't be any once in a full moon franken-thing. [*] Mount the host filesystem from mock and perform a dnf --instalroot=... distro-upgrade on that, turning the whole landscape inside out. Where would mock be executing from? The same filesystem it is modifying? Where is the offline upgrade executing from? How's this fundamentally different? Somehow it seems that this doesn't change much, but just brings in another layer. Or will a complete copy of the system be made in memory to execute the upgrade tools from? Oh come on. Running from a bootstrap image allows using full native capabilities of rpm/dnf in any new version, without having to consider what the previous versions support. How's that "not much"? Let's consider a concrete example that came up recently: grub wants to rewrite something in the bootloader area on disk to help upgrades from very old installations. In current "offline upgrade" scheme, the upgrade tools are running on the real system, with udev active. They can query and touch hardware, can see all the disks as they are, etc. If we went through mock, it'd be running in an nspawn environment w/o access to hardware. And still that offline upgrade will be running on the old systems kernel which will simply *prevent* certain types of actions to be performed in an upgrade, just like using host system packaging stack *prevents* use of native capabilities in the next version, just because the old version doesn't support them, which is just totally a** backwards. Really. Note that I'm talking about a high-level idea here. I haven't looked at what a mock bootstrap image looks like, I haven't looked at what offline upgrade looks like. Sure there would be technical details, perhaps obstacles even to sort out. (Something like os-tree's atomic replacement of things, that's of course a completely different story. But so far we're talking about traditional systems.) So nowadays we have a much simpler mechanism: reboot to a special system target without most daemons running (to avoid interference during the upgrade), run the update there, reboot into the new environment. The biggest advantage is that this way we reduce the amount of "custom": we're running normal installed dnf + rpm in a normal boot environment, we just stop the boot from progressing all the way to the usual graphical environment. I think it's fair to say that amount of bugs related to the upgrade mechanism has been greatly reduced compared to previous schemes. We still have various upgrade issues, but they are in the rpms themselves, and not how we install them. Such a scheme may be feasible in a fast-moving distro like Fedora where you can always afford to sit out the next six months waiting for the new thing to become available also in rawhide-1 version, but it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 upgrades with such a scheme only happen to "work" because of bugs such as missing rpmlib() dependency on file triggers kinda let things stumble through the cracks. The premise is that the upgrade is really a normal dnf upgrade, i.e. a normal 'rpm -U' operation under the hood. The differences are: 1: package count, 2: setting up the machine in a mode where the graphical env. and other non-essential daemons are not active. So if requirements in rpms are specified correctly,
Fedora-Cloud-30-20200327.0 compose check report
No missing expected images. Passed openQA tests: 1/1 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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 1817764] perl-AnyEvent-Handle-UDP-0.050 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817764 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-AnyEvent-Handle-UDP-0. ||050-1.fc33 Resolution|--- |RAWHIDE Last Closed||2020-03-27 08:07:34 -- 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 1814708] perl-PAR-Packer needs a rebuild against new perl 5.30.2 that just landed in stable F31 repositories
https://bugzilla.redhat.com/show_bug.cgi?id=1814708 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-PAR-Packer-1.049-5.fc3 ||2 Resolution|--- |ERRATA Last Closed||2020-03-27 08:00:21 --- Comment #7 from Fedora Update System --- FEDORA-2020-d50fbf64df has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1814374] perl-XML-LibXML-2.0204 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1814374 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2020-03-27 07:59:59 --- Comment #3 from Fedora Update System --- FEDORA-2020-688a3e92ee has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1812295] perl-Encode-3.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1812295 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Encode-3.04-443.fc33 |perl-Encode-3.04-443.fc33 ||perl-Encode-3.04-443.fc32 Resolution|--- |ERRATA Last Closed||2020-03-27 07:59:42 --- Comment #6 from Fedora Update System --- FEDORA-2020-5cb807fa40 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 1808956] perl-Encode-3.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1808956 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Encode-3.03-442.fc33 |perl-Encode-3.03-442.fc33 ||perl-Encode-3.04-443.fc32 Resolution|--- |ERRATA Last Closed||2020-03-27 07:59:40 --- Comment #10 from Fedora Update System --- FEDORA-2020-5cb807fa40 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On Fri, Mar 27, 2020 at 09:04:53AM +0200, Panu Matilainen wrote: > On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: > >On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: > >>> previous-release-blocker(s) and previous-previous-release-blockers(s), > >>> since the changes would need to be deployed in F32 and F31. Also > >>> note that the last time when the upgrade plugins run code is in > >>> upgrade phase between two reboots, and the plugin is running > >>> pre-upgrade code. This code would then invoke post-upgrade rpm. It's > >>> certainly doable, but seems a bit funky. > >> > >>Right, requiring changes to previous versions is not okay. I seem to > >>be thinking our upgrade tooling had gotten fixed at some point to > >>perform the upgrade on the target distro packaging management stack > >>as it would really need to be, but guess that was just a dream. > > > >Relying on the target distro management stack sound nice, but is > >actually problematic: how do you run the next version before you > >install the next version? Sure, you can install stuff to some temporary > >location and run the tools from there, but then you are running in > >a very custom franken-environment. Such a mode of running would face > >the same issue as anaconda installer: it would only get tested during > >the upgrade season, languishing otherwise. > > Mock has this cool bootstrap image thing now. It seems to me we > could use that image to run the system upgrades too [*]. And if/when > we get koji to use that, it'll solve a number of ages old problems > on the build system, AND that image will get heavily tested 24/7 so > it wouldn't be any once in a full moon franken-thing. > > [*] Mount the host filesystem from mock and perform a dnf > --instalroot=... distro-upgrade on that, turning the whole landscape > inside out. Where would mock be executing from? The same filesystem it is modifying? Somehow it seems that this doesn't change much, but just brings in another layer. Or will a complete copy of the system be made in memory to execute the upgrade tools from? Let's consider a concrete example that came up recently: grub wants to rewrite something in the bootloader area on disk to help upgrades from very old installations. In current "offline upgrade" scheme, the upgrade tools are running on the real system, with udev active. They can query and touch hardware, can see all the disks as they are, etc. If we went through mock, it'd be running in an nspawn environment w/o access to hardware. (Something like os-tree's atomic replacement of things, that's of course a completely different story. But so far we're talking about traditional systems.) > >So nowadays we have a much simpler mechanism: reboot to a special > >system target without most daemons running (to avoid interference > >during the upgrade), run the update there, reboot into the new > >environment. The biggest advantage is that this way we reduce the > >amount of "custom": we're running normal installed dnf + rpm in a > >normal boot environment, we just stop the boot from progressing all > >the way to the usual graphical environment. > > > >I think it's fair to say that amount of bugs related to the upgrade > >mechanism has been greatly reduced compared to previous schemes. We > >still have various upgrade issues, but they are in the rpms > >themselves, and not how we install them. > > Such a scheme may be feasible in a fast-moving distro like Fedora > where you can always afford to sit out the next six months waiting > for the new thing to become available also in rawhide-1 version, but > it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 > upgrades with such a scheme only happen to "work" because of bugs > such as missing rpmlib() dependency on file triggers kinda let > things stumble through the cracks. The premise is that the upgrade is really a normal dnf upgrade, i.e. a normal 'rpm -U' operation under the hood. The differences are: 1: package count, 2: setting up the machine in a mode where the graphical env. and other non-essential daemons are not active. So if requirements in rpms are specified correctly, the upgrade always should go through. If they are specified incorrectly — then the same problems would occur on smaller updates. So the upgrade path is something to test to catch such issues in packaging. (And in general, the less scriptlets, the better. This solves the issue even better.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Upgrade tooling
On 3/27/20 9:04 AM, Panu Matilainen wrote: On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. You can also boot into live cd of the next version, mount the existing filesystems similarly to what the rescue image does, and run dnf --installroot=... upgrade from there. Whether manually, or using special tooling. Tooling which would still all be from the next version and thus issues fixable without pushing changes to multiple old versions. - Panu - ___ 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 1817764] perl-AnyEvent-Handle-UDP-0.050 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1817764 Jitka Plesnikova changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|--- |If docs needed, set a value -- 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
Upgrade tooling (was: Re: Fedora 33 System-Wide Change proposal: Sqlite RpmDB)
On 3/26/20 2:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 02:00:49PM +0200, Panu Matilainen wrote: previous-release-blocker(s) and previous-previous-release-blockers(s), since the changes would need to be deployed in F32 and F31. Also note that the last time when the upgrade plugins run code is in upgrade phase between two reboots, and the plugin is running pre-upgrade code. This code would then invoke post-upgrade rpm. It's certainly doable, but seems a bit funky. Right, requiring changes to previous versions is not okay. I seem to be thinking our upgrade tooling had gotten fixed at some point to perform the upgrade on the target distro packaging management stack as it would really need to be, but guess that was just a dream. Relying on the target distro management stack sound nice, but is actually problematic: how do you run the next version before you install the next version? Sure, you can install stuff to some temporary location and run the tools from there, but then you are running in a very custom franken-environment. Such a mode of running would face the same issue as anaconda installer: it would only get tested during the upgrade season, languishing otherwise. Mock has this cool bootstrap image thing now. It seems to me we could use that image to run the system upgrades too [*]. And if/when we get koji to use that, it'll solve a number of ages old problems on the build system, AND that image will get heavily tested 24/7 so it wouldn't be any once in a full moon franken-thing. [*] Mount the host filesystem from mock and perform a dnf --instalroot=... distro-upgrade on that, turning the whole landscape inside out. So nowadays we have a much simpler mechanism: reboot to a special system target without most daemons running (to avoid interference during the upgrade), run the update there, reboot into the new environment. The biggest advantage is that this way we reduce the amount of "custom": we're running normal installed dnf + rpm in a normal boot environment, we just stop the boot from progressing all the way to the usual graphical environment. I think it's fair to say that amount of bugs related to the upgrade mechanism has been greatly reduced compared to previous schemes. We still have various upgrade issues, but they are in the rpms themselves, and not how we install them. Such a scheme may be feasible in a fast-moving distro like Fedora where you can always afford to sit out the next six months waiting for the new thing to become available also in rawhide-1 version, but it's totally non-feasible in something like RHEL. RHEL/CentOS 7 to 8 upgrades with such a scheme only happen to "work" because of bugs such as missing rpmlib() dependency on file triggers kinda let things stumble through the cracks. - Panu - ___ 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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB
On 3/26/20 6:12 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 11:41:56AM -0400, Stephen John Smoogen wrote: On Thu, 26 Mar 2020 at 10:54, Tomasz Torcz wrote: On Thu, Mar 26, 2020 at 02:08:57PM +, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Mar 26, 2020 at 03:29:50PM +0200, Panu Matilainen wrote: No, rpm doesn't use many Linux-specific calls and this is no exception. In fact it doesn't use any of the *at() family calls directly either. But why?! It's not like rpm is massive on Windows Server... Isn't good support for Linux absolutely the most important thing? Well, RPM is a package manager on AIX. IBM/Redhat may want to keep AIX alive ;-) My understanding is that is not the only place it is used. A Linux only version would end being another fork.. I doubt it matters much as it did 10 or 20 years ago.. but it would still be a splitting of community resources versus a growing of community resources. Not all the world can be as free as systemd :). Well, OK, but let's consider that Linux installations are probably something like 99.9%. IMO it's totally appropriate to implement an atomic path for linux, and implement a non-atomic fallback for the systems that need that. We're not talking about anything big here, rather a ~10 line function. Patches welcome - well tested ones that is. That's one of the issues with such alternate paths: that simple thing suddenly has two separate paths you need to test instead of one. Truly atomic database rebuild would be nice of course, but all this attention on that is way out of proportion. - Panu - ___ 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
