[SOLVED] md5sum fails with pacaur, but not with makepkg

gps1539 · 2016-09-16 22:38:15

I just updated my package stock_quote.

After I pushed it, I tested that it installs with pacaur and it failed the md5sum. I recheck, pushed once more and pacaur fails again. I tried on a 2nd system and pacaur also fails to install. However If I download the snapshot from aur, untar it and run makepkg -sir it all works and installs OK, so the md5sum is fine.

Is there anything I could be doing to break this our more likely a issue with pacaur?

Last edited by gps1539 (2016-09-20 06:23:10)

ewaller · 2016-09-16 22:58:22

Pacaur -S stock_quote

worked fine here.

Moving to AUR issues

Alad · 2016-09-16 23:03:53

I see several md5sums changes in the .SRCINFO file without an according change in pkgrel. Remove the cached build directory and try again.

gps1539 · 2016-09-17 21:06:33

Thanks for the replies, alas I'm still missing something here

I deleted my build directory and pulled from git

git clone ssh://aur@aur.archlinux.org/stock_quote.git
vi PKGBUILD (pkgrel=1)
mksrcinfo
git add PKGBUILD .SRCINFO
git commit -m 'fixing md5sum'
git push

pacaur -S stock_quote
.
.
AUR Packages (1) stock_quote-0.7.1-1
.
.
==> Validating source files with md5sums...
stock_quote.py ... FAILED

-----------
If I manually wget the source in PKGBUILD it works
wget https://raw.githubusercontent.com/gps15 … k_quote.py
md5sum stock_quote.py
c773481d8a60dc65664e5ab2ae55f119 stock_quote.py

WorMzy · 2016-09-17 21:16:15

What happens between these two?

pacaur -S stock_quote
.
.
AUR Packages (1) stock_quote-0.7.1-1

Does pacaur download the PKGBUILD to a clean directory, or does it reuse an older directory?

Aside: you should probably drop mksrcinfo and use 'makepkg --printsrcinfo > .SRCINFO' instead.

Spyhawk · 2016-09-17 21:54:13

Since the source isn't versioned, you likely have an old version in your cache (either AURDEST or SRCDEST). Remove it and try again.
The same issue happens with makepkg and requires to remove the old source manually.

gps1539 · 2016-09-18 19:27:45

WorMzy wrote:

What happens between these two?
pacaur -S stock_quote
.
.
AUR Packages (1) stock_quote-0.7.1-1
Does pacaur download the PKGBUILD to a clean directory, or does it reuse an older directory?
Aside: you should probably drop mksrcinfo and use 'makepkg --printsrcinfo > .SRCINFO' instead.

The full output is

pacaur -S stock_quote
:: Package(s) stock_quote not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...

AUR Packages (1) stock_quote-0.7.1-1
Repo Packages (5) blas-3.6.1-2 cblas-3.6.1-2 lapack-3.6.1-2 python-colorama-0.3.7-1 python-numpy-1.11.1-1

Repo Download Size: 0.00 MiB
Repo Installed Size: 20.00 MiB

:: Proceed with installation? [Y/n]

:: Retrieving package(s)...
:: stock_quote build files are up-to-date -- skipping
:: Checking stock_quote integrity...
==> Making package: stock_quote 0.7.1-1 (Sun Sep 18 12:19:24 PDT 2016)
==> Retrieving sources...
-> Found stock_quote.py
==> Validating source files with md5sums...
stock_quote.py ... FAILED
==> ERROR: One or more files did not pass the validity check!
:: failed to verify stock_quote integrity

I also found an md5sums validation issue with the hip-chat client
Both hip-chat and my package installed fine with burgaur

I think pacaur downloads to /tmp/pacaurtmp-username/
Deleting that dir and trying again didn't solve anything.

running pacaur -Scc, also didn't solve this.

gps1539 · 2016-09-18 19:28:56

Spyhawk wrote:

Since the source isn't versioned, you likely have an old version in your cache (either AURDEST or SRCDEST). Remove it and try again.
The same issue happens with makepkg and requires to remove the old source manually.

Thanks
I tried pacaur -Scc but I still get the md5sum issue. Is there another way to clear the caches?

