I have this issue with f-droid. What should I do? Is there any fixes available? And all my apps from F-Droid are currenly seen in Archive repository but not in main one.
Do you have the latest version yet? Update and retry: https://f-droid.org/repo/org.fdroid.fdroid_1016052.apk
Do you use any VPN or Tor or Proxy?
It wasn’t the latest - 1.16.1, but .2 shows the same error. No VPN, no proxy.
Can you clean app data? Android Settings → Apps → F-Droid → Storage → delete app data
It’s ok now, thanks!
You had extra repos, right? Which ones? Maybe we need to reach to them and have them fix something.
When my F-droid instance was in faulty state my apps were visible only in F-Droid archive repository, now everything is visible in the default one.
Clearing data fixed the data, but destroyed all the settingsx including the list of repositories. Frankly, using such a nuclear option should had ben the last response, not the first one! I downloaded the last client from your side hoping it would do something to address the problem - it did not…
The error message was outright trolling: it said “all other repositories are fine”, but it did not say WHICH one was broken.
I believe you could make F-Droid somewhat helpful to user here, and probably more users would come with this problem. So pro-actively making F-Droid helpful would perhaps save everyone time and nerves.
The error message should say WHICH repository is broken.
1.1. It would be nice, if the repositories list window had the problematic repositories marke and the last error stored and shown in the specific repositroy’s details window .
1.2. It would be nice if specific repository’s details windows had a command to flush the local data for only this one repo and download it afresh. Together with a menaniful error message it would’ve make the nuclear option not the only solution.
The F-Droid could also provide for exporting and importing settings data to/from a file, to facilitate recovery after the nuclear option was used.
2.1. At least the list of repositories, with all the required settigns to automatically add them back, if not other settings.
2.2. At least one single repository, so user coluld at least iterate through their repositories open every repo’s details window and exporting one after another
So i was basically left with only a screenshot of the repos i had. I think it was a single screen with 10 repo’s but not 100% sure.
I had to google them one by one by their names read from a bitmap (screenshot) and re-add them, which is not the most easy thing to do on the phone. I could not even “SHARE” a link to a repo from Firefox into F-Droid app - F-Droid does not accept links, only copy-switch-paste time and again.
Ironic thing here is, you went at lengths to design repository hash signatures (xkcd picture about a cryptonerd and a wrench goes here). But now your users have to drop all those crypto-hardened links and re-add from scratch whatever the Google Search would give them, only having the mega-corp for authencity. That was really ironic…
Since it was a “repo” issue it would have helped to “list repos” first so we can track down the offending one. Now we are still not aware of which repo had this issue.
They are not here? Known Repositories
Who forces you to use that exactly?
Who forces you to use that exactly?
Because that is what people are supposed to use when they left in alien land with zero clue.
Does the application suggest them this URL after being reinstalled? No. Then users won’t know such a thing exist. They are left with tabula rasa F-Droid Client and Google.
would have helped to “list repos” first so we can track down
I restored them, loaded afresh - and the error is not repeated. So i did not bothered to transfer the screenshot from a phone to the desktop.
Then again, would there be “export options” or at lease “export repo-list” command in the program - you clould just ask for thie config file from the first reporter…
So, it was some temporary deviation (maybe as little as format versions mismatch between server and client), mayber even in your main repo, that was gone, but in the way it poisoned the clients who update in unlucky time into unusable state.
BTW, it is another problem with nuclear options, they destroy the “test cases”, if some developers would want to debug it, rather than wipe clean a specific instance and move on. Actually, taking such a route looks like a hint “we chose to move over not dig into” from user’s PoV. You did not ask user to save any data for debugging, you explicitly asked him to delete any data, related to the error, so the user did as suggested.
I agree, my next question would have been, “can you submit a logcat from ADB when you try to update?”
Which option you think most people would like, clean app data or adb logcat?
The option like “open the properties of the repository named in the error message and tap [hard reset] button”.
The famous “90% of software program error can be temporary fixed by closing and re-starting program a bit later” just here the conceptual restart would’ve been from “initial repo download” execution point.
ref: Fix critical bug that prevents repo updates after Android updates (!1210) · Merge requests · F-Droid / Client · GitLab
We reset the DB when the user updates their Android major version
Wah! Definitely, this had happenned to me recently… Sounds like THE trigger.