New package: lowfi-2.0.6

[realcharmer]

Closes: #57993

Testing the changes

• I tested the changes in this PR: YES

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, (x86_64-glibc)

[AgarimOSLinux]

I have been using lowfi for several months. In my case I use
configure_args="--all-features" and it works perfect.

When I use
configure_args="--no-default-features --features extra-audio-formats,mpris" I get countless errors. For example:

Command: lowfi
Error: track failure

Caused by:
no track list specified! (default track list feature is disabled)

Location:
src/main.rs:132:31

[realcharmer]

@AgarimOSLinux: That is to be expected. Read the discussion in #57993. The maintainers were skeptical about merging lowfi with the default build options due to some concerns about TOS of the built-in track lists. This is a solution which, in my opinion, can be agreed upon.

Better option would be, of course, if the maintainers would agree to merge this with default build options, ergo with the built-in track list. I am open to modifying the template if that would be the case.

[realcharmer]

To get back the default behavior, you could simply run this:

curl -s -o /tmp/tracklist https://raw.githubusercontent.com/talwat/lowfi/refs/heads/main/data/chillhop.txt && lowfi -t /tmp/tracklist

[tranzystorekk]

Not sure what's the point of packaging the stripped version if it ends up basically broken and needs to be manually patched up with the old list anyway. If there was at least a way to use some other provider with more permissive TOS, I could see that as a saving grace...

[talwat]

It says it in the README, but you just have to save a track list and then use the -t flag to select it. Plus, if the user is the one to actually download the list, then void has no responsibility in that because it's not actually distributing it.

I'm not too sure how that qualifies as "broken"?

[AgarimOSLinux]

@talwat I suggest including a manual. For mostly users would be easier.

[talwat]

@talwat I suggest including a manual. For mostly users would be easier.

I think that's a good solution then. Maybe we could just package a man page with the void version, and point the user to read it in the error message?

I'm planning to add a little disclaimer in the install section anyway about this, just pointing the user in the right direction.

[AgarimOSLinux]

@talwat Every user (not only Void Linux users) could benefit from a manual.

[realcharmer]

Not sure what's the point of packaging the stripped version if it ends up basically broken and needs to be manually patched up with the old list anyway. If there was at least a way to use some other provider with more permissive TOS, I could see that as a saving grace...

It's not broken nor does it need patching. It just expects a file to read song paths from (-t flag), just like any other program. It's entirely up to the user which track list is used. Void won't provide any potential TOC violating track list by default but we can't prohibit the user from using it however the user wants, in accordance with freedom 0. In this scenario the responsibility is moved from Void to the user.

[realcharmer]

Either way, I don't really see a problem with providing the full binary with all features built-in, as other distributions do. If it was an issue, I am sure it would be brought up upstream and @talwat would be inclined to fix that.