I would like to ask “classic” confinement review for “Open Karaoke Producer” package. It uses python multiprocessing module, that needs to access /dev/shm but due to a unsolved bug/limitation (Python multiprocessing sem_open blocked in strict mode), it is not able to run in strict confinement. As it seems that this bug/limitation will not be solved soon, and all proposed workarounds do not fix this problem, I will need to create this package as classic in order to see it running in snap format.
we really need to figure out a way to get per-snap dev/shm support so that we’re not required to conform to strict naming requirements. @sergiusens you mentioned that layouts will fix this. they don’t. I tried layouts with a snap that cannot be fixed any other way, and it just complained that I’m not allowed to use layouts to mount anything at /dev/shm.
Any news on this? I am receiving emails from build system saying that the package is not accepted. Something I need to adjust on my side? I understand the implications, but as this is a limitation of snap, classic confinement is the only way to get the packages on store on cases like mine by now.
The only thing is that it now shows the following warning (but it is not blocking functionality):
/snap/open-karaoke-producer/24/lib/python3.6/site-packages/joblib/_multiprocessing_helpers.py:38: UserWarning: [Errno 13] Permission denied. joblib will operate in serial mode
warnings.warn('%s. joblib will operate in serial mode' % (e,))
/snap/open-karaoke-producer/24/lib/python3.6/site-packages/numba/npyufunc/parallel.py:243: UserWarning: Could not obtain multiprocessing lock due to OS level error: [Errno 13] Permission denied
A likely cause of this problem is '/dev/shm' is missing orread-only such that necessary semaphores cannot be written.
*** The responsibility of ensuring multiprocessing safe access to this initialization sequence/module import is deferred to the user! ***