Package Details: memtest86-efi 1:10.7build1000-1

Git Clone URL: https://aur.archlinux.org/memtest86-efi.git (read-only, click to copy)
Package Base: memtest86-efi
Description: A free, thorough, stand alone memory test as an EFI application
Upstream URL: https://www.memtest86.com
Licenses: GPL2, custom:PassMark
Submitter: UnicornDarkness
Maintainer: UnicornDarkness
Last Packager: UnicornDarkness
Votes: 113
Popularity: 1.99
First Submitted: 2013-10-29 10:25 (UTC)
Last Updated: 2024-02-08 18:13 (UTC)

Dependencies (3)

Required by (0)

Sources (4)

Pinned Comments

UnicornDarkness commented on 2019-06-08 08:52 (UTC) (edited on 2019-06-08 08:53 (UTC) by UnicornDarkness)

As you probably know, the <https://www.memtest86.com/downloads/memtest86-usb.zip> URL is likely to cause problems, like this error:

==> Validating source files with sha512sums...
    memtest86-efi-8.2.zip ... FAILED

To avoid this problem, I prefer to reupload memtest86-usb.zip archive somewhere else, where this kind of breakage will not appear.

I can't upload this archive on AUR directly (archive is 8 MB but AUR accepts 250 KiB maximum), so I decide to put this archive on my Git repository to avoid future breakages.

I hope it suits you.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 15 Next › Last »

Sven commented on 2019-03-12 22:56 (UTC)

This package should install a file to /etc/grub.d/ so that grub-mkconfig picks it up automatically. The memtest86+ package does that. So why does this one skip that?

zerophase commented on 2019-02-28 18:26 (UTC) (edited on 2019-02-28 18:27 (UTC) by zerophase)

@xiretza That issue is the responsibility of you. The package manager is not responsible for the maintenance of your system. Now, the package manager could have a version check that causes the PKGBUILD to fail, if the zip extracted does not have the right version of memtest86.

The proper solution in the cached package directory is:

updpkgsums
makepkg -sric
rm -rf memtest86-usb.zip

UnicornDarkness commented on 2019-02-28 17:51 (UTC)

Ok, that's fixed (again).

xiretza commented on 2019-02-28 16:16 (UTC)

It's certainly not the best way, in fact I would say it's a lot worse than failing checksums.

As long as the PKGBUILD doesn't save the .zip with a versioned name, manual intervention (i.e. deleting the file from the package directory) is always required. The only difference is that if there's a checksum, you know you have to do this. If it's set to SKIP, the old file is simply used without even a warning, and the resulting package never changes. This is arguably more broken than a package that doesn't build because of a wrongly cached file.

The best solution would be to leave the checksum and download the file to a name that contains $pkgver, i.e.

source=("$pkgname-$pkgver.zip::https://www.memtest86.com/downloads/$_pkgbasename-usb.zip"
        [...]

This way, a checksum is always bound to a local file name (since they update at the same time in the PKGBUILD), and a broken checksum means both $pkgver and the checksum need to be updated.

buzo commented on 2019-02-27 14:34 (UTC)

Correct, but it is the best way to deal with the broken upstream. Someone should contact them to fix it.

Besides, there is memtest86+ in the community repo as an alternative.

ortango commented on 2019-02-27 14:30 (UTC)

@Xorg

isn't it the case that this pkgbuild will not download a new memtest86-usb.zip if it exists in the srcdest since the file isn't versioned?

so it will use the last version and extract from there. since you are now skipping the hash check it won't even fail. people will install the old version as the new version and never even know.

UnicornDarkness commented on 2019-02-27 12:19 (UTC)

@dude and @Popkornium18: Ok, done. Thank you for your advice.

Popkornium18 commented on 2019-02-27 10:46 (UTC)

@Xorg Checksum should definitely be 'SKIP' in that case. There is no point in having a checksum verification if it is always failing anyways.

dude commented on 2019-02-27 08:06 (UTC)

@Xorg maybe the sha512sum should be changed to 'SKIP' in that case, if it can't be reliably verified.