Re: Announcing fmt library soversion bump
On 19. 07. 22 1:28, Miro Hrončok wrote: dolphin https://bugzilla.redhat.com/show_bug.cgi?id=2108353 Sorry, dolphin-emu. -- 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: Announcing fmt library soversion bump
On 10. 07. 22 19:43, Vitaly Zaitsev via devel wrote: Hello. fmt 9.0.x update will include a soversion bump from .8 to .9. It has both API and ABI changes. Changelog: https://github.com/fmtlib/fmt/releases/tag/9.0.0 The list of affected packages in Rawhide: 0ad OpenImageIO cantera ceph dolphin-emu domoticz folly libsonata mkvtoolnix sdrpp spdlog vcpkg zswap-cli I can rebuild only spdlog, vcpkg and zswap-cli. For others, I will need proven-packagers assistance. Please use the f37-build-side-54844 side tag. I will merge it into Rawhide later. I see https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee990d1f61 was pushed with just a handful of builds, while many others are broken. What happened here? cachelib https://bugzilla.redhat.com/show_bug.cgi?id=2108349 cantera https://bugzilla.redhat.com/show_bug.cgi?id=2108350 ceph https://bugzilla.redhat.com/show_bug.cgi?id=2108351 dolphin https://bugzilla.redhat.com/show_bug.cgi?id=2108353 easyrpg-player https://bugzilla.redhat.com/show_bug.cgi?id=2108354 fb303 https://bugzilla.redhat.com/show_bug.cgi?id=2108355 fizz https://bugzilla.redhat.com/show_bug.cgi?id=2108356 freeopcua https://bugzilla.redhat.com/show_bug.cgi?id=2108357 gerbera https://bugzilla.redhat.com/show_bug.cgi?id=2108358 mangohud https://bugzilla.redhat.com/show_bug.cgi?id=2108361 proxygen https://bugzilla.redhat.com/show_bug.cgi?id=2108362 rstudio https://bugzilla.redhat.com/show_bug.cgi?id=2108367 sdrpp https://bugzilla.redhat.com/show_bug.cgi?id=2108368 wangle https://bugzilla.redhat.com/show_bug.cgi?id=2108369 -- 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: Updated criteria proposal: networking requirements
On Fri, 2022-06-03 at 16:35 -0700, Adam Williamson wrote: > Hi folks! > > Some time ago I proposed some specific networking release criteria. I > revived the thread back in February, and meeting discussion suggested > we should be more intentional and specific about wifi requirements. So, > looking at it again, I suggest adding an additional footnote: Hi once more folks. As overall response to the proposal has been positive and it doesn't seem to make sense to add dnssec requirements, I am going ahead and publishing this most recent draft into the Basic criteria today. We can move them later if Basic turns out to be too early. Thanks everyone! -- 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: Announcing fmt library soversion bump
On 18/07/2022 23:28, Adam Williamson wrote: Looks like it's failing on some warnings as it's being built with - Wall... Another issue: /builddir/build/BUILD/ceph-17.2.1/src/mon/LogMonitor.cc:418:21: error: no matching function for call to 'format_to(fmt::v9::memory_buffer&, const char [4], const LogEntry&)' 418 | fmt::format_to(file_log_buffer, "{}\n", le); | ~~^ In file included from /usr/include/fmt/format.h:48, from /builddir/build/BUILD/ceph-17.2.1/src/mon/LogMonitor.h:22: /usr/include/fmt/core.h:3190:17: note: candidate: 'templateOutputIt, class ... T, typename std::enable_ifchar>::value, int>::type > OutputIt fmt::v9::format_to(OutputIt, format_string, T&& ...)' 3190 | FMT_INLINE auto format_to(OutputIt out, format_string fmt, T&&... args) | ^ /usr/include/fmt/core.h:3190:17: note: template argument deduction/substitution failed: /usr/include/fmt/core.h:3189:11: error: no type named 'type' in 'struct std::enable_if' 3189 | FMT_ENABLE_IF(detail::is_output_iteratorchar>::value)> | ^ -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: Announcing fmt library soversion bump
On Mon, 2022-07-18 at 22:15 +0200, Vitaly Zaitsev via devel wrote: > On 18/07/2022 21:05, Adam Williamson wrote: > > We could temporarily drop Boxes from Workstation, I guess, especially > > since it doesn't work right now due to libsoup hilarity[0]. But we > > should really have a proper fix ASAP. > > Fixed: https://src.fedoraproject.org/rpms/ceph/pull-request/5 Thanks! But apparently not completely fixed yet: https://koji.fedoraproject.org/koji/taskinfo?taskID=89669510 Looks like it's failing on some warnings as it's being built with - Wall... -- 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: Koji ppc64le build failure
On Mon, Jul 18, 2022 at 09:28:42PM +0200, Dan Horák wrote: > On Mon, 18 Jul 2022 11:39:58 -0700 > Kevin Fenzi wrote: > > > On Mon, Jul 18, 2022 at 11:59:49AM +0100, Richard W.M. Jones wrote: > > > On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote: > > > > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote: > > > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509 > > > > > > > > > > On ppc64le: > > > > > FAIL: test-checkwrite.sh > > > > > > > > > > There should be a core dump associated with this failure. Is it > > > > > possible someone with Koji access could look to see if this is still > > > > > around and capture it? (Even just a full stack trace would be useful) > > > > > > > > > > We've been seeing this error occasionally (same test, only on ppc64le) > > > > > for a few weeks. I reserved a ppc64le machine at Red Hat last week > > > > > and ran this test on basically exactly the same combination of > > > > > software thousands of times, and it didn't fail even once in that > > > > > time, so I'm out of ideas how to reproduce it for myself. > > > > > > > > Core at: > > > > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst > > > > > > > > Module libtasn1.so.6 with build-id > > > > 460fc6bd3f93e57e7d593080f58952f61cdb344a > > > > Stack trace of thread 2744170: > > > > #0 0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + > > > > 0xb9b6c) > > > > ELF object binary architecture: PowerPC64 > > > > > > Sorry, I realised that the core dump won't work without the > > > executable. Is /server/nbdkit still around? (Note there's > > > another "nbdkit" binary in the top build directory, which is _not_ the > > > server.) > > > > To circle back to the list, it sounds like you got it to happen locally? > > I don't think so, I believe Rich needs the binary that produced the > coredump. I have grabbed it and it's now > http://fedora.danny.cz/tmp/nbdkit Thanks for your help! I did finally manage to reproduce it locally (although not fix it so far ...). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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 proposal: Emacs 28 (Self-Contained Change proposal)
Dear Bhavin, A big "yay!" for packaging 28.1; I've been running my own emacs.spec modifications to play around with this, for one reason, and one reason alone: PGTK support. Without it, emacs is virtually unusable on Wayland on hidpi screens with the compositors I've used, as xwayland simply scales pixel-images. Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose that we do not only package an emacs-pgtk binary, but also, that it becomes what you get by default (i.e. when you install and run `emacs`). Felt too big a change to propose for me, a GNU emacs newbie, but I was surprised to see a change proposal for a normal software version bump of emacs (it's not like say GNU Radio makes a change proposal every time they bump version), but then not include that, which feels a bit like a missed chance to round-off the wayland experience of Fedora! Best regards, Marcus On 18.07.22 19:29, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Emacs_28 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files. == Owner == * Name: [[User:Bhavin192| Bhavin Gandhi]] * Email: bhavin...@fedoraproject.org == Detailed Description == The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files. == Benefit to Fedora == This major version of Emacs has bugfixes and new features which also improve the overall speed of Emacs. == Scope == * Proposal owners: Upgrade the Emacs package to 28.1 * Other developers: N/A * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Users might see some warnings while their installed Emacs packages get natively compiled after first launch post the upgrade. These warnings won't break any functionality, though the users are encouraged to update their Emacs packages. == How To Test == # Run dnf update emacs # Open Emacs and check if inbuilt functionalities and packages work as indented. == User Experience == https://www.gnu.org/software/emacs/#Releases * Lisp files are natively compiled, this results in speed improvements for most of the functionalities * Much improved display of Emoji and Emoji sequences * New system for documenting groups of functions == Dependencies == N/A == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == * https://www.gnu.org/software/emacs/news/NEWS.28.1 * https://src.fedoraproject.org/rpms/emacs/pull-request/12 == Release Notes == The upstream release notes are available at https://www.gnu.org/software/emacs/news/NEWS.28.1 These can also be accessed from within Emacs by doing `C-h n`. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS UP] Sphinx 5 and docutils 0.18.1 coming to Rawhide on July 11th
Hello, The packages have been updated in Fedora Rawhide. A big thank you to everyone who helped mitigate the impact of this update. You can now test your packages using Koji scratch build as you're used to. $ koji build --scratch rawhide There are still some packages with open Bugzilla tickets. If you're a maintainer of such package, please take a look at it. Lastly, in case of troubles feel free to reach me through this thread or ping on #fedora-python on libera.chat (ksurma). I'll try to be of help as much as I can. Cheers, Karolina On 6/30/22 17:34, Karolina Surma wrote: > Hello packagers, > > The new major version of the popular documentation framework Sphinx has > been recently released[0]. It brings many changes, among which there is > support of docutils 0.18.1. We aim to update both packages together in > Fedora Rawhide on **July 11th**. > > As usual, an ongoing attempt to smoothly integrate the updates takes > place using Copr[1]. There are some packages impacted with the new > changes. Please take time to review an fix the package, or coordinate > with the upstream. > > If your package hasn't succeeded to build with Python 3.11 yet, we can't > test whether it will work with this update. > > > Common issues and mitigation > > - `None` is no longer accepted as value of `language` in conf.py > Solution: Use `language = 'en'` instead. > > - Build/ tests fail with: `AttributeError: 'path' object has no > attribute 'text'` > Solution: use `path.read_text()` instead > > > Test your package locally in mock using the provided test Copr > > $ mock -r fedora-rawhide-x86_64 > --addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/ > --no-clean > $ mock -r fedora-rawhide-x86_64 > --addrepo=https://download.copr.fedorainfracloud.org/results/ksurma/sphinx-5/fedora-rawhide-x86_64/ > shell > > > Packages that pin Sphinx and docutils to lower versions than are about > to be introduced, and will effectively stop working after the update has > reached Rawhide: > > Sphinx < 5: > python-h2-0:4.1.0-7.fc37.src > python-priority-0:2.0.0-7.fc37.src > python-sphinx-panels-0:0.6.0-3.fc37.src > python-sphinx-tabs-0:3.1.0-7.fc37.src > python3-sphinxcontrib-zopeext-0:0.3.2-3.fc37.noarch > > docutils < 0.18: > python-sphinx-tabs-0:3.1.0-7.fc37.src > python3-sphinx_rtd_theme-0:1.0.0-6.fc37.noarch > > > Full list of known affected packages > > Maintainers by package: > copr-keygen clime dturecek frostyx msuchy praiskup > coq amdunn jjames > diceware kushal > kea fjanus mosvald zdohnal > libcamerajavierm > liblognorm alakatos rsroka zfridric > python-djangobkabrda churchyard jdornak mrunge rdopiera salimma > sgallagh > python-graphviz eclipseo > python-h2eclipseo > python-pikepdf qulogic zdohnal > python-priority eclipseo > python-sphinx-panels qulogic > python-sphinx-tabs hobbes1069 > python-sphinx_rtd_theme jjames ksurma piotrp > python-sphinxcontrib-bibtex jjames > python-sphinxcontrib-htmlhelp churchyard cstratak > python-sphinxcontrib-jsmath churchyard cstratak > python-sphinxcontrib-qthelp churchyard cstratak > python-sphinxcontrib-zopeext jjames > > Packages by maintainer: > alakatos liblognorm > amdunn coq > bkabrdapython-django > churchyard python-django python-sphinxcontrib-htmlhelp > python-sphinxcontrib-jsmath python-sphinxcontrib-qthelp > clime copr-keygen > cstratak python-sphinxcontrib-htmlhelp python-sphinxcontrib-jsmath > python-sphinxcontrib-qthelp > dturecek copr-keygen > eclipseo python-graphviz python-h2 python-priority > fjanus kea > frostyxcopr-keygen > hobbes1069 python-sphinx-tabs > javiermlibcamera > jdornakpython-django > jjames coq python-sphinx_rtd_theme python-sphinxcontrib-bibtex > python-sphinxcontrib-zopeext > ksurma python-sphinx_rtd_theme > kushal diceware > mosvaldkea > mrunge python-django > msuchy copr-keygen > piotrp python-sphinx_rtd_theme > praiskup copr-keygen > qulogicpython-pikepdf python-sphinx-panels > rdopiera python-django > rsroka liblognorm > salimmapython-django > sgallagh python-django > zdohnalkea python-pikepdf > zfridric liblognorm > > > Cheers, > Karolina Surma > > > [0] https://www.sphinx-doc.org/en/master/changes.html > [1] https://copr.fedorainfracloud.org/coprs/ksurma/sphinx-5/ ___ 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: Announcing fmt library soversion bump
On 18/07/2022 21:05, Adam Williamson wrote: We could temporarily drop Boxes from Workstation, I guess, especially since it doesn't work right now due to libsoup hilarity[0]. But we should really have a proper fix ASAP. Fixed: https://src.fedoraproject.org/rpms/ceph/pull-request/5 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: Koji ppc64le build failure
On Mon, 18 Jul 2022 11:39:58 -0700 Kevin Fenzi wrote: > On Mon, Jul 18, 2022 at 11:59:49AM +0100, Richard W.M. Jones wrote: > > On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote: > > > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote: > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509 > > > > > > > > On ppc64le: > > > > FAIL: test-checkwrite.sh > > > > > > > > There should be a core dump associated with this failure. Is it > > > > possible someone with Koji access could look to see if this is still > > > > around and capture it? (Even just a full stack trace would be useful) > > > > > > > > We've been seeing this error occasionally (same test, only on ppc64le) > > > > for a few weeks. I reserved a ppc64le machine at Red Hat last week > > > > and ran this test on basically exactly the same combination of > > > > software thousands of times, and it didn't fail even once in that > > > > time, so I'm out of ideas how to reproduce it for myself. > > > > > > Core at: > > > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst > > > > > > Module libtasn1.so.6 with build-id > > > 460fc6bd3f93e57e7d593080f58952f61cdb344a > > > Stack trace of thread 2744170: > > > #0 0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + > > > 0xb9b6c) > > > ELF object binary architecture: PowerPC64 > > > > Sorry, I realised that the core dump won't work without the > > executable. Is /server/nbdkit still around? (Note there's > > another "nbdkit" binary in the top build directory, which is _not_ the > > server.) > > To circle back to the list, it sounds like you got it to happen locally? I don't think so, I believe Rich needs the binary that produced the coredump. I have grabbed it and it's now http://fedora.danny.cz/tmp/nbdkit Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On Mon, 2022-07-18 at 12:05 -0700, Adam Williamson wrote: > On Mon, 2022-07-18 at 13:47 -0400, Kaleb Keithley wrote: > > On Sun, Jul 17, 2022 at 3:56 PM wrote: > > > > > > > > Same for ceph. I tried unsucessfully to rebuild it. The bug is not yet > > > upstream, only in Debian yet > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014549 > > > > > > I opened https://tracker.ceph.com/issues/56610 > > This is a problem, because it breaks the Rawhide compose: gnome-boxes > is part of Workstation, it requires libvirt-daemon-kvm, that requires > libvirt-daemon-driver-storage, that requires libvirt-daemon-driver- > storage-rbd, and that requires librbd1 which is part of ceph. > > We could temporarily drop Boxes from Workstation, I guess, especially > since it doesn't work right now due to libsoup hilarity[0]. But we > should really have a proper fix ASAP. Sorry, that libsoup hilarity[0] reference: [0]: https://bugzilla.redhat.com/show_bug.cgi?id=2105116 -- 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 proposal: BIND 9.18 (Self-Contained Change proposal)
On Sat, 2022-07-16 at 13:02 +0300, Alexander Bokovoy wrote: > We tested this extensively in FreeIPA upstream CI using a separate COPR > repo. Current FreeIPA versions in Fedora are ready and rawhide version of > bind-dyndb-ldap only needs a rebuild. > > I'm currently on a sick leave but Peter should be able to handle it with > his bind/bind-dyndb-ldap maintainer rights. Thanks, that's very reassuring! > > On Saturday, July 16, 2022, Adam Williamson > wrote: > > On Fri, 2022-07-15 at 17:30 -0400, Ben Cotton wrote: > > > > > > == Scope == > > > * Proposal owners: The update required update of bind-dyndb-ldap > > > package (part of Freeipa suite), but otherwise it is isolated change. > > > > That's a big 'but'. FreeIPA is a release-blocking part of Server, one > > of our Editions. We've seen issues before between bind upgrades and > > FreeIPA. I would like to see assurances that this is being planned > > together with FreeIPA folks and resources will be in place to ensure > > FreeIPA is fully tested and working when this is deployed. > > -- > > 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 > > > > -- > ___ > server mailing list -- ser...@lists.fedoraproject.org > To unsubscribe send an email to server-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/ser...@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure -- 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: Announcing fmt library soversion bump
On Mon, 2022-07-18 at 13:47 -0400, Kaleb Keithley wrote: > On Sun, Jul 17, 2022 at 3:56 PM wrote: > > > > > Same for ceph. I tried unsucessfully to rebuild it. The bug is not yet > > upstream, only in Debian yet > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014549 > > > I opened https://tracker.ceph.com/issues/56610 This is a problem, because it breaks the Rawhide compose: gnome-boxes is part of Workstation, it requires libvirt-daemon-kvm, that requires libvirt-daemon-driver-storage, that requires libvirt-daemon-driver- storage-rbd, and that requires librbd1 which is part of ceph. We could temporarily drop Boxes from Workstation, I guess, especially since it doesn't work right now due to libsoup hilarity[0]. But we should really have a proper fix ASAP. -- 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
Fedora-IoT-36-20220718.0 compose check report
No missing expected images. Failed openQA tests: 2/15 (x86_64), 1/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20220717.0): ID: 1329641 Test: x86_64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1329641 ID: 1329645 Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation@uefi URL: https://openqa.fedoraproject.org/tests/1329645 Old failures (same test failed in Fedora-IoT-36-20220717.0): ID: 1329647 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1329647 Passed openQA tests: 13/15 (x86_64), 14/15 (aarch64) New passes (same test not passed in Fedora-IoT-36-20220717.0): ID: 1329644 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1329644 ID: 1329646 Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1329646 ID: 1329651 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi URL: https://openqa.fedoraproject.org/tests/1329651 ID: 1329661 Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi URL: https://openqa.fedoraproject.org/tests/1329661 Installed system changes in test aarch64 IoT-dvd_ostree-iso install_default_upload@uefi: System load changed from 0.34 to 0.11 Previous test data: https://openqa.fedoraproject.org/tests/1329129#downloads Current test data: https://openqa.fedoraproject.org/tests/1329648#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: F37 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
On Mon, Jul 18, 2022 at 01:30:14PM +0200, Jiri Konecny wrote: > Hi Kevin, > > Dne 16. 07. 22 v 21:35 Kevin Fenzi napsal(a): > > ...snip... > > > For this we will create a self-contained boot.iso style image with a > > > built-in tar-payload (so that the image can work even without network > > > access) based on the latest Anaconda upstream code. > > What packages will be in this tar-payload? > We are planning to use payload from F37 Workstation GA. So it will install > fully functional Fedora 37. The side benefit will be that the payload is > already tested. Ah, ok. You might add this to the change page? > > And can you use the boot.iso to do netinstalls against the network > > respositories, or are you restricted to the tar-payload contents? > Not yet, we are missing Software selection and Source management. This > version is really a first usable image which enables to select disks and > start the installation. However, it's a good base for us for future > improvements so the ISO can be updated with new features and we can get > feedback soon. Makes sense. > > > > ...snip... > > > == Scope == > > > * Proposal owners: > > > The Anaconda team will setup and maintain an automated Web UI preview > > > image creation pipeline, with the image being available via a web > > > server on the Fedora infrastructure. > > So, you will need space to place these images in Fedora Infrastructure > > and nothing else right now from Infra&Releng? > Yes, we just need a publicly accessible storage, where we can upload the > ISO. Right now, we are thinking about > https://fedorapeople.org/groups/anaconda/. Do you think it's a good idea > Kevin or would you recommend us something else? That would work ok I guess. We could also give you space in https://dl.fedoraproject.org/alt/ Or an s3 bucket. Whatever works. 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: Koji ppc64le build failure
On Mon, Jul 18, 2022 at 11:59:49AM +0100, Richard W.M. Jones wrote: > On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote: > > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote: > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509 > > > > > > On ppc64le: > > > FAIL: test-checkwrite.sh > > > > > > There should be a core dump associated with this failure. Is it > > > possible someone with Koji access could look to see if this is still > > > around and capture it? (Even just a full stack trace would be useful) > > > > > > We've been seeing this error occasionally (same test, only on ppc64le) > > > for a few weeks. I reserved a ppc64le machine at Red Hat last week > > > and ran this test on basically exactly the same combination of > > > software thousands of times, and it didn't fail even once in that > > > time, so I'm out of ideas how to reproduce it for myself. > > > > Core at: > > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst > > > > Module libtasn1.so.6 with build-id > > 460fc6bd3f93e57e7d593080f58952f61cdb344a > > Stack trace of thread 2744170: > > #0 0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + 0xb9b6c) > > ELF object binary architecture: PowerPC64 > > Sorry, I realised that the core dump won't work without the > executable. Is /server/nbdkit still around? (Note there's > another "nbdkit" binary in the top build directory, which is _not_ the > server.) To circle back to the list, it sounds like you got it to happen locally? 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: F37 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)
Unfortunately, the only machine I have access to with an HDD as the system drive is running Ubuntu 20.04 LTS, which doesn’t have a multi-threaded version of fixfiles. So I can’t test this on an HDD-only system. Still, here are the timings on a 4-core Atom machine with a SATA SSD and a large SATA HDD data drive mounted at /srv: $ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 1 restore' […] real 6m39.521s user 5m6.599s sys 0m42.000s $ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 0 restore' […] real 3m16.602s user 5m25.444s sys 0m50.843s I took care to drop various kernel caches, especially including dentry and inode caches, to make this more reproducible. Here are the timings on a very modern 16-core machine with NVMe SSD storage: $ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 1 restore' […] real 3m17.277s user 2m42.447s sys 0m24.403s $ sudo bash -c 'sync; for i in $(seq 1 3); do echo $i > /proc/sys/vm/drop_caches; done; time fixfiles -T 0 restore' […] real 0m58.154s user 4m27.209s sys 0m58.127s On 7/18/22 11:48, Gary Buhrmaster wrote: On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach wrote: Dan Čermák writes: Just out of curiosity, how large is the speedup typically? It depends on the number of threads your machine has. But you could get some data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0 restore` on a running system. The following times are reported on my workstation: Has anyone run such a test on a system using classic ("spinning rust") HDDs? It is sometimes the case that parallelizing activities that are I/O intensive can result in excessive seek activity that can result in rather elongated elapsed times (much worse than single threaded operation). ___ devel mailing list --devel@lists.fedoraproject.org To unsubscribe send an email todevel-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: F37 proposal: Mumble 1.4 (Self-Contained Change proposal)
On 18/07/2022 19:29, Ben Cotton wrote: Update the Mumble voice chat application from 1.3 to 1.4. +1. I'm using 1.4.x self-built and it works fine. This change relocates that file in an RPM scriptlet to align with upstream. The old path will become a compatibility symlink to the new path. Please guard this scriptlet with %triggerun: %triggerun -- %{name}-server < 1.3.4-8 # relocation of config file if [ -f %{_sysconfdir}/murmur/murmur.ini ]; then mv %{_sysconfdir}/murmur/murmur.ini %{_sysconfdir}/murmur.ini fi -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: Announcing fmt library soversion bump
On Sun, Jul 17, 2022 at 3:56 PM wrote: > > Same for ceph. I tried unsucessfully to rebuild it. The bug is not yet > upstream, only in Debian yet > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014549 I opened https://tracker.ceph.com/issues/56610 -- Kaleb ___ 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 proposal: Mumble 1.4 (Self-Contained Change proposal)
On 7/18/22 12:29 PM, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Mumble1.4 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the Mumble voice chat application from 1.3 to 1.4. [Snip] * Enable the native PipeWire audio backend * Rename the Mumble server package from murmur to mumble-server, per upstream preference * Relocate Mumble server configuration file from /etc/murmur/murmur.ini to /etc/murmur.ini, per upstream preference [Snip] Excellent, glad to see the changes to follow upstream. ___ 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: Announcing fmt library soversion bump
On 18/07/2022 19:12, Kaleb Keithley wrote: Do you have a link to the failed build? https://koji.fedoraproject.org/koji/taskinfo?taskID=89606207 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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
F37 proposal: Mumble 1.4 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Mumble1.4 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update the Mumble voice chat application from 1.3 to 1.4. == Owner == * Name: [[User:carlwgeorge| Carl George]] * Email: c...@redhat.com == Detailed Description == Earlier this year the Mumble project released a new major version. The full list of new features can be found in the [https://www.mumble.info/blog/mumble-1.4.230/ upstream release notes]. This change also involves several notable packaging changes. * Enable the native PipeWire audio backend * Rename the Mumble server package from murmur to mumble-server, per upstream preference * Relocate Mumble server configuration file from /etc/murmur/murmur.ini to /etc/murmur.ini, per upstream preference == Feedback == == Benefit to Fedora == Mumble is a popular voice chat application. It is commonly used for gaming and podcasts. Updating the Fedora package to the latest upstream version ensures that Fedora Linux continues to be an attractive operating system for those communities. == Scope == * Proposal owners: ** Build version 1.4.x in carlwgeorge/mumble copr ** Test copr packages ** Build version 1.4.x in appropriate Fedora branches * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == The Mumble developers prefer distributions to name the server package mumble-server. Currently this is named murmur in Fedora. This change renames the server package to align with upstream. The required provides/obsoletes will be added per the packaging guidelines. The Mumble developers prefer the server configuration file to be /etc/murmur.ini. Currently this file is /etc/murmur/murmur.ini in Fedora. This change relocates that file in an RPM scriptlet to align with upstream. The old path will become a compatibility symlink to the new path. == How To Test == As Mumble is voice chat software, to test this change you will need a microphone and headphones/speakers. The carlwgeorge/mumble copr repository contains the updated packages. Install the mumble package to test the client. Install the mumble-server package to test the server. If you have other Mumble servers you routinely connect to, connect to them with the updated mumble package. If you are familiar with setting up a Mumble server, set one up with the existing 1.3.x packages and then update to the 1.4.x packages. Verify that the server configuration file gets relocated as described in this change. == User Experience == Users will have the 1.4.x version of Mumble available, with all the upstream features that provides. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: revert to Mumble 1.3 with an epoch * Contingency deadline: beta freeze * Blocks release? no == Documentation == * https://www.mumble.info/blog/mumble-1.4.230/ == Release Notes == Mumble 1.4 is available in Fedora 37. -- 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
F37 proposal: Emacs 28 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Emacs_28 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Update GNU Emacs to 28.1 release. This release includes a wide variety of new features, including native compilation of Lisp files. == Owner == * Name: [[User:Bhavin192| Bhavin Gandhi]] * Email: bhavin...@fedoraproject.org == Detailed Description == The Emacs package will be updated to 28.1 release of GNU Emacs. This will have native compilation feature enabled, and will package additional natively compiled Lisp files. == Benefit to Fedora == This major version of Emacs has bugfixes and new features which also improve the overall speed of Emacs. == Scope == * Proposal owners: Upgrade the Emacs package to 28.1 * Other developers: N/A * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Users might see some warnings while their installed Emacs packages get natively compiled after first launch post the upgrade. These warnings won't break any functionality, though the users are encouraged to update their Emacs packages. == How To Test == # Run dnf update emacs # Open Emacs and check if inbuilt functionalities and packages work as indented. == User Experience == https://www.gnu.org/software/emacs/#Releases * Lisp files are natively compiled, this results in speed improvements for most of the functionalities * Much improved display of Emoji and Emoji sequences * New system for documenting groups of functions == Dependencies == N/A == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), No == Documentation == * https://www.gnu.org/software/emacs/news/NEWS.28.1 * https://src.fedoraproject.org/rpms/emacs/pull-request/12 == Release Notes == The upstream release notes are available at https://www.gnu.org/software/emacs/news/NEWS.28.1 These can also be accessed from within Emacs by doing `C-h n`. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Announcing fmt library soversion bump
On Sun, Jul 17, 2022 at 3:56 PM wrote: > > Same for ceph. I tried unsucessfully to rebuild it. The bug is not yet > upstream, only in Debian yet > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014549 > Do you have a link to the failed build? -- Kaleb ___ 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: Announcing fmt library soversion bump
On 17/07/2022 21:55, zebo...@gmail.com wrote: Same for ceph. I tried unsucessfully to rebuild it. Can you try this workaround: %global optflags %(echo %{optflags} -DFMT_DEPRECATED_OSTREAM) -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: Announcing fmt library soversion bump
On 18/07/2022 18:18, Richard Shaw wrote: That worked for now. What's the long term fix? It will work until the next major release - 10.0.0. All upstreams need to update to the new API? Yes. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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: Golang Mass Rebuild
Hi Tomáš, Jul 18, 2022 1:42:30 AM Tomas Hrcka : > Fedora release engineering is running a mass rebuild of rawhide on 20.6., if > your changes are merged in rawhide/main branches by then, they will be > included. Indeed. The distro-wide mass rebuild has been in the back of my mind, but I'm not sure why I didn't think about it more when planning this. I will still do the "Rebuild for golang..." changelog bump on rawhide for the f36 mergable packages[^1], but I won't actually submit the builds to avoid duplicating work and disrupting the F37 Mass Rebuild. [^1]: If you all couldn't already tell, I really don't like dealing with changelog/release related merge conflicts, so I try to avoid them when making mass changes :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
RE: F37 proposal: Deprecate openssl1.1 package (System-Wide Change)
Ben Beasley writes: > I support deprecating openssl1.1. We definitely shouldn’t be adding any > new packages that depend on it. > > However, dropping the -devel package is almost as drastic as simply > retiring the OpenSSL 1.1 package altogether. Grepping spec files for > 'BuildRequires:.*openssl1' turns up the following packages that would > immediately FTBFS: > > - anope > - baresip > - botan2 > - ceph > - chatty > - dotnet3.1 > - dsniff > - eggdrop > - erlang > - kf5-kdelibs4support > - libasr > - libqxt-qt5 > - libre > - libretls > - lua-sec > - nginx The openssl11-devel BuildRequires in ngnix is in a conditional and has been building with OpenSSL 3 for a while. %if 0%{?fedora} || 0%{?rhel} >= 8 BuildRequires: openssl-devel %else BuildRequires: openssl11-devel %endif > - nodejs Similarly for nodejs, openssl11 is conditional on building for RHEL. ___ 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 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)
On Mon, Jul 18, 2022 at 11:50 AM Gary Buhrmaster wrote: > > On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach wrote: > > > > Dan Čermák writes: > > > > > > Just out of curiosity, how large is the speedup typically? > > > > > > > > It depends on the number of threads your machine has. But you could get some > > data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0 > > restore` on a running system. The following times are reported on my > > workstation: > > > > Has anyone run such a test on a system using > classic ("spinning rust") HDDs? It is sometimes > the case that parallelizing activities that are I/O > intensive can result in excessive seek activity > that can result in rather elongated elapsed times > (much worse than single threaded operation). If that turns out to be the case, it should be possible to detect the use of an SSD vs. a spinning-disc HDD and trigger the `-T` argument appropriately. I don't know if the Change Proposers have plans for that. ___ 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 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)
On Mon, Jul 18, 2022 at 6:44 AM Petr Lautrbach wrote: > > Dan Čermák writes: > > > > Just out of curiosity, how large is the speedup typically? > > > > It depends on the number of threads your machine has. But you could get some > data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0 > restore` on a running system. The following times are reported on my > workstation: > Has anyone run such a test on a system using classic ("spinning rust") HDDs? It is sometimes the case that parallelizing activities that are I/O intensive can result in excessive seek activity that can result in rather elongated elapsed times (much worse than single threaded operation). ___ 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: Suggestion: Use a unified kernel image by default in the future.
On Mo, 18.07.22 14:52, Gerd Hoffmann (kra...@redhat.com) wrote: > On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote: > > Another idea is to measure the initrd and the boot configuration, for > > example taking a hash of the grub configuration and initrd and > > extending a PCR register. > > That is already happening. > > Problem with measuring the initrd is that we don't have fixed hashes for > a given kernel version (due to generating the initrd on the installed > system). > > Problem with grub config measurements is that grub measures every config > file line it processes, which is quite messy: The very newest kernels measure all initrds on their own into PCR 9 these days. It should be the only thing measured into PCR 9, hence you can pre-calculate what you are going to see in the PCR easily if you have the initrds. I also intend to change sd-stub to measure the kernel it is prefixed to and the other stuff it makes use of from the PE image into a separate PCR, that is otherwise not used so far. i.e. PCR 11 or so. This stuff could then also be easily pre-calculated: if you have the kernel image you know what the PCR value will be. Once we have that, we can relatively easily express policies for TPM resources that bind to kernel + initrd, and pre-calculate those easily at build time (or at install time in case of dynamic initrds), without any need for rebooting into the new setup and then looking at the measured hsah values. Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore. The next step is then to extend the kernel PE images, to also contain the PCR hsah signatures appropriate for the kernel. That would make it nice and simple to deploy new kernels in a robust fashion so that they always carry enough metainfo so that TPM policies can be written that match the vendor. (the model isn't perfect yet though: tpm policies built that way need some rollback protection, i.e. some counter kept in tpm nvram that can only increase, and whose cutoff value is also signed along with the PCR hashes, so that one can invalidate old kernels if needed, without having to invalidate signatures as a whole) Lennart -- Lennart Poettering, Berlin ___ 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: Missing LLVM stack bugfix updates in stable Fedora branches
On Mon, Jul 18, 2022 at 4:43 PM Tom Stellard wrote: > > On 7/18/22 06:33, Fabio Valentini wrote: > > > > I have filed multiple bugs against llvm (or rust, which were then > > reassigned to llvm) and llvm compat packages over the past 1-2 years, > > and they've been pretty much ignored. > > Can you send me links to these bugs. The current ones are (some rust bugs are already reassigned to llvm, some weren't yet, but probably should be): https://bugzilla.redhat.com/show_bug.cgi?id=2001328 https://bugzilla.redhat.com/show_bug.cgi?id=2020861 https://bugzilla.redhat.com/show_bug.cgi?id=2041942 https://bugzilla.redhat.com/show_bug.cgi?id=2045116 https://bugzilla.redhat.com/show_bug.cgi?id=2086106 There have been previous ones for F34 that were closed at EOL without resolution: https://bugzilla.redhat.com/show_bug.cgi?id=2020861 https://bugzilla.redhat.com/show_bug.cgi?id=1883457 And these are only the ones I could find quickly, I'm pretty sure there are a few more. > > Also, given that rawhide *is* up-to-date with LLVM bugfix releases > > until about three weeks ago, but the llvm packages on f36 and f35 > > weren't touched since 4 months (f36) and f35 (9 months) ago, > > respectively, so I don't think PTO can be a problem here. > > Or, if it is, then we'd need to have a serious talk about adding > > backup maintainers to those packages ... > > > > We've been training up more people on LLVM packaging so we should be able > to cover the stable release of Fedora better in the future. I'm sorry > that the stable releases have been falling behind, we'll work on getting them > back up to date. That sounds great, thank you for trying to improve the situation. 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: Missing LLVM stack bugfix updates in stable Fedora branches
On 7/18/22 06:33, Fabio Valentini wrote: On Mon, Jul 18, 2022 at 3:26 PM Peter Robinson wrote: Hi, Today I encountered another LLVM-specific bug that affects at least one Rust package and causes non-working code to be produced, which prompted this question: Why are stable releases not getting bugfix releases of LLVM? Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released. Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have been released. Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet (released over 3 weeks ago). However, the llvm13 compat package that exists on Fedora 36+ *has* been updated to version 13.0.1, so I'm not sure why this update wasn't also pushed to Fedora 35, where LLVM 13 is the default, and would benefit much more from bugfixes provided by 13.0.1. Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc on some architectures, mesa/llvmpipe) are an important part of our stack, it seems bad that stable releases are missing out on several bugfix updates for those critical packages. I appreciate that updating ~a dozen packages for new LLVM point releases is work, but I don't think having outdated LLVM components on stable releases of Fedora is a good idea, either. What can we do to improve this situation? Have you reached out to the maintainer(s)? In the past they seem to have been quite effective at keeping things up to date AFAIA so maybe they've got stuff going on of late, PTO, have other priorities or something else. You don't mention if you've had a discussion with the maintainer(s), whether they replied, or even cc:ed them on this mail. I personally would tend to do that before mailing a list, but then maybe you have and you didn't mention it here. I have filed multiple bugs against llvm (or rust, which were then reassigned to llvm) and llvm compat packages over the past 1-2 years, and they've been pretty much ignored. Can you send me links to these bugs. Also, given that rawhide *is* up-to-date with LLVM bugfix releases until about three weeks ago, but the llvm packages on f36 and f35 weren't touched since 4 months (f36) and f35 (9 months) ago, respectively, so I don't think PTO can be a problem here. Or, if it is, then we'd need to have a serious talk about adding backup maintainers to those packages ... We've been training up more people on LLVM packaging so we should be able to cover the stable release of Fedora better in the future. I'm sorry that the stable releases have been falling behind, we'll work on getting them back up to date. -Tom 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
F37 proposal: Haskell GHC 8.10.7 & Stackage LTS 18.28 (Self-Contained Change proposal)
Note that this proposal supersedes the Haskell GHC 9.0 & Stackage LTS 19 proposal, which was deferred to F38. https://fedoraproject.org/wiki/Changes/Haskell_GHC_8.10.7 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The GHC Haskell compiler will be updated from minor version 8.10.5 to 8.10.7, and Haskell packages will be updated to Stackage LTS 18.28 minor versions. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: peter...@redhat.com * Name: [[Haskell_SIG|Haskell SIG]] * Email: hask...@lists.fedoraproject.org == Detailed Description == For Fedora 37, the GHC Haskell compiler will be updated from version 8.10.5 to 8.10.7 release (rebasing from the ghc8.10 package). Along with this, Haskell packages in [https://www.stackage.org Stackage] (the stable Haskell source package distribution) will be updated to the final LTS 18.28 minor release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. == Benefit to Fedora == Fedora users will have a newer more stable Haskell compiler, tools, and current Haskell packages from final Stackage LTS 18. GHC 8.10.7 contains a few important bug fixes (see the release notes linked in the Documentation section for more details). == Scope == * Proposal owners: ** rebase ghc to 8.10.7 ** update ghc-rpm-macros to the final version for F37 ** update packages to latest [https://www.stackage.org/lts-18 Stackage LTS 18] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order using fbrnch ** push the sidetag through Bodhi to Rawhide before the mass rebuild [[https://bodhi.fedoraproject.org/updates/FEDORA-2022-3ae019aee4 done]] * Other developers: no actions should be needed * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == There should not be any significant upgrade impact. Users' Haskell projects will get built with ghc-8.10,7 when they next build. == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep ; cabal install * test upgrades of F36 Haskell packages to F37 == User Experience == Users will have the newer stable minor version of ghc and Haskell libraries and tools available to them. This makes it easier to build the recent versions of Haskell projects. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) ** Change owner can revert back to the versions in F36. * Contingency deadline: Beta Freeze == Documentation == * https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html * https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.6-notes.html * https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html * https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8.10.7-notes.html == Release Notes == The Haskell GHC compiler has been updated from 8.10.5 to 8.10.7 with some important bugfixes. -- 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
[CoreOS] Fedora CoreOS Meeting Minutes 2022-07-13
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-13/fedora_coreos_meeting.2022-07-13-16.30.html Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-13/fedora_coreos_meeting.2022-07-13-16.30.txt Log: https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-13/fedora_coreos_meeting.2022-07-13-16.30.log.html #fedora-meeting-1: fedora_coreos_meeting Meeting started by jlebon at 16:30:05 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-1/2022-07-13/fedora_coreos_meeting.2022-07-13-16.30.log.html . Meeting summary --- * roll call (jlebon, 16:30:11) * Action items from last meeting (jlebon, 16:34:30) * jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/1252 (jlebon, 16:34:51) * New Package Request: zstd (jlebon, 16:35:49) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1251 (jlebon, 16:35:51) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1247 (jlebon, 16:37:47) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-1179490347 (bgilbert, 16:39:06) * AGREED: We will add the zstd package to FCOS, and switch our initrd to use it. (bgilbert, 16:50:34) * extend grub boot prompt timeout on platforms with full console access (jlebon, 16:52:55) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1236 (jlebon, 16:52:58) * there seems to be insufficient desire for a longer timeout. we will not pursue this for now but may reconsider in the future pending more convincing feedback. (jlebon, 17:15:42) * Change default to be equivalent of quiet (jlebon, 17:16:02) * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1244 (jlebon, 17:16:05) * there's general agreement this would be good, but implementation details are still to be fleshed out (jlebon, 17:47:16) Meeting ended at 17:48:33 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * jlebon (78) * bgilbert (76) * dustymabe (64) * walters (32) * zodbot (22) * lucab (17) * travier (7) * miabbott (3) * jmarrero (2) * ravanelli (1) * jbrooks (1) * saqali (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions ___ 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: Suggestion: Use a unified kernel image by default in the future.
indeed, this is why a proposal is to change the way grub measure things. For example introducing a new PCR, for example PCR10, and a new command, "extend", that replay a command into the PCR without actually executing it. This would mean for your above example, if we only limit to the last line, you would boot first your server with initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img and you read a value of PCR10 = p0 Following an upgrade, you would unbind the luks decryption, run _tpm2_pcrextend initrd (hd0,gpt2)/init.fc37.img which brings PCR10 = p1, then you can rebind the luks decryption key with PCR10 (and others) The grub configuration now looks like extend initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img initrd (hd0,gpt2)/init.fc37.img Upon next boot, grub execute the extend command bringing PCR10 to p0, then measure the new "initrd (hd0,gpt2)/init.fc37.img" into it, bringing PCR10 to p1, so decryption can happen automatically. The checksum of initrd can also be checked using grub with the hashsum command. (I realize this idea is not trivial at all. Nevertheless here's a build of grub with a patch that implement part of that https://koji.fedoraproject.org/koji/taskinfo?taskID=89600764) ___ 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: Missing LLVM stack bugfix updates in stable Fedora branches
On Mon, Jul 18, 2022 at 3:26 PM Peter Robinson wrote: > > Hi, > > > Today I encountered another LLVM-specific bug that affects at least > > one Rust package and causes non-working code to be produced, which > > prompted this question: > > > > Why are stable releases not getting bugfix releases of LLVM? > > > > Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released. > > Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have > > been released. > > Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet > > (released over 3 weeks ago). > > > > However, the llvm13 compat package that exists on Fedora 36+ *has* > > been updated to version 13.0.1, so I'm not sure why this update wasn't > > also pushed to Fedora 35, where LLVM 13 is the default, and would > > benefit much more from bugfixes provided by 13.0.1. > > > > Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc > > on some architectures, mesa/llvmpipe) are an important part of our > > stack, it seems bad that stable releases are missing out on several > > bugfix updates for those critical packages. > > > > I appreciate that updating ~a dozen packages for new LLVM point > > releases is work, but I don't think having outdated LLVM components on > > stable releases of Fedora is a good idea, either. > > > > What can we do to improve this situation? > > Have you reached out to the maintainer(s)? In the past they seem to > have been quite effective at keeping things up to date AFAIA so maybe > they've got stuff going on of late, PTO, have other priorities or > something else. > > You don't mention if you've had a discussion with the maintainer(s), > whether they replied, or even cc:ed them on this mail. I personally > would tend to do that before mailing a list, but then maybe you have > and you didn't mention it here. I have filed multiple bugs against llvm (or rust, which were then reassigned to llvm) and llvm compat packages over the past 1-2 years, and they've been pretty much ignored. Also, given that rawhide *is* up-to-date with LLVM bugfix releases until about three weeks ago, but the llvm packages on f36 and f35 weren't touched since 4 months (f36) and f35 (9 months) ago, respectively, so I don't think PTO can be a problem here. Or, if it is, then we'd need to have a serious talk about adding backup maintainers to those packages ... 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: Missing LLVM stack bugfix updates in stable Fedora branches
Hi, > Today I encountered another LLVM-specific bug that affects at least > one Rust package and causes non-working code to be produced, which > prompted this question: > > Why are stable releases not getting bugfix releases of LLVM? > > Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released. > Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have > been released. > Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet > (released over 3 weeks ago). > > However, the llvm13 compat package that exists on Fedora 36+ *has* > been updated to version 13.0.1, so I'm not sure why this update wasn't > also pushed to Fedora 35, where LLVM 13 is the default, and would > benefit much more from bugfixes provided by 13.0.1. > > Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc > on some architectures, mesa/llvmpipe) are an important part of our > stack, it seems bad that stable releases are missing out on several > bugfix updates for those critical packages. > > I appreciate that updating ~a dozen packages for new LLVM point > releases is work, but I don't think having outdated LLVM components on > stable releases of Fedora is a good idea, either. > > What can we do to improve this situation? Have you reached out to the maintainer(s)? In the past they seem to have been quite effective at keeping things up to date AFAIA so maybe they've got stuff going on of late, PTO, have other priorities or something else. You don't mention if you've had a discussion with the maintainer(s), whether they replied, or even cc:ed them on this mail. I personally would tend to do that before mailing a list, but then maybe you have and you didn't mention it here. Peter ___ 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
conserver license change
I've altered the license of conserver in rawhide from 'BSD with advertising and zlib' to 'BSD and zlib' since the former is no longer valid. Lukas ___ 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: Suggestion: Use a unified kernel image by default in the future.
On Fri, Jul 15, 2022 at 10:33:03AM -, Francois Rigault wrote: > Another idea is to measure the initrd and the boot configuration, for > example taking a hash of the grub configuration and initrd and > extending a PCR register. That is already happening. Problem with measuring the initrd is that we don't have fixed hashes for a given kernel version (due to generating the initrd on the installed system). Problem with grub config measurements is that grub measures every config file line it processes, which is quite messy: root@fedora ~# tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep grub_cmd grub_cmd: search --no-floppy --fs-uuid --set=dev 5cc83bf9-c040-42d9-819e-99a16462d518 grub_cmd: set prefix=(hd0,gpt2)/grub2 grub_cmd: export (hd0,gpt2)/grub2 grub_cmd: configfile (hd0,gpt2)/grub2/grub.cfg grub_cmd: set pager=1 grub_cmd: [ -f (hd0,gpt2)/grub2/grubenv ] grub_cmd: load_env -f (hd0,gpt2)/grub2/grubenv grub_cmd: [ ] grub_cmd: set default=47c4701d41c0470992ce27741da89d4a-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64 grub_cmd: [ xy = xy ] grub_cmd: menuentry_id_option=--id grub_cmd: export menuentry_id_option grub_cmd: [ ] grub_cmd: serial --speed=115200 grub_cmd: terminal_input serial console grub_cmd: terminal_output serial console grub_cmd: [ xy = xy ] grub_cmd: set timeout_style=menu grub_cmd: set timeout=5 grub_cmd: [ -f (hd0,gpt2)/grub2/user.cfg ] grub_cmd: insmod increment grub_cmd: [ -n -a 1 = 0 ] grub_cmd: insmod part_gpt grub_cmd: insmod xfs grub_cmd: set root=hd0,gpt2 grub_cmd: [ xy = xy ] grub_cmd: search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 5cc83bf9-c040-42d9-819e-99a16462d518 grub_cmd: insmod part_gpt grub_cmd: insmod fat grub_cmd: set boot=hd0,gpt1 grub_cmd: [ xy = xy ] grub_cmd: search --no-floppy --fs-uuid --set=boot --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 8C55-9DE2 grub_cmd: [ -z ] grub_cmd: set kernelopts=root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8 ro rootflags=subvol=root console=ttyS0,115200 grub_cmd: insmod blscfg grub_cmd: blscfg grub_cmd: [ 1 = 1 -o 0 = 1 ] grub_cmd: set menu_hide_ok=1 grub_cmd: [ 1 = 1 ] grub_cmd: set boot_indeterminate=0 grub_cmd: set boot_success=0 grub_cmd: save_env boot_success boot_indeterminate grub_cmd: [ xy = xy ] grub_cmd: [ ] grub_cmd: [ efi = efi ] grub_cmd: menuentry UEFI Firmware Settings --id uefi-firmware { grub_cmd: [ -f (hd0,gpt2)/grub2/custom.cfg ] grub_cmd: source (hd0,gpt2)/grub2/custom.cfg grub_cmd: [ efi = efi ] grub_cmd: menuentry systemd boot loader { grub_cmd: load_video grub_cmd: [ xy = xy ] grub_cmd: insmod all_video grub_cmd: set gfxpayload=keep grub_cmd: insmod gzio grub_cmd: linux (hd0,gpt2)/vmlinuz-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64 root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8 ro rootflags=subvol=root console=ttyS0,115200 grub_cmd: initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img root@fedora ~# take care, Gerd ___ 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 Mon, Jul 18 2022 at 11:07:41 AM +0200, Miro Hrončok wrote: gnome-photos (maintained by: gnome-sig, pranvk) gnome-photos-42.0-3.fc37.src requires pkgconfig(libgfbgraph-0.2) = 0.2.4 gnome-photos-42.0-3.fc37.x86_64 requires gfbgraph(x86-64) = 0.2.4-2.fc36, gnome-online-miners = 3.34.0-10.fc36, libgfbgraph-0.2.so.0()(64bit) I'm going to rebuild Photos without this dependency, so gnome-online-miners can be retired safely. (The project has been archived upstream, and it doesn't make sense to keep it.) Then since Phil has taken gfbgraph, we should be good. 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 proposal: Deprecate openssl1.1 package (System-Wide Change)
On 23. 06. 22 19:13, Miro Hrončok wrote: $ comm -23 <(repoquery -q --repo=rawhide{,-source} --whatrequires openssl1.1-devel | grep src$ | sort) <(repoquery -q --repo=rawhide{,-source} --whatrequires openssl-devel | grep src$ | sort) ... pypy-0:7.3.9-1.fc37.src https://foss.heptapod.net/pypy/pypy/-/issues/3643 https://src.fedoraproject.org/rpms/pypy/pull-request/30 pypy3.7-0:7.3.9-1.3.7.fc37.src https://src.fedoraproject.org/rpms/pypy3.7/pull-request/28 pypy3.8-0:7.3.9-1.3.8.fc37.src https://src.fedoraproject.org/rpms/pypy3.8/pull-request/18 python-uamqp-0:1.5.3-2.fc37.src https://src.fedoraproject.org/rpms/python-uamqp/pull-request/1 python2.7-0:2.7.18-22.fc37.src https://src.fedoraproject.org/rpms/python2.7/pull-request/36 python3.6-0:3.6.15-9.fc37.src python3.7-0:3.7.13-2.fc37.src TBD -- 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 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi Kevin, Dne 16. 07. 22 v 21:35 Kevin Fenzi napsal(a): ...snip... For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. What packages will be in this tar-payload? We are planning to use payload from F37 Workstation GA. So it will install fully functional Fedora 37. The side benefit will be that the payload is already tested. And can you use the boot.iso to do netinstalls against the network respositories, or are you restricted to the tar-payload contents? Not yet, we are missing Software selection and Source management. This version is really a first usable image which enables to select disks and start the installation. However, it's a good base for us for future improvements so the ISO can be updated with new features and we can get feedback soon. ...snip... == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. So, you will need space to place these images in Fedora Infrastructure and nothing else right now from Infra&Releng? Yes, we just need a publicly accessible storage, where we can upload the ISO. Right now, we are thinking about https://fedorapeople.org/groups/anaconda/. Do you think it's a good idea Kevin or would you recommend us something else? Looking forward to playing with it! Great to hear that! :) Best Regards, Jirka kevin ___ 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: Script to get all deps of a package (for soname bumps etc.)
On Wed, Jul 13, 2022 12:54:37 -0500, Maxwell G wrote: > On 22/07/13 05:35PM, Ankur Sinha wrote: > > > This is what we (I) aren't sure of, and that's why I first obtain the > > capabilities manually and then query for them. If someone can confirm > > that this is indeed the case, that would certainly simplify things. > > Here is confirmation: > > ``` > sudo dnf repoquery --repo=rawhide{,-source} -q --whatrequires > python3-setuptools | grep '\.src' | grep yt-dlp > yt-dlp-0:2022.06.29-2.fc37.src > > $ sudo dnf repoquery --repo=rawhide-source -q --requires yt-dlp | grep > setuptools > python3dist(setuptools) >= 40.8 > ``` > > yt-dlp depends on one of `python3-setuptool`'s virtual provides, and it is > still > found when using the command I gave to find which packages BuildRequire > a certain other package. This also works when querying runtime > dependencies: > > ``` > $ sudo dnf repoquery -q --repo=rawhide --requires reuse | grep setuptools > python3.11dist(setuptools) > $ sudo dnf repoquery -q --repo=rawhide --whatrequires python3-setuptools | > grep reuse > reuse-0:1.0.0-2.fc37.noarch > ``` Thanks very much! That really simplifies it to a single command. -- Thanks, Regards, Ankur Sinha (He / Him / His) | https://ankursinha.in 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: Koji ppc64le build failure
On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote: > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509 > > > > On ppc64le: > > FAIL: test-checkwrite.sh > > > > There should be a core dump associated with this failure. Is it > > possible someone with Koji access could look to see if this is still > > around and capture it? (Even just a full stack trace would be useful) > > > > We've been seeing this error occasionally (same test, only on ppc64le) > > for a few weeks. I reserved a ppc64le machine at Red Hat last week > > and ran this test on basically exactly the same combination of > > software thousands of times, and it didn't fail even once in that > > time, so I'm out of ideas how to reproduce it for myself. > > Core at: > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst > > Module libtasn1.so.6 with build-id > 460fc6bd3f93e57e7d593080f58952f61cdb344a > Stack trace of thread 2744170: > #0 0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + 0xb9b6c) > ELF object binary architecture: PowerPC64 Sorry, I realised that the core dump won't work without the executable. Is /server/nbdkit still around? (Note there's another "nbdkit" binary in the top build directory, which is _not_ the server.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ 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 proposal: Public release of the Anaconda Web UI preview image (Self-Contained Change proposal)
Hi, Dne 16. 07. 22 v 14:34 Dan Čermák napsal(a): Hi, On July 15, 2022 9:30:48 PM UTC, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == The work on Web UI for the Anaconda installer has advanced enough so that it is possible to create and publish self contained preview images. == Owner == * Name: [[User:m4rtink| Martin Kolman]] * Email: mkol...@redhat.com == Detailed Description == Even though still very simple the new Anaconda Web UI is now far enough to support a simple installation workflow from a self-contained image while demonstrating all the main aspects of the new UI, such as: * flexible Wizard layout * responsive PatternFly components * new style built-in help * local and remote access to the Web UI For this we will create a self-contained boot.iso style image with a built-in tar-payload (so that the image can work even without network access) based on the latest Anaconda upstream code. We aim to have the image available for download just after the F37 release (so that the tar-payload can contain final F37 release content) and then updated automatically in regular intervals. That way the rather active Web UI development of the Web UI will be reflected in the up-to-date installation image, as well as any feedback and community PRs. == Benefit to Fedora == The Anaconda Web UI will provide modern responsive user interface based on a well known and widely used toolkit (PatternFly) and backed by proven Cockpit tooling. The screen layout is based on latest UX design guidelines as well as usability testing of the new interface and extensive mockup work. There are improvements in developer experience as well due to the more modern & more mainstream UI technology chosen and powerful Cockpit test tooling (rich unit-test as well as pixel-test framework). The stateless property of the Web UI allows almost live-coding style of UI development. This should make it easier to work on the Anaconda Web UI for not only the Anaconda team, addon developer but also for any interested contributors. Remote Web UI access should also provide a much better experience than the slow and inefficient VNC based remote GUI installation support Anaconda has today. Due to no need for local rendering remotely driven GUI installations on a constrained hardware with minimal installation images should become possible. == Scope == * Proposal owners: The Anaconda team will setup and maintain an automated Web UI preview image creation pipeline, with the image being available via a web server on the Fedora infrastructure. It will be a '''preview image only''', not an official Fedora deliverable and it will not influence Fedora release criteria in any way. * Other developers: Other developers and Fedora users are welcome to try the image once it is released and to provide feedback. * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == (not supplied) == How To Test == Download the Anaconda Web UI preview image and boot it on VM or hardware that contains no important data. Install using the Web UI locally, alternatively try using the Web UI remotely. The installed OS should be functional but its testing or any issues with it are currently out of scope for the Anaconda Web UI preview image. Do you have any plans to integrate this with the Fedora openQA tests? That would automatically give you some basic coverage for the functionality of the installed system. That would be definitely valuable but I don't think it's feasible right now. The current progress is pretty rapid and we are constantly changing things. Having the OpenQA to reflect that could be too heavy from the maintenance PoV. Instead of that, we have pixel tests[0] in our upstream repository to avoid breaking UI, that is much easier to keep updated by us. When the UI will be more stable than we definitely want to have OpenQA support. [0]: https://cockpit-project.org/blog/pixel-testing.html Best Regards, Jirka To provide feedback use one of the Anaconda team communication channels: * IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat * mailing list: anaconda-de...@lists.fedoraproject.org - https://lists.fedoraproject.org/archives/list/anaconda-de...@lists.fedoraproject.org/ * Github Discussion: https://github.com/rhinstaller/anaconda/discussions == User Experience == Should be improved compared to the current GTK interface. == Dependencies == (not supplied) == Contingency Plan == * Contingency mechanism: If we hit some blocking technical issues, the image will be published later. *
Re: Orphaned packages looking for new maintainers
On Mon, Jul 18, 2022 at 11:50 AM Philip Wyett wrote: > On Mon, 2022-07-18 at 11:07 +0200, Miro Hrončok wrote: > > gfbgraph > > As gfbgraph is a dep of gnome-maps, I have taken this one. > Thanks, Phil! -- Kalev ___ 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
Missing LLVM stack bugfix updates in stable Fedora branches
Hi all, Today I encountered another LLVM-specific bug that affects at least one Rust package and causes non-working code to be produced, which prompted this question: Why are stable releases not getting bugfix releases of LLVM? Fedora 35 is stuck at LLVM 13.0.0, while 13.0.1 has been released. Fedora 36 is stuck at LLVM 14.0.0, while 14.0.1 through 14.0.6 have been released. Even Rawhide is at LLVM 14.0.5, but has not been updated to 14.0.6 yet (released over 3 weeks ago). However, the llvm13 compat package that exists on Fedora 36+ *has* been updated to version 13.0.1, so I'm not sure why this update wasn't also pushed to Fedora 35, where LLVM 13 is the default, and would benefit much more from bugfixes provided by 13.0.1. Given that llvm and the whole llvm ecosystem (clang, lld, rustc, ghc on some architectures, mesa/llvmpipe) are an important part of our stack, it seems bad that stable releases are missing out on several bugfix updates for those critical packages. I appreciate that updating ~a dozen packages for new LLVM point releases is work, but I don't think having outdated LLVM components on stable releases of Fedora is a good idea, either. What can we do to improve this situation? 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: Orphaned packages looking for new maintainers
On Mon, 2022-07-18 at 11:07 +0200, Miro Hrončok wrote: > gfbgraph As gfbgraph is a dep of gnome-maps, I have taken this one. Regards Phil -- *** Playing the game for the games own sake. *** Associations: * Debian Maintainer (DM) * Fedora/EPEL Maintainer. * Contributor member of the AlmaLinux foundation. WWW: https://kathenas.org Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg Twitter: @kathenasorg Instagram: @kathenasorg IRC: kathenas GPG: 724AA9B52F024C8B signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Koji ppc64le build failure
On Sun, Jul 17, 2022 at 12:50:01PM -0700, Kevin Fenzi wrote: > On Sun, Jul 17, 2022 at 08:34:30PM +0100, Richard W.M. Jones wrote: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=89618509 > > > > On ppc64le: > > FAIL: test-checkwrite.sh > > > > There should be a core dump associated with this failure. Is it > > possible someone with Koji access could look to see if this is still > > around and capture it? (Even just a full stack trace would be useful) > > > > We've been seeing this error occasionally (same test, only on ppc64le) > > for a few weeks. I reserved a ppc64le machine at Red Hat last week > > and ran this test on basically exactly the same combination of > > software thousands of times, and it didn't fail even once in that > > time, so I'm out of ideas how to reproduce it for myself. > > Core at: > https://infrastructure.fedoraproject.org/infra/tmp/core.nbdkit.1000.9be14c7983c4418eb6245b3fd5719a79.2744149.165808588900.zst > > Module libtasn1.so.6 with build-id > 460fc6bd3f93e57e7d593080f58952f61cdb344a > Stack trace of thread 2744170: > #0 0x7fffa9b59b6c n/a (/usr/lib64/libc.so.6 + 0xb9b6c) > ELF object binary architecture: PowerPC64 Thanks - I've grabbed that file. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ 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-07-18.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 RBTools orphan0 weeks ago evolution-rssmcrha, orphan 1 weeks ago ez-pine-gpg orphan2 weeks ago gfbgraph orphan4 weeks ago gnome-online-miners orphan, pranvk4 weeks ago golang-github-rubyist-tracerxorphan2 weeks ago gpartdcantrell, orphan 2 weeks ago libnss-pgsql orphan1 weeks ago module-macrosorphan2 weeks ago pam_url herlo, orphan 4 weeks ago preproc orphan2 weeks ago preproc-rpmspec orphan2 weeks ago python-proteus orphan4 weeks ago rpkg-macros orphan2 weeks ago rpkg-utilorphan2 weeks ago rpm-git-tag-sort orphan2 weeks ago sourcetrail orphan0 weeks ago topedorphan, tnorth0 weeks ago tryton orphan4 weeks ago trytond orphan4 weeks ago trytond-account orphan4 weeks ago trytond-account-be orphan4 weeks ago trytond-account-de-skr03 orphan4 weeks ago trytond-account-invoice orphan4 weeks ago trytond-account-invoice-history orphan4 weeks ago trytond-account-invoice-line-orphan4 weeks ago standalone trytond-account-product orphan4 weeks ago trytond-account-statementorphan4 weeks ago trytond-account-stock-anglo-saxonorphan4 weeks ago trytond-account-stock-continentalorphan4 weeks ago trytond-analytic-account orphan4 weeks ago trytond-analytic-invoice orphan4 weeks ago trytond-analytic-purchaseorphan4 weeks ago trytond-analytic-saleorphan4 weeks ago trytond-company orphan4 weeks ago trytond-company-work-timeorphan4 weeks ago trytond-country orphan4 weeks ago trytond-currency orphan4 weeks ago trytond-dashboardorphan4 weeks ago trytond-google-maps orphan4 weeks ago trytond-ldap-authentication orphan4 weeks ago trytond-partyorphan4 weeks ago trytond-party-siret orphan4 weeks ago trytond-product orphan4 weeks ago trytond-product-cost-fifoorphan4 weeks ago trytond-product-cost-history orphan4 weeks ago trytond-product-price-list orphan4 weeks ago trytond-project orphan4 weeks ago
Fedora-Cloud-35-20220718.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-20220717.0): ID: 1329275 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1329275 ID: 1329282 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1329282 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: Non-responsive packagers: benzea
On Mon, Jul 18, 2022 at 10:12:55AM +0200, Tomáš Popela wrote: > Hi Pierre, > > Is the subject right? It talks about "michaelanguskelly", but the queries > are for Benjamin (benzea). I can talk to Benjamin if needed (already > pointed him at this thread just in case). Hi Tomáš, Thanks for pointing this out, that's what I get for re-using an old email as template :( The correct user is benzea indeed. Thanks for pointing him to this thread! Pierre > On Mon, Jul 18, 2022 at 9:59 AM Pierre-Yves Chibon > wrote: > > > Good Morning Everyone, > > > > The packagers listed here have been receiving a daily email asking them to > > either adjust their bugzilla or their FAS account so the email address in > > FAS > > matches an existing bugzilla account. > > > > Having a bugzilla account is mandatory per: > > > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account > > > > - benzea contacted since June 23rd 2022 > > benzea is maintainer of rpms/bolt > > benzea is main admin of rpms/devtodo > > benzea has a bugzilla override on rpms/devtodo > > benzea is main admin of rpms/fprintd > > benzea has a bugzilla override on rpms/fprintd > > benzea is main admin of rpms/fwts > > benzea has a bugzilla override on rpms/fwts > > benzea is maintainer of rpms/gamemode > > benzea is main admin of rpms/gnome-network-displays > > benzea has a bugzilla override on rpms/gnome-network-displays > > benzea is main admin of rpms/libfprint > > benzea has a bugzilla override on rpms/libfprint > > benzea is maintainer of rpms/libusb > > benzea is maintainer of rpms/libusb-compat-0.1 > > benzea is maintainer of rpms/libusb1 > > benzea is main admin of rpms/libusbx > > benzea has a bugzilla override on rpms/libusbx > > benzea is main admin of rpms/thermald > > benzea has a bugzilla override on rpms/thermald > > benzea is maintainer of rpms/umockdev > > benzea is maintainer of rpms/upower > > benzea is main admin of rpms/uresourced > > benzea has a bugzilla override on rpms/uresourced > > > > > > > > Does anyone know how to contact them? > > > > > > Thanks, > > > > Pierre > > ___ > > 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: F37 proposal: SELinux Parallel Autorelabel (Self-Contained Change proposal)
On Mon, Jul 18, 2022 at 8:44 AM Petr Lautrbach wrote: > Dan Čermák writes: > > > On July 15, 2022 9:42:35 PM UTC, Ben Cotton wrote: > >>https://fedoraproject.org/wiki/Changes/SELinux_Parallel_Autorelabel > >> > >>This document represents a proposed Change. As part of the Changes > >>process, proposals are publicly announced in order to receive > >>community feedback. This proposal will only be implemented if approved > >>by the Fedora Engineering Steering Committee. > >> > >> > >>== Summary == > >>After a system's SELinux mode is switched from disabled to enabled, or > >>after an administrator runs `fixfiles onboot`, SELinux autorelabel > >>will be run in parallel by default. > >> > >>== Owner == > >>* Name: [[User:plautrba| Petr Lautrbach]] > >>* Email: plaut...@redhat.com > >> > >> > >>== Detailed Description == > >>SELinux tools `restorecon` and `fixfiles` recently gained the ability > >>to relabel files in parallel using the `-T nthreads` option. This > >>option is currently not used in the automatic relabel after reboot. > >>When users want/need the parallel relabeling they have to specify the > >>option explicitly (e.g. `fixfiles -T 0 onboot`). With this change `-T > >>0` (0 == use all available CPU cores) will be the default for > >>`fixfiles onboot` and users will have to use `fixfiles -T 1 onboot` to > >>force it to use only one thread. > >> > >>The rationale is that when autorelabel runs, there are no other > >>resource-intensive processes running on the system, so it's fine (and > >>actually better) to use all available parallelism to speed up the task > >>and get to a fully booted system faster. > >> > >> > >>== Benefit to Fedora == > >>Faster reboot after switching back to an SELinux enabled system or > >>when triggering autorelabel explicitly. > > > > Just out of curiosity, how large is the speedup typically? > > > >> > > > It depends on the number of threads your machine has. But you could get some > data for comparison using `fixfiles -T 1 restore` and `fixfiles -T 0 > restore` on a running system. The following times are reported on my > workstation: > > [root@P1 ~]# time fixfiles -T 0 restore > Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home > /run /run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug > /sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var > / 100.0% > ... > real1m8.488s > user9m24.755s > sys 0m25.424s > > [root@P1 ~]# time fixfiles -T 1 restore > Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home > /run /run/user/1000 /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug > /sys/kernel/debug/tracing /sys/kernel/tracing /tmp /var > / 100.0% > ... > real4m5.450s > user3m55.017s > sys 0m10.088s Also see the original commit message, which compares the run time for different thread counts on a 32-core machine: https://github.com/SELinuxProject/selinux/commit/93902fc8340f8a6ee5ba69ccb150d47918aad226 It doesn't scale perfectly with the number of cores, but it can speed up the relabeling up to ~18 times if you have a beefy machine. I updated the "Benefit to Fedora" section of the proposal with this info. -- Ondrej Mosnacek Senior Software Engineer, Linux Security - SELinux kernel 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: Non-responsive packagers: michaelanguskelly
Hi Pierre, Is the subject right? It talks about "michaelanguskelly", but the queries are for Benjamin (benzea). I can talk to Benjamin if needed (already pointed him at this thread just in case). Tom On Mon, Jul 18, 2022 at 9:59 AM Pierre-Yves Chibon wrote: > Good Morning Everyone, > > The packagers listed here have been receiving a daily email asking them to > either adjust their bugzilla or their FAS account so the email address in > FAS > matches an existing bugzilla account. > > Having a bugzilla account is mandatory per: > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account > > - benzea contacted since June 23rd 2022 > benzea is maintainer of rpms/bolt > benzea is main admin of rpms/devtodo > benzea has a bugzilla override on rpms/devtodo > benzea is main admin of rpms/fprintd > benzea has a bugzilla override on rpms/fprintd > benzea is main admin of rpms/fwts > benzea has a bugzilla override on rpms/fwts > benzea is maintainer of rpms/gamemode > benzea is main admin of rpms/gnome-network-displays > benzea has a bugzilla override on rpms/gnome-network-displays > benzea is main admin of rpms/libfprint > benzea has a bugzilla override on rpms/libfprint > benzea is maintainer of rpms/libusb > benzea is maintainer of rpms/libusb-compat-0.1 > benzea is maintainer of rpms/libusb1 > benzea is main admin of rpms/libusbx > benzea has a bugzilla override on rpms/libusbx > benzea is main admin of rpms/thermald > benzea has a bugzilla override on rpms/thermald > benzea is maintainer of rpms/umockdev > benzea is maintainer of rpms/upower > benzea is main admin of rpms/uresourced > benzea has a bugzilla override on rpms/uresourced > > > > Does anyone know how to contact them? > > > Thanks, > > Pierre > ___ > 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
Non-responsive packagers: michaelanguskelly
Good Morning Everyone, The packagers listed here have been receiving a daily email asking them to either adjust their bugzilla or their FAS account so the email address in FAS matches an existing bugzilla account. Having a bugzilla account is mandatory per: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account - benzea contacted since June 23rd 2022 benzea is maintainer of rpms/bolt benzea is main admin of rpms/devtodo benzea has a bugzilla override on rpms/devtodo benzea is main admin of rpms/fprintd benzea has a bugzilla override on rpms/fprintd benzea is main admin of rpms/fwts benzea has a bugzilla override on rpms/fwts benzea is maintainer of rpms/gamemode benzea is main admin of rpms/gnome-network-displays benzea has a bugzilla override on rpms/gnome-network-displays benzea is main admin of rpms/libfprint benzea has a bugzilla override on rpms/libfprint benzea is maintainer of rpms/libusb benzea is maintainer of rpms/libusb-compat-0.1 benzea is maintainer of rpms/libusb1 benzea is main admin of rpms/libusbx benzea has a bugzilla override on rpms/libusbx benzea is main admin of rpms/thermald benzea has a bugzilla override on rpms/thermald benzea is maintainer of rpms/umockdev benzea is maintainer of rpms/upower benzea is main admin of rpms/uresourced benzea has a bugzilla override on rpms/uresourced Does anyone know how to contact them? Thanks, Pierre ___ 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-36-20220718.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-36-20220717.0): ID: 1329259 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1329259 ID: 1329266 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1329266 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