Package Details: lib32-dav1d 1.4.0-1

Git Clone URL: https://aur.archlinux.org/lib32-dav1d.git (read-only, click to copy)
Package Base: lib32-dav1d
Description: AV1 cross-platform decoder focused on speed and correctness (32 bit)
Upstream URL: https://code.videolan.org/videolan/dav1d/
Licenses: BSD
Submitter: oxalin
Maintainer: oxalin
Last Packager: oxalin
Votes: 7
Popularity: 0.000000
First Submitted: 2019-08-15 16:53 (UTC)
Last Updated: 2024-02-26 00:08 (UTC)

Pinned Comments

oxalin commented on 2023-05-27 03:44 (UTC)

Please, don't flag this package as out-of-date if it is using the same version as the native package.

If you have dependencies problems when building, flagging the package as out-of-date if there is no updated dav1d's version is not the way to go. For this kind of situations, share a comment with whatever error you are uncountering or whatever fix you propose.

oxalin commented on 2020-05-25 15:49 (UTC) (edited on 2020-05-25 15:55 (UTC) by oxalin)

About GPG, it is up to you to import the missing public key. If you receive an error about it, this is ffmpeg's project public key. Something like the following should do the trick: gpg --recv-keys 7180713BE58D1ADC

Latest Comments

1 2 3 Next › Last »

oxalin commented on 2023-05-27 03:44 (UTC)

Please, don't flag this package as out-of-date if it is using the same version as the native package.

If you have dependencies problems when building, flagging the package as out-of-date if there is no updated dav1d's version is not the way to go. For this kind of situations, share a comment with whatever error you are uncountering or whatever fix you propose.

loglog commented on 2022-03-22 16:19 (UTC) (edited on 2022-03-22 16:22 (UTC) by loglog)

@elfosardo Thanks for the hint to install using makepkg.

@oxalin thanks for the idea to sign locally; however I feel it is a hack.

For a proper fix, the VLC team should renew their rusty dusty release key.

BTW, dav1d just advanced to version 1.0.0 - though not officially released yet - but you can already download the tarball and .asc signature. And guess -- it's signed with the same old expired key.

$ LANG=C gpg --verify dav1d-1.0.0.tar.xz.asc 
gpg: assuming signed data in 'dav1d-1.0.0.tar.xz'
gpg: Signature made Fr 18 Mär 2022 15:36:43 CET
gpg:                using DSA key 65F7C6B4206BD057A7EB73787180713BE58D1ADC
gpg: Good signature from "VideoLAN Release Signing Key (2018)" [expired]
gpg:                 aka "VideoLAN Release Signing Key (2015)" [expired]
gpg:                 aka "VideoLAN Release Signing Key (2013)" [expired]
gpg:                 aka "VideoLAN Release Signing Key (2014)" [expired]
gpg:                 aka "VideoLAN Release Signing Key (2016)" [expired]
gpg:                 aka "VideoLAN Release Signing Key (2017)" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 65F7 C6B4 206B D057 A7EB  7378 7180 713B E58D 1ADC
$ echo $?
0

Fun fact: the milestone's release notes include my issue ticket 382: dav1d is signed with expired RSA key though it had been just closed without any action.

oxalin commented on 2022-03-14 20:31 (UTC)

@elfosardo: pamac should be more explicit about the reason of the signature failure. After investgation, it seems pamac is kind of blind to what type of error / warning it encounters.

Could you locally sign the key and see if that helps?

gpg --lsign-key 7180713BE58D1ADC

elfosardo commented on 2022-03-09 09:41 (UTC)

