pacaur - an AUR helper that minimizes user interaction

leosanvieira · 2017-03-14 19:04:53

Thanks, working as expected now, but still throwing the 'invalid option '"--needed"' message when issuing "pacaur -Qua --devel --needed" but only once now instead of twice. The same behaviour doesn't happen when i issue "pacaur -Qum --devel --needed".

Spyhawk · 2017-03-14 21:29:33

Thx, fixed as well.

leosanvieira · 2017-03-15 12:29:24

Thanks again, everything working as expected now.

leosanvieira · 2017-03-20 21:58:35

@Spyhawk,
Sorry for bothering you again but it seems i may have found another bug, after today's pacaur-git updates, when i issue "pacaur -Qqum --devel --needed" or the "-Qqua" equivalent it shows 2 updates for pacaur-git(my noob guess is that it's showing one update for the bump in version to 4.7.6-1 and another due to the commits in the github repository).
The same behaviour doesn't happen when i issue "pacaur -Qum --devel --needed" or the "-Qua" equivalent.

Last edited by leosanvieira (2017-03-20 21:59:48)

Spyhawk · 2017-03-20 23:42:30

@leosanvieira> Indeed. Great catch, thx! Fixed in master.

Lucki · 2017-03-27 16:03:06

Hi,

is there an equivalent flag to (makepkg) '--cleanbuild' for a clean srcdir before building a package?
Besides the general 'warning: Using existing $srcdir' some packages cannot be build with an old srcdir.

Spyhawk · 2017-03-27 18:47:42

No, build is done by makepkg -od then makepkg -sefc. I might add this -C flag by default if there is no side effect with other packages. Do you have an example of such failing package?
Note pacaur won't support PKGBUILDs that don't build with makepkg -o && makepkg -e, as they usually need to be fixed by their maintainer.

Last edited by Spyhawk (2017-03-27 18:49:14)

Lucki · 2017-03-27 19:10:51

I had an existing srcdir for natron (2.2.3-1 -> 2.2.6-2) and lib32-qt4 (4.8.7-6 -> 4.8.7-10), both failed during the normal update.
Both are building fine after removing the existing srcdir.

Edit:
I'm sorry, but I can't reproduce this. Have you added the -c flag "recently"? Maybe my srcdir was a relict of a manual build…
However, see this as a feature request to prevent something like this. Workflow would be makepkg -Cod & makepkg -sefc.

Last edited by Lucki (2017-03-27 21:59:54)

Spyhawk · 2017-03-31 10:43:51

No, the -c flag has been here for a long time.
Edit: Adding -C is likely to break stuff in some situation. I won't do any change until the issue is correctly identified here, and I cannot reproduce either.

Last edited by Spyhawk (2017-04-03 08:17:00)

zaxdan69 · 2017-06-14 06:32:29

Hello,
I'm using pacaur from a yad script and I want to get only the package names from pacaur' s output which is like this:

ddrescue-gui  1.6.1-3 -> 1.7.1-1    :: aur grisbi  1.0.1-1 -> 1.0.2-1    :: aur pacaur  4.7.8-1 -> 4.7.9-1    :: aur xfce4-dockbarx-plugin 0.4.1-1 -> 0.5-1

like this:

ddrescue-gui 
grisbi
pacaur
xfce4-dockbarx-plugin

Is there any argument to achive this?

Spyhawk · 2017-06-14 09:17:36

--quiet, although you probably want to use `cower -uq` directly.

Last edited by Spyhawk (2017-06-14 09:17:45)

zaxdan69 · 2017-06-14 10:06:06

Thanks a lot, works fine with cower -uq.

Z2h-A6n · 2017-07-26 22:55:40

I'm having trouble building timew-git, seemingly because prepare() is never run by makepkg.

The package builds with no errors using makepkg -od && makepkg -sefc, but fails with an error in package() using pacaur -S timew-git. This error seems to be due to some necessary commands in prepare() which are never run.

I had an old version of the package installed, but I uninstalled with pacaur -Rn and cleaned ~/.cache/pacaur with pacaur -Sc before trying to reinstall.

I think this is related to the problems that Lucki and vishwin were having in posts #633 and #616 respectively.

Any advice is appreciated.

Spyhawk · 2017-07-27 11:31:53

One of the patch doesn't apply correctly:

