Data issueshttps://staging.gitlab.com/fdroid/fdroiddata/-/issues2017-06-07T01:38:29Zhttps://staging.gitlab.com/fdroid/fdroiddata/-/issues/660Syncthing-Android pulled submodule syncthing at '-rcX' instead of 'final'2017-06-07T01:38:29Zusername-removed-534375Syncthing-Android pulled submodule syncthing at '-rcX' instead of 'final'Reference: https://github.com/syncthing/syncthing-android/issues/872 and my comment there.Reference: https://github.com/syncthing/syncthing-android/issues/872 and my comment there.https://staging.gitlab.com/fdroid/fdroiddata/-/issues/901Trigger rebuild: com.catchingnow.tinyclipboardmanager2017-10-09T01:47:27Zusername-removed-1120883post@bogus.eeTrigger rebuild: com.catchingnow.tinyclipboardmanagerhttps://staging.gitlab.com/fdroid/fdroiddata/-/issues/902Trigger rebuild: name.soulayrol.rhaa.sholi2017-10-09T01:08:46Zusername-removed-1120883post@bogus.eeTrigger rebuild: name.soulayrol.rhaa.sholihttps://staging.gitlab.com/fdroid/fdroiddata/-/issues/675Unify "Requires Root"2017-05-09T08:01:50Zusername-removed-25246Unify "Requires Root"*Requires Root* is a boolean setting in the metadata. On some apps, we duplicate this information in the description, on some we dont and on others we add specific notes why this app requires root. We should unify this behavior.
My pov ...*Requires Root* is a boolean setting in the metadata. On some apps, we duplicate this information in the description, on some we dont and on others we add specific notes why this app requires root. We should unify this behavior.
My pov is, that this should only be in the metadata, since that allows for the client to re-act to this. This is compliant with our general stance to not duplicate information (no need to mention ads when we have an antifeature for this) and not stating the obvious (like being floss) Former F-Droid versions used to grey out root apps, but the new UI has a regression that prevents this. See https://gitlab.com/fdroid/fdroidclient/issues/928.https://staging.gitlab.com/fdroid/fdroiddata/-/issues/617Update FBReader2017-10-06T11:50:47Zusername-removed-455713Update FBReaderHello,
Is it possible to update FBReader please ?
The version on Fdroid is 2.1 whereas the version on Google play is 2.7.12.1
Thanks !Hello,
Is it possible to update FBReader please ?
The version on Fdroid is 2.1 whereas the version on Google play is 2.7.12.1
Thanks !https://staging.gitlab.com/fdroid/fdroiddata/-/issues/671update libreoffice viewer2017-10-08T14:49:20Zusername-removed-881251update libreoffice viewerthe version on fdroid is from october, 2016. if possible, please update the app.the version on fdroid is from october, 2016. if possible, please update the app.https://staging.gitlab.com/fdroid/fdroiddata/-/issues/802use "Fast-forward merge" for accepting merge requests2017-08-14T12:15:29Zusername-removed-24982use "Fast-forward merge" for accepting merge requestsI think we should switch _fdroiddata_ to accept merge requests with "Fast-forward merge":
"No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. ...I think we should switch _fdroiddata_ to accept merge requests with "Fast-forward merge":
"No merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. When fast-forward merge is not possible, the user is given the option to rebase. "
Since _fdroiddata_ has lots of commits by its nature, I think we want to reduce the number of commits if we can. git and related tools will start to slow down as it gets bigger, so we want to delay that as much as possible. Have you ever worked with a really big git repo? It can be quite painful. Since the vast majority of MRs in _fdroiddata_ do not overlap with other ones, I think there will rarely be merge conflicts.
Another strategy is also use "Squash commits" as much as possible. Like if a MR only changes a single app, it should be squashed.
@mimi89999 @krt @licaon-kter @relan @grote @uniqx @est @xinxinxinxinxin @CiaranGhttps://staging.gitlab.com/fdroid/fdroiddata/-/issues/700use upstream signatures on Wallabag2017-04-19T21:38:41Zusername-removed-71118use upstream signatures on WallabagWallabag is [verifiable](https://verification.f-droid.org/fr.gaulupeau.apps.InThePoche_32.apk.verified.txt) yet the upstream binaries are not used when shipping the app on F-Droid.
Binary APKs are available here from upstream so, presum...Wallabag is [verifiable](https://verification.f-droid.org/fr.gaulupeau.apps.InThePoche_32.apk.verified.txt) yet the upstream binaries are not used when shipping the app on F-Droid.
Binary APKs are available here from upstream so, presumably, we could reuse the signatures?
https://github.com/wallabag/android-app/releases
I am not sure how this work, but I hope someone can figure this out - thanks!https://staging.gitlab.com/fdroid/fdroiddata/-/issues/591Zxing Barcode Scanner 4.7.6 available2017-10-02T08:20:25Zusername-removed-41349Zxing Barcode Scanner 4.7.6 availableZxing Barcode Scanner / `com.google.zxing.client.android` is out of date.
- Current version: `4.7.6`
- Latest F-Droid version: `4.7.3`
https://github.com/zxing/zxingZxing Barcode Scanner / `com.google.zxing.client.android` is out of date.
- Current version: `4.7.6`
- Latest F-Droid version: `4.7.3`
https://github.com/zxing/zxingusername-removed-357829michel@lebihan.plusername-removed-357829michel@lebihan.pl