Arch Linux User Repository

hi @ilovemikael i just add note here and seems solution is on upstream https://github.com/slicer69/doas/issues/103#issuecomment-1207275942

about doas: Operation not permitted solution is in right way cos "The root user doesn't have any entries in your doas.conf file, so no actions by root are allowed." a correct behaviour from doas..

:tumpsup

@itamarperdomo (belated) hi, you are indeed correct in asserting that doas can't be run as root, which is kinda interesting, i guess. thanks for pointing that out.

however, since this is an issue with opendoas itself and not the shim, i am left curious as to what the intent of your comment is; there is obviously already a great deal of sudo functionality missing from this script, so this error on top of that doesn't make much of a difference. i'm impressed you even thought to check if sudo could be run as root, as it seems redundant, and i have no clue why someone would even want to do that, but it is still an error nonetheless.

do you suggest changing this package to facilitate running as root, or are you just leaving a friendly pointer? perhaps there's an instance where running as root is useful that i'm unaware of; if so, i'd love to know.

Hi, suddendly noted that doas does not allow root execution.. i mean duso allows root and non-root users to execute no matter if root is already root

Instead doas just raised an doas: Operation not permitted if root user try to run sudo using doas-sudo-shim, to bypass this inclusivelly user root must be into the doas.conf file

@ilovemikael

@oech3 did send me a merge request, then rescinded it before I could respond, saying they would contact you about this package, I guess. I wouldn't mind merging, I ended up making my package because I wasn't sure if either upstream or this project was still active.

And yeah, despite yay supporting doas, it only uses it if sudo entirely does not exist on the system, whereas I want to keep a shim for sudo for compatibility with random software. As such I have to work around yay running sudo -v before every transaction (I assume to refresh persistent authenticated sessions)

can u guys pls leave comments before making random deletion/merge requests? ...would be kinda polite imo ¯\(ツ)/¯

@oech3 I'm not even necessarily opposed to merging with the -v fork, given that the two packages are redundant aside from the flag; this package exists solely (at least within the context of when doas-sudo-shim was still on the AUR) to retain makepkg compatibility. I don't use yay, so -v is useless for me, but a few extra bytes won't hurt if it results in a few more happy people. Additionally, perhaps informing Enovale of the potential merger would be prudent to ensure everyone's on the same page (though that may already be true, and I'm simply unaware).

In your deletion request, you said the -k flag isn't utile since most aur assistants have config to swap sudo (also mentioned this shim breaking devtools, which I haven't experienced, but if that's true I'd love an elaboration); that may well be the case, but as a paru user, -k is an unnecessary evil as it still calls good ol' pacman -U once finishing building a package (which is where the flag is needed). My configuration is devised to never need to enter a password for root, so -k is totally useless to me in actuality, and it'd be great if there were an option for alpm to ignore its presence for those like myself, but unfortunately, that isn't the reality (as of yet!).

Mayhaps omitting both flags from the pkgbase and reverting to doas-sudo-shim (while keeping the flags in the script, just not the title) could be handy in reducing confusion, ambiguity, and clutter, but then again, that could be a bit too crazy; regardless, if you reply and we can all reach a consensus, then I'd be fine making another merge/deletion request (if you'd like).

hey @luluco250! ~ i'm so so sorry for the latency in response -- been having some technical difficulties regarding mounting the disk on my main laptop after a kernel upgrade (though downgrading from mainline to stable doesn't seem have helped) and not even journalctl can save me as no logs can be written to an unmounted disk (and it isn't even a hardware issue -- arch-chrooting works perfectly!; very befuddling indeed); honestly considering just switching my system to openrc if i can't figure this out soon...

Digression aside (mostly want to provide an explanation for any possibly curious users of my few packages, given they can endure about two clicks of rabbit hole exploration (very vain, i know)), I fixed the forced dependency; it is certainly unnecessary to require building documentation for literally a single shell script which can easily be moved to bin without even needing a package, especially when it's a single page, which itself is outdated too (no description of -k)! I've been meaning to amend that manpage for a while, just haven't prioritized learning asciidoctor as of yet, though it does seem well-designed from what I skimmed through in their docs (arch manpages are generated with asciidoc (sans the -tor), a fork of the doctah), and plus ruby is neat!! (know very little about it currently, hope to change that someday).

Either way, it sucks to have an arbitrary dependency shoved down your throat, and, when possible, it is nice to avoid cluttering the aur with more -minimal packages (guilty as charged), so thanks for your patience, and please let me know if something isn't working right!

also @Frestein, that bug has been remedied -- letting you know incase you hadn't seen yet =)

Bonus for @itamarperdomo w.r.t. zip-->targz conversion: cp fclivaz42-master.zip fclivaz42-master.tar.gz, incredibly, preserves the archive contents perfectly; I don't handle zips too often and thus can't speak on the witchcraft powering its archiving methods, but am aware that filename extensions such as xip, apk, and xpi are in practice functional zip equivalents with suffixes changed, a purely nominal alteration (though xips are signed), so perhaps a similar process is occurring with targz?

Regardless, tar is so unanimous on linux relative to zip that it was my mistake to have even used the zip for the source to begin with; i must have not been paying attention when copying the github link (in fact, although it may be imagined, i recall reading somewhere in the wiki/man for pkgbuilds that targz should be the default for sources, at least it is in makepkg.conf even if i'm a schizophreniform).

NVM... IT'S JUST THAT LIBARCHIVE SUPPORTS GZ, ZIP, AND TAR -- BSDTAR (WHICH ARCH USES) CAN READ/WRITE ZIPS -- GNU TAR/GZIP CAN'T.

The package build process for this is pretty slow and pulls a lot of Ruby dependencies just to build the manual page, while the core functionality is a simple Bash script.

Would it be possible to just skip on generating it?

I had a fork of the original package called doas-sudo-shim-minimal but it got merged with the original at some point and I lost track of where that whole package went, noticing it got deleted recently.

It really is a pain to make this package when bootstrapping slower systems or ones with slower internet connections.

I wouldn't mind creating a fork of this package for that purpose, but I would like to avoid risking it just getting deleted/merged again for being a "subset package".

/home/frestein/.cache/yay/doas-sudo-shim-k/PKGBUILD: line 21: cd: doas-sudo-shim-fclivaz42-master: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: doas-sudo-shim-k-exit status 4