$ makepkg
...
==> Starting prepare()...
Submodule 'src/libshared' (https://git.tasktools.org/scm/tm/libshared.git) registered for path 'src/libshared'
Cloning into '/tmp/makepkg/timew-git/src/timew/src/libshared'...
done.
Submodule path 'src/libshared': checked out '577c22e4c78dbcb9b0bc605d54650e791f3ff4ba'
patching file doc/holidays/refresh
patching file ext/on-modify.timewarrior
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file ext/on-modify.timewarrior.rej
==> ERROR: A failure occurred in prepare().
    Aborting...

This is an issue with the packaging itself. This has been reported on the AUR page (comments) by some people.

Last edited by Spyhawk (2017-07-27 11:34:52)

Z2h-A6n · 2017-07-27 13:47:18

Thanks for looking into it. I saw the comments on the AUR page before. It looks like I must have fixed the patch manually and forgot about it when I was playing around with makepkg. I get the same results as you if I run makepkg on a fresh clone of the repository, so it looks like a mistake on my part.

eschwartz · 2017-07-27 15:41:58

Spyhawk wrote:

One of the patch doesn't apply correctly:

$ makepkg
...
==> Starting prepare()...
Submodule 'src/libshared' (https://git.tasktools.org/scm/tm/libshared.git) registered for path 'src/libshared'
Cloning into '/tmp/makepkg/timew-git/src/timew/src/libshared'...
done.
Submodule path 'src/libshared': checked out '577c22e4c78dbcb9b0bc605d54650e791f3ff4ba'
patching file doc/holidays/refresh
patching file ext/on-modify.timewarrior
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file ext/on-modify.timewarrior.rej
==> ERROR: A failure occurred in prepare().
    Aborting...

This is an issue with the packaging itself. This has been reported on the AUR page (comments) by some people.

No, this is an issue with pacaur itself, which doesn't respect the error code returned by `makepkg -odC --skipinteg ${makeopts[@]} &>/dev/null`

The fact that the PKGBUILD is broken, does not absolve pacaur of the responsibility to pass that error on to the user after it squelches the stdout/stderr of `makepkg -o` (regarding which, on a personal level I fundamentally want to see all output, no matter what, and dislike pacaur hiding it from me).

Last edited by eschwartz (2017-07-27 15:47:57)

Spyhawk · 2017-07-27 16:27:50

The issue referred to here was obviously the package not compiling.

Eschwartz wrote:

The fact that the PKGBUILD is broken, does not absolve pacaur of the responsibility to pass that error on to the user after it squelches the stdout/stderr of `makepkg -o` (regarding which, on a personal level I fundamentally want to see all output, no matter what, and dislike pacaur hiding it from me).

I do entirely agree with this.

Z2h-A6n · 2017-07-27 18:23:26

Eschwartz wrote:

No, this is an issue with pacaur itself, which doesn't respect the error code returned by `makepkg -odC --skipinteg ${makeopts[@]} &>/dev/null`

Thanks, I think that's what was confusing me. It's more obvious why the installation fails if '&>/dev/null' is removed, or if the line is replaced with:

if [[ $silent - true ]]; then
    makepkg -od --skipinteg ${makeopts[@]} &>/dev/null
else
    makepkg -od --skipinteg ${makeopts[@]}
fi

Spyhawk · 2017-07-27 18:52:42

Yes indeed. I did not try to install this package with pacaur, but tried makepkg directly and didn't realised the error was hidden.

Pacaur works relatively well, but handles unexpected errors notoriously badly, so I'm not entirely surprised (though it's less worst than a few months ago). This particular behavior is easy to fix, but there is also room for improvements in quite lot of other part of the code too.

eschwartz · 2017-09-03 02:51:21

https://github.com/rmarquis/pacaur/comm … 9aa69e9b6c
Thanks for not hiding the prepare() output, but I think properly any package which fails -od should also register as an errmakepkg and abort right then and there.

...

Can we please discuss your reasons for not fixing this bug: https://github.com/rmarquis/pacaur/issues/564 ???

Because it is getting to be quite annoying when uninformed pacaur users spam package comments and pick fights in #archlinux-aur and the aur-requests mailing list and this BBS... because they don't realize that makepkg works fine and pacaur doesn't.

Alad · 2017-09-03 09:38:40

As I mentioned on IRC, it should be easy enough to use /var/tmp as intermediary storage for packages to get the correct names for pacman -U, rather than rely on an exact matching of .SRCINFO. A simple regex match then suffices to install the correct split package, and you can move back the build products to $AURDEST afterwards for persistent storage.

I did something similar with aurbuild to get the correct package names for repo-add since the full information is not available from makepkg --packagelist: (cf. https://github.com/rmarquis/pacaur/issu … -290906331)

https://github.com/AladW/aurutils/blob/ … #L143-L150

That also removes the need to loop over extensions as done here:

https://github.com/rmarquis/pacaur/blob … caur#L1759

Last edited by Alad (2017-09-03 09:41:06)

Spyhawk · 2017-09-04 05:44:17

Eschwartz wrote:

Thanks for not hiding the prepare() output, but I think properly any package which fails -od should also register as an errmakepkg and abort right then and there.

Right, oversight from my side.

Eschwartz wrote:

Can we please discuss your reasons for not fixing this bug: https://github.com/rmarquis/pacaur/issues/564 ???
Because it is getting to be quite annoying when uninformed pacaur users spam package comments and pick fights in #archlinux-aur and the aur-requests mailing list and this BBS... because they don't realize that makepkg works fine and pacaur doesn't.

Because I do not consider it a bug. Consider it as design decision following the unfortunetaly removal of the --pkg flag in pacman 5: instead of adding dirty workarounds for the provided info detected as incorrect, everything that can be fixed upstream easily should be fixed upstream.

Incidentally, I also consider bailing out when a discrepancy is detected the lesser of two evils. Lot of efforts and thoughts went into the design of .SRCINFO file to provide reliable information for the RPC and the AUR interface without parsing. Unfortunately, there is still a loophole as it is very easy for maintainers to forget to update this file, which makes the RPC info not completely reliable. Inciting maintainers to update it correctly improves the overall quality of the info delivered through the RPC for all tools that use it. Through its high popularity, pacaur does lead to an overall better RPC info in the absence of a better upstream solution.

This is useful when the .SRCINFO is completely obsolete, with f.e. missing dependencies. This is annoying when only the pkgrel is actually obsolete. It is more annoying when the maintainer isn't responsive and pitiful when someone like Scimmia comments on the aur-requests and many times on AUR pages without actually being a TU and (let's call a cat a cat) using wording that is less than constructive, leading to users thinking he is a despicable TU unable to write a sentence without the "idiot" word, leading right to a fight in a channel room. Not defending the other guy that overreacted here, but the road was paved towards debacle from all sides.

Maybe I'm wrong to focus on the bigger picture here, and believing that an overall info is better on the longer term than a simple click to orphan a package. Maybe I'm wrong in letting maintainers doing their shit instead of circumventing it. Maybe I'm wrong in not seing If that little annoyance leads to a more rapid solution to the real upstream issue, all the better.

If you don't agree with this point of view, that's fine: you don't have to.

This said, it has been clear to me for quite some time that the hassle of maintaining a popular helper is not worth the time nor the hassle. Without entering into the ugly details, this has become an unpaid job I dislike more than enjoy while I have clearly way too many other problems irl to have the luxury to participate in that shitshow any longer - unless it magically becomes a job that I dislike but that is at least handsomely remunerated. Hey, it's Monday morning and I'm writing about two guy fighting in a chat room. What the hell?.

Current plan consists in very minimal maintenance and zero maintenance while I'm abroad for some time, moving to auracle as soon as practically feasible (in an effort to indirectly diminish the overall usage of cower, that has some unrelated, but annoying issues on Arch server logs), and from there encourage users to move on some similar projects, around auracle or others. In retrospect, this is something that should have been done a long time ago.

eschwartz · 2017-09-04 17:15:15

1) I was unaware that only TUs are allowed to comment on AUR packages and on the aur-requests mailing list. Maybe we should ask someone to restrict who is allowed to reply on aur-requests, similar to how arch-dev-public is restricted. Also, let's submit patches to aurweb to do the same. /s

