Replacing linked source in new version with package-bundled one instead produces confusing error on pacaur update

[Det87]

If replacing an external source=() item with a bundled one in an update (either pkgrel or pkgver) (e.g. what just happened with google-chrome: https://aur.archlinux.org/packages/google-chrome/), Pacaur fails the new build due to the conflicting item in the cache (~/.cache/pacaur/pkgname/file) with a confusing error.

At the very end of the build:

:: Installing X package(s)...
:: X package(s) failed to install.
:: ensure package version does not mismatch between .SRCINFO and PKGBUILD
:: ensure package name has a VCS suffix if this is a devel package

[rmarquis]

I don't think this is directly related. The issue you describe sounds like a source file was downloaded by makepkg and then the md5sum was changed later on, but I'd expect the md5sum check to catch the error early on.

Rather, it seems something else went wrong while building the package, and it failed for some reason without stopping the process somehow (before pacman -U installation fails). Unless the user that encountered this issue could provide a debug output, I'm afraid I won't be able to find out what went wrong here.

[Det87]

Well I tried the same with jre8 before reporting and could reproduce successfully (https://aur.archlinux.org/cgit/aur.git/log/?h=jre8).

Do you have a "test" package (0 votes) at hand? 0 vote packages can also be automatically removed without bothering AML, at least within some interval (used to be 1 hour) if done within 24 hours (aurweb.git: Allow users to delete their own packages -> config.proto).

[rmarquis]

If you were able to reproduce with jre8, then there is definitely something that went under my radar.

I don't have such package, but if there is a way to test this without bothering anybody I'll just try to upload a dummy package. Thanks for notifying, I'll have a look asap.

[colemickens]

I'm getting this same behavior with visual-studio-code-insiders which is similar to google-chrome in that it lacks the VCS suffix due to being a package for a binary artifact.

I've tried purging ~/.cache/pacaur/visual-studio-code-insiders before running the pacaur command again, but surprisingly, that didn't help. Also, this is only happening on one of my machines (the other machine had been using a different helper until a couple hours ago, so it might be a factor)

[rmarquis]

I've unfortunately not had time to look further in this issue, and do not have access to an UNIX system for the time being. Please bear my slowness - I'll handle this in a few weeks.

[colemickens]

I can try to help provide more information, as I continue to have three machines exhibiting two different behaviors when trying to update visual-studio-code-insiders and firefox-nightly (both lacking VCS suffixes).

However, I've tried clearing ~/.cache/pacaur repeatedly, with no luck. I'm not sure what other state pacaur/pacman store, so I'm not sure what else to try to clear out to normalize behavior between my machines at least. I'm guessing whatever difference is in place is related to this big.

Let me know if there's other places/things to check... Right now I'm just resorting to running pacaur, sniffing the exit code and retrying with yaourt, which is rather inelegant.

[Det87]

Not sure for example you're running the same thing, and not e.g. an alias?

[colemickens]

Yes, I'm very sure. I use a synced dotfiles and a zsh function I wrote that just invokes pacaur -Syu. The executed steps are the same in both places, same command-line to pacaur confirmed with ps, etc...

[Det87]

Are your pacaur.conf, makepkg.conf and perhaps pacman.conf identical enough?

[colemickens]

I apologize, after closer examination, the reported issue is happening on all of my machines. I had a slight config difference inside my scripts that was causing the failure to be silent on one of my machines.

Now it just looks like AUR is too picky about VCS suffixes for other packages with dynamic versions from Git...

[rmarquis]

Sorry for the delay, I'm still on the move and unable to have a closer look at this issue at the moment. However, this might be related to #507.

@colemickens I guess providing debug output might be useful.

[colemickens]

I suspect it is indeed related to #507. I keep seeing this pop up in more places, especially for visual-studio-code-insiders: https://aur.archlinux.org/packages/visual-studio-code-insiders/

The result of: pacaur -S visual-studio-code-insiders --noconfirm --debug &> output.txt is: output.txt

[rmarquis]

@Det87 My apologies for the rather long delay. I was able to reproduce the issue with a dummy package. It triggers under the following conditions:

• an external source is changed to a local source in the PKGBUILD
• pkgver or pkgrel are updated, with the according .SRCINFO update
• SRCDEST is not enabled in makepkg.conf
• users update the package (new install are unaffected)

Without SRCDEST defined, the external sources files are downloaded in the git directory. When the changes to a local source instead occurs, git pull fails:

:: Retrieving package(s)...
error: The following untracked working tree files would be overwritten by merge:
        eula_text.html
Please move or remove them before you merge.
Aborting

The build with the previous PKGBUILD and older source files still happen, and the install version mismatch error message eventually triggers (as the older pkgver and pkgrel are used instead).

Incidentally, an additional check for git errors was added just a couple of hours ago as part of #755. Now, the process will abort and this issue should not happen anymore :

:: Retrieving package(s)...
error: The following untracked working tree files would be overwritten by merge:
        eula_text.html
Please move or remove them before you merge.
Aborting
:: failed to retrieve helper-debug package

@colemickens The issue with visual-studio-code-insiders is unrelated to this very issue. It is somewhat related to #507 (though it is an edge case), but first and formost it fails because of the way pacaur relies on the RPC information. Since this is a rather multi layered issue, I'll open a new dedicated ticket shortly to track it.

Closing now, and thanks again to both of you for your patience.

[Det87]

@rmarquis really, you're allowed breaks from a voluntary project you're doing such a great job on as-is. God bless.

[colemickens]

@rmarquis Yes, thank you for the time you've spent on this. I was actually thinking about it aproximately 15 minutes before you replied.