oech3 commented in [0] about this thread, because he doesn't know how to response to the thread, I copied this comment here with my replies edited to fix plain-text email style:
> I don't know how to response to PRQ#73348 . I think you need to create an account on https://lists.archlinux.org. Then you need to subscribe to aur-requests@lists.archlinux.org mailing list on the web ui. Then you need to reply to your PRQ#73348 email in your email client with `To:` field recipient as aur-requests@lists.archlinux.org. > I'm affraiding that AUR is filled by launcher with sandboxed setting. I just searched AUR with keyword "firejail". Right now there's only zoom-firejail and linuxqq-firejail two launchers with firejail. I don't think your statement "AUR is filled by launcher with sandboxed setting" is true, at least right now for firejail there's only two packages. > If there is a no app specific workaround without relying on upstream's > fix, this package does nothing. I'm not sure what you mean in this sentence. This package successfully sandboxed zoom with firejail on my laptop running X11 with dwm. I know at least zoom is running in its sandbox directories, because after I record videos on zoom, I need to run `firejail --list` to get the pid of firejail, then run something like `firejail --get=95448 /home/xyz/Documents/Zoom/.../video1111111111.mp4` to move the recorded video file from sandbox directory to my actual filesystem. This level of sandbox is not perfect but good enough for me. This package does things. If you are talking about the outdated workaround in this comment [1]. If you read the related issue [2] carefully, you will realize the issue [2] is not issue of zoom, it is the issue of NVIDIA GPU, all software somehow using NVIDIA GPU is somehow affected by it. And this NVIDIA GPU issue is fixed in this pull request [3]. There's no app specific workaround because this is not app specific bug. And about upstream fix, I don't understand what you mean, we all rely on upstream fix for all software we use, don't we? > The method to override Exec= of system's desktop entries by home > directory should be introduced at somewhere of Arch wiki (I will do it > if needed). I think you mean this should be included in Arch Wiki instead of being a package. But the thing is this package just works for me. And if this package got deleted, user who want to use it on their new computer will be surprised that this package is gone. User will be forced to copy zoom-firejail script and ZoomFirejail.desktop file to their new computer somehow, either manually by typing commands, using some dotfile or configuration management software (infrastructure as code) like Ansible, or use custom local Arch repositories, and all of these ways all sucks in their own way, none of them is as simple and elegant as just install zoom-firejail package from AUR. Not deleting zoom-firejail package also has the benefit of having a place (comment section) for people to fix and discuss future issues related to running zoom in firejail. I believe zoom-firejail should not be deleted. Another simple AUR package is dashbinsh [4], dashbinsh is extremely useful to me, and a lot of pople relied on that package for a working system that use dash instead of bash for /bin/sh. Do you @oech3 think we should delete that package? Me personally I don't think we should delete simple packages just because they are too simple and *seems* to be more fit on Arch wiki instead, especially users are already using the package for many years. [0] https://aur.archlinux.org/packages/zoom-firejail#comment-1024842 [1] https://aur.archlinux.org/packages/zoom-firejail#comment-978751 [2] https://github.com/netblue30/firejail/issues/6372 [3] https://github.com/netblue30/firejail/pull/6387 [4] https://aur.archlinux.org/packages/dashbinsh
signature.asc
Description: PGP signature
