#fdroid-dev

/

      • Tovok7 has quit
      • pserwylo
        cdesai: Okay, mine has been merged, so feel free to ping me if you have any problems. I did a quick merge of your stuff locally, and there were no merge conflicts which was nice.
      • cdesai joined the channel
      • cdesai
        _hc: I started doing that last night but it was hitting a lot of new places this time, but it'll be managable.
      • pserwylo: I did a test with your commits here locally and it's been working fine
      • pserwylo
        cdesai: cool, glad to hear
      • andyrtr has quit
      • andyrtr joined the channel
      • relan joined the channel
      • DrOwl joined the channel
      • ShapeShifter499 joined the channel
      • cdesai
        _hc: finally done with !541, media support
      • NOTICE: [client] !541: Add support for non-apk files - https://gitlab.com/fdroid/fdroidclient/merge_requests/541
      • apologies for taking so long, I lost quite a lot of time in between (most of last weekend and some this week) due to computer crashes - might have to build a new system if they keep happening :/
      • nailyk
        mimi89999_m: ok thanks. You know some one else I could ask?
      • pserwylo
        nailyk: the forum currently has a post in the German language section about the proper words to use, perhaps a French subforum would be a good place to post?
      • If we haven't set that up yet, then perhaps even just a regular post in the main forum.
      • nailyk
        mhh ok.
      • thk
      • pserwylo
        de rien
      • relan has quit
      • relan joined the channel
      • robert___ joined the channel
      • relan has quit
      • _hc has quit
      • _hc joined the channel
      • ShapeShifter499 has quit
      • hi all
      • pserwylo jotting down some notes for the meeting
      • _hc
        hey, I'll start doing the same
      • cdesai
        hello
      • _hc
        pserwylo: CiaranG cdesai est31 mimi89999_m uniq[m] NicoAlt tovok7 meeting time!
      • mimi89999_m
        :-)
      • est31
        hi
      • I've got back to good hardware, will try to get back into f-droid
      • especially considering the recent gaps
      • pserwylo
        recent gaps?
      • est31
        krt leaving
      • pserwylo
        ah yes
      • comradekingu
        gapps probably
      • est31
        lol
      • pserwylo
        so i might jump in and start my report
      • Since last week,
      • Multi signature support is now in the client c!552
      • It plays well, ensuring that we don't suggest an upgrade to apks with the wrong signature.
      • It will also exclude apks with the wrong signature from the versions list all together.
      • NOTICE: [client] !552: Support for " preferred sig" - https://gitlab.com/fdroid/fdroidclient/merge_requests/552
      • _hc
        all you MicroG users should test this!
      • pserwylo
        Today I finished the first attempt at displaying apks with known vulnerabilities (c#1070 c!558).
      • There is some lively discussion around the finer issues related to displaying vulnerabilities in c#1070.
      • Specifically - if an app depends on a vulnerable library, and we flag it but don't notify upstream, we may piss them off.
      • Especially if the part of the library which is vulnerable is not relevant to their app.
      • It would be nice if we could include just enough info to let people make a meaningful bug report upstream.
      • NOTICE: [client] #1070: "this has a known vuln", install in app details, … - https://gitlab.com/fdroid/fdroidclient/issues/1070
      • NOTICE: [client] !558: WIP: Show apps with known vulnerabilities in the … - https://gitlab.com/fdroid/fdroidclient/merge_requests/558
      • NOTICE: [client] #1070: "this has a known vuln", install in app details, … - https://gitlab.com/fdroid/fdroidclient/issues/1070
      • that doesn't mean showing CVE's or anything, but at least linking to a doc on our website where you can figure out what is going on.
      • _hc: Are you able to add an app with two versiosn to testy.at.or.at, the earlier version with a KnownVuln, and the later without?
      • _hc
        part of the idea of the known vuln stuff is that we can also scan and provide metadata for lots of apps, not just the apps in f-droid
      • pserwylo
        It would be helpful to test "We found a vulnerability, we suggest you upgrade..." feature
      • _hc
        pserwylo: yes, I'll add that now
      • cdesai
        could there be an e-mail in the metadata, where upstream would get a report if fdroid flags it
      • pserwylo
        cdesai: although there is AuthorEmail, I don't think it is widely used.
      • but I'd settle for a special page on the wiki, where some of us at team@f-droid.org could sometimes look through and decide whether or not to contact people.
      • est31
        what is "binary transparency"?
      • I know what reproducible builds are
      • pserwylo
        even if it is a manual process (that no one participates in to start with) then we can think about how to improve it in the future
      • cdesai
        pserwylo: I was looking at random apps in fdroiddata to see if they had anything relevant - only 34 apps with Author Email set so yeah not so useful.
      • pserwylo
        est31: making sure that people are not getting served comprimised binaries.
      • it depends directly on reproducible builds, so very closely related I guess
      • est31
        thx
      • pserwylo
        As far as the client is concerned
      • I think when this next group of MRs is done, then we are looking pretty good for v0.105.
      • At the very least we should dump a v0.105-alpha1,
      • because there are quite a few big changes and scope for bugs we may want to iron out.
      • That will end up being quite a release, with several new features (media support, multi sig support, offline "mark for install" support)
      • _hc
        there is already an email in the metadata
      • est31
        ah so its similar to certificate transparency
      • _hc
        cdesai: we do have a lot of links to the issue tracker, so we could even auto-file issues
      • that would be a cool thing to work on, we should include this in the Mozilla grant!
      • a!43
      • NOTICE: [client] !43: For mainline - https://gitlab.com/fdroid/fdroidclient/merge_requests/43
      • admin!43
      • admin#43
      • NOTICE: [admin] #43: applying for a Mozilla Open Source Support grant - https://gitlab.com/fdroid/admin/issues/43
      • pserwylo
        lol
      • cdesai
        _hc: +1. a big majority of the issue tracker links are github so that'd make things easier too
      • 1874/2427 issue tracker links are github.
      • pserwylo
        I'll comment in #1070 along these lines, i.e. we may well investigate auto-submitting issues.
      • NOTICE: [client] #1070: "this has a known vuln", install in app details, … - https://gitlab.com/fdroid/fdroidclient/issues/1070
      • _hc
        pserwylo: as for release numbers, I was thinking of just sticking with 0.105, since we haven't been updating the current version
      • if 0.105 is stable, we can try marking it as the current version
      • I'm thinking we're still in open beta
      • getting to 1.0 RC
      • pserwylo
        I can promise you it wont be stable, I thought it worked quite well when mvdan was tagging regular alpha builds (e.g. after two or three MRs) then we could settle on a stable after a few alphas.
      • It means we didn't need to even consider whether it was worth a release after each MR, we could just do it
      • _hc
        yeah, I want to get back to that pattern once we do a full stable release of the new UX
      • starting with 1.0
      • pserwylo
        If that is the case, then we should just be done with it and tag 1.0-alpha1. Who cares if we need 10 alphas? Most software goes several weeks or many months with alpha releases before they stabilise
      • _hc
        ok, how about we do that after 0.105?
      • ok, fine we can do it now
      • pserwylo
        anyway, I'm not actually to bothered with the version numbers, just with being regular as we push MRs, and also with being conservative with marking current versions.
      • I think you'd fine a lot of support for doing 1.0 with several alphas, in preference to 0.105 without alphas.
      • both result in end users getting features made available,
      • _hc
        done
      • pserwylo
        thanks
      • _hc
        since I'm already kind of going, I'll give the rest of my report
      • thezero has completed his contract, and is focusing on finishing his studies now.
      • I'm aiming to tag the 1.0-alpha0 release end of day Friday (tomorrow)
      • Managing all the localization stuff is still a big time suck for me, including dealing with Weblate, finalizing contracts,
      • getting translators started and answering their questions.
      • then there is also dealing with merge conflicts when importing translations
      • pserwylo
        no worries, so do you want me to jump on the index-v1 support for jekyll-fdroid?
      • _hc
        yes please!
      • pserwylo
        cool, if I dont' get on it tomorrow, I will on Monday.
      • finally, for my report:
      • _hc
        that reminds me, is there anything in particular we should cherry-pick to deploy on f-droid.og?
      • pserwylo
        oh, the search stuff probably. That is annoying lots of people, and shouldn't depend on i18n.
      • therefore, it shouldn't require any apache config
      • _hc
        yeah, makes sense
      • pserwylo
        it should be in a single commit (which adds a dependency on a specific version of Jekyll), but you'll need to change the commit so that it renders English text,
      • because I think the commit that introduced the search sidebar was after translations were included
      • Do we know if it is automatic or not, or are you just going to tag-and-see?
      • If so, then I might see if I can put together a quick commit which shows the current version of the website in the footer
      • _hc
        I'm going to tag it and see
      • pserwylo: how about you put together a merge request with search and the version? against 0.0.1 tag
      • or just make a branch in git
      • and ping me when its ready
      • pserwylo
        okay, done.
      • EOF
      • _hc
        I've been working my way through the client merge request backlog too.
      • will do that more today
      • uniq[m] and I are going to take our first stab at figuring out the netidee.at grant
      • today
      • 've been working on finalizing a bunch of work on fdroidserver, including around the new KnownVuln functionality. This stuff is still quite raw, and there is a lot of potential.
      • You can find out more in this thread which pserwylo already mentioned:
      • #1070
      • NOTICE: [client] #1070: "this has a known vuln", install in app details, … - https://gitlab.com/fdroid/fdroidclient/issues/1070
      • and last, I want to get any last feedback on the new sudo= Build field before merging it: s!297
      • NOTICE: [server] !297: WIP: add new 'sudo=' Build field - https://gitlab.com/fdroid/fdroidserver/merge_requests/297
      • I've gotten some already
      • mimi89999_m: ^^^
      • that's it from me, who's next?
      • cdesai
        I can go
      • _hc
        go!
      • cdesai
        I worked on finishing up the media support this week, and it's done c!541. Works well, and we didn't have to change too much of existing fdroidclient code to get it to fit in.
      • Been a slow week otherwise due to hardware issues on my end :/
      • I'm thinking of adding tests for the media support later on.
      • BTW, is there anything I should look at right away rather than just finding a issue from the milestone?