@aptupdate Is that a regression compared to transmission-4.0.0-2.fc37 build from FEDORA-2023-e83dc0e6cb ? There shouldn't be any changes in how the daemon is built between the 4.0.0-2 and 4.0.0-3 builds.
@kalev I was too fast to give positive karma on transmission-4.0.0-2.fc37 - it failed with core-dump after running for a couple of hours. transmission-4.0.0-3.fc37 failed after only a few minutes. It can be random.
A few lines from log transmission-4.0.0-2.fc37:
Feb 16 11:34:34 hostname transmission-daemon[770]: [2023-02-16 11:34:34.139] ERR utils.cc:72 Couldn't read '/var/lib/transmission/.config/transmission-daemon/resume/81e0b8c596dfe5d1ce7fdd32f0e5847328c44de1.resume': No such file or directory (2) (/builddir/build/BUILD/transmission-4.0.0/libtransmission/utils.cc:72)
Feb 16 11:34:36 hostname transmission-daemon[770]: [2023-02-16 11:34:36.139] ERR utils.cc:72 Couldn't read '/var/lib/transmission/.config/transmission-daemon/resume/f5380a5fdd4cfef41ceb70f655b5d05f47bd8c87.resume': No such file or directory (2) (/builddir/build/BUILD/transmission-4.0.0/libtransmission/utils.cc:72)
Feb 16 12:06:02 hostname transmission-daemon[770]: /usr/include/c++/12/bits/stl_algo.h:3623: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = long unsigned int]: Assertion '!(__hi < __lo)' failed.
Feb 16 12:06:03 hostname systemd[1]: transmission-daemon.service: Main process exited, code=dumped, status=6/ABRT
Feb 16 12:06:03 hostname systemd[1]: transmission-daemon.service: Failed with result 'core-dump'.
and transmission-4.0.0-3.fc37 - stop immediatly:
Feb 16 13:59:26 hostname systemd[1]: Starting transmission-daemon.service - Transmission BitTorrent Daemon...
Feb 16 13:59:26 transmission.fredhs.net systemd[1]: Started transmission-daemon.service - Transmission BitTorrent Daemon.
Feb 16 13:59:27 hostname transmission-daemon[751]: [2023-02-16 13:59:27.805] ERR watchdir-inotify.cc:90 Couldn't watch '/data/download/blackhole': No such file or directory (2) (/builddir/build/BUILD/transmission-4.0.0/libtransmission/watchdir-inotify.cc:90)
Feb 16 14:05:37 hostname transmission-daemon[751]: /usr/include/c++/12/bits/stl_algo.h:3623: constexpr const _Tp& std::clamp(const _Tp&, const _Tp&, const _Tp&) [with _Tp = long unsigned int]: Assertion '!(__hi < __lo)' failed.
Feb 16 14:05:38 hostnamesystemd[1]: transmission-daemon.service: Main process exited, code=dumped, status=6/ABRT
Feb 16 14:05:38 hostname systemd[1]: transmission-daemon.service: Failed with result 'core-dump'.
Feb 16 14:05:38 hostname systemd[1]: transmission-daemon.service: Consumed 15.947s CPU time.
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Ah, I see. Thanks for clearing this up! Could you also file all the details in bugzilla, please, so that @limb who dealt with the first crash can see this? You could perhaps open a new ticket, or maybe just re-open https://bugzilla.redhat.com/show_bug.cgi?id=2169837 and add the details there.
As I understand it, the update to transmission 4.0.0 caused transmission-daemon to start crashing and transmission-4.0.0-2.fc37 didn't fix it completely. transmission-4.0.0-2.fc37 was however pushed to stable updates so it's already broken now for everybody.
This update (4.0.0-3.fc37) didn't fix the crash, but it wasn't supposed to either - it contained an entirely unrelated change. When you compare it to the 4.0.0-2.fc37 update that's in stable updates, this update doesn't make the situation for the crash worse - it's the same. In other words, you could say that this update doesn't regress compared to 4.0.0-2.fc37.
This is an important distinction because the feedback and karma in Bodhi is supposed to be for regression testing.
This update has been submitted for testing by kalev.
This update's test gating status has been changed to 'ignored'.
This update has been pushed to testing.
Works fine.
transmission-daemon.service: Failed with result 'core-dump'
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
@aptupdate Is that a regression compared to transmission-4.0.0-2.fc37 build from FEDORA-2023-e83dc0e6cb ? There shouldn't be any changes in how the daemon is built between the 4.0.0-2 and 4.0.0-3 builds.
Works great! LGTM! =)
kalev edited this update.
@kalev I was too fast to give positive karma on transmission-4.0.0-2.fc37 - it failed with core-dump after running for a couple of hours. transmission-4.0.0-3.fc37 failed after only a few minutes. It can be random. A few lines from log transmission-4.0.0-2.fc37:
and transmission-4.0.0-3.fc37 - stop immediatly:
Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.
Ah, I see. Thanks for clearing this up! Could you also file all the details in bugzilla, please, so that @limb who dealt with the first crash can see this? You could perhaps open a new ticket, or maybe just re-open https://bugzilla.redhat.com/show_bug.cgi?id=2169837 and add the details there.
As I understand it, the update to transmission 4.0.0 caused transmission-daemon to start crashing and transmission-4.0.0-2.fc37 didn't fix it completely. transmission-4.0.0-2.fc37 was however pushed to stable updates so it's already broken now for everybody.
This update (4.0.0-3.fc37) didn't fix the crash, but it wasn't supposed to either - it contained an entirely unrelated change. When you compare it to the 4.0.0-2.fc37 update that's in stable updates, this update doesn't make the situation for the crash worse - it's the same. In other words, you could say that this update doesn't regress compared to 4.0.0-2.fc37.
This is an important distinction because the feedback and karma in Bodhi is supposed to be for regression testing.
Ok, sorry - you are right. As far as I can see 4.0.0-3.fc37 are not a regression from 4.0.0-2.fc37
This update can be pushed to stable now if the maintainer wishes
Thanks!
This update has been submitted for stable by kalev.
This update has been pushed to stable.