2) Going out of your way to throw unnecessary errors when there are vastly better ways to find the built filename is very clearly not because you are worried about missing dependencies.
You already trusted the PKGBUILD that late in the game. A more honest check would be to compare the .SRCINFO to the output of makepkg --printsrcinfo and abort on *any* mismatch, and do so after the user okayed the PKGBUILD but before going further. I would respect your decision if that was what you had done.

Only throwing errors when your lousy, inefficient failure to find a decent filename causes errors, and then emitting highly confusing, fact-free error messages, is simply bad code quality on top of terrible rationale.

Spyhawk · 2017-09-06 09:53:06

1/ I have no willingness to deal with unreasonable behavior coming from either stupid users or undiplomatic bug wrangler. Do whatever you want with that information.
2/ I absolutely agree there is room for improvement for error reporting, as this is one of the weakest side of pacaur. This is however *not* the reason of the show you assisted to.

Alad · 2017-09-06 12:56:50

Here's a replacement for makepkg --pkg that doesn't rely on .SRCINFO:

https://paste.xinu.at/fSJ

$ cd python-nikola
$ ./makepkg-pkg -P python-nikola -- -sr --noconfirm
[...]
$ pacman -Qn python-nikola
python-nikola 7.8.9-1
$ pacman -Qn python-nikola-doc
error: package 'python-nikola-doc' was not found
$ ls -l *.tar.xz
-rw-r--r-- 1 user user 1548208 Sep  6 14:55 python-nikola-7.8.9-1-any.pkg.tar.xz
-rw-r--r-- 1 user user   51968 Sep  6 14:55 python-nikola-doc-7.8.9-1-any.pkg.tar.xz

