> The guarantee I was trying to make is that the sources in the source
> tarball match what is used to build the package, and can be used to
> build the package. Many packages from AUR do something silly like
>
> pkgver() { date +'%Y%m%d'; }
>
> With that, it isn't possible to re-build the s
On Sun, Jun 02, 2019 at 10:09:50AM -0400, Luke Shumaker wrote:
> The guarantee I was trying to make is that the sources in the source
> tarball match what is used to build the package, and can be used to
> build the package. Many packages from AUR do something silly like
>
> pkgver() { date +
On Wed, 29 May 2019 07:59:38 -0400,
bill-auger wrote:
> On Wed, 29 May 2019 12:12:15 +0200 Andreas wrote:
> > Could someone explain to me why we want to break this
> > behaviour?
>
> i think only luke would know first hand - he explained the
> rationale; but its not clear what particular use case
i noticed that libremakepkg has options to control mounting ro or
rw - maybe that was intended to me the solution all along
-w Bind mount a file or
directory, read/write
-r Bind mount a file or
directory, read-only
___
Dev mailing list
Dev@
On Wed, 29 May 2019 12:12:15 +0200 Andreas wrote:
> Could someone explain to me why we want to break this
> behaviour?
i think only luke would know first hand - he explained the
rationale; but its not clear what particular use case it was
intended to support, or some bug it was intended to fix
I have to admit I don't understand the reasoning behind requiring a
read-only startdir. I like the idea of the pkgver() function being able
to modify the PKGBUILD file automagically for vcs based package sources.
Could someone explain to me why we want to break this behaviour?
Best,
-A
On Mon,
On Mon, 20 May 2019 13:01:16 -0400
bill-auger wrote:
> only reverting that change is not enough to address the issue
> though - we should also need to apply the patch gnutoo
> suggested; because right now the kernels do not build
> out-of-the-box with the standard tools - that should not be the
>
only reverting that change is not enough to address the issue
though - we should also need to apply the patch gnutoo
suggested; because right now the kernels do not build
out-of-the-box with the standard tools - that should not be the
case for such a critical base package
i was hoping to avoid gnu
El 19-05-19 a las 04:33, bill-auger escribió:
> the log message for the commit that introduced this change indicates that it
> was necessary for some reason - i think it would be hasty to revert this
> until we know what the trade-off would be
>
> "- We mount the temporary directory containing
the log message for the commit that introduced this change indicates that it
was necessary for some reason - i think it would be hasty to revert this until
we know what the trade-off would be
"- We mount the temporary directory containing the extracted source package
files read-only, to be su
Several packages require a read-write startdir:
- Some packages have a pkgver that is computed dynamically
through a pkgver function. This is the case for many packages
using git repositories. At the end of the package build, the
pkgver is automatically updated in the PKGBUILD, however,
wit
11 matches
Mail list logo
