devel January 2024

devel@lists.fedoraproject.org

163 participants
245 discussions

Request for Review for Two New Packages
by Carlos Rodriguez Fernandez 06 Feb '24

06 Feb '24

Hi All, I posted two new packages for review. Feedback is highly appreciated :) mk-configure https://bugzilla.redhat.com/show_bug.cgi?id=2257985 libmaa https://bugzilla.redhat.com/show_bug.cgi?id=2257986 Some context: I took the orphan package dictd. Dictd depends on libmaa. The dictd spec was pulling libmaa source and building it, and linking to it statically. Libmaa is not available as a package in Fedora. I am separating them and making libmaa available as a dynamic library and its own package. libmaa builds with mk-configure. The new dictd being developed builds with mk-configure as well. For that reason, I went ahead and created also that new mk-configure package. Both packages are necessary to update dictd going forward. Thank you, Carlos R F.

2 1

Package review ticket status change after approval
by Mattia Verga 06 Feb '24

06 Feb '24

Hello folks, before all, I want to thank everyone putting their time in reviewing new package requests! That is a key task in distinguish Fedora among the other Linux distribution and ensure we have high quality packages in our repositories. That said, I'd like to make a request and maybe make all reviewers aware of a feature which was implemented some time ago. I've noticed many reviewers change the ticket status from ASSIGNED to POST when they flag the package as approved: I'd like to request to not do that. The Package Review Tracker webpages make a distinction between packages approved (fedora-review flag set to +) and packages approved AND being built in Fedora. That distinction relies on the ticket status change to POST, which is automatically set when the repository is created in src.fp.o. I think that distinction can be useful to see all packages that were approved, but for some reason the submitter never asked for the repository to be created. So, if you also think that is useful and can change what it may have become a routine for you, just set the review flag accordingly without changing the ticket status. BTW, for the future (if I find some spare time) I plan to change the interface of the Package Review Tracker webpages by moving from using colors to icons. That's because the colors are currently mutually exclusive i.e. whenever a ticket is marked NEEDSPONSOR, the green background will take precedence over all other descriptions. By using multiple icons, we can have better "visual categorization" (and, maybe, enhance the js filter). But before doing so, I'll make a preview of the change and post it here (or on Discussion) to get some feedback... Thanks Mattia

5 6

Heads-up: abseil-cpp 20240116.0 coming to F40/Rawhide
by Ben Beasley 05 Feb '24

05 Feb '24

