Fedora-Rawhide-20210816.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 4 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud Failed openQA tests: 26/206 (x86_64), 27/140 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210814.n.0): ID: 950053 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/950053 ID: 950175 Test: aarch64 Minimal-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/950175 ID: 950177 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/950177 ID: 950181 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/950181 ID: 950234 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/950234 ID: 950329 Test: x86_64 universal install_multi@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/950329 ID: 950363 Test: aarch64 universal install_repository_http_variation@uefi URL: https://openqa.fedoraproject.org/tests/950363 ID: 950370 Test: aarch64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/950370 ID: 950393 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/950393 Old failures (same test failed in Fedora-Rawhide-20210814.n.0): ID: 950051 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/950051 ID: 950064 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/950064 ID: 950068 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/950068 ID: 950069 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/950069 ID: 950072 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/950072 ID: 950082 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/950082 ID: 950088 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/950088 ID: 950091 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/950091 ID: 950093 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/950093 ID: 950109 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/950109 ID: 950116 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/950116 ID: 950117 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/950117 ID: 950132 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/950132 ID: 950136 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/950136 ID: 950153 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/950153 ID: 950194 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/950194 ID: 950196 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/950196 ID: 950202 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/950202 ID: 950210 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/950210 ID: 950212 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/950212 ID: 950214 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/950214 ID: 950217 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/950217 ID: 950221 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/950221 ID: 950224 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/950224 ID: 950279 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/950279 ID: 950286 Test: x86_64 universal install_blivet_software_raid@uefi URL: https://openqa.fedoraproject.org/tests/950286 ID: 950297 Test: x86_64 universal
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 81 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-1f259a45ef openjpeg2-2.3.1-11.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0383a9978e httpie-1.0.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing dmlite-1.15.1-2.el7 java-runtime-decompiler-5.1-1.el7 jsonnet-0.17.0-2.el7 mock-core-configs-35-1.el7 python-rpm-head-signing-1.3-1.el7 singularity-3.8.1-1.el7 uglify-js3-3.14.1-1.el7 Details about builds: dmlite-1.15.1-2.el7 (FEDORA-EPEL-2021-351c9aa861) Lcgdm grid data management and storage framework Update Information: - GridFTP compatibility with el8 - StAR accouning bugfixes - Ciphersuite cleanup ChangeLog: * Mon Aug 16 2021 Petr Vokac - 1.15.1-2 - Ciphersuite cleanup and GridFTP compatibility with el8 - StAR accouning bugfixes * Fri Aug 6 2021 Jonathan Wakely - 1.15.1-1 - Rebuilt for Boost 1.76 java-runtime-decompiler-5.1-1.el7 (FEDORA-EPEL-2021-6e1efadb45) Application for extraction and decompilation of JVM byte code Update Information: bumped to final sources ChangeLog: * Thu Aug 12 2021 Fedora Release Engineering - 5.1-1 - bumped to final sources * Mon Aug 9 2021 Fedora Release Engineering - 5.0.rc1-1 - adapted manpage * Mon Aug 2 2021 Fedora Release Engineering - 5.0.beta2-1 - updated to 5.0 - removed jdk8 subpkg due to compiler api - added Cfr and asmtools plugins - todo man page * Thu Jul 22 2021 Fedora Release Engineering - 4.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Tue Jan 26 2021 Fedora Release Engineering - 4.0-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild * Tue Dec 8 2020 Jiri Vanek - 4.0-2 - Added subpackage built by jdk8 to allow looking into jdk8 apps - for some reason, jdk8 vm can not look into jdk11 vm, even if agent is correctly jdk8 version - the config is still share, which is stupid, but I doubt there is another target audeince then me * Tue Dec 8 2020 Jiri Vanek - 4.0-1 - built by jdk11 * Tue Jul 28 2020 Fedora Release Engineering - 3.0-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild * Fri Jul 10 2020 Jiri Vanek - 3.0-8 - Rebuilt for JDK-11, see https://fedoraproject.org/wiki/Changes/Java11 * Tue Mar 17 2020 Jiri Vanek - 3.0-7 - aligned rsyntaxtextarea version, fixed javadoc generation * Tue Mar 17 2020 Jiri Vanek - 3.0-6 - changed jdk8 requirement * Wed Jan 29 2020 Fedora Release Engineering - 3.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild jsonnet-0.17.0-2.el7 (FEDORA-EPEL-2021-81fca0330d) A data templating language based on JSON Update Information: Initial release of jsonnet on EPEL7 ChangeLog: mock-core-configs-35-1.el7 (FEDORA-EPEL-2021-d8abecdaba) Mock core config files basic chroots Update Information: Fedora 35 configs added ChangeLog: * Mon Aug 16 2021 Pavel Raiskup 35-1 - config: add Fedora 35 configs python-rpm-head-signing-1.3-1.el7 (FEDORA-EPEL-2021-60cc8e3981) Small python module to extract RPM header and file digests Update Information: Initial package import ChangeLog: References: [ 1 ] Bug #1985108 - Review Request: python-rpm-head-signing - Small python module to extract RPM header and file digests
[Bug 1989516] Upgrade perl-Text-Tabs+Wrap to 2021.0726
https://bugzilla.redhat.com/show_bug.cgi?id=1989516 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Text-Tabs+Wrap-2021.07 |perl-Text-Tabs+Wrap-2021.07 |26-1.fc35 |26-1.fc35 ||perl-Text-Tabs+Wrap-2021.07 ||26-1.fc34 Resolution|--- |ERRATA Last Closed||2021-08-17 01:21:30 --- Comment #4 from Fedora Update System --- FEDORA-2021-c7ea378482 has been pushed to the Fedora 34 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20210816.n.0 changes
OLD: Fedora-Rawhide-20210814.n.0 NEW: Fedora-Rawhide-20210816.n.0 = SUMMARY = Added images:3 Dropped images: 1 Added packages: 3 Dropped packages:1 Upgraded packages: 81 Downgraded packages: 0 Size of added packages: 6.00 MiB Size of dropped packages:1.32 MiB Size of upgraded packages: 1.14 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -1.36 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210816.n.0.iso Image: Comp_Neuro live x86_64 Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210816.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210816.n.0.iso = DROPPED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20210814.n.0.armhfp.raw.xz = ADDED PACKAGES = Package: catch22-0.2.1-1.fc36 Summary: CAnonical Time-series CHaracteristics RPMs:catch22 python3-catch22 Size:470.42 KiB Package: golang-github-jwt-3.2.2-1.fc36 Summary: A go implementation of JSON Web Tokens RPMs:golang-github-jwt golang-github-jwt-devel Size:5.30 MiB Package: rubygem-gist-6.0.0-1.fc36 Summary: Upload content to https://gist.github.com RPMs:rubygem-gist rubygem-gist-doc Size:242.16 KiB = DROPPED PACKAGES = Package: deepin-qt5dxcb-plugin-5.0.17-4.fc35 Summary: Qt platform integration plugin for Deepin Desktop Environment RPMs:deepin-qt5dxcb-plugin Size:1.32 MiB = UPGRADED PACKAGES = Package: ModemManager-1.17.900-1.fc36 Old package: ModemManager-1.16.8-4.fc35 Summary: Mobile broadband modem management service RPMs: ModemManager ModemManager-devel ModemManager-glib ModemManager-glib-devel ModemManager-vala Size: 12.34 MiB Size change: 891.12 KiB Changelog: * Sat Aug 14 2021 Peter Robinson - 1.17.900-1 - Update to 1.18.0 RC1 Package: agenda-1.1.2-1.fc36 Old package: agenda-1.1.1-1.fc36 Summary: A simple, slick, speedy and no-nonsense task manager RPMs: agenda Size: 423.62 KiB Size change: 289 B Changelog: * Sat Aug 14 2021 Benjamin A. Beasley 1.1.2-1 - Update to 1.1.2 (fix RHBZ#1993606) Package: apt-2.3.8-1.fc36 Old package: apt-2.3.7-1.fc36 Summary: Command-line package manager for Debian packages RPMs: apt apt-apidoc apt-devel apt-doc apt-libs apt-utils Size: 16.69 MiB Size change: 16.51 KiB Changelog: * Sat Aug 14 2021 Fedora Release Monitoring - 2.3.8-1 - Update to 2.3.8 (#1993644) Package: argyllcms-2.2.0-1.fc36 Old package: argyllcms-1.9.2-13.fc35 Summary: ICC compatible color management system RPMs: argyllcms argyllcms-data argyllcms-doc Size: 27.05 MiB Size change: 13.86 MiB Changelog: * Sun Aug 15 2021 Vitaly Zaitsev - 2.2.0-1 - Updated to version 2.2.0. Package: authselect-1.2.4-2.fc36 Old package: authselect-1.2.4-1.fc35 Summary: Configures authentication and identity sources from supported profiles RPMs: authselect authselect-devel authselect-libs Size: 1.99 MiB Size change: 4.26 KiB Changelog: * Sat Aug 14 2021 Bj??rn Esser - 1.2.4-2 - Add proper Obsoletes for removed authselect-compat package Fixes: rhbz#1993189 Package: bottles-2021.8.14-2.fc36 Old package: bottles-2021.7.28-1.fc35 Summary: Easily manage Wine prefix in a new way RPMs: bottles Size: 205.91 KiB Size change: 7.07 KiB Changelog: * Sun Aug 15 2021 Artem Polishchuk - 2021.8.14-1 - build(update): 2021.8.14 * Sun Aug 15 2021 Artem Polishchuk - 2021.8.14-2 - fix: Add new dep python3-patool Package: cabal-rpm-2.0.10-1.fc36 Old package: cabal-rpm-2.0.9-3.fc35 Summary: RPM packaging tool for Haskell Cabal-based packages RPMs: cabal-rpm Size: 29.31 MiB Size change: 29.20 KiB Changelog: * Sat Aug 14 2021 Jens Petersen - 2.0.10-1 - Spec: drop ghc_fix_rpath for subpkgs - Stackage: bump to LTS 18 - update: only output old version if upgrading - pkgSpecPkgData: try allowing versioned dir Package: calls-41~_beta-1.fc36 Old package: calls-41~.alpha-1.fc35 Summary: A phone dialer and call handler RPMs: calls Size: 1.58 MiB Size change: 104.85 KiB Changelog: * Sat Aug 14 2021 Torrey Sorensen - 41~.beta-1 - Update to 41.beta Package: containerd-1.5.5-1.fc36 Old package: containerd-1.5.3-2.fc35 Summary: Open and reliable container runtime RPMs: containerd containerd-devel Size: 138.83 MiB Size change: 128.25 KiB Changelog: * Sun Aug 15 2021 Olivier Lemasle - 1.5.5-1 - Update to upstream 1.5.5 (fixes rhbz#1983820) - Fixes CVE-2021-32760 (rhbz#1983932) Package: drbd-9.18.2-1.fc36 Old package: drbd-9.17.0-2.fc35 Summary: DRBD user-land tools and scripts RPMs: drbd drbd-bash-completion drbd
Re: Updated hdf5/netcdf/octave coming to rawhide/f35
On 8/16/21 3:29 PM, Fabio Valentini wrote: > On Mon, Aug 16, 2021 at 11:22 PM Orion Poplawski wrote: >> >> That does appear to be the case, it's still pending: >> >> https://bodhi.fedoraproject.org/updates/FEDORA-2021-de38a77e64 > > It's not just taking long, it's stuck. It even gives you a hint as to > *why* it's still pending: > "This update cannot be pushed to stable. These builds > qgis-3.20.1-3.fc36 have a more recent build in koji's f36 tag." > > Looks like somebody rebuilt qgis in rawhide while the side-tag was in-flight. > You'll need to do do another release bump and rebuild it again in the > side tag, and then edit the bodhi update to refresh the list of > builds. > After that's done, bodhi should push the update to stable without > further problems. > > Fabio Thanks - I had just finally managed to actually read the page myself and found that out :facepalm:. New qgis build has been started... -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated hdf5/netcdf/octave coming to rawhide/f35
On Mon, Aug 16, 2021 at 11:22 PM Orion Poplawski wrote: > > That does appear to be the case, it's still pending: > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-de38a77e64 It's not just taking long, it's stuck. It even gives you a hint as to *why* it's still pending: "This update cannot be pushed to stable. These builds qgis-3.20.1-3.fc36 have a more recent build in koji's f36 tag." Looks like somebody rebuilt qgis in rawhide while the side-tag was in-flight. You'll need to do do another release bump and rebuild it again in the side tag, and then edit the bodhi update to refresh the list of builds. After that's done, bodhi should push the update to stable without further problems. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated hdf5/netcdf/octave coming to rawhide/f35
On 8/16/21 2:36 PM, Jerry James wrote: > Hi Orion, > > On Sun, Aug 15, 2021 at 8:17 PM Orion Poplawski wrote: >> I've just submitted the updates for F35 and F36. There are a few >> packages have failed to build (mainly due to arm or other package issues >> - not many due to these updates it seems) and I'll be working on them >> and/or filing bugs for them shortly. > > I've got a fix for mpsolve ready to go, but while the F35 update has > gone through, the F36 update does not seem to have done so. The > octave-6.3.0-1.fc36 package still has tag f36-build-side-44464: > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1817191 > > Is the side tag just taking a really long time to merge? > That does appear to be the case, it's still pending: https://bodhi.fedoraproject.org/updates/FEDORA-2021-de38a77e64 mpsolve wasn't even on my radar so thanks for taking care of that. -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
Hi, On 8/16/21 12:55 AM, Florian Weimer wrote: * Kevin Fenzi: On Sun, Aug 15, 2021 at 01:51:16PM +0200, Florian Weimer wrote: * Kevin Fenzi: Yes. They were mistakenly running the normal kernel (so they had ~3GB memory available). I moved them back to the lpae kernel (so they see 40GB memory), but this causes https://bugzilla.redhat.com/show_bug.cgi?id=1920183 basically OOM kills kojid, which restarts kojid, which restarts the build, which kills kojid, etc... Why aren't the builders running 64-bit kernels, like we do for x86-64? This is not a configuration that I think we support in any way. Who is “we”? I expect that 64-bit kernel bugs will get more attention upstream. At least rpm rejects trying to install a aarch64 kernel on a 32bit userspace. The host (including kojid) should probably be 64-bit, and only the chroot 32-bit. If that doesn't work, it's an RPM bug/missing feature. OS wise, 32-bit containers/etc work fine on 64-bit fedora kernels. This also solves the problem that server grade HW with 32-bit guest (EL1+) support is becoming rarer (basically only older A72 based platforms now) and would provide a path forward on more recent Gravaton2, Ampere, etc platforms. That said, there as you mention various rpm/package build/etc problems caused by `uname -m` returning armv8. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Updated hdf5/netcdf/octave coming to rawhide/f35
Hi Orion, On Sun, Aug 15, 2021 at 8:17 PM Orion Poplawski wrote: > I've just submitted the updates for F35 and F36. There are a few > packages have failed to build (mainly due to arm or other package issues > - not many due to these updates it seems) and I'll be working on them > and/or filing bugs for them shortly. I've got a fix for mpsolve ready to go, but while the F35 update has gone through, the F36 update does not seem to have done so. The octave-6.3.0-1.fc36 package still has tag f36-build-side-44464: https://koji.fedoraproject.org/koji/buildinfo?buildID=1817191 Is the side tag just taking a really long time to merge? -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Overriding default %cmake CXXFLAGS
On 16/08/2021 22:03, Julian Sikorski wrote: %global build_cflags %(echo $RPM_OPT_FLAGS | sed "s@-g@-g1@") %global build_cxxflags %(echo $RPM_OPT_FLAGS | sed "s@-g@-g1@") Changing optflags is better, because it will affect all build flags at once: C, C++, Fortran, etc. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
FedoraRespin-34-updates-20210816.0 compose check report
No missing expected images. Failed openQA tests: 3/45 (x86_64) ID: 949838 Test: x86_64 Workstation-live-iso desktop_fprint URL: https://openqa.fedoraproject.org/tests/949838 ID: 949844 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/949844 ID: 949851 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/949851 Soft failed openQA tests: 4/45 (x86_64) (Tests completed, but using a workaround for a known bug) ID: 949822 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/949822 ID: 949834 Test: x86_64 Workstation-live-iso evince URL: https://openqa.fedoraproject.org/tests/949834 ID: 949835 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/949835 ID: 949837 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/949837 Passed openQA tests: 38/45 (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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Overriding default %cmake CXXFLAGS
On 16/08/2021 21:14, Julian Sikorski wrote:
mame needs to have the symbols level reduced to -g1 or the compilation
will fail due to relocation overflows and generally excessive memory and
disk space usage.
%global optflags %(echo %{optflags} | sed 's/-g /-g1 /')
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Overriding default %cmake CXXFLAGS
W dniu 16.08.2021 o 21:33, Neal Gompa pisze: On Mon, Aug 16, 2021 at 3:32 PM Julian Sikorski wrote: W dniu 16.08.2021 o 21:24, Neal Gompa pisze: On Mon, Aug 16, 2021 at 3:14 PM Julian Sikorski wrote: Hi, mame needs to have the symbols level reduced to -g1 or the compilation will fail due to relocation overflows and generally excessive memory and disk space usage. Right now this is taken care of by editing $RPM_OPT_FLAGS: https://src.fedoraproject.org/rpms/mame/blob/30873dfe8d2ab851bb018b7a104916aaa3d39718/f/mame.spec#_236 Upstream are considering switching to cmake, which is going to render this approach inoperable. Is there a preferred way of editing the flags used by %cmake macro? Thanks! Overriding the %build_cflags and %build_cxxflags macros is sufficient here. Thanks! And what is the recommended way of doing this? Just defining it in the spec? The advantage of the approach used until now is that it only drops -g(2) to -g1, leaving other flags intact. Do it the same way you're doing it now, just change $() for %(). I must be having a short between the headphones: %global build_cflags %(echo $RPM_OPT_FLAGS | sed "s@-g@-g1@") %global build_cxxflags %(echo $RPM_OPT_FLAGS | sed "s@-g@-g1@") this results in no flags being passed to cmake whatsoever. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
Hello Pavel, Thank you for your thoughts. It strikes me that perhaps what you're advising me to do, is likely what I was wanting to do in the first place. I certainly don't feel dissatisfied being a non-packager in Fedora land, and I am probably a bit guilty of exageration of the difficulties on the road to becoming a packager. Honestly, I am looking forward to setting up to do some testing for now. Thanks to everyone for taking the time to offer me the options available to become a packager, this is indeed a good part of why I enjoy being part of the community that is Fedora. Regards, Stephen On Mon, 2021-08-16 at 19:59 +0200, Pavel Valena wrote: > > > On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow > wrote: > > Hello Dan, > > Thank you for reaching out with your response. I have to admit, I > > was > > in a provocotive mood the other day. I had solved a problem for a > > customer that had been worked on unsuccessfully by a local > > competitor > > for three weeks. I was at that moment the master of my trade craft > > and > > in fully glory. I bought some beer to celebrate and the resulting > > email > > came out. So that is not to say I wasn't at least venting some > > portion > > of truth. Please bear with me as I have spent 6 decades walking > > upright, and sometimes I find laying the foundation of a > > conversation > > requires preparation. > > I have built RPM's and SRPM's according to RedHat specifications, I > > think using their tutorials. I have also built an unoffical flatpak > > of > > the IntelliJ IDE IDEA. So as for technical capability, I can read a > > manual as well as the next person. > > My thoughts were that the sponsoring, the proven packagers were > > supposed to be package mentors I thought originally, shouldn't > > happen > > until after sign up, and sign up is preconditioned by a basic CBT > > course with "build an RPM" test as final progression criteria for > > getting to ask for a sponsor. Not something inhibiting but just > > build a > > simple RPM to cover tha basic process. My reasoning is the process > > for > > getting onboarded should, like accepting a resume or CV from anyone > > at > > anytime, be an open door. In order to capatilize on numbers > > certainly > > but also to encourage the real potential individuals who can > > contribute > > technically, but are severely hampered by initial barriers. Even if > > the > > barriers are only perceived ones. The initial CBT I mentioned would > > be > > a way for someone like that to get a "free test". A sort of > > confidence > > boost that takes nothing but their time, and allows them to show > > they > > can do that part. Also, if they have difficulties doing a simple > > RPM, > > they could take some time to get that going and come back to try > > again. > > All of this can happen without the need for a sponsor getting > > involved > > until a minimum level of capability is ascertained, which should > > offload some time (for sponsors), though likely minimal I would > > guess. > > We could make it a badge. > > > > > Hello Stephen, > > I think this situation is very unfortunate and unintended. I think > you can do (or you can start doing it) what you came to do in Fedora, > without the "packager status". In general when you already have some > project / package in Fedora that you want to maintain, you can start > to work on it straight away, as a part of gaining your packager > status. That is, while receiving feedback /advice/ from sponsor. It's > a way to gain the actual skill to become a packager - I don't think > any robot/test can replace that. I don't think packaging is about > just doing builds, in a way "it works", but rather creating a good > spec file / good package that will last for years. > > Doing unofficial reviews for a package you want to get into Fedora, > or submitting a new package review request (if you want to get it to > Fedora), or re-review request (if you want to unorphan the package). > Creating PRs with an enhancement / or package upgrade. Last one you > can even do anonymously: > > > https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously > > All of the above are IMO examples of what packager does. There's no > reason to do something else - you can just start straight away with > what you intend to do, and get a "packager" status later. Or is there > an obstacle that you packager status for, to do anything meaningful > for you? > > I really hope there's a path to achieve what you came to Fedora for. > If not, I'd argue it needs to be created. > > I don't think the idea of getting a packager status, just to get it > reverted some time later, wouldn't help you to become a (better) > packager. For all the best ways of collaboration (which is IMHO what > Fedora is all about) you don't need the packager status for. > > Regards, > Pavel > > > > > > > On Thu, 2021-08-12 at 19:58 +, Dan Čermák wrote: > > > I'd also like to plug Jakub's new sponsor
Re: Overriding default %cmake CXXFLAGS
On Mon, Aug 16, 2021 at 3:32 PM Julian Sikorski wrote: > > W dniu 16.08.2021 o 21:24, Neal Gompa pisze: > > On Mon, Aug 16, 2021 at 3:14 PM Julian Sikorski wrote: > >> > >> Hi, > >> > >> mame needs to have the symbols level reduced to -g1 or the compilation > >> will fail due to relocation overflows and generally excessive memory and > >> disk space usage. Right now this is taken care of by editing > >> $RPM_OPT_FLAGS: > >> https://src.fedoraproject.org/rpms/mame/blob/30873dfe8d2ab851bb018b7a104916aaa3d39718/f/mame.spec#_236 > >> Upstream are considering switching to cmake, which is going to render > >> this approach inoperable. Is there a preferred way of editing the flags > >> used by %cmake macro? Thanks! > >> > > > > Overriding the %build_cflags and %build_cxxflags macros is sufficient here. > > > > > > > Thanks! And what is the recommended way of doing this? Just defining it > in the spec? > The advantage of the approach used until now is that it only drops -g(2) > to -g1, leaving other flags intact. > Do it the same way you're doing it now, just change $() for %(). -- 真実はいつも一つ！/ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Overriding default %cmake CXXFLAGS
W dniu 16.08.2021 o 21:24, Neal Gompa pisze: On Mon, Aug 16, 2021 at 3:14 PM Julian Sikorski wrote: Hi, mame needs to have the symbols level reduced to -g1 or the compilation will fail due to relocation overflows and generally excessive memory and disk space usage. Right now this is taken care of by editing $RPM_OPT_FLAGS: https://src.fedoraproject.org/rpms/mame/blob/30873dfe8d2ab851bb018b7a104916aaa3d39718/f/mame.spec#_236 Upstream are considering switching to cmake, which is going to render this approach inoperable. Is there a preferred way of editing the flags used by %cmake macro? Thanks! Overriding the %build_cflags and %build_cxxflags macros is sufficient here. Thanks! And what is the recommended way of doing this? Just defining it in the spec? The advantage of the approach used until now is that it only drops -g(2) to -g1, leaving other flags intact. Best regards, Julian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: After branching F36, under Rawhide I can not build packages for F35 for i386 arch, instead of it mock builded packages for F36.
Now compilation failing with error: "Error: GPG check FAILED". https://pastebin.com/HNGz7N8A ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Overriding default %cmake CXXFLAGS
On Mon, Aug 16, 2021 at 3:14 PM Julian Sikorski wrote: > > Hi, > > mame needs to have the symbols level reduced to -g1 or the compilation > will fail due to relocation overflows and generally excessive memory and > disk space usage. Right now this is taken care of by editing $RPM_OPT_FLAGS: > https://src.fedoraproject.org/rpms/mame/blob/30873dfe8d2ab851bb018b7a104916aaa3d39718/f/mame.spec#_236 > Upstream are considering switching to cmake, which is going to render > this approach inoperable. Is there a preferred way of editing the flags > used by %cmake macro? Thanks! > Overriding the %build_cflags and %build_cxxflags macros is sufficient here. -- 真実はいつも一つ！/ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Overriding default %cmake CXXFLAGS
Hi, mame needs to have the symbols level reduced to -g1 or the compilation will fail due to relocation overflows and generally excessive memory and disk space usage. Right now this is taken care of by editing $RPM_OPT_FLAGS: https://src.fedoraproject.org/rpms/mame/blob/30873dfe8d2ab851bb018b7a104916aaa3d39718/f/mame.spec#_236 Upstream are considering switching to cmake, which is going to render this approach inoperable. Is there a preferred way of editing the flags used by %cmake macro? Thanks! Best regards, Julian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Can someone help with pycdlib? rhbz#1956566
On Mon, 16 Aug 2021, Brian C. Lane wrote: There's a bug with pycdlib that has been fixed upstream. I've been trying to get the author/maintainer's attention but to no avail. I've even made and tested a PR for it here: https://src.fedoraproject.org/rpms/python-pycdlib/pull-request/2 This effects mkksiso and livemedia-creator (when using virt) on F34 and later. There is also a newer release upstream, but I took the path of least change in my testing. Is there someone who knows how to contact clalancette? Or someone comfortable with applying my fix? Looks like clalancette (who also appears to be the upstream maintainer?) updated rawhide a few days ago to a new upstream version that appears to include your fix already. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Updating Puppet from 5.5 to 7.7 in Fedora 34
Hello everyone, For additional visibility: there is currently an open update to bump Puppet from version 5.5 to 7.7 in Fedora 34. While this can be considered a big change (especially since the config directory changes), it should be ok. Puppet 5.5 is completely broken under Ruby 3 and only Puppet 7.7 added support for Ruby 3. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ec4a4b2634 If you're a Puppet user, please git it a spin. Also a big shout out to brandfbb for his efforts. From here on out, I hope we can keep Puppet up to date. Regards, Ewoud Kohl van Wijngaarden ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Can someone help with pycdlib? rhbz#1956566
There's a bug with pycdlib that has been fixed upstream. I've been trying to get the author/maintainer's attention but to no avail. I've even made and tested a PR for it here: https://src.fedoraproject.org/rpms/python-pycdlib/pull-request/2 This effects mkksiso and livemedia-creator (when using virt) on F34 and later. There is also a newer release upstream, but I took the path of least change in my testing. Is there someone who knows how to contact clalancette? Or someone comfortable with applying my fix? Thanks, Brian -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Please stop submitting interdependent Firefox and NSS updates separately
Hi folks. For about the sixth time this year, interdependent NSS and Firefox updates have been submitted to Bodhi separately: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6fcdbc958b https://bodhi.fedoraproject.org/updates/FEDORA-2021-0446705d87 PLEASE stop doing this. I have been asking for months. It is against the update policy and will break our repositories. The Firefox update got auto-submitted for stable before the NSS update was submitted for stable. If I had not spotted this and also submitted the NSS update for stable, the Firefox update would have been pushed without the NSS update, and the F33 stable repositories would have been broken. This is a real problem, it's not just me making trouble. Update gating on openQA tests (which we implemented earlier this year) should prevent stable getting broken at least, but there is currently a bug in Bodhi: karma autopush ignores gating requirements, so even if gating tests fail, if the autopush threshold is met the update will be pushed stable. I have submitted a fix for this, but until that fix is merged and pushed out, we can still wind up with a broken state in stable if this keeps happening. Once that bug is fixed, if this keeps happening, it will not be possible to push the Firefox update stable until the NSS update goes stable and someone re-triggers the Firefox tests. The correct thing to do is either to put the packages in the same update, or wait for the NSS update to go stable before submitting the Firefox update to testing. If you have issues with permissions, we can deal with that in various ways. Any provenpackager can edit any package into any update; I would be happy to do this on request. Or Martin could be granted packager rights on the nss/nspr packages, which should allow him to edit Firefox packages into nss/nspr updates. Thanks. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Fri, Aug 13, 2021 at 1:38 PM Stephen Snow wrote: > Hello Dan, > Thank you for reaching out with your response. I have to admit, I was > in a provocotive mood the other day. I had solved a problem for a > customer that had been worked on unsuccessfully by a local competitor > for three weeks. I was at that moment the master of my trade craft and > in fully glory. I bought some beer to celebrate and the resulting email > came out. So that is not to say I wasn't at least venting some portion > of truth. Please bear with me as I have spent 6 decades walking > upright, and sometimes I find laying the foundation of a conversation > requires preparation. > I have built RPM's and SRPM's according to RedHat specifications, I > think using their tutorials. I have also built an unoffical flatpak of > the IntelliJ IDE IDEA. So as for technical capability, I can read a > manual as well as the next person. > My thoughts were that the sponsoring, the proven packagers were > supposed to be package mentors I thought originally, shouldn't happen > until after sign up, and sign up is preconditioned by a basic CBT > course with "build an RPM" test as final progression criteria for > getting to ask for a sponsor. Not something inhibiting but just build a > simple RPM to cover tha basic process. My reasoning is the process for > getting onboarded should, like accepting a resume or CV from anyone at > anytime, be an open door. In order to capatilize on numbers certainly > but also to encourage the real potential individuals who can contribute > technically, but are severely hampered by initial barriers. Even if the > barriers are only perceived ones. The initial CBT I mentioned would be > a way for someone like that to get a "free test". A sort of confidence > boost that takes nothing but their time, and allows them to show they > can do that part. Also, if they have difficulties doing a simple RPM, > they could take some time to get that going and come back to try again. > All of this can happen without the need for a sponsor getting involved > until a minimum level of capability is ascertained, which should > offload some time (for sponsors), though likely minimal I would guess. > We could make it a badge. > Hello Stephen, I think this situation is very unfortunate and unintended. I think you can do (or you can start doing it) what you came to do in Fedora, without the "packager status". In general when you already have some project / package in Fedora that you want to maintain, you can start to work on it straight away, as a part of gaining your packager status. That is, while receiving feedback /advice/ from sponsor. It's a way to gain the actual skill to become a packager - I don't think any robot/test can replace that. I don't think packaging is about just doing builds, in a way "it works", but rather creating a good spec file / good package that will last for years. Doing unofficial reviews for a package you want to get into Fedora, or submitting a new package review request (if you want to get it to Fedora), or re-review request (if you want to unorphan the package). Creating PRs with an enhancement / or package upgrade. Last one you can even do anonymously: https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously All of the above are IMO examples of what packager does. There's no reason to do something else - you can just start straight away with what you intend to do, and get a "packager" status later. Or is there an obstacle that you packager status for, to do anything meaningful for you? I really hope there's a path to achieve what you came to Fedora for. If not, I'd argue it needs to be created. I don't think the idea of getting a packager status, just to get it reverted some time later, wouldn't help you to become a (better) packager. For all the best ways of collaboration (which is IMHO what Fedora is all about) you don't need the packager status for. Regards, Pavel > > On Thu, 2021-08-12 at 19:58 +, Dan Čermák wrote: > > I'd also like to plug Jakub's new sponsor page: > > https://docs.pagure.org/fedora-sponsors/all > > > > There you can find all currently active sponsors by language, > > interest, etc. > > > I like the work Jakub did on the sponsor page. This is a good way to > present them. > > > > Cheers, > > > > Dan > As for Eclipse in Fedora Linux, sadly I must say I left trying to get > Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour > of doing what I needed in my home directory, including maven and graal, > and using netbeans flatpak for IDE because it works. I don't blame > Fedora Linux or the related packagers, the satate of Java can be fully > blamed on the corporate entities involved at the heart of java. > I think the packing group is doing the work, they are the ones who put > together this thing we call Fedora Linux. > > As for myself, I have enjoyed the benefits of Fedora Linux for a very > long time and appreciate the efforts
Re: Any recent changes to the arm builders?
On Sun, Aug 15, 2021, at 6:43 PM, Demi Marie Obenour wrote: > > Mark kojid as non-killable by setting its OOM score to -1000? Adding > swap might also help, but then the build is by no means guaranteed to > finish in a reasonable amount of time. If Koji wasn't a clustered container system itself, but just deferred to e.g. Kubernetes, then both problems are solved for free - there's extensive support for using cgroups to correctly protect the control plane (kubelet, etc.) versus user workloads, *and* running 32 bit containers on a 64 bit host is obviously supported. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 8/15/21 3:41 AM, Miro Hrončok wrote: > On 15. 08. 21 4:13, Orion Poplawski wrote: >> Or perhaps at least a statement that support for it is "best effort" only to >> make it more acceptable to ExcludeArch it on some packages. > > Due to the nature of our dependency chain, this would be just slower version > of not including it. E.g. we have trouble building Python and if we > ExcludeArch it, the distro is not working any more. > Well, yes, for python it either makes sense to support arm 32-bit or just drop it entirely from the distribution. For 3D visualization libraries with a relatively small dependency chain ExcludeArch seems more viable. -- Orion Poplawski IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 16 August (Today)
Hi everyone, Please find the logs from today's meeting below. We will meet again in 2 weeks, at the same time (1300 UTC). Minutes: https://meetbot.fedoraproject.org/fedora-neuro/2021-08-16/neurofedora.2021-08-16-13.01.html Log: https://meetbot.fedoraproject.org/fedora-neuro/2021-08-16/neurofedora.2021-08-16-13.01.log.html Minutes in text format: === #fedora-neuro: NeuroFedora - 2021-08-16 === Meeting started by MeWjOr at 13:01:15 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-neuro/2021-08-16/neurofedora.2021-08-16-13.01.log.html . Meeting summary --- * Guide to commands here: https://fedoraproject.org/wiki/Meeting:Guide (FranciscoD, 13:02:04) * Agenda (MeWjOr, 13:02:35) * New introductions and roll call (MeWjOr, 13:02:50) * Tasks from last meeting (MeWjOr, 13:02:57) * Open Pagure tickets (MeWjOr, 13:03:04) * Package health check (MeWjOr, 13:03:11) * Open package reviews check (MeWjOr, 13:03:16) * CompNeuro lab compose status check for Fedora 35 (MeWjOr, 13:03:30) * Neuroscience query of the week! (MeWjOr, 13:03:36) * Next meeting day, and chair (MeWjOr, 13:03:42) * Open floor (MeWjOr, 13:03:48) * Introductions and roll call (MeWjOr, 13:03:57) * Tasks from last meeting (MeWjOr, 13:08:13) * Minutes from the last meeting are here: https://meetbot.fedoraproject.org/fedora-neuro/2021-08-02/neurofedora.2021-08-02-13.04.html (MeWjOr, 13:08:41) * FranciscoD update and fix fsleyes stack (MeWjOr, 13:08:59) * LINK: https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__=Fedora=python-fsleyes_id=12078931=Fedora_format=advanced (FranciscoD, 13:12:09) * MeWjOr disable unstable tests to fix mne (MeWjOr, 13:12:13) * FranciscoD continue packaging SALib deps to update it to new release (and fix FTBFS) (MeWjOr, 13:12:50) * ACTION: FranciscoD continue packaging SALib deps and update it to its new release (MeWjOr, 13:14:02) * FranciscoD investigate pyscaffold FTBFS (MeWjOr, 13:14:17) * ACTION: FranciscoD investigate pyscaffold FTBFS (MeWjOr, 13:16:26) * ACTION: FranciscoD make fixes to catch22 based on reviews (MeWjOr, 13:16:33) * FranciscoD sponsor omnidapps[m] to package maintainer group and add to neuro-sig packaging team (MeWjOr, 13:18:02) * Open pagure tickets (MeWjOr, 13:19:02) * Please find the open tickets here: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting (MeWjOr, 13:19:20) * Package health check (MeWjOr, 13:20:18) * The neuro-sig packaging dashboard is here: https://packager-dashboard.fedoraproject.org/neuro-sig (MeWjOr, 13:20:38) * Open package reviews check. (MeWjOr, 13:30:42) * NeuroFedora package reviews: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro -> click on "show advanced fields" -> "Depends on" (MeWjOr, 13:31:06) * CompNeuro lab compose status check for Fedora 35 (MeWjOr, 13:36:10) * CompNeuro compose task on Koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 (MeWjOr, 13:36:25) * Rawhide is building fine, but F35 is failing (MeWjOr, 13:36:56) * LINK: https://pagure.io/releng/failed-composes/issues (FranciscoD, 13:37:16) * LINK: https://kojipkgs.fedoraproject.org//work/tasks/4082/73894082/mock_output.log (FranciscoD, 13:38:57) * Neuroscience query of the week (MeWjOr, 13:41:25) * 10 rules to improve your academic work-life balance https://journals.plos.org/ploscompbiol/article?id=10.1371%2Fjournal.pcbi.1009124_source=feedburner_medium=feed_campaign=Feed%3A+ploscompbiol%2FNewArticles+%28PLOS+Computational+Biology+-+New+Articles%29 (MeWjOr, 13:42:08) * LINK: https://neuroblog.fedoraproject.org/planet-neuroscientists/ -> blogs/news (FranciscoD, 13:46:37) * LINK: https://neuroblog.fedoraproject.org/planet-neuroscience/ -> journal RSS feeds (FranciscoD, 13:46:43) * pluto doesn't like cookies currently: https://github.com/feedreader/pluto/issues/39 (FranciscoD, 13:48:07) * Next meeting day, and chair (MeWjOr, 13:53:02) * AGREED: next meeting, same time in two weeks (1300 UTC) (MeWjOr, 13:54:38) * ACTION: omnidapps[m] would be chairing the next meeting (MeWjOr, 13:55:20) * Open floor (MeWjOr, 13:56:00) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1977151 (FranciscoD, 13:56:42) * ACTION: shaane[m] look at https://bugzilla.redhat.com/show_bug.cgi?id=1977151 (FranciscoD, 13:58:09) * ACTION: FranciscoD sponsor shaane[m] to packager group (FranciscoD, 13:59:33) Meeting ended at 14:00:41 UTC. Action Items * FranciscoD continue packaging SALib deps and update it to its new release * FranciscoD investigate pyscaffold FTBFS * FranciscoD make fixes to catch22 based on reviews * omnidapps[m] would be chairing the next meeting * shaane[m] look at
[Bug 1983786] CVE-2021-36770 perl-Encode: bug in local configuration loading allows arbitrary Perl code execution placed under the current working directory
https://bugzilla.redhat.com/show_bug.cgi?id=1983786 --- Doc Text *updated* by Cedric Buissart --- A flaw was found in perl-Encode, where the Perl5 Encode module loaded modules within the current directory. This flaw allows an attacker with write access to the current directory of a Perl5 process to inject arbitrary Perl code when this module is loaded, which can be used for a local privilege escalation. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1983786] CVE-2021-36770 perl-Encode: bug in local configuration loading allows arbitrary Perl code execution placed under the current working directory
https://bugzilla.redhat.com/show_bug.cgi?id=1983786 Cedric Buissart changed: What|Removed |Added Fixed In Version||p5-encode 3.12 --- Comment #6 from Cedric Buissart --- Upstream fix : https://github.com/dankogai/p5-encode/commit/527e482dc70b035d0df4f8c77a00d81f8d775c74 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[389-devel] UNSUBSCRIBE/DELETE
UNSUBSCRIBE/DELETE From: Mark Reynolds Sent: Saturday, August 14, 2021 1:44 PM To: 389 Directory server developer discussion. <389-devel@lists.fedoraproject.org> Subject: [389-devel] please review: PR 4873 - Move EntryUUID Plugin to subpackage This message has originated from an[External Source] https://urldefense.com/v3/__https://github.com/389ds/389-ds-base/pull/4873__;!!MEQIFvZ9d4ErIg!SrjsXGBsZn18oKmTGPxbE7i8ZzwnCd8E1hKiyIiEy_NYhu3bMcTudVEUCEny_pqPC-VgAsY$ -- Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://urldefense.com/v3/__https://docs.fedoraproject.org/en-US/project/code-of-conduct/__;!!MEQIFvZ9d4ErIg!SrjsXGBsZn18oKmTGPxbE7i8ZzwnCd8E1hKiyIiEy_NYhu3bMcTudVEUCEny_pqPO7GVmdM$ List Guidelines: https://urldefense.com/v3/__https://fedoraproject.org/wiki/Mailing_list_guidelines__;!!MEQIFvZ9d4ErIg!SrjsXGBsZn18oKmTGPxbE7i8ZzwnCd8E1hKiyIiEy_NYhu3bMcTudVEUCEny_pqP74jdkuI$ List Archives: https://urldefense.com/v3/__https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org__;!!MEQIFvZ9d4ErIg!SrjsXGBsZn18oKmTGPxbE7i8ZzwnCd8E1hKiyIiEy_NYhu3bMcTudVEUCEny_pqP1vVfxWY$ Do not reply to spam on the list, report it: https://urldefense.com/v3/__https://pagure.io/fedora-infrastructure__;!!MEQIFvZ9d4ErIg!SrjsXGBsZn18oKmTGPxbE7i8ZzwnCd8E1hKiyIiEy_NYhu3bMcTudVEUCEny_pqP-5azkHY$ ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 16 August (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 16th August (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat). The meeting is a public meeting, and open for everyone to attend. You can join us over: IRC: https://webchat.libera.chat/?channels=#fedora-neuro Matrix: https://tinyurl.com/matrix-neurofedora You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting=20210816T13=%3A=1 The meeting will be chaired by @major. The agenda for the meeting is: - New introductions and roll call. - Tasks from last week's meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-08-02-13.04.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig - CompNeuro lab compose status check for F35: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Bug 1993507] perl-PDL-2.057 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1993507 Jitka Plesnikova changed: What|Removed |Added Resolution|--- |RAWHIDE CC|caillon+fedoraproject@gmail | |.com, | |jakub.jedel...@gmail.com, | |jples...@redhat.com,| |ka...@ucw.cz, | |lkund...@v3.sk, | |rhug...@redhat.com, | |rstr...@redhat.com, | |sandm...@redhat.com,| |tjczep...@gmail.com | Fixed In Version||perl-PDL-2.57.0-1.fc36 ||perl-PDL-2.57.0-1.fc35 Doc Type|--- |If docs needed, set a value Status|NEW |CLOSED Last Closed||2021-08-16 10:54:58 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
On Mon, Aug 16, 2021 11:57:57 +0200, Vít Ondruch wrote: > I wonder what are the requirements for using Copr? FAS account, but is there > anything else? I think that maintaining packages in Copr for a while just to > gain experience/confidence could deserve better promotion. I think an FAS is pretty much all one needs: https://docs.pagure.org/copr.copr/user_documentation.html > > BTW there is also Fedora Join SIG which focuses on improving of newcomers > experience. However not sure how active this SIG is. It's very active :D I'd note that the Join SIG only provides general guidance to newcomers to help them find the right team/SIG/area to participate in. Since each team/SIG tends to have its own requirements and on-boarding/sponsorship process, the newcomer will still have to engage with the team to participate (or get sponsored in the case of the package maintainers team). If more package maintainers (and dev folks generally) can join the Join SIG and help newcomers along, that'll be great. The idea is to get newcomers better acquainted with the existing community so that they're comfortable and confident enough to participate. The process we have in place is noted here: https://pagure.io/fedora-join/Welcome-to-Fedora Basically, we get folks to create a Fedora account and then we file a first "Welcome to Fedora" ticket for them where we provide them with initial information about how Fedora is organised and what our foundations are and so on. Then we help newcomers find the area/team/SIG they'd like to work in and we guide them to joining it. To join the Join SIG, you can just say "hello!" in a ticket here and someone will add you to the Pagure and FAS groups so you get notifications on new Welcome to Fedora tickets and so on. https://pagure.io/fedora-join/Fedora-Join/new_issue -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Monday's FESCo Meeting (2021-08-16)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00UTC in #fedora-meeting on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-08-16 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2657 F35 Change: Restart User Services after Upgrade https://pagure.io/fesco/issue/2657 APPROVED (+5, 0, 0) = Followups = = New business = #2659 Arbitration request: Crypto policy prevents VPN connections https://pagure.io/fesco/issue/2659 #2660 F35 incomplete changes: Code complete (testable) deadline https://pagure.io/fesco/issue/2660 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: The Death of Java (packages)
I wonder what are the requirements for using Copr? FAS account, but is there anything else? I think that maintaining packages in Copr for a while just to gain experience/confidence could deserve better promotion. BTW there is also Fedora Join SIG which focuses on improving of newcomers experience. However not sure how active this SIG is. Vít [1] https://docs.fedoraproject.org/en-US/fedora-join/ Dne 13. 08. 21 v 13:37 Stephen Snow napsal(a): Hello Dan, Thank you for reaching out with your response. I have to admit, I was in a provocotive mood the other day. I had solved a problem for a customer that had been worked on unsuccessfully by a local competitor for three weeks. I was at that moment the master of my trade craft and in fully glory. I bought some beer to celebrate and the resulting email came out. So that is not to say I wasn't at least venting some portion of truth. Please bear with me as I have spent 6 decades walking upright, and sometimes I find laying the foundation of a conversation requires preparation. I have built RPM's and SRPM's according to RedHat specifications, I think using their tutorials. I have also built an unoffical flatpak of the IntelliJ IDE IDEA. So as for technical capability, I can read a manual as well as the next person. My thoughts were that the sponsoring, the proven packagers were supposed to be package mentors I thought originally, shouldn't happen until after sign up, and sign up is preconditioned by a basic CBT course with "build an RPM" test as final progression criteria for getting to ask for a sponsor. Not something inhibiting but just build a simple RPM to cover tha basic process. My reasoning is the process for getting onboarded should, like accepting a resume or CV from anyone at anytime, be an open door. In order to capatilize on numbers certainly but also to encourage the real potential individuals who can contribute technically, but are severely hampered by initial barriers. Even if the barriers are only perceived ones. The initial CBT I mentioned would be a way for someone like that to get a "free test". A sort of confidence boost that takes nothing but their time, and allows them to show they can do that part. Also, if they have difficulties doing a simple RPM, they could take some time to get that going and come back to try again. All of this can happen without the need for a sponsor getting involved until a minimum level of capability is ascertained, which should offload some time (for sponsors), though likely minimal I would guess. We could make it a badge. On Thu, 2021-08-12 at 19:58 +, Dan Čermák wrote: I'd also like to plug Jakub's new sponsor page: https://docs.pagure.org/fedora-sponsors/all There you can find all currently active sponsors by language, interest, etc. I like the work Jakub did on the sponsor page. This is a good way to present them. Cheers, Dan As for Eclipse in Fedora Linux, sadly I must say I left trying to get Eclipse going on Fedora Linux (Silverblue now) some time ago, in favour of doing what I needed in my home directory, including maven and graal, and using netbeans flatpak for IDE because it works. I don't blame Fedora Linux or the related packagers, the satate of Java can be fully blamed on the corporate entities involved at the heart of java. I think the packing group is doing the work, they are the ones who put together this thing we call Fedora Linux. As for myself, I have enjoyed the benefits of Fedora Linux for a very long time and appreciate the efforts daily. I would like to return more than appreciation to the community and that is my impetus for wanting to package. I think I will take Chris Murphy's advice and start with reviews for now, there is a rather long backlog it seems. Regards, Stephen On August 12, 2021 7:29:10 AM UTC, Felix Schwarz wrote: Hi Stephen, thank you for your interest in contributing to Fedora. I can totally understand that the current policies may seem overwhelming so that becoming a packager might be seen as some kind of "elite" status. I think I would feel the same way if I didn't become a packager ~10 years ago. However I would like to emphasize Ben's point: I think becoming a packager is not as complicated as you’ve written. To become a packager, you must convince a packager sponsor to sponsor you. That’s all; there is no rule about how to do the convincing. Maybe you do 1-2 package updates or fixes (pull request via src.fedoraproject.org) and check the Fedora wiki pages for a list of sponsors. Try contacting some of them directly after you verified they are still active (mailing list/src.fedoraproject.org). Also it helps usually if these sponsors are interested in the languages/tech stack which you tried to improve. That being said: Java in Fedora is one of the hardest areas to tackle. Several "high profile" packagers had to give up on that task (despite heroic efforts) because it is just too much for one person (or a small team). Part of the problem is
Fedora-Cloud-34-20210816.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210815.0): ID: 949431 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/949431 ID: 949442 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/949442 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Memory Constraints macros for RPM (System-Wide Change proposal)
On 8/16/21 12:25 AM, Michel Alexandre Salim wrote:
On Thu, Aug 12, 2021 at 06:14:57PM -0700, Michel Alexandre Salim via devel
wrote:
On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel
wrote:
On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote:
On 8/10/21 8:53 PM, Ankur Sinha wrote:
On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote:
Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a):
This is now implemented on Rawhide; Fedora updates are in testing:
Where is it documented?
I suggest one of these
https://rpm-packaging-guide.github.io/
https://docs.fedoraproject.org/en-US/packaging-guidelines/
That would be great. I was trying to put %limit_build at the top of my
spec and kept getting errors. Then I looked at the mcrouter spec and
realised this needs to go into the %build section XD
Yes, the macro is a strange as it mixes rpm macro language and shell
language, relying on some rather subtle aspects of how spec parsing and
macros work and has to be placed in a shell section. If you ask me, it's
asking for trouble.
Setting RPM_BUILD_NCPUS environment should achieve the same without
requiring the twisty %global override which looks like it may break
_smp_build_ncpus use in later sections (but I may be missing something
there)
So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it
again, could not figure out how to set that definition from within a
macro. Any idea?
openSUSE's macro overrides %_smp_mflags instead, which ... seems to work
for them, but I agree that we should rather use an environment variable instead.
Some findings:
- overriding %_smp_mflags works. But I have to use %global - %define
does not work - and that triggers some ugly warnings at every build
- setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work
since %_smp_build_ncpus is already defined by then
%_smp_build_ncpus being defined or not is not an issue, it's evaluated
on each use. The problem is the time of use: a macro is used during spec
parse, whereas your macro expects to be part of the *shell* execution of
%build.
Seems like the proper fix here is to either:
- try and get this macro into RPM proper, so we can have %limit_build
declared at the top of the spec. This will likely push the change back
to F36 at the earliest, and would make it hard to retrofit on existing
releases, unless we want to carry out-of-tree patches.
Yes, such a thing should go upstream instead of distro-specific hacks,
each different and in the end complicating doing it upstream in the end.
That said, it doesn't have to be in RPM to be usable at top of the spec,
I don't know where that idea comes from. Just do the math in Lua and set
%_smp_ncpus_max from there, and then expected usage is to put it at top
of the spec. It shouldn't be any harder, more likely it should be far
easier than what it's now doing. Doing it that way will also affect all
the parallelisation done by rpmbuild, not just %build.
- _smp_build_ncpus also seems to be defined per platform, even though
the definition is mostly identical, so this will be a bit messy
- change the usage, and require users who want to limit the build to do
something like this:
%make_build %{limit_build -m 4096} -- with %limit_build used as a
%function that spits out the relevant -j override
Updated pull request, using the latter option:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141
The macro is now rewritten in Lua, since I can't coerce the shell
definition to just output a value. Tested locally with mock (I had to
copy fedora-34-x86_64 to fedora-35-x86_64 as the Rawhide target is
currently failing on GPG verification).
- if limit_build computes a number that is higher than %_smp_build_ncpus
it outputs nothing
- if it computes a value that is smaller, it outputs '-j'
- if it computes a value less than 1 it outputs '-j1'
Tested with mcrouter locally and setting the memory requirement to some
ridiculous value (-m 409600) I do end up with a single-core build.
Inline documentation is provided, once the PR is reviewed and this is
built for Rawhide I'll update the packaging guideline.
EEK! NAK!
That totally breaks the idea of how %make_build and friends are supposed
to work. Revert this hack, NOW!
This thing needs to go back to drawing board to be discussed at leisure
rather than trying to hack something up in a hurry that we will regret
later.
- Panu -
Best regards,
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the
Re: Running rawhide mockbuild on Fedora 33 fails with GPG check
On 15. 08. 21 2:02, Miro Hrončok wrote: Hello. I've tried to run a rawhide mockbuild on Fedoa 33 and I get GPG failures. It worked yesterday... Solution: Update to mock-core-configs >= 35-1: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VVIUKZLIYMX322HOC3X4ERVVXI3HVJHT/ https://bodhi.fedoraproject.org/updates/mock-core-configs -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
On 16. 08. 21 0:29, Kevin Fenzi wrote: On Sun, Aug 15, 2021 at 11:43:48AM +0200, Miro Hrončok wrote: On 14. 08. 21 18:19, Kevin Fenzi wrote: It makes me wonder if we should consider letting 32bit arm go... (insert pitchforks and torches). Let's propose it and see what people say? As a package maintainer, I would certainly appreciate this. I can draft a change proposal next week. How about we give time for the iot and arm folks who likely have not seen this yet to chime in. :) I was planning to ask them directly. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
mock-core-configs-35-1 released
Hello, I've just released the new mock-core-configs package: https://github.com/rpm-software-management/mock/releases/tag/mock-core-configs-35-1 Updates are in Bodhi. The new package ships Fedora 35 configuration; and since we seem to already have the composes available - I deployed the new configs to Fedora Copr and enabled the Fedora 35 chroots (prepared by Jakub Kadlčík). This update should also fix the recent Fedora Rawhide build failures, sorry for the delay. Pavel ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Any recent changes to the arm builders?
* Neal Gompa: > ARM is the only remaining non-embedded 32-bit architecture in common use. Where do you see 32-bit Arm being used in a non-embedded way? With “non-embedded” I mean use for general-purpose computation, where the end user installs software of their own choice, and not some fixed set of applications. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
