• Tovok7 has quit
      • comradekingu has left the channel
      • _hc joined the channel
      • _hc has quit
      • NicoAlt joined the channel
      • _hc_roving joined the channel
      • _hc_roving
        I might not be able to be online for the meeting
      • I'm on a mountain in the Alps :)
      • uniq[m]: pserwylo and I have been working in the new funding proposals
      • 1.0alpha0 client is out!
      • server 0.8 is almost done
      • NicoAlt joined the channel
      • NicoAlt
        I' sorry but I cannot attend to the meeting today, again. Haven't done anything beside reviewing stuff from Pete and Torsten, though.
      • uniq[m]
        _hc: great, i hope you're having a great time
      • _hc: are you working on the netidee funding proposal?
      • NicoAlt
        _hc_roving: Do you already know about this fund? I read about it yesterday: https://prototypefund.de/en/
      • _hc_roving: Have fun in the Alps!
      • cdesai
        _hc_roving: Enjoy!
      • I haven't been able to get much done this week either, busy with a college event.
      • I did get mirror supported started towards the end of last week, and have PoC working and up on my gitlab fork.
      • uniq[m]
        cdesai: I'm curious, how's the client going to get a list of available mirrors?
      • cdesai
        uniq[m]: the index already contains them
      • also, another thing, right now mirror support is only for apps, we wanted to get that working before touching the index code, since if that breaks everything stops working.
      • Tovok7 joined the channel
      • pserwylo
        cdesai: mirror support sounds great
      • Tovok7
        the prototype found requires people to work on it to live in Germany during the funding.
      • *fund
      • cdesai
        pserwylo: last item I was working on was picking the right mirror.
      • pserwylo
        what do you think when when you say "right"
      • ping time?
      • or just doesn't time out?
      • Tovok7
        cdesai: how do you distinguish apps from other things?
      • cdesai
        actually, not right, but different mirrors. right now it picks the first non onion mirror
      • Tovok7: the code is in different classes :)
      • I touched InstallManagerService and a bit of the Downloader classes, but not IndexV1Updater yet.
      • Tovok7
        ok, but the index doesn't say this is an app and this is an APK or does it look at the file name?
      • cdesai
        Tovok7: no no, what I meant is only app/media/etc downloads use the mirror
      • the index download itself right now still uses the original address
      • Tovok7
        ahhhh, ok thanks for clarifying
      • cdesai
        pserwylo: for the time out part, we eventually want it so that there's a cycle of retries, so original fails or times out, where the time is set - try a mirror, if that fails, try another, and so on.
      • _hc_roving
        nicoalt prototype fund looks like a good opportunity for you! we can help you put together a proposal
      • pserwylo
        cdesai: in a future sprint (unrelated to Bazaar2 likely) it would be great to let the user select a prefered mirror.
      • Tovok7
        hi _hc_roving! NIce they have internet even on the mountains ;)
      • pserwylo
        That would be super helpful for me here in Aus, and likely Tovok7 too
      • bonus points for showing ping times next to each available mirror!
      • Tovok7
        (or select the fastest mirror automatically)
      • pserwylo
        but obviously out of scope for now
      • cdesai
        agree, it would even help me here in India. perhaps even have a preferred list, adjustable.
      • I was also thinkiing that we might have an option to only use onion mirrors or try them first if tor is enabled
      • pserwylo
        I am going to prepare a small grant proposal (among the larger ones _hc mentioned) to fix the "add repo" stuff. When add repos is fixed, then we should throw in all these advanced mirror-related features in the "Manage repos" screen
      • Tovok7
        if we want f-droid to be a tool that also works well-for non-technical users, I would not do such things in a way users need to do them manually, but automate it for them
      • pserwylo
        Tovok7: Agreed. I suppose it is amost always going to be the fastest mirror that people desire
      • and that is quite a technicaly simple thing to achieve I guess.
      • Tovok7
        fedora does it with their package manager, so I guess yes ;)
      • anyway, looking forward to mirror support! :)
      • pserwylo
        likewise. is that you done cdesai?
      • Tovok7
        repomaker already supports it btw. If you add different remote storages for your repo, they will be added to the mirror list.
      • (but it doesn't use mirrors itself to download stuff)
      • cdesai
        yes, I'll be continuing this weekend/next week, hoping to get it done :)
      • I'm using the guardian project for testing, as it's on onion, github, gitlab and aws
      • got busier than I expected this week, my college is starting an IEEE Student Branch
      • pserwylo
        cool, hope it goes well
      • i'm going to jump in with my report
      • Been spending time fixing minor problems in the website and client.
      • I'd like if we could get a 1.0-alpha1 out soon because I stuffed up and made the "Install" button not work until you do a repo refresh (oops, sorry for that).
      • Tovok7: I completely agree with your earlier comment that we should invest in tests for really basic things (e.g. install F-droid, update repos, and download an app).
      • i might spend somie time outside of the Bazaar2 funding to get simple espresso tests up and running
      • Tovok7
        awesome! though I would test as most stuff in smaller unit tests if possible at all
      • pserwylo
        Though what you reported with the install button not working is a little tricker, would require a test which installs the previous stable version, then installs the version under tests and does key tasks to make sure it works as expected.
      • Tovok7: Yes, getting much better at writing unit tests for key things, but a few broader integrated testw would probably save a lot of trouble too
      • Tovok7
        indeed + they could throw out localized screenshots. I did this in TRansportr recently
      • pserwylo
        good point. _hc_roving is already looking into localized screenshots, so i should probably wait until that is done before touching espresso, less we both implement the same scaffolding and CI stuff
      • Tovok7
        (by throw out I mean these screenshot could be a side effect of those tests)
      • pserwylo
        Also, I started today on getting index-v1 support into jekyll-fdroid (to support screenshots/translations/whats-new/etc).
      • Should be done in a day or so hopefully, but that really means next week because I wont have a whole lot of time tomorrow.
      • In addition to the grant stuff which _hc mentioned, I'm trying to get an F-Droid talk proposal at linux.conf.au, the biggest open source conf in Australia
      • (but it is quite small by other countries standards, maybe 700 people?)
      • The thing I wanted the most feedback on is part of the Bazaar2 proposal which was gathering crash reports from F-Droid apps
      • and allowing users the option to submit them upstream if desired.
      • This is to give developers options other than just Google Play, which in addition to letting people distribute apps, also lets them collect crash reports to diagnose issues.
      • I have a proof of concept system app which, if installed to /system/priv-app (like the privilidged-extension),
      • is able to monitor logs and identify crashes.
      • Once a crash is identified, we can ask the user if they'd like to send those reports somewhere useful for developers.
      • The trick is, where is the best place to send them?
      • We toyed with the idea of GitHub/GitLab/etc (depending on where fdroiddata cloned the app from), perhaps in a "fdroid-issues" project
      • but GitHub doesn't allow confidential issues,
      • and spamming random stack traces, which may include things like SQL queries with sensitive information in them doesn't seem like a good thing to open up.
      • we also have AuthorEmail metadata, but that is perhaps even ruder, to start spamming their email account (especially if they don't know they are on F-Droid)
      • Tovok7
        To me it sounds like an entire side-project to f-droid that should not be underestimated in terms of scope and ammount of work required to do it right. Maybe it would be worth talking to the ACRA folks about it. It is certainly less useful when a system app is required. A proof-of-concept would be nice and might be a starting point for whoever might be interested in this in the future.
      • I wouldn't go too deep into automatic submissions, yet though.
      • pserwylo
        indeed it is large. I might leave it to further discussions with _hc_roving about how it fits into his funding proposal. Perhaps a proof-of-concept is enough to show for that.
      • /system/priv-app is required as of JellyBean, before that the READ_LOGS permission would have been enough.
      • Tovok7
        there's also the danger that in the future not even system apps might be able to read the logs
      • pserwylo
        thats true.
      • anyway, I guess that is me
      • EOF
      • Tovok7
        who wants to go next?
      • uniq[m] thezero ?
      • mimi89999_m ?
      • pserwylo
      • Tovok7
      • I wrestled with weblate and now have a second component up for repomaker's javascript and learned that we need up a GitLab hook for weblate to pick up new translations automatically.
      • I reviewed NicoAlt's latest MR and merged it, so we now have endless scrolling of app lists in repomaker. There's a classic pagination fallback for users without JavaScript.
      • Then I worked on the manual translation workflow for apps in repomaker. This turned out way more tricky when expected. I know have an MR ready: rm!134
      • However, there's still a couple of issues: https://gitlab.com/fdroid/repomaker/issues?labe...
      • The one I would like help on is rm#156
      • NOTICE: [repomaker] !134: Implement Workflow for Translating App Metadata - https://gitlab.com/fdroid/repomaker/merge_requests/134
      • NOTICE: [repomaker] #156: Language codes are case-sensitive - https://gitlab.com/fdroid/repomaker/issues/156
      • how does the client handle case-sensitivty in language codes in the index['localized'] json object?
      • will it handle 'en-us' the same way it handles 'en-US' and what happens if it finds both?
      • problem is that django lowercases all these codes, even the ones the browser sends in ACCEPT_LANGUAGES header
      • pserwylo goes to look up App.java in fdroidclient and the `setLocalized()` block.
      • so if your browser accepts en-US, django looks for en-us which doesn't match en-US in the translation :(
      • and then you get afrikaans instead, because it is the first language it finds ;)
      • pserwylo
      • I can't see any toLower() calls in this class
      • but that doesn't mean we can't add them.
      • I can't possibly think of when 'en-US' and 'en-us' need to be different
      • BubuIIC joined the channel
      • Tovok7
        me neither and maybe there's a reason why django does it...
      • Tovok7 has quit
      • pserwylo
        in fact, we don't even create Locale objects in there, we just work with strings.
      • so even if the Locale Java API did care about it, we are not passing our strings into that API.
      • alrighty, well I might head off to bed now if that is all for tonight.
      • Tovok7 joined the channel
      • Tovok7
        however repos currently use en-US with the local part uppercase. when I import apps from there, I could just lowercase it and write it out in lower-case
      • but I didn't do this, because I don't know what the client will do
      • looks like it will treat it as a different language and ignore it, right?
      • if nobody has the perfect idea for how to solve this best, I probably need to do more research in this matter
      • alternatively, I could lowercase everything internally and uppercase the region part again when writing out the index
      • https://docs.djangoproject.com/en/1.11/topics/i... says Language codes are generally represented in lower-case, but the HTTP Accept-Language header is case-insensitive.
      • but since the internet seems to agree that they should be case-insensitive, it is probably a bug in the server if it allows en-us and en-US for the same app and for the client to treat en-us differently from en-US.
      • pserwylo
        I think it is safe in Android for you to upper case the region part too when writing out.
      • there may be some documentation somewhere in the Android project which explains whether it is upper/lower case (always)
      • Tovok7
        thanks pserwylo! that's probably would I will do as it avoids us having to deal with case-insensitivity now
      • *what
      • gn8 then!
      • pserwylo
        catch you latter.
      • uniq[m]
        My turn I guess
      • I've added new step to `fdroid publish`.
      • After all apps got signed, I'm genereating a (jared) json file containg all signing key fingerprints from the local keystore plus package-names.
      • This file then gets signed with the repoistory key 'repo_keyalias'.
      • pserwylo
        uniq[m]: Oh, this sound interesting to me, worth haning around for.
      • I'm curious as to the anticipated usage of this file?
      • uniq[m]
        This will then be used by `fdroid update` to determine which files go into index.xml
      • I have to put this in an extra file since the our keystore is the only place currently where we've got information about the signingkeys fdroid uses for signing apks
      • I guess this is the easiest way to get this data from our publishing to our build server.
      • would be nice to know how data gets copied between those two machines.