On 12/8/19 1:46 pm, Eli Schwartz wrote:
> Not all compression types can be detected in the seccomp sandbox, so we
> need to disable it. This requires either configuring makepkg to know the
> sandbox is available, or checking for file >= 5.38 in which the sandbox
> option is a no-op even when
On 08/12/19 at 02:15pm, AstroSnail via pacman-dev wrote:
> Hi,
>
> I think I found a bug in pacman.
>
> When a package remove operation can't be satisfied, pacman prints an
> error, describes what went wrong, and does nothing:
> $ sudo pacman -R linux-api-headers
> checking
On 8/12/19 10:15 AM, AstroSnail via pacman-dev wrote:
> Hi,
>
> I think I found a bug in pacman.
>
> When a package remove operation can't be satisfied, pacman prints an
> error, describes what went wrong, and does nothing:
> $ sudo pacman -R linux-api-headers
> checking dependencies...
On August 12, 2019 12:45:40 PM EDT, Jonathon Fernyhough
wrote:
> By default, $HOME is that of the build user. This is usually not a
> problem in ephemeral build containers/chroots but can allow some files
> to escape into the filesystem where `makepkg` is run outside of a
> chroot.
>
> There
On August 12, 2019 6:45:40 PM GMT+02:00, Jonathon Fernyhough
wrote:
>By default, $HOME is that of the build user. This is usually not a
>problem in ephemeral build containers/chroots but can allow some files
>to escape into the filesystem where `makepkg` is run outside of a
>chroot.
>
>There can
By default, $HOME is that of the build user. This is usually not a
problem in ephemeral build containers/chroots but can allow some files
to escape into the filesystem where `makepkg` is run outside of a chroot.
There can also be instances of generated files (e.g. cache, precompiled
bytecode)
Hi,
I think I found a bug in pacman.
When a package remove operation can't be satisfied, pacman prints an
error, describes what went wrong, and does nothing:
$ sudo pacman -R linux-api-headers
checking dependencies...
error: failed to prepare transaction (could not satisfy
