Package Details: octopi 0.16.2-2

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://github.com/aarnt/octopi
Licenses: GPL-2.0-or-later
Conflicts: alpm_octopi_utils
Submitter: ImNtReal
Maintainer: xiota
Last Packager: xiota
Votes: 1601
Popularity: 35.01
First Submitted: 2013-09-03 23:42 (UTC)
Last Updated: 2024-12-24 03:40 (UTC)

Dependencies (20)

Required by (0)

Sources (2)

Latest Comments

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

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.

tallero commented on 2024-03-19 13:19 (UTC) (edited on 2024-03-19 13:26 (UTC) by tallero)

@matmoul: me too have received an angry orphan request from xiota yesterday night.

He has been featured on my livestreamed work session on X.

I described him as a kind person, even if the lack of details about his complaints were unusual i think.

Or Xiota was the guy I had to discuss for a week to correctly split gcr 3 and 4 with a very bad attitude and who also insulted me?

I don't remember; for sure by the tone of his replied I have thought he was a sockpuppet troll used to tactically hanger people.

If you are not familiar with toxic sockpuppets made to create tensions; we can make one together so I'll show you this works.

But probably is not him, lets wait for a confirm.

xiota commented on 2024-03-19 00:03 (UTC)

@matmoul Upstream uses git source. The problem is with changes you made that differ from upstream source.

matmoul commented on 2024-03-18 23:58 (UTC)

@xiota I remain faithful to the upstream...
You can provide a PR which, if accepted, will be pulled here.
https://github.com/aarnt/octopi/blob/master/PKGBUILD

xiota commented on 2024-03-18 23:52 (UTC) (edited on 2024-03-19 00:01 (UTC) by xiota)

@matmoul I am not interested in helping you reproduce issues caused by misnamed files. The problems are well known, and Arch Wiki provides the solution.

Do you have any intention of fixing this package or allowing someone else, such as yochananmarqos, to do so?

Export SRCDEST with it set to a path, such as /tmp. Then touch "$SRCDEST/octopi" or mkdir -p "$SRCDEST/octopi". Build the package with makepkg.

With touch (simulates out of date source):

==> Retrieving sources...
  -> Found octopi
==> Validating source files with sha256sums...
    octopi ... FAILED
==> ERROR: One or more files did not pass the validity check!

With mkdir (simulates folder created by another package, such as aur/octopi-git):

==> Retrieving sources...
  -> Downloading octopi...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0
100 1518k    0 1518k    0     0   254k      0 --:--:--  0:00:05 --:--:--  254k
==> Validating source files with sha256sums...
    octopi ... NOT FOUND
==> ERROR: One or more files did not pass the validity check!

matmoul commented on 2024-03-18 23:34 (UTC)

@xiota That wasn't the question, I just want to reproduce your issue to understand it.

xiota commented on 2024-03-18 23:26 (UTC)

@matmoul The problem is you are not following general, wide-spread best practices, namely, saving source files with version and extension.

The format for entries in the source array is: filename::url

The folder that is extracted depends on the contents of the archive. Upstream could change it and force you to rewrite the PKGBUILD.

I usually don't like split packages, but in this case, it is far better than separate packages that attempt to use (or redownload) the same source and depend on each other.

I suggest adding yochananmarqos as comaintainer to the associated packages so he can fix them. He needs to be added to all of them so he can rename the conflicting packages while deletion is pending. (I would also be able to, but yochananmarqos has already created an alternate PKGBUILD.)

matmoul commented on 2024-03-18 23:06 (UTC) (edited on 2024-03-18 23:07 (UTC) by matmoul)

@xiota I've really tested the line and it work and the line from @yochananmarqos to ...

It seems I haven't figured out all of the source prefix yet.
I thought this would impact the cd in the functions.

But that doesn't explain to me why you're having this problem.
I used tryzen for a long time before using my internal solution without ever encountering a problem.

yochananmarqos commented on 2024-03-18 22:28 (UTC)

...and even better, how about an improved split PKGBUILD? (paste expires in one year)

yochananmarqos commented on 2024-03-18 22:24 (UTC)

...or, y'know... KISS and don't use unnecessary variables:

source=("${pkgname}-${pkgver}.tar.gz::https://github.com/aarnt/octopi/archive/v${pkgver}.tar.gz")

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