hardcode-fixer
hardcode-fixer copied to clipboard
Offline CSV Fallback Option
I installed Manjaro 20.0.2 with KDE two hours ago. When I use sudo pacman -S vim
to install vim, near the end of the installation, the bash shows
:: Running post-transaction hooks...
(1/4) Arming ConditionNeedsUpdate...
(2/4) Updating icon theme caches...
(3/4) Fixing hardcoded icons...
/usr/bin/hardcode-fixer: line 140: [: : integer expression expected
sed: can't read /tmp/tofix.csv: No such file or directory
chown: cannot access '/tmp/tofix.csv': No such file or directory
/usr/bin/hardcode-fixer: line 297: /tmp/tofix.csv: No such file or directory
error: command failed to execute correctly
(4/4) Updating the desktop file MIME type cache...
Then I tried to install other software, same error messages has been echoed too. But those software seems to work fine for now.
So how to fix it? Any other information should I submit?
I also encountered this problem
I'm confused, how was hardcode-fixer running as part of Pacman installs? Is that something you've set up or has is always done that for you on Arch? It might or might not be related to this issue, but will be useful to know for debugging since that's not a feature of the vanilla script.
I didn't do any setup, just simply installed the OS and used pacman to install softwares. But even though I reinstalled the Manjaro 20.0.2, the same problem still happened.
Same here, Manjaro kde. I did a upgrade(using pacman -Syyu
) just an hour ago. Now whatever I'm trying to install on my laptop, this "line:140" always shows up. However, the installation process went quite smoothly, which means the installation is finished without any troubles, and I can run them perfectly well. Weird thing.
Huh that's really weird, the Majaro team must have integrated hardcode-fixer into their install and upgrade command. That's actually quite cool though I'm very surprised to be hearing about it first through a bug request caused by the integration rather than an email or message from their team.
I'll get a Manjaro KDE box setup so that I can try debug this but it's possible that the bug is caused by the way they've integrated it rather than the app. Will update here with what I find though!
Using latest Manjaro KDE here, experiencing the same issue and found a workaround.
The script will automatically fetch the latest version of hardcode script & list of icons to fix from raw.githubusercontent.com
. This address is blocked in mainland China(by dns poisoning).
So I assume those who are experiencing this issue are mainly from mainland China. To check whether you have this issue or not, try to use curl
to fetch a file from raw.githubusercontent.com
.
The workaround is to attach pacman to a proxy server or update your /etc/hosts
file. After the fix the installation process runs smoothly.
Thanks for the heads up @eyeKill, I had no idea that was the case! I'll pass that onto the Manjaro devs too since it's probably good for them to know of that restriction.
@Core00077 @zZer0o Are you both located in mainland China?
Yes, we all located in mainland China. (Core00077's github profile was written in Chinese. )
And thanks for the etc/hosts
solution, the problem was solved indeed.
Yes, and I tried edit my hosts file to fix. Worked here. @eyeKill was right. But I don't think there will be a proper solution to solve this, unless a mirror of github appears, which I don't think could be possible. But that is the case.
This should have been an issue more about the user than the repo itself. What made this issue a pain in the ass is that the script is called by pacman
automatically and current methods aren't elegant enough to resolve it under pacman
's context.
I think a proper workaround might be to add an explicit command line parameter for the script to disable checking for the latest version. Since the manjaro team packge their own version of this repo I'm sure that they can repack & update this package(with the lastest list & script) along with other new packages each cycle.
@eyeKill Agreed. I've just emailed the Manjaro developers about this and will start thinking myself about implementing a fallback option to use a locally stored version of the CSV file if GitHub isn't accessible for whatever reason.
This issue has also highlighted that this particular check should be for raw.githubusercontent.com
rather than github.com
- I naively assumed that those two would be largely equivalent.
Maybe we can bypass the block of raw.githubusercontent.com
by jsdelivr. Just edit git_locate
in https://github.com/Foggalong/hardcode-fixer/blob/master/fix.sh#L17 :
git_locate="https://cdn.jsdelivr.net/gh/Foggalong/hardcode-fixer"
And it works fine for me.
@tongyifan That one oddly doesn't actually work for me! I get a 404 error when I make that substitution. If that works for people as a temporary fix for them though until I can get the offline fallback sorted then that's great :+1:
@tongyifan @Foggalong Maybe it should be "https://cdn.jsdelivr.net/gh/Foggalong/hardcode-fixer@master"
? But I agree with @Foggalong here that we still need a fallback option.
I am from Iran (not China, which means that maybe that address is blocked here too). I recently reinstalled my Manjaro KDE, and the problem`s still appearing after every installation at the end. the annoying thing about this bug, is that it takes about 15mins to finish any installation process!
@eeffathi There's nothing I can do about that on my end unfortunately; I know Manjaro have temporarily disabled the hook upstream but I don't know when that will trickle down to users. If it's causing issues you can go into wherever Manjaro installs the script and either change git_locate
to one which isn't blocked in your country or add a terminate command up top to effectively skip the hook for now.
Using latest Manjaro KDE here, experiencing the same issue and found a workaround.
The script will automatically fetch the latest version of hardcode script & list of icons to fix from
raw.githubusercontent.com
. This address is blocked in mainland China(by dns poisoning).So I assume those who are experiencing this issue are mainly from mainland China. To check whether you have this issue or not, try to use
curl
to fetch a file fromraw.githubusercontent.com
.The workaround is to attach pacman to a proxy server or update your
/etc/hosts
file. After the fix the installation process runs smoothly.
excuse me, bro. How should I just change or add sth in the etc/hosts file exactly.(I'm sorry that i'm really fresh on linux-usage)
Using latest Manjaro KDE here, experiencing the same issue and found a workaround. The script will automatically fetch the latest version of hardcode script & list of icons to fix from
raw.githubusercontent.com
. This address is blocked in mainland China(by dns poisoning). So I assume those who are experiencing this issue are mainly from mainland China. To check whether you have this issue or not, try to usecurl
to fetch a file fromraw.githubusercontent.com
. The workaround is to attach pacman to a proxy server or update your/etc/hosts
file. After the fix the installation process runs smoothly.excuse me, bro. How should I just change or add sth in the etc/hosts file exactly.(I'm sorry that i'm really fresh on linux-usage)
@jacklanda you can modify hosts file by
sudo nano /etc/hosts
For the content to add into hosts file you can refer to: https://zhuanlan.zhihu.com/p/107334179
@eyeKill @jacklanda @eeffathi @tongyifan @Core00077 @zZer0o @yanqi-huang Update for y'all!
The script now has fallback options for gitee and jsDelivr built in, which means it should now be accessible in China and Iran! Not gonna close this issue yet because I'd like to get the offline fallback in there as a more robust solution, but would be much appreciated if you can let me know if the script works for yous now with these alternative URLs in place :slightly_smiling_face: