Package Details: octopi 0.16.2-1

Git Clone URL: https://aur.archlinux.org/octopi.git (read-only, click to copy)
Package Base: octopi
Description: A powerful Pacman frontend using Qt libs
Upstream URL: https://tintaescura.com/projects/octopi
Licenses: GPL-2.0-or-later
Conflicts: octopi-notifier
Provides: octopi-cachecleaner, octopi-notifier, octopi-repoeditor
Submitter: ImNtReal
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 1590
Popularity: 32.51
First Submitted: 2013-09-03 23:42 (UTC)
Last Updated: 2024-12-13 02:40 (UTC)

Dependencies (17)

Required by (0)

Sources (1)

Latest Comments

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

prezdev commented on 2024-04-02 01:20 (UTC)

if you have a PKGDEST error, yay -Scc and ready to update.

Swipe commented on 2024-03-31 07:39 (UTC)

Delete the Octopi package cache dir from your AUR cache to resolve the "could not find PKGDEST" error.

fifi_fifito commented on 2024-03-30 18:00 (UTC)

could not find PKGDEST for: octopi-notifier-qt5 PAKtC

raindog1975 commented on 2024-03-27 19:25 (UTC)

@yochananmarqos Thank you. Everything works fine now (for a moment I thought I'm gonna have to use ... pamac)

yochananmarqos commented on 2024-03-27 19:02 (UTC)

@raindog1975: Oops, fixed.

raindog1975 commented on 2024-03-27 18:53 (UTC)

buid fails at:

"In file included from src/propertiestabwidget.cpp:25: src/termwidget.h:27:10: fatal error: qtermwidget5/qtermwidget.h: No such file or directory 27 | #include "qtermwidget5/qtermwidget.h" | ^~~~ compilation terminated. make: *** [Makefile:858: build/propertiestabwidget.o] Error 1 make: *** Waiting for unfinished jobs.... ==> ERROR: A failure occurred in build(). Aborting... "

xiota commented on 2024-03-27 01:45 (UTC) (edited on 2024-03-27 10:41 (UTC) by xiota)

@yochananmarqos Package appears to be in good hands. I will test in clean chroot after it has been switched to split packaging. There is no need to add me as comaintainer (unless you don't intend to continue maintaining it).

yochananmarqos commented on 2024-03-27 00:07 (UTC)

@xiota or anyone else: Let me know if you would like to be a Co-Maintainer for this package. I adopted them to make a few corrections and create a split package (pending).

niobium93 commented on 2024-03-24 15:05 (UTC)

Also, the reason arch4edu fails to build the x86_64 package seems to be because it mistakenly uses it's aarch64 alpm_octopi_utils package as a builddep. The reason is the same - arch=('any') in alpm_octopi_utils. See log here. Notable parts:

ldconfig: /usr/lib/libalpm_octopi_utils.so is for unknown machine 183.
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /lib/../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: cannot find -lalpm_octopi_utils: No such file or directory
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /lib/../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../libalpm_octopi_utils.so when searching for -lalpm_octopi_utils
/usr/bin/ld: skipping incompatible /usr/lib/libalpm_octopi_utils.so when searching for -lalpm_octopi_utils

niobium93 commented on 2024-03-24 14:39 (UTC)

Please stop using arch=('any') and instead provide an actual list of architectures like arch=('i686' 'x86_64' 'arm' 'armv6h' 'armv7h' 'aarch64'). Using any seems to cause some repositories like arch4edu to provide their aarch64 build to x86_64 users when the x86_64 build fails. This is because arch=('any') is only meant to be used in cases where the built package itself is architecture independent, while this package obviously isn't. This problem also isn't present in the upstream PKGBUILD.