Empty .log files

[unnervingduck]

whipper.log.gz

All my rips have an empty .log file (0 bytes) after succesfully ripping a CD, using whipper 0.10.0 on Fedora 40, installed from the official repos.

I run whipper simply with whipper cd rip and my config looks like this:

[drive:ASUS%20%20%20%20%3ASDRW-08D2S-U%20%20%20%20%3ABA01]
vendor = ASUS


model = SDRW-08D2S-U
release = BA01
defeats_cache = True
read_offset = 6

There's this traceback that occurs in the end:

Traceback (most recent call last):
  File "/usr/bin/whipper", line 33, in <module>
    sys.exit(load_entry_point('whipper==0.10.0', 'console_scripts', 'whipper')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/command/main.py", line 56, in main
    ret = cmd.do()
          ^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/command/basecommand.py", line 141, in do
    return self.cmd.do()
           ^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/command/basecommand.py", line 141, in do
    return self.cmd.do()
           ^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/command/cd.py", line 203, in do
    ret = self.doCommand()
          ^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/command/cd.py", line 589, in doCommand
    self.program.writeLog(discName, self.logger)
  File "/usr/lib64/python3.12/site-packages/whipper/common/program.py", line 699, in writeLog
    log = txt_logger.log(self.result)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/result/logger.py", line 22, in log
    return self.logRip(ripResult, epoch)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.12/site-packages/whipper/result/logger.py", line 151, in logRip
    riplog = yaml.dump(
             ^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/ruamel/yaml/main.py", line 1251, in dump
    error_deprecation('dump', 'dump', arg="typ='unsafe', pure=True")
  File "/usr/lib/python3.12/site-packages/ruamel/yaml/main.py", line 1039, in error_deprecation
    raise AttributeError(s, name=None)
AttributeError: 
"dump()" has been removed, use

  yaml = YAML(typ='unsafe', pure=True)
  yaml.dump(...)

instead of file "/usr/lib64/python3.12/site-packages/whipper/result/logger.py", line 151

        riplog = yaml.dump(

[github-actions[bot]]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

[hapla]

Following. I have the same problem. It seems that dump() and some other functions have been removed in ruamel.yaml version 0.18.0. Fedora 40 has updated to python3-ruamel-yaml-0.18.5 version.

[thecnoNSMB]

I am also experiencing this issue.

[chuckufarley73]

Wasn't searching for this but coincidentally can confirm have also recognised the same issue presenting again under Fedora 40. Thanks for highlighting, wasn't sure whether it was just a random happening..

[mttmartin]

I'm also seeing this on Fedora 40. I briefly looked into it, and the problem appears to be fixed by this commit: https://github.com/whipper-team/whipper/commit/e0942417a1c267781a8b676789730457dcb2e6fa

Unfortunately the last whipper release (10.0.0) was created a couple months before this commit, so that commit is missing from the packaged version we have in the repo.

If it helps, installing the current commit (a4b97422eab6080e974bd001df7c66a6dc5e713d) from the git repo seems to have fixed the issue for me and was fairly straightforward.

[chuckufarley73]

Thanks very much for the response and for having taken a look into this! I wasn't entirely sure it was entirely me but between what I could find via Google and the cdrdao man pages I was still left unclear whether the 'data' in the toc, trying to feed it multiple .wav's, or Other where the chief impediment.

Thanks for clarifying the situation, I'm content to sit back until the commit emerges in a future update as aren't particularly adventurous re commits or Git if I'm honest, only registered in order to post queries or issues occasionally!

Regards, Stu

On Sat, 29 Jun 2024, 16:12 Matthew Martin, @.***> wrote:

I'm also seeing this on Fedora 40. I briefly looked into it, and the problem appears to be fixed by this commit: e094241 https://github.com/whipper-team/whipper/commit/e0942417a1c267781a8b676789730457dcb2e6fa

Unfortunately the last whipper release (10.0.0) was created a couple months before this commit, so that commit is missing from the packaged version we have in the repo.

If it helps, installing the current commit (a4b9742 https://github.com/whipper-team/whipper/commit/a4b97422eab6080e974bd001df7c66a6dc5e713d) from the git repo seems to have fixed the issue for me and was fairly straightforward.

— Reply to this email directly, view it on GitHub https://github.com/whipper-team/whipper/issues/626#issuecomment-2198226985, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3N7NVOV3TYMBINBWWKHDRTZJ3FEPAVCNFSM6AAAAABI23F7PSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGIZDMOJYGU . You are receiving this because you commented.Message ID: @.***>

[mavit]

Fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2024-954f77c437?

[unnervingduck]

Fixed by https://bodhi.fedoraproject.org/updates/FEDORA-2024-954f77c437?

Can confirm this fixed it on my Fedora installation. Another problem I had disappeared too, ejecting after a successful rip now works.