Note that with a /var/tmp folder, makepkg no longer detects if a package is already built. This is both a downside (user does not know a package is already built without further measures, such as find) and an upside (packages with same pkgver+pkgrel can be built without overwriting, see mv -b).

makepkg --packagelist is an alternative to PKGDEST, but this approach is fragile as the package extension is unknown a-priori. See post #646. edit: makepkg --packagelist doesn't run pkgver so it's not an alternative.

Last edited by Alad (2017-09-06 17:32:29)

Arch Linux

#626 2017-03-14 19:04:53

Re: pacaur - an AUR helper that minimizes user interaction

#627 2017-03-14 21:29:33

Re: pacaur - an AUR helper that minimizes user interaction

#628 2017-03-15 12:29:24

Re: pacaur - an AUR helper that minimizes user interaction

#629 2017-03-20 21:58:35

Re: pacaur - an AUR helper that minimizes user interaction

#630 2017-03-20 23:42:30

Re: pacaur - an AUR helper that minimizes user interaction

#631 2017-03-27 16:03:06

Re: pacaur - an AUR helper that minimizes user interaction

#632 2017-03-27 18:47:42

Re: pacaur - an AUR helper that minimizes user interaction

#633 2017-03-27 19:10:51

Re: pacaur - an AUR helper that minimizes user interaction

#634 2017-03-31 10:43:51

Re: pacaur - an AUR helper that minimizes user interaction

#635 2017-06-14 06:32:29

Re: pacaur - an AUR helper that minimizes user interaction

#636 2017-06-14 09:17:36

Re: pacaur - an AUR helper that minimizes user interaction

#637 2017-06-14 10:06:06

Re: pacaur - an AUR helper that minimizes user interaction

#638 2017-07-26 22:55:40

Re: pacaur - an AUR helper that minimizes user interaction

#639 2017-07-27 11:31:53

Re: pacaur - an AUR helper that minimizes user interaction

#640 2017-07-27 13:47:18

Re: pacaur - an AUR helper that minimizes user interaction

#641 2017-07-27 15:41:58

Re: pacaur - an AUR helper that minimizes user interaction

#642 2017-07-27 16:27:50

Re: pacaur - an AUR helper that minimizes user interaction

#643 2017-07-27 18:23:26

Re: pacaur - an AUR helper that minimizes user interaction

#644 2017-07-27 18:52:42

Re: pacaur - an AUR helper that minimizes user interaction

#645 2017-09-03 02:51:21

Re: pacaur - an AUR helper that minimizes user interaction

#646 2017-09-03 09:38:40

Re: pacaur - an AUR helper that minimizes user interaction

#647 2017-09-04 05:44:17

Re: pacaur - an AUR helper that minimizes user interaction

#648 2017-09-04 17:15:15

Re: pacaur - an AUR helper that minimizes user interaction

#649 2017-09-06 09:53:06

Re: pacaur - an AUR helper that minimizes user interaction

#650 2017-09-06 12:56:50

Re: pacaur - an AUR helper that minimizes user interaction

Board footer