Hello Niels,
On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
> Guillem and I have debated this and come to a solution, which we believe
> will be able to address the concerns about the path being "hidden". It
> also enables us to simplify parts of the migration in some cases.
>
> The shor
Sean Whitton:
> Hello,
>
> On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
>
>> Guillem and I have debated this and come to a solution, which we believe
>> will be able to address the concerns about the path being "hidden". It
>> also enables us to simplify parts of the migration in some
Hello,
On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
> Guillem and I have debated this and come to a solution, which we believe
> will be able to address the concerns about the path being "hidden". It
> also enables us to simplify parts of the migration in some cases.
Thank you for you
Sam Hartman:
> I'm concerned about a leading . at least for:
>
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
>
> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
> So I'd prefer s
On 2020-03-09 Sam Hartman wrote:
> I'm concerned about a leading . at least for:
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
On Mon, 2020-03-30 at 13:54:27 +0200, Simon Richter wrote:
> On 30.03.20 00:52, Guillem Jover wrote:
> > And, of course there are always going to be remaining sticking points
> > not covered by features I or others have in mind, but IMO their presence
> > will still mean there's something to improv
Hi,
On 30.03.20 00:52, Guillem Jover wrote:
> And, of course there are always going to be remaining sticking points
> not covered by features I or others have in mind, but IMO their presence
> will still mean there's something to improve somewhere.
This is the same debate we had in a lot of othe
On Sun, 2020-03-29 at 22:48:04 +0200, Marco d'Itri wrote:
> On Mar 29, Guillem Jover wrote:
> > While it's true that we might need to use such pathnames in debian/rules
> > or debhelper fragment files (which some might consider ugly), IMO that
> > has always felt like a sign that there's something
On Mar 29, Guillem Jover wrote:
> While it's true that we might need to use such pathnames in debian/rules
> or debhelper fragment files (which some might consider ugly), IMO that
> has always felt like a sign that there's something missing in our
> packaging helpers/tools.
If you believe this th
On Mon, 2020-03-09 at 09:23:46 -0400, Sam Hartman wrote:
> I'm concerned about a leading . at least for:
>
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
>
> I think that maintaining those directories such that ls shows them will
> be more fri
(note, this is a barely structured brain dump)
On Tue, Mar 10, 2020 at 08:10:55AM +0100, Niels Thykier wrote:
> >> Though, can you elaborate a bit on why the above approach would be
> >> better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
> >> easy way to declare additional art
On Tue, Mar 10, 2020 at 09:07:57AM +, Simon McVittie wrote:
> On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote:
> > On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > > Standardized way of extracting additional build-time artefacts
> >
> > This reminds me of the BYHAND stuff, I for
On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote:
> On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
> > Standardized way of extracting additional build-time artefacts
>
> This reminds me of the BYHAND stuff, I forget how that works though.
I think how that works is that at the appropri
On Tue, 10 Mar 2020 at 08:10:55 +0100, Niels Thykier wrote:
> Just to clarify something related. Should debhelper and other tools by
> default archive "certain files of possible interest" (e.g. config.log)?
> Or should we limit it to "on request only"?
I think it would probably make most sense fo
On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote:
>
Standardized way of extracting additional build-time artefacts
This reminds me of the BYHAND stuff, I forget how that works though.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Simon McVittie:
> On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
>> Simon McVittie:
>>> For example, dpkg-buildpackage could perhaps read one glob per
>>> line from debian/artifacts and hardlink matched files (if any) into
>>> debian/.build/artifacts for collection by a "larger" framew
On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
> Simon McVittie:
> > For example, dpkg-buildpackage could perhaps read one glob per
> > line from debian/artifacts and hardlink matched files (if any) into
> > debian/.build/artifacts for collection by a "larger" framework like
> > sbuild
Hello Julian,
On Mon 09 Mar 2020 at 09:43PM +01, Julian Andres Klode wrote:
> On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. [...]
> [...]
>> The use of a hidden directory is to reduce c
On Mon, Mar 09, 2020 at 10:09:46AM +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. [...]
[...]
> The use of a hidden directory is to reduce clutter and stomping over any
Love the hidden directory.
--
debian developer - deb
Simon McVittie:
Hi :)
> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>> - debian/.build/upstream*
>>
>> These could be used for out-of-tree b
ian.org; debhel...@packages.debian.org
Subject: Re: RFC: Standardizing source package artifacts build paths
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***
I'm concerned about a leading . at least for:
* the debian/tmp replaceme
I'm concerned about a leading . at least for:
* the debian/tmp replacement
* the replacement for the package install directories under debian.
I think that maintaining those directories such that ls shows them will
be more friendly for new maintainers.
So I'd prefer something like debian/build ra
On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
> We'd like to standardize on a new set of artifact build pathnames
> for our deb toolchain. These would have the following form:
>
> - debian/.build/upstream*
>
> These could be used for out-of-tree builds replacing current
>
23 matches
Mail list logo