In one week, 2024-02-04, or slightly later, I plan to update abseil-cpp from 20230802.1 to 20230116.0 (Abseil LTS branch, Jan 2024)[1] in side tags for F40/Rawhide. If I miss getting the update into Rawhide before F40 branching, I plan to do the update in both F41/Rawhide and F40/Branched. Like all new calendar versions of abseil-cpp, this breaks ABI compatibility and bumps the SONAME version. There are also some small intentional breaking API changes[2]. Testing in COPR[3] indicates all directly-dependent packages are compatible, except mozc, which can be fixed by a PR[4]. Besides abseil-cpp, I plan to rebuild all dependent packages using maintainer/co-maintainer or provenpackager privileges. I also plan to merge the mozc PR if it is still open. These packages are: - bear - bloaty - credentials-fetcher - CuraEngine_grpc_definitions - fastnetmon - fcitx5-mozc - frr - grpc - ilbc - libarrow - libphonenumber - mozc - onnxruntime - parlaylib - plasma-dialer - qmlkonsole - qt6-qtgrpc - spacebar - syslog-ng Of these, I expect plasma-dialer and syslog-ng to FTBFS in the side tag since they already FTBFS in Rawhide. Maintainers of all affected packages should have received this email directly (by BCC rather than CC, to keep the message from being held for moderation due to a long CC list). If you want to handle the rebuild of the package yourself, or you have other questions or concerns, please just let me know before 2024-02-04. – Ben Beasley (FAS: music) [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/16 [2] https://github.com/abseil/abseil-cpp/releases/tag/20240116.0 [3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/ [4] https://src.fedoraproject.org/rpms/mozc/pull-request/6

4 4

Mounting USB Storage devices with "sync" option ?
by Abyss Ether 05 Feb '24

05 Feb '24

I created a simple PoC udev rule to mount USB Storage devices with the "sync option. Available here : https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage… Currently, USB Storage devices are mounted without the "sync" option, causing their writes to be cached. This causes an issue, especially with GUI file managers like GNOME Files, where after a file copy operation, it would notify the user that the operation has been completed. If the user then tries to unmount the USB Storage device, they get notified that data is still being written to disk and that they should not remove the USB Storage device from their PC/Laptop/device. This can take a more severe form if the user is using a CLI/GUI utility that DOES NOT inform the user that data is still being written, like the 'cp' CLI utility, the user might be misled into thinking that all writes have finished and plug the USB drive out, at which point data corruption due to unfinished writes occur. This is why, I think functionality should be included in Fedora Linux (or atleast in Fedora Workstation and other desktop spins) such that USB Storage devices are mounted with the "sync" options by default.

13 20

sd_notify in mock
by Vít Ondruch 03 Feb '24

03 Feb '24

Working on update of rubygem-puma, I observe following test failure trying build rubygem-rails in Mock: ~~~ /usr/share/ruby/socket.rb:68:in `connect': Errno::EACCES: Permission denied - connect(2) for /run/host/notify (Puma::SdNotify::NotifyError) from /usr/share/ruby/socket.rb:68:in `connect_internal' from /usr/share/ruby/socket.rb:141:in `connect' from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:140:in `notify' from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:53:in `ready' from /usr/share/gems/gems/puma-6.4.2/lib/puma/plugin/systemd.rb:17:in `block in start' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `block in fire' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `each' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `fire' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:46:in `fire_on_booted!' from /usr/share/gems/gems/puma-6.4.2/lib/puma/single.rb:58:in `run' from /usr/share/gems/gems/puma-6.4.2/lib/puma/launcher.rb:194:in `run' from /usr/share/gems/gems/puma-6.4.2/lib/rack/handler/puma.rb:76:in `run' from /usr/share/gems/gems/rack-2.2.4/lib/rack/server.rb:327:in `start' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:38:in `start' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:143:in `block in perform' from <internal:kernel>:90:in `tap' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:134:in `perform' from /usr/share/gems/gems/thor-1.2.1/lib/thor/command.rb:27:in `run' from /usr/share/gems/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command' from /usr/share/gems/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command/base.rb:87:in `perform' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command.rb:48:in `invoke' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands.rb:18:in `<top (required)>' from /usr/share/ruby/bundled_gems.rb:74:in `require' from /usr/share/ruby/bundled_gems.rb:74:in `block (2 levels) in replace_require' from bin/rails:4:in `<main>' /usr/share/ruby/socket.rb:68:in `connect': Permission denied - connect(2) for /run/host/notify (Errno::EACCES) from /usr/share/ruby/socket.rb:68:in `connect_internal' from /usr/share/ruby/socket.rb:141:in `connect' from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:140:in `notify' from /usr/share/gems/gems/puma-6.4.2/lib/puma/sd_notify.rb:53:in `ready' from /usr/share/gems/gems/puma-6.4.2/lib/puma/plugin/systemd.rb:17:in `block in start' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `block in fire' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `each' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:17:in `fire' from /usr/share/gems/gems/puma-6.4.2/lib/puma/events.rb:46:in `fire_on_booted!' from /usr/share/gems/gems/puma-6.4.2/lib/puma/single.rb:58:in `run' from /usr/share/gems/gems/puma-6.4.2/lib/puma/launcher.rb:194:in `run' from /usr/share/gems/gems/puma-6.4.2/lib/rack/handler/puma.rb:76:in `run' from /usr/share/gems/gems/rack-2.2.4/lib/rack/server.rb:327:in `start' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:38:in `start' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:143:in `block in perform' from <internal:kernel>:90:in `tap' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands/server/server_command.rb:134:in `perform' from /usr/share/gems/gems/thor-1.2.1/lib/thor/command.rb:27:in `run' from /usr/share/gems/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command' from /usr/share/gems/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command/base.rb:87:in `perform' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/command.rb:48:in `invoke' from /builddir/build/BUILD/railties-7.0.8/usr/share/gems/gems/railties-7.0.8/lib/rails/commands.rb:18:in `<top (required)>' from /usr/share/ruby/bundled_gems.rb:74:in `require' from /usr/share/ruby/bundled_gems.rb:74:in `block (2 levels) in replace_require' from bin/rails:4:in `<main>' . ~~~ The full log is available here for the moment: https://copr.fedorainfracloud.org/coprs/vondruch/mpb/build/6885294/ This is the sd_notify source code: https://github.com/agis/ruby-sdnotify/blob/master/lib/sd_notify.rb Nothing spectacular is going on there except it tries to write into socket if the `$NOTIFY_SOCKET` env variable is set. I believe that if I did `env -u NOTIFY_SOCKET`, I would get further. However, I wonder how and why the NOTIFY_SOCKET variable is set? I also wonder why the socket exists if it can't be used? Or would it be usable by `root` so the permissions should be checked first? ~~~ $ mock -r ruby shell --unpriv ... snip ... <mock-chroot> sh-5.2$ echo $NOTIFY_SOCKET /run/host/notify <mock-chroot> sh-5.2$ ll /run/host/notify srwxr-xr-x. 1 root root 0 Jan 11 14:35 /run/host/notify ~~~ It does not seems to be right, but I have no idea where to report this. Is this issue in sd_notify, Mock or is it systemd? Interestingly enough, I don't have this env variable set on my computer. Vít

1 1

[Test-Announce] Kernel 6.7 Test Week is underway!
by Sumantro Mukherjee 01 Feb '24

01 Feb '24

Hey Folks, As most of you might know, Kernel 6.7 Test Week is currently happening[0] I have figured out that, I can't login to FAS from the Kernel Test Result site[1]. If you are also someone who is stuck, please follow the infra issue filed here[2]. And please submit the results here[3] If you have still not participated and have some free time, we urge you to take part in testing! We are also sorry for the inconvenience caused due to login issues. Thanks for testing :) [0] http://fedoraproject.org/wiki/Test_Day:2024-01-21_Kernel_6.7_Test_Week [1] https://apps.fedoraproject.org/kerneltest/ [2] https://pagure.io/fedora-infrastructure/issue/11744 [3] https://testdays.fedoraproject.org/events/173 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED -- _______________________________________________ test-announce mailing list -- test-announce(a)lists.fedoraproject.org To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedorapro… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

4 6

Looking for a new maintainer for ode
by Hans de Goede 01 Feb '24

01 Feb '24

Hi All, I used to do a lot of gaming related Fedora packaging and I still maintain over 200 pkgs, but I really don't have much time for Fedora package maintainership anymore. The last few years I have been limiting my package maintainership to fixing FTBFS, which for many game packages is fine since they are not seeing any new upstream releases. ode is currently 1 minor release behing the latest upstream release and I don't have the time to fix it (since this is just a minor bump the rebase should be trivial): https://bugzilla.redhat.com/show_bug.cgi?id=2218304 Anyone interested in taking over ode maintainership from me ? Regards, Hans

2 2

A reminder: you cannot just "revert" package version bumps
by Adam Williamson 01 Feb '24

01 Feb '24

nirik ran a script that checks for versioning issues in Rawhide today, and it found several: https://pagure.io/releng/issue/11922#comment-893797 Some of these followed a pattern, so I figured a reminder was in order. In all these cases, a new version was pushed to Rawhide, then "reverted" some time later: golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to 1.2.2 in September golang-google-grpc - bumped to 1.58.0 in September, reverted to 1.48.0 in October; no 1.58.0 build ever landed, but the revert left the %release much lower than before python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3 on September 12 python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4 later the same day so the reminder is this: you cannot simply "downgrade" RPM package versions like this. Especially not if the upgraded version ever made it into a Rawhide compose. If a Rawhide user has your package installed, and got the upgraded version, they will be marooned on that build forever unless they manually run `dnf distro-sync`. A `dnf upgrade` will not downgrade the package to the build you now consider to be the "current" one. If you have to downgrade a package that made it to a Rawhide compose, you must use an epoch. If the package did not have an epoch before, make it `Epoch: 1`. If it had an epoch already, bump it by 1. People tend not to like epochs, so *try* not to have to do this. Be really certain before pushing out version bumps. If the "upgraded" build never made it into a compose (as is likely the case for python-pywlroots) you're *probably* okay, but it's still something to be careful about - for instance you might fall into the trap golang-google-grpc fell into with the %release tag. Thanks folks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

8 13

Orphaned python-mccabe (dependency of pylint)
by Miro Hrončok 01 Feb '24

01 Feb '24

Hello. I have orphaned python-mccabe. It does not build with updated hypothesis, because the update broke hypothesmith and I don't have time to look into it: https://bugzilla.redhat.com/2261579 mccabe is a dependency of pylint. Packages other than linters should not BuildRequire pylint in Fedora (but they do). The recursive dependency tree is very large. Here are some basics: $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe pylint-0:3.0.3-3.fc40.src python-f5-icontrol-rest-0:1.3.15-11.fc39.src python-flake8-0:6.0.0-2.fc39.src python-lsp-server-0:1.9.0-3.fc40.src python-twitter-0:3.5-18.fc39.src python3-flake8-0:6.0.0-2.fc39.noarch python3-lsp-server+all-0:1.9.0-3.fc40.noarch python3-pylint-0:3.0.3-3.fc40.noarch $ repoquery -q --repo=rawhide{,-source} --whatrequires pylint --whatrequires python3-pylint crypto-policies-0:20231204-1.git1e3a2e4.fc40.src distro-info-0:0.18-18.fc39.src dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch foomuuri-0:0.21-1.fc40.src nordugrid-arc-0:6.18.0-2.fc40.src nvme-stas-0:2.3.1-1.fc40.src postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch pylint-0:3.0.3-3.fc40.noarch python-geoplot-0:0.5.1-7.fc40.src python-guessit-0:3.8.0-1.fc40.src python-hwdata-0:2.3.8-4.fc39.src python-platformio-0:6.1.13-1.fc40.src python-pocketlint-0:0.25-1.fc40.src python-pylint-venv-0:3.0.2-1.fc40.src python-rebulk-0:3.3.0-1.fc40.src python3-pocketlint-0:0.25-1.fc40.noarch python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch thonny-0:4.1.4-1.fc40.noarch thonny-0:4.1.4-1.fc40.src vcs-diff-lint-0:4-3.fc39.noarch vim-syntastic-python-0:3.10.0-21.fc39.noarch $ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe --recursive crypto-policies-0:20231204-1.git1e3a2e4.fc40.src diskimage-builder-0:3.31.0-2.fc40.noarch distro-info-0:0.18-18.fc39.src dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch foomuuri-0:0.21-1.fc40.src glances-0:3.4.0-3.fc39.src mu-0:1.2.0-10.fc40.noarch mu-0:1.2.0-10.fc40.src nordugrid-arc-0:6.18.0-2.fc40.src nvme-stas-0:2.3.1-1.fc40.src ocaml-atd-0:2.15.0-3.fc40.src piper-0:0.7-5.fc39.src postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch pyee-0:9.0.4-6.fc39.src pylint-0:3.0.3-3.fc40.noarch pylint-0:3.0.3-3.fc40.src python-binary-memcached-0:0.31.2-2.fc39.src python-croniter-0:1.4.1-1.fc40.src python-debianbts-0:2.8.2-13.fc39.src python-django-formtools-0:2.2-10.fc39.src python-esbonio-0:0.16.4-3.fc40.src python-f5-icontrol-rest-0:1.3.15-11.fc39.src python-factory-boy-0:3.3.0-1.fc40.src python-flake8-0:6.0.0-2.fc39.src python-flake8-builtins-0:2.1.0-4.fc39.src python-flake8-comprehensions-0:3.10.1-6.fc39.src python-flake8-import-order-0:0.18.2-3.fc39.src python-flake8-polyfill-0:1.0.2-19.fc39.src python-flake8-quotes-0:3.3.2-4.fc39.src python-flask-mailman-0:1.0.0-1.fc40.src python-geoplot-0:0.5.1-7.fc40.src python-gerritlib-0:0.6.0-24.fc39.src python-guessit-0:3.8.0-1.fc40.src python-hacking-0:6.0.1-1.fc40.src python-hwdata-0:2.3.8-4.fc39.src python-ipmi-0:0.5.4-3.fc39.src python-lsp-server-0:1.9.0-3.fc40.src python-nashpy-0:0.0.40-1.fc39.src python-nikola-0:8.2.4-4.fc39.src python-oslo-context-0:5.2.0-1.fc40.src python-oslo-service-0:3.1.1-8.fc40.src python-pep8-naming-0:0.13.3-3.fc39.src python-platformio-0:6.1.13-1.fc40.src python-pocketlint-0:0.25-1.fc40.src python-pylint-venv-0:3.0.2-1.fc40.src python-pymochad-0:0.2.0-10.fc39.src python-pytest-flake8-path-0:1.5.0-1.fc39.src python-rebulk-0:3.3.0-1.fc40.src python-sqlalchemy-utils-0:0.41.1-2.fc39.src python-twitter-0:3.5-18.fc39.src python3-esbonio+dev-0:0.16.4-3.fc40.noarch python3-flake8-0:6.0.0-2.fc39.noarch python3-flake8-builtins-0:2.1.0-4.fc39.noarch python3-flake8-comprehensions-0:3.10.1-6.fc39.noarch python3-flake8-docstrings-0:1.6.0-6.fc39.noarch python3-flake8-import-order-0:0.18.2-3.fc39.noarch python3-flake8-polyfill-0:1.0.2-19.fc39.noarch python3-flake8-quotes-0:3.3.2-4.fc39.noarch python3-hacking-0:6.0.1-1.fc40.noarch python3-lsp-server+all-0:1.9.0-3.fc40.noarch python3-oslo-concurrency-tests-0:5.2.0-1.fc40.noarch python3-oslo-service-tests-0:3.1.1-8.fc40.noarch python3-oslo-utils-tests-0:6.2.1-1.fc40.noarch python3-pep8-naming-0:0.13.3-3.fc39.noarch python3-pocketlint-0:0.25-1.fc40.noarch python3-pylint-0:3.0.3-3.fc40.noarch python3-pytest-flake8-path-0:1.5.0-1.fc39.noarch python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch python3-tackerclient-tests-unit-0:1.14.0-1.fc40.noarch quodlibet-0:4.6.0-1.fc40.src repo-0:2.35-1.fc39.src spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.src thonny-0:4.1.4-1.fc40.noarch thonny-0:4.1.4-1.fc40.src vcs-diff-lint-0:4-3.fc39.noarch vim-syntastic-python-0:3.10.0-21.fc39.noarch xr-hardware-0:1.1.0-1.fc40.src -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 5

Orphaning python-represent
by Lumír Balhar 01 Feb '24

01 Feb '24

Hello. I'm going to orphan python-represent. I updated it to the latest version so if you take it, there is nothing to be done now. It's a leaf package and I don't have any use for it. Have a nice day. Lumír

2 1

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2024