Hello,
On Fri 04 Jun 2021 at 06:39PM +02, Helmut Grohne wrote:
> Hi Sean,
>
> On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote:
>> dgit wraps some of the existing tools. While dgit is mainly for humans,
>> one role it can have in automated toolchains is producing an ephemeral
>> sour
Hi,
On Thu, 10 Jun 2021, Helmut Grohne wrote:
> On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote:
> > I want to know it precisely in the context of selecting a worker. I don't
> > want to schedule a task on a worker and later get back an answer "sorry I
> > can't handle your task",
Hi Raphaël,
On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote:
> I want to know it precisely in the context of selecting a worker. I don't
> want to schedule a task on a worker and later get back an answer "sorry I
> can't handle your task", and then have to schedule it on some other
On Thu, Jun 10, 2021 at 8:01 AM Raphael Hertzog wrote:
>
> > > PS: I already hate the "mdbp" name after having it typed so many times.
> >
> > I'm not attached to either. Any suggestions?
>
> sbp for "standardized build package" is easier to type but not necessarily
> nicer.
>
> "justadeb" or "gi
Hi,
On Tue, 08 Jun 2021, Helmut Grohne wrote:
> With "look behind the abstraction", I think that you mean that debusine
> would have to implement the mdbp api to perform worker selection. While
> that would be possible indeed, I don't see this as required though.
[…]
> I do wonder though, in what
On Tue, Jun 08, 2021 at 10:07:50PM +0200, Helmut Grohne wrote:
> > PS: I already hate the "mdbp" name after having it typed so many times.
> I'm not attached to either. Any suggestions?
even medebupa seems better to me.
(assuming mdbp is meta debian build package?)
or meta-debuild or something^
Hi Raphaël,
On Tue, Jun 08, 2021 at 12:05:44AM +0200, Raphael Hertzog wrote:
> The point is that if you have to look behind the abstraction to do some
> other related tasks like selecting the worker, then using the abstraction
> to actually execute the build doesn't bring you much, just supplement
Hi,
On Mon, 07 Jun 2021, Helmut Grohne wrote:
> My abstraction says nothing about workers or how to select them. The
> idea behind that was that a user should not have to care. Yes, you
> (debusine) do need a mapping between workers and available distributions
> somewhere. You can implement schedu
Hi Raphaël,
Reading your reply makes me think there must be a misunderstanding. Much
of what you write only makes sense to me that way. I hope my reply is
not too repetitive and clears up some of that.
On Sun, Jun 06, 2021 at 06:00:28PM +0200, Raphael Hertzog wrote:
> I don't want to sound too ne
Hi,
On Fri, 04 Jun 2021, Helmut Grohne wrote:
> This is very sad. The whole point of me reaching out where was
> specifically trying to avoid this kind of fragmentation and now you're
> adding to it. While mdbp also is an implementation, it first and
> foremost is an API and I'd hope that it would
Hi Sean,
On Thu, Jun 03, 2021 at 04:47:44PM -0700, Sean Whitton wrote:
> dgit wraps some of the existing tools. While dgit is mainly for humans,
> one role it can have in automated toolchains is producing an ephemeral
> source package for the purpose of performing a build where the real
> input i
Hi Raphaël,
On Fri, Jun 04, 2021 at 08:42:23AM +0200, Raphael Hertzog wrote:
> I don't intend to restrict too much the number of "tasks" that I will
> accept in debusine, we can have both if it makes sense. Though I believe
> that this is an abstraction worth having at the debusine level without
>
Hi,
On Wed, 02 Jun 2021, Helmut Grohne wrote:
> * debusine's build milestone implements a lock-in on sbuild. The
>abstraction that I'm seeking doesn't happen here.
Just to be clear, I think I want that kind of abstraction at some point.
Because one should be able to schedule a package build
Hello Helmut,
On Mon 31 May 2021 at 08:25AM +02, Helmut Grohne wrote:
>
> So with this mail I seek multiple sorts of replies:
> * What other tools perform builds as part of their job, but don't
>exactly care how they're being performed?
> * What build tools am I missing?
> * Does the probl
Hi Helmut,
Quoting Helmut Grohne (2021-06-03 09:34:32)
> On Thu, Jun 03, 2021 at 09:22:05AM +0200, Jonas Smedegaard wrote:
> > And sure, a frontend wrapper tool may not need to care about some
> > options, if possible to configure the backend independently.
>
> Thank you for putting this so clea
Hi Jonas,
On Thu, Jun 03, 2021 at 09:22:05AM +0200, Jonas Smedegaard wrote:
> And sure, a frontend wrapper tool may not need to care about some
> options, if possible to configure the backend independently.
Thank you for putting this so clearly.
For now, I've been focussing on the interface bet
Quoting Helmut Grohne (2021-06-03 07:41:07)
> On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote:
> > This reminded me of my using of ccache and eatmydata in sbuild. They
> > may not be relevant for the context of mdbp depending on the
> > resources available for building, indeed.
> >
Hi Alex,
On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote:
> This reminded me of my using of ccache and eatmydata in sbuild.
> They may not be relevant for the context of mdbp depending on
> the resources available for building, indeed.
>
> I'm pretty fond of them because they speed u
Hi Helmut,
> On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote:
>
> > Some aspects that you may want to set for a build are:
Paul said:
> What to run in the build environment at each stage.
This reminded me of my using of ccache and eatmydata in sbuild.
They may not be relevant for the conte
Hi Paul,
On Tue, Jun 01, 2021 at 01:00:55AM +, Paul Wise wrote:
> > Some aspects that you may want to set for a build are:
>
> Looking at my pbuilder configs, some more:
Note that you are not a computer program. The thing I'm working on is
not supposed to be run by humans, but by other tools
Hi Raphaël,
On Wed, Jun 02, 2021 at 09:12:24AM +0200, Raphael Hertzog wrote:
> On Mon, 31 May 2021, Helmut Grohne wrote:
> > I see this tight coupling as a problem for mainly two reasons.
> [...]
> > * As tasks grow, there is a desire to distribute builds to multiple
> >machines. As such, the
Hi,
On Mon, 31 May 2021, Helmut Grohne wrote:
> I see this tight coupling as a problem for mainly two reasons.
[...]
> * As tasks grow, there is a desire to distribute builds to multiple
>machines. As such, the various tools typically grow their own
>strategy for moving build tasks betwee
On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote:
> Here are a number of lock-ins I happen to know:
This was mentioned on IRC:
cowpoke (from devscripts) -> remote cowbuilder
--
bye,
pabs
https://wiki.debian.org/PaulWise
On Mon, May 31, 2021 at 6:26 AM Helmut Grohne wrote:
> When someone writes a tool, that happens to build packages as part of
> its job (the earlier list), typically one of the build tools (the second
> list) is chosen and fixed. It's not like you can mix and match them.
> Here are a number of lock
Hi fellow developers,
Building Debian packages is a job that is not only part of our daily
development practice, but also a task regularly performed by tools.
These include:
* QA tools frequently rebuild packages to find bugs
* Archive rebuilds (e.g. Lucas Nussbaum, Matthias Klose, Santiago
25 matches
Mail list logo