Alad · 2016-09-18 19:29:52

I think pacaur downloads to /tmp/pacaurtmp-username/
Deleting that dir and trying again didn't solve anything.

No, it doesn't, unless you're using an ancient version or changed it yourself. See the man page.

eschwartz · 2016-09-18 22:10:18

pacaur is not responsible for your failure to publish versioned releases of your own upstream software.

As for "another way to clear the caches", why don't you at least try the first way before asking for alternatives?
Spyhawk already told you how -- it is set from the environment variables in the man page you didn't read.

Last edited by eschwartz (2016-09-18 22:10:50)

gps1539 · 2016-09-19 15:58:13

Eschwartz wrote:

pacaur is not responsible for your failure to publish versioned releases of your own upstream software.
As for "another way to clear the caches", why don't you at least try the first way before asking for alternatives?
Spyhawk already told you how -- it is set from the environment variables in the man page you didn't read.

In my defence ;-)

man pacaur

"OPERATIONS
Pacman extension operations
-S, -Ss, -Si, -Sw, -Su, -Qu, -Sc, -Scc
Pacaur wraps all pacman operations and by default extends
respectively its install, search, info, download only, update,
check updates and clean functions to the AUR."

Seems fair for a user to assume pacaur -Scc will clean all caches. Clearly it does not and now I know.

I don't understand why versioning my upstream code would make a difference here as packages like hip-chat (from a commercial vendor) also failed with checksum issues before I deleted ~/.cache/pacaur
BTW. Obviously not a good practice to not version.

Last edited by gps1539 (2016-09-19 16:00:24)

Spyhawk · 2016-09-19 18:38:27

gps1539 wrote:

Seems fair for a user to assume pacaur -Scc will clean all caches. Clearly it does not and now I know.

No, it is not. You are confusing built packages cache (PKGDEST) with source cache (SRCDEST). The latter doesn't exist with pre-repository packages because, obviously, these packages are already built. Then you should have noticed that the pacaur man page indeed say something about SRCDEST cache cleaning, when SRCDEST is set (which it isn't by default, and this is a behavior that any advanced makepkg behavior should know). I am also very dubious at your ability to help yourself seeing how you blatantly ignored the information I gave you to solve this issue, asking to be spoon fed instead. There is no need to hide behind some "In my defence" sentence, this is just plain incompetence and disrespect to people that are helping you, or to the people that took time to write documentation.

On a sidenote, I have become increasingly hostile against 'basic' users over the years, going to specifically state that pacaur is targeted at advanced users only to borderline insulting them on the AUR page (which btw fantastically decreased the amount of crap I had to deal with). Sadly, some regular users have had to unjustly pay the price of my growing hostility (which I am truly sorry for), and I am now disappointed that others have to increasingly deal with this very same crap even on the official forums. This is not the goal of the project I started years ago, and with the increasing popularity of pacaur I am afraid this will only get worst. If I had a single request to the mods, that would be to shoot on sight at these threads. Close them. Bin them. Make it clear that users should be responsible for their own system, and that these pacaur thread are not welcome here.
Lastly, I am sorry for this somewhat off topic rant, but sometimes I feel that deleting this project and seeing all these newbies without their spoon feed tools would be a great fun to watch. Oh boy, yes, that would be fun.

Alad · 2016-09-19 18:47:05

Lastly, I am sorry for this somewhat off topic rant, but sometimes I feel that deleting this project and seeing all these newbies without their spoon feed tools would be a great fun to watch. Oh boy, yes, that would be fun.

That might be effective if archlinuxfr removes yaourt from their profane user repo first ...

Last edited by Alad (2016-09-19 18:48:11)

eschwartz · 2016-09-20 01:50:37

gps1539 wrote:

In my defence ;-)
man pacaur
"OPERATIONS
Pacman extension operations
-S, -Ss, -Si, -Sw, -Su, -Qu, -Sc, -Scc
Pacaur wraps all pacman operations and by default extends
respectively its install, search, info, download only, update,
check updates and clean functions to the AUR."
Seems fair for a user to assume pacaur -Scc will clean all caches. Clearly it does not and now I know.

