Re: Self Introduction: Malcolm Inglis (mcinglis)
Kevin Fenzi kirjoitti 17.1.2022 klo 22.05: On Mon, Jan 10, 2022 at 10:47:13AM -0800, Kevin Fenzi wrote: On Mon, Jan 10, 2022 at 11:07:33AM +0100, Vít Ondruch wrote: Just FTR, I don't think that as a sponsor, I can close the ticket and that is a bit discouraging. There's no way to tell pagure.io "everyone in the fedora packager group thats a manager is a admin here", so I have manually been adding any sponsor who replies to a ticket. I suppose if we wanted we could manually list everyone out and add them and then add new folks as they became sponsors. Additionally, I fear it would also leed to 'HI, make me a packager' type tickets (with no other info). We could of course close those or ask for more info, but then someone has to manage that. You have already volunteered for providing the template, that should help to solve this. Hopefully. :) ok. I have a first cut of a template there now. Open a new issue and you should see it. Happy to accept changes/additions/fixes via direct email or here. Thank you, this is great! Those two seem to contradict each other: # If you are a new packager seeking sponsorship via new package or reviews # please close this and # If you are a new packager seeking sponsorship after your new package submission # was approved, please note the link to that review and your background here # for sponsors to review. For the re-reviewing of orphaned packages, I opened a FESCo ticket [1] so it can be properly added to relevant policies, or have the decision logged that those should not be required. [1]: https://pagure.io/fesco/issue/2734 ___ 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
Fedora-Rawhide-20220117.n.1 compose check report
No missing expected images. Compose PASSES proposed Rawhide gating check! All required tests passed Failed openQA tests: 17/228 (x86_64), 25/159 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220114.n.0): ID: 1106996 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1106996 ID: 1106998 Test: x86_64 Workstation-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/1106998 ID: 1107000 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/1107000 ID: 1107002 Test: x86_64 Workstation-live-iso evince URL: https://openqa.fedoraproject.org/tests/1107002 ID: 1107004 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1107004 ID: 1107013 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1107013 ID: 1107066 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1107066 ID: 1107091 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/1107091 ID: 1107118 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1107118 ID: 1107132 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1107132 ID: 1107133 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1107133 ID: 1107136 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1107136 ID: 1107138 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1107138 ID: 1107143 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1107143 ID: 1107154 Test: x86_64 Workstation-upgrade gedit URL: https://openqa.fedoraproject.org/tests/1107154 ID: 1107158 Test: x86_64 Workstation-upgrade evince URL: https://openqa.fedoraproject.org/tests/1107158 ID: 1107160 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1107160 ID: 1107163 Test: x86_64 Workstation-upgrade apps_startstop URL: https://openqa.fedoraproject.org/tests/1107163 ID: 1107174 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1107174 ID: 1107177 Test: aarch64 Workstation-upgrade desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1107177 ID: 1107178 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1107178 ID: 1107186 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1107186 ID: 1107189 Test: aarch64 Workstation-upgrade gedit@uefi URL: https://openqa.fedoraproject.org/tests/1107189 ID: 1107190 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1107190 ID: 1107230 Test: x86_64 universal install_shrink_ext4 URL: https://openqa.fedoraproject.org/tests/1107230 ID: 1107271 Test: aarch64 universal install_xfs@uefi URL: https://openqa.fedoraproject.org/tests/1107271 ID: 1107291 Test: aarch64 universal install_repository_http_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1107291 ID: 1107300 Test: aarch64 universal install_blivet_with_swap@uefi URL: https://openqa.fedoraproject.org/tests/1107300 ID: 1107337 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/1107337 Old failures (same test failed in Fedora-Rawhide-20220114.n.0): ID: 1106989 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1106989 ID: 1106990 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1106990 ID: 1107018 Test: x86_64 KDE-live-iso base_selinux URL: https://openqa.fedoraproject.org/tests/1107018 ID: 1107025 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1107025 ID: 1107048 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/1107048 ID: 1107070 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1107070 ID: 1107106 Test: aarch64 Server-dvd-iso base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1107106 ID: 1107116 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1107116 ID: 1107149 Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi URL: https://openqa.fedoraproject.org/tests/1107149 ID: 1107151 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1107151 ID: 1107247 Test: x86_64 universal install_asian_language URL:
Re: gcc-12.0.0-0.4.fc36 in rawhide
Jakub Jelinek wrote: > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. Certain Ada source files trigger what looks like infinite tail recursion in add_sibling_attributes in dwarf2out.c: https://bugzilla.redhat.com/show_bug.cgi?id=2041667 Björn Persson pgpaayNBpxRq6.pgp Description: OpenPGP digital signatur ___ 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: Request assistance getting a package (usbrelay) into Fedora
Mark, Petr's suggestion I find a co maintainer sounds very sensible. It's unlikely I'll need to do any other package. I would be pleased to assist you if you chose to be that person. Darryl ___ 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: Self Introduction: Jun Miao(miaojun0823)
Hi Chen, Thanks for your welcome, let`s contribute our effort to Fedora community. BR Jun On 2022/1/17 08:50, xinghong chen wrote: welcome Jun, It's very nice to have talk with 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ 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: hiredis soname bump
On Mon, Jan 17, 2022 at 10:44:57AM +1100, Nathan Scott wrote: > On Mon, Jan 17, 2022 at 10:35 AM Iñaki Ucar wrote: > > On Mon, 17 Jan 2022 at 00:21, Nathan Scott wrote: > > > On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote: > > > > > > > > Greetings. > > > > > > > > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to > > > > 1.0.2, which includes a soname bump. > > > > > > I think upstream may have reverted this change FWIW ... > > > https://github.com/redis/hiredis/issues/990 > > > > This refers to the incorrect SONAME bump in 1.0.1 with respect to > > 1.0.0. But as Kevin said, we still have 0.13.3 in Fedora, so... > > Aha - right you are, thanks for the correction. ok, so I made the sidetag (f36-build-side-49618) and rebuilt things, but of course now there's 4 more erroring packages (I guess due to gcc12?). Any help welcomed. :) (bccing maintainers) gearmand https://koji.fedoraproject.org/koji/taskinfo?taskID=81386050 ... ./gear_config.h:35:25: error: conversion from 'int' to 'const std::string' {aka 'const std::__cxx11::basic_string'} is ambiguous sems https://koji.fedoraproject.org/koji/taskinfo?taskID=81386117 ... /builddir/build/BUILD/sems-baad4717fdb3c02a63eb4869f31ec33ff8ec1fed/core/tests/fct.h:267:12: error: '__builtin_strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation] seqan3 https://koji.fedoraproject.org/koji/taskinfo?taskID=81386062 /builddir/build/BUILD/seqan3-3.1.0/include/seqan3/utility/concept/exposition_only/core_language.hpp:67:5: error: testing if a concept-id is a valid expression; add 'requires' to check satisfaction [-Werror=missing-requires] 67 | std::convertible_to= v1), bool>; suircata https://koji.fedoraproject.org/koji/taskinfo?taskID=81386008 Compiling suricata v6.0.4 (/builddir/build/BUILD/suricata-6.0.4/rust) /usr/lib/librustc_driver-f074454651f889f4.so(+0x4d3083)[0xf3c95083] linux-gate.so.1(__kernel_sigreturn+0x0)[0xf7f9a570] /usr/lib/libLLVM-13.so(+0xf564fe)[0xee3684fe] /usr/lib/libLLVM-13.so(+0xf586ae)[0xee36a6ae] /usr/lib/libLLVM-13.so(+0x104900f)[0xee45b00f] /usr/lib/libLLVM-13.so(_ZN4llvm18ScheduleDAGSDNodes12EmitScheduleERNS_26MachineInstrBundleIteratorINS_12MachineInstrELb0EEE+0x382)[0xee45a1a2] /usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGEv+0xa2a)[0xee532fca] /usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel16SelectBasicBlockENS_14ilist_iteratorINS_12ilist_detail12node_optionsINS_11InstructionELb0ELb0EvEELb0ELb1EEES6_Rb+0x303)[0xee532543] /usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel20SelectAllBasicBlocksERKNS_8FunctionE+0x2204)[0xee531d14] /usr/lib/libLLVM-13.so(_ZN4llvm16SelectionDAGISel20runOnMachineFunctionERNS_15MachineFunctionE+0xc22)[0xee52e932] /usr/lib/libLLVM-13.so(+0x37b98e1)[0xf0bcb8e1] /usr/lib/libLLVM-13.so(_ZN4llvm19MachineFunctionPass13runOnFunctionERNS_8FunctionE+0x14b)[0xedfddd0b] /usr/lib/libLLVM-13.so(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x598)[0xedd407d8] /usr/lib/libLLVM-13.so(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x48)[0xedd48148] /usr/lib/libLLVM-13.so(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x43b)[0xedd40fdb] /usr/lib/libLLVM-13.so(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x2b)[0xedd484fb] /usr/lib/librustc_driver-f074454651f889f4.so(+0x5702ed)[0xf3d322ed] /usr/lib/librustc_driver-f074454651f889f4.so(+0x8752aa)[0xf40372aa] /usr/lib/librustc_driver-f074454651f889f4.so(+0x87aefe)[0xf403cefe] /usr/lib/librustc_driver-f074454651f889f4.so(+0x893167)[0xf4055167] /usr/lib/librustc_driver-f074454651f889f4.so(+0x88c6e4)[0xf404e6e4] /usr/lib/librustc_driver-f074454651f889f4.so(+0x7a91a3)[0xf3f6b1a3] /usr/lib/librustc_driver-f074454651f889f4.so(+0x820c27)[0xf3fe2c27] /usr/lib/libstd-1c430345c3146024.so(rust_metadata_std_6938c2bdeba667b5+0x9d37b)[0xf36d537b] /usr/lib/libc.so.6(+0x8baf1)[0xf34d9af1] /usr/lib/libc.so.6(+0x1118cc)[0xf355f8cc] error: could not compile `suricata` 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Big Node.js jump coming to EPEL 7
Last week, I retired the `nodejs` package from EPEL 7 because it was (I believed) stuck on Node.js 6.x due to insufficient dependency support. Apparently, this broke a few things like uglify-js[1], so I spent today looking into whether I could get Node.js 16.x to work (the latest LTS release) and it turns out that I can indeed bludgeon it into working. I have a COPR[2] with a build of Node.js 16.x for EPEL 7 available to try while I await releng unretiring[3] the package. Please note: Node.js 16.x is a SIGNIFICANT version jump. It is very probably that some of your Node packages may not work properly against it. I urge anyone who is maintaining any such packages in EPEL 7 to try them out against the aforementioned COPR prior to my building it in EPEL proper. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2041022 [2] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs_epel7/ [3] https://pagure.io/releng/issue/10541 ___ 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
Fedora rawhide compose report: 20220117.n.1 changes
OLD: Fedora-Rawhide-20220114.n.0 NEW: Fedora-Rawhide-20220117.n.1 = SUMMARY = Added images:1 Dropped images: 9 Added packages: 19 Dropped packages:0 Upgraded packages: 248 Downgraded packages: 1 Size of added packages: 45.36 MiB Size of dropped packages:0 B Size of upgraded packages: 7.92 GiB Size of downgraded packages: 1.10 MiB Size change of upgraded packages: 26.86 MiB Size change of downgraded packages: -222.98 KiB = ADDED IMAGES = Image: KDE raw-xz armhfp Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20220117.n.1.armhfp.raw.xz = DROPPED IMAGES = Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20220114.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220114.n.0.s390x.raw.xz Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20220114.n.0.iso Image: Xfce raw-xz armhfp Path: Spins/armhfp/images/Fedora-Xfce-Rawhide-20220114.n.0.armhfp.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20220114.n.0.s390x.qcow2 Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20220114.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20220114.n.0.s390x.tar.xz Image: Kinoite dvd-ostree aarch64 Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20220114.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20220114.n.0.s390x.tar.xz = ADDED PACKAGES = Package: angband-4.2.3-4.fc36 Summary: Popular roguelike role playing game RPMs:angband angband-data angband-doc Size:5.23 MiB Package: boost-http-server-0-1.20220116gitcd5245f.fc36 Summary: Improvements on top of the Boost Asio HTTP server example RPMs:boost-http-server boost-http-server-devel boost-http-server-doc Size:973.35 KiB Package: dub-1.23.0-2.fc36 Summary: Package and build management system for D RPMs:dub Size:2.68 MiB Package: golang-github-hashicorp-envparse-0-0.1.20220114gitd9cfd74.fc36 Summary: Minimal environment variable parser for Go RPMs:golang-github-hashicorp-envparse-devel Size:19.62 KiB Package: hash-slinger-3.1-2.fc36 Summary: Generate and verify various DNS records such as SSHFP, TLSA and OPENPGPKEY RPMs:hash-slinger Size:40.41 KiB Package: kiss-0~20211207git22cf331-1.fc36 Summary: Initial setup for systems using Plasma RPMs:kiss Size:243.29 KiB Package: mrcpp-1.4.1-3.fc36 Summary: A numerical mathematics library based on multiresolution analysis RPMs:mrcpp mrcpp-data mrcpp-devel Size:30.95 MiB Package: perl-Syntax-Keyword-MultiSub-0.02-1.fc36 Summary: Multiple dispatch on subroutines RPMs:perl-Syntax-Keyword-MultiSub perl-Syntax-Keyword-MultiSub-tests Size:146.92 KiB Package: rubygem-cucumber-create-meta-6.0.1-1.fc36 Summary: Produce the meta message for Cucumber Ruby RPMs:rubygem-cucumber-create-meta rubygem-cucumber-create-meta-doc Size:218.02 KiB Package: rubygem-cucumber-cucumber-expressions-14.0.0-1.fc36 Summary: A simpler alternative to Regular Expressions RPMs:rubygem-cucumber-cucumber-expressions rubygem-cucumber-cucumber-expressions-doc Size:295.16 KiB Package: rubygem-cucumber-gherkin-22.0.0-1.fc36 Summary: Fast Gherkin lexer/parser RPMs:rubygem-cucumber-gherkin rubygem-cucumber-gherkin-doc Size:330.02 KiB Package: rubygem-cucumber-tag-expressions-4.0.2-1.fc36 Summary: Cucumber tag expressions for ruby RPMs:rubygem-cucumber-tag-expressions rubygem-cucumber-tag-expressions-doc Size:221.54 KiB Package: rust-conhash-0.4.0-1.fc36 Summary: Consistent Hashing library in Rust RPMs:rust-conhash+default-devel rust-conhash-devel Size:18.66 KiB Package: rust-custom_error-1.9.2-1.fc36 Summary: Define custom errors without boilerplate using the custom_error! macro RPMs:rust-custom_error+default-devel rust-custom_error+std-devel rust-custom_error+unstable-devel rust-custom_error-devel Size:39.79 KiB Package: rust-madvr_parse-0.1.3-1.fc36 Summary: MadVR measurement file library RPMs:rust-madvr_parse+default-devel rust-madvr_parse-devel Size:19.96 KiB Package: rust-nix0.22-0.22.2-1.fc36 Summary: Rust friendly bindings to *nix APIs RPMs:rust-nix0.22+default-devel rust-nix0.22-devel Size:208.10 KiB Package: switchboard-plug-tweaks-1.0.3-2.fc36 Summary: Switchboard Tweaks Plug RPMs:switchboard-plug-tweaks Size:463.48 KiB Package: vala-language-server-0.48.4-2.fc36 Summary: Language server for the Vala programming language RPMs:vala-language-server Size:1.34 MiB Package: wlroots0.14-0.14.1-1.fc36 Summary: A modular Wayland compositor library RPMs:wlroots0.14 wlroots0.14-devel Size:1.99 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 2ping-4.5.1-1.fc36 Old package: 2ping
Re: Self Introduction: Garry Williams
On Sunday, January 16, 2022 5:31:41 PM EST Sebastian Crane wrote: > Welcome to Fedora! The Bridge Hand Generator looks really > interesting. I've been meaning to learn Bridge; now I'll be able to > have computer-assistance for at least the dealing aspect! Thank you for the warm welcome, Sebastian. You will never regret learning the game of bridge. I encourage you to give it a try. -- Garry T. Williams ___ 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: IMA signing questions
On Thu, Jan 6, 2022 at 5:17 AM Patrick マルタインアンドレアス Uiterwijk wrote: > > - How do I generate my own new keypair so I can IMA-sign an RPM? > > You can generate the key with the standard OpenSSL commands. > For example, an RSA key can be generated like: > openssl genrsa | openssl pkcs8 -topk8 -nocrypt -outform DER -out > privatekey.der > > (do note that the key will need to be in DER format). Thanks for these tips. rpm-sign complains when I use a DER-formatted key. I switched to a regular PEM-formatted key file, and that works. Looking at libimaevm's read_priv_pkey(), it checks for a "pkcs11:" URI, and if it doesn't find that string prefix, it just calls fopen and PEM_read_PrivateKey. Reading rpm_head_signing/verify_rpm.py it looks like you're sending a DER-formatted file to "evmctl ima_verify". I guess that's where the DER format comes in? Something else I'm wondering: rpmsign writes those four-byte "keyid" values to my FILESIGNATURE entries even if I don't have a public cert at all. How does it do that? I see verify_rpm.py checks the RPM's keyid values against the final four bytes of a sha1 of a public certificate, but what if I haven't generated that yet? Also, on Rawhide, rpmsign fails with an error in EVP_PKEY_sign. Example with a random SRPM: rpmsign --addsign --define "_gpg_name secur...@example.com" --signfiles --fskpath privatekey.pem bash-5.1.8-3.fc36.src.rpm bash-5.1.8-3.fc36.src.rpm: hash(sha1): 9958fb4ee30415c75bd992982ac1463c6ff6ce739e00aaf7d7ad992feb0b40f1 sign_hash_v2: signing failed: (invalid digest length) in EVP_PKEY_sign openssl: error:1C8000A6:Provider routines::invalid digest length error: sign_hash failed error: signFile failed Since this works on CentOS Stream 9, I updated my Rawhide test environment from ima-evm-utils-1.3.2-4.fc36 to the version in CentOS 9 Stream (ima-evm-utils-1.4-4), then rebuilt rpm-4.17.0-4.fc36 against the newer libimaevm.so.3.0.0, and then I could use --signfiles in Rawhide. My builds are at https://fedorapeople.org/~ktdreyer/ima/ . I think the next step is to get ima-evm-utils 1.4 into Fedora. - Ken ___ 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: Self Introduction: Malcolm Inglis (mcinglis)
On Mon, Jan 10, 2022 at 10:47:13AM -0800, Kevin Fenzi wrote: > On Mon, Jan 10, 2022 at 11:07:33AM +0100, Vít Ondruch wrote: > > > > Just FTR, I don't think that as a sponsor, I can close the ticket and that > > is a bit discouraging. > > There's no way to tell pagure.io "everyone in the fedora packager group > thats a manager is a admin here", so I have manually been adding any > sponsor who replies to a ticket. > > I suppose if we wanted we could manually list everyone out and add them > and then add new folks as they became sponsors. > > > > Additionally, I fear it would also leed to 'HI, make me a packager' type > > > tickets (with no other info). We could of course close those or ask for > > > more info, but then someone has to manage that. > > > > > > You have already volunteered for providing the template, that should help to > > solve this. > > Hopefully. :) ok. I have a first cut of a template there now. Open a new issue and you should see it. Happy to accept changes/additions/fixes via direct email or here. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, Jan 17, 2022 at 01:37:08PM -0600, Justin Forbes wrote: > > For kernel, the only bug on the GCC side I'm aware of is > > https://gcc.gnu.org/PR101941 > > We are seeing similar issues in a few different files depending on > arch. Largely due to options compiled in and compile order, nothing > particularly arch specific. All of the failures are with > fortify_string, some are read beyond size of object. Some are write > beyond size of object. Some are directive output may be truncated. > These kernels all build fine against f35 and stable fedora kernels > fail against rawhide, so it is definitely the toolchain changes, and > not limited to bad code brought in through the 5.17 merge window. A > good sampling of the errors can be seen in the build log for > https://koji.fedoraproject.org/koji/taskinfo?taskID=81369256 with most > arches failing in different places. All I've looked at (besides PR101941) was check.c:2836:58: error: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 9 [-Werror=format-truncation=] which boils down to roughly: char a[16]; void f (int x, int y) { int idx; if (y) { idx = x / sizeof (void *); snprintf (a, sizeof a, "pv_ops[%d]", idx); } } where the warning doesn't seem to be a false positive, though perhaps it would need to be a very large module. pv_ops[-268435456] is the longest string for lp64 and pv_ops[-536870912] for ilp32, but even when not negative, pv_ops[536870911] is 18 bytes including zero termination, not 16. If you have other warnings and they seem to be false positives, please send them to Martin Sebor. Jakub ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, Jan 17, 2022 at 12:32 PM Jakub Jelinek wrote: > > On Mon, Jan 17, 2022 at 12:27:15PM -0600, Justin Forbes wrote: > > > gcc 12 snapshot has landed as the system compiler into rawhide today. > > > GCC 12 is going to enter its stage4 development phase (only regression > > > and documentation bugfixes allowed) on Monday 17th, so there should be > > > just those bugfixes and not new features etc. anymore. > > > https://gcc.gnu.org/gcc-12/changes.html lists important changes, > > > most important is probably that vectorization is enabled at -O2 now > > > which is the option with most of the distribution is built with. > > > > > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists > > > some cases where people need to adjust their code. Other things > > > include the usual C++ header changes, where previously some standard > > > header included some other header as an implementation detail but it > > > doesn't > > > any longer and so code that relied on such indirect include that isn't > > > required by the standard needs to include the header that provides > > > whatever > > > it relies on. Or e.g. packages using -Werror where new warnings are > > > reported with the newer compiler and -Werror results in build failures. > > > > > > If there are bugs on the compiler side, please let me know immediately, > > > so that those bugs can be fixed before the mass rebuild next week. > > > > > > > I suppose I should have checked fedora-devel before trying to chase > > down build failures as kernel merge window issues. Kernel builds are > > failing in a few places (depending on arch). > > For kernel, the only bug on the GCC side I'm aware of is > https://gcc.gnu.org/PR101941 We are seeing similar issues in a few different files depending on arch. Largely due to options compiled in and compile order, nothing particularly arch specific. All of the failures are with fortify_string, some are read beyond size of object. Some are write beyond size of object. Some are directive output may be truncated. These kernels all build fine against f35 and stable fedora kernels fail against rawhide, so it is definitely the toolchain changes, and not limited to bad code brought in through the 5.17 merge window. A good sampling of the errors can be seen in the build log for https://koji.fedoraproject.org/koji/taskinfo?taskID=81369256 with most arches failing in different places. Justin ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, Jan 17, 2022 at 12:27:15PM -0600, Justin Forbes wrote: > > gcc 12 snapshot has landed as the system compiler into rawhide today. > > GCC 12 is going to enter its stage4 development phase (only regression > > and documentation bugfixes allowed) on Monday 17th, so there should be > > just those bugfixes and not new features etc. anymore. > > https://gcc.gnu.org/gcc-12/changes.html lists important changes, > > most important is probably that vectorization is enabled at -O2 now > > which is the option with most of the distribution is built with. > > > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists > > some cases where people need to adjust their code. Other things > > include the usual C++ header changes, where previously some standard > > header included some other header as an implementation detail but it doesn't > > any longer and so code that relied on such indirect include that isn't > > required by the standard needs to include the header that provides whatever > > it relies on. Or e.g. packages using -Werror where new warnings are > > reported with the newer compiler and -Werror results in build failures. > > > > If there are bugs on the compiler side, please let me know immediately, > > so that those bugs can be fixed before the mass rebuild next week. > > > > I suppose I should have checked fedora-devel before trying to chase > down build failures as kernel merge window issues. Kernel builds are > failing in a few places (depending on arch). For kernel, the only bug on the GCC side I'm aware of is https://gcc.gnu.org/PR101941 Jakub ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Fri, Jan 14, 2022 at 8:32 AM Jakub Jelinek wrote: > > Hi! > > gcc 12 snapshot has landed as the system compiler into rawhide today. > GCC 12 is going to enter its stage4 development phase (only regression > and documentation bugfixes allowed) on Monday 17th, so there should be > just those bugfixes and not new features etc. anymore. > https://gcc.gnu.org/gcc-12/changes.html lists important changes, > most important is probably that vectorization is enabled at -O2 now > which is the option with most of the distribution is built with. > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists > some cases where people need to adjust their code. Other things > include the usual C++ header changes, where previously some standard > header included some other header as an implementation detail but it doesn't > any longer and so code that relied on such indirect include that isn't > required by the standard needs to include the header that provides whatever > it relies on. Or e.g. packages using -Werror where new warnings are > reported with the newer compiler and -Werror results in build failures. > > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. > I suppose I should have checked fedora-devel before trying to chase down build failures as kernel merge window issues. Kernel builds are failing in a few places (depending on arch). Justin ___ 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: Non-responsive maintainer check for aconole
Thank you. I sent an email to your Red Hat account CC my Red Hat account on Jan 12th. I also filed a PR at https://src.fedoraproject.org/rpms/lldpd/pull-request/6 Finally, I requested help regarding a test failing in dist-git that works locally: https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/R47O6SQYZB4GZADD5QICJMO656BPSDPL/ (I saw a previous PR with a similar problem) Best regards. On Mon, Jan 17, 2022 at 4:56 PM Aaron Conole wrote: > David Sastre writes: > > > In accordance with the Fedora non-responsive maintainer policy, I am > attempting to contact Aaron Conole (aconole). > > Contacted. > > > Does anyone know how to contact this package maintainer? Direct email > and bug reports have had no response. > > Looks like the bug reports got filtered incorrectly, sorry about that. > > OTOH, I don't have any direct emails re: lldpd. > > > This is in reference to these open bugs with lldpd: > > https://bugzilla.redhat.com/show_bug.cgi?id=1797336 > > https://bugzilla.redhat.com/show_bug.cgi?id=1921441 > > https://bugzilla.redhat.com/show_bug.cgi?id=1984478 > > https://bugzilla.redhat.com/show_bug.cgi?id=2040390 > > > > Non-responsive bug has been filed: > > https://bugzilla.redhat.com/show_bug.cgi?id=2041362 > > I'll look at them. Thanks. > > > Output from fedora-active-user: > > > > Last action on koji: > >Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu > [still active] > > > > Last package update on bodhi: > >No activity found on bodhi > > Last actions performed according to fedmsg: > > - david.sas...@redhat.com commented on RHBZ#2041362 'Non-responsive > maintainer check for acon...' on > > 2022-01-17 09:33:36 > > - david.sas...@redhat.com filed a new bug RHBZ#2041362 > 'Non-responsive maintainer check for acon...' on > > 2022-01-17 09:33:36 > > - david.sas...@redhat.com updated 'cc' on RHBZ#2040390 > 'CVE-2021-43612 lldpd: heap-based buffer ...' on > > 2022-01-17 09:19:56 > > - bcot...@redhat.com updated 'bug_status' and 'resolution' on > RHBZ#1921441 'CVE-2020-27827 lldpd: > > lldp/openvswitch: ...' on 2021-11-30 18:51:21 > > - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: > lldp/openvswitch: ...' on 2021-11-30 > > 18:51:21 > > - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: > lldpd' on 2021-11-30 18:40:14 > > - bcot...@redhat.com updated 'bug_status' and 'resolution' on > RHBZ#1876763 'F33FailsToInstall: lldpd' on > > 2021-11-30 18:40:14 > > - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: > lldpd' on 2021-11-04 17:21:25 > > - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: > lldp/openvswitch: ...' on 2021-11-04 > > 17:11:37 > > - jose.p.oliveira@gmail.com updated 'isobsolete' on RHBZ#1797336 > 'lldpd-1.0.12 is available' on 2021-09-19 > > 02:30:31 > > ___ 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: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 17.01.2022 um 05:16 schrieb Chris Murphy : > > On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote: >> >> >> >>> Am 14.01.2022 um 23:51 schrieb Fabio Valentini : >>> >>> >>> Wait, I thought this change was about making the path consistent >>> within Fedora variants? >> >> The question still is whether this is actually useful and beneficial. > > If you value Fedora having a snapshot and rollback scheme of some > kind, it's useful and beneficial. If you don't, then the change is > neutral because it has not a single technical downside presented so > far - just emotive ones. The loss of LSB / FHS compliance is by no means "just emotive", nor is the consequence of probably having to adapt an unknown number of scripts, backup routines, etc. . As you stated in a previous post, LVM snapshot is „under-developed“ and therefore currently not useful. Is there another snapshot & rollback tool in Fedora repository I can use out of the box (after I moved rpm db to /usr)? Unfortunately, I don’t know one. Currently I would have to create a LVM snapshot and a manually crafted selective backup of files and subdirectories. And test all the stuff. Not particularly practical. I guess, an achievement of a truly viable snapshot and rollback system for file-based distributions requires far a greater number of relocations than just the rpm db. The article of a (presumably) Suse employee I’m trying to retrieve (see an earlier post of mine) offers a proposal for this very purpose (including a backwards compatibility link system). This would eventually end up in an FHS 4.x. Moving the rpm db alone adds only disadvantages to file-based distributions, not a single advantage. And it is not neutral either. In the end, we don't really need to do anything. If I understand correctly, rpm-ostree is already implementing the change anyway, without any change voting, and everyone else will continue as before, following LSB/FHS and the current Fedora guidelines. > Again if you see no value in snapshots/rollbacks, you don't see the > advantage. If you like the idea, then you'd also necessarily come to > realize that some pressure on organizing files into locations with > compatible life cycles, so those locations can be independently rolled > back. I see a lot of value in snapshot&rollback systems. And I see not only „some“ pressure (or better requirements) to reorganise files into different locations. The rpm db is far from sufficient. The proposal mentioned above did exactly that, but rpm db did not end up in /usr but together with parts of /var and /etc somewhere else I don’t remember in detail. And if we make adjustments to achieve a snapshot/rollback system, then we should do it right and not stop halfway unfinished. Peter ___ 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: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
> Am 17.01.2022 um 05:17 schrieb Chris Murphy : > > On Sun, Jan 16, 2022 at 4:34 PM Peter Boy wrote: >> >> >> @Neal, I remember a Suse employee made once (about a year ago) a proposal to >> slightly modify FHS to better separate distro specific from local specific >> content, especially in /etc. Unfortunately I can't find the link again. Do >> you happen to know if that was related to Suse's snapshot+rollback scheme? > > Maybe this: > https://github.com/lnussel/lnussel.github.io/blob/fs/_posts/2020-12-16-fslayout.md > Yes, that the right direction. I’ll start my search from that. Thanks Peter ___ 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: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)
On Sunday, January 16, 2022 11:16:57 PM EST Chris Murphy wrote: > On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote: > > > Am 14.01.2022 um 23:51 schrieb Fabio Valentini : > > > > > > > > > Wait, I thought this change was about making the path consistent > > > within Fedora variants? > > > > The question still is whether this is actually useful and beneficial. > > If you value Fedora having a snapshot and rollback scheme of some > kind, it's useful and beneficial. If you don't, then the change is > neutral because it has not a single technical downside presented so > far - just emotive ones. I'm a little concerned about what this increased writing to /usr, which many people have on a SSD, will do. I have everything that gets written to with any regularity on spinning disks. Everything else is SSD. I have to agree with Chris Adams that rpms own things on many top level directories. I have rpms that own programs/files that live on /opt and other top level directories. I also agree that most programs cannot recreate their directory paths and consider it's absense to be a catastrophic failure. I also see things like kmail which uses mariadb as it's storage. It occassionally contains migration scripts to change the format of the database. It never has a migration script to go backwards. We do the same thing with fapolicyd and its lmdb backing storage. We migrate forward, but we never allow backwards migration. To roll back fapolicyd, you'd need to snapshot /var and roll it back. But since /var has the mail spool and other accumulated data, you'd risk losing lots of stuff if /var was rolled back. I'd think the solution for image based distros is to put the rpmdb in /usr/ lib/rpm and bind mount it to /var/lib/rpm. Doing it this way means no changes are needed. -Steve ___ 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: Non-responsive maintainer check for aconole
David Sastre writes: > In accordance with the Fedora non-responsive maintainer policy, I am > attempting to contact Aaron Conole (aconole). Contacted. > Does anyone know how to contact this package maintainer? Direct email and bug > reports have had no response. Looks like the bug reports got filtered incorrectly, sorry about that. OTOH, I don't have any direct emails re: lldpd. > This is in reference to these open bugs with lldpd: > https://bugzilla.redhat.com/show_bug.cgi?id=1797336 > https://bugzilla.redhat.com/show_bug.cgi?id=1921441 > https://bugzilla.redhat.com/show_bug.cgi?id=1984478 > https://bugzilla.redhat.com/show_bug.cgi?id=2040390 > > Non-responsive bug has been filed: > https://bugzilla.redhat.com/show_bug.cgi?id=2041362 I'll look at them. Thanks. > Output from fedora-active-user: > > Last action on koji: >Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu [still > active] > > Last package update on bodhi: >No activity found on bodhi > Last actions performed according to fedmsg: > - david.sas...@redhat.com commented on RHBZ#2041362 'Non-responsive > maintainer check for acon...' on > 2022-01-17 09:33:36 > - david.sas...@redhat.com filed a new bug RHBZ#2041362 'Non-responsive > maintainer check for acon...' on > 2022-01-17 09:33:36 > - david.sas...@redhat.com updated 'cc' on RHBZ#2040390 'CVE-2021-43612 > lldpd: heap-based buffer ...' on > 2022-01-17 09:19:56 > - bcot...@redhat.com updated 'bug_status' and 'resolution' on RHBZ#1921441 > 'CVE-2020-27827 lldpd: > lldp/openvswitch: ...' on 2021-11-30 18:51:21 > - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: > lldp/openvswitch: ...' on 2021-11-30 > 18:51:21 > - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd' > on 2021-11-30 18:40:14 > - bcot...@redhat.com updated 'bug_status' and 'resolution' on RHBZ#1876763 > 'F33FailsToInstall: lldpd' on > 2021-11-30 18:40:14 > - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd' > on 2021-11-04 17:21:25 > - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: > lldp/openvswitch: ...' on 2021-11-04 > 17:11:37 > - jose.p.oliveira@gmail.com updated 'isobsolete' on RHBZ#1797336 > 'lldpd-1.0.12 is available' on 2021-09-19 > 02:30:31 ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, Jan 17, 2022 at 02:59:15PM -, Artur Frenszek-Iwicki wrote: > I tried compiling colobot with the new gcc, expecting it to break in some > new and fascinating way, and got the following error: > > In function 'std::char_traits::copy(char*, char const*, unsigned long)', > inlined from 'std::__cxx11::basic_string, > std::allocator >::_S_copy(char*, char const*, unsigned long)' at > /usr/include/c++/12/bits/basic_string.h:423:21, > inlined from 'std::__cxx11::basic_string, > std::allocator >::_S_copy(char*, char const*, unsigned long)' at > /usr/include/c++/12/bits/basic_string.h:418:7, > inlined from 'std::__cxx11::basic_string, > std::allocator >::_M_replace(unsigned long, unsigned long, char const*, > unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22, > inlined from 'std::__cxx11::basic_string, > std::allocator >::assign(char const*)' at > /usr/include/c++/12/bits/basic_string.h:1645:19, > inlined from 'std::__cxx11::basic_string, > std::allocator >::operator=(char const*)' at > /usr/include/c++/12/bits/basic_string.h:813:28, > inlined from 'Ui::CList::SetItemName(int, > std::__cxx11::basic_string, std::allocator > > const&)' at > /builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28: > /usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing > 9223372036854775810 or more bytes at offsets -4611686018427387902 and > [-4611686018427387903, 4611686018427387904] may overlap up to > 9223372036854775813 bytes at offset -3 [-Werror=restrict] > 431 | return static_cast(__builtin_memcpy(__s1, __s2, > __n)); > | > ^ > > The relevant bit of code is this line: > m_items[i].text = " "; > Where the ".text" struct member is an std::string. > > Any suggestions on how to fix this will be appreciated. Please send me preprocessed source + g++ command line, provided the warning is reproduceable without -flto. Jakub ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Sun, Jan 16, 2022 at 01:18:51PM -0500, Kaleb Keithley wrote: > Ceph fails with gcc-12 too. > > scratch build at > https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838 > > upstream ceph bug at https://tracker.ceph.com/issues/53896 That looks like a ceph bug. C++ says std::unique_ptr is defined in , and while that TU includes , it includes it only after src/include/rados/buffer.h has on line 97+ template struct unique_leakable_ptr : public std::unique_ptr> { using std::unique_ptr>::unique_ptr; }; Most likely with earlier g++ releases you got or parts of it indirectly from some other header. #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include are the standard C++ headers that are included before the std::unique_ptr use in the source, looking at g++ 10 output seems that included bits/unique_ptr as implementation detail. https://gcc.gnu.org/r12-2696 removed that implementation detail. Jakub ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
I tried compiling colobot with the new gcc, expecting it to break in some new and fascinating way, and got the following error: In function 'std::char_traits::copy(char*, char const*, unsigned long)', inlined from 'std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.h:423:21, inlined from 'std::__cxx11::basic_string, std::allocator >::_S_copy(char*, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.h:418:7, inlined from 'std::__cxx11::basic_string, std::allocator >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' at /usr/include/c++/12/bits/basic_string.tcc:532:22, inlined from 'std::__cxx11::basic_string, std::allocator >::assign(char const*)' at /usr/include/c++/12/bits/basic_string.h:1645:19, inlined from 'std::__cxx11::basic_string, std::allocator >::operator=(char const*)' at /usr/include/c++/12/bits/basic_string.h:813:28, inlined from 'Ui::CList::SetItemName(int, std::__cxx11::basic_string, std::allocator > const&)' at /builddir/build/BUILD/colobot-colobot-gold-0.2.0-alpha/src/ui/controls/list.cpp:664:28: /usr/include/c++/12/bits/char_traits.h:431:56: error: 'memcpy' accessing 9223372036854775810 or more bytes at offsets -4611686018427387902 and [-4611686018427387903, 4611686018427387904] may overlap up to 9223372036854775813 bytes at offset -3 [-Werror=restrict] 431 | return static_cast(__builtin_memcpy(__s1, __s2, __n)); |^ The relevant bit of code is this line: m_items[i].text = " "; Where the ".text" struct member is an std::string. Any suggestions on how to fix this will be appreciated. Thanks in advance, A.FI. colobot scm: https://src.fedoraproject.org/rpms/colobot/ colobot upstream: https://github.com/colobot/colobot/ koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=81361550 ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
FlexiBLAS is FTBFS in rawhide [1], and upstream has managed to create a MWE that doesn't involve FlexiBLAS [2]. So it seems like an issue specific to CMake + GCC/GFortran 12 + CMake's FortranC Interface. Possible regression in gcc? Iñaki [1] https://koschei.fedoraproject.org/package/flexiblas?collection=f36 [2] https://github.com/mpimd-csc/flexiblas/issues/20#issuecomment-1014597590 On Fri, 14 Jan 2022 at 15:40, Jakub Jelinek wrote: > Hi! > > gcc 12 snapshot has landed as the system compiler into rawhide today. > GCC 12 is going to enter its stage4 development phase (only regression > and documentation bugfixes allowed) on Monday 17th, so there should be > just those bugfixes and not new features etc. anymore. > https://gcc.gnu.org/gcc-12/changes.html lists important changes, > most important is probably that vectorization is enabled at -O2 now > which is the option with most of the distribution is built with. > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists > some cases where people need to adjust their code. Other things > include the usual C++ header changes, where previously some standard > header included some other header as an implementation detail but it > doesn't > any longer and so code that relied on such indirect include that isn't > required by the standard needs to include the header that provides whatever > it relies on. Or e.g. packages using -Werror where new warnings are > reported with the newer compiler and -Werror results in build failures. > > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. > > Another important thing I wanted to say is that we'd like to switch > ppc64le from the numerically problematic IBM extended long double to > IEEE 754 quad long double. This is an ABI change. Some libraries > are already built so that they support both ABIs at the same time, > including glibc, libstdc++, libgcc, libgfortran etc. > For other libraries and binaries, the compiler, assembler and linker > will notice if they use long double and flag them as using either > IBM or IEEE long double and linker (or I think dynamic linker too) > might complain when things are mixed. > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble > but the glibc/gcc libraries are built compatibly with both. > We'd like to configure gcc shortly before the mass rebuild with > --with-long-double-format=ieee so that it will default to > -mabi=ieeelongdouble, probably on a side-tag build first, and it > will be highly desirable to rebuild at least some of the most commonly > used library packages in the order of dependencies there, otherwise > I'd be afraid the mass rebuild could fail for way too many packages > (as the mass rebuild doesn't do dependency order rebuilds but just > goes through packages alphabetically or so). > Any suggestions on which packages have commonly used library packages > that use long double? > readelf -A on libraries on ppc64le prints either nothing (either > the library is thought not to use long double or supports both ABIs > transparently or hasn't been rebuilt for some years), or > Attribute Section: gnu > File Attributes > Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double > for libraries (or binaries or object files) that use IBM long double > only or > Attribute Section: gnu > File Attributes > Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double > for IEEE long doubles. > So I think we want to rebuild on a side-tag packages that > provide shared libraries used by hundreds of other packages that > are > Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double > right now. > > Jakub > ___ > 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 > -- Iñaki Úcar ___ 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: Request for help with sponsor: retry
Your original reviewer (or any Fedora packager) can still approve the package even though they are not a packager sponsor. You just won’t be able to import it until you have found a sponsor. It’s normal to have one or more packages approved before finding a sponsor—seehttps://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#submitting_quality_new_packages. On 1/16/22 11:55, Graham Leggett via devel wrote: Hi all, I’ve had a review of the retry tool athttps://bugzilla.redhat.com/show_bug.cgi?id=2017119, but I need help with a sponsor. Happy to try review some other packages in return, but will need a bit of hand holding. Regards, Graham — ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, 2022-01-17 at 15:10 +0100, Vitaly Zaitsev via devel wrote: > On 17/01/2022 15:00, Ben Beasley wrote: > > dependency “json”: https://github.com/nlohmann/json/issues/3138 > > https://bugzilla.redhat.com/show_bug.cgi?id=2041187 > Rawhide compose doomed again [1] :( , I still haven't the results of koschei opencv altivec build with gcc-12.0.0-0.5, it failed with gcc- 12.0.0-0.4 [2] [2] https://koschei.fedoraproject.org/package/opencv?collection=f36 [1] https://kojipkgs.fedoraproject.org/compose/rawhide/ -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gcc-12.0.0-0.4.fc36 in rawhide
On 17/01/2022 15:00, Ben Beasley wrote: dependency “json”: https://github.com/nlohmann/json/issues/3138 https://bugzilla.redhat.com/show_bug.cgi?id=2041187 -- 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: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 17 January (Today)
https://meetbot.fedoraproject.org/fedora-neuro/2022-01-17/neurofedora.2022-01-17-13.02.html On Mon, Jan 17, 2022 at 2:12 PM Luna Jernberg wrote: > Attending, as the Fedora-DI/Diversity meeting today got cancelled and i > got some spare time :) > > On Mon, Jan 17, 2022 at 10:40 AM Ankur Sinha > wrote: > >> Hello everyone, >> >> Please join us at the next Open NeuroFedora team meeting on Monday 17th >> January (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or >> Matrix. The meeting is a public meeting, and open for everyone to >> attend. You can join us over: >> >> Matrix: https://matrix.to/#/#neuro:fedoraproject.org >> IRC: https://webchat.libera.chat/?channels=#fedora-neuro >> >> 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&iso=20220117T13&p1=%3A&ah=1 >> >> The meeting will be chaired by @ankursinha. The agenda for the >> meeting is: >> >> - New introductions and roll call. >> - Tasks from last meeting: >> https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-12-06-13.01.html >> - Open Pagure tickets: >> https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=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 F36: >> 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 >> ___ >> 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 >> > ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On 1/17/22 12:32, Jakub Jelinek wrote: Perhaps Paolo Bonzini is familiar with both qemu and gcc... /me waves hands. This is now https://gcc.gnu.org/PR104067. Paolo ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
Skimming through Koschei, here are a sampling of regressions that seem to be associated with GCC 12. Some of these are in packages I maintain directly; others are via @neuro-sig. With a few exceptions, I have triaged these only to the extent of confirming the problem appeared at the same time as GCC 12 and noting the initial error. I mostly haven’t gotten around to filing or searching for bugs, upstream or downstream. Explicit deletion of the std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems like it is going to be a popular cause of FTBFS in C++ packages. Use of this constructor mostly happens implicitly. I think explicit use of the default constructor, e.g. std::string_view(), will usually be the simplest correct substitute. Problems in popular dependencies (boost, json, opencv) are also impacting a lot of packages. **Internal compiler or debugger error:** abseil-cpp: “internal compiler error: tree code 'template_type_parm' is not supported in LTO streams” debugbreak: %check uses gdb, which now crashes (“(core dumped) gdb -q -x "${exe}-rpm-test.gdb" --batch < /dev/null”) on ppc64le/x86_64, but not on aarch64 **Compilation error from a dependency header:** dependency “boost”: “# error "Never use directly; include instead."”, via boost/multiprecision/cpp_int/intel_intrinsics.hpp octave-iso2mesh dependency “boost”: “error: use of deleted function 'std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::nullptr_t)” via boost/graph/bellman_ford_shortest_paths.hpp python-graph-tool dependency “json”: https://github.com/nlohmann/json/issues/3138 dicomanonymizer giada dependency “opencv”: “invalid parameter combination for AltiVec intrinsic '__builtin_vec_sldw'” on ppc64le, in opencv4/opencv2/core/vsx_utils.hpp fasttrack highfive **New test failures:** moose: “Error: SetGet::strGet: Field Vm not found on Element z”, multiple SIGABRT/SIGSEGV mpir: “mpn_get_d wrong, didn't get 0.0 on underflow” on aarch64, ppc64le python-numpoly: multiple results have dtype 'int64' where 'int32' is expected sleef: https://github.com/shibatch/sleef/issues/439 – failing tests skipped for now New compilation errors: COPASI: “error: passing 'const CDataVectorN' as 'this' argument discards qualifiers [-fpermissive]” grpc: initializing std::string_view/absl::string_view with nullptr – fixed and PR sent upstream python-steps: “static assertion failed: key equality predicate must be invocable with two arguments of key type” via c++/12/bits/hashtable_policy.h vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string' is ambiguous” – looks like an attempt to initialize a string by std::string(nullptr), which is now explicitly deleted (“basic_string(nullptr_t) = delete”) On 1/14/22 09:31, Jakub Jelinek wrote: Hi! gcc 12 snapshot has landed as the system compiler into rawhide today. GCC 12 is going to enter its stage4 development phase (only regression and documentation bugfixes allowed) on Monday 17th, so there should be just those bugfixes and not new features etc. anymore. https://gcc.gnu.org/gcc-12/changes.html lists important changes, most important is probably that vectorization is enabled at -O2 now which is the option with most of the distribution is built with. https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists some cases where people need to adjust their code. Other things include the usual C++ header changes, where previously some standard header included some other header as an implementation detail but it doesn't any longer and so code that relied on such indirect include that isn't required by the standard needs to include the header that provides whatever it relies on. Or e.g. packages using -Werror where new warnings are reported with the newer compiler and -Werror results in build failures. If there are bugs on the compiler side, please let me know immediately, so that those bugs can be fixed before the mass rebuild next week. Another important thing I wanted to say is that we'd like to switch ppc64le from the numerically problematic IBM extended long double to IEEE 754 quad long double. This is an ABI change. Some libraries are already built so that they support both ABIs at the same time, including glibc, libstdc++, libgcc, libgfortran etc. For other libraries and binaries, the compiler, assembler and linker will notice if they use long double and flag them as using either IBM or IEEE long double and linker (or I think dynamic linker too) might complain when things are mixed. Right now the rawhide gcc still defaults to -mabi=ibmlongdouble but the glibc/gcc libraries are built compatibly with both. We'd like to configure gcc shortly before the mass rebuild with --with-long-double-format=ieee so that it will default to -mabi=ieeelongdouble, probably on a side-tag build first, and it will be highly desirable to rebuild at least some of the most common
Re: Fedora Copr EPEL 8 being moved to RHEL+EPEL (and s390x native as bonus)
Hello all! Red Hat subscribed builders (for EPEL 8) have been deployed to production. So any EPEL 8 build in Fedora Copr is now done against RHEL 8 + EPEL 8. As always, please report back any issues. There's though some problem related to the s390x native builders. Please stay tuned on that part... For now, s390x stays emulated (and as I noticed later after the announcement, we haven't enabled the epel-8-s390x chroot, yet - so there's no regression at least). I hope these issues will be resolved by the end of the week. Happy building, Pavel On Monday, January 10, 2022 11:22:03 AM CET Pavel Raiskup wrote: > Hello maintainers. > > Currently, we build all EPEL variants against CentOS "base" in Fedora > Copr, i.e. epel-* configs means CentOS+EPEL. By the end of January 2022 > CentOS 8 mirrors will start disappearing, pushing us to change the configs > to avoid build failures. > > We would like to start the migration to the RHEL base as soon as possible, > so we are at least a bit "ahead" the change. So we can start resolving > the issues. > > There doesn't seem to be a real blocker, or known issue. > > - We got enough subscriptions from Red Hat for Fedora Copr purposes to > start building against official RHEL channels. > > - The Mock + configs is stuck in Bodhi for now, but it doesn't block > Copr to apply for the change earlier. This is mostly about community > decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is > broken. > > - The remaining problem seemed to be the s390x architecture, as the > emulation being _currently_ done wouldn't work with Red Hat > subscriptions, see details in [1] discussion. But thanks to IBM > sponsoring us IBM Cloud access we should be OK to deploy the s390x > arch support in Fedora Copr at the same time with the EPEL change > (this will go in a separate announcement). > > **So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.** If > everything works well at least. > > Side note from me... Note that EPEL 9 in Fedora Copr is still CentOS > Stream 9 + EPEL 9 ATM. This will change to "RHEL 9 + EPEL 9" once RHEL 9 > is generally available (subscribed content). Might seem as a > complication for users, but it's actually not - it is good thing we can > start working on EPEL 9 now. So I want to congratulate to EPEL community > here, the fact we have stream in place allows us to bring EPEL 9 up before > actually RHEL is available. That's an awesome step (jump) forward > compared to previous releases! > > [1] > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/ > > 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: Next Open NeuroFedora Meeting: 1300 UTC on Monday, 17 January (Today)
Attending, as the Fedora-DI/Diversity meeting today got cancelled and i got some spare time :) On Mon, Jan 17, 2022 at 10:40 AM Ankur Sinha wrote: > Hello everyone, > > Please join us at the next Open NeuroFedora team meeting on Monday 17th > January (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or > Matrix. The meeting is a public meeting, and open for everyone to > attend. You can join us over: > > Matrix: https://matrix.to/#/#neuro:fedoraproject.org > IRC: https://webchat.libera.chat/?channels=#fedora-neuro > > 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&iso=20220117T13&p1=%3A&ah=1 > > The meeting will be chaired by @ankursinha. The agenda for the > meeting is: > > - New introductions and roll call. > - Tasks from last meeting: > https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-12-06-13.01.html > - Open Pagure tickets: > https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=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 F36: > 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 > ___ > 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 > ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Fri, 2022-01-14 at 15:31 +0100, Jakub Jelinek wrote: > If there are bugs on the compiler side, please let me know > immediately, so that those bugs can be fixed before the mass rebuild > next week. One of LibreOffice's import tests started to crash during rebuild with gcc-12, sbergman filed a little reproducer as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104007 ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Mon, Jan 17, 2022 at 12:32:36PM +0100, Jakub Jelinek wrote: > On Sun, Jan 16, 2022 at 05:58:10PM +, Richard W.M. Jones wrote: > > I tried recompiling qemu and it fails with an odd error in the RCU > > torture test. Bug submitted upstream here: > > > > https://gitlab.com/qemu-project/qemu/-/issues/823 > > > > ... but since GCC 12 is the only big thing that has changed since we > > just rebuilt qemu, could that be a reason? > > > > https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df675b126264c/tests/unit/rcutorture.c#L320 > > > > Anyway I'll try to nudge someone on the virt team who knows about > > these things to take a look. > > Does -O0 help? -flto vs. -fno-lto? -fno-ipa-modref (gcc 12 is slightly > more aggressive in the interprocedural TBAA)? > If -O0 helps, can you find out if it is the test or something in a library or > whatever that the test uses, and if the latter, try to bisect it to one *.o > file? If -O0 doesn't help, try to mix and match gcc 11 and gcc 12 built > objects. I know next to nothing about qemu, so it would help if somebody > familiar with it did that. Perhaps Paolo Bonzini is familiar with both > qemu and gcc... > Having just one preprocessed source + compiler command line and knowing > roughly what to look for allows bisection and further analysis. Partially answered here: https://gitlab.com/qemu-project/qemu/-/issues/823 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: Request assistance getting a package (usbrelay) into Fedora
Hi, Darryl. > How to clone the GitHub repository in the spec file RPM packages are build from Source files. You don't clone the repository in the spec; rather, you download the repository as a tarball and use that. For GitHub, you can download a specific git tag (or commit) by using the following URL as a source: https://github.com/darrylb123/usbrelay/archive/%{tag_or_commit}/usbrelay-%{tag_or_commit}.tar.gz > should there be one package or a separate python package If the python bindings are usable without the command-line application, or if the application is usable without the python interface - it can be done. You don't need to create a separate .spec file; rather, you can build the python package as a sub-package. For what it's worth, back in the day I wrote a couple of posts on my blog that aim to explain some basics of RPM packaging. Maybe you'll find them useful. - https://blog.svgames.pl/article/basics-of-rpm-packaging - https://blog.svgames.pl/article/building-multiple-packages-with-rpm A.FI. ___ 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: Request assistance getting a package (usbrelay) into Fedora
Hi Darryl, if you have all sources in single repository then only one source package should exist for them. That means one spec file, which can contain multiple sub-packages produced on build. But input should still be single if they come from single repository. You can build both python and native code from single spec file. It you have never worked with RPM, I would recommend finding someone interested as co-maintainer. You would have to create a package review and obtain a sponsor to own your own package in Fedora. To start RPM packaging, I would suggest reading [1]. Also packaging guidelines [2] of course. Or just copy and modify existing spec. I think my sep review [3] might be useful inspiration to you. It contains both python and cmake builds. Your project uses just make, so %make_build and %make_install would be used instead. Spec file is a recipe to build an RPM package, it would need only source archive in addition. 1. https://rpm-packaging-guide.github.io/ 2. https://docs.fedoraproject.org/en-US/packaging-guidelines/ 3. https://bugzilla.redhat.com/show_bug.cgi?id=2029677 On 1/17/22 11:43, Darryl Bond wrote: > Hello, > I maintain a small application hosted on GitHub. > (https://github.com/darrylb123/usbrelay) > It allows control of USB connected electrical relays. Originally it was a > simple command line application. > Over the years, it has accumulated additional features such as a python > interface, and an mqtt daemon. > There is a debian package that has not been maintained for many years. We are > endeavouring to fix that. > As a long term Fedora user, I would love to get it into Fedora. However I > have never attempted to create an rpm package. The more I read, the more > confused I am. > > Questions on Issues like: > - How to clone the GitHub repository in the spec file Spec file does not clone github repository in any way. Source rpm package contains spec file and source code archive. In case of github, it would be obtained from a release tag. Some smart url can be used from github to download tar.gz source archive, from which the code would be built. If you look on sep [3] example, %forgemeta macro with %forgeurl0 make it easy and it would choose correct %forgesource automagically. > - should there be one package or a separate python package. It makes sense to package python3-usbrelay and usbrelay separately. But both would be built from single source. > - what about the daemon/ systemd service... If you do not have separate library and utilities, keep systemd service together with utilities. If library with devel package exists, it should be separate from utilities/daemons. If you have shared library, I think you should have 4 subpackages in total. - usbrelay (utility and daemon) - usbrelay-libs (shared library) - usbrelay-devel (header files and usbrelay.so) - python3-usbrelay (python module) > > Any help greatly appreciated > > Darryl Regards, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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: gcc-12.0.0-0.4.fc36 in rawhide
On Sun, Jan 16, 2022 at 05:58:10PM +, Richard W.M. Jones wrote: > I tried recompiling qemu and it fails with an odd error in the RCU > torture test. Bug submitted upstream here: > > https://gitlab.com/qemu-project/qemu/-/issues/823 > > ... but since GCC 12 is the only big thing that has changed since we > just rebuilt qemu, could that be a reason? > > https://gitlab.com/qemu-project/qemu/-/blob/1cd2ad11d37c48f284f557954e1df675b126264c/tests/unit/rcutorture.c#L320 > > Anyway I'll try to nudge someone on the virt team who knows about > these things to take a look. Does -O0 help? -flto vs. -fno-lto? -fno-ipa-modref (gcc 12 is slightly more aggressive in the interprocedural TBAA)? If -O0 helps, can you find out if it is the test or something in a library or whatever that the test uses, and if the latter, try to bisect it to one *.o file? If -O0 doesn't help, try to mix and match gcc 11 and gcc 12 built objects. I know next to nothing about qemu, so it would help if somebody familiar with it did that. Perhaps Paolo Bonzini is familiar with both qemu and gcc... Having just one preprocessed source + compiler command line and knowing roughly what to look for allows bisection and further analysis. Jakub ___ 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: Request assistance getting a package (usbrelay) into Fedora
I used this software some years ago during my PhD, although ultimately didn't go very far with it (decided against writing my own automation system and outsourced it to an undergrad with LabVIEW...). I would be happy to take a look (especially if I can find that little USB relay again I was having so much fun playing with). Best, Fuller Mark E. Fuller, Ph.D. ful...@fedoraproject.org ful...@stossrohr.net @fuller:one.ems.host https://www.stossrohr.net PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 On 17/01/2022 12:43, Darryl Bond wrote: Hello, I maintain a small application hosted on GitHub. (https://github.com/darrylb123/usbrelay) It allows control of USB connected electrical relays. Originally it was a simple command line application. Over the years, it has accumulated additional features such as a python interface, and an mqtt daemon. There is a debian package that has not been maintained for many years. We are endeavouring to fix that. As a long term Fedora user, I would love to get it into Fedora. However I have never attempted to create an rpm package. The more I read, the more confused I am. Questions on Issues like: - How to clone the GitHub repository in the spec file - should there be one package or a separate python package. - what about the daemon/ systemd service... Any help greatly appreciated Darryl ___ 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 OpenPGP_0xD599E76CFFCABF60.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: gcc-12.0.0-0.4.fc36 in rawhide
On Sun, Jan 16, 2022 at 01:18:51PM -0500, Kaleb Keithley wrote: > Ceph fails with gcc-12 too. > > scratch build at > https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838 > > upstream ceph bug at https://tracker.ceph.com/issues/53896 Can you please mail me preprocessed source on which this now fails and the g++ command line? If it is a compiler change rather than libstdc++ I could bisect and try to find out what's going on. Jakub ___ 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: Request assistance getting a package (usbrelay) into Fedora
On Mon, Jan 17, 2022 at 11:44 AM Darryl Bond wrote: > > Hello, > I maintain a small application hosted on GitHub. > (https://github.com/darrylb123/usbrelay) > It allows control of USB connected electrical relays. Originally it was a > simple command line application. > Over the years, it has accumulated additional features such as a python > interface, and an mqtt daemon. > There is a debian package that has not been maintained for many years. We are > endeavouring to fix that. > As a long term Fedora user, I would love to get it into Fedora. However I > have never attempted to create an rpm package. The more I read, the more > confused I am. Hi! > Questions on Issues like: Maybe I am able to answer some of your questions. > - How to clone the GitHub repository in the spec file Short answer: You don't. RPM packages are (usually) built from declarative "Source" files, not by manually executing steps to get those sources. In this case, you would use the standard git archive / tarball provided by GitHub for the release you want to package, with a parametrized URL like this one: URL: https://github.com/darrylb123/usbrelay Source0: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz This makes it possible to only change the version string in one place and not having to update the Source URLs etc. too. Then for Fedora packages, "spectool" is the tool used to download / prepare those source files before building a source package. "spectool -g usbrelay.spec" will parse your .spec file and download the files from the URLs specified with Source0, Source1, etc. "rpmbuild -bs usbrelay.spec" will then construct your source package, assuming you place the files in the expected locations on file system. "mock usbrelay-0.8-1.fc35.src.rpm" will then build your packages in the standard clean sandbox that's used by all Fedora RPM builds. > - should there be one package or a separate python package. That depends on the use case. Are the python bindings useful without the command line interface? Does the command line interface depend on the python bindings anyway? If they are useful without each other, building a "python3-usbrelay" package from the same "usbrelay" package is possible, you do not need to create separate .spec files for that. > - what about the daemon/ systemd service... Same applies here. If the application is useful without the daemon+service, I'd split those off into a separate sub-package too. 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
Request assistance getting a package (usbrelay) into Fedora
Hello, I maintain a small application hosted on GitHub. (https://github.com/darrylb123/usbrelay) It allows control of USB connected electrical relays. Originally it was a simple command line application. Over the years, it has accumulated additional features such as a python interface, and an mqtt daemon. There is a debian package that has not been maintained for many years. We are endeavouring to fix that. As a long term Fedora user, I would love to get it into Fedora. However I have never attempted to create an rpm package. The more I read, the more confused I am. Questions on Issues like: - How to clone the GitHub repository in the spec file - should there be one package or a separate python package. - what about the daemon/ systemd service... Any help greatly appreciated Darryl ___ 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
Fedora-Cloud-34-20220117.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-20220116.0): ID: 1106135 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1106135 ID: 1106146 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1106146 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: upgrading RH 9 system->Fedora with iso files and apt only
This is exactly what I was looking for. Thanks. https://www.babycarestudio.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 17 January (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 17th January (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or Matrix. The meeting is a public meeting, and open for everyone to attend. You can join us over: Matrix: https://matrix.to/#/#neuro:fedoraproject.org IRC: https://webchat.libera.chat/?channels=#fedora-neuro 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&iso=20220117T13&p1=%3A&ah=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-12-06-13.01.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=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 F36: 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
Packit in 2021
Hello all! We would like to share with you what happened in Packit last year. Here, two blog posts sum it up for you: * https://packit.dev/posts/2021-features/ * https://packit.dev/posts/2021-in-numbers/ Thank all of you who has helped us to achieve that! On behalf of the Packit team, František ___ 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
Non-responsive maintainer check for aconole
In accordance with the Fedora non-responsive maintainer policy, I am attempting to contact Aaron Conole (aconole). Does anyone know how to contact this package maintainer? Direct email and bug reports have had no response. This is in reference to these open bugs with lldpd: https://bugzilla.redhat.com/show_bug.cgi?id=1797336 https://bugzilla.redhat.com/show_bug.cgi?id=1921441 https://bugzilla.redhat.com/show_bug.cgi?id=1984478 https://bugzilla.redhat.com/show_bug.cgi?id=2040390 Non-responsive bug has been filed: https://bugzilla.redhat.com/show_bug.cgi?id=2041362 Output from fedora-active-user: Last action on koji: Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu [still active] Last package update on bodhi: No activity found on bodhi Last actions performed according to fedmsg: - david.sas...@redhat.com commented on RHBZ#2041362 'Non-responsive maintainer check for acon...' on 2022-01-17 09:33:36 - david.sas...@redhat.com filed a new bug RHBZ#2041362 'Non-responsive maintainer check for acon...' on 2022-01-17 09:33:36 - david.sas...@redhat.com updated 'cc' on RHBZ#2040390 'CVE-2021-43612 lldpd: heap-based buffer ...' on 2022-01-17 09:19:56 - bcot...@redhat.com updated 'bug_status' and 'resolution' on RHBZ#1921441 'CVE-2020-27827 lldpd: lldp/openvswitch: ...' on 2021-11-30 18:51:21 - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: lldp/openvswitch: ...' on 2021-11-30 18:51:21 - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd' on 2021-11-30 18:40:14 - bcot...@redhat.com updated 'bug_status' and 'resolution' on RHBZ#1876763 'F33FailsToInstall: lldpd' on 2021-11-30 18:40:14 - bcot...@redhat.com commented on RHBZ#1876763 'F33FailsToInstall: lldpd' on 2021-11-04 17:21:25 - bcot...@redhat.com commented on RHBZ#1921441 'CVE-2020-27827 lldpd: lldp/openvswitch: ...' on 2021-11-04 17:11:37 - jose.p.oliveira@gmail.com updated 'isobsolete' on RHBZ#1797336 'lldpd-1.0.12 is available' on 2021-09-19 02:30:31 ___ 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
Fedora-Cloud-35-20220117.0 compose check report
No missing expected images. Failed openQA tests: 1/8 (aarch64) New failures (same test not failed in Fedora-Cloud-35-20220116.0): ID: 1106069 Test: aarch64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1106069 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-35-20220116.0): ID: 1106061 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1106061 ID: 1106072 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1106072 Passed openQA tests: 7/8 (x86_64), 6/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