NewPipe update request

#1

Is it possible to get NewPipe updated please?

1.4.1 was released on 7th September 2018 but the last update on F-droid was 23rd July 2018.

Here is the list of releases: https://github.com/TeamNewPipe/NewPipe/releases

An update would be awesome as this is the only market place NewPipe is available from.

Also note that all previous versions of the app no longer work as per this issue: https://github.com/TeamNewPipe/NewPipe/issues/1659 which is fixed in 1.4.1.

#2

It will be done automatically

#4

this one example with YT collapse shows the big problem with F-Droid app delivery. And it seems to unable to haste this (currently). @team , care to change something with that?

#5

Not sure what it shows, sad to see everyone talk about this like itā€™s F-Droidā€™s fault when: a closed source network service treats its users as hostiles changing APIs willy-nilly breaking 3-rd party apps.

Read that phrase again, and again, and again, and stop ranting about what F-Droid can do or doesnā€™t do.

Did the F-Droid build service break? No.
Did the F-Droid publishing service break? No.
Did the F-Droid APK download service break? No.
Did the F-Droid app submission break? No

Does the site at fault still work in a browser? Yes, USE THAT! PANIC END.

:frowning:

/PS: Merge requests to streamline the F-Droid workflow are welcomed here:



Letā€™s fight this people, letā€™s fix it! git clone !!! :slight_smile:

#6

Updated NewPipe yesterday but only to 0.14 version, fix is in 0.14.1. Hope fix will come soon to F-Droid.

#7

Please calm down.

this one example with YT collapse shows the big problem with F-Droid app delivery.

example , shows , app delivery

Nobody blames noone for YT problems. I wouldnā€™t care to write one word about it.

I touched the other problem that was discussed long time ago: slowness of the process.

And thatā€™s mostly tolerable in most cases except some momentsā€¦ when it gets really irritating.

Sidenote: AFAIK the problems arenā€™t just in code, human factor also exists. And that canā€™t be solved by MRs.

#8

Exactly, how many of these who are ā€œaffectedā€ (allow me to roll eyes here) would start contributing to F-Droid? I guess rather none. Once the fixed version is in everybody continues with their lives, the next day it was all a dream. (Until next time, thereā€™s always a next time when it comes to this situation)

I am calm, Iā€™m more disheartened than anything.

#9

Still no update on f-droid for 1.4.1

#10

I was build yesterday: https://f-droid.org/wiki/page/org.schabi.newpipe/lastbuild_68

It needs to wait like all the other apps, the end of the process, then publish.

/PS: The build server is still running: https://f-droid.org/wiki/index.php?title=Special:RecentChanges&days=7&from=&hidebots=0&hideanons=1&hideliu=1&limit=500

#11

To sum up, there are two main reasons why app sometimes take a long time to appear in the index:

  • The building process is slow because we use a new separate virtual machine for every APK
  • New apps or updates are not published until every build currently queued is complete

I understand it can be frustrating but there is nothing we maintainers can do to manually speed up an important app update.
Of course, if you have ideas on how to improve the building process, your help is welcome.

And app authors that want more control over updates can create their own F-Droid repository.

(Also, keep in mind that we tend to publish updates rather quickly compared to other package managers that build from source like Ubuntu for example.)

#12

Wow! Surprising!

Š²Ń‚, 11 сŠµŠ½Ń‚. 2018 Š³., 1:01 Rudloff:

ā€¦ but there is nothing we maintainers can do to manually speed up an important app update.

Of course, if you have ideas

Manually? This is easy.

  1. Move the seven-times-asked app to the head of the build queue

  2. Sign this one app manually when itā€™s built

  3. Drop to the repo and regenerate index

All three are exactly manual steps and exceptional but this is what supportive communities and paid companies do in such cases.

(Also, keep in mind that we tend to publish updates rather quickly compared to other package managers that build from source like Ubuntu for example.)

Wrong. I wont tell for Ubuntu but there are other disros that do much quicker.

Though itā€™s not rational to compare head to head. Android packages arenā€™t similar to Linux packages.

#13

Debian updates their package index 3 times a day. It would be nice we could do that as well, but weā€™re not there (yet?).

Well there was a > 60 hour delay there (between update and deploy) on the weekend. So something did break? I donā€™t know. At least thatā€™s what caused the annoying delay in building new things.

If the F-Droid is actually working as intended without any delays between any of the stages we are able to publish a new index ~ once a day. At that pace nobody is actually complaining.

#14

Just because I have no idea how f-droid works, why is that? I have a hard time figuring out the rationale behind this choice.
Also IMHO apps building, in addition to fifo, should take into account some kind of priority e.g. (top to bottom): security upgrade, broken app upgrade, standard/new features upgrade. Every time an app is built, the builder should check what the next high priority app is in queue and needs to be built, if any. Just an opinion of an outsider, I donā€™t know if itā€™s feasible right now.

#15

I thought it was ā€œthe weekend factorā€ :smiley:

#16

more like a human factor.

#17

Generating the index takes a few hours (fdroid update has to gather all kind of metadata information from all the apps source repos). You can probably imagine why itā€™s done in batches :wink: .

Most of the builds get automatically added by checkupdates. There is no point in this process where a build entry can be marked as more critical as any other.

Also it would not help at all because the server would still build all pending builds and everything is gated by the index signing in the endā€¦ :-/

#18

Š²Ń‚, 11 сŠµŠ½Ń‚. 2018 Š³., 19:36 Marcus Hoffmann:

Generating the index takes a few hours (fdroid update has to gather all kind of metadata information from all the apps source repos). You can probably imagine why itā€™s done in batches :wink:

This is a very interesting and useful information. Iā€™m sure thereā€™s a bug hanging somewhere for it. Please someone share if not difficult: besides obvious ā€œcachingā€ improvement I got another idea to purpose.

#19

Iā€™m just a lowly user who enjoys F-Droid immenselyā€¦ I appreciate the time all of you put into making all this work. I always read in awe. A big THANKS.

#20

Haha, everybody loses their minds when their YouTube scraper app breaks, brb, gotta get some popcorn

*IS SCREAMING INTERNALLY TOO*

#21

Guys, I understand your frustration about how slow F-Droid delivers updates. Let me explan why this happens. F-Droid cycle looks like this:

  1. Check for updates. F-Droid downloads recent changes of 2365 apps and parses them to find new releases.
  2. Build. For each new release F-Droid starts a VM and builds it from scratch. Usually there are dozens. Even the smallest utility needs 7 minutes to build, while each Fennec APK will take up to 5 hours.
  3. Generate index. F-Droid gathers metadata from fdroiddata (2773 entries), apps source code (98 file trees) and APKs (19229 of them, each needs to be unzipped and parsed).
  4. Sign APKs and index. Ciaran manually transfers APKs and the new index to an air-gapped system (it has no Internet connection to avoid signing keys leaks), signs them and brings signed files back.

Hopefully you now see why each stage takes many hours and the whole cycle takes days.