Re: Dropping of sshd.socket unit
On Thu, Aug 03, 2023 at 11:29:03AM +0200, Dmitry Belyavskiy wrote: > Dear colleagues, > > I've pushed a fresh build of OpenSSH to rawhide. > We decided to drop the sshd.socket unit from rawhide. We don't think > it's worth going through the changes process, but would like to > provide a heads-up. > > See the details in https://bugzilla.redhat.com/show_bug.cgi?id=2025716. The DoS attack is described here: https://bugs.archlinux.org/task/62248 ... and it sounds like a bug in systemd. Surely this same attack applies to any socket-activated service so should be fixed in systemd? I don't recall inetd having the same problem. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: LibuserDeprecation (System Wide)
Steve Grubb writes: > On Monday, June 26, 2023 2:47:01 PM EDT Peter Robinson wrote: >> On Thu, Jun 22, 2023 at 5:15 PM Aoife Moloney wrote: >> > >> > >> > https://fedoraproject.org/wiki/Changes/LibuserDeprecation >> > >> > >> > >> > >> > This document represents a proposed Change. As part of the Changes >> > process, proposals are publicly announced in order to receive >> > community feedback. This proposal will only be implemented if approved >> > by the Fedora Engineering Steering Committee. >> > >> > >> > >> > >> > == Summary == >> > >> > >> > >> > Libuser is not actively developed. Most of the depending component >> > have build-time option to work without libuser. >> > >> > >> > >> > == Owner == >> > >> > >> > >> > * Name: [[User:THalman| Tomas Halman]] >> > >> > >> > >> > * Email: >> > >> > >> > >> > >> > == Detailed Description == >> > >> > >> > >> > The libuser provides library and command line utilities to manipulate >> > user and group information. The purpose of the library >> > is/was to hide the differences between users in LDAP and files in etc >> > (passwd, groups...). The support for LDAP >> > is not complete and there is no plan to extend the functionality. >> > >> > >> > >> > The LDAP integration in Fedora is nowadays done by SSSD. >> > >> > >> > >> > In the past, the libuser was used by more component including Fedora >> > installer. Currently the list is short >> > >> > >> > >> > * usermode (Requires development, it is not complicated but the >> > dependency is unconditional) >> > * util-linux (compile time option) >> > * passwd (I suggest to ship passwd utility from shadow-utils instead >> > of passwd and drop passwd package as well) >> >> >> Has the maintainer of the passwd utility been engaged about this >> suggestion? Is there a difference in functionality between the two >> variants of passwd? > > Yes, there is at least one difference that I know of. The one from passwd is > SELinux aware. I think that the threat it is defending against is root being > a shared account. You can have web admin, db admin, security officer, and > other roles. You do not want someone in one of these roles to be able to > change the root password and take over / block other admins. > > If you run in the unconfined domain, then you would never know it's there. > It's when you actually use roles that you bump into this. Both passwd [1] and shadow-utils passwd [2] use "passwd" permission to check whether a root user is allowed to change passwords. In this part the behavior (but output) should not change when /usr/bin/passwd is replaced with the version from shadow-utils. e.g. using passwd.shadow from shadow-utils and for "staff" user assigned to "staff_u" SELinux user with uid 0 it looks like: [root@fedora ~]# id uid=0(root) gid=1003(staff) groups=1003(staff) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023 [root@fedora ~]# passwd passwd: SELinux denying access due to security policy. [root@fedora ~]# passwd.shadow passwd.shadow: root is not authorized by SELinux to change the password of root [1] https://pagure.io/passwd/blob/master/f/selinux_utils.c#_83 [2] https://github.com/shadow-maint/shadow/blob/master/src/passwd.c#L979 Petr > > -Steve > > >> > == Feedback == >> > >> > >> > >> > >> > == Benefit to Fedora == >> > >> > >> > >> > The main benefit is to decrease the maintenance and packaging work on >> > library that does not bring much value while the functionality is >> > provided by another components. >> > >> > >> > >> > == Scope == >> > * Proposal owners: Dropping the package, move it to EPEL eventually >> > >> > >> > >> > >> > * Other developers: >> > >> > >> > >> > ** Update usermode code to make libuser dependency configurable. >> > ** Update usermode packaging to compile it without libuser >> > ** Change packaging of util-linux to compile without libuser dependency >> > ** Change packaging of shadow-utils to provide passwd utility >> > >> > >> > >> > >> > * Release engineering: [https://pagure.io/releng/issue/11492] >> > >> > >> > >> > Libuser is part of base image and must be removed. IMO mass rebuild is >> > not required. >> > >> > >> > >> > >> > * Policies and guidelines: Since this is about dropping packages >> > release notes must be updated. >> > >> > >> > >> > >> > * Trademark approval: N/A (not needed for this Change) >> > >> > >> > >> > * Alignment with Community Initiatives: N/A >> > >> > >> > >> > >> > == Upgrade/compatibility impact == >> > >> > >> > >> > People who used libuser to manipulate users in LDAP will have to move to >> > SSSD. >> >> > >> > >> > == How To Test == >> > >> > >> > >> > 0. no special hardware needed >> > 1. remove libuser, passwd, install new shadow-utils, usermod and >> > util-linux > 2. try to change password of some user >> > 3. try to modify user using usermod >> > 4. expected results: everything works normally >> > >> > >> > >> > == User Experience == >> > This change should not be visible for users. >> >
Removal of Modular repos broke upgrades to Fedora 39: What now?
Hello folks, With the retirement of modularity, the modular dnf repositories for Fedora 39 no longer exist. However, this will introduce a problem during upgrades. When users try to upgrade from previous Fedora releases with fedora-repos-modular installed, they will hit fatal errors that will probably look like this: Errors during downloading metadata for repository 'fedora-modular': - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 (IP: ...) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 (IP: ...) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 (IP: ...) Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 (IP: ...) Or: Error: Failed to download metadata for repository 'fedora-modular': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried (The actual error might differ depending on the exact state of the removal of the modular repos and their mirrorlist etc.) This is caused by the combination of the following facts: - the modular repo configuration in Fedora 37/38 has skip_if_unavailable=False - when the releasever is set to 39, the URLs of the repos give error 404 This is a big deal, because even users who don't use modularity at all (but have not uninstalled fedora-repos-modular) will not be able to upgrade to Fedora 39+ without reaching for help. Adam outlined 3 options to solve this problem in the bugzilla where he reported this: https://bugzilla.redhat.com/2228827 I slept on it and have found a fourth option (but I don't think it's very viable). I'll present all 4 options here: A. Set skip_if_unavailable=True in the modular repo configuration on old Fedora That is, update fedora-repos-modular in Fedora 37 and 38 to have skip_if_unavailable=True. That would mean: 1. Users who have up-to-date Fedora 37 or 38 can upgrade. Yay! 2. Users who don't update their packages before upgrading still cannot upgrade. Technically this is not supported, but I am afraid users will hit this problem. 3. Users of Fedora older than 37 also cannot upgrade. Technically this is not supported, but I am afraid users will hit this problem. 4. Users of modular packages might see weird behavior when the modular repository is temporarily offline and is hence skipped. Considering other quirks of modularity and the assumed small user base, I don't consider this a blocker, but it's "not nice". This solution is far from ideal, but it is easy. It can be done right now. B. Mirror empty modular repositories for the time being That is, the modular repositories would not give error 404, but instead would be empty. We would do this at least for F39 and F40 and we could keep doing that even for a longer while. That would mean: 1. The error would disappear. 2. Users without modules would not notice anything. 3. Only users of Fedora 38 or older upgrading to Fedora X or newer would have a problem and we could decide what X is (whether it's 40 or 50). I think this is a good solution, but it requires some work beyond my own abilities (I have no idea how to achieve this) and it won't happen over night. C. Document this in the upgrade documentation That is, we change nothing in the repos, but we make sure to instruct users to invoke dnf system-upgrade with --disablerepo='*modular*' and perform similar action in GUI tools. That would mean: 1. Users who follow the docs will not be impacted. 2. Users who just click the *Upgrade* button would still be impacted. 3. Users who keep upgrading the way they did for years would still be impacted. 4. Upgrading via GUI might easily get much more complicated than it is today. I think we can hardly call this a solution. D. Change our upgrade tools to disable modular repos on upgrades to F39+ That is, patch dnf system-upgrade, patch PackageKit or whatever does this in GUI in Fedora 37 and 38 to disable the modular repos when upgrading to F39+. That would mean: 1. The error would disappear. 2. Users without modules using the official upgrade tools would not notice anything. 3. Users who upgrade via dnf distro-sync etc. would still be impacted. Technically this is not supported, but I am afraid users will hit this problem. 4. Users of Fedora older than 37 cannot upgrade. Technically this is not supported, but I am afraid users will hit this problem. I think this solution is doomed to be incomplete because there are far to much means of upgrading to a new Fedora release. It also requires a lot of engineering work in various different places and it won't happen fast enough. What do you think we should do? My preference would be to go with option (B)
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote: > Hello folks, > > With the retirement of modularity, the modular dnf repositories for Fedora 39 > no longer exist. However, this will introduce a problem during upgrades. When > users try to upgrade from previous Fedora releases with fedora-repos-modular > installed, they will hit fatal errors that will probably look like this: > > Errors during downloading metadata for repository 'fedora-modular': >- Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) >- Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) >- Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare > internal mirrorlist: Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > > Or: > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were > tried > > (The actual error might differ depending on the exact state of the removal of > the modular repos and their mirrorlist etc.) > > > This is caused by the combination of the following facts: > > - the modular repo configuration in Fedora 37/38 has > skip_if_unavailable=False > - when the releasever is set to 39, the URLs of the repos give error 404 > > This is a big deal, because even users who don't use modularity at all (but > have not uninstalled fedora-repos-modular) will not be able to upgrade to > Fedora 39+ without reaching for help. > > Adam outlined 3 options to solve this problem in the bugzilla where he > reported > this: https://bugzilla.redhat.com/2228827 So an update to this, thanks to Miro for double-checking me: I had forgotten that the openQA tests edit the dnf config to point to the compose tree (in order to make sure we're testing the right thing - there's an ordering problem if we just test the actual 'rawhide' location on the mirror system, it might not have been synced by the time the tests run). It looks like the public 'rawhide' location *does* still have a Modular tree: https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ but there's still a problem there, because...it's now just stale data. That is the Modular tree from the 20230802.n.0 compose, and unless someone does something about it, it always *will* be. Keeping the last set of modular repos frozen in amber forever doesn't seem like the best permanent situation :) So this is still an issue, but at least it doesn't actually immediately break upgrades to Rawhide using the default dnf config. I'll downgrade the bug severity appropriately. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, Aug 04, 2023 at 11:42:07AM +0100, Adam Williamson wrote: > On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote: > > Hello folks, > > > > With the retirement of modularity, the modular dnf repositories for Fedora > > 39 > > no longer exist. However, this will introduce a problem during upgrades. > > When > > users try to upgrade from previous Fedora releases with > > fedora-repos-modular > > installed, they will hit fatal errors that will probably look like this: > > > > Errors during downloading metadata for repository 'fedora-modular': > >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > > > (IP: ...) > >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > > > (IP: ...) > >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > > > (IP: ...) > > Error: Failed to download metadata for repo 'fedora-modular': Cannot > > prepare > > internal mirrorlist: Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > > > (IP: ...) > > > > Or: > > > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were > > tried > > > > (The actual error might differ depending on the exact state of the removal > > of > > the modular repos and their mirrorlist etc.) > > > > > > This is caused by the combination of the following facts: > > > > - the modular repo configuration in Fedora 37/38 has > > skip_if_unavailable=False > > - when the releasever is set to 39, the URLs of the repos give error 404 > > > > This is a big deal, because even users who don't use modularity at all (but > > have not uninstalled fedora-repos-modular) will not be able to upgrade to > > Fedora 39+ without reaching for help. > > > > Adam outlined 3 options to solve this problem in the bugzilla where he > > reported > > this: https://bugzilla.redhat.com/2228827 > > So an update to this, thanks to Miro for double-checking me: I had > forgotten that the openQA tests edit the dnf config to point to the > compose tree (in order to make sure we're testing the right thing - > there's an ordering problem if we just test the actual 'rawhide' > location on the mirror system, it might not have been synced by the > time the tests run). > > It looks like the public 'rawhide' location *does* still have a Modular > tree: > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ > > but there's still a problem there, because...it's now just stale data. > That is the Modular tree from the 20230802.n.0 compose, and unless > someone does something about it, it always *will* be. Keeping the last > set of modular repos frozen in amber forever doesn't seem like the best > permanent situation :) Do we still have the problem where dnf will preferrentially pick content from a modular repo, even if it has older NEVR than the same package name in a non-modular repo ? IOW, would the existance of this stale modular content, prevent the upgrade tools from correctly bringing in content from the new release ? With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, 2023-08-04 at 12:16 +0100, Daniel P. Berrangé wrote: > > > > It looks like the public 'rawhide' location *does* still have a Modular > > tree: > > > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ > > > > but there's still a problem there, because...it's now just stale data. > > That is the Modular tree from the 20230802.n.0 compose, and unless > > someone does something about it, it always *will* be. Keeping the last > > set of modular repos frozen in amber forever doesn't seem like the best > > permanent situation :) > > Do we still have the problem where dnf will preferrentially pick > content from a modular repo, even if it has older NEVR than the > same package name in a non-modular repo ? > > IOW, would the existance of this stale modular content, prevent > the upgrade tools from correctly bringing in content from the > new release ? Well, I think only if you have a module explicitly enabled. We dropped the whole "ooh, if this is in a module, pull it in and enable the module!" thing aaages ago, it only lasted like one release I think. IIRC, anyway. But yes, if you have any modules enabled, the experience is going to be bad. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, Aug 04, 2023 at 12:25:34PM +0100, Adam Williamson wrote: > On Fri, 2023-08-04 at 12:16 +0100, Daniel P. Berrangé wrote: > > > > > > It looks like the public 'rawhide' location *does* still have a Modular > > > tree: > > > > > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ > > > > > > but there's still a problem there, because...it's now just stale data. > > > That is the Modular tree from the 20230802.n.0 compose, and unless > > > someone does something about it, it always *will* be. Keeping the last > > > set of modular repos frozen in amber forever doesn't seem like the best > > > permanent situation :) > > > > Do we still have the problem where dnf will preferrentially pick > > content from a modular repo, even if it has older NEVR than the > > same package name in a non-modular repo ? > > > > IOW, would the existance of this stale modular content, prevent > > the upgrade tools from correctly bringing in content from the > > new release ? > > Well, I think only if you have a module explicitly enabled. We dropped > the whole "ooh, if this is in a module, pull it in and enable the > module!" thing aaages ago, it only lasted like one release I think. > IIRC, anyway. Ok, so for most people it should be fairly harmless having the stale content in the modular repo. During upgrade dnf will look at the repo and ignore all the outdated RPMs. Them presumably something will have an "Obsoletes: fedora-modular-repos" so the repo config files all get erased during the upgrade, and thus the modular content will never be consulted thereafter. IOW, just leavnig the stale repo there forever wouldn't look to be terrible, though from a conceptual POV it would be nicer to just have an empty repo at the URL instead. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20230804.n.0 changes
OLD: Fedora-Rawhide-20230803.n.0 NEW: Fedora-Rawhide-20230804.n.0 = SUMMARY = Added images:1 Dropped images: 2 Added packages: 6 Dropped packages:1 Upgraded packages: 101 Downgraded packages: 0 Size of added packages: 3.89 MiB Size of dropped packages:315.83 KiB Size of upgraded packages: 19.43 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 238.80 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20230804.n.0.iso = DROPPED IMAGES = Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20230803.n.0.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20230803.n.0.iso = ADDED PACKAGES = Package: efs-utils-1.35.0-1.fc39 Summary: Utilities for Amazon Elastic File System (EFS) RPMs:efs-utils Size:60.11 KiB Package: pplite-0.11-1.fc39 Summary: Convex polyhedra library for abstract interpretation RPMs:pplite pplite-devel pplite-tools Size:3.09 MiB Package: python-lark-1.1.7-1.fc39 Summary: Lark is a modern general-purpose parsing library for Python RPMs:python3-lark Size:375.28 KiB Package: rust-gix-object-0.33.1-1.fc39 Summary: Immutable and mutable git objects with decoding and encoding support RPMs:rust-gix-object+default-devel rust-gix-object+serde-devel rust-gix-object+verbose-object-parsing-errors-devel rust-gix-object-devel Size:95.45 KiB Package: rust-gix-sec-0.8.4-1.fc39 Summary: Shared trust model implementation for gix RPMs:rust-gix-sec+default-devel rust-gix-sec+serde-devel rust-gix-sec-devel Size:43.24 KiB Package: rust-goblin0.6-0.6.1-1.fc39 Summary: Impish, cross-platform, ELF, Mach-o, and PE binary parsing and loading crate RPMs:rust-goblin0.6+alloc-devel rust-goblin0.6+archive-devel rust-goblin0.6+default-devel rust-goblin0.6+elf32-devel rust-goblin0.6+elf64-devel rust-goblin0.6+endian_fd-devel rust-goblin0.6+log-devel rust-goblin0.6+mach32-devel rust-goblin0.6+mach64-devel rust-goblin0.6+pe32-devel rust-goblin0.6+pe64-devel rust-goblin0.6+std-devel rust-goblin0.6-devel Size:239.58 KiB = DROPPED PACKAGES = Package: python-lark-parser-0.9.0-11.fc39 Summary: Lark is a modern general-purpose parsing library for Python RPMs:python3-lark-parser Size:315.83 KiB = UPGRADED PACKAGES = Package: 389-ds-base-2.4.3-1.fc39 Old package: 389-ds-base-2.4.2-4.fc39 Summary: 389 Directory Server (base) RPMs: 389-ds-base 389-ds-base-devel 389-ds-base-libs 389-ds-base-snmp cockpit-389-ds python3-lib389 Size: 21.36 MiB Size change: 45.85 KiB Changelog: * Mon Jul 24 2023 Mark Reynolds - 2.4.2-5 - Bump version to 2.4.2-5 - Add the bash completion scripts to the appropriate files section * Thu Aug 03 2023 Mark Reynolds - 2.4.3-1 - Bump version to 2.4.3-1 - Issue 5729 - Memory leak in factory_create_extension (#5814) - Issue 5870 - ns-slapd crashes at startup if a backend has no suffix (#5871) - Issue 5876 - CI Test random failure - Import (#5879) - Issue 5877 - test_basic_ldapagent breaks test_setup_ds_as_non_root* tests - Issue 5867 - lib389 should use filter for tarfile as recommended by PEP 706 (#5868) - Issue 5853 - Update Cargo.lock and fix minor warning (#5854) - Issue 5785 - CLI - arg completion is broken - Issue 5864 - Server fails to start after reboot because it's unable to access nsslapd-rundir - Issue 5856 - SyntaxWarning: invalid escape sequence '\,' - Issue 5859 - dbscan fails with AttributeError: 'list' object has no attribute 'extends' - Issue 3527 - UI - Add nsslapd-haproxy-trusted-ip to server setting (#5839) - Issue 4551 - Paged search impacts performance (#5838) - Issue 4758 - Add tests for WebUI - Issue 4169 - UI - Fix retrochangelog and schema Typeaheads (#5837) - issue 5833 - dsconf monitor backend fails on lmdb (#5835) - Issue 3555 - UI - Fix audit issue with npm - stylelint (#5836) Package: adobe-mappings-cmap-20230622-1.fc39 Old package: adobe-mappings-cmap-20230118-3.fc39 Summary: CMap resources for Adobe's character collections RPMs: adobe-mappings-cmap adobe-mappings-cmap-deprecated adobe-mappings-cmap-devel Size: 2.25 MiB Size change: -11.15 KiB Changelog: * Thu Aug 03 2023 Richard Lescak - 20230622-1 - rebase to version 20230622 (#2216272) Package: anaconda-39.29-1.fc39 Old package: anaconda-39.28-1.fc39 Summary: Graphical system installer RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui anaconda-webui anaconda-widgets anaconda-widgets-devel Size: 22.72 MiB Size change: 1.63 MiB Changelog: * Thu Aug 03 2023 Packit - 39.29-1 - webu
Re: Dropping of sshd.socket unit
Once upon a time, Richard W.M. Jones said: > The DoS attack is described here: > > https://bugs.archlinux.org/task/62248 > > ... and it sounds like a bug in systemd. Surely this same attack > applies to any socket-activated service so should be fixed in systemd? > I don't recall inetd having the same problem. (x)inetd would shut a port under heavy net-connection load for a short period, but systemd seems to shut it permanently under those conditions. For systemd to replace inetd-type socket activation, it needs to have a timeout on the disable. This probably isn't a high priority though, because very few things support inetd-type modes anymore. -- Chris Adams ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
Once upon a time, Miro Hrončok said: > With the retirement of modularity, the modular dnf repositories for > Fedora 39 no longer exist. However, this will introduce a problem > during upgrades. When users try to upgrade from previous Fedora > releases with fedora-repos-modular installed, they will hit fatal > errors that will probably look like this: Could the repo config be removed by having fedora-repos Obsolete: fedora-repos-moduler <= 39? -- Chris Adams ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On 04. 08. 23 14:45, Chris Adams wrote: Once upon a time, Miro Hrončok said: With the retirement of modularity, the modular dnf repositories for Fedora 39 no longer exist. However, this will introduce a problem during upgrades. When users try to upgrade from previous Fedora releases with fedora-repos-modular installed, they will hit fatal errors that will probably look like this: Could the repo config be removed by having fedora-repos Obsolete: fedora-repos-moduler <= 39? That has already been done. But when the upgrade happens, the repo config is still there, to be removed in the transaction that fails. -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
On Friday, August 4, 2023 8:42:18 AM EDT Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > > The DoS attack is described here: > > > > https://bugs.archlinux.org/task/62248 > > > > ... and it sounds like a bug in systemd. Surely this same attack > > applies to any socket-activated service so should be fixed in systemd? > > I don't recall inetd having the same problem. > > (x)inetd would shut a port under heavy net-connection load for a short > period, but systemd seems to shut it permanently under those conditions. > For systemd to replace inetd-type socket activation, it needs to have a > timeout on the disable. Yes, as one of the authors of xinetd, I pointed this out long ago. But they said they were not trying to replace xinetd and if people want a more full featured experience, use xinetd. > This probably isn't a high priority though, because very few things > support inetd-type modes anymore. This would be a problem for MLS systems. The way the role/level/category is negotiated between systems is with VPN keys which maps to SE Linux policy. Once the key is negotiated, it connects via the socket API where the sshd instances is started with the right SE Linux labels. This is a small but important use case. I suppose the fallback would be to go back to using xinetd if this is not fixed in systemd. -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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
Once upon a time, Miro Hrončok said: > On 04. 08. 23 14:45, Chris Adams wrote: > >Could the repo config be removed by having fedora-repos Obsolete: > >fedora-repos-moduler <= 39? > > That has already been done. But when the upgrade happens, the repo > config is still there, to be removed in the transaction that fails. Ah, that makes sense, sorry. :) -- Chris Adams ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Dropping of sshd.socket unit
Once upon a time, Steve Grubb said: > Yes, as one of the authors of xinetd, I pointed this out long ago. But they > said they were not trying to replace xinetd and if people want a more full > featured experience, use xinetd. Except... wasn't there a big push to replace xinetd with systemd socket activation in Fedora? In fact, xinetd was orphaned and retired, so the only way to have that kind of functionality in Fedora is through systemd, so systemd needs to support the same functionality. -- Chris Adams ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
V Fri, Aug 04, 2023 at 12:16:14PM +0200, Miro Hrončok napsal(a): > With the retirement of modularity, the modular dnf repositories for Fedora > 39 no longer exist. However, this will introduce a problem during upgrades. > When users try to upgrade from previous Fedora releases with > fedora-repos-modular installed, they will hit fatal errors that will > probably look like this: > > Errors during downloading metadata for repository 'fedora-modular': > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > - Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare > internal mirrorlist: Status code: 404 for > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > > Or: > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were > tried > > (The actual error might differ depending on the exact state of the removal > of the modular repos and their mirrorlist etc.) > > > This is caused by the combination of the following facts: > > - the modular repo configuration in Fedora 37/38 has > skip_if_unavailable=False > - when the releasever is set to 39, the URLs of the repos give error 404 > This is a general problem of removing a repository from the distribution. Unrelated to Modularity. I propose this procedure: Keep Fedora <= 38 as it is. For Fedora 39 and 40 keep an empty repository on mirrors and uninstall the repository configuration by obsoleting fedora-repos-modular. Then in Fedora 41 remove the repository from mirrors. That way users of currently relased Fedoras <= 38 will have access to their modules, and users upgrading to Fedora 39 or 40 won't get the 404 HTTP error. After this upgrade to 39 or 40 the repository definition became nonexistant thanks to the obsolete. Fedora >= 41 can stop mirroring the repository because upgrade guidelines only support jump to N+1 and N+2 distribution release. -- Petr 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, report it: https://pagure.io/fedora-infrastructure/new_issue
bodhi and testing farm disagrees on test result
Hi, seems there is an issue with the test results presented in bodhi, please see https://bodhi.fedoraproject.org/updates/FEDORA-2023-94f22746e1 bodhi thinks fedora-ci.koji-build.rpmdeplint.functional failed (it's "red"), but when I click on the test in bodhi testing farm say "passed". What can be wrong? Dan ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Script for installing TeXLive packages required by a document?
Hi folks, fedtex is now built, and updates pushed: https://bodhi.fedoraproject.org/updates/?packages=fedtex -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, 4 Aug 2023 at 06:16, Miro Hrončok wrote: > Hello folks, > > With the retirement of modularity, the modular dnf repositories for Fedora > 39 > no longer exist. However, this will introduce a problem during upgrades. > When > users try to upgrade from previous Fedora releases with > fedora-repos-modular > installed, they will hit fatal errors that will probably look like this: > > Errors during downloading metadata for repository 'fedora-modular': >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) >- Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > Error: Failed to download metadata for repo 'fedora-modular': Cannot > prepare > internal mirrorlist: Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > (IP: ...) > > Or: > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were > tried > > (The actual error might differ depending on the exact state of the removal > of > the modular repos and their mirrorlist etc.) > > > This is caused by the combination of the following facts: > > - the modular repo configuration in Fedora 37/38 has > skip_if_unavailable=False > - when the releasever is set to 39, the URLs of the repos give error 404 > > This is a big deal, because even users who don't use modularity at all > (but > have not uninstalled fedora-repos-modular) will not be able to upgrade to > Fedora 39+ without reaching for help. > > Adam outlined 3 options to solve this problem in the bugzilla where he > reported > this: https://bugzilla.redhat.com/2228827 > > I slept on it and have found a fourth option (but I don't think it's very > viable). I'll present all 4 options here: > > I think we are going to need to do multiple of these solutions because there are too many ways people upgrade their systems (usually because someone told them there method would work years ago or they just found a doc which was written years ago, etc). As Petr Pisar points out elsewhere this is not a new problem. We regularly see someone on IRC for years asking why an upgrade didn't work and it comes down to something like skip_if_unavailable=true or some similar issue where a repository is not properly set up (say a copr or third party repo) for the current release. 1. We need to document that this failure could and can occur. We need to point out that we are only testing N methods for upgrades and anything else will need manual work arounds. The way to maybe find those will be to ask on . 2. We need to work out 1-2 methods we 'support' for upgrading which of the ones below I would say D and A where certain tooling will check to see if the upgrade is possible and then alert if it isn't and try a method of turning things off if ok. [If that is even possible with code paths not yet written.] 3. 4. Profit. I don't like B because it could be the most fragile as it will need work in pungi to make sure that the repositories are ALWAYS properly created in a way that doesn't cause problems. [They can't just be 'empty'. They need to be empty with repodata that allows for updates to always work. If this requires hacking pungi then any upgrade of the source code on the releng boxes could cause breakage weeks later or releases later.] It is also hard to ever turn this off. As much as we like to have people upgrade from 36->37 or 36->38, there is a large enough 'hump' of people who do a 36->40 turn that means we would be doing this til maybe 44. Of course if it is just a simple pungi config which doesn't make other things break, B may be the easiest.. > > A. Set skip_if_unavailable=True in the modular repo configuration on old > Fedora > > > > B. Mirror empty modular repositories for the time being > > > > C. Document this in the upgrade documentation > > > > D. Change our upgrade tools to disable modular repos on upgrades to F39+ > > > > > What do you think we should do? My preference would be to go with option > (B) > and fallback to option (A) if (B) isn't finished in reasonable time. > > > -- > 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, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- Stephen Smoogen, Re
Re: Orphaned python-testing.postgresql
I realized I have a package pending review[1] that uses python-testing.postgresql for its tests, so I have picked it back up (along with python-testing.common.database), and I will fix the FTI/FTBFS in F39/Rawhide. It’s unfortunate that upstream seems to have moved on from these packages, but I do want to run the tests that require them, and they are simple enough that I expect I can keep them working for as long as necessary without much effort. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2189323 On 7/18/23 11:02, Ben Beasley wrote: In response, I have also orphaned python-testing.common.database: - since python-testing.postgresql was the only package that depended on it (python-testing.mysqld was never packaged) - since nothing depends on python-testing.postgresql anymore, and - since upstream for these packages has been inactive for 4-5 years I think it’s probably best to let these packages go, but anyone considering picking them up should know that both packages have spec files that use modern practices and are in a good “state of repair.” - Ben Beasley (FAS: music) On 7/18/23 2:47 AM, Miroslav Suchý wrote: I orphaned https://src.fedoraproject.org/rpms/python-testing.postgresql I do not use it any more. Feel free to grab it. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Python packaging with pip
Hi, it's been a while since I did active Python packaging. However, one of my packages, python-qcelemental, https://github.com/MolSSI/QCElemental, has switched over from setup.py to $ python -m pip install qcelemental I did not see anything in the Python packaging guidelines on how to handle such cases in the spec file. Does anybody have an example I could follow? Susi -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Python packaging with pip
On Fri, 4 Aug 2023, Susi Lehtola wrote: Hi, it's been a while since I did active Python packaging. However, one of my packages, python-qcelemental, https://github.com/MolSSI/QCElemental, has switched over from setup.py to $ python -m pip install qcelemental I did not see anything in the Python packaging guidelines on how to handle such cases in the spec file. Does anybody have an example I could follow? You can't build Fedora packages using pip (no network access allowed), but it looks like they switched to a pyproject.toml, so following the standard modern guidelines should work, ie: %generate_buildrequires %pyproject_buildrequires %build %pyproject_wheel %install %pyproject_install Scott ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
On Fri, 2023-08-04 at 11:13 -0400, Stephen Smoogen wrote: > 2. We need to work out 1-2 methods we 'support' for upgrading which of the > ones below I would say D and A where certain tooling will check to see if > the upgrade is possible and then alert if it isn't and try a method of > turning things off if ok. Well, this is, effectively, exactly already the case. We already have specific supported methods of upgrading: https://docs.fedoraproject.org/en-US/quick-docs/upgrading/ (basically, graphical upgrade for Workstation; dnf system-upgrade for everything else; both using the default stock repository configuration). The tooling that checks to see if the upgrade is possible and alert if it isn't is...well...the upgrade process. It does that. The issue as described affected the "supported" methods of upgrading, except that (as described in the correction) it doesn't actually cause immediate issues in real-world cases because of the 'stale' tree that remains on the official repo location. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bodhi and testing farm disagrees on test result
On Fri, 2023-08-04 at 15:40 +0200, Dan Horák wrote: > Hi, > > seems there is an issue with the test results presented in bodhi, please > see https://bodhi.fedoraproject.org/updates/FEDORA-2023-94f22746e1 > > bodhi thinks fedora-ci.koji-build.rpmdeplint.functional failed (it's > "red"), but when I click on the test in bodhi testing farm say "passed". > > What can be wrong? Well, Bodhi just gets the result from resultsdb. And the result there is definitely "failed": https://resultsdb.fedoraproject.org/results/41380875 Fedora CI files that result via ci-resultsdb-listener: https://pagure.io/ci-resultsdb-listener I think the message that triggered that result was this one: https://apps.fedoraproject.org/datagrepper/v2/id?id=0bb07f00-a232-48e9-a64f-4e9c7d603cf9&is_raw=true&size=extra-large which is actually an 'error' message, not a 'failed' message. resultsdb does - as of fairly recently - have an ERROR outcome, at least in the Fedora deployment, but it did not have one for a long time; ci- resultsdb-listener specifically uses the FAILED outcome for .error results, which we could perhaps improve now ERROR is available. The message doesn't tell us exactly what the error was, just "Infrastructure Failure". But this is basically what happened - some kind of system error occurred during/after the test run which somehow caused CI to publish a message indicating the test errored out, even though (as you saw) the logs indicate it passed. From there the details of how we report CI results to resultsdb turned it into a "failed" result. CCing the ci@ list - someone from there should be able to look more closely into what went on here and if anything can be improved (beyond making ci-resultsdb-listener use the ERROR outcome, now we have it). Practically speaking, we should be able to just re-run the tests and it should come out good. I'll bonk that button now. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: bodhi and testing farm disagrees on test result
On Fri, 2023-08-04 at 23:43 +0100, Adam Williamson wrote: > > Practically speaking, we should be able to just re-run the tests and it > should come out good. I'll bonk that button now. Ah, as the failure wasn't a gating one, Bodhi doesn't show the Re- Trigger Tests button. So I can't do it. Someone with privs in the Fedora CI system might be able to rerun the test to get the results to line up, if it's important. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Python packaging with pip
On 8/4/23 22:08, Scott Talbert wrote: > On Fri, 4 Aug 2023, Susi Lehtola wrote: >> Hi, >> >> it's been a while since I did active Python packaging. However, one of my >> packages, python-qcelemental, https://github.com/MolSSI/QCElemental, has >> switched over from setup.py to >> >> $ python -m pip install qcelemental >> >> I did not see anything in the Python packaging guidelines on how to handle >> such >> cases in the spec file. Does anybody have an example I could follow? > > You can't build Fedora packages using pip (no network access allowed), but > it looks like they switched to a pyproject.toml, so following the standard > modern guidelines should work, ie: > > %generate_buildrequires > %pyproject_buildrequires > > %build > %pyproject_wheel > > %install > %pyproject_install Dear Scott, thanks; this did the trick! Susi -- Susi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
