erything in bulk might help in the short term
<zyga> mborzecki: but won't change how those things are messy internally when considered along with the rest of osutil
<mborzecki> heh, if you move some of the calls to osutil there's probably going to be some funky import dependencies
<zyga> mborzecki: there already are, much of the code uses osutil already
<zyga> mborzecki: how would you feel about the syscalls package?
<zyga> mborzecki: the public API would be various system calls
<zyga> mborzecki: and a means to mock them all (e.g. with the recorder already present in another package)
<mborzecki> zyga: there's stdlib syscalls already, could those wrappers just live in osutil instead?
<zyga> mborzecki: yes but I'd like them not to
<zyga> osutils is already kind of large
<zyga> but most importantly it already has a number of them and some mocking
<zyga> mborzecki: (mock-this, mock-that, not in general)
<zyga> mborzecki: the idea is that eventually, over time, code could move to use the new pakcage
<zyga> and drop its own mocking
<zyga> mborzecki: this is why I think a new package would help
<zyga> mborzecki: if we move them over to osutil right now you will see a number of separate mocking systems that need to be reconciled
<mborzecki> zyga: osutils/syscalls? with a godoc that 'here lie the syscalls we can mock' ? :)
<zyga> :D
<zyga> mborzecki: that works for me
<zyga> mborzecki: importantly, mock in bulk
<zyga> not one by one
<Chipaca> mborzecki: osutil/sys
<Chipaca> ?
<mborzecki> right, avoids a name clash with stdlib's syscalls
<ogra> would gadgets on top of debian work or is there any special-casing-code that only allows them on ubuntu classic ?
<zyga> Chipaca: would you prefer if this was in osutil/sys?
<zyga> brb
<Chipaca> zyga: i'm not sure quite what you're asking, but, probably? the difference between osutil/syscall[s] and the existing osutil/sys escapes me
<pedronis> zyga: what are the changes to snap-update-ns about ?
<zyga> pedronis: being able to expose the internals for interactive debugging
<pedronis>