Package Details: himitsu 0.6-1

Git Clone URL: https://aur.archlinux.org/himitsu.git (read-only, click to copy)
Package Base: himitsu
Description: Secret storage manager
Upstream URL: https://himitsustore.org/
Keywords: key keystore password secstore
Licenses: GPL3
Submitter: torresjrjr
Maintainer: torresjrjr
Last Packager: torresjrjr
Votes: 5
Popularity: 0.010135
First Submitted: 2022-06-20 05:28 (UTC)
Last Updated: 2024-01-31 21:11 (UTC)

Dependencies (3)

Sources (2)

Latest Comments

1 2 Next › Last »

torresjrjr commented on 2023-11-12 20:12 (UTC)

TrialInError,

I've updated the PKGBUILD to use hare-git(AUR).

I've notified user fossdd that the himitsu-git(AUR) package is out-of-date, and have sent him an email.

TrialnError commented on 2023-11-12 16:49 (UTC) (edited on 2023-11-12 16:49 (UTC) by TrialnError)

The reason is rather simple. It is still a difference if I compile a stable release with a development snapshot of the dev environment, or if I compile a possible unstable snapshot of the software.
I could have changed the -git to use the tag/commit, but then I can use this. And it avoids possible hassle with programs which add himitsu as a dep.

torresjrjr commented on 2023-11-10 18:12 (UTC)

TrialInError,

If there really is precedent for using alternative -git makedeps, then I shall consider it for himitsu(AUR). Though, the difference here is that, while libucl had (I'm assuming) versioned releases, upstream hare doesn't yet.

The commit chosen for the hare(AUR) PKGBUILD is the latest working commit which builds on the latest working harec(AUR) commit, which is based on the latest versioned release of qbe(AUR).

himitsu 0.4 may build with hare-git(AUR), but then why not use himitsu-git(AUR)? Nonetheless, I see the value, and i'll try to use -git here if I can.

TrialnError commented on 2023-11-09 17:05 (UTC) (edited on 2023-11-09 17:31 (UTC) by TrialnError)

This is in general true. But if there is breakage to avoid or if backporting fixes is to bothersome due to changes, even packages in the repos temporarily used a build from git.
And sometimes it cannot be avoided, like with hikari and libucl-git. Latest release of libucl was 2018, but a newer version was needed. Didn't exist, therefore the -git package as a dep for a non development package. Now it could be reverted back, as there was finally a release.
And qbe kinda reminds me of wlroots :D The back and forth with wlroots and wlroots-git to avoid breakage of the build process...
But well, let's see what happens :)

Edit: Who decided on the commit in the hare PKGBUILD? Just pinpointing to a specific commit is hardly a "stable" release. Nevertheless and just for confirmation himitsu 0.4 builds fine with the -git toolchain :)

torresjrjr commented on 2023-11-09 12:42 (UTC)

TrialInError,

The package name himitsu(AUR) implies makedeps which are non "-git". This is what himitsu-git(AUR) is for. By the way, the maintainer of himitsu-git(AUR) should be alerted that his PKGBUILD file is failing to build, when it should be able to.

As it turns out, upstream himitsu versions 0.3 and 0.4 both don't compile with current hare(AUR). There is no solution other than waiting for a new qbe(AUR), harec(AUR), and hare(AUR) release. A revert or epoch is pointless.

TrialnError commented on 2023-11-09 07:00 (UTC)

What is your reasoning for not changing the makedep?
Of course you can always change the version back. Via revert, or manually (plus epoch). But what would be the gain if there is still the problem Liselotte reported? Or is that resolved?

torresjrjr commented on 2023-11-08 23:33 (UTC)

TrialInError,

I believe changing the hare(AUR) dependency to hare-git(AUR) would be disingenuous.

I'm looking through the Arch Wiki for instruction. Would a revert commit work? Would it be acceptable?

TrialnError commented on 2023-11-08 20:53 (UTC)

I see. Thanks for the explanation.
Interesting problem. But if it's certain, it builds with hare-git, then I would change the makedep to hare-git for the time being. Still leaves the possibility that one gets the right timing to build an incompatible hare-git, but well.. One cannot have everything :D

torresjrjr commented on 2023-11-08 19:44 (UTC)

TrialInError,

I believe I've made an error in my decision to upgrade this package.

himitsu 0.4 requires a recent hare toolchain from the hare, harec, and qbe master branches. However, hare(AUR)'s latest release is too old, and a new release cannot be made, since hare(AUR) depends on harec(AUR), which depends on qbe(AUR), which does not have a recent release.

https://c9x.me/git/qbe.git

himitsu 0.4 theoretically should build with hare-git(AUR).

Perhaps I should have waited for a new release from qbe, harec, and hare. I'm not sure what the correct protocol is from here.

TrialnError commented on 2023-11-08 19:12 (UTC)

With what hare version did you compile this? If I try to build 0.4 I get the following error:

/tmp/makepkg/himitsu/src/himitsu-0.4/secstore/secstore.ha:71:29: error: Unknown object 'os::BUFSZ'
71 |        let wbuf: [os::BUFSZ]u8 = [0...];
/tmp/makepkg/himitsu/src/himitsu-0.4/secstore/secstore.ha:71:12: error: Initializer is not assignable to binding type
let wbuf: [os::BUFSZ]u8 = [0...];
/tmp/makepkg/himitsu/src/himitsu-0.4/secstore/secstore.ha:71:12: error: Initializer is not assignable to binding type
71 |        let wbuf: [os::BUFSZ]u8 = [0...];
Error: harec: exited with status 1
hare build: build failed

(slightly mangled and incomplete output, because something went wrong with the escape sequences and the build process printed over the complete terminal window)