Fedora-Rawhide-20210503.n.2 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 1 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 11/193 (x86_64), 12/132 (aarch64) New failures (same test not failed in Fedora-Rawhide-20210502.n.0): ID: 877199 Test: x86_64 KDE-live-iso desktop_terminal **GATING** URL: https://openqa.fedoraproject.org/tests/877199 ID: 877244 Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi URL: https://openqa.fedoraproject.org/tests/877244 ID: 877246 Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi URL: https://openqa.fedoraproject.org/tests/877246 ID: 877275 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/877275 ID: 877281 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/877281 ID: 877285 Test: aarch64 Server-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/877285 Old failures (same test failed in Fedora-Rawhide-20210502.n.0): ID: 877122 Test: x86_64 Server-dvd-iso install_vnc_server URL: https://openqa.fedoraproject.org/tests/877122 ID: 877160 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/877160 ID: 877182 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/877182 ID: 877184 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/877184 ID: 877196 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/877196 ID: 877247 Test: aarch64 Server-dvd-iso install_vnc_server@uefi URL: https://openqa.fedoraproject.org/tests/877247 ID: 877278 Test: aarch64 Server-dvd-iso install_vnc_client@uefi URL: https://openqa.fedoraproject.org/tests/877278 ID: 877354 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/877354 ID: 877356 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/877356 ID: 877383 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/877383 ID: 877384 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/877384 ID: 877392 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/877392 ID: 877411 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/877411 ID: 877419 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/877419 ID: 877428 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/877428 ID: 877433 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/877433 ID: 877437 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/877437 Soft failed openQA tests: 1/193 (x86_64), 3/132 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20210502.n.0): ID: 877220 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/877220 ID: 877227 Test: aarch64 Minimal-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/877227 ID: 877283 Test: aarch64 Server-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/877283 ID: 877307 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/877307 Passed openQA tests: 181/193 (x86_64), 117/132 (aarch64) New passes (same test not passed in Fedora-Rawhide-20210502.n.0): ID: 877148 Test: x86_64 Server-dvd-iso base_package_install_remove URL: https://openqa.fedoraproject.org/tests/877148 ID: 877176 Test: x86_64 Workstation-live-iso base_package_install_remove URL: https://openqa.fedoraproject.org/tests/877176 ID: 877197 Test: x86_64 KDE-live-iso base_package_install_remove URL: https://openqa.fedoraproject.org/tests/877197 ID: 877203 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/877203 ID: 877221 Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove URL: https://openqa.fedoraproject.org/tests/877221 ID: 877235 Test: aarch64 Minimal-raw_xz-raw.xz base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/877235 ID: 877260 Test: aarch64 Server-dvd-iso modularity_tests@uefi URL: https://openqa.fedoraproject.org/tests/877260 ID: 877264 Test: aarch64 Server-dvd-iso base_package_install_remove@uefi URL: https://openqa.fedoraproj
Re: F35 Change: More flexible use of SSSD fast cache for local users (System-Wide Change proposal)
Am Mon, May 03, 2021 at 12:21:31PM -0400 schrieb Neal Gompa:
> On Mon, May 3, 2021 at 10:48 AM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache
> >
> > == Summary ==
> > Allow to switch SSSD’s fast cache for local users on and off at runtime.
> >
> > == Owner ==
> > * Name: [[User:sbose| Sumit Bose]]
> > * Email: sb...@redhat.com
> >
> >
> > == Detailed Description ==
> > In Fedora 26 SSSD’s fast cache for local users was introduced by
> > [[Changes/SSSDCacheForLocalUsers|SSSDCacheForLocalUsers]]. It is
> > currently enabled by default which means that ''sss'' is the first
> > module listed for the ''passwd'' and ''group'' databases in
> > ''/etc/nsswitch.conf'' and that the ''sssd'' monitor process, the
> > ''sssd_nss'' responder and the ''sssd_be'' backend process are running
> > by default. Those defaults made sense because at this time changes to
> > ''/etc/nsswitch.conf'' required a reboot because long running
> > processes were not aware of the changes because ''/etc/nsswitch.conf''
> > was read only once during the first lookup (it might be sufficient to
> > restart all long running processes but a reboot is typically easier).
> > With ''glibc'' version 2.33, available since Fedora 34,
> > ''/etc/nsswitch.conf'' will be reread automatically for the next
> > lookup if it was modified (timestamp changed). This allows to enable
> > or disable SSSD’s fast cache for local users and update
> > ''/etc/nsswitch.conf'' accordingly at runtime as it e.g. was possible
> > with ''nscd'' (''nscd'' is deprecated in Fedora 34 by
> > [[Changes/DeprecateNSCD|DeprecateNSCD]] because SSSD can provide the
> > caching as well, this Change is not in conflict with deprecating
> > ''nscd'' since SSSD can still provide the caching of local users and
> > groups but can now also be switched on and off at runtime without
> > potential impacts on local user lookups).
> > Given that SSSD will not be started by default anymore to provide the
> > cached local users it should not be the first entry in
> > ''/etc/nsswitch.conf'' anymore. It would even be possible to not have
> > the ''sss'' entry in the default ''/etc/nsswitch.conf'' and let
> > ''authselect'' add it if a SSSD related profile is selected.
> > The following components will be affected by the change:
> > * the SSSD package will be built without the ''--enable-files-domain''
> > and the service file will be extended so that SSSD will not be started
> > if no configuration is present
> > ** ''--enable-files-domain'' is already dropped for non-Fedora builds
> > https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_506
> > ** changes to the service file are already available
> > https://github.com/SSSD/sssd/commit/a25256fe22dd0b976093d15a5c7c73e1dc64bbcc
> > and are added already on non-Fedora build where
> > ''--enable-files-domain'' is not set
> > * in ''authselect'' the ''sssd'' profile will have a new feature, e.g.
> > ''with-files-domain'' to set the order in ''nsswitch.conf'' at runtime
> > https://github.com/pbrezina/authselect/commit/cc1d6b15310d8c9616d2ae1c8879baf3ed0f70ab
> > * the default order in ''nsswitch.conf'' in glibc should be updated so
> > that ''files'' is the first.
> > https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc-fedora-nsswitch.patch
> >
> >
> > == Benefit to Fedora ==
> > With this change fewer processes will run in a default or minimal
> > Fedora installation. The runtime enable and disablement will allow to
> > switch on caching of local users and groups when needed but keep the
> > number of processes small when the benefit would be neglectable.
> > The changes to ''/etc/nsswitch.conf'' will be beneficial for
> > environments where the SSSD client libraries are not installed at all
> > as proposed by F35 Change proposal:
> > [[Changes/SmallerContainerBase|Smaller Container Base Image]].
> >
> > == Scope ==
> > * Proposal owners: The SSSD maintainers will enable the needed changes
> > to the SSSD packages and create pull-requests for the changes to
> > ''authselect'' and the modified default ''/etc/nsswitch.conf'' file.
> > * Other developers: ''authselect'' and ''glibc'' maintainers have to
> > accept the pull-requests for their components.
> > * Release engineering: No action from Release engineering is needed.
> > * Policies and guidelines: N/A (not needed for this Change)
> > * Trademark approval: N/A (not needed for this Change)
> > * Alignment with Objectives:
> >
> >
> > == Upgrade/compatibility impact ==
> > Caching of local users and groups by SSSD is not enabled by default
> > anymore and must be enabled manually if needed.
> >
> >
> > == How To Test ==
> > SSSD will not be run by default anymore. Caching of local users and
> > groups can be enabled manually if needed as it was with ''nscd''. The
> > manual steps are
> >
> > authselect select sssd with-files-domain
> > echo -e '[sssd]\nenable_files_domain = True' >
> > /etc/sssd/conf.d/files_domain.conf
> >
Fedora rawhide compose report: 20210503.n.2 changes
OLD: Fedora-Rawhide-20210502.n.0 NEW: Fedora-Rawhide-20210503.n.2 = SUMMARY = Added images:0 Dropped images: 11 Added packages: 1 Dropped packages:0 Upgraded packages: 194 Downgraded packages: 0 Size of added packages: 88.84 KiB Size of dropped packages:0 B Size of upgraded packages: 3.08 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 16.58 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Everything boot s390x Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210502.n.0.iso Image: Server dvd ppc64le Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20210502.n.0.iso Image: Server boot ppc64le Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20210502.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210502.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210502.n.0.iso Image: Cloud_Base qcow2 ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210502.n.0.ppc64le.qcow2 Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210502.n.0.s390x.qcow2 Image: Cloud_Base raw-xz ppc64le Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210502.n.0.ppc64le.raw.xz Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20210502.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210502.n.0.iso Image: Cloud_Base raw-xz s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210502.n.0.s390x.raw.xz = ADDED PACKAGES = Package: rust-vmm-sys-util-0.8.0-2.fc35 Summary: Helpers and utilities used by multiple rust-vmm components and VMMs RPMs:rust-vmm-sys-util+default-devel rust-vmm-sys-util+serde-devel rust-vmm-sys-util+serde_derive-devel rust-vmm-sys-util+with-serde-devel rust-vmm-sys-util-devel Size:88.84 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: OpenImageIO-2.2.14.0-1.fc35 Old package: OpenImageIO-2.2.13.0-1.fc35 Summary: Library for reading and writing images RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils python3-openimageio Size: 20.82 MiB Size change: -3.40 KiB Changelog: * Sun May 02 2021 Richard Shaw - 2.2.14.0-1 - Update to 2.2.14.0. Package: R-4.0.5-1.fc35 Old package: R-4.0.4-1.fc35 Summary: A language for data analysis and graphics RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath libRmath-devel libRmath-static Size: 347.78 MiB Size change: 778.82 KiB Changelog: * Mon May 03 2021 Tom Callaway - 4.0.5-1 - update to 4.0.5 Package: R-qcc-2.7-4.fc35 Old package: R-qcc-2.7-3.fc34 Summary: SQC package for R RPMs: R-qcc Size: 3.23 MiB Size change: -61 B Changelog: * Mon May 03 2021 Iztok Fister Jr. - 2.7-4 - Cosmetic changes - New maintainer of this package Package: ansible-collection-community-mysql-2.1.0-1.fc35 Old package: ansible-collection-community-mysql-1.3.0-1.fc35 Summary: MySQL collection for Ansible RPMs: ansible-collection-community-mysql Size: 69.62 KiB Size change: 8.34 KiB Changelog: * Sun May 02 2021 Orion Poplawski - 2.1.0-1 - Update to 2.1.0 Package: anthy-unicode-1.0.0.20201109-4.fc35 Old package: anthy-unicode-1.0.0.20201109-3.fc35 Summary: Japanese character set input library for Unicode RPMs: anthy-unicode anthy-unicode-devel emacs-anthy-unicode xemacs-anthy-unicode Size: 34.30 MiB Size change: 4.13 KiB Changelog: * Mon May 03 2021 Takao Fujiwara 1.0.0.20201109-4 - Delete unnecessary xemacs in tests/tests.yml Package: arm-none-eabi-binutils-cs-1:2.35-4.fc35 Old package: arm-none-eabi-binutils-cs-1:2.35-3.fc35 Summary: GNU Binutils for cross-compilation for arm-none-eabi target RPMs: arm-none-eabi-binutils-cs Size: 11.15 MiB Size change: -882 B Changelog: * Mon May 03 2021 Michal Hlavinka - 1:2.35-4 - bump release for rebuild Package: arpwatch-14:3.1-13.fc35 Old package: arpwatch-14:3.1-12.fc35 Summary: Network monitoring tools for tracking IP addresses on a network RPMs: arpwatch Size: 1.54 MiB Size change: 1.92 KiB Changelog: * Mon May 03 2021 Benjamin A. Beasley - 14:3.1-13 - Fix systemd sandboxing syntax in unit file - generate ethercodes.dat from latest oui.csv Package: autowrap-0.22.3-1.fc35 Old package: autowrap-0.22.0-5.fc34 Summary: Generates Python Extension modules from [Cython] PXD files RPMs: python3-autowrap Size: 91.60 KiB Size change: 445 B Changelog: * Mon May 03 2021 Antonio Trande - 0.22.3-1 - Release 0.22.3 Package: avogadro2-libs-1.93.1-1.fc35 Old package: avogadro2-libs-1.93.0-8.fc34 Summary
Proposed Release Schedule for 12.0.1 and 13.0.0
Hi, Here is the proposed release schedule for the next 2 releases: 12.0.1 May 11: 12.0.1-rc1 June 8: 12.0.1-rc2 June 22: 12.0.1-final 13.0.0 July 27: release/13.x branch created July 30: 13.0.0-rc1 Aug 24: 13.0.0-rc2 Sep 7: 13.0.0-rc3 Sep 21: 13.0.0-final If there are no objections, I will add these to the website in a few days. -Tom ___ 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: Where is hosted rpm-build package?
On Mon, May 3, 2021 at 3:54 PM Mikhail Gavrilov wrote: > Where is hosted rpm-build package? > > $ fedpkg clone -a rpm-build > Cloning into 'rpm-build'... > fatal: repository 'https://src.fedoraproject.org/rpms/rpm-build.git/' not > found > Could not execute clone: Failed to execute command. > > I want to debug `brp-strip` macro, but for replace this macros in the mock > container I need make my own rpm-build package. $ rpm -qi rpm-build Name: rpm-build Version : 4.16.1.3 Release : 1.fc33 Architecture: x86_64 Install Date: Tue 30 Mar 2021 07:50:00 AM MDT Group : Unspecified Size: 243677 License : GPLv2+ Signature : RSA/SHA256, Mon 22 Mar 2021 06:16:03 AM MDT, Key ID 49fd77499570ff31 Source RPM : rpm-4.16.1.3-1.fc33.src.rpm Build Date : Mon 22 Mar 2021 05:27:58 AM MDT Build Host : buildhw-x86-01.iad2.fedoraproject.org Packager: Fedora Project Vendor : Fedora Project URL : http://www.rpm.org/ Bug URL : https://bugz.fedoraproject.org/rpm Summary : Scripts and executable programs used to build packages Description : The rpm-build package contains the scripts and executable programs that are used to build packages using the RPM Package Manager. Note the "Source RPM" line. That tells you that you want the rpm package. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Where is hosted rpm-build package?
Where is hosted rpm-build package? $ fedpkg clone -a rpm-build Cloning into 'rpm-build'... fatal: repository 'https://src.fedoraproject.org/rpms/rpm-build.git/' not found Could not execute clone: Failed to execute command. I want to debug `brp-strip` macro, but for replace this macros in the mock container I need make my own rpm-build package. ___ 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
Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
LINUX KERNEL -- Adding to the variety of places where the Linux kernel supports making use of Zstd compression, kernel modules moving forward can now enjoy size reductions with Zstd. Linux already supports optional Gzip and XZ compression of kernel modules while beginning with Linux 5.13 there is support added for Zstd. In user-space, KMOD 28 already supports dealing with Zstd-compressed modules. The compressed modules are suffixed .ko.zst. The support for Zstd compressed kernel modules was sent in as part of the Kbuild updates for the Linux 5.13 merge window. The Kbuild updates also include more LLVM Clang compiler handling work and other alterations, including an indicator whether the kernel was built with link-time optimizations (LTO). Separate from the Kbuild updates and likely for post-5.13, there is renewed work on getting the latest Zstd code within the kernel updated against the upstream state. These patches get the Zstd code in the kernel updated against the latest upstream code, which is much newer than the current Zstd 1.3.1 derived code in the kernel. The Zstd kernel code is now generated automatically from the upstream Zstd code. With this pending Zstd code update for the kernel, Btrfs with Zstd compression is 5~15% faster, SquashFS decompression is ~15% faster, F2FS Zstd is 3~20% faster, kernel Zstd decompression is 35% faster, Zram decompression and read is 30% faster, and initramfs Zstd compression is around 5% faster. Plus there are bug fixes and other improvements in re-basing the kernel's Zstd code-base. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Zstd-Modules ___ 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: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
Hello, I take hawtjni, maven-shade-plugin and exec-maven-plugin Thanks Nicolas De Amicis Le 03.05.21 à 10:23, Miro Hrončok a écrit : (The subject line referes to https://www.youtube.com/watch?v=E3418SeWZfQ) The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-05-03.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change Add64 orphan 3 weeks ago R-qcc orphan 1 weeks ago ant-contrib java-maint-sig, mizdebsk, orphan 0 weeks ago aopalliance java-maint-sig, mizdebsk, orphan 0 weeks ago apache-ivy java-maint-sig, mizdebsk, orphan 0 weeks ago arduino elxreno, orphan, patches, thozza 0 weeks ago args4j java-maint-sig, mizdebsk, orphan 0 weeks ago bsh java-maint-sig, mizdebsk, orphan 0 weeks ago cajun-jsonapi orphan 2 weeks ago cal10n java-maint-sig, mizdebsk, orphan 0 weeks ago cgdcbxd orphan 0 weeks ago clang9.0 jistone, orphan, tstellar 2 weeks ago dain-snappy java-maint-sig, mizdebsk, orphan 0 weeks ago disruptor java-maint-sig, mizdebsk, orphan 0 weeks ago dpdk aconole, linville, orphan, tredaell 0 weeks ago dropwatch orphan 0 weeks ago dssi orphan 3 weeks ago dssi-vst orphan 3 weeks ago exec-maven-plugin java-maint-sig, mizdebsk, orphan 0 weeks ago fasterxml-oss-parent java-maint-sig, orphan 0 weeks ago fbreader orphan 3 weeks ago fedora-jam-backgrounds orphan 3 weeks ago fedora-jam-kde-theme jvlomax, orphan 3 weeks ago fluidsynth-dssi orphan 3 weeks ago freight-container orphan 0 weeks ago freight-tools orphan 0 weeks ago freqtweak orphan 3 weeks ago gnome-desktop alexl, caolanm, fmuellner, gnome- 3 weeks ago sig, orphan, rhughes gnome-guitar orphan 3 weeks ago gocomplete go-sig, logic, orphan 2 weeks ago google-gson java-maint-sig, mizdebsk, orphan 0 weeks ago gtk-nodoka-engine orphan 2 weeks ago hamcrest2 java-maint-sig, orphan 0 weeks ago hawtjni java-maint-sig, mizdebsk, orphan 0 weeks ago hexter-dssi orphan 3 weeks ago hsqldb fnasser, mizdebsk, orphan 1 weeks ago icfg orphan 0 weeks ago irqbalance orphan 0 weeks ago isorelax java-maint-sig, mizdebsk, orphan 0 weeks ago jackctlmmc orphan 3 weeks ago jackson-annotations java-maint-sig, orphan 0 weeks ago jackson-bom java-maint-sig, orphan 0 weeks ago jackson-core java-maint-sig, orphan 0 weeks ago jackson-databind java-maint-sig, orphan 0 weeks ago jackson-parent java-maint-sig, orphan 0 weeks ago jakarta-commons-httpclient java-maint-sig, mizdebsk, orphan 0 weeks ago jakarta-el java-maint-sig, orphan 0 weeks ago jakarta-interceptors java-maint-sig, orphan 0 weeks ago jakarta-persistence java-maint-sig, orphan 0 weeks ago jakarta-saaj java-maint-sig, orphan 0 weeks ago jakarta-server-pages java-maint-sig, orphan 0 weeks ago jakarta-ws-rs java-maint-sig, orphan 0 weeks ago jakarta-xml-rpc java-maint-sig, orphan 0 weeks ago jakarta-xml-ws java-maint-sig, orphan 0 weeks ago janino java-maint-sig, orphan 0 weeks ago jansi-native java-maint-sig, mizdebsk, orphan 0 weeks ago javacc java-maint-sig, mizdebsk, orphan 0 weeks ago javacc-maven-
Re: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Mon, May 3, 2021 at 1:12 PM Martin Kolman wrote: > > Good point & we got quite a few reactions for both keeping and removing > the option, so I'll create an official Fedora Change proposal. > Thanks! Feel free to reach out via email or IRC/Matrix if you have any questions. > I guess this can be considered a self-contained change, not a system- > wide one, right ? > Yes, I would call this a self-contained change. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Gnome Fractal and veloren/airshipper needs maintainer
On 5/2/21 10:25 AM, Tomasz Torcz wrote: > Dnia Sun, May 02, 2021 at 02:15:21PM -, Artem Tim napisał(a): >> Veloren and Veloren Airshipper bot using rust-nightly. you can forget about >> packaging it for official repos in Fedora. >> >> Fractal - good luck to package it Fedora. >> >> But both packaged for a long time and available in COPR: >> >> - Fractal: https://copr.fedorainfracloud.org/coprs/atim/fractal/ > > Additionaly someone (Daniel García Moreno?) provides Fractal as > flatpak on flathub. Note that neither of those have ppc64le or s390x builds, though it's another question whether there are such users for a GUI app. ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
> On Thu, Apr 29, 2021 at 4:17 PM Martin Kolman I agree with this change, however it's the sort of thing that should > go through Fedora's Changes process: > https://docs.fedoraproject.org/en-US/program_management/changes_policy/ > > This gives it increased visibility within the Fedora contributor > community and with users. > > > Thanks, > BC Good point & we got quite a few reactions for both keeping and removing the option, so I'll create an official Fedora Change proposal. I guess this can be considered a self-contained change, not a system- wide one, right ? ___ 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: GNOME only: KeepassXC quirks
Il 01/05/21 12:40, Vitaly Zaitsev via devel ha scritto:
> On 01.05.2021 11:44, Germano Massullo wrote:
>> Let's wait also for Jan Grulich. He should be back next days/weeks
>
> Yes, but my simple workaround works fine. We need to add a new method:
>
> ```c++
> #ifdef Q_OS_LINUX
> void wayland_hacks()
> {
> // Workaround to https://github.com/ksnip/ksnip/issues/416
> QByteArray currentDesktop = qgetenv("XDG_CURRENT_DESKTOP").toLower();
> QByteArray sessionDesktop = qgetenv("XDG_SESSION_DESKTOP").toLower();
> QByteArray sessionType = qgetenv("XDG_SESSION_TYPE").toLower();
> if (sessionType.contains("wayland") &&
> (currentDesktop.contains("gnome") || sessionDesktop.contains("gnome")))
> {
> qputenv("QT_QPA_PLATFORM", "xcb");
> }
> }
> #endif
> ```
>
> Then call it in main(), just before the QApplication initialization:
>
> ```c++
> int main(int argc, char** argv)
> {
> #ifdef Q_OS_LINUX
> wayland_hacks();
> #endif
> QApplication app(argc, argv);
> }
> ```
>
https://src.fedoraproject.org/rpms/keepassxc/blob/rawhide/f/xcb.patch
https://bodhi.fedoraproject.org/updates/?packages=keepassxc
Any KeePassXC karma feedback is welcomed
___
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: nokey warning during F33->F34 upgrade (fstrm package)
Il 01/05/21 20:41, Samuel Sieb ha scritto: > On 2021-05-01 2:42 a.m., Germano Massullo wrote: >> Il 30/04/21 18:33, Kevin Fenzi ha scritto: >>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: After running dnf system-upgrade download --releasever=34 and downloading all files, I got the following warning warning: /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY > > Wasn't there a prompt after that to import the key? As far I can see from this my (old) bugreport yes https://bugzilla.redhat.com/show_bug.cgi?id=1286652 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: More flexible use of SSSD fast cache for local users (System-Wide Change proposal)
On Mon, May 3, 2021 at 10:48 AM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache
>
> == Summary ==
> Allow to switch SSSD’s fast cache for local users on and off at runtime.
>
> == Owner ==
> * Name: [[User:sbose| Sumit Bose]]
> * Email: sb...@redhat.com
>
>
> == Detailed Description ==
> In Fedora 26 SSSD’s fast cache for local users was introduced by
> [[Changes/SSSDCacheForLocalUsers|SSSDCacheForLocalUsers]]. It is
> currently enabled by default which means that ''sss'' is the first
> module listed for the ''passwd'' and ''group'' databases in
> ''/etc/nsswitch.conf'' and that the ''sssd'' monitor process, the
> ''sssd_nss'' responder and the ''sssd_be'' backend process are running
> by default. Those defaults made sense because at this time changes to
> ''/etc/nsswitch.conf'' required a reboot because long running
> processes were not aware of the changes because ''/etc/nsswitch.conf''
> was read only once during the first lookup (it might be sufficient to
> restart all long running processes but a reboot is typically easier).
> With ''glibc'' version 2.33, available since Fedora 34,
> ''/etc/nsswitch.conf'' will be reread automatically for the next
> lookup if it was modified (timestamp changed). This allows to enable
> or disable SSSD’s fast cache for local users and update
> ''/etc/nsswitch.conf'' accordingly at runtime as it e.g. was possible
> with ''nscd'' (''nscd'' is deprecated in Fedora 34 by
> [[Changes/DeprecateNSCD|DeprecateNSCD]] because SSSD can provide the
> caching as well, this Change is not in conflict with deprecating
> ''nscd'' since SSSD can still provide the caching of local users and
> groups but can now also be switched on and off at runtime without
> potential impacts on local user lookups).
> Given that SSSD will not be started by default anymore to provide the
> cached local users it should not be the first entry in
> ''/etc/nsswitch.conf'' anymore. It would even be possible to not have
> the ''sss'' entry in the default ''/etc/nsswitch.conf'' and let
> ''authselect'' add it if a SSSD related profile is selected.
> The following components will be affected by the change:
> * the SSSD package will be built without the ''--enable-files-domain''
> and the service file will be extended so that SSSD will not be started
> if no configuration is present
> ** ''--enable-files-domain'' is already dropped for non-Fedora builds
> https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_506
> ** changes to the service file are already available
> https://github.com/SSSD/sssd/commit/a25256fe22dd0b976093d15a5c7c73e1dc64bbcc
> and are added already on non-Fedora build where
> ''--enable-files-domain'' is not set
> * in ''authselect'' the ''sssd'' profile will have a new feature, e.g.
> ''with-files-domain'' to set the order in ''nsswitch.conf'' at runtime
> https://github.com/pbrezina/authselect/commit/cc1d6b15310d8c9616d2ae1c8879baf3ed0f70ab
> * the default order in ''nsswitch.conf'' in glibc should be updated so
> that ''files'' is the first.
> https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc-fedora-nsswitch.patch
>
>
> == Benefit to Fedora ==
> With this change fewer processes will run in a default or minimal
> Fedora installation. The runtime enable and disablement will allow to
> switch on caching of local users and groups when needed but keep the
> number of processes small when the benefit would be neglectable.
> The changes to ''/etc/nsswitch.conf'' will be beneficial for
> environments where the SSSD client libraries are not installed at all
> as proposed by F35 Change proposal:
> [[Changes/SmallerContainerBase|Smaller Container Base Image]].
>
> == Scope ==
> * Proposal owners: The SSSD maintainers will enable the needed changes
> to the SSSD packages and create pull-requests for the changes to
> ''authselect'' and the modified default ''/etc/nsswitch.conf'' file.
> * Other developers: ''authselect'' and ''glibc'' maintainers have to
> accept the pull-requests for their components.
> * Release engineering: No action from Release engineering is needed.
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> Caching of local users and groups by SSSD is not enabled by default
> anymore and must be enabled manually if needed.
>
>
> == How To Test ==
> SSSD will not be run by default anymore. Caching of local users and
> groups can be enabled manually if needed as it was with ''nscd''. The
> manual steps are
>
> authselect select sssd with-files-domain
> echo -e '[sssd]\nenable_files_domain = True' >
> /etc/sssd/conf.d/files_domain.conf
> chmod 600 /etc/sssd/conf.d/files_domain.conf
> systemctl start sssd
>
>
>
> == User Experience ==
> A default installation will have less running processing since the
> SSSD components are not running by default anymore.
>
> == Dependencies ==
Re: nokey warning during F33->F34 upgrade (fstrm package)
Il 01/05/21 19:49, Kevin Fenzi ha scritto: > On Sat, May 01, 2021 at 11:42:52AM +0200, Germano Massullo wrote: >> Il 30/04/21 18:33, Kevin Fenzi ha scritto: >>> On Fri, Apr 30, 2021 at 02:19:31PM +0200, Germano Massullo wrote: After running dnf system-upgrade download --releasever=34 and downloading all files, I got the following warning warning: /var/lib/dnf/system-upgrade/fedora-e21c25ac3662d294/packages/fstrm-0.6.0-4.fc34.x86_64.rpm: Header V4 RSA/SHA256 Signature, ID key 45719a39: NOKEY Why this package does not have a key? >>> That is in fact the f34 key and the package is signed with it. >>> >>> You don't have that key in your rpmdb (which is why it says NOKEY). >> Mmh why it says that only for that package? > Don't know. ;( Do you still have that file? Or it's gone with the > upgrade? What file? >>> There was a fedora-release for f33/f32 that had this key in it, if you >>> updated to that it should have been able to correctly import it. >> I always upgrade from N to N+1 Fedora versions >> >>> Hard to say whats going on without more info. >>> What version is there? what version of fedora-release do you have >>> installed? >> From dnf system upgrade logs I see a >> fedora-release-common-33-4.noarch > Yeah, that should definitely have the key in it and if the rest worked I > don't see why that one package would be singled out... > > Perhaps file a bug on dnf system-upgrade plugin and see if they can > figure it out? Ah I found out this my old bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1286652 which leads to "Feature request: make clear RPM to trigger key import is signed" https://bugzilla.redhat.com/show_bug.cgi?id=1293882 that is a bugreport where people already started to work on it years ago ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Mon, May 3, 2021 at 11:14 AM Martin Kolman wrote: > > On Sat, 2021-05-01 at 23:23 +, patra...@gmail.com wrote: > > > On 4/30/21 10:23 AM, Richard W.M. Jones wrote: > > > > > > +1 > > > > > > in addition to, e.g., an _initial_ setup on a remote/headless box at > > > a VPS. > > > > Ubuntu Server installer handles this in a very nice way by allowing to > > import SSH keys from a GitHub account given a username, i.e. via an URL > > like this: https://github.com/patrakov.keys . Maybe it's a good idea to > > implement the same feature in Anaconda? > Sounds like a good idea - we would certainly accept PRs[0] adding > support for this to Anaconda in a robust manner. :) > > BTW, it seems to me that many developers also use GitLab and many > Fedora projects use Pagure as well. Maybe it would make sense to > support those as well, provided they have a suitable API available of > course. > We don't have an API for this yet in Pagure, but that's only because nobody has asked for it. Contributions are welcome to add an API route to fetch public keys for users. :) -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
Awesome. I'll follow that suggestion and review my Technical Writing notes from the Fall! :) -- Badger Badger Badger Mushroom Mushroom A ssnake On Mon., May 3, 2021, 8:36 a.m. Matthew Miller, wrote: > On Mon, May 03, 2021 at 04:29:54PM +0200, Vít Ondruch wrote: > > Right, but this sub- thread it about > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers > > Ah, sorry. I got lost. :) > > But now that you mention it, I'd like to see that migrated to the new docs > system too. > > -- > Matthew Miller > > Fedora Project Leader > ___ > 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 14:14 +, Wolfgang Ulbrich wrote: > Yes, why not adding an option to anaconda to create a personal ssh > key? > Same like amazon cloud does. > Eg. when you create a el8 server in AWS, AWS gives you an option to > create a ssh key before you finish the setup of this machine. > With that key you can later login to the root account of your AWS > server machine. So if I understand it correctly: - it creates a key pair - makes the provisioned machine thrust the publick key part of the pair - you transfer the private key to your machine and use it to talk to that one machine only Sounds like an interesting idea, although in the non-cloud environment I think the best thing the installer could do is to create the key pair and ann the public key to trusted keys. User would then have to do the rest (transfer the private key in a safe manner to his machine). Yet again, patches welcome, as I'm afraid its unlikely we would get to implementing something like this any time soon. > ___ > 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Fri, 2021-04-30 at 15:33 -0400, DJ Delorie wrote: > > I normally would complain about taking options away from users, but > as I > typically use ssh for root *anyway*, I felt this wasn't appropriate > (although I have a friend who never uses ssh keys, always > password-over-ssh). > > I would, however, ask that the config file have a commented out > option > that re-enables it, with a suitable text comment clearly saying > "uncomment this to allow root passwords over ssh". You are talking about the SSH daemon config file, right ? Sounds like a good ideam to me, independent on the end result of this Anaconda related discussion so I suggest opening a RFE bug on the SSH daemon with this suggestion or even outright sending patches for the default config file. :) > > Perhaps that comment might be a good place to mention ssh-copy-id ? > > Such comments make the "best practices" much more discoverable > without > frustrating users who just want to make things work. > ___ > 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 08:32 +0200, Peter Boy wrote: > > > > Am 29.04.2021 um 22:09 schrieb Martin Kolman : > > > > Hi! > > At the moment the Anaconda installer used by Fedora contains an > > option > > called "Allow SSH root login with password" on the root password > > configuration screen. > > ... > > Note that the checkbox is not ticked by default, the user needs to > > make > > a conscious choice to allow this security problematic SSH login > > behavior. > > ... > > good time to finally drop the "Allow SSH root login with password" > > from > > the Anaconda GUI. > > I greatly appreciate Fedora's emphasis on establishing the most secure > system possible by default. It was one of my reasons to choose Fedora, > years ago. > > But what makes the Anaconda team think that the system administrator > could activate the option for no good reason, just for fun, > recklessness or the joy of 'adventure'? > > I don't mean to be unkind, but in my view you are about to patronize > the system administrator in a kind of missionary overzealousness. But > reading Fedora vision, Fedora is about Freedom, another good reason to > decide for it. Actually, it's the other way around - we believe in the administrator being a professional who can easily an on override via a kickstart if really needed, such as one described here: https://anaconda-installer.readthedocs.io/en/latest/common-bugs.html#enabling-root-password-ssh-login-via-password > > > If you are aware of some critical Fedora/Fedora spin usecase that > > depends on users regularly ticking this option, please let us know! > > No system administrator will 'regularly' ticking that option! That is > an unrealistic assumption. It is reserved for special exceptions > (that's why it is off by default). Others have already described such > cases. > > At the very least, I am in favor of leaving the option in the Server > Edition as it is. The option is currently not parametric in any way, but we do have per product/variant configuration files that encode differences from the Fedora baseline, such as the XFS based default partitioning for the Fedora Server variant: https://github.com/rhinstaller/anaconda/blob/master/data/product.d/fedora-server.conf#L14 So if consensus is reached for keeping the option available on Fedora Server variant only (ideally ACKEd by the Fedora Server SIG) it would be possible to show the option only in the Fedora Server installer variant, at the cost of some added code complexity. > > ___ > 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: Remove old GPG keys?
On Mon, May 03, 2021 at 11:06:44AM -0400, Sam Varshavchik wrote: > My approach is slightly awkward -- having to manually parse the conf > files and perform release and arch substitution. But it has the > advantage of pretty much figuring everything out. It also did me a > favor and found some old conf files on one of my servers, that ages > ago I used – my dim recollection – to do an upgrade from a throwaway > local repo, and so the repo conf referenced keys that did not exist. > It was nice to clean that up. Another thing you can do is just `sudo rpm -e --allmatches gpg-pubkey` and then add back manually when DNF next prompts you. I'm not sure if there's a way to tell DNF to prompt for all current keys other than as a side-effect of wanting to install a package -- Matthew Miller Fedora Project Leader ___ 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: Intention to dropping the the "Allow SSH root login with password" option from the installer GUI
On Sat, 2021-05-01 at 23:23 +, patra...@gmail.com wrote: > > On 4/30/21 10:23 AM, Richard W.M. Jones wrote: > > > > +1 > > > > in addition to, e.g., an _initial_ setup on a remote/headless box at > > a VPS. > > Ubuntu Server installer handles this in a very nice way by allowing to > import SSH keys from a GitHub account given a username, i.e. via an URL > like this: https://github.com/patrakov.keys . Maybe it's a good idea to > implement the same feature in Anaconda? Sounds like a good idea - we would certainly accept PRs[0] adding support for this to Anaconda in a robust manner. :) BTW, it seems to me that many developers also use GitLab and many Fedora projects use Pagure as well. Maybe it would make sense to support those as well, provided they have a suitable API available of course. [0] https://github.com/rhinstaller/anaconda > ___ > 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: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
Il giorno lun, 03/05/2021 alle 10.23 +0200, Miro Hrončok ha scritto: > (The subject line referes to > https://www.youtube.com/watch?v=E3418SeWZfQ) > > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper > reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected > packages or a package that depends on one. Please adopt the affected > package or > retire your depending package to avoid broken dependencies, otherwise > your > package will fail to install and/or build when the affected package > gets retired. > > Request package ownership via the *Take* button in he left column on > https://src.fedoraproject.org/rpms/ > > Full report available at: > https://churchyard.fedorapeople.org/orphans-2021-05-03.txt > grep it for your FAS username and follow the dependency chain. > > For human readable dependency chains, > see https://packager-dashboard.fedoraproject.org/ > For all orphaned packages, > see https://packager-dashboard.fedoraproject.org/orphan > I took these packages, I was comaintainer of most of them. Add64 dssi jmeters lv2-fabla lv2-ll-plugins lv2-mdaEPiano lv2-newtonator lv2-sorcer lv2-swh-plugins lv2-vocoder-plugins meterbridge I tried to take also lv2-c++-tools, but this doesn't work on pagure, maybe for the presence of ++? Fas: tartina Ciao Guido signature.asc Description: This is a digitally signed message part ___ 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: Remove old GPG keys?
Miroslav Suchý writes: Dne 03. 05. 21 v 0:18 Sam Varshavchik napsal(a): Yes, I'm replying to this old thread. See it in the list archives. And, since then, doesn't look much has changed. Old pgp keys are still gathering dust, in everyone's rpm databases. I had nothing else to do this lazy Sunday afternoon, so I finally decided to do something about it. This cleaned up over 40 old PGP keys from one of my laptop: https://github.com/svarshavchik/clean-rpm-gpg-pubkey You inspired me to do: https://github.com/xsuchy/fedora-upgrade/commit/ 138fa54b62c633c6435a86eaf53b0ed44ae48fe5 Although I chosen to remove only enumerated keys. Yeah, so: 1) Someone has to remember to do this as part of every release 2) This doesn't do anything about add-on repositories' keys 3) I had pgp keys going all the way to F19, etc… My approach is slightly awkward -- having to manually parse the conf files and perform release and arch substitution. But it has the advantage of pretty much figuring everything out. It also did me a favor and found some old conf files on one of my servers, that ages ago I used – my dim recollection – to do an upgrade from a throwaway local repo, and so the repo conf referenced keys that did not exist. It was nice to clean that up. pgpfVzGVJABVD.pgp 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
F35 Change: More flexible use of SSSD fast cache for local users (System-Wide Change proposal)
https://fedoraproject.org/wiki/Changes/FlexibleLocalUserCache
== Summary ==
Allow to switch SSSD’s fast cache for local users on and off at runtime.
== Owner ==
* Name: [[User:sbose| Sumit Bose]]
* Email: sb...@redhat.com
== Detailed Description ==
In Fedora 26 SSSD’s fast cache for local users was introduced by
[[Changes/SSSDCacheForLocalUsers|SSSDCacheForLocalUsers]]. It is
currently enabled by default which means that ''sss'' is the first
module listed for the ''passwd'' and ''group'' databases in
''/etc/nsswitch.conf'' and that the ''sssd'' monitor process, the
''sssd_nss'' responder and the ''sssd_be'' backend process are running
by default. Those defaults made sense because at this time changes to
''/etc/nsswitch.conf'' required a reboot because long running
processes were not aware of the changes because ''/etc/nsswitch.conf''
was read only once during the first lookup (it might be sufficient to
restart all long running processes but a reboot is typically easier).
With ''glibc'' version 2.33, available since Fedora 34,
''/etc/nsswitch.conf'' will be reread automatically for the next
lookup if it was modified (timestamp changed). This allows to enable
or disable SSSD’s fast cache for local users and update
''/etc/nsswitch.conf'' accordingly at runtime as it e.g. was possible
with ''nscd'' (''nscd'' is deprecated in Fedora 34 by
[[Changes/DeprecateNSCD|DeprecateNSCD]] because SSSD can provide the
caching as well, this Change is not in conflict with deprecating
''nscd'' since SSSD can still provide the caching of local users and
groups but can now also be switched on and off at runtime without
potential impacts on local user lookups).
Given that SSSD will not be started by default anymore to provide the
cached local users it should not be the first entry in
''/etc/nsswitch.conf'' anymore. It would even be possible to not have
the ''sss'' entry in the default ''/etc/nsswitch.conf'' and let
''authselect'' add it if a SSSD related profile is selected.
The following components will be affected by the change:
* the SSSD package will be built without the ''--enable-files-domain''
and the service file will be extended so that SSSD will not be started
if no configuration is present
** ''--enable-files-domain'' is already dropped for non-Fedora builds
https://src.fedoraproject.org/rpms/sssd/blob/rawhide/f/sssd.spec#_506
** changes to the service file are already available
https://github.com/SSSD/sssd/commit/a25256fe22dd0b976093d15a5c7c73e1dc64bbcc
and are added already on non-Fedora build where
''--enable-files-domain'' is not set
* in ''authselect'' the ''sssd'' profile will have a new feature, e.g.
''with-files-domain'' to set the order in ''nsswitch.conf'' at runtime
https://github.com/pbrezina/authselect/commit/cc1d6b15310d8c9616d2ae1c8879baf3ed0f70ab
* the default order in ''nsswitch.conf'' in glibc should be updated so
that ''files'' is the first.
https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc-fedora-nsswitch.patch
== Benefit to Fedora ==
With this change fewer processes will run in a default or minimal
Fedora installation. The runtime enable and disablement will allow to
switch on caching of local users and groups when needed but keep the
number of processes small when the benefit would be neglectable.
The changes to ''/etc/nsswitch.conf'' will be beneficial for
environments where the SSSD client libraries are not installed at all
as proposed by F35 Change proposal:
[[Changes/SmallerContainerBase|Smaller Container Base Image]].
== Scope ==
* Proposal owners: The SSSD maintainers will enable the needed changes
to the SSSD packages and create pull-requests for the changes to
''authselect'' and the modified default ''/etc/nsswitch.conf'' file.
* Other developers: ''authselect'' and ''glibc'' maintainers have to
accept the pull-requests for their components.
* Release engineering: No action from Release engineering is needed.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
Caching of local users and groups by SSSD is not enabled by default
anymore and must be enabled manually if needed.
== How To Test ==
SSSD will not be run by default anymore. Caching of local users and
groups can be enabled manually if needed as it was with ''nscd''. The
manual steps are
authselect select sssd with-files-domain
echo -e '[sssd]\nenable_files_domain = True' >
/etc/sssd/conf.d/files_domain.conf
chmod 600 /etc/sssd/conf.d/files_domain.conf
systemctl start sssd
== User Experience ==
A default installation will have less running processing since the
SSSD components are not running by default anymore.
== Dependencies ==
The ''glibc'' maintainers have to accept a pull-request to modify the
default ''/etc/nsswitch.conf'' file.
== Contingency Plan ==
* Contingency mechanism: Revert SSSD spec file changes and order
changes in ''/etc/nsswitch.conf''
* Con
Re: New RPM submission
On Mon, May 03, 2021 at 04:29:54PM +0200, Vít Ondruch wrote: > Right, but this sub- thread it about > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Ah, sorry. I got lost. :) But now that you mention it, I'd like to see that migrated to the new docs system too. -- Matthew Miller Fedora Project Leader ___ 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 RPM submission
Dne 03. 05. 21 v 16:14 Matthew Miller napsal(a): On Mon, May 03, 2021 at 11:11:23AM +0200, Vít Ondruch wrote: Just FTR, if anybody has some specific proposal but don't feel empowered to update the wiki, I think it is still good idea to make a copy of the wiki page in their personal space and add the suggestions on top of that page. This way, the specific proposal can be shared with wider audience for a review, until it is deemed acceptable. E.g. in the old days when packaging guidelines were kept in wiki, I used to have drafts like this [1, 2] in my personal space where it is obvious what I am proposing and what is the difference to original. With the new system, you can fork https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages and similarly get the differences, and even submit pull requests which can be commented on. Right, but this sub- thread it about https://fedoraproject.org/wiki/Join_the_package_collection_maintainers Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: New RPM submission
On Mon, May 03, 2021 at 11:11:23AM +0200, Vít Ondruch wrote: > Just FTR, if anybody has some specific proposal but don't feel > empowered to update the wiki, I think it is still good idea to make > a copy of the wiki page in their personal space and add the > suggestions on top of that page. This way, the specific proposal can > be shared with wider audience for a review, until it is deemed > acceptable. > > E.g. in the old days when packaging guidelines were kept in wiki, I > used to have drafts like this [1, 2] in my personal space where it > is obvious what I am proposing and what is the difference to > original. With the new system, you can fork https://pagure.io/packaging-committee/blob/master/f/guidelines/modules/ROOT/pages and similarly get the differences, and even submit pull requests which can be commented on. -- Matthew Miller Fedora Project Leader ___ 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
Gnome Fractal and veloren/airshipper needed maintainer
Hello foks! I will candidate to maintain the fractal and veloren/airshipper package Fábio ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org 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
Intent to orphan maven-verifier-plugin
I adopted maven-verifier-plugin because it was a transitive dependency for condor back in December 2019. I did essentially nothing with it. It is no longer a part of the dependency chain and is about to fall victim to the Javapocalypse[1]. So I plan on orphan it at the end of the week. If anyone wants to pick it up (and thus adopt the dependencies jackson-bom, jackson-parent, jackson-core, apache-ivy, spice-parent, hawtjni, jackson-databind, jackson-annotations, aopalliance, weld-parent, jakarta-server-pages, jansi-native, jakarta-interceptors, snakeyaml), let me know before then and I'll just hand it over to you instead. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
> (The subject line referes to https://www.youtube.com/watch?v=E3418SeWZfQ) Made my day, thanks :) portmidi is affected, and so is python-pygame through portmidi. portmidi does not see any development to speak of but I don't see a direct replacemnt. I can build portmidi without java, though: This would dump the portmidi-tools package, but the library and python bindings would still be there. Are there any portmidi-tools users out there? Cry out loud, please :) ___ 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: Remove old GPG keys?
Dne 03. 05. 21 v 0:18 Sam Varshavchik napsal(a): Yes, I'm replying to this old thread. See it in the list archives. And, since then, doesn't look much has changed. Old pgp keys are still gathering dust, in everyone's rpm databases. I had nothing else to do this lazy Sunday afternoon, so I finally decided to do something about it. This cleaned up over 40 old PGP keys from one of my laptop: https://github.com/svarshavchik/clean-rpm-gpg-pubkey You inspired me to do: https://github.com/xsuchy/fedora-upgrade/commit/138fa54b62c633c6435a86eaf53b0ed44ae48fe5 Although I chosen to remove only enumerated keys. Miroslav ___ 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: KDE Autostart in F34
On Wed, Apr 28, 2021 at 4:15 AM Kevin Kofler via devel wrote: > > Rex Dieter wrote: > > kde plasma on f34 uses systemd user session and > > systemd-xdg-autostart-generator > > Why was this changed? ksmserver worked fine all this time. Why can we not > let systemd handle, well, *system* services (as its name says) and leave > user services to the desktop environment? > Because ksmserver does a bad job of user session management and it was causing serious (nearly release blocking!) bugs for the last few Fedora Linux releases. We had expressed interest to upstream about using systemd user session management for the Plasma session to resolve these issues early last year and they had made it available for Plasma 5.20, so we switched to it then. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: KDE Autostart in F34
> > Thanks Vitaly. We will look into converting it to systemd-user unit. > > I believe that would work for all other desktop managers as well. > > Yeah, you might want to ship both a systemd unit and an XDG autostart > file for the time being. There will still be graphical desktops > environments which are not started using systemd in the foreseeable > future. Hopefully fixed upstream in Plasma 5.22: https://bugs.kde.org/show_bug.cgi?id=433987 ___ 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-32-20210503.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20210502.0): ID: 876465 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/876465 ID: 876472 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/876472 Passed openQA tests: 6/7 (x86_64), 6/7 (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: New RPM submission
Just FTR, if anybody has some specific proposal but don't feel empowered to update the wiki, I think it is still good idea to make a copy of the wiki page in their personal space and add the suggestions on top of that page. This way, the specific proposal can be shared with wider audience for a review, until it is deemed acceptable. E.g. in the old days when packaging guidelines were kept in wiki, I used to have drafts like this [1, 2] in my personal space where it is obvious what I am proposing and what is the difference to original. Vít [1] https://fedoraproject.org/w/index.php?title=User:Vondruch/Draft_RawhideGuidelines&action=history [2] https://fedoraproject.org/w/index.php?title=User:Vondruch/Draft_RawhideGuidelines&diff=509792&oldid=509791 Dne 01. 05. 21 v 10:42 Mattia Verga via devel napsal(a): Il 01/05/21 10:21, Joan Moreau via devel ha scritto: For instance, personally, I am not using Fedora at all (Arch fan ;) ) but just willing to make my piece of software available widely for those interested. I am happy to maintain the package in the long run, but will not get involve to much into Fedora project except my small piece of software contribution. That's absolutely fine, but in my opinion the wiki should clarify one thing: a certain amount of involvement in Fedora should be taken into account if one wants to become a packager. I don't think it's not entirely clear that by publishing a package in Fedora repositories implies 1) maintain the package updated, 2) maintain the specfile in line with future Packaging Guidelines changes and 3) get in touch with the community to handle possible bugs filed by other users which install your package. There must be a section that clearly states that if the scope is "I made this piece of software and I'll fire through Fedora repositories, then goodbye", or "I use this software, I'll push into Fedora repositories and never touch it again until this version is fine for me" there are other means to achieve that. That's the reason for having the "sponsorship barrier" at joining time, that, I know very well, it's quite scaring if you're not English mother tongue. Anyway, after a successful review of a package, one could get in touch with some sponsors by filing a ticket in the appropriate page [1] and some nice folk will help them to enter the packager group. Mattia [1] https://pagure.io/packager-sponsors/ ___ 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: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
On 03. 05. 21 10:43, Michael Schwendt wrote: On Mon, 3 May 2021 10:23:02 +0200, Miro Hrončok wrote: Full report available at: https://churchyard.fedorapeople.org/orphans-2021-05-03.txt grep it for your FAS username and follow the dependency chain. Some more detail would be helpful in this case: Too many dependencies for dpdk, not all listed here mschwendt: dpdk Doesn't ring a bell. And the depchain above isn't complete. Is this package a low-level requirement for NetworkManager? When you are listed, the dependency is listed as well. But sometimes it is hard to find. Yes it is a requirement for NetworkManager. Go to https://churchyard.fedorapeople.org/orphans-2021-05-03.txt Search for mschwendt. Find this: claws-mail (maintained by: mschwendt) claws-mail-3.17.8-4.fc35.src requires NetworkManager-libnm-devel = 1:1.32.0-0.2.fc35 Or go to https://packager-dashboard.fedoraproject.org/mschwendt and search for claws-mail - click "depends on orphaned packages" and "Show dependency network" -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
On Mon, 3 May 2021 10:23:02 +0200, Miro Hrončok wrote: > Full report available at: > https://churchyard.fedorapeople.org/orphans-2021-05-03.txt > grep it for your FAS username and follow the dependency chain. Some more detail would be helpful in this case: Too many dependencies for dpdk, not all listed here > mschwendt: dpdk Doesn't ring a bell. And the depchain above isn't complete. Is this package a low-level requirement for NetworkManager? ___ 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: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
On 03. 05. 21 10:23, Miro Hrončok wrote: Full report available at: https://churchyard.fedorapeople.org/orphans-2021-05-03.txt Depending on: jboss-modules (40), status change: 2021-04-26 (0 weeks ago) byteman (maintained by: jerboaa, jhuttana) byteman-4.0.11-4.fc34.src requires mvn(org.jboss.modules:jboss-modules) = 1.5.2.Final systemtap (maintained by: amerey, drsmith2, fche, jistone, lberk, mcermak, mjw, scox, smakarov, wcohen) systemtap-runtime-java-4.5-0.202104140933gitad00fb87e.fc35.x86_64 requires byteman = 4.0.11-4.fc34 dotnet3.1 (maintained by: crummel, dotnet-sig, omajid, rhea) dotnet3.1-3.1.114-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 dotnet5.0 (maintained by: omajid) dotnet5.0-5.0.202-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 gcc (maintained by: aoliva, jakub, law, mpolacek) gcc-11.1.1-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 glib2 (maintained by: alexl, caillon, caolanm, gnome-sig, mbarnes, mclasen, rhughes, rstrode, rtcm, ssp) glib2-2.68.1-2.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 glibc (maintained by: codonell, djdelorie, fweimer, mcermak, mfabian, pfrankli, siddhesh, submachine) glibc-2.33.9000-2.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 java-11-openjdk (maintained by: ahughes, jerboaa, jvanek) java-11-openjdk-1:11.0.11.0.9-2.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 java-latest-openjdk (maintained by: ahughes, jerboaa, jvanek, pmikova) java-latest-openjdk-1:16.0.1.0.9-2.rolling.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 libcouchbase (maintained by: avsej) libcouchbase-3.1.2-1.fc35.src requires systemtap-devel = 4.5-0.202104140933gitad00fb87e.fc35, systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 libmemcached (maintained by: jorton, remi, tkorbar) libmemcached-1.0.18-22.fc34.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 libvirt (maintained by: berrange, clalance, crobinso, jforbes, laine, libvirt-maint, osier, veillard, virtmaint-sig) libvirt-7.2.0-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 lttng-tools (maintained by: dmarlin, greenscientist, ktdreyer, mjeanson, suchakra) lttng-tools-2.12.3-3.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 lttng-ust (maintained by: dmarlin, greenscientist, ktdreyer, mjeanson, suchakra) lttng-ust-2.12.1-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 lttng-ust-devel-2.12.1-1.fc35.i686 requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 lttng-ust-devel-2.12.1-1.fc35.x86_64 requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 mariadb (maintained by: hhorak, ljavorsk, mbayer, mmuzila, mschorm, spike) mariadb-3:10.5.9-5.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 mir (maintained by: ngompa) mir-2.3.2-2.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 netatalk (maintained by: cicku, kni) netatalk-5:3.1.12-23.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 nodejs (maintained by: mrunge, nodejs-sig, patches, piotrp, sgallagh, zvetlik) nodejs-1:14.16.1-2.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 pcp (maintained by: agerstmayr, lberk, mgoodwin, nathans) pcp-5.3.0-3.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 perl (maintained by: alexl, caillon, caolanm, corsepiu, iarnell, jplesnik, mbarnes, mspacek, ppisar, psabata, rhughes, spot, ssp) perl-4:5.32.1-474.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 perl-devel-4:5.32.1-474.fc35.i686 requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 perl-devel-4:5.32.1-474.fc35.x86_64 requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 php (maintained by: jorton, remi) php-8.0.5-1.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 postgresql (maintained by: hhorak, panovotn, pkubat, praiskup, tgl) postgresql-13.2-6.fc35.src requires systemtap-sdt-devel = 4.5-0.202104140933gitad00fb87e.fc35 python2.7 (maintained by: churchyard, cstratak, python-sig, torsava,
Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)
(The subject line referes to https://www.youtube.com/watch?v=E3418SeWZfQ) The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2021-05-03.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change Add64orphan3 weeks ago R-qccorphan1 weeks ago ant-contrib java-maint-sig, mizdebsk, orphan 0 weeks ago aopalliance java-maint-sig, mizdebsk, orphan 0 weeks ago apache-ivy java-maint-sig, mizdebsk, orphan 0 weeks ago arduino elxreno, orphan, patches, thozza 0 weeks ago args4j java-maint-sig, mizdebsk, orphan 0 weeks ago bsh java-maint-sig, mizdebsk, orphan 0 weeks ago cajun-jsonapiorphan2 weeks ago cal10n java-maint-sig, mizdebsk, orphan 0 weeks ago cgdcbxd orphan0 weeks ago clang9.0 jistone, orphan, tstellar 2 weeks ago dain-snappy java-maint-sig, mizdebsk, orphan 0 weeks ago disruptorjava-maint-sig, mizdebsk, orphan 0 weeks ago dpdk aconole, linville, orphan, tredaell 0 weeks ago dropwatchorphan0 weeks ago dssi orphan3 weeks ago dssi-vst orphan3 weeks ago exec-maven-pluginjava-maint-sig, mizdebsk, orphan 0 weeks ago fasterxml-oss-parent java-maint-sig, orphan0 weeks ago fbreader orphan3 weeks ago fedora-jam-backgrounds orphan3 weeks ago fedora-jam-kde-theme jvlomax, orphan 3 weeks ago fluidsynth-dssi orphan3 weeks ago freight-containerorphan0 weeks ago freight-toolsorphan0 weeks ago freqtweakorphan3 weeks ago gnome-desktopalexl, caolanm, fmuellner, gnome- 3 weeks ago sig, orphan, rhughes gnome-guitar orphan3 weeks ago gocomplete go-sig, logic, orphan 2 weeks ago google-gson java-maint-sig, mizdebsk, orphan 0 weeks ago gtk-nodoka-engineorphan2 weeks ago hamcrest2java-maint-sig, orphan0 weeks ago hawtjni java-maint-sig, mizdebsk, orphan 0 weeks ago hexter-dssi orphan3 weeks ago hsqldb fnasser, mizdebsk, orphan 1 weeks ago icfg orphan0 weeks ago irqbalance orphan0 weeks ago isorelax java-maint-sig, mizdebsk, orphan 0 weeks ago jackctlmmc orphan3 weeks ago jackson-annotations java-maint-sig, orphan0 weeks ago jackson-bom java-maint-sig, orphan0 weeks ago jackson-core java-maint-sig, orphan0 weeks ago jackson-databind java-maint-sig, orphan0 weeks ago jackson-parent java-maint-sig, orphan0 weeks ago jakarta-commons-httpclient java-maint-sig, mizdebsk, orphan 0 weeks ago jakarta-el java-maint-sig,
Re: The Death of Java (packages)
On 4/26/21 10:19 PM, Fabio Valentini wrote: > Hi everybody, > > Long story short, I can no longer in good conscience be the primary > maintainer of (most) Java packages in Fedora. I am not using any of > them, I don't like Java or any other languages targeting the JVM, and > don't get me started on the horrid Java ecosystem. Recently I've been > spending 40-60 hours per week at my desk, and I just don't have the > capacity to feel guilty for not taking care of those packages any > longer. Thank you for the past work, you've done huge effort to keep java packages in Fedora. Best wishes, Markku > > 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 > ___ 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-33-20210503.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210502.0): ID: 876395 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/876395 ID: 876402 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/876402 Passed openQA tests: 6/7 (x86_64), 6/7 (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
