Release on public stores about paperless-mobile HOT 36 OPEN

Good news @IzzySoft, finally got reproducible builds working :) will probably be merged into the official repository in the next days.

from paperless-mobile.

Hey, I just started a pull request on the F-Droid repository. Progress can be tracked here: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12573

Does anyone know if I have to open an RFP Request?

from paperless-mobile.

Yes, I will also publish this app on FDroid. I cannot say when, but it seems I just need to add some metadata to the project, so at least in theory it should be easy.

from paperless-mobile.

That one looks perfectly clean from what my scanner reports, thanks a lot! So if you wish just go ahead make it e.g. 2.1.1+1028 (btw small typo in the release notes: 2.0.1 = 2.1.0) and have a 2.1.1 release. My updater would fetch it within 24h then.

Ah, scrap that: it's just a single commit ahead. I simply replaced the APK in staging and removed the anti-features. Effective (live) with the next sync then 😃

So next station: F-Droid.org? From what I see it looks like it's ready to apply. Ah, you did already – great! And I don't even have to tell you about reproducible builds anymore 🤩 I see fastlane was reported missing (you have it in the wrong place: can you move it one level up so it's found? fastlane must be in the repo root to be detected by F-Droid. And the build failed, hm (checks logs) ah, didn't build reproducible – because of some SVGs? Strange. Maybe this can give some guidance: HOWTO: diff & fix APKs for Reproducible Builds?

Also strange: the size of the F-Droid built APK (36 MB) is much larger than yours (26 MB) – or rather smaller, as it goes for the "fat lady" (> 130 MB; what is missing here?). Maybe you should go with per-ABI builds at F-Droid as well? I see no hint of that in the metadata there.

from paperless-mobile.

That's some awesome news! Been following the issue on fdroid gitlab all along because I can't wait to install your app with f-droid!
Looks like it has been quite a pain to arrange for reproducible builds. Thank you for making it happen and not giving up!

from paperless-mobile.

I've now submitted the app to the Google Play Store. I'll update this thread once it has been released.

from paperless-mobile.

I'd also love to see the app on f-droid. If that helps, I found the quick start guide for publishing an app to f-droid.

from paperless-mobile.

Thanks a lot for your efforts! I'll take a look at reproducible builds as soon as I find the time.

Regarding the fastlane directory, I will add a symbolic link to the android/fastlane folder, since I want to use fastlane to push to google play aswell. That should work right (I think I've seen it a couple of times in other flutter projects in the F-Droid repository).

from paperless-mobile.

Yes, for F-Droid that should work. And for my repo, as I now know you will keep the location, I've simply set that. Btw, if you wouldn't mind replacing those check-marks by bullet points (simple asterisks, like * item), your full_description.txt would render as proper Markdown so I could enable pulling that (after you made the footnote e.g. a ¹ Not fully translated yet or that would become a bullet-point list as well 🙈).

Oh, and btw, the latest changelogs seem to be missing in both locales 😉

from paperless-mobile.

Sure, I'll take care of that.

from paperless-mobile.

Thanks, very cool!
I think the video.txt was generated by fastlane, I'll remove it.

from paperless-mobile.

Thanks for the swift reply! Yes, whenever it's ready. We'll wait for your ping (or ping you when getting "impatient" 🙈).

from paperless-mobile.

Sorry, this was automatically marked as stale by the bot, I've removed the label and disabled the bot.

Hm, bots acting on their own – is that AL then already? 🙈 💨 Eh, happens 😉

which embeds opencv *.so files.

I rather meant the other way around (just follow the link). Flutter does embed the full path of the source files into the *.so files it generates. As you most likely have a different directory structure (e.g. based on your user's home dir), that makes the files different than from those built by F-Droid.

I think it won't be before mid/end of july unfortunately,

You didn't put in a year – but if you meant 2023, that's perfectly acceptable! 😄

Sorry for the confusion.

No prob, guessed as much. Wish you the best progress then!

from paperless-mobile.

Wonderful news, @astubenbord – congrats! And I second what @amo13 wrote 😃

from paperless-mobile.

Hi, yes, this is on the roadmap and I will have a look in the next couple of days. I wanted to have a relatively stabile version with all features and translation ready first before I publish to any store.

I also plan on releasing in the Google Play Store, but I have never done that before.

from paperless-mobile.

What's the name of the app? Trying to find it.

from paperless-mobile.

There was an issue with app access so the Review Team could not test the actual app, so I set up a Demo instance and it was accepted just now, here's the link: https://play.google.com/store/apps/details?id=de.astubenbord.paperless_mobile

It may be that the app cannot be found in search yet because it was just published, but it should show up in search tomorrow.

from paperless-mobile.

Is a FDroid release planned as well?

from paperless-mobile.

I filed a request for IzzyOnDroid: https://gitlab.com/IzzyOnDroid/repo/-/issues/357

from paperless-mobile.

And Izzy is just investigating. My scanner complains about 2 show-stoppers would it be for F-Droid.org:

Offending libs:
---------------
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Google Play Core (/com/google/android/play/core): NonFreeNet,NonFreeDep

2 offenders.

What are those needed for (if you didn't add them explicitly and wonder the same I do, flutter pub deps might help to figure)? Could there possibly be a "foss flavor" coming without them? In the hope for that, I've just added the app (to be precise: the armeabi variant, as that leaves us a little more head-room unto reaching the per-app limit of 30 MB in my repo and also supports more devices) to my repo now, with the 2 anti-features outlined, so it will become available here with the next sync around 7 pm UTC. I happily provide you the metadata set up here via PR in Fastlane format if you wish: F-Droid.org will ask for that when you apply there with the new "foss flavor". To build on it, be welcome to my Fastlane Cheat Sheet then 😃 And also to pick a badge if you want link to the new presence, e.g. from your Readme.

from paperless-mobile.

Hi, thanks for investigating this! I just added an (unused) dependency to in_app_review to test some stuff and forgot to remove it, I guess this is what is causing the dependencies on some google services. I'll remove it tomorrow and let you know!

from paperless-mobile.

Yes, in-app-review sounds like it could perfectly explain the two! If you want me to test before you tag a new release, just let me know where to find the APK. Alternatively, create a new release and attach the APKs as you've done with the current one – within 24h my updater should fetch them and yell at me to remove the NonFreeDep, at which point I'd automatically cross-check for NonFreeNet as well (which is not yelled for as it is not clearly bound to some lib only – just think of any YT or GH client which also depends on non-free networks).

from paperless-mobile.

I added a pre release without the dependency, forgot to post the comment here.

from paperless-mobile.

Great! Please let me know when full_description.txt is adjusted so I enable it on my end to be pulled from your fastlane. Thanks!

from paperless-mobile.

Updated it on development and added latest changelogs!

from paperless-mobile.

Thanks! Enabled it in my repo then. Btw, any reason you keep an empty video.txt? If there is no video to link to, you can simply remove that file 😉

from paperless-mobile.

Ah, that could explain. Does no harm, though – I was just wondering. Not the first time I encounter that.

from paperless-mobile.

Looks like a git rebase is needed to unblock the merge request over at f-droid gitlab.

from paperless-mobile.

How should a rebase "unblock" the MR? It wouldn't change the content of the YAML file, and thus not fix the build. Looking at the failed build rather suggests some files are either different per se, or using different line endings (e.g. because of being produced on a Windows machine and thus coming with CRLF, while the F-Droid build process is using Debian Linux). Updating the YAML to the latest release however might help – especially when those issues were solved meanwhile.

from paperless-mobile.

I have to admit that I didn't get to fixing this yet. I will try to have another look after the next release which has taken quite some time now, but I'm also relatively busy apart from that. So unfortunately this will have to wait for now until I have more free time again :/

from paperless-mobile.

This issue is stale because it has been open for 30 days with no activity.

from paperless-mobile.

🤔 Last comment before that: "We'll wait for your ping". So it became stale because you didn't ping? 🤔 But then I see some "moved to done" label, and now I'm confused: did we miss some ping? Didn't see one in the merge request.

But then, I saw the log of the failed build. Maybe I can give a hint on that: it's the RB-test that fails. As reason it lists some *.so, and this is Flutter – so the most likely reason are Embedded build paths.

from paperless-mobile.

Sorry, this was automatically marked as stale by the bot, I've removed the label and disabled the bot.

But thanks for the hint, maybe the document_scanner package is included in the app, which embeds opencv *.so files. I'll get back to you as soon as I have more time, but I think it won't be before mid/end of july unfortunately, I'm just really busy at the moment and due to updates to paperless, some core features of the app are broken which has higher priority (and I can't even afford to work on these at the moment) 😢

Sorry for the confusion.

from paperless-mobile.

I rather meant the other way around (just follow the link). Flutter does embed the full path of the source files into the *.so files it generates. As you most likely have a different directory structure (e.g. based on your user's home dir), that makes the files different than from those built by F-Droid.

Ah I see, so I just have to make sure that the working directories in both the F-Droid and GitHub build scripts are equal? Okay, I'll give it a try.

from paperless-mobile.

Yes, that. There are a few examples for that, and the docs give some hints, too. Thanks!

from paperless-mobile.

FYI, app is available now on TestFlight and validated by Apple, will work with @astubenbord to update associated docs with links.

from paperless-mobile.