Package Details: octopi 0.15.0-4

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
Provides: octopi-cachecleaner, octopi-repoeditor
Submitter: ImNtReal
Maintainer: yochananmarqos
Last Packager: yochananmarqos
Votes: 1423
Popularity: 30.37
First Submitted: 2013-09-03 23:42 (UTC)
Last Updated: 2024-03-31 18:49 (UTC)

Dependencies (14)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 35 Next › Last »

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")

xiota commented on 2024-03-18 22:23 (UTC) (edited on 2024-03-18 22:27 (UTC) by xiota)

Arch Wiki PKGBUILD#Sources

Warning: The downloaded source filename must be unique because the SRCDEST directory can be the same for all packages. For instance, using the version number of the project as a filename potentially conflicts with other projects with the same version number. In this case, the alternative unique filename to be used is provided with the syntax source=('unique_package_name::file_uri'); e.g. source=("$pkgname-$pkgver.tar.gz::https://github.com/coder/program/archive/v$pkgver.tar.gz").

Changing that single line does not break the package because the archive is unpacked and its contents are used for the rest of the build process.