-
-
Notifications
You must be signed in to change notification settings - Fork 99
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
Trackers added in the last release! #102
Comments
Does DataBackup-1.0.0-alpha05-arm64-v8a-foss-release.zip pass the test? |
to 100% – not a single offender detected, wonderful!
Certainly! My updater understands regular expressions for which APKs to ignore and which APKs to focus on (here: Thanks a lot!!! |
Noiice! Just follow ur suggestion, let's pick |
* #102 Change-Id: I673226291a70c20ab41639f54be46b027b3dda73
Ugh, missed it's up already 🙈 Just fetched 1.0.0rc1, re-enabled auto-updates and will now keep 3 versions. Thanks a lot! Issue solved 🥳 |
Thx:) |
Sir I changed the package name for the next build, can you have a check for it? |
That means everyone using it needs to re-install. Are you sure this is intended? If so, is it possible to export/import settings (and whatever else is needed)? PS: Apologies for the delay, I was on vacation. |
PPS: Whoever has the app installed with the original package name won't receive any update notifications to tell them they'd have to switch. So if you're sure you want to change the package name, how to inform existing users? Not even the release notes mention the renaming. Further, changing the package name also means the link to my repo will change. So if you really want to change the package name, a suggested path would be:
|
Thanks for these great suggestions, I mean to develop the latst version for the old package indeed and, it may take some time, will let you know when it's ready:) |
That sounds good! How long do you estimate will it take – round-about? Just asking as I get the alert every day, so if it's more than a week or two I'd like to tune down updates from (currently) once-per-day to once-per-month to avoid the annoyance 😉 |
It may not be soon, once-per-month is fine |
Thanks! Done that then. Gives us time until the end of the month, then pulls the most recent version again complaining to me once more, which can serve as reminder to check with you how far you've got 😆 |
Looking forward to the next release then, thanks! Btw, checking my notes and your releases: for IzzyOnDroid (which your Readme still links to), the updater was pinned to only fetch APKs matching |
I'm so sorry sir, I almost forgot it :( I'd follow your great suggestion, will build the last Btw, now foss version is build from f-droid server, can we use the same apk in IzzyOnDroid? |
Cool! And yes, the IoD updater just takes the APKs you provide at releases. If you upload the F-Droid built APK there, that would be fetched. But that way you'd loose the advantage of faster updates, as you had to wait for F-Droid's build (which usually takes 3..5 days), then needed to fetch that manually and add it to releases (at least several more hours lost), and then wait for the IoD updater to fetch it (less than 24h). Which means a delay of a week instead of a delay of a few hours from the time of your new version being ready. You're sure you want it that way? |
It seems that there's no better workaround for it, if I build foss version with my own signature, there'll be two different signatures for foss build, it may be confusing. |
You should have established reproducible builds. You still can switch to those at F-Droid – though that would mean for everyone having installed the app from there to uninstall and reinstall to move to the changed signature then. And F-Droid has no RB specialists anymore (the one they had left F-Droid, and those who left are now working together at IzzyOnDroid). As long as there'd be two different signatures, that would mean people are stuck with the place they originally installed from. They wouldn't see the other one in their clients (unless they enabled the related expert setting). So you could e.g. look at it for a while and then decide whether you want to go RB (for easy switching), recommend one place over the other, or just point out the differences together with their pros and cons to let folks decide for themselves. Of course, if you think that's too much, and your app available at F-Droid.org suffices, we can also remove it from IoD. Just sticking with a rather outdated version here would not be good. |
It would be really a pity if we stop updating on loD :(
How about this? I can move builds manually after froid builds are complete, it seems to be the only way to handle this. |
That would still mean having to wait for the F-Droid build cycle to succeed with a build. Might shave off 1..2 days from the above. Thus the only advantage you'd have were the additional checks done here at IzzyOnDroid, while losing the advantage of your releases becoming available faster. And those having installed your app from IzzyOnDroid would need to uninstall and reinstall one time as well, as the packageName changed. Wouldn't it be preferable to achieve reproducible builds at F-Droid.org then? Yes, those having installed your app from there would then need to uninstall/re-install once (it cannot be avoided that one party has to). But then you'd have both advantages. If you can run that F-Droid build and provide me the APK(s), I could check how close you are to RB already. Remember, the RB specialist now is with the IzzyOnDroid team 😜 |
Well, I'll have a try, thanks! |
Hi sir, I'm trying on RB, I wonder can |
I've worked on reproducible builds for 2days, there're still two builds not reproducible: coreutils and gnu tar, there're both using autoconf build system, and extremely depend on the build environment. It seems I have run out all my way... |
Afraid I cannot help with that, I'm no RB expert (I cannot even manage to build this app at all). And F-Droid no longer has any RB expert, so you're most likely out of luck there, too. |
My updater just pulled today's release and screamed an alarm:
That's an absolute no-go for an app that should take care for personal data, so I had to remove Alpha-5 from my repo again and disabled auto-updates for now. I very much welcome your switching to per-ABI builds so I can keep multiple versions, which I'll certainly do once those trackers have been removed again. Can you please do that?
The text was updated successfully, but these errors were encountered: