On Thu, 23 Feb 2017 at 10:02:55 -0800, Nikolaus Rath wrote:
> Yes, but last time I checked a "apt-get source && debuild -us -uc" still
> defaults to using just a single CPU unless you explicitly set
> DEB_BUILD_OPTIONS=parallel.
Check again - dpkg-buildpackage now defaults to -Jauto
(it sets DEB_B
❦ 23 février 2017 10:02 -0800, Nikolaus Rath :
Your chosen build environment is not common [...]
>>>
>>> This has come up a few times now. Could someone explain what is so odd
>>> about his envirnoment? It does not look unusual to me.
>>
>> Official buildd have several CPU. Most "important"
On Feb 21 2017, Vincent Bernat wrote:
> ❦ 21 février 2017 09:48 -0800, Nikolaus Rath :
>
>>> Your chosen build environment is not common [...]
>>
>> This has come up a few times now. Could someone explain what is so odd
>> about his envirnoment? It does not look unusual to me.
>
> Official build
On Tue, 21 Feb 2017 at 23:35:44 +, Ben Hutchings wrote:
> Having said that, some ioctls that make sense for block-backed
> filesystems, such as FS_IOC_FIEMAP, won't work on a tmpfs (or nfs,
> ubifs, etc.).
One notable omission is that tmpfs doesn't do generic "user." extended
attributes (due t
❦ 22 février 2017 00:46 +0100, Adam Borowski :
>> > > * using a qemu build chroot (Debian doesn't do this, other might)
>> >
>> > Is that because QEMU is slow, or some other reason?
>>
>> AIUI qemu(-static) cannot handle threading very well. So if a build
>> process uses such applications, thi
On Tue, 2017-02-21 at 14:18 -0700, Sean Whitton wrote:
> On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote:
> > > * with /tmp on tmpfs on some archs
> >
> > [...]
> >
> > You mean the 64-bit PowerPC architectures? tmpfs allocates at
> > least a
> > page per file, and they have 64K pa
On Tue, Feb 21, 2017 at 11:04:52PM +0100, Christoph Biedl wrote:
> > > * using a qemu build chroot (Debian doesn't do this, other might)
> >
> > Is that because QEMU is slow, or some other reason?
>
> AIUI qemu(-static) cannot handle threading very well. So if a build
> process uses such applicat
Ben Hutchings wrote...
> > * when using eatmydata
>
> I can certainly think of a test case that would be broken by eatmydata
> and I would not want to rule out such test cases. But still, I am
> suprised by this.
#667965 - don't know whether this still exists. I later decided to patch
dpkg so "
Sean Whitton wrote...
> I'm not sure why you're mentioned powerpc archs
Because that's a surprising feature of that arch and once you've
realized you were caught by this, you will not forget it. Bonus:
Rebuilding on a porter box passes since /home is not a tmpfs.
Christoph
PS:
https://sour
On Tue, Feb 21, 2017 at 02:37:23AM +, Ben Hutchings wrote:
> > * with /tmp on tmpfs on some archs
> [...]
>
> You mean the 64-bit PowerPC architectures? tmpfs allocates at least a
> page per file, and they have 64K pages...
I'm not sure why you're mentioned powerpc archs, but as a hopefully
On Tue, Feb 21, 2017 at 09:36:58PM +0100, Vincent Bernat wrote:
> Accomodating for all build environments is a slippery slope. What if I
> use a 128MB host with 64GB of swap? Timing-related tests will start to
> fail. Is it Debian job to fix all the test suites? Should I be able to
> build package
❦ 21 février 2017 09:48 -0800, Nikolaus Rath :
>> Your chosen build environment is not common [...]
>
> This has come up a few times now. Could someone explain what is so odd
> about his envirnoment? It does not look unusual to me.
Official buildd have several CPU. Most "important" downstream
d
> Your chosen build environment is not common [...]
This has come up a few times now. Could someone explain what is so odd
about his envirnoment? It does not look unusual to me.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38
On Tue, 2017-02-21 at 11:50 +0800, Paul Wise wrote:
> On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
>
> > This is a charming idea altough I have doubt it will work out: As
> > usual the information has to be kept up-to-date, so unless it is
> > collected and verified every now and then a
On Mon, Feb 20, 2017 at 04:42:49PM -0800, Russ Allbery wrote:
> To say my opinion explicitly, since there's been a lot of discussion here,
> some of which I've been involved in somewhat ambiguously:
Thanks for writing this up, Russ. I fully agree with *everything* you said here:
> I think this i
On Mon, Feb 20, 2017 at 01:12:33PM +0100, Santiago Vila wrote:
> Believe me, this is also frustrating for me. If you absolutely need a
> machine to reproduce this, contact me privately.
If someone creates a patch, then the bug is much more likely to get fixed,
whether it's RC or not. Any FTBFS th
On Tue, Feb 21, 2017 at 11:50:15AM +0800, Paul Wise wrote:
> On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
>
> > This is a charming idea altough I have doubt it will work out: As
> > usual the information has to be kept up-to-date, so unless it is
> > collected and verified every now and
On Tue, Feb 21, 2017 at 6:36 AM, Christoph Biedl wrote:
> This is a charming idea altough I have doubt it will work out: As
> usual the information has to be kept up-to-date, so unless it is
> collected and verified every now and then automatically, it will
> become unsuable pretty soon.
FYI the
On Mon, 2017-02-20 at 23:36 +0100, Christoph Biedl wrote:
> Niels Thykier wrote...
>
> [ topic shift ]
>
> > On a related note: Having some way to declare minimum requirements for
> > e.g. disk space and memory (a la "base GB usage + GB usage/core") used
> > would be great.
> > Especially if it
Santiago Vila writes:
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
> https://people.debian.org/~sanvila/my-building-environment.txt
> Before I ask the R
Holger Levsen writes:
> On Mon, Feb 20, 2017 at 09:59:29PM +, Ian Jackson wrote:
>> + A FTBFS bug is still RC even if:
>> + it doesn't happens on buildd.debian.net;
>> + it only happens randomly;
>> + it only happens on machines with one (virtual) cpu core.
> while I do a
Santiago Vila wrote...
> I fully agree with the underlying idea, however: If we can measure the
> failure rate, then it means it already fails too often to be acceptable.
Cannot deny I somehow like that approach.
> For that to happen, the around 50 packages which FTBFS randomly should
> do so le
Niels Thykier wrote...
[ topic shift ]
> On a related note: Having some way to declare minimum requirements for
> e.g. disk space and memory (a la "base GB usage + GB usage/core") used
> would be great.
> Especially if it is available in metadata, so wanna-build can see
> whether it makes sense
On Mon, Feb 20, 2017 at 09:59:29PM +, Ian Jackson wrote:
> My advice would be to avoid asking the TC such general questions.
My advice too.
> There are two sensible questions:
>
> * Should the following bugs be RC ?
> [ list of 20 bugs or whatever ]
with a list of 20 bugs I dont think
Santiago Vila writes ("Re: Help requested: Packages which FTBFS randomly"):
> Maybe this one for a start?:
>
> Should building Debian source packages on a single-CPU machine be
> supported at the same level as building on a multi-core machine, to
> the point that a
Vincent Bernat writes ("Re: Help requested: Packages which FTBFS randomly"):
> ❦ 20 février 2017 21:13 GMT, Ian Jackson :
> > With the correct infrastructure (which is not that hard) the causes
> > can be completely eliminated. I don't ever experience random build
On Mon, Feb 20, 2017 at 09:22:35PM +, Ian Jackson wrote:
> If you do not get good answers, please take this to the TC.[1]
Thanks a lot for your support, Ian.
What kind of question do you think I could make to the TC?
Maybe this one for a start?:
Should building Debian source packages on a
❦ 20 février 2017 21:13 GMT, Ian Jackson :
> With the correct infrastructure (which is not that hard) the causes
> can be completely eliminated. I don't ever experience random build
> failures of any of my own packages and if I did I would hunt them down
> with a vengeance.[1]
Good for you.
h
Ian Jackson writes:
> Russ Allbery writes:
>> The point is that they don't randomly fail in the sense that they don't
>> fail n% of the time when run in any possible build environment.
>> Rather, in the subset of cases we're talking about in this thread, the
>> tests work reliably on the develope
Russ Allbery writes ("Re: aren't unreliable tests worse than none? (Re: Help
requested: Packages which FTBFS randomly)"):
> The point is that they don't randomly fail in the sense that they don't
> fail n% of the time when run in any possible build environment. R
Santiago Vila writes ("Re: Help requested: Packages which FTBFS randomly"):
> I don't think that's what we want.
Picking on this message at random:
Many of the messages in this thread are IMO defending the
indefensible, using unreasonable arguments. Reading them, and some
Christoph Biedl writes ("Re: Help requested: Packages which FTBFS randomly"):
> Ian Jackson wrote...
> > IMO all of these bugs should be RC. A randomly-reproducible build
> > failure with more than negligible probabilty is likely to show up for
> > some of Debian&#x
On Mon, Feb 20, 2017 at 06:46:25PM +, Holger Levsen wrote:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> > The point is that they don't randomly fail in the sense that they don't
> > fail n% of the time when run in any possible build environment.
We don't really know. Some
Holger Levsen writes:
> On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
>> This is, in a sense, an unreliable test, but it's not unreliable in a
>> way that directly affects the main line of package development.
> until someone affected wants to contribute…
Sure. I think it's a h
On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> The point is that they don't randomly fail in the sense that they don't
> fail n% of the time when run in any possible build environment.
…but point taken, not all FTBFS bugs are RC(!) as
<20170220152410.3mkm5tebg5i2y...@perpetual.pse
On Mon, Feb 20, 2017 at 10:29:28AM -0800, Russ Allbery wrote:
> This is, in a sense, an unreliable test, but it's not unreliable in a way
> that directly affects the main line of package development.
until someone affected wants to contribute…
--
cheers,
Holger
signature.asc
Descript
Holger Levsen writes:
> While I agree with Niels that it would be very worthwhile to be able to
> define ressource requirements for a package to build (and thus know I
> have to life with some packages having trouble sometimes) I find it
> *very* strange to be content with test suites which rando
On Mon, Feb 20, 2017 at 11:45:00AM +0100, Vincent Bernat wrote:
> Time is a limited resource and we need to set our priorities. Having
> test suites that work 100% of the time with constrained resources is not
> a goal I find worthy of the time I can spend on Debian. Unfortunately,
> those bugs are
On Mon, Feb 20, 2017 at 06:10:23PM +0100, Vincent Bernat wrote:
> ❦ 20 février 2017 13:44 GMT, Holger Levsen :
>
> >> As a rule of thumb, upstream usually knows better than me which tests
> >> are important. Tests are quite important for the packager to know if
> >> they didn't make an obvious m
Le 20 février 2017 16:55:49 GMT+01:00, Julien Cristau a
écrit :
>On 02/20/2017 07:57 AM, Niels Thykier wrote:
>> Vincent Bernat:
>>> [...]
>>>
>>> [...] The policy doesn't state that a package
>>> must build when there is not enough disk space or memory. Maybe it
>would
>>> be far simpler to al
On Mon, 2017-02-20 at 08:30 +, Simon McVittie wrote:
> On Mon, 20 Feb 2017 at 01:00:33 +0100, Santiago Vila wrote:
> > Wait a moment. How we do define "common" when applied to a "build
> > environment"?
>
> Do we rely on it for Debian to function, or was it set up to determine
> what works (e.
On Mon, Feb 20, 2017 at 03:24:10PM +, Simon McVittie wrote:
> On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> > You are somehow trying to equate RC-ness with "it FTBFS in
> > buildd.debian.org".
>
> No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
> is ef
❦ 20 février 2017 13:44 GMT, Holger Levsen :
>> As a rule of thumb, upstream usually knows better than me which tests
>> are important. Tests are quite important for the packager to know if
>> they didn't make an obvious mistake when updating a package (e.g new
>> dependency missing, something e
On 02/20/2017 07:57 AM, Niels Thykier wrote:
> Vincent Bernat:
>> [...]
>>
>> [...] The policy doesn't state that a package
>> must build when there is not enough disk space or memory. Maybe it would
>> be far simpler to allow packages to fail to build if there is not enough
>> CPUs.
>>
>
> On a r
On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> You are somehow trying to equate RC-ness with "it FTBFS in buildd.debian.org".
No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
is effectively release-critical whether Policy says it is or not,
because if we can'
On Mon, Feb 20, 2017 at 01:46:20PM +0100, Vincent Bernat wrote:
> As a rule of thumb, upstream usually knows better than me which tests
> are important. Tests are quite important for the packager to know if
> they didn't make an obvious mistake when updating a package (e.g new
> dependency missing,
❦ 20 février 2017 11:03 GMT, Holger Levsen :
>> Time is a limited resource and we need to set our priorities. Having
>> test suites that work 100% of the time with constrained resources is not
>> a goal I find worthy of the time I can spend on Debian.
>
> While I agree with Niels that it would b
On Mon, Feb 20, 2017 at 11:33:23AM +, Ghislain Vaillant wrote:
> I share the same feelings towards a similar intermittent FTBFS with
> src:python-qtpy (#8544936). I admit I have no clue what is going on,
> neither does upstream, nor does the reporter (Santiago).
That would be #854496. It also
On Mon, 2017-02-20 at 11:45 +0100, Vincent Bernat wrote:
> ❦ 20 février 2017 10:05 GMT, Jonathan Dowland :
>
> > None of the FTBFS problems I've seen in this thread have been because the
> > tests *required* multiple cores, by the way; more so that they were racy
> > or buggy in some other fashi
On 02/20/2017 11:05 AM, Jonathan Dowland wrote:
> On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
>> * single-CPU machines have gone the way of the dodo. Even the crummiest
>> machine I could find while dumpster-diving looking for a non-sse3 one
>> already has HT and builds your
On Mon, Feb 20, 2017 at 11:45:00AM +0100, Vincent Bernat wrote:
> Time is a limited resource and we need to set our priorities. Having
> test suites that work 100% of the time with constrained resources is not
> a goal I find worthy of the time I can spend on Debian.
While I agree with Niels that
On 02/15/2017 09:45 PM, Santiago Vila wrote:
> Building a package is like following an algorithm. It may take less or
> more time, but it always has to finish. For this reason, "your CPU is
> too slow to build my package" is always a very poor excuse, and I hope
> you are not trying to set a minimu
❦ 20 février 2017 10:05 GMT, Jonathan Dowland :
> None of the FTBFS problems I've seen in this thread have been because the
> tests *required* multiple cores, by the way; more so that they were racy
> or buggy in some other fashion. If uniprocessor buildds are finding these
> bugs then that's a
On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
> * single-CPU machines have gone the way of the dodo. Even the crummiest
> machine I could find while dumpster-diving looking for a non-sse3 one
> already has HT and builds your examples successfully. Same for ARM SoCs
> -- my
On Mon, Feb 20, 2017 at 08:30:04AM +, Simon McVittie wrote:
> Debian is an operating system, not an academic exercise. If a package
> builds successfully reliably enough on buildds, porterboxes, and
> developers' hardware or VMs that we can prepare security updates and
> other urgent patches fo
On Mon, Feb 20, 2017 at 01:57:52AM +0100, Adam Borowski wrote:
> * single-CPU machines have gone the way of the dodo. Even the crummiest
> machine I could find while dumpster-diving looking for a non-sse3 one
> already has HT and builds your examples successfully. Same for ARM SoCs
> -- my
On Mon, 20 Feb 2017 at 01:00:33 +0100, Santiago Vila wrote:
> Wait a moment. How we do define "common" when applied to a "build
> environment"?
Do we rely on it for Debian to function, or was it set up to determine
what works (e.g. for QA)? The former is common; the latter might not
be, and failin
Vincent Bernat:
> [...]
>
> [...] The policy doesn't state that a package
> must build when there is not enough disk space or memory. Maybe it would
> be far simpler to allow packages to fail to build if there is not enough
> CPUs.
>
On a related note: Having some way to declare minimum requirem
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> Your chosen build environment is not common and fixing build failures
> for uncommon environment may seem a waste of the "Debian-allocated time"
> for some people (including me).
Yeah. I think your priorities are somewhat backwards
On Mon, Feb 20, 2017 at 12:05:42AM +0100, Vincent Bernat wrote:
> More and more packages come with test suites to help developers and
> packagers ensure things are working as expected. It would be great if
> test suites didn't have failures of their own but it's better to have
> them and it's under
❦ 19 février 2017 22:59 +0100, Santiago Vila :
> I'm pretty sure that I was already a DD when such thing could have
> happened, but right now I can't remember it.
>
> (See #848063 for why I'm asking this).
IMO, you are also pretty aggressive.
More and more packages come with test suites to hel
On Sun, Feb 19, 2017 at 10:59:56PM +0100, Santiago Vila wrote:
> BTW: Could anybody tell me when exactly "FTBFS on a single-CPU machine"
> stopped being serious and RC? Did such thing ever happened?
I don't think so. (It never stopped being serious.)
If some people disagree I'd say this is life
On Sun, Feb 19, 2017 at 06:27:16PM +0100, Christoph Biedl wrote:
> Ian Jackson wrote...
>
> > If there is to be a failure probability threshold I would set it at
> > 10^-4 or so. After all, computer time is cheap.
>
> To determine 10^-4 with some accurance you'd have to rebuild that
> package 200
Ian Jackson wrote...
> IMO all of these bugs should be RC. A randomly-reproducible build
> failure with more than negligible probabilty is likely to show up for
> some of Debian's users and downstreams and cause them mysterious
> trouble. It also causes trouble for stalwarts like Santiago, doing
Am Sonntag, den 19.02.2017, 16:09 +0100 schrieb Steve Cotton:
> Impossible d'initialiser SDL:Couldn't open X11 display
Why does the package require an X11 display to build?
- Fabian
signature.asc
Description: This is a digitally signed message part
On Wed, Feb 15, 2017 at 06:26:51PM +0100, Santiago Vila wrote:
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
>
> https://people.debian.org/~sanvila/my-build
On Fri, Feb 17, 2017 at 06:59:00PM +, Niels Thykier wrote:
> Santiago Vila:
> > On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
> >
> >> Santiago already brought it up in #844264. I believe my answer in
> >> comment 70 is still relevant (other than I incorrectly used "after the
Santiago Vila:
> On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
>
>> Santiago already brought it up in #844264. I believe my answer in
>> comment 70 is still relevant (other than I incorrectly used "after the
>> freeze" when I meant "after the release").
>
> Well, but when I said
On Fri, Feb 17, 2017 at 08:54:54AM -0600, Jeff Epler wrote:
> On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote:
> > Can anyone here reproduce any of the following *two* bugs?
> > (Using sbuild in a single-CPU machine)
> >
> > 837067 1.000 libsecret
>
> Using a fresh 1CPU / 1GB x86
On Fri, Feb 17, 2017 at 03:34:08PM +, Holger Levsen wrote:
> https://tests.reproducible-builds.org/libsecret looks better:
I forgot to mention this (kind of) URL:
https://tests.reproducible-builds.org/debian/history/libsecret.html
--
cheers,
Holger
signature.asc
Description: Di
On Fri, Feb 17, 2017 at 08:54:54AM -0600, Jeff Epler wrote:
> On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote:
> > Can anyone here reproduce any of the following *two* bugs?
> > (Using sbuild in a single-CPU machine)
> > 837067 1.000 libsecret
>
> Using a fresh 1CPU / 1GB x86 syst
On Fri, Feb 17, 2017 at 12:16:16PM +0100, Santiago Vila wrote:
> Can anyone here reproduce any of the following *two* bugs?
> (Using sbuild in a single-CPU machine)
>
> 837067 1.000 libsecret
Using a fresh 1CPU / 1GB x86 system on digitalocean's NYC region, upgraded to
debian testing, I tried
On Fri, Feb 17, 2017 at 06:23:00AM +, Niels Thykier wrote:
> Santiago already brought it up in #844264. I believe my answer in
> comment 70 is still relevant (other than I incorrectly used "after the
> freeze" when I meant "after the release").
Well, but when I said "Ok, will do" in Bug #844
Ian Jackson:
> Santiago Vila writes ("Help requested: Packages which FTBFS randomly"):
>> The following packages FTBFS for me randomly. First column is the bug
>> number, second column is the estimated probability of failure in my
>> build environment, which is des
On Thu, Feb 16, 2017 at 10:32:04PM +, Jonathan Dowland wrote:
> Thanks for doing this.
...despite alarming hostility from your fellow developers (as I read
the bugs in more detail, in growing horror... #844264 in particular)
--
Jonathan Dowland
Please do not CC me, I am subscribed to the l
This is really intriguing. I suspected your build environment must
have been weird, but it looks fine to me. The likely elephant in the
room is the single processor. I'm pretty amazed that this seems to be
a stumbling block, but there we go.
Thanks for doing this.
signature.asc
Description: Digi
Santiago Vila writes ("Help requested: Packages which FTBFS randomly"):
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
IMO all of thes
On Wed, Feb 15, 2017 at 03:02:23PM -0500, Jeremy Bicha wrote:
> On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote:
> > Allowing packages to fail 50% of the time is interpreting Release
> > Policy in a somewhat twisted way.
>
> Except that your build system is far more limited than the average
On Wed, Feb 15, 2017 at 08:38:17PM +0100, Bernd Zeimetz wrote:
> Hi,
>
> > The following packages FTBFS for me randomly. First column is the bug
> > number, second column is the estimated probability of failure in my
> > build environment, which is described here:
> >
> > https://people.debian.or
On Wed, Feb 15, 2017 at 2:36 PM, Santiago Vila wrote:
> Allowing packages to fail 50% of the time is interpreting Release
> Policy in a somewhat twisted way.
Except that your build system is far more limited than the average
system used to build packages in 2017.
Thanks,
Jeremy Bicha
On Wed, Feb 15, 2017 at 08:05:51PM +0100, Thibaut Paumard wrote:
> Dear Santiago,
>
> Le 15/02/2017 à 18:26, Santiago Vila a écrit :
> > Hello.
> >
> > The following packages FTBFS for me randomly. First column is the bug
> > number, second column is the estimated probability of failure in my
> >
Hi,
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
>
> https://people.debian.org/~sanvila/my-building-environment.txt
did you try to diff the build output
Dear Santiago,
Le 15/02/2017 à 18:26, Santiago Vila a écrit :
> Hello.
>
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
>
> https://people.debian.org/~sanv
Hello.
The following packages FTBFS for me randomly. First column is the bug
number, second column is the estimated probability of failure in my
build environment, which is described here:
https://people.debian.org/~sanvila/my-building-environment.txt
Before I ask the Release Managers that they
84 matches
Mail list logo
