Makepkg can't pass checksum validation and package fails

Okay, If you can see the files, can you modify them ? Because I have two theories about what is happening.

  1. It is the path which is automounted that leads to the makepkg problems, which can be changed on Gparted just BE SURE to select the correct drive.
  2. If it not path (I highly doubt it) then it’s mounting as read-only

Gparted partition naming:

https://gparted.org/display-doc.php%3Fname%3Dhelp-manual#gparted-name-partition

Yes, everything is normal until makepkg

Please don’t create multiple topics for the same issue. I’ve merged the two together.

It seems all of this is because you’re trying to use an NTFS filesystem on Linux and expecting permissions to work right. They won’t. Use an ext4 filesystem to write to.

FYI, your post would have been binned on the Arch forums by now.

3 Likes
  1. A usb disk formated as ntfs on Windows
  2. In Manjaro xfce, plug the usb disk, it is automounted as /run/media/aaa/D:\/
  3. If clone aur repo at the path, makepkg fails, for detailed error: Makepkg can’t pass checksum validation and package fails
  4. If clone aur repo at ~, makepkg succeeds
  5. If mounted the usb disk manually at /mnt, makepkg succeeds

step 4 & 5 proves that the problem is caused by the path (/run/media/aaa/D:\/)

So, then it’s the drives partition name/label which is the problem. It’s not thunar that is causing the problem, it is the drive which has a label that makes a weird path which causes makepkg break

Yes, makepkg has not take care of this situation. I’ll report a bug there.

It’s a very special use case but might as well report it. but I agree the makepkg should be able to handle it (even though it is not the right way to have a path)

Binned :rofl: :rofl: :rofl:
Jokes aside, yeah it’s not nice to go creating new threads for each and every different problem.
Well at least he got his problem solved

If your “bug report” is anything like this mess, it won’t be taken seriously. If there is a bug, we’d all like to see it fixed, of course.

What I suggest is posting what you want to report here first and we’ll help you with it. We want it to actually be fixed if there is a bug, right? :wink:

Keep in mind you need to reproduce it on Arch, they will not accept it if you are using Manjaro.

1 Like

I did not know that they would not accept from a manjaro system, interesting, the more you know.

Nope. Arch is not Manjaro; Manjaro is not Arch. makepkg is part of pacman which is Arch’s package manager. Manjaro is of course based on Arch, but Arch does not support anything but pure Arch.

1 Like

OK, I must refine my description later.
And I’ll try to report the problem without saying I’m using Manjaor / archlinux.

No. DO NOT attempt to deceive Arch developers and expect to get away with it. They will find you out and your account will be banned.

1 Like

Just detail your problem to @Yochanan and he can test it on his arch machine.

I have no problem with makepkg, there’s nothing to report.

1 Like

I’m not going to deceive Arch developers.
To reproduce the problem:

  1. mount a usb disk as D:\
  2. on D:\, git clone https://aur.archlinux.org/vscodium-bin.git
  3. makepkg failed because checksum failed
  4. more info
$ makepkg -g 
==> Retrieving sources...
  -> Found vscodium-bin.desktop
  -> Found VSCodium-linux-x64-1.51.1.tar.gz
==> Generating checksums for source files...
sha256sums=('\65e6b053e6d8be61763801312ded64a82cf835d77a6eabe1b9d7eb9e87b2e49b')
sha256sums_x86_64=('\cb2ee41c1b1042d4ebfb5e644ec59ded3fe6ce77c15abcd67078fca52abec442')

Will this be ok?

No.

image

There’s no such thing as D:\ on GNU/Linux.

3 Likes

Post temporarily closed until tomorrow and @followait is taking a break from the forum until then.

Folks are worn and tired, so this is an official break. See ya tomorrow! :wave:

mounting

When thunar automounts a device it uses gvfs.

gvfs mount a device using the device label as path and if no label it mount using partition’s UUID.

When your devices is labelled like this - you are effectively escaping the path character as a literal char

which then makes the system understand the path as aaa/D:/aur/ which of course doesn’t exit because it actually contain a backslash too.

Since everything is a file - you can without risc play with creating folders and files with or without escaped characters - and you will find how Linux behaves different than Windows.

makepkg

There is no problem with makepkg - it does what it is supposed to.

The problem is the name/label of your stick’s partition. Change the label and problem goes away.

sudo e2label /dev/sdy1 'd-drive'

experiment

Open a terminal and create a temp folder and cd into the folder (my prompt looks like this ➜ followed by the current folder)

➜  ~ mkdir temp
➜  ~ cd temp

Now type in mkdir D:\ and press Enter - note what happens

➜  temp mkdir D:\ 
> 

As you have a backslash as the last char before Enter - the system expects more - indicated by the gt sign - so press enter one more time.

Repeat the above - this time type E:\ Enter - press f Enter

➜  temp mkdir E:\
> f                  
➜  temp 

Now list the content

➜  temp ls
D:  E:f

Now you have two folders - but they have no \ - because the backslash is an escape character in Linux.

Now try to create a folder containing a backslash and list the content

➜  temp mkdir G:\\
➜  temp ls
D:   E:f  'G:\'

now lets create a sub folder inside one of our folders

➜  temp mkdir D:\/aur
➜  temp ls D:
aur

one more time with E:f

➜  temp mkdir E:f/aur   
➜  temp ls E:f
aur

now a third time with G:\

➜  temp mkdir G:\/aur
mkdir: cannot create directory ‘G:/aur’: No such file or directory

Ups - this is not possible - obvious the folder exist - so what is happening?

➜  temp ls
D:   E:f  'G:\'

The escape char is happening - let’s try one more time

➜  temp mkdir G:\\/aur
➜  temp ls G:\ 
> 
zsh: correct 'G:' to 'G:\' [nyae]? n
ls: cannot access 'G:': No such file or directory

Ups - lets list it again

➜  temp ls G:\\
aur

Can you see the pattern here? Let’s take a look at your initial problem - the folder structure

aaa/D:\/aur/

The mountpoint is only containing one backslash and following our experiment - for the shell to be able to navigate that specific path you would need it to look like this aaa/D:\\/aur/.

Now you can argue it is bug - but I don’t see like that - I see your label is containing an - for a Linux system - illegal char sequence.

4 Likes