Re: F34: httpd package stuck in bodhi
On 12/10/21 00:37, Bojan Smojver via devel wrote: > Could someone with sufficient permissions please get httpd package unstuck in > bodhi? > > It's been sitting there for a few days, waiting to get to stable, but it > keeps getting kicked out, because some automated tests did not pass. The > package contains security fixes. > > Thanks, > > -- > > Bojan Maybe @adamwill knows better what's going on. Adding him in cc. As a side note, I noticed that httpd-2.4.51 updates are available for F34 and Rawhide, but F35 update is missing... you may have forgotten to submit it. Mattia___ 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: Retired Packages (Self-Contained Change proposal)
On Mon, Oct 11, 2021 at 09:55:05PM +0200, Miro Hrončok wrote: > On 11. 10. 21 21:41, Zbigniew Jędrzejewski-Szmek wrote: > >On Mon, Oct 11, 2021 at 08:17:36PM +0200, Miro Hrončok wrote: > >>On 11. 10. 21 20:14, Zbigniew Jędrzejewski-Szmek wrote: > >>>On Fri, Oct 08, 2021 at 08:21:51AM +0200, Miroslav Suchý wrote: > Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a): > >When are you supposed to run remove-retired-packages? > After the upgrade. > > > >If you run remove-retired-packages after the upgrade, you already > >managed to upgrade and nothing is broken, no? > > > Nothing is broken **now**. But it very often broke N+1 or N+2 > upgrade. I remember some package broken N+5 upgrade. And then you > (or some co-maintainer) hesitated to add it to > fedora-obsolete-packages because "it is too old". :) > >>> > >>>That's why we should keep packages in f-o-p for much longer than we > >>>currently do. There was just a thread about Jiri upgrading from F22 > >>>to a recent release. That procedure would have been made easier if > >>>f-o-p had more packages. > >>> > >>>What exactly is the rationale for constantly trimming the list in f-o-p? > >> > >>It is a huge mess to maintain. > > > >Hmm, I still don't get it. It's just a list that you append to at the end. > >Old entries don't need to be touched at all. > > The list is super huge and provenpackagers add stuff to the middle > of it or create duplicate entries. I've seen that happening even > when it's starting to get huge before the cleanup. The first issue should be fixed by better documentation. The second issue can be fixed by a test. I'd be happy to submit a PR if that'd help. Zbyszek ___ 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: Maxwell G (@gotmax23)
Maxwell G via devel kirjoitti 12.10.2021 klo 6.44: 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. Welcome to the Fedora Project, Maxwell! I hope you will enjoy your time here. 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. Thank you for the contribution. In cases like this, it is worth considering if the fork can be complete replacement for youtube-dl. If yt-dlp does everything youtube-dl does, just better, it could be a good idea to just replace the original with the improved version. Naturally, such replacement needs to be discussed with the current maintainers of the youtube-dl package first. So perhaps you want to tag the youtube-dl maintainers with a 'needinfo' in your review request and ask for their view on this? 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? [3]: https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#one_off_contributions Contribution of this kind if very much appreciated. The first steps of a new packager are currently quite rough, any ideas on how to make them easier are very welcome. In case you did not find it already, the source repository for the Package Maintainer Docs is this: https://pagure.io/fedora-docs/package-maintainer-docs You can file an issue or a pull request there. If the matter needs to be discussed first, the right place is here on the devel mailing list. Otto ___ 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
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
F34: httpd package stuck in bodhi
Could someone with sufficient permissions please get httpd package unstuck in bodhi? It's been sitting there for a few days, waiting to get to stable, but it keeps getting kicked out, because some automated tests did not pass. The package contains security fixes. Thanks, -- Bojan ___ 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
OCaml packages failing in ELN
The ELN package builds for the recent OCaml 4.13 update have mostly been failing, over and over. I finally took a look at some today; they're going to keep failing until a human intervenes. Rebuilding against Rawhide packages was supposed to fix this issue, but it doesn't fix the problem we're having this time: package builds that succeeded when they should have failed. The problem is that some packages low in the OCaml dependency tree were built successfully, but against packages that hadn't been rebuilt yet. The builds succeeded, so now those builds are sitting in the ELN repository, preventing the corresponding Rawhide builds from being used, but they have unresolvable dependencies. If building the packages in the same order they were built for Rawhide is infeasible, then we need a backtracking algorithm that detects build failures due to uninstallable packages and rebuilds those. Right now, at the very least, ocaml-dune needs such a rebuild. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20211010.n.0 changes
On Mon, Oct 11, 2021 at 9:06 AM Kevin Fenzi wrote: > Yeah, I was asked to untag that after untagging the latest python3.10 > package. > > See https://bugzilla.redhat.com/show_bug.cgi?id=2012513 > > This is what failed rawhide composes from 20211006 to 20211009. Got it. Thanks for satisfying my curiosity. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: jaxb* packages retired on f35+ (despite still being used)
Hi Endi, On Mon, Oct 11, 2021 at 8:58 AM Endi Sukma Dewata wrote: > Hi, some of JAXB packages failed to build possibly due to Maven/Ant changes > earlier this year, and since there has been no solution we decided to drop > JAXB dependency from Dogtag. We just barely managed to complete the work > recently, so unfortunately this could not be done much earlier before the > freeze deadline. JAXB was already dropped from RHEL, but I did not realize it > was still in use on F35. Sorry for the troubles. Don't lose any sleep over it. It turned out that the JAXB support wasn't needed, and removing dependencies on JAXB was fairly easy. It would be nice to have advance notice of packages disappearing, but the consequences this time weren't too bad. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reasons to subscribe to the package-announce list?
On Mon, Oct 11, 2021 at 09:45:59PM +0300, Otto Urpelainen wrote: > > Sure, making people aware of all the tooling that is available is good. But > the volume of messages in those lists is so large that I cannot believe it > is a good idea to subscribe, unless some kind of automatic processing is > implemented. Yeah, I don't personally see much use for package-announce anymore. It was started back in the day before rss feeds and other tools. scm-commits I think is still valuable as it's a record of all commits, so anyone interested can see and it's distributed so after the commits there's no way to rewite the emails. :) That said, subscribing to it by a human isn't too great now... the volume is just too much to even skim. Back in the old days I used to read they all the commits (and caught some fun bugs too), but its just not possible anymore. > So, I am no thinking of keeping the list of important mailing lists really > short, but the modify the "Find software you wish to package/maintain for > Fedora" a bit. It now starts from the assumption that each new maintainer is > going to add their very own package. Since it is also useful to help out > with the existing ones, that section could also explain how to get > notifications from interesting packages. There, both the Watch setting at > Package Sources and these mailing lists can be discussed. Yeah, that makes perfect sense. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
On 11. 10. 21 21:10, Neal Gompa wrote: On Wed, Sep 29, 2021 at 2:49 AM Kamil Paral wrote: On Mon, Sep 27, 2021 at 3:03 PM Miro Hrončok wrote: I've checked the status quo. Package "reproducer_reversed" starts supplementing package "rpm". "rpm" is installed, but "reproducer_reversed" is not. 1. dnf upgarde, no rpm update available: reproducer_reversed is not pulled in 2. dnf reinstall rpm: reproducer_reversed is pulled in 3. dnf downgrade rpm: reproducer_reversed is pulled in 4. dnf upgrade rpm: reproducer_reversed is pulled in 5. dnf upgrade, rpm update avilable: reproducer_reversed is pulled in Would this change proposal actually change the observed behavior? In what way? Based on Jaroslav's response, I'm afraid the new behavior will be that "reproducer_reversed" doesn't get pulled in in any of those cases (or perhaps just in case #2). But let's wait for Jaroslav to provide a definitive answer. It might be worth renaming the option "exclude_from_weak_autodetect" to imply its actual effect. Strawman idea: "weakexclude_unsatisfied_weakdeps_on_upgrade"? If I understand this right, it won't be only on upgrade. Also on reinstall, downgrade, etc. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Retired Packages (Self-Contained Change proposal)
On 11. 10. 21 21:41, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 11, 2021 at 08:17:36PM +0200, Miro Hrončok wrote: On 11. 10. 21 20:14, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Oct 08, 2021 at 08:21:51AM +0200, Miroslav Suchý wrote: Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a): When are you supposed to run remove-retired-packages? After the upgrade. If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? Nothing is broken **now**. But it very often broke N+1 or N+2 upgrade. I remember some package broken N+5 upgrade. And then you (or some co-maintainer) hesitated to add it to fedora-obsolete-packages because "it is too old". :) That's why we should keep packages in f-o-p for much longer than we currently do. There was just a thread about Jiri upgrading from F22 to a recent release. That procedure would have been made easier if f-o-p had more packages. What exactly is the rationale for constantly trimming the list in f-o-p? It is a huge mess to maintain. Hmm, I still don't get it. It's just a list that you append to at the end. Old entries don't need to be touched at all. The list is super huge and provenpackagers add stuff to the middle of it or create duplicate entries. I've seen that happening even when it's starting to get huge before the cleanup. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reasons to subscribe to the package-announce list?
Otto Urpelainen kirjoitti 11.10.2021 klo 21.45: Kevin Fenzi kirjoitti 10.10.2021 klo 23.49: On Sun, Oct 10, 2021 at 02:14:06PM +0300, Otto Urpelainen wrote: Hello, Package Maintainer Docs currently recommend joining the package-announce mailing list in two places [1,2], describing it as follows: You should also consider joining the package-announce mailing list — The commits mailing list gets notifications on all commits in any package in the Fedora repository. This is a very high traffic mailing list. The Fedora package database sends commit mails for packages you (co-)maintain. Odd. thats... not the right description. Thats the description for the scm-commits list? package-announce gets updates announcements of all the packages going to stable updates through bodhi. Thank you for this information. This explains why I saw only Bodhi updates in the package-announce archives. I wonder, would it be better to drop this recommendation? Instead, it could be recommended to go to Package Sources and adjust the Watch setting for individual packages as needed? The paragraph quoted above is already kind of recommending that approach in the last sentence. What are the use cases where subscribing to the package-announce mailing list is better than watching individual packages? Are the use cases common enough that the mailing list deserves to be called "important" and be recommended for everybody interested in Fedora packaging? Yes, I think it might be worth mentioning these lists, but not reccomending subscribing unless interested. Something like: There are some completely optional lists that contain posts about all packages: scm-commits, which has the commits for every package in fedora posted to it, and package-announce, which has every stable update notice posted to it as packages are pushed stable. Both of these are very high traffic mailing lists and are only suggested if you have the time and energy to watch all the changes going on in fedora packages. Or something like that. Sure, making people aware of all the tooling that is available is good. But the volume of messages in those lists is so large that I cannot believe it is a good idea to subscribe, unless some kind of automatic processing is implemented. So, I am no thinking of keeping the list of important mailing lists really short, but the modify the "Find software you wish to package/maintain for Fedora" a bit. It now starts from the assumption that each new maintainer is going to add their very own package. Since it is also useful to help out with the existing ones, that section could also explain how to get notifications from interesting packages. There, both the Watch setting at Package Sources and these mailing lists can be discussed. Here is a try at implementing these ideas: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/41# ___ 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: Retired Packages (Self-Contained Change proposal)
On Mon, Oct 11, 2021 at 08:17:36PM +0200, Miro Hrončok wrote: > On 11. 10. 21 20:14, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Oct 08, 2021 at 08:21:51AM +0200, Miroslav Suchý wrote: > >>Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a): > >>>When are you supposed to run remove-retired-packages? > >>After the upgrade. > >>> > >>>If you run remove-retired-packages after the upgrade, you already > >>>managed to upgrade and nothing is broken, no? > >> > >> > >>Nothing is broken **now**. But it very often broke N+1 or N+2 > >>upgrade. I remember some package broken N+5 upgrade. And then you > >>(or some co-maintainer) hesitated to add it to > >>fedora-obsolete-packages because "it is too old". :) > > > >That's why we should keep packages in f-o-p for much longer than we > >currently do. There was just a thread about Jiri upgrading from F22 > >to a recent release. That procedure would have been made easier if > >f-o-p had more packages. > > > >What exactly is the rationale for constantly trimming the list in f-o-p? > > It is a huge mess to maintain. Hmm, I still don't get it. It's just a list that you append to at the end. Old entries don't need to be touched at all. Zbyszek ___ 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
Summary/Minutes from today's FESCo Meeting (2021-10-11)
Minutes: https://meetbot.fedoraproject.org/fedora-meeting/2021-10-11/fesco.2021-10-11-19.00.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting/2021-10-11/fesco.2021-10-11-19.00.txt Log: https://meetbot.fedoraproject.org/fedora-meeting/2021-10-11/fesco.2021-10-11-19.00.log.html Meeting summary --- * init process (zbyszek, 19:00:15) * #2667 F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (zbyszek, 19:02:09) APPROVED (+7, 0, 0) (Four votes in the ticket, three votes in the meeting.) * #2672 Nonresponsive group: @java-maint-sig (zbyszek, 19:04:37) * AGREED: @java-maint-sig is declared "nonresponsive", and the plan (pasted below) will be implemented. (+7, 0, 0) (zbyszek, 19:12:59) 1. We remove all BZ assignee overrides to @java-maint-sig. This is a must. 2. We remove access of @java-maint-sig from all packages. 3. We ask the members of the group if they want to admin the list/BZ account. - We give it to the volunteer. - We empty the group and cancel the BZ account/list if nobody shows up. 4. We don't orphan the packages, they have some "de jure" maintainers. 5. Replace the description of pagure.io/java-maint-sig * Next week's chair (zbyszek, 19:13:21) * ACTION: zbyszek will chair next meeting (zbyszek, 19:13:56) * Open Floor (zbyszek, 19:14:01) * https://qa.fedoraproject.org/blockerbugs/milestone/35/final/buglist (zbyszek, 19:17:46) Meeting ended at 19:20:02 UTC. Action Items * zbyszek will chair next meeting Action Items, by person --- * zbyszek * zbyszek will chair next meeting ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)
On Wed, Sep 29, 2021 at 2:49 AM Kamil Paral wrote: > > On Mon, Sep 27, 2021 at 3:03 PM Miro Hrončok wrote: >> >> I've checked the status quo. >> >> Package "reproducer_reversed" starts supplementing package "rpm". "rpm" is >> installed, but "reproducer_reversed" is not. >> >> 1. dnf upgarde, no rpm update available: reproducer_reversed is not pulled in >> 2. dnf reinstall rpm: reproducer_reversed is pulled in >> 3. dnf downgrade rpm: reproducer_reversed is pulled in >> 4. dnf upgrade rpm: reproducer_reversed is pulled in >> 5. dnf upgrade, rpm update avilable: reproducer_reversed is pulled in >> >> Would this change proposal actually change the observed behavior? In what >> way? > > > Based on Jaroslav's response, I'm afraid the new behavior will be that > "reproducer_reversed" doesn't get pulled in in any of those cases (or perhaps > just in case #2). But let's wait for Jaroslav to provide a definitive answer. > It might be worth renaming the option "exclude_from_weak_autodetect" to imply its actual effect. Strawman idea: "weakexclude_unsatisfied_weakdeps_on_upgrade"? -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Reasons to subscribe to the package-announce list?
Kevin Fenzi kirjoitti 10.10.2021 klo 23.49: On Sun, Oct 10, 2021 at 02:14:06PM +0300, Otto Urpelainen wrote: Hello, Package Maintainer Docs currently recommend joining the package-announce mailing list in two places [1,2], describing it as follows: You should also consider joining the package-announce mailing list — The commits mailing list gets notifications on all commits in any package in the Fedora repository. This is a very high traffic mailing list. The Fedora package database sends commit mails for packages you (co-)maintain. Odd. thats... not the right description. Thats the description for the scm-commits list? package-announce gets updates announcements of all the packages going to stable updates through bodhi. Thank you for this information. This explains why I saw only Bodhi updates in the package-announce archives. I wonder, would it be better to drop this recommendation? Instead, it could be recommended to go to Package Sources and adjust the Watch setting for individual packages as needed? The paragraph quoted above is already kind of recommending that approach in the last sentence. What are the use cases where subscribing to the package-announce mailing list is better than watching individual packages? Are the use cases common enough that the mailing list deserves to be called "important" and be recommended for everybody interested in Fedora packaging? Yes, I think it might be worth mentioning these lists, but not reccomending subscribing unless interested. Something like: There are some completely optional lists that contain posts about all packages: scm-commits, which has the commits for every package in fedora posted to it, and package-announce, which has every stable update notice posted to it as packages are pushed stable. Both of these are very high traffic mailing lists and are only suggested if you have the time and energy to watch all the changes going on in fedora packages. Or something like that. Sure, making people aware of all the tooling that is available is good. But the volume of messages in those lists is so large that I cannot believe it is a good idea to subscribe, unless some kind of automatic processing is implemented. So, I am no thinking of keeping the list of important mailing lists really short, but the modify the "Find software you wish to package/maintain for Fedora" a bit. It now starts from the assumption that each new maintainer is going to add their very own package. Since it is also useful to help out with the existing ones, that section could also explain how to get notifications from interesting packages. There, both the Watch setting at Package Sources and these mailing lists can be discussed. Otto ___ 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: Retired Packages (Self-Contained Change proposal)
On 11. 10. 21 20:14, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Oct 08, 2021 at 08:21:51AM +0200, Miroslav Suchý wrote: Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a): When are you supposed to run remove-retired-packages? After the upgrade. If you run remove-retired-packages after the upgrade, you already managed to upgrade and nothing is broken, no? Nothing is broken **now**. But it very often broke N+1 or N+2 upgrade. I remember some package broken N+5 upgrade. And then you (or some co-maintainer) hesitated to add it to fedora-obsolete-packages because "it is too old". :) That's why we should keep packages in f-o-p for much longer than we currently do. There was just a thread about Jiri upgrading from F22 to a recent release. That procedure would have been made easier if f-o-p had more packages. What exactly is the rationale for constantly trimming the list in f-o-p? It is a huge mess to maintain. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Retired Packages (Self-Contained Change proposal)
On Fri, Oct 08, 2021 at 08:21:51AM +0200, Miroslav Suchý wrote: > Dne 07. 10. 21 v 18:23 Miro Hrončok napsal(a): > >When are you supposed to run remove-retired-packages? > After the upgrade. > > > >If you run remove-retired-packages after the upgrade, you already > >managed to upgrade and nothing is broken, no? > > > Nothing is broken **now**. But it very often broke N+1 or N+2 > upgrade. I remember some package broken N+5 upgrade. And then you > (or some co-maintainer) hesitated to add it to > fedora-obsolete-packages because "it is too old". :) That's why we should keep packages in f-o-p for much longer than we currently do. There was just a thread about Jiri upgrading from F22 to a recent release. That procedure would have been made easier if f-o-p had more packages. What exactly is the rationale for constantly trimming the list in f-o-p? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-35-20211011.n.0 compose check report
No missing expected images. Failed openQA tests: 4/204 (x86_64), 2/141 (aarch64) New failures (same test not failed in Fedora-35-20211010.n.0): ID: 1023890 Test: x86_64 universal upgrade_2_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1023890 ID: 1023905 Test: x86_64 universal upgrade_minimal_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1023905 Old failures (same test failed in Fedora-35-20211010.n.0): ID: 1023707 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1023707 ID: 1023723 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1023723 ID: 1023819 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1023819 ID: 1023925 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1023925 Soft failed openQA tests: 3/204 (x86_64), 3/141 (aarch64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-35-20211010.n.0): ID: 1023681 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1023681 ID: 1023796 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1023796 Old soft failures (same test soft failed in Fedora-35-20211010.n.0): ID: 1023724 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1023724 ID: 1023735 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1023735 ID: 1023808 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1023808 ID: 1023826 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1023826 Passed openQA tests: 197/204 (x86_64), 136/141 (aarch64) New passes (same test not passed in Fedora-35-20211010.n.0): ID: 1023647 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1023647 ID: 1023660 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1023660 ID: 1023664 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1023664 ID: 1023710 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1023710 ID: 1023753 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1023753 ID: 1023760 Test: aarch64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1023760 ID: 1023928 Test: aarch64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1023928 Installed system changes in test x86_64 Server-boot-iso install_default: System load changed from 0.08 to 0.35 Previous test data: https://openqa.fedoraproject.org/tests/1022189#downloads Current test data: https://openqa.fedoraproject.org/tests/1023615#downloads Installed system changes in test x86_64 Workstation-live-iso install_default@uefi: Mount /run/user/983 appeared since previous compose 2 services(s) added since previous compose: user-runtime-dir@983.service, user@983.service System load changed from 0.33 to 1.15 Previous test data: https://openqa.fedoraproject.org/tests/1022250#downloads Current test data: https://openqa.fedoraproject.org/tests/1023676#downloads Installed system changes in test x86_64 Workstation-live-iso install_default_upload: System load changed from 0.99 to 0.45 Previous test data: https://openqa.fedoraproject.org/tests/1022252#downloads Current test data: https://openqa.fedoraproject.org/tests/1023678#downloads Installed system changes in test x86_64 KDE-live-iso install_default@uefi: System load changed from 0.87 to 0.69 Previous test data: https://openqa.fedoraproject.org/tests/1022276#downloads Current test data: https://openqa.fedoraproject.org/tests/1023702#downloads Installed system changes in test x86_64 KDE-live-iso install_default_upload: System load changed from 1.21 to 0.85 Previous test data: https://openqa.fedoraproject.org/tests/1022277#downloads Current test data: https://openqa.fedoraproject.org/tests/1023703#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi: Used swap changed from 9 MiB to 5 MiB Previous test data: https://openqa.fedoraproject.org/tests/1022294#downloads Current test data: https://openqa.fedoraproject.org/tests/1023720#downloads Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload: System load changed from 0.69 to 0.90 Previous test data: https://openqa.fedoraproject.org/tests/1022296#downloads Current test data: https://openqa.fedoraproject.org/tests/1023722#downloads I
Re: Fedora rawhide compose report: 20211010.n.0 changes
On Mon, Oct 11, 2021 at 11:37:41PM +0900, Mamoru TASAKA wrote: > Jerry James wrote on 2021/10/11 23:26: > > On Sun, Oct 10, 2021 at 7:26 AM Fedora Rawhide Report > > wrote: > > > = DOWNGRADED PACKAGES = > > > Package: python-pip-21.2.3-2.fc36 > > > Old package: python-pip-21.2.3-4.fc36 > > > Summary: A tool for installing and managing Python packages > > > RPMs: python-pip-doc python-pip-wheel python3-pip > > > Size: 3.56 MiB > > > Size change: 290.52 KiB > > > > What happened here? The 21.2.3-2 build is from August 16. > > > > $ koji list-history --build python-pip-21.2.3-4.fc36 > Thu Oct 7 05:24:37 2021 python-pip-21.2.3-4.fc36 tagged into > f36-updates-candidate by cstratak > Thu Oct 7 05:24:42 2021 python-pip-21.2.3-4.fc36 tagged into > f36-signing-pending by bodhi > Thu Oct 7 05:36:03 2021 python-pip-21.2.3-4.fc36 untagged from > f36-signing-pending by autopen > Thu Oct 7 05:36:03 2021 python-pip-21.2.3-4.fc36 tagged into > f36-updates-testing-pending by autopen > Thu Oct 7 05:37:00 2021 python-pip-21.2.3-4.fc36 tagged into f36 by bodhi > Thu Oct 7 05:37:04 2021 python-pip-21.2.3-4.fc36 tagged into eln by > distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org [still active] > Thu Oct 7 05:37:06 2021 python-pip-21.2.3-4.fc36 untagged from > f36-updates-testing-pending by bodhi > Thu Oct 7 05:37:07 2021 python-pip-21.2.3-4.fc36 untagged from > f36-updates-candidate by bodhi > Sun Oct 10 10:57:01 2021 python-pip-21.2.3-4.fc36 untagged from f36 by kevin > > So python-pip-21.2.3-4.fc36 is untagged (I don't know the reason) and > the latest package for python-pip is now 21.2.3-2.fc36 Yeah, I was asked to untag that after untagging the latest python3.10 package. See https://bugzilla.redhat.com/show_bug.cgi?id=2012513 This is what failed rawhide composes from 20211006 to 20211009. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: jaxb* packages retired on f35+ (despite still being used)
Hi, some of JAXB packages failed to build possibly due to Maven/Ant changes earlier this year, and since there has been no solution we decided to drop JAXB dependency from Dogtag. We just barely managed to complete the work recently, so unfortunately this could not be done much earlier before the freeze deadline. JAXB was already dropped from RHEL, but I did not realize it was still in use on F35. Sorry for the troubles. -- Endi S. Dewata ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-IoT-36-20211011.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 3/16 (x86_64), 1/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20211010.0): ID: 1023585 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server URL: https://openqa.fedoraproject.org/tests/1023585 ID: 1023599 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition URL: https://openqa.fedoraproject.org/tests/1023599 Old failures (same test failed in Fedora-IoT-36-20211010.0): ID: 1023591 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1023591 ID: 1023606 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1023606 Passed openQA tests: 13/16 (x86_64), 14/15 (aarch64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: System load changed from 0.27 to 0.45 Previous test data: https://openqa.fedoraproject.org/tests/1022546#downloads Current test data: https://openqa.fedoraproject.org/tests/1023595#downloads Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.67 to 0.82 Previous test data: https://openqa.fedoraproject.org/tests/1022551#downloads Current test data: https://openqa.fedoraproject.org/tests/1023600#downloads -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora rawhide compose report: 20211010.n.0 changes
Jerry James wrote on 2021/10/11 23:26: On Sun, Oct 10, 2021 at 7:26 AM Fedora Rawhide Report wrote: = DOWNGRADED PACKAGES = Package: python-pip-21.2.3-2.fc36 Old package: python-pip-21.2.3-4.fc36 Summary: A tool for installing and managing Python packages RPMs: python-pip-doc python-pip-wheel python3-pip Size: 3.56 MiB Size change: 290.52 KiB What happened here? The 21.2.3-2 build is from August 16. $ koji list-history --build python-pip-21.2.3-4.fc36 Thu Oct 7 05:24:37 2021 python-pip-21.2.3-4.fc36 tagged into f36-updates-candidate by cstratak Thu Oct 7 05:24:42 2021 python-pip-21.2.3-4.fc36 tagged into f36-signing-pending by bodhi Thu Oct 7 05:36:03 2021 python-pip-21.2.3-4.fc36 untagged from f36-signing-pending by autopen Thu Oct 7 05:36:03 2021 python-pip-21.2.3-4.fc36 tagged into f36-updates-testing-pending by autopen Thu Oct 7 05:37:00 2021 python-pip-21.2.3-4.fc36 tagged into f36 by bodhi Thu Oct 7 05:37:04 2021 python-pip-21.2.3-4.fc36 tagged into eln by distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org [still active] Thu Oct 7 05:37:06 2021 python-pip-21.2.3-4.fc36 untagged from f36-updates-testing-pending by bodhi Thu Oct 7 05:37:07 2021 python-pip-21.2.3-4.fc36 untagged from f36-updates-candidate by bodhi Sun Oct 10 10:57:01 2021 python-pip-21.2.3-4.fc36 untagged from f36 by kevin So python-pip-21.2.3-4.fc36 is untagged (I don't know the reason) and the latest package for python-pip is now 21.2.3-2.fc36 Regards, Mamoru ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20211011.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 8/206 (x86_64), 11/141 (aarch64) New failures (same test not failed in Fedora-Rawhide-20211010.n.0): ID: 1023289 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1023289 ID: 1023322 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1023322 ID: 1023330 Test: x86_64 KDE-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1023330 ID: 1023363 Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1023363 ID: 1023375 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1023375 ID: 1023389 Test: aarch64 Server-dvd-iso install_blivet_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1023389 ID: 1023415 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1023415 ID: 1023422 Test: aarch64 Server-raw_xz-raw.xz base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1023422 ID: 1023453 Test: aarch64 Cloud_Base-qcow2-qcow2 base_package_install_remove@uefi URL: https://openqa.fedoraproject.org/tests/1023453 ID: 1023532 Test: aarch64 universal install_serial_console@uefi URL: https://openqa.fedoraproject.org/tests/1023532 Old failures (same test failed in Fedora-Rawhide-20211010.n.0): ID: 1023305 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1023305 ID: 1023319 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1023319 ID: 1023327 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1023327 ID: 1023343 Test: x86_64 Silverblue-dvd_ostree-iso evince URL: https://openqa.fedoraproject.org/tests/1023343 ID: 1023418 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1023418 ID: 1023441 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi URL: https://openqa.fedoraproject.org/tests/1023441 ID: 1023536 Test: aarch64 universal install_cyrillic_language@uefi URL: https://openqa.fedoraproject.org/tests/1023536 ID: 1023541 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1023541 ID: 1023547 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1023547 Soft failed openQA tests: 2/141 (aarch64), 3/206 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20211010.n.0): ID: 1023430 Test: aarch64 Workstation-raw_xz-raw.xz install_arm_image_deployment_upload@uefi URL: https://openqa.fedoraproject.org/tests/1023430 Old soft failures (same test soft failed in Fedora-Rawhide-20211010.n.0): ID: 1023301 Test: x86_64 Workstation-live-iso gedit URL: https://openqa.fedoraproject.org/tests/1023301 ID: 1023344 Test: x86_64 Silverblue-dvd_ostree-iso gedit URL: https://openqa.fedoraproject.org/tests/1023344 ID: 1023355 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1023355 ID: 1023448 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1023448 Passed openQA tests: 195/206 (x86_64), 128/141 (aarch64) New passes (same test not passed in Fedora-Rawhide-20211010.n.0): ID: 1023235 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/1023235 ID: 1023436 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi URL: https://openqa.fedoraproject.org/tests/1023436 ID: 1023440 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1023440 ID: 1023442 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1023442 ID: 1023483 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1023483 ID: 1023486 Test: x86_64 universal install_btrfs URL: https://openqa.fedoraproject.org/tests/1023486 ID: 1023559 Test: aarch64 universal install_multi@uefi URL: https://openqa.fedoraproject.org/tests/1023559 ID: 1023572 Test: aarch64 universal install_european_language@uefi URL: https://openqa.fedoraproject.org/tests/1023572 Installed system changes in test x86_64 Everything-boot-iso install_default: System load changed from 0.38 to 0.24 Previous test data: https://openqa.fedoraproject.org/tests/1021867#downloads Current test data: https://openqa.fedoraproject.org/tests/1023294#downloads Installed system changes in test
Re: Fedora rawhide compose report: 20211010.n.0 changes
On Sun, Oct 10, 2021 at 7:26 AM Fedora Rawhide Report wrote: > = DOWNGRADED PACKAGES = > Package: python-pip-21.2.3-2.fc36 > Old package: python-pip-21.2.3-4.fc36 > Summary: A tool for installing and managing Python packages > RPMs: python-pip-doc python-pip-wheel python3-pip > Size: 3.56 MiB > Size change: 290.52 KiB What happened here? The 21.2.3-2 build is from August 16. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: llvm 13.0.0-final ABI Change
On 10/9/21 5:33 AM, Fabio Valentini wrote: On Fri, Oct 1, 2021 at 5:03 AM Tom Stellard wrote: Hi, I'm going to start packaging LLVM 13.0.0-final for rawhide and f35. The 13.0.0-final release has a different ABI than 13.0.0-rc1, so I will be rebuilding the following packages as part of the update: castxml doxygen gnome-builder mesa openshadinglanguage qt-creator qt6-qttools zig It looks like the llvm 13 update for rawhide is stuck because of failed gating tests, and no update for Fedora 35 has been submitted yet ... (and the other issue is that the list of packages that need to be rebuilt seems to be incomplete). Do you still plan to submit LLVM 13 final for Fedora rawhide / 35 (maybe with a freeze exception? it would be great to have the "stable" versions on images and in release repos instead of the pre-release RC builds). I've fixed the gating test, but I ran into a circular dependency issue with mesa that is blocking the rest of the update. I'll send another email when I have that fixed, and I'm ready to do the update in rawhide. -Tom (I'm slightly biased, since apparently the LLVM 13 update might finally fix compilation issues with certain Rust packages, which I've been waiting for for months. :) ) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora 35 compose report: 20211011.n.0 changes
OLD: Fedora-35-20211010.n.0 NEW: Fedora-35-20211011.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:0 Upgraded packages: 0 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 0 B Size of downgraded packages: 0 B Size change of upgraded packages: 0 B Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = = DOWNGRADED PACKAGES = ___ 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: Onboarding package
On Wed, Oct 6, 2021 at 5:21 AM Vít Ondruch wrote: > > > Dne 06. 10. 21 v 9:44 Zbigniew Jędrzejewski-Szmek napsal(a): > > On Wed, Oct 06, 2021 at 09:39:46AM +0200, Vít Ondruch wrote: > >> Dne 05. 10. 21 v 18:04 Stephen John Smoogen napsal(a): > >>> On Tue, 5 Oct 2021 at 11:28, Matthew Miller > >>> wrote: > On Mon, Oct 04, 2021 at 09:17:30PM +0200, Vitaly Zaitsev via devel wrote: > >> Is this really necessary? > > Yes. Because anyone can add something like this: > > %post > > rm -rf / > > > > And it will destroy the installed system or even the hardware. > Yeah, but... that's not going get through the PR process? In fact, that > specific thing should fail in CI before a human gets to it even. > > Overall, we put a lot of trust in maintainers. I don't see this > _particular_ > route as a likely one for violating that trust. > > >>> I think part of the problem is that I don't think the proposal has > >>> enough flesh on its bones for people not to see it causing all kinds > >>> of problems somewhere. Or vice versa seeing not enough to see it being > >>> worthwhile for a beginner. [For many a developer, PR's aren't that > >>> interesting to most developers and not what they think about when > >>> looking at packaging. Running fedpkg and making a spec file work on my > >>> system and through the complicated koji+bodhi+mbs+.. stack is real > >>> packaging.] So we need a real proposal with an end to end idea of what > >>> is being done, what is to be learned, and how it is to be 'watched' by > >>> real developers to make sure people are learning things. > >>> > >>> > >> This was proposed in the "release early, release often" spirit. So I > >> am glad for the generally positive feedback for this idea and I also > >> appreciate the concerns which were risen. > >> > >> And as I said, this targets the newcomers, so start with the PR is > >> probably the right thing to do. But even "start with PR" has more > >> degrees of freedom, e.g. should the contributors modify the > >> changelog manually or should the `%autorelease` / `%autochangelog` > >> be used as proposed by Matt? Maybe this could be two scenarios after > >> all. But it is hard to judge where the line is between being useful > >> to learn something and being tedious, boring, unattractive or > >> discouraging. > > I'd very much lean on the side of %autorelease/%autochangelog. > > That workflow isn't perfect yet, but it's certainly the feature, and > > in general, newcomers should learn the new workflows. > > (There's also the issue raised by Matt that with traditional > > %changelog pretty much each and every parallel pull request would > > conflict.) > > > I have put together very naive concept here: > > https://fedorapeople.org/cgit/vondruch/public_git/dummy-onboarding-contributors-pr.git/ > > https://copr.fedorainfracloud.org/coprs/vondruch/dummy-onboarding-contributors-pr/ > > However, with more traffic commits like [1] will conflict anyway. > Matthew recommended that it be a functional package and others have suggested that it should also be part of a Badge series. I think we could make this work fairly easily: 1) We write a simple application to include in the package. Its purpose will be to display a web page that lists the names of all of the CONTRIBUTORS up to this point and then, after 30 seconds, automatically redirects to the badge-claim link. 2) The application would also be designed to throw an error if the binary is located anywhere but /usr/bin. Essentially "you built the package and were able to install it successfully". 3) The application would generate the list of CONTRIBUTORS from a drop directory (CONTRIBUTORS.d) instead of a single file, so we can avoid the potential conflicts. ___ 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: Modularity: Demodularizing packages
On Mon, Oct 11, 2021 at 8:46 AM Petr Pisar wrote: > > Hello packagers, > > I'm glad to announce that now it's possible to move a package back from > a module to a nonmodular repository. > This is awesome! Thank you so much for this! :) -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: leap from f22 to f34 fairytale
I think if you jump more than 2 versions at a time the packages obsoleted by fedora-obsolete-packages might not be picked up properly because it only holds packages for about 2 versions before they are removed from it. So jumping from F26 to F33 directly might miss the obsoletes from F27-F31ish. -Ian On Mon, Oct 11, 2021 at 1:49 PM JT wrote: > Nice. I did an update from F26-F33 last year doing one version at time > instead of jumping more than one version... and had no major issues. I > wonder how far back its possible to start from and walk through the version > updates. > > On Mon, Oct 11, 2021 at 3:55 AM Jiri Vanek wrote: > >> Hello good people! >> >> I would like to thanx to everybody for amazing work in fedora, for >> keeping it alive, and updatable. >> >> In friday I had found an old laptop running f22 and decided to try a leap >> update to f34. It was not just default inntall, there was vlc and much >> more "unknown" comonents. >> Well, transaction failed on python stack, but no surprise here (f31 ahd >> python2->python3?). >> So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. >> Transaction passed. Update passed, and system started and was alive. >> Although the system was behaving terribly (there were experiemtnal patches >> in graphic drivers and also >> gnomeshell was weird, not speaking about wayalnd), it was stable enough >> to make another huge leap. F27->f31 faile dagain on pythn stack, but only >> because of four packages. >> f27->f30 passed again. UNluckily --nogpg check was no longer transferable >> from download to reboot+update. But gpgcheck=1 in active repos fixed it.[1] >> in and in the morning a running shining smooth quick and super stbale >> system was there. >> f30-> f34 died again on python stack.. (yah, dnf and freinds should stop >> using that or keep embedded interpreter) >> f30->31 passed again to even more shining and more working system. >> f31->f33 (yup, that was typo, but found it to late in trasnaction) passed >> again withot issues. >> >> Thanx a lot! II was never expecting such leaps would work so smoothly! >> >>J. >> >> >> [1] https was a culprint herem causing the keys impossible to downlaod. >> in f31, gpgcheck could be enabled again. >> -- >> Jiri Vanek Mgr. >> Principal QA Software Engineer >> Red Hat Inc. >> +420 775 39 01 09 >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org >> Do not reply to spam on the list, report it: >> https://pagure.io/fedora-infrastructure >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ 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: leap from f22 to f34 fairytale
On 11/10/2021 13:48, JT wrote: Nice. I did an update from F26-F33 last year doing one version at time instead of jumping more than one version... and had no major issues. I wonder how far back its possible to start from and walk through the version updates. I recently did F15-F34 though I did do it two versions at a time for the most part. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Schedule for Monday's FESCo Meeting (2021-10-11)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 19:00UTC in #fedora-meeting on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2021-10-11 19:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = #2666 Nonresponsive maintainer: Jan Pokorný jpokorny https://pagure.io/fesco/issue/2666 APPROVED (+3,0,-0) #2668 Nonresponsive maintainer: Ben Rosser tc01 https://pagure.io/fesco/issue/2668 APPROVED (+2,0,-0) = Followups = #2667 F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF https://pagure.io/fesco/issue/2667 = New business = #2672 Nonresponsive group: @java-maint-sig https://pagure.io/fesco/issue/2672 = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: leap from f22 to f34 fairytale
Nice. I did an update from F26-F33 last year doing one version at time instead of jumping more than one version... and had no major issues. I wonder how far back its possible to start from and walk through the version updates. On Mon, Oct 11, 2021 at 3:55 AM Jiri Vanek wrote: > Hello good people! > > I would like to thanx to everybody for amazing work in fedora, for keeping > it alive, and updatable. > > In friday I had found an old laptop running f22 and decided to try a leap > update to f34. It was not just default inntall, there was vlc and much > more "unknown" comonents. > Well, transaction failed on python stack, but no surprise here (f31 ahd > python2->python3?). > So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. > Transaction passed. Update passed, and system started and was alive. > Although the system was behaving terribly (there were experiemtnal patches > in graphic drivers and also > gnomeshell was weird, not speaking about wayalnd), it was stable enough to > make another huge leap. F27->f31 faile dagain on pythn stack, but only > because of four packages. > f27->f30 passed again. UNluckily --nogpg check was no longer transferable > from download to reboot+update. But gpgcheck=1 in active repos fixed it.[1] > in and in the morning a running shining smooth quick and super stbale > system was there. > f30-> f34 died again on python stack.. (yah, dnf and freinds should stop > using that or keep embedded interpreter) > f30->31 passed again to even more shining and more working system. > f31->f33 (yup, that was typo, but found it to late in trasnaction) passed > again withot issues. > > Thanx a lot! II was never expecting such leaps would work so smoothly! > >J. > > > [1] https was a culprint herem causing the keys impossible to downlaod. in > f31, gpgcheck could be enabled again. > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Modularity: Demodularizing packages
Hello packagers, I'm glad to announce that now it's possible to move a package back from a module to a nonmodular repository. Motivation == In the past there was a problem that once a package was added into a module, there was to way to return it back. Let's say you have a curl:experimental module stream which delivers a future version of curl and which unfortunately needs a not-yet released version of OpenSSL. So you add two components into the module: filter: rpms: - openssl-devel - openssl-perl components: rpms: openssl: rational: Run-time dependency ref: experimental buildorder: 0 curl: rational: API ref: experimental buildorder: 1 and release Fedora 35 with it: name: curl stream: experimental version: 1 artifacts: rpms: - curl-0:-0.module_42.x86_64 - openssl-libs-1:3.0.1-0.1.module_42.x86_64 Users who want the experimental curl, will enable the stream with "dnf module switch-to curl:experimental" and curl-0:-0.module_42.x86_64 with the patched openssl-libs-1:3.0.0-1.module_42.x86_64 will get installed. Time flows, OpenSSL releases a new 3.0.1 version with the missing feature, Fedora will upgrade the nonmodular openssl to 1:3.0.1-1, and you, as curl:experimental maintainer, want to get rid of the bundled, now redundant openssl. So you remove it from your module: components: rpms: curl: rational: API ref: experimental buildorder: 0 pushes it to an updates-testing-modular repository: name: curl stream: experimental version: 2 artifacts: rpms: - curl-0:-0.module_42.x86_64 and after "dnf upgrade", you will find out that your machine is not using the new nonmodular openssl-libs-1:3.0.1-1.fc35 but still your old modular openssl-libs-1:3.0.1-0.1.module_42 package. How is it possible? What has gone wrong? The problem === The reason lies in a "modular filtering" performed by DNF. When DNF loads repository metadata, it will see two module builds: - curl:experimental:1 from fedora-modular repository with these packages: - curl-0:-0.module_42.x86_64 - openssl-libs-1:3.0.1-0.1.module_42.x86_64 - curl:experimental:2 from updates-testing-modular with this package: - curl-0:-0.module_42.x86_64 DNF will enumerate packages of all the versions of the module, and adds both curl, and openssl-libs to the modular filter. As a result, the nonmodular openssl-libs won't be visible, and instead the two curl and openssl-libs modular packages become visible to an RPM dependency solver. Simply put, DNF does process old module versions. Why does it do? Because you may want to downgrade a broken package to an older version. The solution There were two approaches proposed: One was ignore the non-latest modules, another was mark removed packages explicitly. DNF maintainer decided for the latter with an explanation that the former would affect already released modules. Therefore the process of demodularization is following: demodularized: rpms: - openssl-libs components: rpms: curl: rational: API ref: experimental buildorder: 0 A new explicit field "demodularized" was introduced. It lists names of the binary packages which are not part of the module stream any longer. This list then appears in the repository: name: curl stream: experimental version: 2 demodularized: rpms: - openssl-libs artifacts: rpms: - curl-0:-0.module_42.x86_64 and DNF will ignore the listed modular package of this stream. It means that "dnf upgrade" will make these packages available to the RPM solver: - curl-0:-0.module_42.x86_64modular - openssl-libs-1:3.0.1-1.x86_64 nonmodular - openssl-libs-1:3.0.1-0.1.module_42.x86_64 formerly modular The solver will identify 1:3.0.1-1 as the highest NEVRA and install that. It means that the module's maintainer needs to coordinate the demodularization with the nonmodular maintainer because standard NEVRA ordering will be used. To provide a smooth transition, the nonmodular package should be built in a higher NEVRA before undergoing the demodularization. DNF also reports the demodularized packages in "dnf module info ..." output. It's important to mention that only the latest version of the module stream is consulted for the demodularized list. That allows you to reintroduce the package in any future module version simply by removing it from the list. It also means that you need to carry the demodularized list in all future module versions as long as there is a historical version w
Re: leap from f22 to f34 fairytale
On 10/11/21 12:28, Petr Pisar wrote: V Mon, Oct 11, 2021 at 09:55:05AM +0200, Jiri Vanek napsal(a): f30-> f34 died again on python stack.. (yah, dnf and freinds should stop using that or keep embedded interpreter) DNF 5 is going be written in C++ without any Python. with all its pros and cons :) -- Petr ___ 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 -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora rawhide compose report: 20211011.n.0 changes
OLD: Fedora-Rawhide-20211010.n.0 NEW: Fedora-Rawhide-20211011.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 0 Dropped packages:0 Upgraded packages: 28 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:0 B Size of upgraded packages: 1.78 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -3.23 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20211010.n.0.aarch64.tar.xz = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: anarch-1.02d-4.20210616gitf6a6a68a.fc36 Old package: anarch-1.02d-3.20210616gitf6a6a68a.fc36 Summary: Suckless, anarcho-pacifist Doom clone that runs everywhere RPMs: anarch-CSFML anarch-SDL2 Size: 961.92 KiB Size change: 4.53 KiB Changelog: * Mon Oct 04 2021 Artur Frenszek-Iwicki - 1.02d-4.20210617gitf6a6a68a8 - Add a patch to make the game store its save file in XDG_DATA_HOME Package: caja-1.26.0-2.fc36 Old package: caja-1.26.0-1.fc35 Summary: File manager for MATE RPMs: caja caja-core-extensions caja-devel caja-schemas Size: 21.62 MiB Size change: -9.21 KiB Changelog: * Sun Oct 10 2021 Wolfgang Ulbrich - 1.26.0-2 - fix https://github.com/mate-desktop/caja/issues/1562 - use https://github.com/mate-desktop/caja/pull/1563 Package: calibre-5.29.0-1.fc36 Old package: calibre-5.28.0-1.fc36 Summary: E-book converter and library manager RPMs: calibre Size: 69.34 MiB Size change: -73.15 KiB Changelog: * Sun Oct 10 2021 Kevin Fenzi - 5.29.0-1 - Update to 5.29.0. Fixes rhbz#2012277 Package: containerd-1.5.7-1.fc36 Old package: containerd-1.5.5-1.fc36 Summary: Open and reliable container runtime RPMs: containerd containerd-devel Size: 138.87 MiB Size change: 40.33 KiB Changelog: * Sun Oct 10 2021 Olivier Lemasle - 1.5.7-1 - Update to upstream 1.5.7 (fixes rhbz#2009149) - Fixes CVE-2021-41103 (fixes rhbz#2011014, rhbz#2011007) Package: deepin-qt-dbus-factory-5.4.20-1.fc36 Old package: deepin-qt-dbus-factory-5.4.17-1.fc36 Summary: A repository stores auto-generated Qt5 dbus code RPMs: deepin-qt-dbus-factory deepin-qt-dbus-factory-devel Size: 4.37 MiB Size change: 5.37 KiB Changelog: * Sun Oct 10 2021 Robin Lee 5.4.20-1 - New release 5.4.20 Package: eb-4.4.3-18.fc36 Old package: eb-4.4.3-17.fc34 Summary: Library for accessing Japanese CD-ROM electronic books RPMs: eb eb-devel Size: 1.50 MiB Size change: -19.06 KiB Changelog: * Wed Jul 21 2021 Fedora Release Engineering - 4.4.3-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild * Mon Oct 11 2021 Jens Petersen - 4.4.3-18 - remove RPATH to fix FTBFS (#1987434) Package: firebird-4.0.0.2496-5.fc36 Old package: firebird-4.0.0.2496-4.fc36 Summary: SQL relational database management system RPMs: firebird firebird-devel firebird-doc firebird-examples firebird-utils libfbclient2 libfbclient2-devel libib-util Size: 51.83 MiB Size change: -3.28 KiB Changelog: * Sun Oct 10 2021 Kalev Lember - 4.0.0.2496-5 - Recommend logrotate rather than hard requiring Package: gajim-1.3.3-1.fc36 Old package: gajim-1.3.2-3.fc35 Summary: Jabber client written in PyGTK RPMs: gajim Size: 6.69 MiB Size change: 2.61 KiB Changelog: * Sun Oct 10 2021 Michael Kuhn - 1.3.3-1 - Update to 1.3.3 Package: geany-plugins-1.38-1.fc36 Old package: geany-plugins-1.37-4.fc35 Summary: Plugins for Geany RPMs: geany-plugins-addons geany-plugins-autoclose geany-plugins-automark geany-plugins-codenav geany-plugins-commander geany-plugins-common geany-plugins-debugger geany-plugins-defineformat geany-plugins-geanyctags geany-plugins-geanydoc geany-plugins-geanyextrasel geany-plugins-geanygendoc geany-plugins-geanyinsertnum geany-plugins-geanymacro geany-plugins-geanyminiscript geany-plugins-geanynumberedbookmarks geany-plugins-geanypg geany-plugins-geanyprj geany-plugins-geanyvc geany-plugins-geniuspaste geany-plugins-git-changebar geany-plugins-keyrecord geany-plugins-latex geany-plugins-lineoperations geany-plugins-lipsum geany-plugins-markdown geany-plugins-overview geany-plugins-pairtaghighlighter geany-plugins-pohelper geany-plugins-pretty-printer geany-plugins-projectorganizer geany-plugins-scope geany-plugins-sendmail geany-plugins-shiftcolumn geany-plugins-spellcheck geany-plugins-tableconvert geany-plugins-treebrowser geany-plugins-updatechecker geany-plugins-vimode geany-plugins-workbench geany-plugins-xmlsnippets Size: 14.83 MiB Size change: 199.81 KiB Changelog: * Sun Oct 10 2021 Dominic Hopf 1.38-1 - New upstream release: Geany-Plugins
Re: leap from f22 to f34 fairytale
V Mon, Oct 11, 2021 at 09:55:05AM +0200, Jiri Vanek napsal(a): > f30-> f34 died again on python stack.. (yah, dnf and freinds should stop > using that or keep embedded interpreter) DNF 5 is going be written in C++ without any Python. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: openbabel-3.1* in Rawhide
Hi all. Even Kalzium (new release) is rebuilt against openbabel3 -- --- Antonio Trande Fedora Project mailto: sagit...@fedoraproject.org GPG key: 0x29FBC85D7A51CC2F GPG key server: https://keyserver1.pgp.com/ OpenPGP_0x29FBC85D7A51CC2F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: leap from f22 to f34 fairytale
On Mon, 2021-10-11 at 10:34 +0200, Casper wrote: > Happy to read this :) > > Congrats, man :) > > I will do soon an f33 - f34 - f35 journey F33 -> F35 should work (update) directly > Jiri Vanek a écrit : > > Hello good people! > > > > I would like to thanx to everybody for amazing work in fedora, for > > keeping it alive, and updatable. > > > > In friday I had found an old laptop running f22 and decided to try > > a leap update to f34. It was not just default inntall, there was > > vlc and much more "unknown" comonents. > > Well, transaction failed on python stack, but no surprise here (f31 > > ahd python2->python3?). > > So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. > > Transaction passed. Update passed, and system started and was > > alive. > > Although the system was behaving terribly (there were experiemtnal > > patches > > in graphic drivers and also gnomeshell was weird, not speaking > > about > > wayalnd), it was stable enough to make another huge leap. F27->f31 > > faile > > dagain on pythn stack, but only because of four packages. > > f27->f30 passed again. UNluckily --nogpg check was no longer > > transferable from download to reboot+update. But gpgcheck=1 in > > active repos fixed it.[1] in and in the morning a running shining > > smooth quick and super stbale system was there. > > f30-> f34 died again on python stack.. (yah, dnf and freinds should > > stop using that or keep embedded interpreter) > > f30->31 passed again to even more shining and more working system. > > f31->f33 (yup, that was typo, but found it to late in trasnaction) > > passed again withot issues. > > > > Thanx a lot! II was never expecting such leaps would work so > > smoothly! > > > > J. > > > > > > [1] https was a culprint herem causing the keys impossible to > > downlaod. in f31, gpgcheck could be enabled again. > > -- > > Jiri Vanek Mgr. > > Principal QA Software Engineer > > Red Hat Inc. > > +420 775 39 01 09 > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: > > https://pagure.io/fedora-infrastructure > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-34-20211011.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211010.0): ID: 1023220 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1023220 ID: 1023228 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1023228 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Next Open NeuroFedora Meeting: 1300 UTC on Monday, 11 October (Today)
Hello everyone, Please join us at the next Open NeuroFedora team meeting on Monday 11th October (today!) at 1300UTC in #fedora-neuro on IRC (Libera.chat) or Matrix. The meeting is a public meeting, and open for everyone to attend. You can join us over: Matrix: https://matrix.to/#/#neuro:fedoraproject.org IRC: https://webchat.libera.chat/?channels=#fedora-neuro You can convert the meeting time to your local time using this command in a terminal: $ date --date='TZ="UTC" 1300 today' or you can use this link: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20211011T13&p1=%3A&ah=1 The meeting will be chaired by @ankursinha. The agenda for the meeting is: - New introductions and roll call. - Tasks from last meeting: https://meetbot.fedoraproject.org/teams/neurofedora/neurofedora.2021-09-27-13.00.html - Open Pagure tickets: https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting - Package health check: https://packager-dashboard.fedoraproject.org/neuro-sig - Open package reviews check: https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro - Koschei packages check: https://koschei.fedoraproject.org/groups/neuro-sig - CompNeuro lab compose status check for F35/F36: https://koji.fedoraproject.org/koji/packageinfo?packageID=30691 - Neuroscience query of the week - Next meeting day, and chair. - Open floor. We hope to see you there! You can learn more about NeuroFedora here: https://neuro.fedoraproject.org -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: leap from f22 to f34 fairytale
Happy to read this :) Congrats, man :) I will do soon an f33 - f34 - f35 journey Jiri Vanek a écrit : > Hello good people! > > I would like to thanx to everybody for amazing work in fedora, for keeping it > alive, and updatable. > > In friday I had found an old laptop running f22 and decided to try a leap > update to f34. It was not just default inntall, there was vlc and much more > "unknown" comonents. > Well, transaction failed on python stack, but no surprise here (f31 ahd > python2->python3?). > So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. > Transaction passed. Update passed, and system started and was alive. > Although the system was behaving terribly (there were experiemtnal patches > in graphic drivers and also gnomeshell was weird, not speaking about > wayalnd), it was stable enough to make another huge leap. F27->f31 faile > dagain on pythn stack, but only because of four packages. > f27->f30 passed again. UNluckily --nogpg check was no longer transferable > from download to reboot+update. But gpgcheck=1 in active repos fixed it.[1] > in and in the morning a running shining smooth quick and super stbale > system was there. > f30-> f34 died again on python stack.. (yah, dnf and freinds should stop > using that or keep embedded interpreter) > f30->31 passed again to even more shining and more working system. > f31->f33 (yup, that was typo, but found it to late in trasnaction) passed > again withot issues. > > Thanx a lot! II was never expecting such leaps would work so smoothly! > > J. > > > [1] https was a culprint herem causing the keys impossible to downlaod. in > f31, gpgcheck could be enabled again. > -- > Jiri Vanek Mgr. > Principal QA Software Engineer > Red Hat Inc. > +420 775 39 01 09 > ___ > 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 -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der Jabber/XMPP Messaging: cas...@casperlefantom.net 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
leap from f22 to f34 fairytale
Hello good people! I would like to thanx to everybody for amazing work in fedora, for keeping it alive, and updatable. In friday I had found an old laptop running f22 and decided to try a leap update to f34. It was not just default inntall, there was vlc and much more "unknown" comonents. Well, transaction failed on python stack, but no surprise here (f31 ahd python2->python3?). So random bisetct, leap update to f27. Needed --nogpgcheck[1]. Wou. Transaction passed. Update passed, and system started and was alive. Although the system was behaving terribly (there were experiemtnal patches in graphic drivers and also gnomeshell was weird, not speaking about wayalnd), it was stable enough to make another huge leap. F27->f31 faile dagain on pythn stack, but only because of four packages. f27->f30 passed again. UNluckily --nogpg check was no longer transferable from download to reboot+update. But gpgcheck=1 in active repos fixed it.[1] in and in the morning a running shining smooth quick and super stbale system was there. f30-> f34 died again on python stack.. (yah, dnf and freinds should stop using that or keep embedded interpreter) f30->31 passed again to even more shining and more working system. f31->f33 (yup, that was typo, but found it to late in trasnaction) passed again withot issues. Thanx a lot! II was never expecting such leaps would work so smoothly! J. [1] https was a culprint herem causing the keys impossible to downlaod. in f31, gpgcheck could be enabled again. -- Jiri Vanek Mgr. Principal QA Software Engineer Red Hat Inc. +420 775 39 01 09 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Cloud-33-20211011.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211010.0): ID: 1022972 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1022972 ID: 1022980 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1022980 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure