Re: Let's retire original glib and gtk+ (new report)
> Am 08.03.2022 um 01:41 schrieb Kevin Kofler via devel > : > > I do not see why we would want to force removing working, maintained > packages from the distribution. That is a major disservice to users and > basically a "screw you" to the maintainer. Whom does that help? > > GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to > "stick around forever", at least as long as somebody is willing to maintain > them. They are needed to keep legacy applications working. 1+++ IMHO And, by the way, it is one of Linux’s (and Fedora Linux’s) core distinguishing features that it does not follow the short-term commercial life cycles, but enables long-term usability, for "old" hardware as well as software. And we should not give that up lightly and without need. ___ 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: Let's retire original glib and gtk+ (new report)
Michael Catanzaro wrote: > Broken dependencies will be automatically retired if they are not fixed > within a certain time, so it's really OK to do this. The broken > packages won't stick around forever: they will eventually get cleaned > up. In other words, leaf applications that end users care about will eventually get dropped as well (which is no surprise if you remove the library they depended on). I do not see how that is "really OK to do" in any way. Kevin Kofler ___ 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: Let's retire original glib and gtk+ (new report)
Michael Catanzaro wrote: > The maintainer is unwilling to retire them. > > I think we should ask FESCo to force them to be retired. It's confusing > to have ancient versions of the packages in the distro, and they will > stick around forever if not. I do not see why we would want to force removing working, maintained packages from the distribution. That is a major disservice to users and basically a "screw you" to the maintainer. Whom does that help? GLib 1 and GTK+ 1 are compatibility libraries. It is their whole purpose to "stick around forever", at least as long as somebody is willing to maintain them. They are needed to keep legacy applications working. If FESCo wants to get involved at all (I do not really see any need for them to intervene in the first place), I ask FESCo to affirm that a compatibility library can remain in the distribution as long as it is maintained and to ask people to refrain from posting unhelpful threads such as this one. Nobody is asking you to maintain those packages, so I do not see why you need to care at all about their existence. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: how to debug failures inside mock when building takes a long time?
Felix Schwarz wrote: > Btw: How do you handle/fix build issues when you can only build inside > mock? > > So for example your mock build fails because some paths or binaries are > wrong and it is not obvious from the error what needs to be changed. In > these situations I'd like to have some kind of interactive repl shell > similar to pdb. Is there something like that for mock? Or some other trick > to fix such problems? > > I found that fixing a build is really time consuming especially if the > error only happens in the %check section and build times are high. I > thought about using a reverse shell (+ enable network for mock) but I > guess there is a better way to do this? There is actually a "mock shell" command that opens a shell inside the mock chroot. You can also run arbitrary shell commands (including scripts that you have previously manually copied in using the "copyin" command) in it. Mock does a lot more than just building packages, the latter is just the default operation. Kevin Kofler ___ 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: Problem with cmake 3.23.0
Hi, On Fri, 2022-03-04 at 18:07 +0100, Kamil Dudka wrote: > On Friday, March 4, 2022 4:17:01 PM CET Sérgio Basto wrote: > > I think you missed the > > https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds > > When the change landed, I had to fix all my packages to build although > they > had been using out of source builds since the beginning. Now I have to > fix > them again. Maintaining a spec file that works on RHEL-7..9 and on all > supported releases of Fedora is more and more difficult for no good > reason > but I am not giving it up for now: > > https://github.com/csutils/csdiff/commit/df8d918c > https://github.com/csutils/csdiff/commit/9ec45f67 > I would have to waste some time to understand your commits, but at first glance they are not correct, I would also have to analyze how the macros are going on el7, I think cmake3 macros from epel-7 already assumed all this. I advise anyone to carefully read the wiki page. We have two options, or keep the directories, or remove the all directories, from the build. if we don't want to change anything we can use Martin's solution that is add: %global __cmake_in_source_build 1 otherwise we should not use any directory and use: %undefine __cmake_in_source_build Best regards, > Kamil > > -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 3/7/22 2:03 PM, Neal Gompa wrote: A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf If Fedora wants to adopt "default i686 off" I am OK with that. I will gladly add an "IncludeArch" or whatever macro to wine, mingw-wine-gecko, wine-mono, wine-dxvk, and vkd3d to keep building Wine on Fedora. Yes, it is more than just the 'wine' package that is affected by this. P.S. (this is directed at the mailing list): I have built wine for years. I've submitted wine patches. I engage with upstream. Please engage *me* when it comes to changes affecting wine. I'll be happy to answer questions and work with any changes required. ___ 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
Singular soname bump and a review swap
As you all know by now, I'm trying to retire as steward of the sagemath and Macaulay2 stacks. Nevertheless, after some impassioned pleas from a couple of sagemath users, I have prepared an update for sagemath 9.5. This will require an update to Singular 4.2.1p3, which comes with an soname bump. Sagemath 9.5 has spun the primecount interface out into a separate package. This means that I need to *add* one package to the set I am trying to give away so that I can keep claiming that the packages are in good shape. Is anyone interested in a review swap? I need this one: python-primecountpy: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2061570 The updates will be done sometime next week, after that review is complete. -- 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Neal Gompa writes: > On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote: >> >> Fabio Valentini writes: >> >> > For example, as far as I know, you need the 32-bit host libraries for >> > running 32-bit Windows applications in Wine. Dropping that would make >> > our Wine packages almost useless, since a large fraction of Windows >> > software still isn't 64-bit. >> >> Would it be possible to have package foo's x86_64 build produce a >> foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an >> important use case, but keeping the whole arch machinery around for it >> seems like overkill - just having the packages that are relevant for it >> build 32-bit variants as a special case seems a lot cleaner. >> > > Koji normally filters out foreign arches from buildroot repos. There > are ways around it, but none are usable in Fedora Koji. Good to know. Guess it'd have to be things like foo-32.x86_64.rpm then. Be well, --Robbie 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 3:46 PM Adam Williamson wrote: > > On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote: > > So, I'll go ahead and be a bad guy here: > > > > Perhaps it's time to just retire i686 completely? > > > > Steam is available as a flatpak > > Do we know how the flatpak is built and updated? Would Fedora ending > i686 support affect *that* work? It would certainly affect *our* runtimes. And affect *our* ability to support applications natively, including native Linux games. -- 真実はいつも一つ！/ 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote: > So, I'll go ahead and be a bad guy here: > > Perhaps it's time to just retire i686 completely? > > Steam is available as a flatpak Do we know how the flatpak is built and updated? Would Fedora ending i686 support affect *that* work? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood wrote: > > Fabio Valentini writes: > > > For example, as far as I know, you need the 32-bit host libraries for > > running 32-bit Windows applications in Wine. Dropping that would make > > our Wine packages almost useless, since a large fraction of Windows > > software still isn't 64-bit. > > Would it be possible to have package foo's x86_64 build produce a > foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an > important use case, but keeping the whole arch machinery around for it > seems like overkill - just having the packages that are relevant for it > build 32-bit variants as a special case seems a lot cleaner. > Koji normally filters out foreign arches from buildroot repos. There are ways around it, but none are usable in Fedora Koji. -- 真実はいつも一つ！/ 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Fabio Valentini writes: > For example, as far as I know, you need the 32-bit host libraries for > running 32-bit Windows applications in Wine. Dropping that would make > our Wine packages almost useless, since a large fraction of Windows > software still isn't 64-bit. Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner. Be well, --Robbie 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 2:15 PM Miro Hrončok wrote:
>
> On 07. 03. 22 19:30, Fabio Valentini wrote:
> > On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
> >>
> >> Once upon a time, Ben Cotton said:
> >>> == Summary ==
> >>>
> >>> Package maintainers are encouraged to actively stop building their
> >>> packages for i686, especially if supporting this architecture requires
> >>> significant investment of time or resources, for no benefit. This will
> >>> not apply to packages which are still depended on by other i686
> >>> packages, or which get used in a "multilib" context (i.e. for running
> >>> 32-bit applications on x86_64).
> >>
> >> It's unclear what this actually means for packagers. Should
> >> ExcludeArch: lines be added to spec files?
> >
> > Ah, yes, thanks for catching that. This was indeed my intention:
> > Packagers add "ExcludeArch: %{ix86}" to the package in question, if it
> > is safe to do so (unused / leaf packages only).
> > I forgot to add that detail to the proposal, will add it now.
> >
> > As far as I can tell, any approach more sophisticated than that (like
> > automatically determining the i686 packages we *need*) would require
> > significantly more work, and probably be more error-prone, introduce
> > more friction, and make it harder to revert errors.
>
> This begs several questions that would probably need to be clarified e.g. in
> the packaging guidelines. For example:
>
> --
>
> I am adding a brand new package to multiple Fedora releases. The package is
> not
> noarch. It successfully builds on i686. What am I supposed to do?
>
> a) build it on i686, until it fails there
> b) excludearch %ix86 right away not to create a dead dep tree
> c) excludearch %ix86 on F37+ only, as this is a F37 change
>
> ---
>
> I am updating a package that no longer builds on i686. How do I know if I can
> exclude it safely? What checks do I run? Am I allowed to push this update to
> stable Fedora releases?
>
> ---
>
> My package is noarch but has multiple arched dependencies. How do I properly
> make Koji not attempt to build it on i686?
>
A simpler solution would be to just default-off i686 and check-in some
marker file that indicates the package needs to be built for multilib.
This is how openSUSE does it today with the baselibs.conf file:
https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf
--
真実はいつも一つ！/ 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote: > On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi wrote: > > > > So, I'll go ahead and be a bad guy here: > > > > Perhaps it's time to just retire i686 completely? > > > > Steam is available as a flatpak, and old software thats 32bit only and > > can't be rebuilt could just be run from a f36 container? > > > > This would save us: > > > > * all the builder resources > > * all the multilib calculation time/space in composes > > > > If we don't want to retire it now, when will we? > > I have considered this option, but I don't think we can do that yet. > > For example, as far as I know, you need the 32-bit host libraries for > running 32-bit Windows applications in Wine. > Dropping that would make our Wine packages almost useless, since a > large fraction of Windows software still isn't 64-bit. > > But I could be wrong. And if we indeed don't need wine.i686 to run > 32-bit Windows apps, retiring i686 entirely would be an option, I > agree. > (I myself am using the Steam flatpak you mentioned. It works well, and > I don't need 32-bit libs on my host system at all, which is nice.) Wouldn't wine problem be solved by providing the 32bit version as a flatpak if still needed for some corner cases? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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: Documentation for F15's "Remove SETUID" Change?
On Wed, Mar 2, 2022 at 7:15 PM Steve Grubb wrote: > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use capabilities with a few still running as root when > they don't need to be. [...] Not... really. grep is telling me there are 22 spec files that say %cap and 63 that match /%attr.4/. - ajax ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 8:15 PM Miro Hrončok wrote: > Thanks for your feedback, I'll respond inline. > > This begs several questions that would probably need to be clarified e.g. in > the packaging guidelines. For example: > > -- > > I am adding a brand new package to multiple Fedora releases. The package is > not > noarch. It successfully builds on i686. What am I supposed to do? > > a) build it on i686, until it fails there > b) excludearch %ix86 right away not to create a dead dep tree > c) excludearch %ix86 on F37+ only, as this is a F37 change I think new packages could probably exclude i686 on all branches, since with new packages, assuming the i686 packages are unused is always true. :) > --- > > I am updating a package that no longer builds on i686. How do I know if I can > exclude it safely? What checks do I run? Am I allowed to push this update to > stable Fedora releases? If .spec files are maintained in a "use conditionals and merge everywhere" fashion, then the "ExcludeArch: i686" statement would need to be wrapped in a "%if %fedora >= 37" conditional. So no, in general the change for excluding i686 must not be pushed to stable branches. > --- > > My package is noarch but has multiple arched dependencies. How do I properly > make Koji not attempt to build it on i686? I think this case is already covered in the Packaging Guidelines for "noarch packages with unported dependencies": https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unported_dependencies 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
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 07. 03. 22 20:25, Kevin Fenzi wrote: So, I'll go ahead and be a bad guy here: Perhaps it's time to just retire i686 completely? Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container? This would save us: * all the builder resources * all the multilib calculation time/space in composes If we don't want to retire it now, when will we? Supporting i686 has only brought pain and misery on me and I have never really benefit from it in any way. So I can definitively relate to this, but I suppose we should really cmpile a lit of use cases for multilib before we pull the plug. Is it indeed just Steam (flatpak) and legacy stuff? Don't we also need it e.g. for plain Wine? -- 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: Documentation for F15's "Remove SETUID" Change?
Hi Steve, On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote: > Hello, > > On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote: > > The subject of setuid came up in a private conversation recently, and to my > > surprise we don't seem to have it documented in the packaging guidelines: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation > > > > "We should change documentation on packaging guidelines to talk about > > using file capabilities." > > > > but the only mention of capabilities seem to be that, if you use it or > > suid, PIE must be enabled: > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie > > > > Should this be documented somewhere, or if it's there but it's lost in > > the wiki->docs migration, does anyone know where the documentation is? > > As someone involved in that change, the situation was much worse back in > 2011. Almost everything was running as root. The inspection tools back then > were non-existent, which is what I wrote pscap and netcap. > > Now, a lot of things use capabilities with a few still running as root when > they don't need to be. But I have not looked at all daemons. The lesser used > ones may need checking. But I think maybe some guidance could be good. > Something like: > That's really comprehensive, thanks. Can we document this? I'm a bit worried about the situation where a packager and a reviewer don't have the institutional memory of "we recommend capabilities over setuid/setgid" and new setuid packages creeping in again. Best regards, -- Michel Alexandre Salim identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi wrote: > > So, I'll go ahead and be a bad guy here: > > Perhaps it's time to just retire i686 completely? > > Steam is available as a flatpak, and old software thats 32bit only and > can't be rebuilt could just be run from a f36 container? > > This would save us: > > * all the builder resources > * all the multilib calculation time/space in composes > > If we don't want to retire it now, when will we? I have considered this option, but I don't think we can do that yet. For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit. But I could be wrong. And if we indeed don't need wine.i686 to run 32-bit Windows apps, retiring i686 entirely would be an option, I agree. (I myself am using the Steam flatpak you mentioned. It works well, and I don't need 32-bit libs on my host system at all, which is nice.) 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
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
So, I'll go ahead and be a bad guy here: Perhaps it's time to just retire i686 completely? Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container? This would save us: * all the builder resources * all the multilib calculation time/space in composes If we don't want to retire it now, when will we? 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: Let's retire original glib and gtk+ (new report)
On Mon, Mar 7 2022 at 04:48:27 PM +, Paul Howarth wrote: I'm not unwilling to retire them, I just want their users to be retired first so I don't leave a bunch of broken dependencies behind. Hi, sorry, maybe I misunderstood your previous statements. Broken dependencies will be automatically retired if they are not fixed within a certain time, so it's really OK to do this. The broken packages won't stick around forever: they will eventually get cleaned up. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
Once upon a time, Ben Cotton said:
== Summary ==
Package maintainers are encouraged to actively stop building their
packages for i686, especially if supporting this architecture requires
significant investment of time or resources, for no benefit. This will
not apply to packages which are still depended on by other i686
packages, or which get used in a "multilib" context (i.e. for running
32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should
ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention:
Packagers add "ExcludeArch: %{ix86}" to the package in question, if it
is safe to do so (unused / leaf packages only).
I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like
automatically determining the i686 packages we *need*) would require
significantly more work, and probably be more error-prone, introduce
more friction, and make it harder to revert errors.
This begs several questions that would probably need to be clarified e.g. in
the packaging guidelines. For example:
--
I am adding a brand new package to multiple Fedora releases. The package is not
noarch. It successfully builds on i686. What am I supposed to do?
a) build it on i686, until it fails there
b) excludearch %ix86 right away not to create a dead dep tree
c) excludearch %ix86 on F37+ only, as this is a F37 change
---
I am updating a package that no longer builds on i686. How do I know if I can
exclude it safely? What checks do I run? Am I allowed to push this update to
stable Fedora releases?
---
My package is noarch but has multiple arched dependencies. How do I properly
make Koji not attempt to build it on i686?
--
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: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Once upon a time, Fabio Valentini said: > As far as I can tell, any approach more sophisticated than that (like > automatically determining the i686 packages we *need*) would require > significantly more work, and probably be more error-prone, introduce > more friction, and make it harder to revert errors. Hmm, seems like it shouldn't be that hard... make a list of the buildroot packages plus the packages included in multilib, and then follow the build dependency trees. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams wrote:
>
> Once upon a time, Ben Cotton said:
> > == Summary ==
> >
> > Package maintainers are encouraged to actively stop building their
> > packages for i686, especially if supporting this architecture requires
> > significant investment of time or resources, for no benefit. This will
> > not apply to packages which are still depended on by other i686
> > packages, or which get used in a "multilib" context (i.e. for running
> > 32-bit applications on x86_64).
>
> It's unclear what this actually means for packagers. Should
> ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention:
Packagers add "ExcludeArch: %{ix86}" to the package in question, if it
is safe to do so (unused / leaf packages only).
I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like
automatically determining the i686 packages we *need*) would require
significantly more work, and probably be more error-prone, introduce
more friction, and make it harder to revert errors.
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
Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Once upon a time, Ben Cotton said: > == Summary == > > Package maintainers are encouraged to actively stop building their > packages for i686, especially if supporting this architecture requires > significant investment of time or resources, for no benefit. This will > not apply to packages which are still depended on by other i686 > packages, or which get used in a "multilib" context (i.e. for running > 32-bit applications on x86_64). It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files? -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: VERY late notification emails
On Sat, Mar 05, 2022 at 10:58:53AM +, Dan Čermák wrote: > > > On March 5, 2022 9:03:54 AM UTC, Gary Buhrmaster > wrote: > >On Mon, Feb 28, 2022 at 5:25 PM Kevin Fenzi wrote: > > > >> No, there's things we can do and are trying to do. ;) > > > >I seem to remember that one of the issues > >identified was (for those of us using gmail > >for the notifications) was that google could > >end up throttling emails. > > > >I have a vague recollection that google has > >numerous recommendations to mitigate > >against throttling (including DKIM and SPF), > >in addition to a method in which one can > >reduce certain delays for "buik" email > >and also monitor for issues ((I think via > >postmaster.google.com?) > > > >I am going to presume that these resources > >have been investigated and you have looked > >at the google monitoring information. Can > >you share why the emails are getting delayed > >according to Google? Yes, we do all those things. Google limits incoming emails to accounts. Here's the google "workspace" page on it (but I think there's also possibly lower limits for 'free' accounts: https://support.google.com/a/answer/1366776?hl=en So basically from time to time people (especially those on scm-commits mailing list) go over those limits and google just rejects email to them until it cools down. There's often also people who go over their google storage quota and it rejects emails for them until they delete things. > It's definitely not just Google, I keep getting delayed emails as well and my > emails are not hosted by a big provider. These are two seperate discussions. FMN is slow/behind, and google sometimes drops/delays/rejects FMN emails. I watched it over the weekend, and now it's only 3 days behind. ;( Hopefully it will finish catching up... I'm continuing to watch it. We are also close to having the python3 version up in staging. 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
RHEL moving to issues.redhat.com only long term
Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh ___ 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
F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval == Summary == Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64). == Owner == * Name: [[User:Decathorpe| Fabio Valentini]] * Email: decathorpe [AT] gmail [DOT] com == Detailed Description == Fedora does no longer ship any deliverables for i686, not even RPM repositories for i686 are published any longer. The kernel package itself also [[Changes/Stop Building i686 Kernels|dropped support for i686]] in Fedora 31, so there has not been any way to run Fedora on 32-bit x86 systems for years. Only a tiny fraction of all packages that are built on i686 are actually used (i.e. "multilib" support for Wine, Steam, etc. on x86_64). == Feedback == (none yet) == Benefit to Fedora == Stopping to run unnecessary package builds on i686 will free up no small amount of resources. In particular, stopping to build for i686 could potentially free up almost half of the existing x86 builder resources in koji. Additionally, support for building on 32-bit targets is starting to get dropped by upstream projects, and resource constraints of 32-bit architectures (i.e. per-process and total memory limits) also make building large libraries or applications increasingly difficult. With ARMv7 support having been removed from Fedora 37 already, i686 is the only remaining supported 32-bit architecture. Encouraging package maintainers to drop i686 support from their packages (if possible), instead of requiring them to work around those resource constraints or missing upstream support, will significantly lower the maintenance burden, especially for some problematic packages. == Scope == * Proposal owners: Proposal owners will provide convenience scripts for checking whether a given package is a leaf package on i686, and will help with identifying potential candidate packages. * Other developers: Package maintainers who are affected by 32-bit architecture / i686 specific problems are encouraged to investigate dropping support for i686 entirely, instead of having to invest time to fix or work around those issues, for very little benefit to Fedora. This can be done incrementally, as dropping support for i686 from some packages will in turn make other packages leaves on i686. * Release engineering: N/A There are already no deliverables for i686, so there should be no impact on Release engineering. * Policies and guidelines: Packages that drop support for i686 will no longer need to file a tracking bug and block the [https://bugzilla.redhat.com/show_bug.cgi?id=179258 32-bit x86 ExcludeArch tracker bug]. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == This Change only affects unused / leaf packages that are never installed on user systems (particularly because it has not been possible to install i686-based Fedora for years). == How To Test == The remaining use cases of i686 packages (i.e. "multilib") for popular 32-bit applications should continue to work. For example, installing the Steam client (steam.i686), Wine, or other applications that require 32-bit compatibility libraries should still be possible, and not fail due to broken dependencies. == User Experience == N/A == Dependencies == N/A == Contingency Plan == This Change is supposed to only affect unused components / leaf packages. However, if a package maintainer accidentally stops building a package on i686 despite it still being required for something else, this should be easy to revert - by adding back i686 architecture support to the affected packages, in reverse order. Since removal of support for i686 will happen slowly and incrementally, this should be relatively straightforward. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora packages will incrementally drop support for the i686 architecture (32-bit x86), where this support is no longer required. This is intended to reduce resource consumption of build servers. Additionally, it will make package maintenance for Fedora easier, because a growing number of projects already either no longer provide support for - or fail to build due to resource constraints on - 32-bit architectures. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/c
Re: Packaging guidelines: gettext vs. gettext-devel
On Sat, 2022-03-05 at 16:08 -0500, Elliott Sales de Andrade wrote: > On Fri, Mar 4, 2022 at 3:26 PM Ken Gaillot > wrote: > > Hi all, > > > > I have a question about the guidelines for "Handling Locale Files": > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_handling_locale_files > > > > The guidelines state, "If the package uses gettext for > > translations, > > add BuildRequires: gettext". > > > > gettext-devel seems the more logical dependency, since it has the > > autoconf macros. And of course the guidelines for "Devel Packages" > > state "-devel packages must be used to contain files which are > > intended > > solely for development or needed only at build-time." > > > > gettext is a tool that happens to be used in development, but that is > not the same as being a "Devel Package". It is much the same as gcc > or > clang, which we don't have people install gcc-devel and clang-devel > for. > gettext-devel is for development _against_ gettext, which is not the > same as using it. > > For a properly released autotools-based project, the gettext autoconf > macros are not necessary as the tarball should have been generated > with configure.ac expanded into configure. Aha, I think the "properly released" part is the essence :) The spec in question calls autoreconf, which leads to the gettext-devel dependency. After more digging, I found that calling autoreconf is an unsettled area of the guidelines. I think the simplest way forward is to use gettext-devel as the dependency as long as the spec calls autoreconf. Longer term, I can think about whether autoreconf can be avoided. > > > Both gettext and gettext-devel depend on gettext-libs, which might > > make > > the issue unnoticeable for packages don't use autotools. > > > > Would "gettext" or "gettext-devel" be more correct for > > BuildRequires? > > In short, gettext is, unless you have special requirements. Thanks for the explanation, it makes sense now. -- Ken Gaillot ___ 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: Let's retire original glib and gtk+ (new report)
On Mon, 07 Mar 2022 10:29:02 -0600 Michael Catanzaro wrote: > On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto > wrote: > > Hi, > > In resume glib still required for 20 packages [1], > > apart of the sweet memories that some package bring to us , any of > > these packages is needed ? or haven't replacement ? > > The maintainer is unwilling to retire them. > > I think we should ask FESCo to force them to be retired. It's > confusing to have ancient versions of the packages in the distro, and > they will stick around forever if not. I'm not unwilling to retire them, I just want their users to be retired first so I don't leave a bunch of broken dependencies behind. Paul. ___ 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: Let's retire original glib and gtk+ (new report)
Hi On Mon, Mar 7, 2022 at 11:29 AM Michael Catanzaro wrote: > On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto > > Hi, > > In resume glib still required for 20 packages [1], > > apart of the sweet memories that some package bring to us , any of > > these packages is needed ? or haven't replacement ? > > The maintainer is unwilling to retire them. > > I think we should ask FESCo to force them to be retired. It's confusing > to have ancient versions of the packages in the distro, and they will > stick around forever if not > Instead of forcing a mandate to remove it, perhaps a migration to Copr would be a better way out of this Rahul ___ 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: Let's retire original glib and gtk+ (new report)
On Mon, 2022-03-07 at 16:17 +, Sérgio Basto wrote: > Hi, > In resume glib still required for 20 packages [1], > apart of the sweet memories that some package bring to us , any of > these packages is needed ? or haven't replacement ? > > Thanks > > alsa-tools (maintained by: perex, timj) > alsa-tools-1.2.5-3.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36 > alsa-tools-firmware-1.2.5-3.fc36.x86_64 requires alsa-firmware = 1.2.4- > 6.fc36 > > alsa-firmware (maintained by: perex, timj) > alsa-firmware-1.2.4-6.fc36.noarch requires alsa-tools-firmware = 1.2.5- > 3.fc36 These two seem like they would need addressing. Presumably we could drop some graphical thing from alsa-tools and keep the rest. > > fvwm (maintained by: jhogarth, mcermak, pertusus, peter) > fvwm-2.6.9-7.fc36.src requires libstroke-devel = 0.5.1-45.fc36 > fvwm-2.6.9-7.fc36.x86_64 requires libstroke.so.0()(64bit) At least *somebody* was using fvwm as recently as F34: https://www.reddit.com/r/Fedora/comments/ounk85/f34_ive_been_trying_different_wm_and_at_the/ so I guess we might care about them? There appears to be an vfwm3: https://github.com/fvwmorg/fvwm3 with tagged 1.0.x releases, but I've no idea how usable/popular/packageable that is. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Let's retire original glib and gtk+ (new report)
On Mon, Mar 7 2022 at 04:17:09 PM +, Sérgio Basto wrote: Hi, In resume glib still required for 20 packages [1], apart of the sweet memories that some package bring to us , any of these packages is needed ? or haven't replacement ? The maintainer is unwilling to retire them. I think we should ask FESCo to force them to be retired. It's confusing to have ancient versions of the packages in the distro, and they will stick around forever if not. ___ 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
Let's retire original glib and gtk+ (new report)
Hi, In resume glib still required for 20 packages [1], apart of the sweet memories that some package bring to us , any of these packages is needed ? or haven't replacement ? Thanks [1] Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools bubblemon crossfire crossfire-client crossfire-maps dillo freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda xconvers xdialog xvattr Package (co)maintainersStatus Change == glib pghmcfc, rdieter 229 weeks ago The following packages require above mentioned packages: Depending on: glib (20), status change: 2017-10-10 (229 weeks ago) bubblemon (maintained by: sham1) bubblemon-1.46-31.fc36.x86_64 requires libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit) gnubg (maintained by: limb) gnubg-1:1.06.001-14.fc35.src requires glib-devel = 1:1.2.10-64.fc36 gtk+ (maintained by: pghmcfc, rdieter) gtk+-1:1.2.10-98.fc36.i686 requires libglib-1.2.so.0, libgmodule- 1.2.so.0 gtk+-1:1.2.10-98.fc36.src requires glib-devel = 1:1.2.10-64.fc36 gtk+-1:1.2.10-98.fc36.x86_64 requires libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit) gtk+-devel-1:1.2.10-98.fc36.i686 requires glib-devel(x86-32) = 1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10 gtk+-devel-1:1.2.10-98.fc36.x86_64 requires glib-devel(x86-64) = 1:1.2.10-64.fc36, pkgconfig(glib) = 1.2.10 xvattr (maintained by: ppisar, thias) gxvattr-1.3-44.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib- 1.2.so.0()(64bit), libgtk-1.2.so.0()(64bit) hikari (maintained by: fnux, sway-sig) hikari-2.3.3-2.fc36.src requires glib-devel = 1:1.2.10-64.fc36 librcc (maintained by: ivanromanov) librcc-gtk+-0.2.12-20.fc36.i686 requires libgdk-1.2.so.0, libglib- 1.2.so.0, libgmodule-1.2.so.0, libgtk-1.2.so.0 librcc-gtk+-0.2.12-20.fc36.x86_64 requires libgdk-1.2.so.0()(64bit), libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit), libgtk- 1.2.so.0()(64bit) manedit (maintained by: pali) manedit-1.2.1-27.fc36.x86_64 requires libglib-1.2.so.0()(64bit), libgmodule-1.2.so.0()(64bit) tilda (maintained by: hannes, laxathom) tilda-1.5.4-4.fc36.src requires glib-devel = 1:1.2.10-64.fc36 xconvers (maintained by: hobbes1069) xconvers-0.8.3-29.fc36.x86_64 requires libglib-1.2.so.0()(64bit) xdialog (maintained by: konradm) xdialog-2.3.1-30.fc36.x86_64 requires libglib-1.2.so.0()(64bit) alsa-tools (maintained by: perex, timj) alsa-tools-1.2.5-3.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36 alsa-tools-firmware-1.2.5-3.fc36.x86_64 requires alsa-firmware = 1.2.4- 6.fc36 crossfire-client (maintained by: limb) crossfire-client-1.75.2-2.fc36.src requires gtk+-devel = 1:1.2.10- 98.fc36 dillo (maintained by: aarem, atim) dillo-3.0.5-14.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36 freedroidrpg (maintained by: limb) freedroidrpg-1.0-0.fc37.rc2.8.src requires gtk+-devel = 1:1.2.10- 98.fc36 libstroke (maintained by: jhogarth, sophiekovalevsky) libstroke-0.5.1-45.fc36.src requires gtk+-devel = 1:1.2.10-98.fc36 alsa-firmware (maintained by: perex, timj) alsa-firmware-1.2.4-6.fc36.noarch requires alsa-tools-firmware = 1.2.5- 3.fc36 crossfire (maintained by: limb) crossfire-client-images-1.71.0-21.fc36.x86_64 requires crossfire-client = 1.75.2-2.fc36 fvwm (maintained by: jhogarth, mcermak, pertusus, peter) fvwm-2.6.9-7.fc36.src requires libstroke-devel = 0.5.1-45.fc36 fvwm-2.6.9-7.fc36.x86_64 requires libstroke.so.0()(64bit) crossfire-maps (maintained by: limb) crossfire-maps-1.71.0-12.fc36.noarch requires crossfire = 1.71.0- 21.fc36 NsCDE (maintained by: dcavalca) NsCDE-1.4-2.fc36.src requires fvwm = 2.6.9-7.fc36 NsCDE-1.4-2.fc36.x86_64 requires fvwm = 2.6.9-7.fc36 Affected (co)maintainers aarem: glib atim: glib dcavalca: glib fnux: glib hannes: glib hobbes1069: glib ivanromanov: glib jhogarth: glib konradm: glib laxathom: glib limb: glib mcermak: glib pali: glib perex: glib pertusus: glib peter: glib pghmcfc: glib ppisar: glib rdieter: glib sham1: glib sophiekovalevsky: glib sway-sig: glib thias: glib timj: glib Depending packages (rawhide) (20): NsCDE alsa-firmware alsa-tools bubblemon crossfire crossfire-client crossfire-maps dillo freedroidrpg fvwm gnubg gtk+ hikari librcc libstroke manedit tilda xconvers xdialog xvattr FTBFS (rawhide) (1): glib FTBFS (rawhide) (depended on) (1): glib FTBFS (rawhide) (not depended on) (0): -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2022-03-07 16:01:58 UTC Addresses (24): pghm...@fedoraproject.org, rdie...@fedoraproject.org, sh...@fedoraproject.org, l...@fedoraproject.org, ppi...@fedoraproject.org, th...@fedoraproject.org, f...@fedoraproject.org, sway-...@fedoraproject.org, ivanroma...@fedoraproject.org, p...@fedoraproject.org, han...@fedoraproject.org, laxat...@fedoraproject.org
Fedora-36-20220307.n.0 compose check report
No missing expected images. Failed openQA tests: 12/229 (x86_64), 11/161 (aarch64) New failures (same test not failed in Fedora-36-20220306.n.0): ID: 1162863 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1162863 ID: 1162889 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1162889 ID: 1162910 Test: x86_64 KDE-live-iso base_package_install_remove URL: https://openqa.fedoraproject.org/tests/1162910 ID: 1162944 Test: aarch64 Server-dvd-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1162944 ID: 1163023 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1163023 ID: 1163070 Test: x86_64 universal install_simple_encrypted URL: https://openqa.fedoraproject.org/tests/1163070 ID: 1163162 Test: aarch64 universal support_server@uefi URL: https://openqa.fedoraproject.org/tests/1163162 ID: 1163191 Test: aarch64 universal install_iscsi@uefi URL: https://openqa.fedoraproject.org/tests/1163191 Old failures (same test failed in Fedora-36-20220306.n.0): ID: 1162876 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1162876 ID: 1162884 Test: x86_64 Workstation-live-iso eog URL: https://openqa.fedoraproject.org/tests/1162884 ID: 1162907 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1162907 ID: 1162919 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1162919 ID: 1163008 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi URL: https://openqa.fedoraproject.org/tests/1163008 ID: 1163014 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1163014 ID: 1163037 Test: x86_64 Workstation-upgrade gnome_text_editor URL: https://openqa.fedoraproject.org/tests/1163037 ID: 1163038 Test: x86_64 Workstation-upgrade apps_startstop URL: https://openqa.fedoraproject.org/tests/1163038 ID: 1163051 Test: aarch64 Workstation-upgrade eog@uefi URL: https://openqa.fedoraproject.org/tests/1163051 ID: 1163057 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1163057 ID: 1163060 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1163060 ID: 1163091 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1163091 ID: 1163092 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1163092 ID: 1163157 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa.fedoraproject.org/tests/1163157 ID: 1163165 Test: aarch64 universal install_asian_language@uefi URL: https://openqa.fedoraproject.org/tests/1163165 Soft failed openQA tests: 14/229 (x86_64), 10/161 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-36-20220306.n.0): ID: 1162914 Test: x86_64 Silverblue-dvd_ostree-iso eog URL: https://openqa.fedoraproject.org/tests/1162914 ID: 1162932 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1162932 ID: 1163027 Test: x86_64 Workstation-upgrade upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1163027 ID: 1163049 Test: aarch64 Workstation-upgrade upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1163049 ID: 1163089 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/1163089 ID: 1163090 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1163090 ID: 1163095 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1163095 ID: 1163112 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/1163112 ID: 1163113 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1163113 ID: 1163114 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1163114 ID: 1163115 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1163115 ID: 1163129 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1163129 ID: 1163132 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1163132 ID: 1163133 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1163133 ID: 1163134 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1163134 ID: 1163163 Test: aarch64 universal upgrade_server_64bit@uefi URL: https://openqa.fedoraproject.org/tests/116316
F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs == Summary == java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and java-latest-openjdk packages will no longer build i686 subpackages == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: * Product: java and java stack * Responsible WG: java-sig (java and java-maint)(which no longer exists) === Expected schedule === * during march, drop i686 builds from all jdks in fedora rawhide == Detailed Description == Fedora currently ships: * java-1.8.0-openjdk (LTS) * java-11-openjdk (LTS) * java-17-openjdk (LTS) * java-latest-openjdk (STS, jdk18). All those builds on all architectures except jdk8, where arm32 with jit is built by different package. Unluckily, the i686 bit builds of jdk are rotten in upstream. The recent breakage of i686 JIT just before branching nearly killed jdk17 as system jdk feature. The rotting have main visibility with newer GCCs. If GCC bump, and it does, it always triggers new issues in i686 JIT, and there is less and less people to somehow workaround them. Unluckily, there is probably no longer anyone willing to really fix them == Benefit to Fedora == The i686 builds are rotten in usptream, and to patch them localy had become pain. We may be introducing very bugy i686 jdk. Better then to do so, we would rather not ship that at all. This will untie hands of both JDK and GCC developers, who will no longer need to dive into nasty legacy code. == Scope == Change owners * we will simiply stop building i686 pkg in rawhide Other developers * may notice the multilib i686 java missing. * it is up to them to drop i686 builds or to povide workaround (if possible) Other * Release engineering: https://pagure.io/releng/issue/10686 * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == * The upgrade on multilib systems will lead to autoremoval of i686 javastack * which should be minimum - 99% of javastack is noarch == How To Test == install i686 java will result to not packages found == User Experience == User experience on multilib systems will be bad. Bad reasonable. == Dependencies == There are is unknown number of multilib java consumers. I expect some of them may rise voice, but that will have to handled one by one. == Contingency Plan == * Contingency mechanism: return i686 packages * Contingency date: (not provided) == Documentation == Will be neded... == Release Notes == None yet... -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
HEADS UP: ABI-breaking rebuild for ffmpeg in F36+ incoming (drop non-upstream patch)
Hey all, I'm going to do an ABI-breaking update of FFmpeg in F36+ to drop a non-upstream patch that was intended to make it work with Chromium. However, the patch never made it upstream and other FFmpeg builds don't have it anymore, so now we have an ABI incompatibility that needs to be fixed. I will do this later today or tomorrow, depending on when I can make the time for it. Based on a repoquery, these are the only reverse dependencies: * attract-mode * siril * unpaper I'll rebuild those in a side-tag and propose an update. RHBZ reference: https://bugzilla.redhat.com/2061392 -- 真実はいつも一つ！/ 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
how to debug failures inside mock when building takes a long time?
Am 07.03.22 um 13:25 schrieb Miro Hrončok: Building pypy is nontrivial. I don't know if you can "just" build it on x86_64 for i686 without using mock, but you should be able to do it in mock: Btw: How do you handle/fix build issues when you can only build inside mock? So for example your mock build fails because some paths or binaries are wrong and it is not obvious from the error what needs to be changed. In these situations I'd like to have some kind of interactive repl shell similar to pdb. Is there something like that for mock? Or some other trick to fix such problems? I found that fixing a build is really time consuming especially if the error only happens in the %check section and build times are high. I thought about using a reverse shell (+ enable network for mock) but I guess there is a better way to do this? Felix ___ 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
[Test-Announce] [Test Day] Fedora 36 i18n 2022-03-07 through 2022-03-14
Hey Folks, As most of you already know, we have the i18n test week happening now. If you are someone who loves to experience Fedora Linux in your native language and test out the new i18n changes this is your moment. The wiki [0] starts off by telling you what the test day is all about, the test day result page[1] has the test cases which can be executed during this test week! Happy Testing! [0] https://fedoraproject.org/wiki/Test_Day:2022-03-08_I18N_Test_Day [1] https://testdays.fedoraproject.org/events/127 PS : If you have questions, reach out to the @test list or the #fedora-test-day on libera -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED ___ test-announce mailing list -- test-annou...@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora-Rawhide-20220307.n.0 compose check report
Missing expected images: Minimal raw-xz armhfp Compose FAILS proposed Rawhide gating check! 3 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 17/231 (x86_64), 23/161 (aarch64) New failures (same test not failed in Fedora-Rawhide-20220305.n.0): ID: 1162075 Test: x86_64 Workstation-live-iso desktop_login URL: https://openqa.fedoraproject.org/tests/1162075 ID: 1162081 Test: x86_64 Workstation-live-iso evince URL: https://openqa.fedoraproject.org/tests/1162081 ID: 1162151 Test: aarch64 Server-dvd-iso install_resize_lvm@uefi URL: https://openqa.fedoraproject.org/tests/1162151 ID: 1162203 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi URL: https://openqa.fedoraproject.org/tests/1162203 ID: 1162208 Test: aarch64 Workstation-raw_xz-raw.xz base_update_cli@uefi URL: https://openqa.fedoraproject.org/tests/1162208 ID: 1162367 Test: aarch64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/1162367 Old failures (same test failed in Fedora-Rawhide-20220305.n.0): ID: 1162041 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/1162041 ID: 1162042 Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller **GATING** URL: https://openqa.fedoraproject.org/tests/1162042 ID: 1162053 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/1162053 ID: 1162054 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/1162054 ID: 1162055 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/1162055 ID: 1162056 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/1162056 ID: 1162057 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/1162057 ID: 1162106 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/1162106 ID: 1162111 Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1162111 ID: 1162114 Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1162114 ID: 1162161 Test: aarch64 Server-dvd-iso server_freeipa_replication_master@uefi URL: https://openqa.fedoraproject.org/tests/1162161 ID: 1162162 Test: aarch64 Server-dvd-iso install_repository_hd_variation@uefi URL: https://openqa.fedoraproject.org/tests/1162162 ID: 1162164 Test: aarch64 Server-dvd-iso server_role_deploy_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1162164 ID: 1162173 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi URL: https://openqa.fedoraproject.org/tests/1162173 ID: 1162174 Test: aarch64 Server-dvd-iso server_freeipa_replication_replica@uefi URL: https://openqa.fedoraproject.org/tests/1162174 ID: 1162181 Test: aarch64 Server-dvd-iso server_freeipa_replication_client@uefi URL: https://openqa.fedoraproject.org/tests/1162181 ID: 1162185 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi URL: https://openqa.fedoraproject.org/tests/1162185 ID: 1162187 Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi URL: https://openqa.fedoraproject.org/tests/1162187 ID: 1162189 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi URL: https://openqa.fedoraproject.org/tests/1162189 ID: 1162215 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1162215 ID: 1162217 Test: aarch64 Workstation-raw_xz-raw.xz desktop_update_graphical@uefi URL: https://openqa.fedoraproject.org/tests/1162217 ID: 1162243 Test: x86_64 Workstation-upgrade desktop_fprint URL: https://openqa.fedoraproject.org/tests/1162243 ID: 1162256 Test: aarch64 Workstation-upgrade evince@uefi URL: https://openqa.fedoraproject.org/tests/1162256 ID: 1162257 Test: aarch64 Workstation-upgrade desktop_browser@uefi URL: https://openqa.fedoraproject.org/tests/1162257 ID: 1162258 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi URL: https://openqa.fedoraproject.org/tests/1162258 ID: 1162292 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/1162292 ID: 1162293 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/1162293 ID: 1162314 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1162314 ID: 1162330 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1162330 ID: 1162347 Test: aarch64 universal upgrade_minimal_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1162347 ID: 1162358 Test: aarch64 universal install_arabic_language@uefi URL: https://openqa
Re: Dropping 32bit arches from pypy2.7?
On 07. 03. 22 10:51, Victor Stinner wrote: How can someone reproduce the issue? I was asked by a developer running Ubuntu. Is there an easy way to: (*) Get Fedora 36 (*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the command line for that? Building pypy is nontrivial. I don't know if you can "just" build it on x86_64 for i686 without using mock, but you should be able to do it in mock: (*) get any supported fedora, even 34 or 35 (*) dnf install fedpkg mock (*) add the user to the mock group (*) fedpkg clone -a pypy && cd pypy (*) fedpkg srpm (*) mock -r fedora-rawhide-i386 --enablerepo=local pypy-*.src.rpm Untested. Use https://rpm-software-management.github.io/mock/#mock-inside-podman-fedora-toolbox-or-docker-container if the Fedora system in fact a container. -- 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
Fedora 36 compose report: 20220307.n.0 changes
OLD: Fedora-36-20220306.n.0 NEW: Fedora-36-20220307.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
Fedora rawhide compose report: 20220307.n.0 changes
OLD: Fedora-Rawhide-20220305.n.0 NEW: Fedora-Rawhide-20220307.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 1 Dropped packages:1 Upgraded packages: 117 Downgraded packages: 0 Size of added packages: 148.21 KiB Size of dropped packages:111.71 KiB Size of upgraded packages: 4.51 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 1.49 GiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = Package: perl-Crypt-Curve25519-0.06-1.fc37 Summary: Generate shared secret using elliptic-curve Diffie-Hellman function RPMs:perl-Crypt-Curve25519 Size:148.21 KiB = DROPPED PACKAGES = Package: golang-github-microsoft-opengcs-0.3.9-7.fc35 Summary: Guest Compute Service for Linux Hyper-V Container RPMs:golang-github-microsoft-opengcs-devel Size:111.71 KiB = UPGRADED PACKAGES = Package: COPASI-4.34.251-4.fc37 Old package: COPASI-4.34.251-3.fc37 Summary: Biochemical network simulator RPMs: COPASI COPASI-data COPASI-doc COPASI-gui python3-COPASI Size: 54.65 MiB Size change: 5.43 KiB Changelog: * Sat Mar 05 2022 Antonio Trande - 4.34.251-4 - Fix rhbz#2060860 Package: ClanLib06-0.6.5-56.fc37 Old package: ClanLib06-0.6.5-55.fc36 Summary: Version 0.6 of this Cross platform C++ game library RPMs: ClanLib06 ClanLib06-devel Size: 5.16 MiB Size change: 5.26 KiB Changelog: * Sun Mar 06 2022 Hans de Goede - 0.6.5-56 - Use Fedora's standard LDFLAGS when linking - Stop using obsolete pthread_mutexattr_setkind_np (rhbz#2045209) Package: ClanLib1-1.0.0-37.fc37 Old package: ClanLib1-1.0.0-36.fc36 Summary: Cross platform C++ game library RPMs: ClanLib1 ClanLib1-devel Size: 11.89 MiB Size change: -3.69 KiB Changelog: * Sun Mar 06 2022 Hans de Goede - 1.0.0-37 - Stop using obsolete pthread_mutexattr_setkind_np, fixing FTBFS of dependend packages Package: adwaita-qt-1.4.1-3.fc37 Old package: adwaita-qt-1.4.1-2.fc36 Summary: Adwaita theme for Qt-based applications RPMs: adwaita-qt5 adwaita-qt6 libadwaita-qt5 libadwaita-qt5-devel libadwaita-qt6 libadwaita-qt6-devel Size: 2.68 MiB Size change: 519.26 KiB Changelog: * Sat Mar 05 2022 Neal Gompa - 1.4.1-3 - Small cleanups to the packaging Package: auriferous-1.0.1-36.fc37 Old package: auriferous-1.0.1-35.fc35 Summary: Game inspired by the classic Loderunner RPMs: auriferous Size: 62.27 MiB Size change: 27.97 KiB Changelog: * Wed Jan 19 2022 Fedora Release Engineering - 1.0.1-36 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Package: ballbuster-1.0-37.fc37 Old package: ballbuster-1.0-36.fc35 Summary: Move the paddle to bounce the ball and break all the bricks RPMs: ballbuster Size: 7.04 MiB Size change: 2.39 KiB Changelog: * Wed Jan 19 2022 Fedora Release Engineering - 1.0-37 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Package: c4core-0.1.9-1.fc37 Old package: c4core-0.1.8-3.fc36 Summary: C++ core utilities RPMs: c4core c4core-devel Size: 532.61 KiB Size change: 23.06 KiB Changelog: * Tue Mar 01 2022 Benjamin A. Beasley 0.1.9-1 - Update to 0.1.9 (close RHBZ#2057741) Package: c4fs-0.0.1-5.20220113git8ffaf65.fc37 Old package: c4fs-0.0.1-4.20220113git8ffaf65.fc36 Summary: C++ file system utilities RPMs: c4fs c4fs-devel Size: 172.48 KiB Size change: 1.63 KiB Changelog: * Sat Mar 05 2022 Benjamin A. Beasley 0.0.1-5 - Rebuild for c4core 0.1.9 Package: c4log-0.0.1^20220113gitb8b86f3-2.fc37 Old package: c4log-0.0.1^20220113gitb8b86f3-1.fc37 Summary: C++ type-safe logging, mean and lean RPMs: c4log c4log-devel Size: 129.11 KiB Size change: 2.16 KiB Changelog: * Sat Mar 05 2022 Benjamin A. Beasley 0.0.1^20220113gitb8b86f3-2 - Rebuild for c4core 0.1.9 Package: chromium-99.0.4844.51-1.fc37 Old package: chromium-98.0.4758.102-1.fc37 Summary: A WebKit (Blink) powered web browser that Google doesn't want you to use RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 300.19 MiB Size change: -6.00 MiB Changelog: * Sat Mar 05 2022 Tom Callaway - 99.0.4844.5-1 - update to 99.0.4844.5 Package: clanbomber-1.05-41.fc37 Old package: clanbomber-1.05-40.fc35 Summary: Lay bombs and Blast the other players of the field game using ClanLib RPMs: clanbomber Size: 7.71 MiB Size change: 21.84 KiB Changelog: * Wed Jan 19 2022 Fedora Release Engineering - 1.05-41 - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild Package: copyq-6.1.0-1.fc37 Old package: copyq-6.0.1-3.fc37 Summary: Advanced clipboard manager RPMs: copyq Size:
Re: Dropping 32bit arches from pypy2.7?
How can someone reproduce the issue? I was asked by a developer running Ubuntu. Is there an easy way to: (*) Get Fedora 36 (*) Build PyPy 2.7 for 32-bit: can it be done on x86-64? What is the command line for that? Victor ___ 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-20220307.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-20220306.0): ID: 1161992 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1161992 ID: 1161998 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1161998 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On 07. 03. 22 10:42, Miro Hrončok wrote: The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-03-07.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change ... nodejs-backbone nodejs-sig, orphan, vjancik 0 weeks ago This one has an interesting impact on Python packages. python3-notebook requires js-backbone and hence the Orphaned packages report lists "too many dependencies for nodejs-backbone". However, if this is retired, I know a way forward to re-bundle it in python3-notebook, as does upstream. Unfortunately, it is not possible to do it before it is retired. -- 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
Orphaned packages looking for new maintainers
The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ Full report available at: https://churchyard.fedorapeople.org/orphans-2022-03-07.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change augeas-vala orphan 1 weeks ago beanstalk-client orphan 0 weeks ago bmap-toolsorphan 0 weeks ago deltarpm jdieter, orphan 0 weeks ago ghc-dbus orphan 0 weeks ago ghc-libxml-saxorphan 0 weeks ago gimp-fourier-plugin orphan 1 weeks ago gocl orphan 1 weeks ago javahelp2 orphan 3 weeks ago linenoise orphan 0 weeks ago lua-ldap orphan 0 weeks ago nautilus-image-converter orphan, timj 4 weeks ago nodejs-backbone nodejs-sig, orphan, vjancik 0 weeks ago php-pecl-datadog_traceorphan 5 weeks ago python-aiohttp-cors orphan, python-sig 0 weeks ago python-aiohttp-negotiate orphan 0 weeks ago python-blessings orphan 0 weeks ago python-fastimport orphan 0 weeks ago python-hkdf orphan 1 weeks ago python-lrparsing orphan 0 weeks ago python-magic-wormhole orphan 1 weeks ago python-magic-wormhole-mailbox-orphan 1 weeks ago server python-magic-wormhole-transit-orphan 1 weeks ago relay python-ofxparse orphan 0 weeks ago python-phonenumbers orphan 0 weeks ago python-plyvel orphan 0 weeks ago python-pystalkorphan 0 weeks ago python-spake2 orphan 1 weeks ago python-txtorcon orphan 1 weeks ago python-uinput orphan 1 weeks ago python-unidifforphan 0 weeks ago qcommandline orphan 0 weeks ago rpg-cli orphan, rust-sig 3 weeks ago rubygem-database_cleaner orphan 2 weeks ago rubygem-ruby-ntlm orphan 5 weeks ago ssh-contact orphan 4 weeks ago telepathy-farstream orphan 4 weeks ago telepathy-idleorphan 4 weeks ago telepathy-logger orphan, rishi4 weeks ago vorbisgainorphan 4 weeks ago w_scanorphan 3 weeks ago xorg-sgml-doctoolsairlied, ajax, alexl, caillon, 5 weeks ago caolanm, glisse, mbarnes, orphan, rhughes, rstrode, slaanesh, ssp, whot xorg-x11-docs airlied, ajax, alexl, caillon, 5 weeks ago caolanm, glisse, mbarnes, orphan, rhughes, rstrode, slaanesh, ssp, whot xorg-x11-drv-sisusb airlied, aj
Fedora-Cloud-35-20220307.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-35-20220306.0): ID: 1161918 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1161918 ID: 1161924 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1161924 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