No, that is not a defense, and if you actually understood how makepkg works then you would never have had this question to begin with.

Or, as Spyhawk said.

And the fact that you failed to read the rest of the pacaur manpage and were therefore not saved from your pre-existing lack of understanding about how makepkg works... is still not a valid defense.

gps1539 wrote:

I don't understand why versioning my upstream code would make a difference here as packages like hip-chat (from a commercial vendor) also failed with checksum issues before I deleted ~/.cache/pacaur
BTW. Obviously not a good practice to not version.

Err, because other packages have the same bad practice of either re-releasing their code with different checksums, or not providing versioned downloads, therefore you should do the same? I am not sure why you believe this is a flattering comparison.

Also, why does it make a difference if it comes from a commercial vendor? If anything, that makes it less likely upstream will behave.

Trilby · 2016-09-20 02:17:20

All else aside, I don't know how this didn't jump out at you:

gps1539 wrote:

:: stock_quote build files are up-to-date -- skipping

I know why it didn't jump out at other people in this thread -at least at first - because you intentionally hid that part of the output.

Pay attention to the output of commands. Post complete output of commands when seeking help.

Spyhawk wrote:

If I had a single request to the mods, that would be to shoot on sight at these threads. Close them. Bin them. Make it clear that users should be responsible for their own system.

Personally I'd love to. But we walk a fine line.

On another note - thanks for your contributions Spyhawk. I've never used pacaur, but it seems to be one of the better aur tools. Sadly 99% of the feedback on software tends to be from the 1% of people who really shouldn't be sitting anywhere near a computer. Don't let it get to you too much.

gps1539 · 2016-09-20 06:16:39

Eschwartz wrote:

gps1539 wrote:
In my defence ;-)
man pacaur
"OPERATIONS
Pacman extension operations
-S, -Ss, -Si, -Sw, -Su, -Qu, -Sc, -Scc
Pacaur wraps all pacman operations and by default extends
respectively its install, search, info, download only, update,
check updates and clean functions to the AUR."
Seems fair for a user to assume pacaur -Scc will clean all caches. Clearly it does not and now I know.
No, that is not a defense, and if you actually understood how makepkg works then you would never have had this question to begin with.
Or, as Spyhawk said.
And the fact that you failed to read the rest of the pacaur manpage and were therefore not saved from your pre-existing lack of understanding about how makepkg works... is still not a valid defense.
gps1539 wrote:
I don't understand why versioning my upstream code would make a difference here as packages like hip-chat (from a commercial vendor) also failed with checksum issues before I deleted ~/.cache/pacaur
BTW. Obviously not a good practice to not version.
Err, because other packages have the same bad practice of either re-releasing their code with different checksums, or not providing versioned downloads, therefore you should do the same? I am not sure why you believe this is a flattering comparison.
Also, why does it make a difference if it comes from a commercial vendor? If anything, that makes it less likely upstream will behave.

How is knowing how makepkg works is relevant when the issue seems to be with pacaur? makepkg worked fine, hint in the title ;-), other aur helpers also seems to work fine. Obvious workaround is to use another helper.

BTW. Logically Mozilla must also be following the same bad practices I do based on this (or maybe there is an issue with pacaur after all)

pacaur -S firefox-beta-bin
:: Package(s) firefox-beta-bin not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...

AUR Packages (1) firefox-beta-bin-49.0-1

:: Proceed with installation? [Y/n]

:: Retrieving package(s)...
:: firefox-beta-bin build files are up-to-date -- skipping
:: Checking firefox-beta-bin integrity...
==> Making package: firefox-beta-bin 49.0-1 (Mon Sep 19 23:08:49 PDT 2016)
==> Retrieving sources...
-> Found firefox-beta-bin.desktop
-> Found firefox-beta-bin-safe.desktop
-> Found firefox-49.0.tar.bz2
==> Validating source files with sha512sums...
firefox-beta-bin.desktop ... Passed
firefox-beta-bin-safe.desktop ... Passed
==> Validating source_x86_64 files with sha512sums...
firefox-49.0.tar.bz2 ... FAILED
==> ERROR: One or more files did not pass the validity check!
:: failed to verify firefox-beta-bin integrity

