-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flexo panics with custom repo #79
Comments
Update: I forgot to mention that I'm using version 1.6.2. After launching flexo with
and as the last line before crashing:
Launching with the
|
Thank you for your bug report. I was able to reproduce the issue on x86, so the issue is not related to ARM. But describing your ARM setup was helpful, I wasn't aware that such changes are required to build Flexo using cross. The issue seems to be related to redirects. The url https://download.opensuse.org/repositories/home:/ungoogled_chromium/Arch/x86_64/ungoogled-chromium-95.0.4638.69-1-x86_64.pkg.tar.zst redirects me to this url, which, in turn, redirects me to another url, which, finally, redirects me to this url. If I use the final destination in my [[custom_repo]]
name = "home_ungoogled_chromium_Arch"
url = "https://widehat.opensuse.org/repositories/home:/ungoogled_chromium/Arch" and then I can successfully download the file via Flexo: curl -vv http://127.0.0.1:7878/custom_repo/home_ungoogled_chromium_Arch/x86_64/ungoogled-chromium-95.0.4638.69-1-x86_64.pkg.tar.zst > /dev/null You may try this as a workaround, but I wouldn't just copy-paste the url from my config, but instead see where you're redirected to (perhaps the mirror is using geolocation-based redirects or something fancy). You can use curl to determine the final location: curl -Ls -o /dev/null -w %{url_effective} https://download.opensuse.org/repositories/home:/ungoogled_chromium/Arch/x86_64/ungoogled-chromium-95.0.4638.69-1-x86_64.pkg.tar.zst But that's obviously just a workaround until Flexo can handle redirects properly. |
Glad to be helpful about the ARM build. Anyway, that did the trick, thanks. The final URL was the same for me. |
I'm planning to look into it this weekend, I can't say how long it's going to take. |
Before I start telling you about the issue I have to say that my setup is probably quite uncommon:
I want to run flexo on a raspberry pi 2 (at the moment it runs raspbian buster, eventually I want to install Arch ARM).
For some reason, the pi could not compile flexo: cargo seg faults without other message. So I decided to cross compile it for armv7 from my main PC (running standard arch linux) using cross.
cross build --release --target armv7-unknown-linux-gnueabihf
Building is fine (but at first it exit with an error because of some
openssl
header missing so as suggested here I added the following toCargo.toml
openssl = { version = "0.10", features = ["vendored"] }
and everything went fine. I then moved the built binary to my Pi, created the configuration file at
/etc/flexo/flexo.toml
using this. And finally on my Arch PC I addedServer = http://192.168.1.30:7878/$repo/os/$arch
to my/etc/pacman.d/mirrorlist
file.Everything works fine, until I decide to add a custom repo.
Without flexo
/etc/pacman.conf
has this custom repo, and works just fine:after flexo, that repo becomes:
and I appended this to the flexo configuration file:
Then when I try to install ungoogle-chromium via
pacman -S ungoogled-chromium
pacman exit because it cannot find the file (err 404) and flexo crashes with this stack trace:Installing other packages from
core
extra
orcommunity
works fine even after adding the custom repo.The strange thing is that if I try to manually download other files from the custom_repo through the proxy, it works:
wget http://192.168.1.30:7878/custom_repo/home_ungoogled_chromium_Arch/x86_64/ungoogled-chromium-95.0.4638.69-1-x86_64.pkg.tar.zst.sig
But trying to download the package archive with
wget http://192.168.1.30:7878/custom_repo/home_ungoogled_chromium_Arch/x86_64/ungoogled-chromium-95.0.4638.69-1-x86_64.pkg.tar.zst
causes flexo to crash with the same stack trace.
Clearly the file exists in the repo
Do you know what's the deal? Some shenanigans with the binary built that way? Or maybe because of the OS? or the architecture?
Thanks in advance for taking your time to give a look to this issue and for developing such an amazing piece of software
The text was updated successfully, but these errors were encountered: