Self Introduction: Maxwell G (@gotmax23)
Hi everyone, I am Maxwell G or @gotmax23 on FAS and Github. I am relatively new to Linux but after trying different distros, I settled on Fedora. I don't have a lot of time between school and having chronic pain, but I'd like to give back and contribute as much as I can. I created a package for yt-dlp, a fork of youtube-dl with extra fixes and features, and submitted a [review request][1] on Bugzilla. I still need a sponsor and someone to review my submission. I am a big Ansible user and would be happy help with Fedora's Ansible packages. I already maintain `ansible-collection-community-general`on the AUR, so it would be non-trivial for me to maintain it in Fedora. I have identified some other areas I could help with, but I don't want to bite off more than I can chew. Either way, I will [continue][2] submitting PRs to fix issues or update versions for the packages that I use. As I said, I have [contributed][2] to a couple Fedora packages on src.fedoraproject.org prior to submitting this application; I have some feedback on improving the contribution process for those who aren't part of the packager group. When I have a chance to type it up, where should I send it? Thanks, Maxwell đ [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2012522 [2]: https://src.fedoraproject.org/user/gotmax23/requests?type=filed&status=all (my Pagure PRs) [3]: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#one_off_contributions -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email -BEGIN PGP PUBLIC KEY BLOCK- mQINBF/Vl1IBEADCKuxteexi7gWDmxLkCQT5Q34TUX4uFpCccPgxjsYbUm+JxTQH vpxbbnWyEcqdJ3Tg9HQT/L4zXhPNsCSW0SHVkodfajmajGy1xCy2i0lyYfOsS1pf dvjjl6UqXjH7HJYviilqVyDddgONiULRuMzRiUZaUWTkJcRTb+TWdKnNzRujvoRk wdtGiQMoF8tsr/1A3uqK4Af9ezkKE9aAQLW6NUbBI2TsRejrNnJb8naF6W8htGuo jxrJ+olsidLKgvp7BgPv2o+4Sn+emEkOR3ZqvznfZy1w5MISO+A9ompsnAC9KNsR Np4taxZei1/s+4FggkRe6NrYEyhI7lKQd+JWkLVEt0MduWA5vlqCqE6E5ELcS66S 9xVedzpznGsR5Fp44D0AhXRWbeOWo2ILCsBs3isA/SnwbhlOxVIJcZRLunJFlsgA 0a7+PAkKU2pU7H7J9JwOHMrX9reOwTWNN1b8fTIxPN8DOpXcuVd2U6rl8XpMGRQ5 QMTTZJaHVc5E1C+gdNa7kXQUiVFdWAzGIUB5Yf3Kq4l0lpm5ab19xWxxGKg6TZWk STD2GUvmVuOvB1YdX8J59Uswec7EZIzM1xutuZvxWWcP8DGvPQ8za05zV5oOij5W EwdSYyXJYY+kXDwN7duQAlJMe/yLC16utUHNzSnCaRPpD2JEFvcwXwIkDwARAQAB tCpNYXh3ZWxsIEcgKENvbW11bmljYXRpb24pIDxnb3RtYXhAZS5lbWFpbD6JAk4E EwEIADgWIQT1fHblojj+CmKOLs73nk4l6MZh+AUCX9WXUgIbAwULCQgHAgYVCgkI CwIEFgIDAQIeAQIXgAAKCRD3nk4l6MZh+EG7EACVBn7CPKj4WYCqxzfXJQ1Hi3Fw 5zFpjdq+K1yPaHr/1leusgiMn+va8jIDj98SMv9WCHvlVL7Jge/759m+udjAUhTm Xurly+u0+pu04CI8vxZcwYAxKGPdfcE9qDYQMl+3dYP+uRJzZWTd1oPZH9Dj7aXx 9nXWRuOj00d5u2+/O+w+tx21U2QMi5Sa2Li5lkeLDkoHwnUV5SuQkeCOD0sbxb04 UVxYWKQlAV5aoTObxUFl0aHdsYoE9bDVL+CR3aXbAgdXwMGbYgJk/3TW9dwbbooj GlBXqRhpk4QGi5Gk6n2FX1dHtuDQckPyBqIpRessNttJhuTybEGeU6URhjUdaPBw /iqEn2I4D5OlHo9EMS9vmm7zNFMgNnKyuC7l1h1q5IfKoGNoSnqAS0cWLMTKb1dI L0J8e3V1MNj8i+qv1azKYIm9q0Yp0gXuwkKtF+5G+T5xPe6zOh++8kNbxTPhZc3z 9OX0SE1dk67tPP15BdNXfXgYzvRHCfNdwvq0YxFKeWGRs1gNT+OihKJwwWzdoAda LF7azyj+QmrER6PC8g5K2+ksbI/9IOr3txgWdxJkdvp7C/MaYgbpsF8Uee6sBlQ7 TjNjpdJBbfcyMZIZHJKm8vr/7CadHdY5FB+Im975VV7VX4sHcgnYBMtE1fVayVUb eMU1tr0HVqICw0Uh4LkCDQRf1ZdSARAA0bGr6WcB86DQihPn0REiU+STdLWjoY8g 6hKLIFB9GGiL+gbIxOqnqscBoPYUDJJyPCPklAiFkI5rU+Rj+hlGm//S4SBcv/8v 1holuVa0mVjLKGbIsmxlbenCPFUIh0v+//mwzbUOYtTvA93jUPxHHUcM/23qATgi am+oUurvtD5GiwJCh/BxnEVO4e/b05wgh3GY6jpFMIXIKLUrN3VWrPPkaciL0fzz V+TbDoR3kOKV7H1QbPyAIVS8KZiG7Uhdq/uI8f6eHPUsUUxCU52EmG9Hwj3E27g9 Zt+mFXMaSOvktheEgvYMEQG6Av/+9I7Z1ogglGHmKTEXUXv0LMphfnx56+Aciwqe P3+nscBLNeXkf8mw7Ua8ELdaFwEo1YS3akdrdrqhVornWXPZXvAuacYY1awIdTRu MOsetLpQiYMCti45k0RBto1OYsaYu984nWmZrI4/IuwoaAKLSaKEfQRMB2Lsfa0g EADJ7pxvs856938cb51IdlH8VfWBxGzqGPMTDIH+I/u6RPrt3oH6V1vBj1+mWjMU 9/JDbw09RZ1S8GCiYdyI/C/F8WUhyHIcd9mUZkjcsvBtOvFyiC4pX6x6Adbu6+oH Rlm17M+jP9cCWok/A1eKhJgsCHtqTXoNE0Qj2l20kGQTw3H8uJ/J69/yljyFE8E4 PQOwc2i8WZsAEQEAAYkCNgQYAQgAIBYhBPV8duWiOP4KYo4uzveeTiXoxmH4BQJf 1ZdSAhsMAAoJEPeeTiXoxmH4NrAQAJVaDz8c/w6j4ZkQnyBF7XnMqUVtrZUkCuzO fNnYEa8Boh2ecNEZGbG+FW8JdCkOAWtval0I6wKOOy8P4JG7yZet4JGO2vBWaqry p8hq/6p2CkSNng13PqBabTyyZihYGio0zqrbJx6HKMTfRprg+LEsPHoY5eLnDaUl hzcnywBla8UJM61gVD3bQXj8OPJJskjLpdST2zic6KgOiHliOQ5dGFQ5H2wnFRg9 zPQnfqTrP0kQ4tHsH49fDEdgay6BdPBax3RGEeNWyjoflOzllKwb+JXHB39ZiSaC OU1+55WDqoPLbqEErNO8028ZFF0YKlkoPEnUAPgeSjKudcbVbMTpdxcdY9ZvQThI OpjcTkNO6CltLLjqv+hBgpMYow2mLegT7h2auSXCLNSSfGRA9uxn72zzvX0/Vjo+ RREFAXSmwAQNK5BN8SglxPngRxvUDARjrG/3wlt11/WV0HwzZ54eky4jn6/kDInq t8vSs8UBZ+LGNcEhA3t8X2eAMZvcA21cNPhkmZrRYD3hcYv4zxn+FBRqtW+PHd1x l4ad4Tpyq3qb5kRKywNKvKfweOCwaImOe9duXe5EfE+TDWgGDUBmBUFKoo4s8/N3 zm9oEtohHenpDwEJ9zEKSnuktWi7vrmmHolYKdRSWSBx5euqP6kpfdh9daLwpOio DyGUjUlJ =vsVr -END PGP PUBLIC KEY BLOCK- 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
Re: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi, On Sat, 2021-10-16 at 15:33 -0700, Kevin Fenzi wrote: > On Sat, Oct 16, 2021 at 10:02:38AM -0400, Nico Kadel-Garcia wrote: > > > > it could have made good sense, and still would, for the "ansible" > > package to be what is now being colloquially referred to as > > "ansible-core", but for which the published upstream git repo is > > still > > https://github.com/ansible/ansible, and which is and will remain > > accessible as a github release tarball with the old numbering. The > > pypi.org published "ansible-core" is a republication of that repo > > with > > a new name duck-taped on it. Fragmenting out the bulky and > > potentially > > dynamic set of tools that are now in the "galaxy collections" suite > > makes some sense, but the result is that to get any of the core > > modules like "ansible.posix"Â we wind up including 573 Megabytes of > > unneeded and unwelcome debris in > > /usr/lib/python3.6/site-packages/ansible_collections. Very few of us > > need more than 10% of the list > > If you don't need more, don't install 'ansible'. Just install > ansible-core and use galaxy or seperate packaged collections to install > just what you need. > > > There is no specific source repository for the "ansible_collections" > > tarball, as best I can tell. The list of modules selected from the > > galaxy collection is very large, but incomplete and I've not seen any > > criteria for what goes in that tarball and what does not. Have you > > seen any? > > Yes, but I can't seem to find it now. ;( > Basically it was agreeing to use symantic versioning and agreeing to > release on the same schedule as the rest, etc. I don't know if there's > further requirements now. I'll find that doc and post it, but kinda > weekending now. ;) > > ...snip... > > kevin Here[1] is a link to the rules that collections must follow in order to be included in the `ansible` bundle. Here[2] is a link to the build data repository for the `ansible` package. This includes which versions of the collections exist in each version of the `ansible` package, as well as which versions of `ansible-core` each `ansible` package depends on. The Ansible team uses antsibull[3] to compile these releases. Thanks, Maxwell [1]: https://github.com/ansible-collections/ansible-inclusion [2]: https://github.com/ansible-community/ansible-build-data [3]: https://github.com/ansible-community/antsibull -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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: F37 Change: Ansible 5 (Self-Contained Change proposal)
Hi Nico, I understand your frustration about the Ansible reorganization, and I agree that they could have documented it better, but I think that you are missing the context surrounding this decision. Oct 16, 2021 4:46:43 PM Nico Kadel-Garcia : > On Sat, Oct 16, 2021 at 3:03 PM Gordon Messmer > wrote: > > > > On 10/15/21 16:29, Nico Kadel-Garcia wrote: > > > > > > I would publish ansible-core as just that, with a "Provides: > > > ansible > > > %{version{-%{release}" and even "Obsoletes: ansible >= > > > %{version}". > > ... > > > The "ansible" package could be a > > > meta package with "Requires: ansible-core ansible_collections" to > > > avoid the versioning confusion. > > > > > > Those two things can't both be done, though, can they? If the > > "ansible-core" package provides and obsoletes "ansible", then users > > wouldn't be able to install the "ansible" package that requires > > ansible_collections. > > They *can* physically, but doing both together would get very silly. > I'd meant "do one or the other". The current model of "install > ansible, get a few Megabytes of material you actually use that is > almost entirely in ansible-core and 576 Megabytes of bulky material, > more than 90% of which you will never use" is awkward, and I'd much > rather see the galaxy collection packages published, and remain, > distinct. > Fedora is not deprecating the current ansible-collection-* packages. If you don't like the PyPi `ansible` package, then install the `ansible- core` package and install the collections you want using the ansible- collection-* Fedora packages or with `ansible-galaxy collection install`, as the change description explains and Kevin reiterated. > Discard the "ansible" package as an unwelcome approach, it's > too big and too confusing. I recommend you reread the initial post; it provides a good explanation for why Ansible split most of the modules away from the core engine and how the new packages (ansible-core and ansible) compare to the old package (ansible 2.9). The new `ansible` package just contains the collections that themselves contain the modules that, prior to Ansible 2.9, were hosted at github.com/ansible/ansible. The reason Ansible created this new package was to avoid breaking existing workflows that relied on those modules. Now, users can choose between installing the collections manually or installing the `ansible` bundle. > > > It does make me wish I'd been on the IRC channels that came up with > this bundling to walk through the concerns much earlier. In practical > terms and the relationship between Red Hat sponsored software like > Ansible, and Fedora development, I acknowledge that it may be too > late to revise. But that "too late" is a political and social issue, > not necessarily a technical one. I don't think this decision has anything to do with Fedora and RedHat's relationship. All Fedora is really doing with this change is updating the `ansible` package to the latest version available on PyPI. If you were already using the `ansible-core` package, you can continue using that. Fedora is not making any significant changes to that package with this change. > > As a practical matter, I don't see any functional difference > > between the > > proposed change (publishing an ansible-core package, and an ansible > > package that contains collections) and your suggested alternative > > (publishing an ansible-core package, and an ansible package that > > requires collections), unless we disregard the meta package. > > It distinguishes the newly bundled ansible-core, which OK, that made > sense to fragment, from an extremely bulky and therefore brittle > bundle that is mostly unwelcome, even dangerous. I don't think the `ansible` bundle is dangerous or unwelcome. The new bundle is very helpful for people who don't want to deal with separate dependencies and want to continue using Ansible as it used to be -- where all of the modules are included in one monolithic package. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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: F37 Change: Ansible 5 (Self-Contained Change proposal)
On Fri, 2021-10-15 at 16:31 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Ansible5 > > == Summary == > > The ansible project has re-organized how they release and distribute > ansible. This change moves Fedora to be in sync with those changes > and > retires the old 'ansible classic/2.9.x' package in favor of a > 'ansible' package that pulls in ansible-core (the engine) and > includes > all the collections in upstream ansible releases. Hi everyone, I have a couple comments/questions about this change. How will this effect EPEL? Is the plan to keep Ansible 2.9 there for now? Could we also consider making Ansible a modular package on both Fedora and EPEL? Then, it would be possible to install any of the currently supported versions of the Ansible core/engine (ansible 2.9, ansible- base 2.10, and ansible-core 2.11). Will the new `ansible` package have virtual provides for the collections it provides? While there is not a good reason to, it will still be possible to install both the new `ansible` package and any of the ansible-collection-* packages, right? Also, I would be happy to help with Ansible packaging in Fedora; however, I am not yet part of the packager group and still need a sponsor. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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: During the first update after installation: Failed to connect to bus: Invalid argument
On Tue, 2021-11-09 at 18:30 -0500, Sam Varshavchik wrote: > The bug was opened for a different problem. Once it was fixed, this > spam > started showing up. This bug was reopened. > > Who knows what spam will show up after this bug gets fixed⊠> Hi Sam, The bug was just not fixed properly in the first place. It looks like @zbyszek pushed a fix to s.fp.o[1], but they have not yet pushed the update to Bodhi. Thanks, Maxwell [1]: https://src.fedoraproject.org/rpms/systemd/c/5326f0bf63e944024d6aafa1debf857ac3656078?branch=f35 -- Maxwell G Pronouns: He/Him/His gotmax@e.email ___ 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: During the first update after installation: Failed to connect to bus: Invalid argument
Hi everyone, On Tue, 2021-11-09 at 17:55 -0600, Maxwell G via devel wrote: > On Tue, 2021-11-09 at 18:30 -0500, Sam Varshavchik wrote: > > The bug was opened for a different problem. Once it was fixed, this > > spam > > started showing up. This bug was reopened. > > > > Who knows what spam will show up after this bug gets fixed⊠> > > Hi Sam, > > The bug was just not fixed properly in the first place. It looks like > @zbyszek pushed a fix to s.fp.o[1], but they have not yet pushed the > update to Bodhi. > > Thanks, > Maxwell > > [1]: > https://src.fedoraproject.org/rpms/systemd/c/5326f0bf63e944024d6aafa1debf857ac3656078?branch=f35 It is possible that I'm missing something (I'm not super knowledgeable in this area). Please let me know if that's the case. I tried rebuilding the systemd packages with that patch using mock. I am now getting a different error message. ``` console Running scriptlet: syncthing-1.18.4-1.fc35.x86_64 2/2 Failed to start transient service unit: Connection reset by peer Failed to set unit properties on syncthing.service: Transport endpoint is not connected Failed to start transient service unit: Connection reset by peer Failed to reload daemon: Transport endpoint is not connected Failed to start transient service unit: Connection reset by peer Failed to start jobs: Transport endpoint is not connected Failed to start transient service unit: Connection reset by peer Failed to reload daemon: Transport endpoint is not connected Failed to start transient service unit: Connection reset by peer Failed to start jobs: Transport endpoint is not connected ``` Thanks, Maxwell -- Maxwell G Pronouns: He/Him/His gotmax@e.email ___ 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: Bugzilla Email Notifications
Hi Yaakov, Nov 9, 2021 10:22:12 PM Yaakov Selkowitz : > On Wed, 2021-11-10 at 03:56 +, Maxwell G (@gotmax23) via devel wrote: > > Does anyone know if it's possible to set bugzilla.redhat.com to email me a > > copy of new bugs or comments that I create? > > Try: https://bugzilla.redhat.com/userprefs.cgi?tab=email > > Then in the "The change was made by me" row, unclick the relevant boxes (e.g. > Reporter and CCed). Thank you for pointing me in the right direction. Also, it it seems like Bugzilla email notifications have been delayed by multiple hours all day. For example, if you left a comment on a bug that I am subscribed to, the email notification would not arrive until hours later. Bugzilla's page loading has been slower than it already is. Has anyone else encountered this? Please let me know if I should report this issue somewhere else. Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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: Action required: Account system IRC pointer reset
> > I wonder, which mailing list was your original / first message (the > > announcement, I think?) in this thread sent to? Is there a mailing > > list archive link for it? > > Because I seem to be missing the actual announcement mail with all > > the > > details from my mail inbox, only subsequent responses are here. > > It went to annou...@lists.fedoraproject.org, but I guess I should > have > also sent it to devel-announce? mattdm has suggested that we need > something like a 'contributor-announce' for things like this. > > https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/thread/DK2DYBB3JZW4J3KUYREEEC42Z4D3IPP2/ > > kevin Thanks for clearing that up! I had the same thought. -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email 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: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
Hi everyone, On Thu, 2021-09-16 at 15:17 -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect > > > == Summary == > exclude_from_weak_autodetect enables autodetection of unmet weak > dependencies (Recommends or Supplements) of installed packages and > blocks installation of packages satisfying already unmet dependencies. > In other words: When you don't have the recommended package installed, > it won't be automatically installed with future upgrades of the > recommending package. I am not sure if this was intended, but this change has broken rich weak dependencies when both packages are not installed as part of the same transaction. In my yt-dlp package's specfile[1], I have three subpackages for shell completions: `yt-dlp-bash-completion`, `yt-dlp-zsh-completion`, and `yt-dlp-fish-completion. Here is the `bash-completion` block: ``` spec %package bash-completion Summary:Bash completion for %{name} Requires: %{name} = %{version} Requires: bash-completion Supplements:(%{name} and bash-completion) BuildArch: noarch ``` The intended effect is for the shell completions to be installed at the time `yt-dlp` itself is installed if the respective shell package (`bash-completion`, `zsh` or `fish`) is already present while still allowing users to opt out. However, now this does not work; dnf will only install the completions if both `yt-dlp` and the shell package are installed as part of the same transaction. I can confirm that this is caused by this change, because adding `-- setopt=exclude_from_weak_autodetect=false` fixes the problem. Replacing `Supplements` with forward facing boolean `Requires` did not work either. ``` spec Recommends: (%{name}-bash-completion if bash-completion) Recommends: (%{name}-zsh-completion if zsh) Recommends: (%{name}-fish-completion if fish) ``` While I agree that {rich,} weak dependencies should not be reinstalled as part of updates, I do believe that they should be installed if one of the packages is being installed for the first time. I also think we should consider implementing better guidelines for shell completions in Fedora. I believe that shell completions should be split into subpackages and that these subpackages should depend on the shells themselves or a `-filesystem` package that actually own the directories. Right now, directory ownership is kind of a mess. At least on my system, there are several packages that own /usr/share/bash- completion, /usr/share/zsh/vendor-completions, /usr/share/zsh/site- functions, and /usr/share/fish/vendor_completions.d/. We can also use this oppurtunity to create macros for each of these directories. Management of shell completion packages was discussed further in my package review ticket [2]. I am relatively new to Fedora, so please correct me if I got anything wrong. Thanks, Maxwell [1]: https://src.fedoraproject.org/rpms/yt-dlp/blob/rawhide/f/yt-dlp.spec [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2012522 -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
Hi everyone, I am resending this message, because I think it got lost. I sent it at the begining of a weekend, so people must not have seen it. I am CC'ing the change owner, as I feel that more clarification is required. I maintain that this change should only apply to updates; `dnf install`, `dnf reinstall` should behave as they have been. At least, this change and all of its effects should be fully explained to packagers. We should probably discuss the shell completion stuff seperately. Thanks, Maxwell On Fri, 2021-11-12 at 15:48 -0600, Maxwell G wrote: > Hi everyone, > > On Thu, 2021-09-16 at 15:17 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect > > > > > > == Summary == > > exclude_from_weak_autodetect enables autodetection of unmet weak > > dependencies (Recommends or Supplements) of installed packages and > > blocks installation of packages satisfying already unmet > > dependencies. > > In other words: When you don't have the recommended package > > installed, > > it won't be automatically installed with future upgrades of the > > recommending package. > > I am not sure if this was intended, but this change has broken rich > weak dependencies when both packages are not installed as part of the > same transaction. > > In my yt-dlp package's specfile[1], I have three subpackages for > shell > completions: `yt-dlp-bash-completion`, `yt-dlp-zsh-completion`, and > `yt-dlp-fish-completion. Here is the `bash-completion` block: > > ``` spec > %package bash-completion > Summary:   Bash completion for %{name} > Requires:  %{name} = %{version} > Requires:  bash-completion > Supplements:   (%{name} and bash-completion) > BuildArch: noarch > ``` > > The intended effect is for the shell completions to be installed at > the > time `yt-dlp` itself is installed if the respective shell package > (`bash-completion`, `zsh` or `fish`) is already present while still > allowing users to opt out. However, now this does not work; dnf will > only install the completions if both `yt-dlp` and the shell package > are > installed as part of the same transaction. I can confirm that this is > caused by this change, because adding `-- > setopt=exclude_from_weak_autodetect=false` fixes the problem. > Replacing > `Supplements` with forward facing boolean `Requires` did not work > either. > > ``` spec > Recommends: (%{name}-bash-completion if bash-completion) > Recommends: (%{name}-zsh-completion if zsh) > Recommends: (%{name}-fish-completion if fish) > ``` > > While I agree that {rich,} weak dependencies should not be > reinstalled > as part of updates, I do believe that they should be installed if one > of the packages is being installed for the first time. > > I also think we should consider implementing better guidelines for > shell completions in Fedora. I believe that shell completions should > be > split into subpackages and that these subpackages should depend on > the > shells themselves or a `-filesystem` package that actually own the > directories. Right now, directory ownership is kind of a mess. At > least > on my system, there are several packages that own /usr/share/bash- > completion, /usr/share/zsh/vendor-completions, /usr/share/zsh/site- > functions, and /usr/share/fish/vendor_completions.d/. We can also use > this oppurtunity to create macros for each of these directories. > > Management of shell completion packages was discussed further in my > package review ticket [2]. > > I am relatively new to Fedora, so please correct me if I got anything > wrong. > > Thanks, > Maxwell > > [1]: > https://src.fedoraproject.org/rpms/yt-dlp/blob/rawhide/f/yt-dlp.spec > [2]: https://bugzilla.redhat.com/show_bug.cgi?id=2012522 > -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: Unowned system directories
Hi, On Tuesday, November 23, 2021 1:37:36 PM CST Steve Grubb wrote: > Hello, > > I am preparing to migate a F35 system to new hardware and was sanity checking > the whole system. One thing I found was that there are a number of system > directories that that are not owned by the package that uses them: > > /var/cache/ibus > /var/cache/PackageKit > /var/cache/cups > /var/log/anaconda > /var/lib/tpm2-tss > /var/lib/machines > /var/lib/hsqldb > /var/lib/cs > /var/lib/rpcbind > /var/lib/portables > /etc/module-build-service > /etc/default > /etc/pesign > /etc/ipa > /etc/ndctl > /etc/flatpak Yes, I have also noticed issues with directory ownership. However, I am not sure what the rules are about packages owning directories under `/var/cache` or `/var` in general. I can tell you that the `filesystem` package owns `/var/cache` itself: ``` $ rpm -qf /var/cache filesystem-3.14-7.fc35.x86_64 ``` There are also some directories that are owned by multiple packages, e.g. shell completions packages[1,2], instead of none at all. > Should there be a gating or other test that catches this? I think there should be. For your reference, here[3,4] are the sections of the Fedora Packaging Guidelines surrounding directory ownership. Thanks, Maxwell [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZSXQBRTQ6YJGE4LIBZ32BFABE6BLIOW7/ [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ERPOO3YGBHUJAMNXCEIUXGGH6LWEA7LN/ [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership [4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/ 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: Calling on all Thinkpad T490 users...
On Tuesday, November 23, 2021 1:19:34 PM CST Chris Murphy wrote: > Hi, > > Question: > Do you have a T490 laptop successfully booting Fedora 34 or 35? And > did it get Fedora by upgrade or clean install? > > Background: > We've got a weird bug related to new shim 15.4 since Fedora 34 > resulting in unbootable systems. The work around it to copy over the > old shim to the EFI System partition and carry on. > https://bugzilla.redhat.com/show_bug.cgi?id=1955416 > > The working assumption is that this is some sort of shim and/or > firmware bug that affects all T490's (and maybe some other models, not > sure). But now I'm wondering if that assumption isn't true and there's > actually something unique about some T490's? Of course only people > who have the problem are reporting in the bug and Reddit, etc. so it's > a self-selecting group. > > > -- > Chris Murphy > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > I have a Thinkpad X1 Extreme Gen 2. I haven't had any boot problems. I do have a bug where my desktop freezes or behaves strangely after resuming from sleep, but that is unrelated. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: GitHub source URLs not working
On Friday, November 26, 2021 6:15:33 PM EST SĂ©rgio Basto wrote: > On Fri, 2021-11-26 at 14:37 -0500, Susi Lehtola wrote: > > Hi, > > > > > > I am experiencing problems updating packages employing GitHub source > > URLs. For instance, > > > > $ spectool -g python-pyscf.spec > > Downloading: > > https://github.com/pyscf/pyscf/archive/v2.0.1/pyscf-2.0.1.tar.gz > > Download failed: > > 404 Client Error: Not Found for url: > > https://codeload.github.com/pyscf/pyscf/tar.gz/v2.0.1/pyscf-2.0.1 > > - 0.0 B Elapsed Time: 0:00:00 > > > > > > > > The URLs used to work. Has anyone else noticed the same problem? > > already reported here (4 hours ago) : > https://github.com/github/feedback/discussions/8149 Hi everyone, This issue has been fixed. For anyone who wasn't following the Github thread that SĂ©rgio linked, here is the response from a Github staff member: > Hi everyone. đđ» > > A change in the handling of URL schemes was deployed a couple of days ago > that caused the regression being discussed here. Due to the amount of traffic > that the archive endpoints see, and the high baseline of 404s on them, this > regression did not cause an unusual increase of errors that would've caused > our alerting to kick in. The change has just been rolled back, so the issue > is fixed. We will investigate this issue further after the weekend and take > the appropriate steps to make sure similar regressions don't happen in the > future. > > Thank you for reaching out, your patience and understanding. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: Fedora 33 End Of Life
On Monday, November 29, 2021 5:12:22 PM CST Neal Gompa wrote: > On Mon, Nov 29, 2021 at 5:52 PM Justin Forbes wrote: > > > > On Mon, Nov 29, 2021 at 4:16 PM Mohan Boddu wrote: > > > > > > Hello all, > > > > > > Fedora 33 will go end of life for updates and support on 30th of > > > November 2021. No further updates, including security updates, will be > > > available for Fedora 33 after the said date. All the updates of Fedora > > > 33 being pushed to stable will be stopped as well. > > > > > > > Whether it was intentional or not, it pretty much did last week as > > dist-git was not allowing commits to the F33 branch. > > > > Nope, I was able to push to the f33 branch this morning. I never had > an issue here. I believe that this was indeed an issue for some amount of time until the infra team fixed it. -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora
On Monday, December 6, 2021 6:43:57 PM CST Nico Kadel-Garcia wrote: > On Mon, Dec 6, 2021 at 3:59 AM Vitaly Zaitsev via devel > wrote: > > > > On 05/12/2021 04:07, Nico Kadel-Garcia wrote: > > > This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and > > > '%license' macros strip off the subdirectories of the files and > > > install them directly at the top of the docdir. > > > > You should deal with them manually. > > > > Example: > > https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L124-L161 > > https://github.com/rpmfusion/tg_owt/blob/master/tg_owt.spec#L178-L179 > > Simply put, "no". Manually organizing component names for more than > 300 README files and more than 100 LICENSE files does not seem a wise > use of anyone's package compilation time. > > If it's necessary, I could see doing something like this instead, or > using a local macro > > cp -D ansible_collections/foo/bar/baz/README.md > %{buildroot}%{defaultdocdir}/%{package}-%{version}/foo/bbar/baz/README.md > > I'll still want to separate '%license" files from "%doc", which means > I won't just be able to use: > > %doc %{defaultdocdir}/%{package}-%{version The specfile that Vitaly linked also marks the license files with `%license`. -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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
Fwd: debug_package when using go_generate_buildrequires
I am forwarding this to devel@, because I am reviewing this package and would also like a response. Thanks, Maxwell -- Forwarded Message -- Subject: debug_package when using go_generate_buildrequires Date: Monday, December 6, 2021, 5:42:08 AM CST From: Mikel Olasagasti To: gol...@lists.fedoraproject.org Hi all, I was updating some golang specs I've and switching them to use go_generate_buildrequires. I realized that some specs that are using it fail to build if `%global debug_package %{nil}` is not set. Same spec with all BuildRequires defined works just fine. Example: - Full spec (go2rpm): https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec - go_generate_buildrequires spec: https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec - Full spec build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572 - go_generate_buildrequires build: https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147 Is this expected? Is adding `%global debug_package %{nil}` correct or good practice for this scenario? Kind regards, Mikel Olasagasti (mikelo2) ___ golang mailing list -- gol...@lists.fedoraproject.org To unsubscribe send an email to golang-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/gol...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure - -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
On Friday, December 10, 2021 8:29:10 AM CST Kamil Paral wrote: > Hey Maxwell, > can you please file a new bug in bugzilla against dnf and copy the problem > description into it? Then make your new bug block bug 2013327 [1], which is > the tracker for this Change. This way you'll make sure that this problem > doesn't get lost and the maintainer has to deal with it before the > appropriate Change deadline. Thanks! > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2013327 > I just did[1]. Thank you for pointing me in the right direction! [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2033130 -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: Mock v2.16 release, mock-core-configs v36.4
On Thursday, December 16, 2021 12:25:12 PM CST Pavel Raiskup wrote: > Hello! > > I'm glad I can announce that we have a new release of Mock. See the full > release notes [1]. The major change that happened is the removal of > 'epel-8' config files, as a follow-up for [2] discussion (and of course on > *devel lists, big thanks to everyone for the discussion). > > Note that this is is the last v2 release being shipped to all supported > Fedora/EPEL versions. From now on, we'll move to v3 with development (in > 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only). > > [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16 > [2] https://pagure.io/epel/issue/133 > [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe > [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a > [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00 > [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7 > > Happy building! > Pavel I have tested this update and found a couple problems. Please see my comment on the Fedora 35 update page (linked above) or see below: > Hi @praiskup et. al, > > There are a couple problems: > > - `fedpkg --release epel8 mockbuild ` does not work properly. It defaults to > rhel8, which does not work by default and results in a 403 error when > dnf/mock attempts to install packages. After running `ln -s > /etc/mock/alma+epel-8-x86 _64.cfg ~/.config/mock/epel-8-x86_64.cfg`, it breaks entirely: > > ``` > $ fedpkg --release epel8 mockbuild --no-cleanup-after > Not downloading already downloaded ansible-core-2.12.1.tar.gz > > setting SOURCE_DATE_EPOCH=1638921600 > Wrote: > /home/gotmax/Sync/git-repos/packaging/fedora_rpms/forks.repos/ansible.repos/ansible-core/ansible-core-2.12.1-2.el8.src.rpm > > mockbuild.exception.ConfigError: Could not find included config file: > /tmp/epel-8-x86_64.v230b0w7mockconfig/templates/almalinux-8.tpl > > ERROR: Error in configuration > Could not execute mockbuild: Failed to execute command. > ``` > > It is possible to override the buildroot with `--root alma+epel-8-x86_64`, > but that is cumbersome and shouldn't be necessary. > > - Using `alma+epel-8-x86_64` works with `mock` itself and with `fedpkg` after > applying the aforementioned fix, but mock/dnf repeatedly prints out the > following error when installing packages: `Invalid configuration value: > failoverm ethod=priority in /var/lib/mock/alma+epel-8-x86_64/root/etc/dnf/dnf.conf; Configuration: OptionBinding with id "failovermethod" does not exist`. > > - Even if I wanted to use the `rhel+epel-8-*` configs, they don't work at > all, as `subscription-manager` is broken (rhbz#1995465) and it is impossible > to obtain an entitlement. > > In my opinion, this update should not be pushed until these crucial issues > are fixed. > > Thanks, > > Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: How to reset a branch on fedpkg?
On Sunday, December 19, 2021 6:35:13 AM CST Chen Chen wrote: > Hi everyone, > > I recently adopted an orphaned package. There are unwanted commits in a > branch, and I'd like to reset this branch to be as same as rawhide. How can I > achieve this? > It seems force push were not allowed on src.f . I also do not want to commit > a "git revert" on it to avoid "x commits ahead - click to create new PR" on > web UI. > > Regards, > Chen Hi Chen, Have you tried `fedpkg push --force` (or `-f` for short)? Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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
Non-responsive Maintainer Check for ishcherb
Hi everyone, I hope you are having/had a good weekend. I am sending this email in accordance with the Non-Responsive Maintainer Policy[0]. I created a non-responsive maintainer bug[1] for @ishcherb over two weeks ago and have not received a response. I am happy to help maintain this package. A month ago, I created a PR[2] to update `python-ansi2html` to the latest upstream release (1.6.0) and implement the new Python Packaging Guidelines. The PR did not receive a response from the package's main maintainer (@ishcherb) nor the co-maintainer (@ralph). The latest upstream version, 1.6.0, was released a year ago. The release-monitoring bug[3] for this release similarly did not receive a response from the maintainers. Here is the output of fedora_active_user for @ishcherb: ``` $ fedora_active_user.py --nofas --user ishcherb --email shcherbina.ir...@gmail.com Last action on koji: Fri, 24 Sep 2021 tag_package_owners entry created by mohanboddu [still active] Last package update on bodhi: 2017-11-21 12:46:16 on package spec2scl-1.2.1-1.fc27 Last actions performed according to fedmsg: - gotmax@e.email filed a new bug RHBZ#2028650 'Non-responsive maintainer check for ishc...' on 2021-12-02 15:24:48 - gotmax@e.email commented on RHBZ#2028650 'Non-responsive maintainer check for ishc...' on 2021-12-02 15:24:47 - gotmax@e.email updated 'cc' on RHBZ#1888556 'python-ansi2html-1.6.0a1 is available' on 2021-11-03 05:29:12 - ishcherb moved to position 589 on the badges leaderboard on 2021-10-27 02:24:46 - ishcherb has been awarded the "Tadpole with Legs" badge on 2021-10-27 02:24:37 And for @ralph: ``` $ fedora_active_user.py --nofas --user ralph --email 'rb...@redhat.com' Last action on koji: Sun, 10 Oct 2021 tag_package_owners entry created by oscar [still active] Last package update on bodhi: 2020-11-16 15:46:58 on package python-jira-2.0.0-10.fc34 Last actions performed according to fedmsg: - jaclu unstarred ralphbean/bugwarrior on 2021-12-17 16:22:27 - jaclu starred ralphbean/bugwarrior on 2021-12-17 16:22:27 - None on 2021-12-17 14:02:49 - None on 2021-12-17 14:02:48 - None on 2021-12-17 14:02:48 - None on 2021-12-17 14:02:47 - None on 2021-12-17 13:59:34 - None on 2021-12-17 13:59:24 - None on 2021-12-17 13:59:24 - None on 2021-12-17 13:59:23 Last email on mailing list: On 2018-11-15T01:35:55Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-09-10T15:30:19Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-09-07T19:42:06Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-08-28T14:10:39Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-06-26T13:24:49Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-06-25T13:25:53Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-18T13:33:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-11T01:00:42Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-05-10T12:22:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ On 2018-04-20T16:21:34Z rb...@redhat.com emailed as Ralph Bean on https://lists.fedoraproject.org/archives/api/list/infrastruct...@lists.fedoraproject.org/ Bugzilla activity 20 bugs assigned, cc or on which rb...@redhat.com commented Last comment on the most recent ticket on bugzilla: #1417509 2017-03-11 rbea ``` Does anyone know if @ishcherb and @ralph are still active in Fedora? Thanks, Maxwell [0]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/ [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2028650 [2]: https://src.fedoraproject.org/rpms/python-ansi2html/pull-request/3 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1888556 [4]: https://koji.fedoraproject.org/koji/userinfo?userID=3662 (@ishcherb's Koji user page) [5]: https://koji.fedoraproject.org/koji/userinfo?userID=1974 (@ralph's Koji user page) -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedorapro
Re: Mock v2.16 release, mock-core-configs v36.4
On Tuesday, December 21, 2021 8:22:55 AM CST Miro HronÄok wrote: > On 19. 12. 21 22:39, Pavel Raiskup wrote: > > On Sunday, December 19, 2021 10:22:57 PM CET Pavel Raiskup wrote: > >> So it seems that fedpkg doesn't (yet) know there's ~/.config/mock* at all. > > > > Proposed fix: https://pagure.io/rpkg/pull-request/595 > > It seems that this would only fix the issue if the symbolic link has already > been created. But before that, `fedpkg --release epel8 mockbuild` would still > fail, wouldn't it? Can we fix that as well, even if it's fixed in some > documentation only? > Yes, I think `fedpkg --release epel8 mockbuild` should print the same error message mock does when no default has been set, instead of defaulting to a non-functional koji config. -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: Self Introduction: Malcolm Inglis (mcinglis)
On Wednesday, January 5, 2022 4:28:19 PM CST Inglis, Malcolm via devel wrote: > I have two outstanding PRs that I think are hanging on uploading new sources > to the Lookaside Cache I have experienced this issue myself and seen it happen to other newcomers several times. It nullifies the purpose of CI for a population that it can benefit the most. It is possible to run `fedpkg new-sources --offline`, which updates the `sources` file and `.gitignore` without actually touching the lookaside cache. This saves the package maintainer who merges the PR the trouble of creating another commit (they still have to run `fedpkg new-sources` to actually upload the tarball to the lookaside cahce), but the whole area still creates unnecessary friction. @msrb submitted a PR[1] to Fedora CI to fix the issue, but it was never merged. [1]: https://github.com/fedora-ci/dist-git-build-pipeline/pull/25 -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 PGP Keyserver: hkp://keyserver.ubuntu.com gotmax@e.email 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: moby-engine (also known as Docker) maintenance in Fedora
On Wed Nov 16, 2022 at 08:25 -0500, Dusty Mabe wrote: > On 11/16/22 06:09, Dan ÄermĂĄk wrote: > > On November 14, 2022 7:18:45 PM UTC, "TimothĂ©e Ravier" > > wrote: > > I'm using docker for $dayjob and would be willing to help out a bit, but I > > will not be the main maintainer, as I don't feel comfortable taking such a > > huge package and lack the cycles for that. Yes, the package is complicated :(. It could use some cleanup (see the end of [1]), but I'm trying to step away from the package, and I haven't had time to. [1]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DMPZRAUO3H5EHOCZDULYORYJVQU2WBIJ/ > I think there are others that would be willing to help mentor you if > you'd be interested in the challenge (with help). The Golang SIG has > regular meetings and various ways to communicate, which might be a > good way to engage: https://fedoraproject.org/wiki/SIGs/Go That's true. Our next meeting is the 21st at 19:00 UTC in #fedora-golang. As always, anybody is welcome to attend :). > >> This notably impacts Fedora CoreOS as we are including the moby-engine > >> package by default to let users pick their container engine of choice > >> whithout deciding for them in advance. We offer both major container > >> engines by default in the image (podman and moby-engine). > > > > No offense, but this sounds like that this is something the Fedora coreos > > team should tackle. Given that Fedora coreos appears to be driven to a > > large extend by redhat (at least that's my impression, please correct me if > > I'm wrong), I find it a bit odd that the business is asking volunteers to > > step up to help the business out... > > No offense taken. This is a great opportunity to add some clarity. Red Hat > doesn't ship Docker in products any longer. It was dropped in RHEL8+: > https://access.redhat.com/solutions/3696691 Yes, Docker and Containerd are no longer Supported in RHEL, but that's besides the point here. Fedora CoreOS ships moby-engine. The CoreOS Working Group apparently care about moby-engine and want it to be included in FCOS. I picked up on this and asked if they'd be willing to help maintain it. The two developers involved (who are paid by RH to work on FCOS) made clear that they are uninterested in doing so[^1] and took it upon themselves to find a volunteer to maintain the package. We got more contributions from an outside contributor who wasn't a package maintainer (3 PRs which involved rebasing patches, updating dependencies, and diagnosing build failures) than the FCOS team (0 PRs, 5 pings on their issue tracker and IRC, this email). I'm not trying to cause unnecessary strife here and they have apologized, but I'd be dishonest if I said I wasn't disappointed with the way this situation was handled. [^1]: which is alright. Everyone is free to choose what packages they do or don't want to maintain. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Orphaned a lot of (mostly) Go packages owned by @fpokorny
On Thu Nov 24, 2022 at 02:39 +0100, Miro HronÄok wrote: > go-compilers > go-srpm-macros These should both be orphaned. go-srpm-macros has been retired, as it's now a subpackage of go-rpm-macros. go-compilers is Obsoleted by go-rpm-macros itself, but it looks like it has not yet been retired. I've gone ahead and done that. This split happened a few years ago, but the old packages were never properly removed. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Orphaned a lot of (mostly) Go packages owned by @fpokorny
On Thu Nov 24, 2022 at 12:25 +0100, Miro HronÄok wrote: > On 24. 11. 22 3:38, Maxwell G via devel wrote: > > On Thu Nov 24, 2022 at 02:39 +0100, Miro HronÄok wrote: > >> go-compilers > >> go-srpm-macros > > > > These should both be orphaned. go-srpm-macros has been retired, as it's > > now a subpackage of go-rpm-macros. > > But it exists on Fedora 36 and needs a maintainer there. It will likely be > auto-orphaned once Fedora 36 EOLs. Should I give it to you? It's not part of the Fedora 36 composes, because go-rpm-macros's go-srpm-macros subpackage has a higher NEVR, but feel free to assign it to me. > > > go-compilers is Obsoleted by > > go-rpm-macros itself, but it looks like it has not yet been retired. > > I've gone ahead and done that. This split happened a few years ago, but > > the old packages were never properly removed. > > Ack. Technically also needs a maintainer but less important considering ti is > obsoleted. Users do report bugzillas for whatever component, so I do > recommend > having a responsive/responsible bugzilla PoC even for this one. You can also assign this one to me. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: F38 proposal: Reproducible builds: Clamp build mtimes to $SOURCE_DATE_EPOCH (System-Wide Change proposal)
On Thu Nov 10, 2022 at 15:23 -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes > > 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 == > > The `%clamp_mtime_to_source_date_epoch` RPM macro will be set to `1`. > When an RPM package is built, mtimes of packaged files will be clamped > to `$SOURCE_DATE_EPOCH` which is already set to the date of the latest > `%changelog` entry. As a result, more RPM packages will be > reproducible: The actual modification time of files that are e.g. > modified in the `%prep` section or built in the `%build` section will > not be reflected in the resulting RPM packages. Files in RPM packages > will have mtimes that are independent of the time of the actual build. > Will packagers still be required to use install -p, cp -p, etc. to preserve mtimes? For some packages, the source archives mtimes will be lower than $SOURCE_DATE_EPOCH, but e.g. for ancillary Source files (e.g. systemd units) stored in distgit, using -p won't make a difference, because the mtimes aren't preserved when Koji clones the distgit repository. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Red Hat Bugzilla fonts
On Tue Nov 29, 2022 at 18:51 +0100, Vitaly Zaitsev via devel wrote: > Hello. > > RHBZ began to demand Microsoft font "Segoe UI" since yesterday: > > font-family: SFMono-Medium, SF Mono, Segoe UI Mono, "Roboto Mono", > "Ubuntu Mono", Menlo, Courier, monospace > > > SFMono-Medium, SF Mono > > Not packaged and not installed by default on Fedora, so the Segoe UI > Mono is used. > > Is this okay? I think only open-source and packaged fonts should be used. > I believe Ubuntu fonts' license is also not permitted for Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)
On Tue Nov 29, 2022 at 12:57 CST, Jeremy Linton wrote: > Hi, > > > On 6/16/22 15:53, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer > > > > 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. > > Given how this just went in the FESCo meeting, I might toss out an > alternative I've not seen anyone else suggest. > > Why not turn this on just for rawhide and leave it off for the main > distro releases? > > That is sorta what happens with the kernel already (extra debug > options). Its not perfect but rawhide is largely intended to be the dev > target anyway, so this solves both the "how do I do detailed > testing/profiling" as well as maintaining peak performance for everyone > else. I don't think those two things are analogous. It's possible to install a non-debug kernel on Rawhide. This is a distro-wide change that affects every package. Also, as Vitaly said, doing two mass rebuilds is untenable. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Schedule for Tuesday's FESCo Meeting (2022-11-29)
Nov 29, 2022 2:31:29 PM Kevin Kofler via devel : Stephen Gallagher wrote: Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat. does anyone have a complete log? It does not show up on meetbot.fedoraproject.org, and the raw log at https://meetbot-raw.fedoraproject.org/fedora-meeting/2022-11-29/fesco.2022-11-29-17.00.log.txt is truncated. Yeah, zodbot broke during the meeting :(. I pasted my logs here[1]. [1]: https://paste.sr.ht/~gotmax23/3576b21a357f5da14cc5871925d1f45999197b62 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Schedule for Tuesday's FESCo Meeting (2022-11-29)
On Tue Nov 29, 2022 at 22:13 +, Zbigniew JÄdrzejewski-Szmek wrote: > I just saw gotmax's comment after pasting this in ;) And I saw you beat me to replying to Kevin after I had already sent the same thing. The more the merrier I guess :). -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Some reasons I really dislike buildroot overrides and would like us to get rid of them soon
On Fri Dec 2, 2022 at 13:30 -0800, Adam Williamson wrote: > What does everyone else think? Has the time come? Or is there more we > need to do to make side tags usable for all cases before getting rid of > overrides? -1. For many use cases, side tags are the correct solution and buildroot overrides should not be used. However, there are occasions where they are still useful. If people are improperly using buildroot overrides and breaking the buildroot, the correct solution is education and documentation, not banning them entirely. Examples: 1. There is a Go compiler release that has patches for a CVE (i.e. almost every Go release ). I create buildroot overrides so all new builds are able to immediately start using it. 2. The same thing above but with other Go libraries that are statically linked into Go binaries. 3. There is a bug in macros that break builds. The fix should be available in the buildroot for all new builds immediately. 4. Some other buildtime only dependency update provides a bugfix that is needed for packages that BuildRequire it. On Fri Dec 2, 2022 at 23:21 +0100, Fabio Valentini wrote: > Not sure if we should turn them off entirely, but we could restrict > their use somewhat? For example, only allow people in "releng" or "qa" > groups to file them. I'd prefer not to have to bother releng every time I need to do this. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Starting Flatpak SIG
On Thu Dec 8, 2022 at 17:29 +, Timothée Ravier wrote: > > Do we need a mailing list? My initial gut feeling is no, but I'm > > interested in what other people think. > > I think we don't. Tracking conversations and issues is much easier with a > tracker than mailing lists. I think it's helpful to have a mailing list for discussion and leave the issue tracker for tracking bugs/RFEs or other work that's already agreed upon. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Include minor version number in packaged Python shebangs
On Fri Dec 9, 2022 at 22:04 +, Audrey Toskin wrote: > DNF modules let you install multiple different versions of Python 3, > and the `alternatives` tool lets you change which is the default > version invoked by `/usr/bin/python3`. This is not the case on any current Fedora release. AFAIK, only EL 8 manages /usr/bin/python3 with alternatives. In current releases, /usr/bin/python3 always points to the default system python interpreter even if you have other python interpreter packages on your system. > However, at least for *Enterprise Linux 8, it seems a lot of packages > were built assuming the distro's default Python 3.6, but at runtime > only invoke "Python 3", not 3.6 specifically. In EPEL, packages with /usr/bin/python3 shebangs are meant to be executed with python3.6. You are correct that this falls apart when the python3 alternative points to a different Python interpreter. This oversight has been fixed[1] so new package builds that are meant for python3.6 have /usr/bin/python3.6 interpreters. We have not rebuilt existing packages so they are still affected by this. Therefore, it is recommended to keep python3 as /usr/bin/python3.6. [1]: https://lists.fedoraproject.org/archives/list/epel-de...@lists.fedoraproject.org/thread/RE3PG72B5AX7NTACPDSBGOWCMN7I3OQJ/ > It seems that I still need Python 3.6 for most packages installed via > DNF on EL8, Correct. > So, the workaround to having both installed on my system at the same > time would be to edit the shebangs to include the minor version of > Python that each application requires. It'd be better to set the python3 alternative to python3.6 (alternatives --set python3 /usr/bin/python3.6). Local modifications like this are not recommended. They will be discarded on updates. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: duktape soname bump
On Fri Dec 16, 2022 at 20:31 +0100, Frantisek Zatloukal wrote: > I wish I could write that I am going to build duktape 2.7.0 which bumps the > soname. However, my brain kind of misfired and I didn't, for some reason, > announce this upfront. The changes are minor, ABI changing stuff, I've > taken care of rebuilding all the dependencies (main maintainers of those > are in BCC): > - gerbera > - libproxy > - polkit > - python-dukpy > In any case, thank you for taking the time to properly rebuild the packages and not break the distribution. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Polymake soname bump
On Mon Dec 19, 2022 at 14:10 -0700, Jerry James wrote: > If all goes well, I will do the same for F37. I don't think this soname bump should happen in a stable release. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Polymake soname bump
On Mon Dec 19, 2022 at 15:56 -0700, Jerry James wrote: > On Mon, Dec 19, 2022 at 3:54 PM Maxwell G via devel > wrote: > > On Mon Dec 19, 2022 at 14:10 -0700, Jerry James wrote: > > > If all goes well, I will do the same for F37. > > > > I don't think this soname bump should happen in a stable release. > > Because ... ? The new version is backwards API compatible (although > not ABI compatible) with the previous version, I'm going to rebuild > the only consumer of the library, and the new version fixes bugs. > What is your objection? ABI incompatible updates are against the Updates Policy for stable releases: > ABI changes in general are very strongly discouraged, they force > larger update sets on users and they make life difficult for > third-party packagers. -- https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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
Golang bundled() Provides generator
Hi Fedorians, A recent PR reminded me that I never properly announced the new (well, four months old) bundled() Provides generator for Golang projects[1]. This can be used to simplify generating these Provides when bundling is justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.txt file generated by `go mod vendor` with `%license` and the generator will take care of the rest. This removes the need for long lists of Provides that clutter specfiles and have to be updated after each upstream release. It's up to package maintainers to inspect the Provides for correctness when opting in to this generator. Please let us know if you find any bugs. The generator is available in all Fedora branches and on EPEL 9 (part of go-rpm-macros-epel that shadows RHEL's go-rpm-macros). go-rpm-macros has been updated in c9s, so I'll remove the generator from go-rpm-macros-epel when the next RHEL 9 minor release comes out. [1]: https://pagure.io/go-rpm-macros/c/226596177c63c3dc180b5aeda45fe3b18706e877?branch=master and https://pagure.io/go-rpm-macros/c/c32fbbd25bbcedee8c0b898d3653255b18a0d30e?branch=master [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_or_unbundled -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Is there convenient way to setup Fedora compilation flags outside of the RPM build?
On Sun Dec 25, 2022 at 09:02 -0500, Sam Varshavchik wrote: > rpm -E '%__global_ldflags' > > is also needed for LDFLAGS. %__global_ldflags is deprecated. You should use %build_ldflags instead[1]. Also, %build_cflags, %build_cxxflags, and friends are preferred to %optflags AFAIK. [1]: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_130 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Cfitsio soname bump, side tag created
On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > created a side tag f38-build-side-61457 > > I have already built cfitsio, CCfits and wcslib. Affected packages are: > > astrometry > bes > CCfits > cpl > elements-alexandria > gdal > healpix > indi-3rdparty-gphoto > kstars > kst > LabPlot > libindi > luminance-hdr > perl-Astro-FITS-CFITSIO > phd2 > python-astropy > python-fitsio > python-healpy > root > siril > skyviewer > sourcextractor++ > ufraw > vips > wcslib > > Best regards, Sergio @music already built luminance-hdr. I'm submitting builds for the rest. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Cfitsio soname bump, side tag created
On Thu Dec 29, 2022 at 09:40 HST, Maxwell G via devel wrote: > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > > created a side tag f38-build-side-61457 > > > > I have already built cfitsio, CCfits and wcslib. > > @music already built luminance-hdr. I'm submitting builds for the rest. The builds have finished. The following packages failed to build after being rebuilt a total of three times: name:taskid:status -- astrometry:95679269:failed esorex:95679267:failed python-astropy:95679270:failed python-healpy:95679272:failed esorex and python-astropy are preexisting failures. python-healpy and astrometry depend on python-astropy and are failing with DEBUG util.py:443: No matches found for the following disable plugin patterns: local, spacewalk, versionlock DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is already installed. DEBUG util.py:443: Error: DEBUG util.py:443: Problem: conflicting requests DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed by python3-astropy-5.1-3.fc38.aarch64 DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable packages) DEBUG util.py:596: Child return code was: 1 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Cfitsio soname bump, side tag created
On Thu Dec 29, 2022, Maxwell G via devel wrote: > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I have > > > created a side tag f38-build-side-61457 > > > > > > I have already built cfitsio, CCfits and wcslib. > > > > > @music already built luminance-hdr. I'm submitting builds for the rest. > > > The builds have finished. The following packages failed to build after > being rebuilt a total of three times: > > name:taskid:status > -- > astrometry:95679269:failed > esorex:95679267:failed > python-astropy:95679270:failed > python-healpy:95679272:failed > > > esorex and python-astropy are preexisting failures. python-healpy and > astrometry depend on python-astropy and are failing with > > DEBUG util.py:443: No matches found for the following disable plugin > patterns: local, spacewalk, versionlock > DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is > already installed. > DEBUG util.py:443: Error: > DEBUG util.py:443: Problem: conflicting requests > DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed by > python3-astropy-5.1-3.fc38.aarch64 > DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable > packages) > DEBUG util.py:596: Child return code was: 1 I've submitted https://src.fedoraproject.org/rpms/python-astropy/pull-request/2/. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
On Mon Jan 2, 2023 at 09:57 +0100, Miroslav SuchĂœ wrote: > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a): > > produces bogus changelog messages and artificially > > inflates Release counters. > > I always wondered why people are afraid of gaps in numbering? It is > just a number. The number will not object if you skip some of them. :) The release number shows how many builds of the same version have been made. A high release is also baseline indicator that a package/project is stale downstream and/or upstream. When the first build of foo v1.5.0 is foo-1.5.0-6 because the author took the time to split up logical changes into separate commits, the value of that release number is lost. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Rpmautospec howto do a rebuild for something
On Mon Jan 2, 2023 at 12:32 +, SĂ©rgio Basto wrote: > I need rebuild a package that is using rpmautospec , how I can rebuild > the package and increase relversion ? `git commit --allow-empty -m "Changelog entry here"` will do what you want. The empty commit will result in a release and changelog bump. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Orphaned packages looking for new maintainers
On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote: > I went ahead and took vim-nerdtree. FYI: Nerdtree is unmaintained upstream: https://github.com/preservim/nerdtree/issues/1280 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Help with Rust packaging
Jan 7, 2023 4:41:29 PM LumĂr Balhar : y-py upstream uses maturin as a build backend which is not available in Fedora yet so I had to add some metadata manually to port it to setuptools-rust Why not package maturin? Is there something particularly problematic about maturin (e.g. lots of missing dependencies) or is it just lack of time? -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: List of long term FTBFS packages to be retired in February
On Wed Jan 11, 2023 at 13:58 +0100, Miro HronÄok wrote: > Based on the current fail to build from source policy, the following packages > should be retired from Fedora 38 approximately one week before branching. > golang-github-gin-gonic eclipseo, go-sig I've fixed this: https://bugzilla.redhat.com/show_bug.cgi?id=2045509 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: List of long term FTBFS packages to be retired in February
On Wed Jan 11, 2023 at 13:58 +0100, Miro HronÄok wrote: > golang-github-d2g-dhcp4servereclipseo, go-sig I need a package review to fix this: https://bugzilla.redhat.com/show_bug.cgi?id=2160202 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Cfitsio soname bump, side tag created
On Thu Jan 12, 2023 at 01:19 +0100, Sergio Pascual wrote: > El vie, 30 dic 2022 a las 2:33, Maxwell G via devel (< > devel@lists.fedoraproject.org>) escribiĂł: > > > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > > On Thu Dec 29, 2022, Maxwell G via devel wrote: > > > > On Wed Dec 28, 2022 at 15:00 +0100, Sergio Pascual wrote: > > > > > Hello again, as stated before [1], I'm updating cfitsio to 4.2. I > > have > > > > > created a side tag f38-build-side-61457 > > > > > > > > > > I have already built cfitsio, CCfits and wcslib. > > > > > > > > > > > @music already built luminance-hdr. I'm submitting builds for the rest. > > > > > > > > > The builds have finished. The following packages failed to build after > > > being rebuilt a total of three times: > > > > > > name:taskid:status > > > -- > > > astrometry:95679269:failed > > > esorex:95679267:failed > > > python-astropy:95679270:failed > > > python-healpy:95679272:failed > > > > > > > > > esorex and python-astropy are preexisting failures. python-healpy and > > > astrometry depend on python-astropy and are failing with > > > > > > DEBUG util.py:443: No matches found for the following disable plugin > > patterns: local, spacewalk, versionlock > > > DEBUG util.py:445: Package pkgconf-pkg-config-1.8.0-3.fc37.aarch64 is > > already installed. > > > DEBUG util.py:443: Error: > > > DEBUG util.py:443: Problem: conflicting requests > > > DEBUG util.py:443:- nothing provides libcfitsio.so.9()(64bit) needed > > by python3-astropy-5.1-3.fc38.aarch64 > > > DEBUG util.py:445: (try to add '--skip-broken' to skip uninstallable > > packages) > > > DEBUG util.py:596: Child return code was: 1 > > > > I've submitted > > https://src.fedoraproject.org/rpms/python-astropy/pull-request/2/. > > > > > Hello, I have built python-astropy 5.2 in the side tag, we can continue > with the packages depending on it. I have taken care of esorex too Great! I rebuilt the last two packages and submitted an update: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5e54e85176 -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Orphaned packages looking for new maintainers
> Can take this if no-one else is interested (@Sergio Basto?) > > > docker-compose   lsm5, orphan, ttomecek  1 weeks > > ago The Python docker-compose is deprecated upstream in favor of the Compose V2 Docker CLI Plugin written in Go. The latter is not yet packaged for Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Retiring Bottles in favor of Flatpak provided by upstream
On Tue Jan 24, 2023 at 22:44 +0100, Sandro wrote: > Development of Bottles is moving fast and we have been struggling to > keep up with upstream releases, especially since the introduction of > Rust components. What (rust) dependencies are missing? Is it just python-orjson? I worked on packaging that last night. It seems this library is gaining in popularity. Four new rust dependencies and updating pyo3 to 0.17 (while creating compat packages for 0.16) are needed. Updating pyo3 is straightforward and Fabio started working on it (thanks!). https://copr.fedorainfracloud.org/coprs/gotmax23/orjson/builds/ https://git.sr.ht/~gotmax23/fedora-python-orjson I'm not sure I can commit to maintaining these myself, though. Let me know if you're interested in helping out. > Upstream has approached the maintainers [1,2] and asked us to retire the > package in favor of the Flatpak packages provided by upstream. I wish this upstream was more friendly to distribution packagers... Approaching downstream maintainers like this feels inappropriate and somewhat antithetical to the tenets of OSS. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
On Fri Feb 3, 2023 at 02:00 +0100, Miro HronÄok wrote: > On 02. 02. 23 17:06, Ben Cotton wrote: > > # Create a blank ''blocker'' package that Conflicts with the to be > > removed packages. > > # Create a new Copr with the blocker package in its default buildroot. > > This will simulate the actual removal of these packages. > > Was this verified to actually work that way? Isn't the conflicting > default-installed package removed when something that is conflicting is about > to be installed? Yes, I did confirm it. You're right that just adding the package to the buildroot doesn't work. I also built a modified go-rpm-macros to ensure that blocker is pulled in (see the attachment); %gometa explicitly adds `BuildRequires: blocker` to specfiles and every go-rpm-macros subpackage has `Requires: blocker`. I already found a couple false positives. -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 proposal: Mass Retire Golang Leaves (Self-Contained Change proposal)
On Fri Feb 3, 2023 at 01:42 +, Maxwell G wrote: > (see the attachment) Here it is! -- Maxwell G (@gotmax23) Pronouns: He/Him/His diff --git a/blocker.patch b/blocker.patch new file mode 100644 index 000..76999f4 --- /dev/null +++ b/blocker.patch @@ -0,0 +1,24 @@ +From 90303acd82a190711f6b902a25341dff459780ca Mon Sep 17 00:00:00 2001 +From: Maxwell G +Date: Sat, 21 Jan 2023 18:16:39 -0600 +Subject: [PATCH] blocker + +--- + rpm/macros.d/macros.go-srpm | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/rpm/macros.d/macros.go-srpm b/rpm/macros.d/macros.go-srpm +index d589894..d3d232c 100644 +--- a/rpm/macros.d/macros.go-srpm b/rpm/macros.d/macros.go-srpm +@@ -117,6 +117,7 @@ else + exclusive_arches = "%{golang_arches_future}" + end + print( "BuildRequires: go-rpm-macros\\n") ++print( "BuildRequires: blocker\\n") + print(rpm.expand("ExclusiveArch: " .. exclusive_arches .. "\\n")) + local fedora = require "fedora.common" + local go = require "fedora.srpm.go" +-- +2.39.0 + diff --git a/go-rpm-macros.spec b/go-rpm-macros.spec index 1ca030b..1a278cc 100644 --- a/go-rpm-macros.spec +++ b/go-rpm-macros.spec @@ -19,29 +19,32 @@ Version: 3.2.0 %global gopath %{_datadir}/gocode Name: go-rpm-macros +Epoch: 1 Release: %autorelease Summary: Build-stage rpm automation for Go packages License: GPL-3.0-or-later URL: %{forgeurl} Source:%{forgesource} +Patch: blocker.patch -Requires: go-srpm-macros = %{version}-%{release} -Requires: go-filesystem = %{version}-%{release} +Requires: go-srpm-macros = %{?epoch:%{epoch}:}%{version}-%{release} +Requires: go-filesystem = %{?epoch:%{epoch}:}%{version}-%{release} Requires: golist +Requires: blocker %ifarch %{golang_arches} Requires: golang Provides: compiler(golang) Provides: compiler(go-compiler) = 2 -Obsoletes: go-compilers-golang-compiler < %{version}-%{release} +Obsoletes: go-compilers-golang-compiler < %{?epoch:%{epoch}:}%{version}-%{release} %endif %ifarch %{gccgo_arches} Requires: gcc-go Provides: compiler(gcc-go) Provides: compiler(go-compiler) = 1 -Obsoletes: go-compilers-gcc-go-compiler < %{version}-%{release} +Obsoletes: go-compilers-gcc-go-compiler < %{?epoch:%{epoch}:}%{version}-%{release} %endif %description @@ -55,6 +58,7 @@ pull it in for Go packages only. Summary: Source-stage rpm automation for Go packages BuildArch: noarch Requires: redhat-rpm-config +Requires: blocker %description -n go-srpm-macros This package provides SRPM-stage rpm automation to simplify the creation of Go @@ -69,6 +73,7 @@ go-srpm-macros will pull in for Go packages only. %package -n go-filesystem Summary: Directories used by Go packages License: LicenseRef-Fedora-Public-Domain +Requires: blocker %description -n go-filesystem This package contains the basic directory layout used by Go packages. @@ -77,7 +82,7 @@ This package contains the basic directory layout used by Go packages. Summary: RPM spec templates for Go packages License: MIT # go-rpm-macros only exists on some architectures, so this package cannot be noarch -Requires: go-rpm-macros = %{version}-%{release} +Requires: go-rpm-macros = %{?epoch:%{epoch}:}%{version}-%{release} #https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/51 #Requires: redhat-rpm-templates ___ 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: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases
2023-02-07T11:43:53Z Lokesh Mandvekar : > We (podman upstream and fedora maintainers) are hoping to disable i686 > and 32-bit arm builds for Podman and some related tools under > https://github.com/containers org. We would like to do this also for > released Fedora versions, and not just the upcoming ones. > > What Fedora paperwork do we need in place to get this going? arm32 has been removed entirely from F37+. I don't think excluding packages from arm32 at this point in the F36 release cycle is acceptable. Wait until the release goes EOL. As for i686, you don't need extra paperwork thanks to exclude packages thanks to https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval. You just need to properly handle dependent packages. You cannot ExcludeArch a package unless all of its dependents are also excluded. It's recommended to exclude Go packages with `ExclusiveArch: %{golang_arches_future}`. For other packages, a regular `ExcludeArch: %{ix86}` is sufficient. Here's some of the dependents you need to account for: --- $ cat
fedrq - new repoquerying tool
Hi Fedorians, I've been working on a repoquerying tool called fedrq [1] that I'd like to share with you. Here's the elevator pitch: fedrq provides a friendly interface to query the Fedora repositories. It makes it really easy to query across Fedora and EPEL branches. It uses the dnf Python bindings (libdnf5 backend is almost done) and doesn't shell out to dnf repoquery. Amongst other things, fedrq allows querying for reverse dependencies, packages that contain a certain Provide or file, subpackages of an SRPM, and general package metadata. My favorite features are the easy branch switching, `fedrq subpkgs` (there's no real equivalent in dnf repoquery), and the ability to dump package metadata as JSON. The many threads about how to properly query for dependencies when doing SO name bump rebuilds and my own frustrations with dnf repoquery inspired this tool. You can install fedrq from PyPI or from gotmax23/fedrq [2] on Copr. The EXAMPLES section of fedrq(1) [3] provides a good intro and demonstration of fedrq's functionality. The tool is very much a WIP and any feedback is appreciated. For reverse dependency rebuilds, you probably want the following command: ``` $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent ``` This accounts for any package that depends on any subpackage/binary RPM produced by SRCNAME at buildtime and/or runtime, and spits out the names of the source packages that need to be rebuilt. For simple packages that output only one RPM, `fedrq whatrequires -F source PKGNAME` is sufficient. [1] https://sr.ht/~gotmax23/fedrq/ [2] https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq/ [3] https://gotmax23.srht.site/fedrq/fedrq.1.html#EXAMPLES -- Thanks, Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedrq - new repoquerying tool
On Sun Feb 12, 2023 at 08:12 +, Mattia Verga via devel wrote: > Il 12/02/23 06:31, Maxwell G via devel ha scritto: > > For reverse dependency rebuilds, you probably want the following > > command: > > > > ``` > > $ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent > > $ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent > > ``` > > > > This accounts for any package that depends on any subpackage/binary RPM > > produced by SRCNAME at buildtime and/or runtime, and spits out the names > > of the source packages that need to be rebuilt. For simple packages that > > output only one RPM, `fedrq whatrequires -F source PKGNAME` is > > sufficient. > > > Thanks for this! I never found a (easy) way to make dnf output the exact > reverse dependency of libindi, for example, and your tool does that well > with an easy to understand output: > > $ fedrq whatrequires -F source $(fedrq subpkgs libindi) > indi-3rdparty-drivers > indi-3rdparty-libraries > kstars > libindi > phd2 > stellarium > > Though, it would be nice to have an easier subcommand or option just for > that, as it will be, I think, the most required use case. Maybe a 'fedrq > whatrequires --soname-bump SRCNAME'? Thanks for trying it out and for the feedback! I don't want to tack this on to `whatrequires`, but a separate subcommand might be warranted. Name suggestions are welcome. subpkgs-whatrequires is accurate but way too long :). I created an issue for this in fedrq's issue tracker [1]. [1] https://todo.sr.ht/~gotmax23/fedrq/13 -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: fedrq - new repoquerying tool
On Sun Feb 12, 2023 at 13:40 +, Maxwell G via devel wrote: > > Though, it would be nice to have an easier subcommand or option just for > > that, as it will be, I think, the most required use case. Maybe a 'fedrq > > whatrequires --soname-bump SRCNAME'? > > Thanks for trying it out and for the feedback! I don't want to tack this > on to `whatrequires`, but a separate subcommand might be warranted. Name > suggestions are welcome. subpkgs-whatrequires is accurate but way too > long :). I created an issue for this in fedrq's issue tracker [1]. > > > [1] https://todo.sr.ht/~gotmax23/fedrq/13 > This is now available on the main branch. $ fedrq whatrequires -F source $(fedrq subpkgs SRCNAME) can be replaced with $ fedrq whatrequires-src -F source SRCNAME or $ fedrq wrsrc -F source SRCNAME wrsrc is an alias for whatrequires-src. If you want, you can install https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq-dev/build/5519594/ or $ pip install 'git+https://git.sr.ht/~gotmax23/fedrq#main' to try it out. I'll cut a release later this week. -- Maxwell G (@gotmax23) Pronouns: He/They ___ 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: ANTLR packages and i686
(Sorry for the messed up line wrapping. I wanted to get this out.) Hi Jerry, On 22/07/06 08:13PM, Jerry James wrote: > - golang-github-google-cel (eclipseo, @go-sig): needs the Go runtime > from the antlr4-project package > - golang-google-grpc (eclipseo, @go-sig): needs > golang-github-google-cel. Is consumed by a TON of other Go packages, > so many that I did not attempt to trace them. I'm replying as a member of the go-sig, as the primary maintainer is pretty busy lately. At least 289 source packages (recursively) BuildRequire golang-github-google-cel-devel[1]. Some of these packages only provide `-devel` subpackages that should've been included in the above query, but there are likely also some that provide binaries that could be used by other packages (go or otherwise; runtime and/or buildtime). The dependents of those packages aren't included in the count above. I am working on querying for those packages and asking maintainers to remove the leaves. The go-sig is also considering entirely removing go stack from i686, but we have not made a lot of progress yet. My preference would be to wait to remove all go packages from there by removing %ix86 from %golang_arches instead of adding `ExcludeArch: %ix86` to just the golang packages that need golang-antlr4-runtime-devel. Non go packages can probably be `ExcludeArch`ed first. Please do not remove golang-antlr4-runtime-devel until we've dealt with at least the packages affected by removing this one. I understand that this probably isn't the answer you want to hear. We are in a similar situation; we'd like to remove the go stack from i686, as it adds extra maintenance burden, but there are other packages that depend on go stuff that need to be dealt with first (and some go packages that don't follow the packaging guidelines and are missing ExclusiveArch: %{golang_arches}`). [1]: sudo dnf repoquery --repo=rawhide{,-source} --recursive --whatrequires | grep '\.src$' | pkgname | sort | uniq -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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: Fedora 37 mass rebuild started
On 22/07/22 09:08AM, Michael J Gruber wrote: > notmuch failed to build from source because of a strange test suite failure > on ppc64le: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89837091 > > The only failing test is a pytest run on the bindings > > ``` > T391-python-cffi: Testing python bindings (pytest) > FATAL: /builddir/build/BUILD/notmuch-0.36/test/T391-python-cffi.sh: > interrupted by signal 15 > ``` > > whereas other tests of those bindings work. What makes it even more strange > is that for a scratch build all tests work on all architectures: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89853627 > > Is there possibly a timing issue where tests on ppc64le happen to take "too > long" and pytest gets killed? It sounds like this might've been a transient issue, likely related to something on the builder, as it also worked fine when I scratch built it. The releng folks can probably tell you how to handle this and if you should rebuild it, just wait, or whatever. As Kevin said: > You can contact releng in #fedora-releng channel on Libera.Chat, the > #releng:fedoraproject.org room on Matrix, or by dropping an email to > our list[2] or filing an issue in pagure[3]. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
repoquery-fu (was Re: Retiring the pcre package from Fedora)
On 22/07/22 10:24PM, Fabio Valentini wrote: > the script that determines leaf packages in the Rust SIG Can you provide a link to this? > $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires > pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery > --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ; > dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires > pcre-utf32) | sort | uniq | grep src It's actually possible to pass --whatrequires mutliple times with all of the dependencies, instead of running multiple queries. e.g.: sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq This is quite a bit faster. I only just recently learned this, so I thought I'd pass it on :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Retiring the pcre package from Fedora
(It seems my previous message didn't send properly...) On 22/07/22 10:24PM, Fabio Valentini wrote: > the script that determines leaf packages in the Rust SIG Can you provide a link to this? > $ (dnf repoquery --whatrequires pcre ; dnf repoquery --whatrequires > pcre-cpp ; dnf repoquery --whatrequires pcre-devel ; dnf repoquery > --whatrequires pcre-static ; dnf repoquery --whatrequires pcre-tools ; > dnf repoquery --whatrequires pcre-utf16 ; dnf repoquery --whatrequires > pcre-utf32) | sort | uniq | grep src It's actually possible to pass --whatrequires mutliple times with all of the dependencies, instead of running multiple queries. e.g.: sudo dnf repoquery --whatrequires pcre --whatrequires pcre-cpp --whatrequires pcre-devel --whatrequires pcre-static --whatrequires pcre-tools --whatrequires pcre-utf16 --repo=rawhide{,-source} -q | grep '\.src$' | sort | uniq This is quite a bit faster. I only just recently learned this, so I thought I'd pass it on :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Heads-up: ODE soname bump
On 22/07/24 06:05PM, Kalev Lember wrote: > If ODE 0.16 was only built as part of the mass rebuild and wasn't > available in the buildroot during the mass rebuild (and I don't think > it was), then all the other packages that depend on it were still > built against the older ODE 0.14 version as part of the mass rebuild. > Once the mass rebuild is merged back into f37 then all other packages > that depend on ODE are going to have broken dependencies. That indeed appears to be the case. The f37-rebuild build target[1] builds against f37-build but tags completed builds into f37-rebuild. ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild. [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581 [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899 Also, looking at ompl, one of ode's dependents, you can see that it was rebuilt against the old version of ode: > DEBUG util.py:445: ode-devel x86_64 > 0.14-15.fc36 build 66 k -- https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log and https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925 In order to fix this, a provenpackager will need to build all of the dependents in a sidetag like normal. Preferably, this could happen before the mass rebuild tag is merged back into f37. I am a bit busy today, but I suppose I could do this later if nobody beats me to it. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Upstream Release Monitoring - bug report
On 22/07/26 09:54AM, Kevin Fenzi wrote: > If you want to watch activity on a package you want The little 'watch' > pulldown under The package description. You can set there if you want to > watch bugs, commits, both, etc. If you only wanted to watch koji builds, > you would need to set that in FMN (apps.fedoraproject.org/notifications) Neither FMN nor the "Watch commits" button on src.fp.o work for me. FMN just shows a page to set my contact information with no way to create filters; the "Watch commits" option doesn't work on src.fp.o (i.e. it doesn't send notifications for new commits) despite working on pagure.io. I believe the FMN brokenness has something to do with my account not existing in the old FAS2 instance, but I'm not sure about the src.fp.o issue. Is it some deliberate configuration difference or a bug? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: HTTP 500 - https://admin.fedoraproject.org/accounts/
On 22/07/28 12:06PM, Andrew Bauer wrote: > The backend server that is hosting admin.fedoraproject.org/accounts/ is > throwing an HTTP 500 SSL handshake error. I would recommend filing an infra ticket: https://pagure.io/fedora-infrastructure/new_issue. devel@ is not the correct place to report issues like this. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Important changes to software license information in Fedora packages (SPDX and more!)
On 22/07/29 11:19AM, Matthew Miller wrote: > New docs site for licensing and other legal topics > -- > > All documentation related to Fedora licensing has moved to a new > section in Fedora Docs, which you can find at: > > https://docs.fedoraproject.org/en-US/legal/ > Fedora license information in a structured format > - > > The âgoodâ (allowed) and âbadâ (not-allowed) licenses for Fedora are > now stored in a repository, using a simple structured file format for > each license (itâs TOML). You can find this at: > > https://gitlab.com/fedora/legal/fedora-license-data > > This data is then presented in easy tabular format in the > documentation, at: As part of this change, the data on which licenses are GPL-compatible seems to have been removed. Other projects were relying on this (e.g. [1]). Are there any plans to add it back? [1]: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#id5 -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Re: Important changes to software license information in Fedora packages (SPDX and more!)
On 22/07/31 12:57PM, Richard Fontana wrote: > I can go into why I don't think it's worthwhile, if there's interest. Feel free to go into more details if you'd like :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Important changes to software license information in Fedora packages (SPDX and more!)
Kevin Kofler via devel wrote: > Now you have to compare every word of the MIT license > with the very similar templates such as MIT, MIT-CMU, MIT-feh, etc., and > then figure out which one it actually is. If it is even one of these and not > some random mix of several variants (one sentence from here, one sentence > from there, âŠ). You're right. MIT/BSD License variants are a pain to deal with. In practice, they are mostly equivalent, so having to identify is a burden without a lot of benefit. Currently, there's MIT variants such as the HPND that aren't even part of the new license list, despite being explicitly listed on the old list and being used by packages like libX11[1]. As that license deprecated, it's not likely to cause issues when importing new packages, but it is still used by older packages. There are other examples of licenses missing from the new list that are already blocking new packages[2]. [1]: https://gitlab.com/fedora/legal/fedora-license-data/-/issues/1#note_969573331 [2]: https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/12#note_1045611169 > But that is how things work in practice. It is just impossible to read > through every source file and scan for copied snippets. They can even appear > in the middle of a file, with the license attached right there. So the > packager and the reviewer will both check the COPYING/LICENSE/LICENCE file > provided by upstream, then go exemplarily through a handful source files to > check that the copyright header and/or SPDX REUSE header matches that > license, and then declare that as the one License. This is onerous if you do it manually, but there are tools to make it a bit easier. You can use scancode-toolkit or licencecheck to scan the entire codebase. I believe the RH legal folks recommended the former at some point, but licensecheck is used by fedora-review and actually packaged in Fedora[^1]. The Legal docs recommend SPDX license-diff[3] and [4] to see if a certain license text exists in SPDX. [^1]: I wish luck to anyone who tries to package tries to package scancode. There are quite a few unpackaged dependencies... [3]: https://addons.mozilla.org/en-US/firefox/addon/spdx-license-diff/ [4]: https://tools.spdx.org/app/check_license/ -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Fedora-legal-list] Updating several packages to SPDX
Do Callway > SPDX license changes where there's a clear mapping and no other additions or removals still have to be announced? That wasn't my understanding. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Intent to retire: novacom-client, novacom-server
On Tuesday, August 16, 2022 Jonathan Dieter wrote: > So, unless I hear from someone who wants it within the next week and > has a plan on how to fix the current FTBFS bug[2], on August 23, I will > retire novacom-client[3] and novacom-server[4]. I would suggest just orphaning the packages. This way, anyone can pick up the packages themself through the src.fp.o web interface. The packages will get automatically retired in six weeks if nobody claims them. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
python-ntlm-auth License Correction
I've corrected the license of python-ntlm-auth from LGPLv3+ to MIT. It was relicensed upstream 5 years ago, but the previous maintainer never updated the License field. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: F37 side tag after branching point
On Tuesday, August 23, 2022 1:16:00 PM CDT Iñaki Ucar wrote: > We have a new R version sitting on a side tag (f37-build-side-55653) > for a few weeks now, where packages are being rebuilt as time permits. Can this perhaps be handled differently next time? I admit that I'm not familiar with the R ecosystem, so the answer may be no. Side tags are not meant to be open for this long. So far, this R rebuild has caused a lot of problems (see "The R stack in Rawhide is on fire"). What are the issues that prevent the rebuild from happening all at once? Can it be staged in COPR to make sure nothing will break? Can the packages be built all at once with a script? > Unfortunately, F37 is not rawhide anymore, so the question is whether > this side tag could be safely merged both in F37 and rawhide when it > is ready. I'll defer to the releng folks, but I think you should be able to merge the sidetag normally through the Bodhi interface, though it will be for f37 and not rawhide. You'll have to rebuild everything in rawhide. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts
On Tuesday, August 23, 2022 Lyes Saadi wrote: > Fortunately, Icon Development Kit is under CC0, so we're kinda saved > from a Licensing apocalypse (although, I have to admit that this is not > ideal). The CC0 has been banned for new packages in Fedora. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts
On Tuesday, August 23, 2022 Elliott Sales de Andrade wrote: > > The CC0 has been banned for new packages in Fedora. > > Banned for code, not content. Icons are not code. Good point! Thanks for the correction. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: sqlcipher soname change in rawhide
On Thursday, August 25, 2022 Carl George wrote: > [root@f38-container:~]# repoquery --repo > rawhide-source,rawhide-modular-source \ > > --quiet --queryformat '%{name}' --archlist src --whatrequires > > sqlcipher-devel > libgda > python-peewee > sqlitebrowser > [root@f38-container:~]# repoquery --repo > rawhide-source,rawhide-modular-source \ > > --quiet --queryformat '%{name}' --archlist src --whatrequires > > 'pkgconfig(sqlcipher)' > kmymoney > rust-libsqlite3-sys > skrooge You do not need to separately query for the Provides like this. If you keep the regular repository enabled and filter out the src packages after, the Provides are queried, as well. $ sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires sqlcipher-devel | grep '\.src$' | pkgname | sort -u kmymoney libgda python-peewee rust-libsqlite3-sys skrooge sqlitebrowser -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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
More Ansible license changes
Hi Fedorians, I'm back with more ansible license updates. Upstream, some of the community Ansible Collections have adopted the REUSE specification, which makes it much easier to determine the overall license. For collections that have adopted this, the license texts are all stored as files in one directory, instead of being spread out throughout the source tree as file headers. I would like to thank the upstream developers for working with me on this. The License tag of ansible-collection-community-general has changed from "GPLv3+ and BSD and Python" to "GPL-3.0-or-later AND BSD-2-Clause AND PSF-2.0 AND MIT". See https://src.fedoraproject.org/rpms/ansible-collection-community-general/pull-request/8. The License tag of ansible has changed from "GPLv3+" to "GPL-3.0-or-later AND Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND MPL-2.0 AND PSF-2.0". I cannot claim this to be 100% accurate, but I have done my best to determine the overall license. Note that ansible is a curated bundle of 103 Ansible collections, so this task is a bit difficult. See https://src.fedoraproject.org/rpms/ansible/pull-request/32. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: CPE Weekly Update - Week 34 2022
Aug 26, 2022 7:02:06 AM Michal Konecny : If you want to receive weekly reports by emails in the future, please subscribe to either https://communityblog.fedoraproject.org/ or https://discussion.fedoraproject.org/c/news/commblog/61. We will stop sending them in the future. Why is that? I appreciate getting the updates as a clean, plain text email that doesn't require clicking external links to read. Also, I'd venture that not every CentOS person is interested in the Fedora blog or forums. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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
ansible-collection-community-mysql License Change
Hi Fedorians, The license of ansible-collection-community-mysql has been updated from "GPLv3+ and Python" to "GPL-3.0-or-later AND PSF-2.0 AND BSD-2-Clause". See https://src.fedoraproject.org/rpms/ansible-collection-community-mysql/c/242bcaa709334c0a5ec0d78d1a2da3daaae532ce?branch=rawhide. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: problem creating a kernel module rpm package
On Sunday, August 28, 2022 Jerry Kiely wrote: > I did remove it and got the following result: > > rfpkg mockbuild -N --root fedora-36-x86_64-rpmfusion_free > sources file doesn't exist. Source files download skipped. > Failed to get repository name from Git url or pushurl > Failed to get ns from Git url or pushurl > Could not execute mockbuild: > /home/jerry/Workspace/Research/RPM/Modules/hid-ite8291r3-kmod is not a > valid repo > Try `spectool -g NAME_HERE.spec` and then rerun the rfpkg command. You have to download the sources to build the package. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Minizip renaming (Self-Contained Change proposal)
On 22/08/30 05:57PM, Zbigniew JÄdrzejewski-Szmek wrote: > On Mon, Aug 15, 2022 at 05:04:27PM -0400, Ben Cotton wrote: > > == Detailed Description == > > Upstream has changed the naming of the "minizip" package to > > "minizip-ng" and we should follow their naming so there is no > > confusion about which package is the right one. Upstream has also > > requested to rename the "minizip-compat" zlib subpackage to "minizip" > > which is the right naming for the package. > > > > The "minizip" and "minizip-compat" provides different shared libraries > > which prevent us from conflicting sonames. > > > > The plan behind this change can be put into x steps which will be > > completed separately and in the given order: > > > > ''NOTE: All of the Provides and Obsoletes will be added to the *-devel > > subpackages as well.'' > > > > 1) Create a new package "minizip-ng" which will `Provides: minizip = > > %{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)` > > Hi, > > it seems that Obsoletes does not work with boolean dependencies, > so the proposed for would not work. Correct. And even if it did work, you'd want to use the "with" operator not "and." > Instead, please use the standard form described by the Packaging > Guidelines: > Obsoletes: minizip < 3.0.3 That also won't work. If minizip-ng "Obsoletes: minizip < 3.0.3" and the new minizip package (the current minizip-compat) is 1.2.12-5, it will get Obsoleted by minizip-ng, which is unwanted. I would suggest adding "Epoch: 1" to the new minizip package (current minizip-compat) so it sorts above 3.0.3. You also shouldn't add "Provides: minizip = %{sameevr}`" to minizip-ng. It will break parallel installability with the new minizip package. Just wait to retire the current minizip (the one that's becoming minizip-ng) until step 2 has been completed. > > 2) Rebuild all of the packages that BuildRequire/Require "minizip" > > package to BuildRequire/Require new "minizip-ng" package Who will be doing this? How will it be done? > > 3) Retire the "minizip" package following the > > [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ > > Package Retirement Process] > > > > 4) Wait for the Fedora 40 when it's ensured that every user has > > updated at least to the Fedora 38. Remove the `Provides` and > > `Obsoletes` from the "minizip-ng" package > > FWIW, I prefer to keep those for a while. We don't officially support > this, but people do upgrades over more than two versions quite often, > and it's nice not to break that. I agree. If you use the approach I outlined above, removing the the Obsoletes won't be necessary in order to rename minizip-compat to minizip. > > 5) Rename the "minizip-compat" to the "minizip" package and add > > `Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat > > < 1.2.12` > > As already mentioned in the original discussion thread, this step is > risky. We generally try to follow upstream naming on packages, but > sometimes it's not possible for various technical reasons. This seems > to be one of those cases, because limitiations of Obsoletes mean that > we can't obsolete a subset of package versions. If you use the Epoch approach, this wouldn't be an issue. Also, what's the idea of waiting to do step 5 until Fedora 40? > Minizip-compat is not intended to be used by anything in the > distribution, so it's not a big deal if the package name is "wrong". > Thus, I think it's better to skip this last step and tell minizip > upstream that the we'll keep the "-compat" name for compatiblity > reasons. Maybe add a sentence of explanation to the package name. I agree. While it's possible to overcome the technical hurdles, this whole Change seems like more headache than its worth. Kevin and I had to deal with a similar situation of Obsoletes and Provides and boolean Requires with the ansible -> ansible-core split, and it's been a huge pain. This change is probably more complicated than that. It's likely that I've confused something in this email given the complexity of a renaming like this -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Non-responsive maintainer check for olem
Sep 2, 2022 5:36:41 AM Fabio Valentini : Does anybody know whether olem still wants to maintain their Fedora packages? I'm fairly sure that they no longer wish to maintain Fedora packages. I reached out to them about moby-engine and containerd at the end of May, and they said they no longer have time to maintain them. I have been maintaining those packages myself for a while. Side note: I have asked for co-maintainers for those packages a couple times, but so far, I have not found any. Perhaps one of the CoreOS people would be interested? It seems those packages are used a lot there based on the bug reports we've gotten. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Non-responsive maintainer check for olem
On Friday, September 2, 2022 Dusty Mabe wrote: > > Side note: I have asked for co-maintainers for those packages a couple > > times, but so far, I have not found any. Perhaps one of the CoreOS people > > would be interested? It seems those packages are used a lot there based > > on the bug reports we've gotten. > > Interesting. I opened an issue for us to discuss: > https://github.com/coreos/fedora-coreos-tracker/issues/1291 Thank you! I left to a comment to add more context. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to get a new gilab.com/fedora sub-project?
Sep 3, 2022 4:18:19 AM Miro HronÄok : We'd like to move https://gitlab.com/fberat/mass-prebuild/ into the Fedora namespace, ideally under something like: https://gitlab.com/fedora/packager-tools/ What do we need to do? Hi Miro, You have to file an infra ticket. See [1]. It would be nice if we could change the process to be more self-service (i.e. give Fedora contributors permissions to do this themselves). That could come along with guidelines of what may be put under the Fedora namespace and how subgroups should be organized. [1]: https://pagure.io/fedora-infrastructure/issues?search_pattern=Gitlab&status=all -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Conditional Patch line
On Monday, September 5, 2022 Richard W.M. Jones wrote: > I have a downstream patch[0] which -- I don't really understand why -- > breaks riscv64 builds but is necessary for primary Fedora arches. Is > it correct to do: > > %ifnarch riscv64 > Patch123: downstream.patch > %endif > > given that the package uses %autosetup and therefore doesn't have > explicit %patch lines. > > I think this means that if I build the SRPM on riscv64 then the > downstream patch wouldn't be included, meaning that SRPM would then > fail to build on other arches. In this particular case that doesn't > matter, but it feels wrong. Is there a recommended way to do this > (apart from fixing the patch)? Yes, conditionalizing Source or Patch lines is a bad idea. This exact case is explicitly forbidden by the guidelines[1]. There is also a guidelines PR to forbid any type of Source/Patch conditionaliztion[2]. [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/ #_no_arch_specific_sources_or_patches [2]: https://pagure.io/packaging-committee/pull-request/1163 If you don't want to add %patchX for every Patch, you can use regular `%setup -q` together with %autopatch, which allows more granular control than `%autosetup`. >From /usr/lib/rpm/macros: ``` # Apply patches using %autosetup configured SCM. # Typically used with no arguments to apply all patches in the order # introduced in the spec, but alternatively can be used to apply indvidual # patches in arbitrary order by passing them as arguments. # -vVerbose # -p Prefix strip (ie patch -p argument) # -m Apply patches with number >= min only (if no arguments) # -M Apply patches with number <= max only (if no arguments) %autopatch(vp:m:M:) %{lua: ``` -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Monday, September 5, 2022 Peter Robinson wrote: > it would probably be easier to join and become a packager by > packaging a random leaf package no one would use, then as a packager > pick up an random orphaned package that's in the core distro and then > just compromise the distro that way TBH. They wouldn't even need to pick up a core package. "Supplements: kernel" would get them far enough... -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [EPEL-devel] EPEL: packaging multiple versions and compat packages
On Monday, September 5, 2022 Mark E. Fuller wrote: > Can someone point me to a good resource on how (if permitted) I can make > appropriate compat(?) packages to allow for two major versions of the > same package to be available? > Is this allowed for EPEL? You can package compat packages as long as they don't conflict with anything in RHEL. EPEL packages may conflict with other EPEL packages, however. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote: > If > you want to enforce such a policy, find sponsors and buy devices for all > Fedora contributors. I kind of agree with this. See what PyPi is doing[1]. I don't think anyone who maintains one package should get one, but perhaps provenpackagers or those who maintain more than X packages should be required to have *some kind* of MFA enabled. [1]: https://pypi.org/security-key-giveaway/ -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Michael Catanzaro wrote: > Currently I do not have any 2FA enabled > on my Fedora account I have 2FA set up on my account and it works okay. You'd use `fkinit` instead of `kinit` that requires special setup[1] to work with 2FA. It doesn't work with the GOA kerberos integration. When authenticating with Fedora online services, there's a field for the token just like on any other site that supports 2FA. > because there's no way to disable it once enabled, > and I'm afraid something will break, so I'm not brave enough to opt in. > I highly doubt I'm alone here. I'd guess that Infrastructure could disable it for you if you enable it and then change your mind. [1]: https://fedoraproject.org/wiki/Infrastructure/ Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Inactive packagers to be removed after the F37 release
On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote: > > mobile device > > Requires proprietary Google services. As has already been said, that's not true. Google Authenticator is far from the only software that supports the TOTP standard. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
Aug 29, 2022 1:32:21 PM Ben Cotton : https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 == Summary == Cryptographic policies will be tightened in Fedora ''38''-39, SHA-1 signatures will no longer be trusted by default. Fedora ''38'' will do a "jump scare", introducing the change but then reverting it in time for Beta. Test your setup with TEST-FEDORA39 today and file bugs in advance so you won't get bit by Fedora ''38''-39. I think this is a bad idea. It's quite hostile to packagers. It will break rawhide for months and make it very difficult to stabilize the distro before the beta freeze or do any type of rebuild. It very well may affect other Changes. It will still cause untold problems even if you revert it before the beta freeze. Please test this in COPR (as Miro already said) or somewhere else instead of destabilizing the distro. You can analyze the COPR failures and report bugs just like the Python SIG does for new Python major versions. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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
CVE Tracking Bugs
Hi Fedorians, I think the security tracking bug filing process needs to be amended. The current process is quite frustrating for me and other contributors. This is especially bad for Go CVEs, which there are lot of. Red Hat Product Security creates a single tracking bug for Fedora{, EPEL} _and_ all Red Hat products and CCs a bunch of Fedora maintainers. They then create separate bugs for each package that they deem affected. The affected packages are oftened determined in a manner that appears overzealous and arbitrary. After the bugs are created, we get spammed with a bunch of notifications about private bugs, RH product errata, and various other things that are completely irrelevant to Fedora. These messages flood my Bugzilla mailbox and obscure actual issues that I need to address. I do not really care whether a Go CVE has been mitigated in Red Hat Advanced Cluster Management for Kubernetes 2.4 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8." --- Some particularly egregious examples: I maintain an Ansible kubernetes collection, and they reported it as vulnerable to some CVE with a specific Openshift component. The collection not vulnerable. They provided no actionable information, and the description was unclear. When I asked why it was reported, they said that the package "used OpenShift." A couple Go CVEs ago[^1], they created bugs against hundreds of Go libraries. They arbitrarily chose branches and packages. The bugs were not actionable by packagers of individual go libraries. Only applications that provide binaries need to be rebuilt. They were reported shortly before the F34 EOL, so we got a huge amount of emails after the bugs were automatically closed. In fact, a Go packager reported that these messages from the _security_ team DOSed their mail server. To their credit, they have fixed this issue after one of the other Go SIG people talked to them. Now, these bugs are only filed against the golang component. [^1]: Really, it was a couple Go releases ago. There are multiple CVEs reported with each Go release these days. Another time, their automation posted the exact same comment over 200 times. --- First and foremost, there needs to be a clear way for packagers to report problems with this process to prodsec. I don't think Fedora packagers should be CCed on these global trackers. We could create a separate "Security Response" component under the "Fedora" Bugzilla product to create tracker bugs for CVEs that affect multiple Fedora components, or we could ask prodsec to only CC Fedora maintainers on the child, package-level bugs. I guess I could acomplish what I'm proposing by filtering out mails with "X-Bugzilla-Product: Security Response" headers and not have gone on this rant, but I still think this needs to be addressed. Does anyone know how to reach prodsec about this? -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Thursday, September 8, 2022 Jaroslav Mracek wrote: > First of all we are not going to remove old DNF from the distribution. Isn't that what > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. says? -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
Sep 8, 2022 8:45:19 AM Maxwell G via devel : On Thursday, September 8, 2022 Jaroslav Mracek wrote: First of all we are not going to remove old DNF from the distribution. Isn't that what The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. says? Sorry, I was unclear. I meant to say that those two statements appear contradictory. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: CVE Tracking Bugs
On Thursday, September 8, 2022 Neal Gompa wrote: > Fedora maintainers are CC'd often on the parent bug to bypass the > private bug status while a bug is "under development". This has > happened a few times for me as a maintainer of crypto-adjacent > packages. That's a good point. I guess they could fix that by copying the description into the Fedora bug like Kevin said and/or making those "under development" security bugs private to all Fedora contributors instead of CCing specific people. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: CVE Tracking Bugs
On Friday, September 9, 2022 VĂt Ondruch wrote: > However, I think that the idea is that whatever should be said about the > CVE should be said in the main tracer. The fedora tracker should be used > just to not forget to fix this in Fedora. Why not both? We shouldn't have to reference two different bugs to figure out what's going on. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: libFLAC soname bump
On Mon Sep 12, 2022 at 11:29 AM CDT, Michel Alexandre Salim wrote: > > > > Would a proven packager be willing to take care of it? The new flac is > > now built in --target=f38-build-side-58420. libsndfile and audiofile > > need to be rebuilt next as some of the other packages depend on them. > > > > Sure, what do you need done? Just push an update from that sidetag, or > actually do some rebuilds as well? It sounds like they need all of those packages to be rebuilt: ``` $ koji list-tagged f38-build-side-58420 Build Tag Built by flac-1.4.0-1.fc38 f38-build-side-58420 mlichvar ``` -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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: CVE Tracking Bugs
On Mon Sep 12, 2022, VĂt Ondruch wrote: > > Dne 09. 09. 22 v 17:09 Maxwell G via devel napsal(a): > > On Friday, September 9, 2022 VĂt Ondruch wrote: > >> However, I think that the idea is that whatever should be said about the > >> CVE should be said in the main tracer. The fedora tracker should be used > >> just to not forget to fix this in Fedora. > > Why not both? We shouldn't have to reference two different bugs to figure > > out > > what's going on. > > > > > > First of all, what is the information you would like to put to either of > the trackers? Currently, the Fedora trackers contain > This is an automatically created tracking bug! It was created to ensure > that one or more security vulnerabilities are fixed in affected versions > of fedora-all. > > For comments that are specific to the vulnerability please use bugs filed > against the "Security Response" product referenced in the "Blocks" field. > > For more information see: > http://fedoraproject.org/wiki/Security/TrackingBugs > > When submitting as an update, use the fedpkg template provided in the next > comment(s). This will include the bug IDs of this tracking bug as well as > the relevant top-level CVE bugs. > > Please also mention the CVE IDs being fixed in the RPM changelog and the > fedpkg commit message. > > NOTE: this issue affects multiple supported versions of Fedora. While only > one tracking bug has been filed, please correct all affected versions at > the same time. If you need to fix the versions independent of each other, > you may clone this bug as appropriate. while the main bug has the actual description. I'm saying that the description should be copied to the Fedora tracker. -- Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Non-responsive maintainer check for golang-github-prometheus-common-devel
Hi Tobias, On Fri Sep 16, 2022, Tobias Zellner wrote: > some weeks ago I opened the bug > https://bugzilla.redhat.com/show_bug.cgi?id=2109630 I commented on your bug and submitted a fix. > Since there is no response to this bug, and following your guide lines > (https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/), > I opend Non-responsive maintainer check f a for this package For the record, the maintainer is fpokorny. Indeed, it seems that maintainer is unresponsive. They haven't had any recent activity in distgit. Other Go SIG members have been maintaining their packages for some time. They are also slated to be removed[1] from the packager group as part of the new Inactive Packager process[2]. This won't actually happen until the end of October, so feel free to continue with the standard Nonresponsive Maintainer process. [1]: https://pagure.io/find-inactive-packagers/issue/222 [2]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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
Fwd: Fwd: CVE Tracking Bugs
Hi Huzaifa, Thank you for your response and for getting it to me despite the issues with the mailing list. You have to subscribe[1] to the devel list to post to it. There has been a lot of good discussion about this on the ML since my original post[2]. I am forwarding this to the list to keep the community in the loop. I will respond in more detail later. [1]: https://lists.fedoraproject.org/admin/lists/devel.lists.fedoraproject.org/ [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ETPDV57SDTABYN6P6MGRZWRRCXVFLPZD/ Best, Maxwell Forwarded message from Huzaifa Sidhpurwala on Sat Sep 17, 2022: Hello Max, Pete tried to send this email to devel list, but it got rejected, so i thought i will forward this to you directly. -- Forwarded message - From: Pete Allor Date: Wed, Sep 14, 2022 at 6:47 AM Subject: Fwd: CVE Tracking Bugs To: Huzaifa Sidhpurwala , Przemyslaw Roguski , Clifford Perry Can you all get this email to Maxwell? -- Forwarded message - From: Date: Tue, Sep 13, 2022 at 9:13 PM Subject: Re: CVE Tracking Bugs To: Your message to the devel mailing-list was rejected for the following reasons: The message is not from a list member The original message as received by Mailman is attached. -- Forwarded message -- From: Pete Allor To: devel@lists.fedoraproject.org Cc: Bcc: Date: Tue, 13 Sep 2022 20:49:04 -0400 Subject: Re: CVE Tracking Bugs Maxwell, One of my folks pointed this post out to me today. From a ProdSec perspective, you can reach out directly to me. The PSIRT Team and their work on CVEs report up through me, so I will be glad to have a discussion with you and why my folks are not supporting you fully and how to fix that. I think the main thrust you are pointing to is that as the CNA for Fedora, we should not be mixing all Red Hat errata into the Fedora project. Meaning keeping them more separated and distinct. That may not address all concerns, but I think it would be a good starting point to keep the focus correct and distinct, not overload on messages and bring attention to what is critical / important so they are not missed. I am traveling this week. Can we set a meeting next week to discuss further? Pete *** Hi Fedorians, I think the security tracking bug filing process needs to be amended. The current process is quite frustrating for me and other contributors. This is especially bad for Go CVEs, which there are lot of. Red Hat Product Security creates a single tracking bug for Fedora{, EPEL} _and_ all Red Hat products and CCs a bunch of Fedora maintainers. They then create separate bugs for each package that they deem affected. The affected packages are oftened determined in a manner that appears overzealous and arbitrary. After the bugs are created, we get spammed with a bunch of notifications about private bugs, RH product errata, and various other things that are completely irrelevant to Fedora. These messages flood my Bugzilla mailbox and obscure actual issues that I need to address. I do not really care whether a Go CVE has been mitigated in Red Hat Advanced Cluster Management for Kubernetes 2.4 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.5 for RHEL 8" or "Red Hat Advanced Cluster Management for Kubernetes 2.6 for RHEL 8." --- Some particularly egregious examples: I maintain an Ansible kubernetes collection, and they reported it as vulnerable to some CVE with a specific Openshift component. The collection not vulnerable. They provided no actionable information, and the description was unclear. When I asked why it was reported, they said that the package "used OpenShift." A couple Go CVEs ago[^1], they created bugs against hundreds of Go libraries. They arbitrarily chose branches and packages. The bugs were not actionable by packagers of individual go libraries. Only applications that provide binaries need to be rebuilt. They were reported shortly before the F34 EOL, so we got a huge amount of emails after the bugs were automatically closed. In fact, a Go packager reported that these messages from the _security_ team DOSed their mail server. To their credit, they have fixed this issue after one of the other Go SIG people talked to them. Now, these bugs are only filed against the golang component. [^1]: Really, it was a couple Go releases ago. There are multiple CVEs reported with each Go release these days. Another time, their automation posted the exact same comment over 200 times. --- First and foremost, there needs to be a clear way for packagers to report problems with this process to prodsec. I don't think Fedora packagers should be CCed on these global trackers. We could create a separate "Security Response" component under the "Fedora" Bugzilla product to create tracker bugs for CVEs that affect multiple Fedora components, or we could ask prodsec to only CC Fedora maintainers on the child, package-
Re: update libXft to 2.3.6
Sep 18, 2022 Otto Liljalaakso : 18. syyskuuta 2022 1.53.45 GMT+03:00 Thomas Dickey kirjoitti: The release monitoring project for libXft (https://release-monitoring.org/project/1777/) doesn't appear to have noticed the release of 2.3.6 a week ago. Any clues on how to fix this? When I open that link, it shows 2.3.6 as the latest release. Maybe there just was some lag? It says "retrieved on 2022-09-10", though, strange that you still did not see it a week later. I fixed the release-monitoring.org listing earlier but then forgot to update the mailing list. The filtering and version prefix settings were incorrect. Once I sorted that out, the version showed up property. I apologize for the confusion! -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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: Non-responsive maintainer check for olem
On Fri Sep 2, 2022, Maxwell G via devel wrote: > > Sep 2, 2022 5:36:41 AM Fabio Valentini : > > > Does anybody know whether olem still wants to maintain their Fedora > > packages? > I'm fairly sure that they no longer wish to maintain Fedora packages. I > reached out to them about moby-engine and containerd at the end of May, > and they said they no longer have time to maintain them. I have been > maintaining those packages myself for a while. > > Side note: I have asked for co-maintainers for those packages a couple > times, but so far, I have not found any. Perhaps one of the CoreOS people > would be interested? It seems those packages are used a lot there based > on the bug reports we've gotten. It looks like the nonresponsive maintainer process is going to proceed. I've done some analysis of the Go packages that will be orphaned so the Go SIG can figured out how to handle this. This was done by hand, so please excuse any errors. The following packages are dependencies of golang-github-docker{,-cli} and/or containerd: 1. golang-github-hanwen-fuse 2. golang-github-fvbommel-sortorder 3. golang-github-containerd-nri 4. golang-github-moby-locker 5. golang-github-moby-term 6. golang-github-tonistiigi-rosetta 7. golang-github-google-containerregistry 8. golang-github-containerd-stargz-snapshotter (FTBFS) 9. golang-github-kyokomi-emoji is a dependency of hugo olem also maintained open-policy-agent and some of its dependencies: - open-policy-agent - golang-github-yashtewari-glob-intersection (open-policy-agent is the only dependent) - golang-uber-automaxprocs (dependency of both open-policy-agent and clash) This maintainer also maintained golang-github-jsonnet-bundler and golang-github-containerd-cni. These packages are leaves. I sent a separate message to the golang list about retiring these. I suppose we could just wait for it to happen automatically. Many of these libraries are out of date, but only one of them FTBFS (according to Koschei), which I'd consider pretty good. Updating these packages will likely require packaging a bunch of new dependencies. I think eclipseo has been doing some work on the docker side of things, though. Thanks for that! I have been keeping containerd and moby-engine up to date. moby-engine could use a cleanup. Currently, docker-proxy (github.com/moby/libnetwork), docker-init (bundled tini-static), dockerd (github.com/moby/moby), and the docker cli (github.com/docker/cli) are all part of the moby-engine package. This makes the specfile rather cumbersome. Ideally, it should be split up. I just haven't had the time to do so. docker cli should be straightforward. github.com/moby/libnetwork will soon be merged into github.com/moby/moby, so docker-proxy doesn't make sense to split out right now. For docker-init, we should investigate whether we could configure docker to look for the existing tini-static binary or at least create a symlink. It expects the binary to be installed to %{_libexecdir}/docker/docker-init. I am really not a fan of the bundled tini-static. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His ___ 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 proposal: Replace DNF with DNF5 (System-Wide Change proposal)
On Tue Sep 6, 2022, Ben Cotton wrote: > == Upgrade/compatibility impact == > The new DNF5 will obsolete `dnf`, `yum`, `dnf-automatic`, `yum-utils`, > and DNF plugins (core and extras). python3-dnf and LIBDNF (`libdnf`, > `python3-hawkey`) will be obsoleted by `fedora-obsolete-packages`. I am worried about removing python3-dnf this early. As far as I can tell, the new Python libdnf bindings are very much not a drop in replacement. There are a fair amount of tools and scripts that depend on python3-dnf. The change proposal listed some of them, but Ansible's dnf module is notably missing. Personal user scripts (such as the one I use for Go CVE rebuilds) and some of releng's scripts will also be broken. I don't think we should proceed with removing python3-dnf until the majority of the important dependent software is ported. (To be clear, I don't consider my personal scripts to be important dependent software :). In general, I think the "If DNF5 will be not ready to replace DNF" contingent needs to have definite criteria and the compatibility section needs to be expanded. Of course FESCo can do as they see fit, but I personally have qualms with approving a major change like this in advanced of an actual stable release and major testing, especially without a clear definition of when DNF5 is considered ready to replace DNF4. -- Best, Maxwell G (@gotmax23) Pronouns: He/Him/His 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