Re: DLA 773-1 and DLA 773-2
On Mon, Jan 09, 2017 at 07:52:58PM +0000, Chris Lamb wrote:
> Guido Günther wrote:
>
> > I had the same problem with flake8 in gbp and used
> >
> > flake8 -j1
> >
> > to work around this. I think we can only skip the patch if hitting a
> > EPERM.
>
> I'm a little confused by the mention of flake8 here - the test itself
> is requiring access to the multiprocessing library (+ /dev/shm etc.)
> rather than calling flake8 and that failing AFAICT
Flake8 does the same internally what the test does (using the
multiprocess module):
Traceback (most recent call last):
File "/usr/bin/flake8", line 11, in <module>
load_entry_point('flake8==3.2.1', 'console_scripts', 'flake8')()
File "/usr/lib/python3/dist-packages/flake8/main/cli.py", line 16, in main
app.run(argv)
File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 322, in run
self._run(argv)
File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 305, in _run
self.initialize(argv)
File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 301, in initialize
self.make_file_checker_manager()
File "/usr/lib/python3/dist-packages/flake8/main/application.py", line 227, in make_file_checker_manager
checker_plugins=self.check_plugins,
File "/usr/lib/python3/dist-packages/flake8/checker.py", line 94, in __init__
self.process_queue = multiprocessing.Queue()
File "/usr/lib/python3.5/multiprocessing/context.py", line 101, in Queue
return Queue(maxsize, ctx=self.get_context())
File "/usr/lib/python3.5/multiprocessing/queues.py", line 42, in __init__
self._rlock = ctx.Lock()
File "/usr/lib/python3.5/multiprocessing/context.py", line 66, in Lock
return Lock(ctx=self.get_context())
File "/usr/lib/python3.5/multiprocessing/synchronize.py", line 163, in __init__
SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
File "/usr/lib/python3.5/multiprocessing/synchronize.py", line 60, in __init__
unlink_now)
PermissionError: [Errno 13] Permission denied
This is because in the chroot
$ ls -ld /dev/shm/
drwxr-xr-x 2 root root 40 Dec 18 22:42 /dev/shm/
whereas outside the chroot
$ ls -ld /dev/shm/
drwxrwxrwt 2 root root 280 Jan 9 20:51 /dev/shm/
After a
chmod 1777 /dev/shm/
inside the chroots this passes. I always thought restricting permissions
on /dev/shm in the chroot was intentional but maybe it's just a bug?
> I could, however skip the test on EPERM, but this issue seems like
> more of a buildd admin issue… ?
It's at least consistent in pbuilder chroots as well.
Cheers,
-- Guido
Reply to: