Package Details: vlc-git 4.0.0.r29905.gc347fed91e-1

Git Clone URL: https://aur.archlinux.org/vlc-git.git (read-only, click to copy)
Package Base: vlc-git
Description: Multi-platform MPEG, VCD/DVD, and DivX player
Upstream URL: https://code.videolan.org/videolan/vlc
Licenses: GPL2, LGPL2.1
Conflicts: vlc
Provides: vlc
Submitter: None
Maintainer: xiota (knoelli)
Last Packager: knoelli
Votes: 209
Popularity: 0.34
First Submitted: 2008-04-01 12:14 (UTC)
Last Updated: 2024-07-13 20:48 (UTC)

Required by (156)

Sources (3)

Latest Comments

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

MontBD.Veloper commented on 2024-09-25 03:26 (UTC) (edited on 2024-09-25 03:27 (UTC) by MontBD.Veloper)

@xiota, yes, I received response from code.videolan.org as seen in my previous comment. With regards to your suggestion, I will do that. Thanks.

xiota commented on 2024-09-21 11:57 (UTC) (edited on 2024-09-21 11:59 (UTC) by xiota)

I wouldn't mind switching to github, because their performance is usually better, but there can still be problems cloning some github repos. But doing so would require users to clear cache before next build or some changes to the package to make it work without clearing cache. Some other updates are also needed, like changing license strings to SPDX identifiers.

@MontBD.Veloper Do you receive any response when you ping code.videolan.org? If not, you may have something like a DNS outage (some sites may still work because of caching). Otherwise, please try rebuilding with git config --global http.version HTTP/1.1 added to the beginning of the PKGBUILD? (If you're not building in clean chroot, run git config --global http.version HTTP/2 after build to undo.)

knoelli commented on 2024-09-21 11:49 (UTC) (edited on 2024-09-21 11:50 (UTC) by knoelli)

@MontBD.Veloper Changing the upstream url would technically be no problem. In the past, the VLC team used code.videolan.org as primary place where development took place, and their github repository was way behind. That's why I made the switch to code.videolan.org back then. Currently both resources are updated regularly so we might switch back to github. Btw. for me there's a difference in the latency for code.videolan.org (on average 25ms) and github.com (on average 15ms), but that barely makes a notable difference.

MontBD.Veloper commented on 2024-09-21 11:25 (UTC) (edited on 2024-09-21 11:27 (UTC) by MontBD.Veloper)

Can we use their github repo as the upstream url? As I experienced slow download when cloning the current upstream url. I have successfully installed it using the github repo in the PKGBUILD.

Error when installing:

fetch-pack: unexpected disconnect while reading sideband packet 
fatal: early EOF fatal: fetch-pack: invalid index-pack output 
==> ERROR: Failure while downloading vlc git repo Aborting... 
Failed to build vlc-git aur

Pinging the current upstream url:

PING code.videolan.org (213.36.253.9) 56(84) bytes of data.
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=1 ttl=45 time=281 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=2 ttl=45 time=281 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=4 ttl=45 time=283 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=5 ttl=45 time=281 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=6 ttl=45 time=282 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=8 ttl=45 time=281 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=9 ttl=45 time=281 ms
64 bytes from goldeneye2.videolan.org (213.36.253.9): icmp_seq=10 ttl=45 time=283 ms

--- code.videolan.org ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9045ms
rtt min/avg/max/mdev = 280.734/281.736/283.287/0.999 ms

Pinging google:

PING google.com (142.251.221.14) 56(84) bytes of data.
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=1 ttl=56 time=8.55 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=2 ttl=56 time=4.79 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=3 ttl=56 time=5.28 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=4 ttl=56 time=4.78 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=5 ttl=56 time=4.65 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=6 ttl=56 time=4.91 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=7 ttl=56 time=4.98 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=8 ttl=56 time=4.68 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=9 ttl=56 time=5.68 ms
64 bytes from mnl08s02-in-f14.1e100.net (142.251.221.14): icmp_seq=10 ttl=56 time=5.04 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 4.652/5.334/8.550/1.111 ms

As you can see there is a big difference in their latency. I just pointed out here that my internet is not the cause of the issue.

This is just a suggestion, maybe this is just on me or only an isolated case, you may check it out on your side.

BTW, big thanks to the contributors of this package.

1211days commented on 2024-06-26 16:38 (UTC)

@knoelli, thank you very much! Compilation works again

knoelli commented on 2024-06-26 10:25 (UTC)

@1211days Thank you for bringing this to my attention. The problem seems to be caused by VLC moving to ffmpeg 7.0. I've added a patch based on commit #1c15a5e1 that fixes the issue, so compilation should now work again.

1211days commented on 2024-06-25 19:49 (UTC) (edited on 2024-06-25 20:15 (UTC) by 1211days)

I'm getting a compilation error: https://0x0.st/Xm-6.txt

knoelli commented on 2024-05-23 20:30 (UTC)

@SebastianOnArch Thank you for letting me know. I updated the PKGBUILD and removed the gcc14 compatibility patch. Additionally, I fixed recent compilation errors due to QT6 detection problems.

SebastianOnArch commented on 2024-05-23 10:48 (UTC) (edited on 2024-05-23 12:14 (UTC) by SebastianOnArch)

There have been changes made to upstream (ceae7711b649738f06188f906b7782258222c090), fixing the gcc 14 issue, thus rendering the gcc14.patch useless.

Currently, the package can't build, because the patch can't find the initial source line. Removing the gcc14.patch fixes the issue.

knoelli commented on 2024-05-13 18:47 (UTC)

@PizzaBote2.4 Build fails due to an upstream incompatibility with latest gcc 14. I've added a patch to PKGBUILD to fix the issue.

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