@loglog @oxalin: thanks both for your replies, although this particular issue is not related to the key not being imported (as I wrote, I've done that already), nor to the package itself. I know that it's not the AUR responsibility to keep the key up-to-date, nor I was implying that. I saw the comment from loglog, but the issue I encountered make the package not buildable using pamac, instead of just receiving a warning, I'm getting a failure, as you can see from the trace I posted. Anyway, to bypass the issue I used makepkg instead of pamac, so the problem seems related to the current pamac version and how it reads the package signature. Hope this can help others trying to build this package.

loglog commented on 2022-03-08 14:05 (UTC)

@elfosardo: This is a known problem, see my comment from 2022-01-10 below. The videolan signoff keys seem to be orphaned since 2017. It is not the AUR maintainer's responsibility, but a negligence of the videolan team.

I reported the issue to the dav1d team, but they did not recognize the relevance to their project and closed the issue. I added a comment to the "next release" ticket for the upcoming next version. We'll see if that will help.

If anyone has a better understanding of the VideoLan.org project and can address this general issue (which is not specific to the dav1d codec and project), you're welcome to jump in.

dav1d issue ticket 382: (dav1d is signed with expired RSA key)[ https://code.videolan.org/videolan/dav1d/-/issues/382]

dav1d issue ticket 374: (next release)[ https://code.videolan.org/videolan/dav1d/-/issues/374]

elfosardo commented on 2022-03-07 10:30 (UTC)

@oxalin: thank you for your answer, I've imported the key correctly, as I usually do for other packages. This is what I'm getting:

==> Validating source files with sha512sums...
    dav1d-0.9.2.tar.xz ... Passed
    dav1d-0.9.2.tar.xz.asc ... Skipped
    c6a08b3aa1ee99dade53e5e32033bc1d14455a22.patch ... Skipped
==> Validating source files with b2sums...
    dav1d-0.9.2.tar.xz ... Passed
    dav1d-0.9.2.tar.xz.asc ... Skipped
    c6a08b3aa1ee99dade53e5e32033bc1d14455a22.patch ... Skipped
==> Verifying source file signatures with gpg...
    dav1d-0.9.2.tar.xz ... cat: write error: Broken pipe
FAILED
==> ERROR: One or more PGP signatures could not be verified!
Finished with result: exit-code
Main processes terminated with: code=exited/status=1
Service runtime: 2.218s
CPU time consumed: 2.062s
Error: Failed to build lib32-dav1d

oxalin commented on 2022-03-07 00:43 (UTC)

@elfosardo : you probably mean the VideoLAN's public key has expired. Please, don't flag a package out-of-date for this reason: the key is outside of the source code's scope. I'm providing a mean to get the key in my pinned comment, but it is to the user's responsibility to get the proper key and work around it.

That being said, even with the expired key, you should receive a warning (as long as you imported the key in the first place), but it shouldn't fail. If you have the key and it fails, than there must be something else going on. If you have a trace, let me know.

elfosardo commented on 2022-03-06 17:23 (UTC)

Because of the expired packaging key, this can't be built anymore

loglog commented on 2022-01-10 11:34 (UTC) (edited on 2022-01-19 11:57 (UTC) by loglog)

I tried to update from 0.9.2-1 to 0.9.2-2, but pamac builds a package lib32-dav1d-0.9.2-1-x86_64.pkg.tar and installs it. I end up with v0.9.2-1 again.

Pamac's output includes this:

==> Verifying source file signatures with gpg... dav1d-0.9.2.tar.xz ... Passed (WARNING: the key has expired.) ==> WARNING: Warnings have occurred while verifying the signatures. [...] ninja: Entering directory `build' [30/117] Generating include/vcs_version.h with a custom command fatal: not a git repository: '/var/tmp/pamac-build-bernhard/lib32-dav1d/src/dav1d-0.9.2/.git' [117/117] Linking target tools/dav1d [...] ==> Leaving fakeroot environment. ==> Finished making: lib32-dav1d 0.9.2-1 (Mo 10 Jan 2022 11:22:55 CET) ==> Cleaning up... [...] Checking available disk space... [1/1] Reinstalling lib32-libdav1d (0.9.2-1)... [1/1] Transaction successfully finished.

Pamac's output does not include the word 'patch', and during the compilation meson.build does not contain the change that makes the essential difference between 0.9.2-1 and 0.9.2-2.

During compilation, there exists a directory /var/tmp/pamac-build-bernhard/lib32-dav1d/.git but no /var/tmp/pamac-build-bernhard/lib32-dav1d/src/dav1d-0.9.2/.git

Platform: Manjaro Linux, Kernel 5.15.12, Intel Core i7-2820

EDIT (2022-01-19): The VideoLAN.org packaging key, which was used to sign dav1d-0.9.2.tar.xz, expired recently:

$ LANG=C gpg --list-keys  7180713BE58D1ADC
pub   dsa1024 2013-01-21 [SC] [expired: 2022-01-08]
      65F7C6B4206BD057A7EB73787180713BE58D1ADC
[...]

Nocifer commented on 2022-01-08 10:37 (UTC)

Alright, on the one hand this now builds successfully for me. But on the other hand I just gave it a try and so does lib32-shaderc, which used to produce the same error at the linking stage and which hasn't seen any updates in the meantime. Also, trying to build lib32-dav1d without the new upstream patch produces a whole bunch of new linking errors which weren't present before - these errors must be what @aaronp was referring to and what the upstream patch actually fixes.

But anyway, long story short, the linking error I had encountered with both lib32-dav1d and lib32-shaderc is now gone and both packages can be built just fine, which leads me to believe the issue was just an incompatibility with some system library or another that got silently resolved. Whatever the case, mission accomplished.