Package Details: freetube 0.20.0-4

Git Clone URL: (read-only, click to copy)
Package Base: freetube
Description: An open source desktop YouTube player built with privacy in mind.
Upstream URL:
Licenses: AGPL3
Submitter: picokan
Maintainer: picokan
Last Packager: picokan
Votes: 62
Popularity: 3.15
First Submitted: 2020-10-02 22:19 (UTC)
Last Updated: 2024-06-02 14:41 (UTC)

Latest Comments

1 2 3 4 5 6 .. 12 Next › Last »

chrrybmb commented on 2024-06-11 08:56 (UTC)

I believe the issue with electron 30 has been fixed in 30.0.6:

dawidpotocki commented on 2024-05-30 12:13 (UTC)

I was helping someone with building of this package, so I figured I will post the solution here.

Just replace the yarn commands with this:

UV_USE_IO_URING=0 yarn --cache-folder "${srcdir}/yarn-cache" install
UV_USE_IO_URING=0 yarn --cache-folder "${srcdir}/yarn-cache" run build

Here is a related issue:

gregsie commented on 2024-04-28 09:07 (UTC)

Hello. pamac is flagging electron29 as out of date. scfc@manjaro ~ $ pamac checkupdates -a Your system is up to date.

Out of Date: electron29-bin 29.0.1-1 AUR scfc@manjaro ~ $

No issues with freetub-bin. Love this application, great work as always!

taivlam commented on 2024-04-20 15:31 (UTC)

Thank you!

picokan commented on 2024-04-20 13:11 (UTC)

My bad, should be fixed.

taivlam commented on 2024-04-20 09:32 (UTC) (edited on 2024-04-20 15:30 (UTC) by taivlam)

Update: Issue has been fixed!

Hi, the SHA256 checksum for the file needs to be changed from 3f4951c6cdb33cc1c4df05606760197efe45321519c259e47656077d6df2af18 to 6e6f87019452eab4dd75ffe241cebe979fab532596647cdbc42f9a4aaf30cbe5.

When I try to build the package, I received this message at the end of stdout:

==> Validating source files with sha256sums...
    v0.20.0-beta.tar.gz ... Passed
    freetube.desktop ... Passed ... FAILED
==> ERROR: One or more files did not pass the validity check!

picokan commented on 2024-04-20 07:39 (UTC)

Normally I keep the dependency as the lastest electron version to avoid keeping multiple electron versions in my system, but I've seen a lot of problems with version 30 over many different programs, so I will downgrade the dependency to v29.

Also from what I understand reading the github issue, telling freetube to use v29 in the package.json file, but then building it and running it with v30 was what was causing the issue in this specific case.

On that final point, please never create issues or tickets upstream if you can't replicate it using their own steps. I package freetube for our convenience, not to be another source of noise.

je-vv commented on 2024-04-17 17:13 (UTC) (edited on 2024-04-17 17:17 (UTC) by je-vv)

In that they were right @tuxayo, becuase we use the easy yarn way, and I was mistaken with my original patch, electron is not needed at all, since with yarn downloads by itself the electron binary it needs, the system electron is not being used on the build.

That said, I see two places where the freetube packaging is hard coding versions:

FreeTube-0.20.0-beta/yarn.lock:3497:  resolved ""
FreeTube-0.20.0-beta/yarn.lock:3500:    "@electron/get" "^2.0.0"
FreeTube-0.20.0-beta/package.json:92:    "electron": "^29.1.6",

I'm no expert on yarn neither javascript, but good trial would be to edit those two file, and see. The sad side, is that they are hard coding everything, the major, the minor and the patch versions (if electron uses semver), which is pretty static.

Yarn is a bit of a headache...

And it bothers me a little bit the answer was that someone tried it on electron30, but didn't say how. As you can see, 29 is hard coded...

But it can be tried. Another possibility is to change the electron dependency to electron29, as it's the hard coded version coming with freetube, and also on the script, like the patch I wrote (just removing the electron dependency, and keeping the electron29 one), and live with that.

I think it'll depend on the package mantainer. It would be nice to totally use the system electron for building, but with yarn is not that easy, at most you can specify it what version to download and use, but that one would still not be the system one. But it might be close enough. Full hard coded version though...

Not sure what this package mantainer will choose, :)

BTW, I edited my patch since eletron was then really bogus

tuxayo commented on 2024-04-17 16:15 (UTC) (edited on 2024-04-17 16:15 (UTC) by tuxayo)

Turns out no, the dev really implied that electron 30 works. And they tested it and it works.

The issue is that package.json lists electron 29 so it builds against it and the AUR package has electron 30 for runtime.

We're back to a packing issue here.

tuxayo commented on 2024-04-17 01:59 (UTC) (edited on 2024-04-17 16:17 (UTC) by tuxayo)

But that github issue was closed just because they don't support this AUR package

Your are right! The triaging was so strict it missed or ignore the actual point, electron 30 support.

I don't see the implication that electron 30 is supported [...] So I don't think there's any implication of electron 30.0 supported, they didn't mention that, just that they don't care about the AUR package.

I assumed good faith in their response and though it implied it was supported. So that the packing was wrong. There is no way to close such a ticket «Segfaults after updating to electron 30» without mentioning electron 30 isn't supported. Turns out yes ^^"

edit: I misunderstood, it's not about too strict and expeditive triaging