Unrar not working with version error reporting in UI #2832
Comments
|
it should be installing the non-free
|
|
@thezoggy Ok so I understand, you are saying that unrar-nonfree >= 7 is a hard dependency on the host? I can try to install that and retest and will update here. |
|
no, im saying that it should have installed the unrar-nonfree. as you have no version im guessing you have the unrar-free version (which isnt supported). do |
|
I'm surprised, because the SABnzbd flatpak brings it own unrar: https://github.com/flathub/org.sabnzbd.sabnzbd/blob/master/org.sabnzbd.sabnzbd.yaml#L84-L90C13 @kkcarlc what does you sabnzbd.log say related to this: |
|
which unrar
=> /usr/local/bin/unrar
unrar |grep Copyright
=> UNRAR 7.00 freeware Copyright (c) 1993-2024 Alexander RoshalI had some permission overrides that I reset to the defaults and reinstalled the flatpak with Entering the flatpak with dpkg -s unrar-free
dpkg-query: package 'unrar-free' is not installed and no information is available |
|
@sanderjo Last log I have is from 2023 and it says: 2023-11-25 02:03:07,212::INFO::[SABnzbd:460] UNRAR binary... found (/app/bin/unrar)
2023-11-25 02:03:07,212::INFO::[SABnzbd:468] UNRAR binary version 6.24Looking at the settings UI in |
|
Ouch ... I can confirm on my Ubuntu ... running on a very old laptop with B820 Celeron from 2012. So is this the unrar with too high CPU features? @kkcarlc on what CPU are you running it? |
|
@sanderjo Running on a |
|
Please do not install unrar on your own system (unless you need to)! The Flatpak includes the unrar bin, so it matches the correct/recommended spec of the app itself. :) I'll check if I'm having the same error, because I did bump unrar and other deps. Maybe the path inside de Flatpak differs, which could be possible. @thezoggy I'm using the unrar-src package from RarLab itself. |
|
@francoism90 I do see the path from the recent logs shared above as |
|
@kkcarlc Thanks for reporting! Think it may be caused because I've bump unrar-src. 🤔 Not on the computer right now, will check later today. |
So ... related to / same as linuxserver/docker-unrar#4 ? So the new Because: compile option of unrar (as provided by rarlab) compiles for "recent" x86 hardware. Gives problems on old x86 hardware. EDIT I don't know if this is relevant / legal at all, but on my 2012 Celeron, I get this: Not a core dump, but might be bad. I don't know EDIT 2: I installed flatpak & flatpak-sabnzbd on my modern x86, and
This confirms my hypothesis that the flatpak itself is correct, with unrar, but only for new hardware, due to the compile option in the rarlab provided makefile. |
|
For the record, this my complete start output: $ flatpak run org.sabnzbd.sabnzbd
2024-04-06 10:22:21,140::INFO::[SABnzbd:1144] --------------------------------
2024-04-06 10:22:21,140::INFO::[SABnzbd:1145] SABnzbd.py-4.2.3
2024-04-06 10:22:21,140::INFO::[SABnzbd:1155] Commit = e7e06dea419a03bfe179af64b7a69398f652a7b9
2024-04-06 10:22:21,140::INFO::[SABnzbd:1157] Full executable path = /app/bin/SABnzbd.py
2024-04-06 10:22:21,140::INFO::[SABnzbd:1158] Arguments = "/app/bin/SABnzbd.py"
2024-04-06 10:22:21,140::INFO::[SABnzbd:1159] Python-version = 3.11.8 (main, Nov 10 2011, 15:00:00) [GCC 13.2.0]
2024-04-06 10:22:21,140::INFO::[SABnzbd:1160] Dockerized = False
2024-04-06 10:22:21,141::INFO::[SABnzbd:1161] CPU architecture = x86_64
2024-04-06 10:22:21,142::INFO::[SABnzbd:1164] Platform = posix - Linux-6.8.1-300.fc40.x86_64-x86_64-with-glibc2.38
2024-04-06 10:22:21,143::INFO::[SABnzbd:1170] Preferred encoding = UTF-8
2024-04-06 10:22:21,143::INFO::[SABnzbd:1192] SSL version = OpenSSL 3.1.5 30 Jan 2024
2024-04-06 10:22:21,144::INFO::[SABnzbd:1201] Certifi version = 2024.02.02
2024-04-06 10:22:21,145::INFO::[SABnzbd:1202] Loaded additional certificates from /app/lib/python3.11/site-packages/certifi/cacert.pem
2024-04-06 10:22:21,145::INFO::[SABnzbd:1212] Using INI file /var/home/user/.sabnzbd/sabnzbd.ini
2024-04-06 10:22:21,146::INFO::[postproc:143] Loading postproc queue
2024-04-06 10:22:21,147::INFO::[scheduler:190] Scheduling RSS interval task every 60 min (delay=22)
2024-04-06 10:22:21,147::INFO::[scheduler:200] Scheduling version check in 10 minutes and daily at 15:5
2024-04-06 10:22:21,147::INFO::[scheduler:225] Setting schedule for midnight BPS reset
2024-04-06 10:22:21,147::INFO::[scheduler:234] Setting schedule for midnight server expiration check
2024-04-06 10:22:21,147::INFO::[scheduler:243] Setting schedule for server quota check
2024-04-06 10:22:21,147::INFO::[__init__:323] All processes started
2024-04-06 10:22:21,147::INFO::[SABnzbd:338] Template location for Glitter is /app/bin/interfaces/Glitter
2024-04-06 10:22:21,148::INFO::[SABnzbd:338] Template location for Config is /app/bin/interfaces/Config
2024-04-06 10:22:21,149::INFO::[misc:1230] [N/A] Running external command: ['/app/bin/unrar']
2024-04-06 10:22:21,152::INFO::[misc:1230] [N/A] Running external command: ['/app/bin/7z']
2024-04-06 10:22:21,169::INFO::[misc:1230] [N/A] Running external command: ['/app/bin/par2', '-V']
2024-04-06 10:22:21,174::INFO::[SABnzbd:423] SABCTools module (v8.1.0)... found!
2024-04-06 10:22:21,174::INFO::[SABnzbd:424] SABCTools module is using SIMD set: AVX2
2024-04-06 10:22:21,174::INFO::[SABnzbd:425] SABCTools module is linked to OpenSSL: True
2024-04-06 10:22:21,174::INFO::[SABnzbd:445] Cryptography module (v42.0.5)... found!
2024-04-06 10:22:21,175::INFO::[SABnzbd:451] par2 binary... found (/app/bin/par2)
2024-04-06 10:22:21,175::INFO::[SABnzbd:458] UNRAR binary... found (/app/bin/unrar)
2024-04-06 10:22:21,175::INFO::[SABnzbd:466] UNRAR binary version 7.00
2024-04-06 10:22:21,175::INFO::[SABnzbd:473] 7za binary... found (/app/bin/7z)
2024-04-06 10:22:21,175::INFO::[SABnzbd:475] 7za binary version 17.05
2024-04-06 10:22:21,175::INFO::[SABnzbd:481] nice binary... found (/usr/bin/nice)
2024-04-06 10:22:21,175::INFO::[SABnzbd:485] ionice binary... found (/usr/bin/ionice)
...I can also enter it fine, and execute flatpak enter org.sabnzbd.sabnzbd bash
$ /app/bin/unrar -v
UNRAR 7.00 freeware Copyright (c) 1993-2024 Alexander Roshal@kkcarlc Just a few questions:
@sanderjo I prefer upstream to solve this, instead of adjusting flags. Do other Flatpaks have issues with unrar as well? Did anyone contact RarLab? |
|
Ah, that test method is nice! It works ... as long as flatpak-sabnzbd is running (so just like with docker): On my recent x86: I'll have access to the old x86 tonight, so I can test then. In the meantime OP @kkcarlc could do that. Your questions:
Note: I'm not a flatpak user; I just installed flatpak for this github issue. Regarding upstream: clear. I don't know if that is happening at rarlab. |
|
@sanderjo Thanks for testing! :) Yeah, if this is an unrar-src issue, it may also affects users outside the docker/flatpak/etc. sandbox. I try to avoid adjusting flags and makefiles, as upstream should handle these cases (in my opinion at least - excluding 'simple' stuff like paths, etc.). |
|
@francoism90 optimizing for the native arch of the system during compile only makes sense in case the compiled program is either only ever used on that very system, or compatibility between that system and all other 100% guaranteed. As soon as you end up distributing to other systems without the luxury of that degree of compatibility (e.g. anything from flatpak to linux distributions) you don't really have a choice but to target a certain common hardware baseline and instruction set, regardless of upstream's default compiler options. Any program that wants to go beyond that will have to rely on runtime detection of hardware features (which unrar supports just fine). |
|
Ah, "good" news: I've got another old x86 (Intel(R) Core(TM) i7-2635QM ... from 2011), with Ubuntu 22.04, and flatpak-sabnzbd does show
@Safihre again I would like to suggest that SABnzbd checks the unrar output for the |
|
@sanderjo Could you please report your findings to RARLAB? I'm willing to change the flags, if they say they are not going to fix it. |
|
@francoism90 I believe that @Safihre is already doing that. He has a warm relation with rarlab. |
|
Yep, I'll do that. |
|
@jcfp I think Flatpak already handles this, as they do build the package (also for ARM). In most cases, I don't think you should have to adjust flags for Flatpak/Docker/Snap, etc. |
|
To add to (my) confusion (again): the unrar from rarlab does run on my i7. But then I don't understand yet why the flatpak-SABnzbd unrar version already fails. Plain sabnzbd straight on Ubuntu 22.04 on my old 2011 i7, with unrar 7 from rarlab, does report the version correctly: So:
|
|
OK ... based on the above, I did something ugly, but it works: copy the compiled unrar 7 binary from rarlab into the flatpak So @francoism90 is that acceptable & feasible for you? No compiling unrar, but getting the unrar compiled binary. |
|
@sanderjo I do not like this approach. We have seen what Like I said before, this issue also exists outside Flatpak. Edit: I also don't know if just including the |
If they did, this issue wouldn't exist in the first place. If anything, flatpak builds may simply rely on compiler defaults; i.e., the low-end baseline most compilers (gcc and the likes) target by default unless instructed otherwise (e.g. via -march). |
|
@jcfp We don't know if Flatpak is to blame here. Because @sanderjo already compiled unrar on an older system, and got the same error. @Safihre is contacted RARLab, and I think this is the correct approach. It doesn't look the Flatpak Builder is doing wrong here, also because @sanderjo also linked to Docker build issues. |
|
Got a very quick response from Rarlab. Think we need @animetosho input on this one:
|
It shouldn't be defined and he shouldn't be trying to make it defined. |
2024-04-06 15:41:31,173::INFO::[SABnzbd:458] UNRAR binary... found (/app/bin/unrar)
2024-04-06 15:41:31,174::INFO::[notifier:142] Sending notification: Warning - Your UNRAR version is 0.00, we recommend version 5.50 or higher.<br />
To prevent all helpful warnings, disable Special setting 'helpful_warnings'. (type=warning, job_cat=None)
2024-04-06 15:41:31,174::WARNING::[misc:94] Your UNRAR version is 0.00, we recommend version 5.50 or higher.<br />
|
|
Rolling back to release flatpak --user update --commit=1b93894a78966e8ec2005d49ab0faf8ffb90b5c0f1561dfa471a184eb6a25c02 org.sabnzbd.sabnzbdconfirms that the binary is shipped with the flatpak and is an older version. flatpak enter org.sabnzbd.sabnzbd bash
/app/bin/unrar | head -2
#=> UNRAR 6.24 freeware Copyright (c) 1993-2023 Alexander RoshalThe UI doesn't report the error of flatpak version |
|
to note that lsio did change their build process a few weeks ago to drop i do believe only the nightly branch have gotten the update, so master/unstable at this time would still use dockermod until they do. |
|
@thezoggy I'm I understanding correctly we need to wait for a version bump of unrar to fix this? :) |
Depends, for the ARM64 one or what most of the people have complained about with it being busted in docker for those with legacy cpu.. its fallout of linuxserver using CXXFLAGS which they dropped on the nightly tag. If your using master/unstable you just gotta wait for them to pull in update (trigger force package) since they control their unrar themselves as they built it out for all their stuff. Or of course just build your own. If using native unrar builds from rarlab and that one isnt working on a glibc system, then perhaps that build needs a bugfix (and if fixed in newer versions, then yes bump required if not silently replacing existing build). But it wasn't clear if what animetosho was talking about made it back to unrar dev to do anything. Again all the ones I've seen of unrar being broken has just been due to lsio unrar trying to target modern cpu and they are just rocking old atom cpu or something that doesnt have full support for the instruction when that flag was used, but now after being dropped should have restored compatibility. other docker maintainers do use lsio unrar as well.. which is why it can get a little confusing when people talk about what doesnt or does work. |
|
@animetosho I got a reply:
|
|
It looks like older versions of Clang have a bug where it hides functions behind define checks, so function-level arch targeting doesn't work for ARM. If you want to support older compilers, the way to work around the issue would be to split arch specific functions to separate their own file, then use Maybe there's some workaround for Clang to make function-level targeting work. I think some libraries rely on this, so perhaps check those. But given that it works fine on Clang 17, I'm willing to chalk it up as a compiler bug more than anything else. |
|
I am going to close this. There is nothing more we can do.. Rarlabs should fix this, we gave them all the suggestions by @animetosho. |
|
So this effectively ends sabnzbd support for older cpus after version 4.2.2. I'm running sabnzbd on an older box. I think this would be more common than not. I understand the bug is upstream, but upstream should not be building with Can upstream not support all x86-64 cpus with Is it possible to work around upstream by bind mounting unrar into the flatpak? Should I contact upstream by discussing with them via email as suggested from their website? I am not understanding the ARM64 argument. Different compilations need to happen for different architectures. Why is not the default x86 architecture to support older cpus? |
Presumably the dev doesn't know how to supply different flags for different archs, and doesn't want to supply a second Makefile, so they just throw a "it's fixed" |
Sab is not rar nor do we distribute rar on Linux. If your not happy with flatpak because of the packages it's installing then switch to something else that gives you the control or figure out how to update the env with what you want... Someone submitted stuff to do snap.. which I guess is used for flatpak as well? I'm not familiar with how it's used to know if it's stage vs build package needs a change or what specifically it's not working for you. For what I've seen with reports the issue generally has been peoples builds were using the wrong march for the system.. which shouldn't be the case if it's just installing the package from your os.. If the unrar version isn't working for you because of who build it, try another build. If it's not working because of a bug, then try another version. If its a bug with unrar that's installed on your os then might need to report it to unrar.. but again need to figure out if it's actually a problem with official build or something your building yourself or what |
|
Isn't the value proposition of flatpak to work across environments? For those officially packaging software in flatpak it seems that it would fall under their purview. A collective shrug at the end of this isn't entirely unexpected, albeit disappointing. However, there is no obligation to provide software in the first place, so I have no expectation nor entitlement in that regard. Sabnzbd is great software and I thank you for it. Additionally, thank you for spending the time looking into the issue. |
Per: It's meant for aarch64, x86_64. |
|
No I am using x86_64. The discussion mentioning ARM was that upstream was patching for ARM and using This is my processor: I am not super familiar with building flatpak, but a workaround I was looking into was bind mounting into the app directory to provide my own unrar binary. However due to the sandboxing this seems unlikely since it is mounted Im looking into the possibility of cloning the Sabnzbd's flatpak repo and building myself. The problem mentioned above is that the unrar
If I built this myself, I wouldn't have a problem and would have to package into the flatpak. However, I would only be solving the problem for myself. If possible, it would probably be better to patch that makefile before building with |
That worked for my setup (very old x86): |
|
@sanderjo I must have missed this. Are you saying that you patched the flatpak yaml with a download unrar binary and then rebuilt it? Or is there a bind mount option into the /app/bin directory that I am having trouble finding? From reading flatpak docs I thought this app directory was locked down and not allowed to be updated after flatpak is built. |
|
No. I just installed the flatpak, found unrar in the installed flatpak directory structure, and copied the working unrar version onto it. No problems with mount nor read-only. No rebuilding. So: find hopefully it will say something like
Get the unrar from rarlab. Check is works on your old x86 by actually unrarring a rar set (just running without unrarring seems not enough) Worked for me. |
|
@sanderjo Wow! I just copied my host unrar binary over and it worked as you mentioned. Thank you! The location of those files were in Thanks everyone for their help on this. I am very happy for this workaround, but I think a more robust fix would be able to patch the unrar makefile during the time of build of the flatpak to not include Thanks again. |
|
Cool. The same seems to be the case for snap: all under /snap/, with files in plain sight. with for example
which is executable from the host (but not changeable, due to ro) |
|
For completeness from gcc man page for x86 options:
Upstream most certainly wants something other than this since they do not know what machine unrar is going to run on. An x86-64 option would be the baseline for a generic x86-64 arch and should be the target unless specific instructions are being used requiring newer cpus. Below is a patch in case SABnzbd was going to fix this or communicate with upstream to do so. I built with this on the machine I was having an issue with and placed it within the flatpak as @sanderjo mentioned above and it was successful. |
AFAIK / AFAIR the Linux unrar from rarlabs (https://www.rarlab.com/download.htm ... currently "RAR 7.01 beta 1 for Linux x64") just works on old x86 hardware. Can you try? Saves you time. |
I can confirm that this also works on my problematic machine. |
Yes. And that makes clear why the rarlab person has no real need to change his build process. |
|
@Safihre can you put "Flatpak:" in the title of this issue so it's easy to find for others? |
I agree partially with that. For now his build process works, but is machine dependent. The problem is the Edit: |
|
I'm willing to make changes to support older architects, as the package needs to be bumped for the newest SAB version anyway. What would be a good workaround? For now I'm thinking about changing the build flags, not something I really would like to see, but if Rarlab still hasn't fixed this, it may be the only thing to do. |
You probably only need to drop the |
|
@francoism90 I agree with @jcfp's above comment. I commented up the thread to include a base target of x86-64, however that locks support into amd64 machines and not sure about the project supplying support for aarch64 in the future. I tested a build with the C flags mentioned by @jcfp and it works. My testing was:
So flatpak is in a unique position here. Linux distros build without Thanks for everyone's help on this. |
at one point lsio was replacing they do static builds, which perhaps that might be something to do with the flatpak build. |
and others
SABnzbd version
4.2.3 [e7e06de]
Operating system
Debian (SABnzbd installed via Flatpak)
Using Docker image
None
Description
After upgrading to version
4.2.3via flatpak distributed via Flathub remote, a new error is showing in the UI:Your UNRAR version is 0.00, we recommend version 5.50 or higher.After downloading binary news, the files are not unrar'ed.
No changes have been made to the host environment, and this issue is verified not present in
4.2.2. The unrar version on the host is the nonfree version with version number6.2.6.I am not sure if this is impacting non-flatpak installs, or if flatpak installs are supported, but I wanted to file to bring attention to this issue.
The text was updated successfully, but these errors were encountered: