• ShapeShifter499 joined the channel
      • _hc
      • no builds published
      • NicoAlt joined the channel
      • Tovok7 joined the channel
      • hey Tovok7 uniq[m] pserwylo CiaranG cdesai NicoAlt thezero and anyone else who is listening: meeting time!
      • thezero
        hey _hc!
      • _hc
      • thezero: exams over for you?
      • thezero
        no, sadly :(
      • _hc
        well, glad you could join anyway
      • Tovok7
        hi all
      • uniq[m]
        hi everyone
      • _hc
        unless someone else wants to start, I'm ready
      • The big news is CiaranG fixed the last issue that is preventing the index-v1.jar from being published admin#36
      • NOTICE: [admin] #36: Add signed new index to F-Droid.org - https://gitlab.com/fdroid/admin/issues/36
      • That should be hitting f-droid.org today or tomorrow
      • that means that anyone with client v0.103 installed will start getting localized texts and graphics
      • and repomaker can then use f-droid.org as a source, since it only uses the new index format.
      • I also tagged v0.103.2 of client
      • it includes a big stability fix related to updates and their notifications
      • there are more localization updates there too
      • like 100% complete Chinese for China
      • I've also been working on the final issues to support APKs signed by different signing keys
      • like #740
      • and s#153
      • NOTICE: [client] #740: handle multiple APKs per repo differing only by s… - https://gitlab.com/fdroid/fdroidclient/issues/740
      • NOTICE: [server] #153: optionally support multiple signing keys per APKs - https://gitlab.com/fdroid/fdroidserver/issues/153
      • one piece of bad news is that fdroidclient has some hardcoded issues when the index contains more than one APK with the same packageName/versionCode
      • so my plan is to keep preventing duplicate packageName/versionCode APKs from going into index.xml
      • and only allow them in index-v1.json
      • but unfortunately, this will be incompatible with all 0.103 versions until that's fixed in fdroidclient
      • basically, the database layer in client enforces only one entry per packageName/versionCode
      • since 0.103 is basically an extended ebta
      • beta
      • it seems OK to me to not handle backwards compatibilitiy for 0.103
      • I have a merge request for the server side almost done, it includes
      • the new `fdroid update --rename-apks` for people dealing with large APK collections from the wild
      • it renames them following the standard, and moves duplicates out of the repo
      • in this case duplicate is based on packageName/versionCode/signer
      • I couldn't think of a use case for having multiple APKs with the same packageName/versionCode/signer
      • Tovok7: that should be useful for your Cuba trip
      • in other news, I ran a test build in fdroiddata that uses `sudo apt install` to install the required packages.
      • This was the last confirmation needed to prove that we can add a new Build metadata field to allow arbitrary build setups for apps
      • the preferred way for apps is still to use the standard Debian setup as much as possible
      • adding custom package installs lets us handle potentially conflicting build setups, like conflicting version of Rust, Go, etc.
      • at this point, I'm thinking the Build field should be called "sudo=..."
      • it would only run on the buildserver VM, so people could run `fdroid build` on their machien without it running the sudo= stuff each time
      • Tovok7
        why not something like requires-debian: where you just list the packages you need?
      • this would prevent the build scripts from calling arbitrary commands with sudo
      • _hc
        krt[m] and mvdan and I had discussed making it something like "packages=...", but there are many other things that apps need, like `npm install`, or things like downloading the Qt or Kivy SDK
      • we don't need to prevent builds from running sudo on the buildserver, its a VM that is reset after each build
      • Tovok7
        then I'd say we should check _if_ we are running in a VM and if not, stop and warn about a recipe calling sudo
      • _hc
        if we ever support Docker, then security concerns might warrant limiting access to sudo
      • Tovok7
        because many people, me included, build apps on their local machine for development
      • _hc
        Tovok7: yeah, that's the idea of the sudo= build flag
      • Build:0.103.2,103250
      • commit=v0.103.2
      • subdir=app
      • gradle=yes
      • sudo=npm install foo
      • then `fdroid build` would ignore sudo= entirely, unless it was running on the buildserver
      • Tovok7
        that's cool
      • _hc
        then we could also add lint checks or other enforcement to disallow sudo calls in prebuild= build= etc
      • Tovok7
        maybe printing a warning or info about that sudo being ignored
      • _hc
        passwordless sudo has always been setup in the buildserver
      • mvdan
        if you really want to go this route, you'll need a more foolproof method - what if a script/makefile/etc calls sudo?
      • _hc
        there is no way to stop it without putting a password on sudo
      • which users should already have
      • and it doesn't matter on the buildserver
      • mvdan
        then sudo= isn't enforced at all
      • _hc
        that's not new
      • mvdan
        and it's pretty useless if you ask me
      • _hc
        there is currently nothing preventing apps from putting sudo calls in their builds
      • this would be an improvement over that
      • the point of the sudo= build field is to make it easy to call things that need sudo on the buildserver
      • mvdan
        I don't see any advantage other than it erroring if fdroid isn't running in a VM
      • which you could do just as well by searching for "sudo" in any of the script flags
      • that's what your lint suggestion is, after all
      • also, I assume this is still a limited experiment
      • _hc
        like Tovok7 said, sudo= wouldn't error on a user call of `fdroid build`
      • it wuld print a warning
      • mvdan
        well, whatever action, it doesn't matter
      • just think twice before adding yet another build flag
      • _hc
        at this point, we're up to thinking about this for the 5th or 6th time ;-)
      • mvdan
        and I'm glad, because if not fdroiddata would have a dozen sudo calls already
      • _hc
        as for a different issue: anyone have any issues with not doing backwards compatible duplicate APK handling for 0.103?
      • It seems like it would be a lot of work, and not really worth it since this is really still a beta
      • Tovok7
        I think it is fine looking forward with this one and don't bother with supporting older versions
      • _hc
        well, just 0.103, everything before that will work fine because the duplicates APKs will not be included in index.xml
      • Tovok7
        so they shouldn't notice any difference, right?
      • it is just that you need a newer client if you want that feature
      • _hc
        as far as I can tell, yes
      • once f-droid.org has a lot of duplicate APKs (i.e.. different only by signer), older clients might get some wierd results in terms of which APKs get shown
      • we can always improve the logic for choosing the one that goes into index.xml as needed
      • to support old vetsions
      • ok, that's it from me, whoever is ready, go next!
      • uniq[m]
        I'm currently working on getting `fdroid publish` to create a second signed apk with the developers signature, based on our metadata and our self-built apk.
      • that's all for me this week
      • _hc
        can you expand on that a bit? like when it'll be used?
      • Tovok7
        uniq[m]: ^
      • _hc
        uniq[m]: did we lose you?
      • I guess someone else should go ahead
      • Tovok7
        I can go
      • Nothing much to report, because NicoAlt and me were implementing the UI design for repomaker
      • So there's nothing really new, except making it look nicer and more intuitive
      • We are using more JavaScript now to implement certain features
      • but so far always manage to provide fallbacks
      • for when it is disabled
      • Tomorrow, we have a user testing. I helped to recruit testers and we booked all 12 slots.
      • The testing will be remote with video call, so that's intersting.
      • We have people from Sri Lanka, Pakistan, etc.
      • EOF
      • _hc
        that's good news
      • nice range :)
      • of places
      • should be some nice int'l promotion as well
      • that reminds me, once we get the Tibetan translation done, then F-Droid will probably be the first app store in Tibetan :)
      • Tovok7: will you have time to test the index-v1.jar before the user test?
      • Tovok7
        the f-droid.org one? depends on when it comes out
      • I added pagination yesterday (forgot that one), so we are ready to handle 1000s of apps
      • _hc
        ah, good !
      • Tovok7
        if it comes out too late (or there are too many issues with it), we can always use guardian and testy repo
      • _hc
      • I'll leave testy alone for now then
      • let me know if you need updates there
      • its easy to do
      • Tovok7
        thanks, I think not touching it is the best you can do until the weekend ;)
      • _hc
        ok, who's next?
      • Tovok7
        maybe while we wait, here's repomaker's current milestone: https://gitlab.com/fdroid/repomaker/milestones/1
      • It shows the details of what we have been up to and how we are very short of meeting tomorrows deadline :)
      • _hc
        the burndown chart's on fire! ;-)
      • Tovok7
        especially in the last days :)
      • I can also spot the weekends in the plateaus
      • _hc
      • good! weekends are important
      • this man needs to discover weekends away from the computer: https://github.com/JakeWharton
      • his activity chart is a bit scary
      • Tovok7
        at least it has *some* white dots ;)
      • who's missing? just cdesai and pserwylo?
      • _hc
        thezero: cdesai pserwylo anything to report?
      • thezero
        me not much
      • just a question, can we include openssh-client and git in the fdroidclient-ci-image?
      • _hc
      • Tovok7
      • _hc
        for publishing to github?
      • gitlab?
      • thezero
        otherwise I need to install them every time there is a commit for publishing to gitlab
      • exactly