I'm really sorry for the late reply. The reason I was taking so much
time to answer the question "how many packages are affected" is that
I'm *also* tracking packages which FTBFS randomly:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?correspondent=sanvila%40debian.org;dist=unstable;include=subjec
Simon McVittie wrote:
> On Thu, 25 Jul 2019 at 13:22:42 +0200, Santiago Vila wrote:
> > The only thing it did not have was more than one CPU, but AFAIK that's
> > not something that may be considered as a misconfiguration.
>
> Roughly what proportion of Debian packages are failing to build in
> th
On Fri, 26 Jul 2019 at 19:05:50 +0200, Santiago Vila wrote:
> The practical implications of this is that we are currently forcing
> users to spend extra money if they want *assurance* that all the
> packages (and not just "most" of them) will build, which is a pity.
I have two counterpoints to tha
Hi,
as I'm not sure everyone is aware of what the problem with p4est was, I
decided to write a short summary:
- Summary --
- p4est uses MPI, a standard for parallel applications running on single
machines up to clusters with 100 000+
On Tue, Jul 30, 2019 at 09:05:04PM +0200, Santiago Vila wrote:
> Quoting Debian Policy:
>
> Packages should build reproducibly, which for the purposes of this
> document [19] means that given
>
> a version of a source package unpacked at a given path;
> a set of versions of installed bu
Quoting Debian Policy:
Packages should build reproducibly, which for the purposes of this
document [19] means that given
a version of a source package unpacked at a given path;
a set of versions of installed build dependencies;
a set of environment variable values;
a build archi
On Tue, Jul 30, 2019 at 02:40:06PM +0200, Santiago Vila wrote:
>...
> This is really like a weak form of "reproducible builds", as in "every
> time I try to build the package in a capable system, the build succeeds".
Is a single-core system capable of rebuilding a package with parallel=64 ?
> The
On Mon, Jul 29, 2019 at 05:23:49PM -0500, Gunnar Wolf wrote:
> without a bug roundtrip plus new upload. But second, and I think most
> important: how many extra fields would this need? Build-CPU,
> Build-RAM, Build-HDD spring to mind... But many other more detailed
> bits could creep their way in i
On 29/07/19 at 17:23 -0500, Gunnar Wolf wrote:
> My opinion, based on what we talked about this bug during DebConf and
> the people I talked with, is that we should provide an advice
> following roughly:
>
> - The Release Team are empowered to set the base requirements to build
> packages for a
Santiago Vila dijo [Thu, Jul 25, 2019 at 01:22:42PM +0200]:
> > Or are you asking the TC for advice, or are you asking us to use a
> > different one of the TC's powers?
>
> Advice first.
OK, good this is made explicit. Thanks.
> > There are many aspects of a build environment that might be consi
Santiago Vila writes:
> Even if we ever wanted to allow packages to "need" more than one CPU
> for building, I'd like to believe that we would do so by introducing a
> new control field for that, say, Build-CPU, instead of making
> multi-core mandatory for all packages.
I agree.
Bdale
signatu
On Fri, Jul 26, 2019 at 07:05:50PM +0200, Santiago Vila wrote:
>...
> https://people.debian.org/~sanvila/single-cpu/
>...
> The practical implications of this is that we are currently forcing
> users to spend extra money if they want *assurance* that all the
> packages (and not just "most" of them)
Adrian Bunk wrote:
> It might help your case if you would describe why using more than one
> core is not an option for you.
I have already explained that several times.
The first one here, on a theoretical level:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907829#57
Then I went ahead and
On Thu, 25 Jul 2019 at 16:39:38 +0300, Adrian Bunk wrote:
> On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote:
> > The only thing it did not have was more than one CPU, but AFAIK that's
> > not something that may be considered as a misconfiguration.
>
> For CPU-bound tasks like package
On Thu, 25 Jul 2019 at 13:22:42 +0200, Santiago Vila wrote:
> The only thing it did not have was more than one CPU, but AFAIK that's
> not something that may be considered as a misconfiguration.
Roughly what proportion of Debian packages are failing to build in
this environment?
Roughly how many
On Thu, Jul 25, 2019 at 01:22:42PM +0200, Santiago Vila wrote:
> On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote:
>...
> Ok, my build environment:
>
> * Had enough RAM.
> * Had enough disk.
>...
> The only thing it did not have was more than one CPU, but AFAIK that's
> not something
On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote:
> Do I understand correctly that you are asking the TC to exercise our
> power to overrule developers, in order to overrule the maintainer's
> and/or the release team's judgement about the severity of (bugs like)
> #907829?
Not yet.
retitle 932795 How to handle FTBFS bugs in release architectures
thanks
On Wed, Jul 24, 2019 at 12:05:45PM +0100, Simon McVittie wrote:
> I don't think framing this as a question of ethics is necessarily
> helpful. When people disagree on a technical question, a recurring
> problem is that both "s
18 matches
Mail list logo