Last edited by gps1539 (2016-09-20 06:19:42)

gps1539 · 2016-09-20 06:23:36

gps1539 wrote:

Eschwartz wrote:
gps1539 wrote:
In my defence ;-)
man pacaur
"OPERATIONS
Pacman extension operations
-S, -Ss, -Si, -Sw, -Su, -Qu, -Sc, -Scc
Pacaur wraps all pacman operations and by default extends
respectively its install, search, info, download only, update,
check updates and clean functions to the AUR."
Seems fair for a user to assume pacaur -Scc will clean all caches. Clearly it does not and now I know.
No, that is not a defense, and if you actually understood how makepkg works then you would never have had this question to begin with.
Or, as Spyhawk said.
And the fact that you failed to read the rest of the pacaur manpage and were therefore not saved from your pre-existing lack of understanding about how makepkg works... is still not a valid defense.
gps1539 wrote:
I don't understand why versioning my upstream code would make a difference here as packages like hip-chat (from a commercial vendor) also failed with checksum issues before I deleted ~/.cache/pacaur
BTW. Obviously not a good practice to not version.
Err, because other packages have the same bad practice of either re-releasing their code with different checksums, or not providing versioned downloads, therefore you should do the same? I am not sure why you believe this is a flattering comparison.
Also, why does it make a difference if it comes from a commercial vendor? If anything, that makes it less likely upstream will behave.
How is knowing how makepkg works is relevant when the issue seems to be with pacaur? makepkg worked fine, hint in the title ;-), other aur helpers also seems to work fine. Obvious workaround is to use another helper.
BTW. Logically Mozilla must also be following the same bad practices I do based on this (or maybe there is an issue with pacaur after all)
pacaur -S firefox-beta-bin
:: Package(s) firefox-beta-bin not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...
AUR Packages (1) firefox-beta-bin-49.0-1
:: Proceed with installation? [Y/n]
:: Retrieving package(s)...
:: firefox-beta-bin build files are up-to-date -- skipping
:: Checking firefox-beta-bin integrity...
==> Making package: firefox-beta-bin 49.0-1 (Mon Sep 19 23:08:49 PDT 2016)
==> Retrieving sources...
-> Found firefox-beta-bin.desktop
-> Found firefox-beta-bin-safe.desktop
-> Found firefox-49.0.tar.bz2
==> Validating source files with sha512sums...
firefox-beta-bin.desktop ... Passed
firefox-beta-bin-safe.desktop ... Passed
==> Validating source_x86_64 files with sha512sums...
firefox-49.0.tar.bz2 ... FAILED
==> ERROR: One or more files did not pass the validity check!
:: failed to verify firefox-beta-bin integrity

Marked as solved, not a package issue

Trilby · 2016-09-20 11:34:21

FFS, stop quoting huge irrelevant passages - especially when you're just quoting your own previous post with an already huge irrelevant quote.

It's been clear to everyone but you that this is not a packaging issue. It's also not a pacaur issue. Don't blame a tool simply because you haven't bothered to read it's documentation *or* it's output. It's a reading comprehension issue. And the issue is yours.

Closed to prevent further decay of an already pointless thread.

Arch Linux

#1 2016-09-16 22:38:15

[SOLVED] md5sum fails with pacaur, but not with makepkg

#2 2016-09-16 22:58:22

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#3 2016-09-16 23:03:53

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#4 2016-09-17 21:06:33

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#5 2016-09-17 21:16:15

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#6 2016-09-17 21:54:13

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#7 2016-09-18 19:27:45

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#8 2016-09-18 19:28:56

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#9 2016-09-18 19:29:52

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#10 2016-09-18 22:10:18

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#11 2016-09-19 15:58:13

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#12 2016-09-19 18:38:27

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#13 2016-09-19 18:47:05

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#14 2016-09-20 01:50:37

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#15 2016-09-20 02:17:20

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#16 2016-09-20 06:16:39

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#17 2016-09-20 06:23:36

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

#18 2016-09-20 11:34:21

Re: [SOLVED] md5sum fails with pacaur, but not with makepkg

Board footer