Bug#907829: p4est: FTBFS on single CPU machines
On Tue, 2 Oct 2018, Adrian Bunk wrote: > Everyone else uses the common-sense approach of using CPU-strong > machines for CPU-intensive tasks like package building, if you > have made different practical experiences I'd be interested in > seeing the bills. https://people.debian.org/~sanvila/single-cpu/ TLDR: For packages which require 1 GB of RAM or less to build (approximately 96% of all packages), building them on machines with 2 CPUs is 50% more expensive on average than doing so on machines with only 1 CPU. Note that the maintainers of this package quickly found a fix for the bug, and the only reason the package is still unfixed in buster is that you downgraded the bug. Had Debian Policy and the original severity been respected, the package most probably would be fixed in buster now, as there are always people applying existing patches to fix RC bugs in bug-squashing parties. So, you have not helped anything at all to raise the quality of Debian by downgrading this bug. In fact, you have helped negative. To me, this is not anymore about Debian Policy, Release Policy, or the RC-ness of a given bug, this is about trying to skip all the decision-making procedures in Debian. I'm really sorry but I have no other option than complaining to the TC in the hope that I don't have to repeat this discussion with anybody else in the future. Please subscribe to the bug I've just filed if you like: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932795 Thanks.
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Oct 15, 2018 at 10:03:47PM +0100, Chris Lamb wrote: > Adrian Bunk wrote: > > > You are being a complete asshole when you are trying to use RC bugs for > > forcing other people to spend any time *ever* on your pet project. > > Whatever the technical merits here, calling a colleague an "asshole" in > any context is completely inappropriate and moreover behaviour > unbecoming of a Debian Developer. > > Adrian, I cordially invite you to withdraw your statement. I hereby withdraw the word "asshole". What I cannot withdraw are my personal feelings based on the attitude behind these "please try building with sbuild on a single-CPU machine, as I did" bugs. > Best wishes, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
Adrian Bunk wrote: > You are being a complete asshole when you are trying to use RC bugs for > forcing other people to spend any time *ever* on your pet project. Whatever the technical merits here, calling a colleague an "asshole" in any context is completely inappropriate and moreover behaviour unbecoming of a Debian Developer. Adrian, I cordially invite you to withdraw your statement. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907829: p4est: FTBFS on single CPU machines (?)
Adrian Bunk wrote: > You are being a complete asshole when you are trying to use RC bugs for > forcing other people to spend any time *ever* on your pet project. Whatever the technical merits here, calling a colleague an "asshole" in any context is completely inappropriate and moreover behaviour unbecoming of a Debian Developer. Adrian, I cordially invite you to withdraw your statement. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907829: p4est: FTBFS on single CPU machines
On Tue, Oct 02, 2018 at 09:43:39PM +0200, Santiago Vila wrote: > On Sun, Sep 30, 2018 at 11:49:26PM +0300, Adrian Bunk wrote: > > > Noone disagrees that these are bugs. > > True, but you seem to consider them second-class FTBFS bugs. > > However, it is not "just a bug", which is how you seem to paint it. > > It is a FTBFS bug, possibly the worst kind of bug a package may have, > the kind of bug that should never be present in a stable release. > That's why we consider FTBFS bugs as serious, to ensure that a stable > release does not have any such bugs. > > You seem to think that it's fine to require a "must build" only in > buildd.debian.org, but you do not realize that doing so is like having > an implicit "build-depends: buildd.debian.org". > > We ship Debian packages to our users, but we do not ship > buildd.debian.org as part of the distribution. > > So, we can't honestly say that "packages build from source" if they > only build ok in buildd.debian.org, which is the reason buildd.debian.org > should not be the "standard" to measure if a package builds or not. > > And that's precisely why we invented build-depends, to make the builds > reproducible for everybody (reproducible as in "every time I try to > build the package, the package is built"), not just reproducible in > buildd.debian.org. > > But now, in a stable release, we can't even have the assurance that > the package will build, because in addition to build-depends, the > build machine is now supposed to be a clone of buildd.debian.org in > every sense. > > Why in earth do we want build-depends, then, if not to ensure that the > packages will build for everybody? >... > I was just talking in a completely general sense, i.e. it is not a bug > for a package to "require" 4 GB of RAM to build (I mean "require" as > in "it builds with 4 GB but it does not build with 3 GB"). I would > hope that we agree on that. >... There would be some logic behind your reasoning if you would apply the same standards you have for CPU usage to packages that FTBFS due to low amount of RAM. You don't, that's why it is hard to take you seriously. And the real-world problems when building software in 2018 are about RAM, not single-CPU machines. >... > I have already shown that it's *cheaper*. And yet you insist that it's > not the right(TM) way to build packages. Are you going to pay for the > extra money I would spend on virtual machines, just so that I build > packages "the only way approved by you" to build packages? >... Cheaper only in fairytale world where other resources like RAM or storage aren't billed for a longer amount of time when the build takes forever due to lack of CPUs. Are you actually paying for the kind of virtual machines you are describing? Everyone else uses the common-sense approach of using CPU-strong machines for CPU-intensive tasks like package building, if you have made different practical experiences I'd be interested in seeing the bills. > > But it is simply rude trying to use RC bugs saying > > To reproduce, please try building with sbuild on a single-CPU machine, as > > I did. > > for forcing this as high priority upon other people. > > I'm not forcing anything. It's a FTBFS bug in a release architecture, > and it's therefore serious by nature. I'm not really "making" it RC. It is not a FTBFS on any buildd for a release architecture. > As far as priority is concerned, I don't dictate the priority by which > maintainers should fix their serious bugs. If they want to say "hello" every > 29 days in the bug report to avoid the autoremoval, that's up to them. >... This is not about when to fix it, it is about who has to do the fixing. It is *you* who is responsible to do the fixing for your pet project of building on single-CPU machines, not the maintainer. Most other people do consider it nuts to do serious package building on single-CPU machines in 2018. You are being a complete asshole when you are trying to use RC bugs for forcing other people to spend any time *ever* on your pet project. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 11:49:26PM +0300, Adrian Bunk wrote: > Noone disagrees that these are bugs. True, but you seem to consider them second-class FTBFS bugs. However, it is not "just a bug", which is how you seem to paint it. It is a FTBFS bug, possibly the worst kind of bug a package may have, the kind of bug that should never be present in a stable release. That's why we consider FTBFS bugs as serious, to ensure that a stable release does not have any such bugs. You seem to think that it's fine to require a "must build" only in buildd.debian.org, but you do not realize that doing so is like having an implicit "build-depends: buildd.debian.org". We ship Debian packages to our users, but we do not ship buildd.debian.org as part of the distribution. So, we can't honestly say that "packages build from source" if they only build ok in buildd.debian.org, which is the reason buildd.debian.org should not be the "standard" to measure if a package builds or not. And that's precisely why we invented build-depends, to make the builds reproducible for everybody (reproducible as in "every time I try to build the package, the package is built"), not just reproducible in buildd.debian.org. But now, in a stable release, we can't even have the assurance that the package will build, because in addition to build-depends, the build machine is now supposed to be a clone of buildd.debian.org in every sense. Why in earth do we want build-depends, then, if not to ensure that the packages will build for everybody? > But it is simply rude trying to use RC bugs saying > To reproduce, please try building with sbuild on a single-CPU machine, as I > did. > for forcing this as high priority upon other people. I'm not forcing anything. It's a FTBFS bug in a release architecture, and it's therefore serious by nature. I'm not really "making" it RC. As far as priority is concerned, I don't dictate the priority by which maintainers should fix their serious bugs. If they want to say "hello" every 29 days in the bug report to avoid the autoremoval, that's up to them. And BTW, I'm *offering* ssh access to the maintainers in case they are unable to reproduce the bugs, yes, such a rude person I am. > Noone else doing build testing would even consider using > a single-CPU machine for that in 2018. That's your opinion. Just because *you* would not do it personally does not mean nobody should do it or that it's a bad idea. I have already shown that it's *cheaper*. And yet you insist that it's not the right(TM) way to build packages. Are you going to pay for the extra money I would spend on virtual machines, just so that I build packages "the only way approved by you" to build packages? > > > The result is the same in both cases - a machine supported by Debian > > > cannot build a package. > > > > Except that in one case we have a bug and we both agree that it's a > > bug, and in the other case it is not a bug and we both agree that it's > > not a bug. > >... > > Please do not make incorrect claims about what I said. > > Let me repeat what I actually said about RAM usage: > > [...] Hmm, no, sorry, I was not referring to the paragraph you quote or the kind of structural problems you describe. I was just talking in a completely general sense, i.e. it is not a bug for a package to "require" 4 GB of RAM to build (I mean "require" as in "it builds with 4 GB but it does not build with 3 GB"). I would hope that we agree on that. Thanks.
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 09:08:30PM +0200, Santiago Vila wrote: >... > There needs to be a *very* powerful reason for a package to "need" > more than one CPU, and so far I have never found a package which > "legitimately" needs more than one CPU. >... Noone disagrees that these are bugs. But it is simply rude trying to use RC bugs saying To reproduce, please try building with sbuild on a single-CPU machine, as I did. for forcing this as high priority upon other people. For the binary packages we are providing as part of our releases to our users it is not relevant whether a single-CPU machine can build a package, and as already explained there are plenty of other reasons why some supported machine might not be able to build some specific package. It is fine if you have your personal pet project of keeping packages buildable on single-CPU machines, and there is some overlap with other peoples pet projects like keeping the hppa port of Debian alive. If someone wants to works on keeping Debian buildable on single-CPU machines or keeping the hppa port alive that is fine - everyone has the right to decide what he wants to do with his own time. But trying to use RC bugs for forcing other people to do the work on such a pet project like keeping Debian buildable on single-CPU machines or keeping the hppa port alive is not OK - there is no excuse for trying to force other people to work on your pet project. Already for some time your attempts to force doing the work on your pet project upon other people has generated perfectly understandable hostility from other developers towards you that obscures all the useful other work you are doing. And yes, this is nothing more than your personal pet project. Noone else doing build testing would even consider using a single-CPU machine for that in 2018. > > The result is the same in both cases - a machine supported by Debian > > cannot build a package. > > Except that in one case we have a bug and we both agree that it's a > bug, and in the other case it is not a bug and we both agree that it's > not a bug. >... Please do not make incorrect claims about what I said. Let me repeat what I actually said about RAM usage: <-- snip --> Bugs that are nearly always involved is that every major release of gcc regresses on memory usage. Including cases where even "-O0 -g0" uses 2 GB RAM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030 For anyone who cares about building on low-end machines fixing such bugs should be the highest priority. <-- snip --> Your "it is not a bug" claim is also completely wrong in the cases where the memory usage of the compiler exceeds the virtual address space on a 32bit architecture, I am constantly submitting workaround patches for such cases - and different from single-CPU building these memory exhaustion bugs are RC build failures that do happen on our buildds. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines
> building != running > > And I am getting really annoyed of your double standard regarding > build requirements. We have to put things in perspective before claiming double-standards. > If a package cannot be built on a single-core machine with 256 MB RAM > due to the number of CPUs, you claim this would be an enormous problem > equal to dropping support for running Debian on that machine. Because I can build approximately 99.99% of all Debian packages with a single-core machine. There needs to be a *very* powerful reason for a package to "need" more than one CPU, and so far I have never found a package which "legitimately" needs more than one CPU. I have yet to see a case where more than one CPU is actually *required*. > But if a package cannot be built on a single-core machine with > 256 MB RAM due to the amount of RAM, this is apparently fine for you. Because only 40% - 50% of Debian packages may be built with such amount of memory, and also, because if a package is not buildable with a given amount of memory, it's usually not the package's fault, but a real requirement from gcc. > The result is the same in both cases - a machine supported by Debian > cannot build a package. Except that in one case we have a bug and we both agree that it's a bug, and in the other case it is not a bug and we both agree that it's not a bug. I don't see what double standards you refer here. Why should I be equally upset for something which is a bug and has an easy fix and for something which is not a bug and it does not have any easy fix at all? Thanks.
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 06:13:13PM +0200, Santiago Vila wrote: >... > > Building all packages on the baseline is never possible, and I already > > tried to explain to you that your "1 CPU with unlimited RAM" scenario is > > pretty far away from the real-world problems. > > This is double standards again. Not being able to build all packages > on the baseline has never been an excuse to not submit baseline > violations (when we find them) as serious. > > You do that, and I fully support it, but for some strange reason > assumming multi-core is "ok to the point of downgrading this bug" > while assuming, say, SSE on i386, is not. > > Please explain that. building != running And I am getting really annoyed of your double standard regarding build requirements. If a package cannot be built on a single-core machine with 256 MB RAM due to the number of CPUs, you claim this would be an enormous problem equal to dropping support for running Debian on that machine. But if a package cannot be built on a single-core machine with 256 MB RAM due to the amount of RAM, this is apparently fine for you. The result is the same in both cases - a machine supported by Debian cannot build a package. Feel free to talk to ask the release team if you think I misinterpret them when saying that single-core FTBFS are not RC, there is nothing left to be discussed between you and me on that topic. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 06:22:23PM +0300, Adrian Bunk wrote: > Noone is talking about no longer supporting running Debian on > single-core systems. Well, you are talking about dropping (or lowering) support for building Debian on single-core systems. But we are not a proprietary software company where what you call "using" is the "usual thing" and building is a "special thing", secondary in importance, that it is only guaranteed to work in the official buildds. We are a free software project, and being able to build the package is essential to what we offer. There is no excuse to take away this essential freedom just because "it builds ok in the buildds", the same way there would not be an excuse to ship packages that do not work just because "they work in the buildds". Just becase less people try the packages by building them does not mean that building is less important than "using" them. So I'll ask again: Why do you want to deprecate building on single-core and not "using" in single-core? If we followed your "real-world" arguments, support for both things should be on par. > Building all packages on the baseline is never possible, and I already > tried to explain to you that your "1 CPU with unlimited RAM" scenario is > pretty far away from the real-world problems. This is double standards again. Not being able to build all packages on the baseline has never been an excuse to not submit baseline violations (when we find them) as serious. You do that, and I fully support it, but for some strange reason assumming multi-core is "ok to the point of downgrading this bug" while assuming, say, SSE on i386, is not. Please explain that. Thanks.
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 04:36:25PM +0200, Santiago Vila wrote: > On Sun, Sep 30, 2018 at 04:32:17PM +0300, Adrian Bunk wrote: >... > But surely that's not an excuse good enough to deprecate Debian on > single-core systems, which is what you apparently are trying to do > here. > > As far as following blindly the rule you say results in something as > grave and deep as deprecating Debian on single-core systems, >... Please stop these unfounded accusations. Noone is talking about no longer supporting running Debian on single-core systems. Building all packages on the baseline is never possible, and I already tried to explain to you that your "1 CPU with unlimited RAM" scenario is pretty far away from the real-world problems. A Raspberry Pi is a quad-core faster than our current armel/armhf buildds. But ARM hardware with >= 8 GB RAM is prohibitively expensive. > > Feel free to ask the release team for a definite statement on that > > if you think I am misunderstanding the position of the release team. > > So what are we really discussing about, severity or RC-ness? > > They are related but they are not exactly the same. > > Is it your claim in this bug that it should not be serious, or you > agree that it's serious and you only claim that it should not be RC? You don't make sense here. "serious" is an RC bug severity. > I ask because some time ago I was going to report FTBFS bugs on > unbuildable packages (because of unmet build-depends) and you told me > that it was too early in the release cycle of buster for that. This was about not reporting issues *that are not present in unstable*. It doesn't make sense that other people spend time debugging problems that are already fixed in unstable and where the fix might migrate to testing in a few days. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 04:32:17PM +0300, Adrian Bunk wrote: > On Sun, Sep 30, 2018 at 03:10:23PM +0200, Santiago Vila wrote: > >... > > In my opinion, you are so much fixated on the idea that "does not fail > > on the buildds" is the "same" as "the bug is not RC" that you would > > end up applying such (wrong) rule > >... > > AFAIK you are not a release manager. What authority do you have to > > decide that this bug is not RC, or not serious? > >... > > In my experience the release team treats "does not fail on buildds of > release architectures" as "the bug is not RC". Well, probably because the buildds are usually considered as "well-configured autobuilders", and a package which FTBFS only in the reporter's machine and not in the buildds has a probability > 0 of being caused by a misconfigured autobuilder. But surely that's not an excuse good enough to deprecate Debian on single-core systems, which is what you apparently are trying to do here. As far as following blindly the rule you say results in something as grave and deep as deprecating Debian on single-core systems, I can't accept following a rule just because "that's what we have always done". > Feel free to ask the release team for a definite statement on that > if you think I am misunderstanding the position of the release team. So what are we really discussing about, severity or RC-ness? They are related but they are not exactly the same. Is it your claim in this bug that it should not be serious, or you agree that it's serious and you only claim that it should not be RC? I ask because some time ago I was going to report FTBFS bugs on unbuildable packages (because of unmet build-depends) and you told me that it was too early in the release cycle of buster for that. Thanks.
Bug#907829: p4est: FTBFS on single CPU machines
On Sun, Sep 30, 2018 at 03:10:23PM +0200, Santiago Vila wrote: >... > In my opinion, you are so much fixated on the idea that "does not fail > on the buildds" is the "same" as "the bug is not RC" that you would > end up applying such (wrong) rule >... > AFAIK you are not a release manager. What authority do you have to > decide that this bug is not RC, or not serious? >... In my experience the release team treats "does not fail on buildds of release architectures" as "the bug is not RC". Feel free to ask the release team for a definite statement on that if you think I am misunderstanding the position of the release team. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines
On Fri, 7 Sep 2018, Adrian Bunk wrote: > On Fri, Sep 07, 2018 at 02:45:31PM +0200, Santiago Vila wrote: > >... > > And I put a very simple example: Imagine that all our amd64 > > autobuilders are Intel and there is a package which FTBFS on AMD. > > > > Are you really trying to tell me that the FTBFS bug would not be > > serious "because it does not happen on buildd.debian.org"? > > That's pretty exactly how things are handled. No, we would not do that, because it would mean users of Debian on Intel would be better supported than users of Debian on AMD. And that would be completely absurd, not to say ridiculous. Users of Intel and AMD should be equally supported, because they are both users of "Debian on amd64", a release architecture. Similarly, users of amd64 on single-cpu and users of amd64 on multi-core are both users of "Debian on amd64", a release architecture, and therefore they should be equally supported. We are the universal operating system and do *not* discriminate among users of the different release architectures, much less among the users of the *same* (release) architecture. Your reply, however, clarifies what I think is the root cause of this disagreement: In my opinion, you are so much fixated on the idea that "does not fail on the buildds" is the "same" as "the bug is not RC" that you would end up applying such (wrong) rule when it makes absolutely no sense to apply it (for example, the Intel/AMD case). It is even more interesting that you decided not to reply to some key questions I asked, so I'll try again: Do you want to deprecate using Debian on single-core, or only building Debian on single-core? I say please show me the standard or official statement saying "Debian on amd64 has to be multi-core", or "Debian on single-core is deprecated or less supported" and you basically reply that "we don't need any official statement, considering the number of affected users is enough". However, I see you have absolutely no problem applying standards in cases like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908384 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909817 In those bugs, the package blindly assumes CPU features that may or may not be present on any Debian system of the same architecture. In this bug (p4est), the package blindly assumes CPU features (being multi-core) that may or may not be present on any Debian system of the same architecture. Why some of those bugs have to be serious and this one only important is still an unexplained mystery, but to me it seems a clear case of double-standards. If we were to consider the "number of people affected", there are probably more users of amd64 on single-core (remember that we have to count everybody who uses Debian on virtual machines) than users of i386 on very old CPUs. AFAIK you are not a release manager. What authority do you have to decide that this bug is not RC, or not serious? I don't mind you moving severities up and down based on "common sense", and in fact I really appreciate all the tidy up work you do with FTBFS bugs. But there does not seem to be a "common sense" here. Instead, we have a case of double-standards. Can I move the priorities of bugs reported by you up and down based on my own criteria as well? Thanks.
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Fri, Sep 07, 2018 at 02:45:31PM +0200, Santiago Vila wrote: >... > And I put a very simple example: Imagine that all our amd64 > autobuilders are Intel and there is a package which FTBFS on AMD. > > Are you really trying to tell me that the FTBFS bug would not be > serious "because it does not happen on buildd.debian.org"? That's pretty exactly how things are handled. An even better example than yours: Some of the current mips buildds do have an FPU, and some don't. Some packages do not build on the buildds without FPU. The solution is to blacklist these packages for the buildds without FPU. And after the blacklisting the RC FTBFS bugs are closed since they are no longer happening on buildd.debian.org. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Fri, Sep 07, 2018 at 10:46:36AM +0300, Adrian Bunk wrote: > On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote: > > > You will have noticed that we usually report FTBFS bugs when a package > > fails to build in any "correctly" configured autobuilder, we don't wait > > for the build failure to happen on buildd.debian.org. > >... > > No release architectures has a single-core autobuilder at buildd.debian.org. > > And it is completely out of the discussion that any would in the future. I was trying to argue that the official autobuilders are not, and should not be, the only measure by which we consider a bug to be serious or not. And I put a very simple example: Imagine that all our amd64 autobuilders are Intel and there is a package which FTBFS on AMD. Are you really trying to tell me that the FTBFS bug would not be serious "because it does not happen on buildd.debian.org"? I would like to believe that you would say "baseline violation", since that's what you said (and I fully agree) here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906697 Now you could maybe argue that using a package and building it are "different" things. And they are in fact different things: Being able to build a package is actually *more* important than being able to use it, because building is a *precondition* for use. If I try to build a package and it fails, there is no package to use. This is the very reason why we consider a FTBFS to be serious. The package is completely unsuitable for release. It prevents the package from working at all because there is no package to use at all. Now the question: Do you want to deprecate using Debian on single-core, or only building Debian on single-core? > > But that's only the best case scenario. The worst case scenario is > > that you build all packages using 2 CPU but only a proportion of them > > support (and benefit from) parallel build. For those who don't we are > > wasting completely the extra CPU. > > > > So no, it's not cheaper in general, and it may be even more expensive. > > Which cloud provider are you using? I have actually used many of them. The most popular ones like vultr, digital ocean or linode offer all-in-one packages in which more CPUs means more RAM and of course more money, usually in powers of two. For example, if we compare the most expensive single-CPU with the cheapest multi-CPU on Vultr, that means going from $10/month to $20/month: https://www.vultr.com/pricing/ This is double the price for something which may or may not take half the time (depending on the package). So yes, I already did the math and definitely building on several CPUs is not cheaper. On GCE you can pay for CPUs and RAM independently, but CPUs are generally more expensive than RAM: https://cloud.google.com/compute/pricing (The disk here is very cheap: $0.04 by GB-month). Why are we discussing about the price, anyway? Are you trying to discriminate against people who build on single-cpu because they are rich, because they are poor, because in your opinion they don't use their resources efficiently, because of what? Thanks.
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Thu, Sep 06, 2018 at 10:46:07PM +0200, Santiago Vila wrote: > On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote: >... > Ok, I started saying "FTBFS = serious" but the above does not really > count as a counter-example. We agree that a FTBFS bug in an unreleased > arch is not RC, that's completely out of the discussion. >... > You will have noticed that we usually report FTBFS bugs when a package > fails to build in any "correctly" configured autobuilder, we don't wait > for the build failure to happen on buildd.debian.org. >... No release architectures has a single-core autobuilder at buildd.debian.org. And it is completely out of the discussion that any would in the future. > That's simply not true. Here is the math: > > In the best case scenario, a machine with 2 CPU will usually cost > double than a single-CPU. It will build the package in half of the > time, but since it cost double per minute, the total cost is > approximately the same, not cheaper at all. > > But that's only the best case scenario. The worst case scenario is > that you build all packages using 2 CPU but only a proportion of them > support (and benefit from) parallel build. For those who don't we are > wasting completely the extra CPU. > > So no, it's not cheaper in general, and it may be even more expensive. Which cloud provider are you using? Your math assumes that expensive resources like RAM or storage would be free, and not cost you more when you have to provision them longer due to the longer build time. If you want to do do the math properly, you have to take into account that faster build times mean fewer seconds you also have to pay for everything else. > > Debian packages should build on single-core machines and it is a bug > > when they don't, but it is mostly irrelevant in practice. > > Hmm, "mostly irrelevant" and "in practice". > > The problem with that is that it's highly subjective. We don't > "optimize for Internet Explorer". We follow standards, and being > multi-core is not an intrinsic property of the amd64 architeture. > > You seem to think that because desktop computers are almost always > multi-core these days, "these days" was 10 years ago. Today even cheap embedded devices like a Raspberry Pi are quadcore. >... > In practice, there is only a *handful* of packages that do not build > on single-core. The actual figure is closer to 5 than 10, 20 or > whatever is the number that you might be guessing. > > Would it be the same for you if this number was 5 than if it was 200 > or 300? (BTW: What was the approximate number you had in mind?) Yes. These are bugs, but in reality "FTBFS on hppa" is the most relevant consequence. >... > You keep talking about "not RC" for "practical" reasons, but for me it > is *really* practical that I can build 99.98% of all Debian packages > on single-cpu machines. It is not also a practical thing for Debian > that people can make QA in a cheap way, without wasting CPUs? >... When you buy hardware today you usually get more cores than you can use, but RAM costs a fortune. Like it is a real problem that plenty complete ARM quadcore systems like the Raspberry Pi are available in the $30-40 range, but anything with >= 8 GB RAM is ridiculously expensive. This is the core reason why you are facing so much resistance when you are trying to use release critical bugs to force people to spend their spare time on something that has no actual practical relevance. It also obscures the many useful bug reports you submit when you are insisting that whatever fails to build in your weird setup should be considered release critical. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Thu, Sep 06, 2018 at 09:01:02PM +0300, Adrian Bunk wrote: > On Mon, Sep 03, 2018 at 03:31:30PM +0200, Santiago Vila wrote: > > > FTBFS bugs have always been serious. Do you have a statement from a > > member of the release team saying specifically that those bugs > > should be buster-ignored? > > > > (That's what we should really do, btw, if we wanted a serious bug not > > to be RC). > > https://release.debian.org/buster/rc_policy.txt > ... > 4. Autobuilding > ... > Packages must autobuild without failure on all architectures on > which they are supported. > ... Ok, I started saying "FTBFS = serious" but the above does not really count as a counter-example. We agree that a FTBFS bug in an unreleased arch is not RC, that's completely out of the discussion. In our case single-core amd64 is the same arch as multi-core amd64, so a FTBTS in single-core amd64 is a FTBFS in amd64 for all purposes, and amd64 is a released architecture. Moreover, the above paragraph has more than one possible interpretation. For some people (maybe you), "autobuild" in the phrase above is only what happens in buildd.debian.org. For me, autobuilding is just what autobuilders do. There is a set of autobuilders in buildd.debian.org, there is another in reproducible-builds, and I also have my own autobuilders. You will have noticed that we usually report FTBFS bugs when a package fails to build in any "correctly" configured autobuilder, we don't wait for the build failure to happen on buildd.debian.org. Literally tons and tons of FTBFS bugs have been filed on the basis that the package failed to build in standard-configured autobuilders (not necessarily buildd.debian.org). I think this supports my interpretation of "autobuilding". > Other cases of problems that do not happen when autobuilding like for > example building with locales other than C are also usually considered > Severity: important. I agree with this, for a FTBFS bug to be reported as serious, it usually needs to happen in an autobuilder which is not misconfigured. The standard autobuilder has LANG=C and if not we call it misconfigured, and for that reason most people do not usually report those bugs as important. But being single-core in no way is a "misconfiguration", and I refuse to consider such thing on the same "level" as building with a locale different than C. An autobuilder which is single-core is not "defective". [...] > > Missing build-depends, for example, have always been serious bugs, > > even if they do not happen in the official buildds. > > > > Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC" > > are not always the same thing. > > This case has an own item in the list: > > https://release.debian.org/buster/rc_policy.txt > ... > 4. Autobuilding > > Packages must list any packages they require to build beyond those > that are "build-essential" in the appropriate Build-Depends: fields. > ... > > There doesn't seem to be a similar special case for single-core machines. I'm not sure what exactly you mean here. There is not a special case for Intel CPUs. If official autobuilders on amd64 had all of them Intel CPUs and a package FTBFS on AMD, it would be a serious bug, because being Intel would be accidental, not part of the "standard to build Debian packages". > > You are perhaps assuming that I'm trying to build all packages on a > > single machine which is able to build everything. > >... > > No, what I am saying is that you are focussing on a case that is > mostly irrelevant in practice, and that trying to make it a high > priority for other people to solve such issues is therefore a > waste of time. I'm not really "focusing" on single-core, it's just what I usually do to build packages, that's all. In my QA work, 99% of the bugs I find are not related to the number of CPUs at all. Our problem is that you are trying to make single-core users as second-class citizens of the amd64 architecture (in a similar way unreleased architectures are already second-class because their FTBFS may not be serious), while I still believe they deserve exactly the same level of support of multi-core users, because there is only one amd64 architeture, not two. > [...] > For VMs it would be a waste of money to pay for a VM that has a huge > amount of RAM and storage but only one CPU for building packages. > It is both faster and cheaper to use a multi-CPU VM for that. That's simply not true. Here is the math: In the best case scenario, a machine with 2 CPU will usually cost double than a single-CPU. It will build the package in half of the time, but since it cost double per minute, the total cost is approximately the same, not cheaper at all. But that's only the best case scenario. The worst case scenario is that you build all packages using 2 CPU but only a proportion of them support (and benefit from) parallel build. For those who don't we are wasting completely the extra CPU. So no, it's not
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Sep 03, 2018 at 03:31:30PM +0200, Santiago Vila wrote: > On Mon, Sep 03, 2018 at 01:03:27PM +0300, Adrian Bunk wrote: > > On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote: > > >... > > > This single-CPU thing has been discussed before and the bugs have > > > never stopped being serious: > > > > > > https://lists.debian.org/debian-devel/2017/02/msg00380.html > > >... > > > > Do you have a statement from a member of the release team saying so? > > FTBFS bugs have always been serious. Do you have a statement from a > member of the release team saying specifically that those bugs > should be buster-ignored? > > (That's what we should really do, btw, if we wanted a serious bug not > to be RC). https://release.debian.org/buster/rc_policy.txt ... 4. Autobuilding ... Packages must autobuild without failure on all architectures on which they are supported. ... Other cases of problems that do not happen when autobuilding like for example building with locales other than C are also usually considered Severity: important. > > >... > > > Ok, my autobuilder is not one of buildd.debian.org. So what? Packages > > > *must* be buildable on any system where Debian itself runs (provided > > > there is enough RAM and disk), i.e. on any autobuilder which is not > > > misconfigured. Having a single CPU does not count as a "misconfiguration". > > > > It is completely arbitrary if you want to define that requiring any > > amount of RAM or disk usage is fine, but a similar requirement for > > the number of CPUs must not happen. > > No, it's not arbitrary at all, because requiring a big amount of RAM > is not a bug [*], while requiring 2 CPUs has always been a serious bug. > > [*] Only in very extreme cases like this one I went ahead and filed a bug: >... Bugs that are nearly always involved is that every major release of gcc regresses on memory usage. Including cases where even "-O0 -g0" uses 2 GB RAM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79030 For anyone who cares about building on low-end machines fixing such bugs should be the highest priority. > > > Nothing else, like CPU speed, number of CPUs, instruction set above > > > the baseline amd64, etc. should be assumed or taken for granted > > > "just because buildd.debian.org is that way". > > > > > > Otherwise the package will have a hidden and undeclared > > > "build-depends: buildd.debian.org" (so to speak), and I would consider > > > such build restriction completely unacceptable. > > > > > > No, we don't follow "de-facto standards", we just follow standards, > > > and so far we have not formally declared single-cpu systems as "unsuitable > > > for building" (by way of general resolution or by policy). > > >... > > > > What packages actually follow is "builds on the buildds". > > No, that's only a close approximation of what we do, but it's not what we do. > > Building ok in buildd.debian.org is a necessary condition but it's not > sufficient. > > Missing build-depends, for example, have always been serious bugs, > even if they do not happen in the official buildds. > > Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC" > are not always the same thing. This case has an own item in the list: https://release.debian.org/buster/rc_policy.txt ... 4. Autobuilding Packages must list any packages they require to build beyond those that are "build-essential" in the appropriate Build-Depends: fields. ... There doesn't seem to be a similar special case for single-core machines. >... > > The machine you want to enable to build all packages would > > have the following specs: > > - 1 CPU > > - 16 GB RAM > > - 75 GB storage > > > > This is an insane configuration. > > You are perhaps assuming that I'm trying to build all packages on a > single machine which is able to build everything. >... No, what I am saying is that you are focussing on a case that is mostly irrelevant in practice, and that trying to make it a high priority for other people to solve such issues is therefore a waste of time. In reality people have nearly always multi-core machines but often not enough RAM. On 32bit the address space is an additional problem. Like Debian has a huge userbase on the Raspberry Pi that has 4 CPUs but only 1 GB RAM. Single-core machines today are either ancient or low-end embedded, and in either case the amount of RAM is the biggest problem. "FTBFS on hppa" is pretty much the worst consequence in practice when a package does not built with one core. For VMs it would be a waste of money to pay for a VM that has a huge amount of RAM and storage but only one CPU for building packages. It is both faster and cheaper to use a multi-CPU VM for that. Debian packages should build on single-core machines and it is a bug when they don't, but it is mostly irrelevant in practice. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Sep 03, 2018 at 01:03:27PM +0300, Adrian Bunk wrote: > On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote: > >... > > This single-CPU thing has been discussed before and the bugs have > > never stopped being serious: > > > > https://lists.debian.org/debian-devel/2017/02/msg00380.html > >... > > Do you have a statement from a member of the release team saying so? FTBFS bugs have always been serious. Do you have a statement from a member of the release team saying specifically that those bugs should be buster-ignored? (That's what we should really do, btw, if we wanted a serious bug not to be RC). > >... > > Ok, my autobuilder is not one of buildd.debian.org. So what? Packages > > *must* be buildable on any system where Debian itself runs (provided > > there is enough RAM and disk), i.e. on any autobuilder which is not > > misconfigured. Having a single CPU does not count as a "misconfiguration". > > It is completely arbitrary if you want to define that requiring any > amount of RAM or disk usage is fine, but a similar requirement for > the number of CPUs must not happen. No, it's not arbitrary at all, because requiring a big amount of RAM is not a bug [*], while requiring 2 CPUs has always been a serious bug. [*] Only in very extreme cases like this one I went ahead and filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852106 but never as a serious bug. > > Nothing else, like CPU speed, number of CPUs, instruction set above > > the baseline amd64, etc. should be assumed or taken for granted > > "just because buildd.debian.org is that way". > > > > Otherwise the package will have a hidden and undeclared > > "build-depends: buildd.debian.org" (so to speak), and I would consider > > such build restriction completely unacceptable. > > > > No, we don't follow "de-facto standards", we just follow standards, > > and so far we have not formally declared single-cpu systems as "unsuitable > > for building" (by way of general resolution or by policy). > >... > > What packages actually follow is "builds on the buildds". No, that's only a close approximation of what we do, but it's not what we do. Building ok in buildd.debian.org is a necessary condition but it's not sufficient. Missing build-depends, for example, have always been serious bugs, even if they do not happen in the official buildds. Therefore "builds in buildd.debian.org" and "it has a FTBFS which is RC" are not always the same thing. > We don't need a GR to formally declare that > - some packages don't build with only 1 CPU, > - some packages don't build with only 8 GB RAM > - some packages don't build with only 70 GB storage No, what we don't need is a GR to declare that FTBFS bugs are serious. If you think certain serious bugs should not be RC, that's an issue for the release managers to decide, and we would have to use buster-ignore for that. What you did here sounds like "downgrade because this is not RC because I say so" to me. > >... > > And no, single-cpu is not exotic. You are only considering physical > > machines, but there is a whole world of virtualization out there where > > you can still choose the number of CPUs in the system, and single-cpu > > is still cheaper (and I guess it will still be for a long time). > > Yes, but that usually also limits the amount of RAM You are speaking about linode, digital ocean, vultr, etc. But other providers, like GCE or mivocloud, allow changing CPUs and RAM in an independent way, so that's not really a problem for me. > and you are fine with packages using any amount of that. I'm not really "fine" with any amount of RAM, but I accept as a fact of life that some packages will need a lot of RAM. But I can't accept as a fact of life that a package needs several CPUs to build, because that's a serious bug. In this case it's the package the one needing a change, not my building setup. [ You will notice that not even for this particular report I have needed a multi-cpu machine. The build log suggested that it was a "number-of-cpu" problem. The maintainer has suggested a patch, I tried it, and it worked ]. > The machine you want to enable to build all packages would > have the following specs: > - 1 CPU > - 16 GB RAM > - 75 GB storage > > This is an insane configuration. You are perhaps assuming that I'm trying to build all packages on a single machine which is able to build everything. That would be insane indeed, but that's *not* what I do, because it would be a waste of resources. I build packages in several different machines, I keep track of the amount of RAM required by each package so that I'm efficient at using RAM. Also, some of my virtual machines are self-hosted by KVM and virt-manager, so I can easily have a single CPU and a lot of RAM if required. On the contrary, I do *not* keep track of packages requiring more than one CPU in order to build them in a different machine, because that's a serious FTBFS bug and I should never
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Sep 03, 2018 at 09:23:54AM +0200, Graham Inggs wrote: > Hi Santiago > > On 2 September 2018 at 19:21, Santiago Vila wrote: > > My guess is that this is a bug in p4est but it's triggered by a build > > depends > > which changed behaviour somewhere between 2017-12-24 (where version 1.1-5 > > still built ok for me in buster) and 2018-06-03 (where it did not anymore). > > Yes, openmpi flipped the default for oversubscription *again*, see #849974. > > Would you please check whether the following change to debian/rules > fixes it for you? > > --- a/debian/rules > +++ b/debian/rules > @@ -3,6 +3,7 @@ > include /usr/share/dpkg/pkg-info.mk > > export OMPI_MCA_plm_rsh_agent=/bin/false > +export OMPI_MCA_rmaps_base_oversubscribe=1 > > %: > dh $@ > Yes, it fixes it. Thanks a lot.
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Sep 03, 2018 at 01:22:47AM +0200, Santiago Vila wrote: >... > This single-CPU thing has been discussed before and the bugs have > never stopped being serious: > > https://lists.debian.org/debian-devel/2017/02/msg00380.html >... Do you have a statement from a member of the release team saying so? >... > Ok, my autobuilder is not one of buildd.debian.org. So what? Packages > *must* be buildable on any system where Debian itself runs (provided > there is enough RAM and disk), i.e. on any autobuilder which is not > misconfigured. Having a single CPU does not count as a "misconfiguration". It is completely arbitrary if you want to define that requiring any amount of RAM or disk usage is fine, but a similar requirement for the number of CPUs must not happen. > Nothing else, like CPU speed, number of CPUs, instruction set above > the baseline amd64, etc. should be assumed or taken for granted > "just because buildd.debian.org is that way". > > Otherwise the package will have a hidden and undeclared > "build-depends: buildd.debian.org" (so to speak), and I would consider > such build restriction completely unacceptable. > > No, we don't follow "de-facto standards", we just follow standards, > and so far we have not formally declared single-cpu systems as "unsuitable > for building" (by way of general resolution or by policy). >... What packages actually follow is "builds on the buildds". We don't need a GR to formally declare that - some packages don't build with only 1 CPU, - some packages don't build with only 8 GB RAM - some packages don't build with only 70 GB storage >... > And no, single-cpu is not exotic. You are only considering physical > machines, but there is a whole world of virtualization out there where > you can still choose the number of CPUs in the system, and single-cpu > is still cheaper (and I guess it will still be for a long time). Yes, but that usually also limits the amount of RAM and you are fine with packages using any amount of that. The machine you want to enable to build all packages would have the following specs: - 1 CPU - 16 GB RAM - 75 GB storage This is an insane configuration. Also notice that the "75 GB storage" is exactly the amount provisioned today on the amd64 buildds, there are packages that have workarounds for being able to build on the buildds with only 75 GB storage - and won't build with even less. Don't get me wrong, a package not building on a machine with 1 CPU is a bug that should be reported. But trying to enforce to be able to build every single package in the archive on single-CPU machines is something that strikes me as a huge waste of time - we have so many far more relevant bugs that should be debugged and fixed before that. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
Hi Santiago On 2 September 2018 at 19:21, Santiago Vila wrote: > My guess is that this is a bug in p4est but it's triggered by a build depends > which changed behaviour somewhere between 2017-12-24 (where version 1.1-5 > still built ok for me in buster) and 2018-06-03 (where it did not anymore). Yes, openmpi flipped the default for oversubscription *again*, see #849974. Would you please check whether the following change to debian/rules fixes it for you? --- a/debian/rules +++ b/debian/rules @@ -3,6 +3,7 @@ include /usr/share/dpkg/pkg-info.mk export OMPI_MCA_plm_rsh_agent=/bin/false +export OMPI_MCA_rmaps_base_oversubscribe=1 %: dh $@ Regards Graham
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Mon, Sep 03, 2018 at 01:33:30AM +0300, Adrian Bunk wrote: > On Sun, Sep 02, 2018 at 11:19:04PM +0200, Santiago Vila wrote: > > This is not an architecture-specific bug which only happens on > > unreleased architectures. > > > > Instead, this happened to me on amd64, which is a release architecture. > > But not on any autobuilder for a release architecture. My autobuilder is for amd64, which is a release architecture. Ok, my autobuilder is not one of buildd.debian.org. So what? Packages *must* be buildable on any system where Debian itself runs (provided there is enough RAM and disk), i.e. on any autobuilder which is not misconfigured. Having a single CPU does not count as a "misconfiguration". Nothing else, like CPU speed, number of CPUs, instruction set above the baseline amd64, etc. should be assumed or taken for granted "just because buildd.debian.org is that way". Otherwise the package will have a hidden and undeclared "build-depends: buildd.debian.org" (so to speak), and I would consider such build restriction completely unacceptable. No, we don't follow "de-facto standards", we just follow standards, and so far we have not formally declared single-cpu systems as "unsuitable for building" (by way of general resolution or by policy). This single-CPU thing has been discussed before and the bugs have never stopped being serious: https://lists.debian.org/debian-devel/2017/02/msg00380.html Please let us not have such discussion again. And no, single-cpu is not exotic. You are only considering physical machines, but there is a whole world of virtualization out there where you can still choose the number of CPUs in the system, and single-cpu is still cheaper (and I guess it will still be for a long time). Thanks.
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Sun, Sep 02, 2018 at 11:19:04PM +0200, Santiago Vila wrote: > On Sun, Sep 02, 2018 at 09:55:25PM +0300, Adrian Bunk wrote: > > Control: severity -1 important > > > > On Sun, Sep 02, 2018 at 05:21:28PM +, Santiago Vila wrote: > > >... > > > The error message (not enough slots available) suggests that this package > > > is > > > not ready to be built on single-CPU machines. > > >... > > > > This matches the build failure on hppa, but is not a problem for any > > release architecture buildd. > > Hmm, I don't follow your line of reasoning here. > > This is not an architecture-specific bug which only happens on > unreleased architectures. > > Instead, this happened to me on amd64, which is a release architecture. But not on any autobuilder for a release architecture. > The fact that our current amd64 autobuilders have several CPUs is > *accidental*, not a *property* of the amd64 architecture. It is not accidental and it is not a property of the amd64 architecture. It is de facto mandatory for every autobuilder for a release architecture. All autobuilders for all 10 release architectures have more than one CPU, s390x buildds have 2 CPUs and all others at least 4 CPUs. Single-CPU has become very exotic. Today even $30 embedded boards have 4 CPUs, a machine that has the >= 4 GB RAM required for a buildd usually has more than one CPU. And an autobuilders needs more than one CPU, since it shouldn't regress compared to the slowest current autobuilders that have 4 CPUs. Lower-end embedded devices like the $5 Raspberry Pi Zero might have only one CPU, but they are both from CPU power and amount of RAM far too weak for an autobuilder. > Thanks. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
On Sun, Sep 02, 2018 at 09:55:25PM +0300, Adrian Bunk wrote: > Control: severity -1 important > > On Sun, Sep 02, 2018 at 05:21:28PM +, Santiago Vila wrote: > >... > > The error message (not enough slots available) suggests that this package is > > not ready to be built on single-CPU machines. > >... > > This matches the build failure on hppa, but is not a problem for any > release architecture buildd. Hmm, I don't follow your line of reasoning here. This is not an architecture-specific bug which only happens on unreleased architectures. Instead, this happened to me on amd64, which is a release architecture. The fact that our current amd64 autobuilders have several CPUs is *accidental*, not a *property* of the amd64 architecture. Thanks.
Bug#907829: p4est: FTBFS on single CPU machines (?)
Control: severity -1 important On Sun, Sep 02, 2018 at 05:21:28PM +, Santiago Vila wrote: >... > The error message (not enough slots available) suggests that this package is > not ready to be built on single-CPU machines. >... This matches the build failure on hppa, but is not a problem for any release architecture buildd. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907829: p4est: FTBFS on single CPU machines (?)
Package: src:p4est Version: 1.1-5 Severity: serious Tags: ftbfs Dear maintainer: I tried to build this package in buster but it failed: [...] debian/rules build-arch dh build-arch dh_update_autotools_config -a debian/rules override_dh_autoreconf make[1]: Entering directory '/<>' echo 1.1 > .tarball-version echo 1.1 > sc/.tarball-version dh_autoreconf ./bootstrap Running bootstrap in subdirectory sc --- This is the bootstrap script for libsc --- It is NOT required to run bootstrap to build from a tar.gz archive Development requires a libtool recent enough to contain LT_INIT (2.2 works) Current directory is /<>/sc libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'. [... snipped ...] ./test/sc_test_sort Either request fewer slots for your application, or make more slots available for use. -- FAIL test/sc_test_sort (exit status: 1) FAIL: test/sc_test_sortb -- There are not enough slots available in the system to satisfy the 2 slots that were requested by the application: ./test/sc_test_sortb Either request fewer slots for your application, or make more slots available for use. -- FAIL test/sc_test_sortb (exit status: 1) Testsuite summary for libsc 1.1 # TOTAL: 12 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 12 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to p4...@librelist.com make[4]: *** [Makefile:2031: test-suite.log] Error 1 make[4]: Leaving directory '/<>/sc' make[3]: *** [Makefile:2139: check-TESTS] Error 2 make[3]: Leaving directory '/<>/sc' make[2]: *** [Makefile:2426: check-am] Error 2 make[2]: Leaving directory '/<>/sc' make[1]: *** [Makefile:3388: check-recursive] Error 1 make[1]: Leaving directory '/<>' dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:8: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 To reproduce, please try building with sbuild on a single-CPU machine, as I did. The error message (not enough slots available) suggests that this package is not ready to be built on single-CPU machines. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. My guess is that this is a bug in p4est but it's triggered by a build depends which changed behaviour somewhere between 2017-12-24 (where version 1.1-5 still built ok for me in buster) and 2018-06-03 (where it did not anymore). Thanks.
