Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.rc > #389991 > unrolled thread

Bug#1103113: on filing FTBFS due to out-of-memory on i386

Back to article view | Back to linux.debian.bugs.rc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1103113: on filing FTBFS due to out-of-memory on i386 Paul Gevers <elbrus@debian.org> - 2025-04-17 09:20 +0200
    Processed: on filing FTBFS due to out-of-memory on i386 "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-04-17 09:20 +0200
    Bug#1103113: on filing FTBFS due to out-of-memory on i386 Jérémy Lal <kapouer@melix.org> - 2025-04-17 09:40 +0200
    Bug#1103113: on filing FTBFS due to out-of-memory on i386 Lucas Nussbaum <lucas@debian.org> - 2025-04-17 10:10 +0200
      Bug#1103113: on filing FTBFS due to out-of-memory on i386 Paul Gevers <elbrus@debian.org> - 2025-04-17 10:50 +0200

#389991 — Bug#1103113: on filing FTBFS due to out-of-memory on i386

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 moreinfo

Hi Lucas,

[Release Team member hat on]

I always appreciate your QA work on rebuilding Debian, but I'm wondering 
what the value is of filing out-of-memory FTBFS bugs on a 32 bit 
architecture for source packages that only builds arch:all binaries. 
arch:all binaries in Debian are build on 64 bits architectures with more 
memory space than the 32 bits architectures, so I don't think it's worth 
the stress of the maintainers (of arch:all binaries only sources) to 
look into out-of-memory FTBFS RC problems on low address space systems 
(in this case it looks like assumptions in a test, but still). Related, 
arch:all only source packages have no way to avoid you trying to build 
on i386. Can you please share your opinion?

I haven't demoted the severity of the (currently one) bug I spotted just 
yet, to enable you to respond, but as you can see from my response, I'm 
inclined to do that.

Paul

[toc] | [next] | [standalone]

#389993 — Processed: on filing FTBFS due to out-of-memory on i386

Processing control commands:

> tags -1 moreinfo
Bug #1103113 [src:emscripten] emscripten: FTBFS in testing/i386: RuntimeError: Aborted(RangeError: WebAssembly.instantiate(): Out of memory: Cannot allocate Wasm memory for new instance)
Added tag(s) moreinfo.

-- 
1103113: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103113
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#389995

[Multipart message — attachments visible in raw view] — view raw

Le jeu. 17 avr. 2025 à 09:15, Paul Gevers <elbrus@debian.org> a écrit :

> Control: tags -1 moreinfo
>
> Hi Lucas,
>
> [Release Team member hat on]
>
> I always appreciate your QA work on rebuilding Debian, but I'm wondering
> what the value is of filing out-of-memory FTBFS bugs on a 32 bit
> architecture for source packages that only builds arch:all binaries.
> arch:all binaries in Debian are build on 64 bits architectures with more
> memory space than the 32 bits architectures, so I don't think it's worth
> the stress of the maintainers (of arch:all binaries only sources) to
> look into out-of-memory FTBFS RC problems on low address space systems
> (in this case it looks like assumptions in a test, but still). Related,
> arch:all only source packages have no way to avoid you trying to build
> on i386. Can you please share your opinion?
>
I haven't demoted the severity of the (currently one) bug I spotted just
> yet, to enable you to respond, but as you can see from my response, I'm
> inclined to do that.
>

About the bug itself: I'm inclined to fix it - the test suite is already
trimmed down
(because it would be too much resources to run it fully), so I can make sure
to not run tests requiring 2gb+ of memory on 32-bits archs.

Jérémy

[toc] | [prev] | [next] | [standalone]

#389998

Hi Paul,

On 17/04/25 at 09:12 +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Lucas,
> 
> [Release Team member hat on]
> 
> I always appreciate your QA work on rebuilding Debian, but I'm wondering
> what the value is of filing out-of-memory FTBFS bugs on a 32 bit
> architecture for source packages that only builds arch:all binaries.
> arch:all binaries in Debian are build on 64 bits architectures with more
> memory space than the 32 bits architectures, so I don't think it's worth the
> stress of the maintainers (of arch:all binaries only sources) to look into
> out-of-memory FTBFS RC problems on low address space systems (in this case
> it looks like assumptions in a test, but still). Related, arch:all only
> source packages have no way to avoid you trying to build on i386. Can you
> please share your opinion?
> 
> I haven't demoted the severity of the (currently one) bug I spotted just
> yet, to enable you to respond, but as you can see from my response, I'm
> inclined to do that.

In general: when mass-filing bugs, I try hard to find the right balance
between the time spent filing bugs, and the amount of errors I make.
(Filing bugs later in the release process translates to giving less time to
maintainers to work on them, so there's some value to filing bugs
early, and thus to be efficient at filing bugs.) But yes sometimes I make
mistake, and bugs are reported when they shouldn't. I'm very fine with the
severity being downgraded or discussed. I see bugs as "facts about
packages", and the fact that the test suite fails on i386 exists
independently from the severity assigned to that fact by the release
team. Of course we don't need to track all "facts" in a bug tracker, but
that one sounds useful enough to be tracked.

Regarding the case of arch:all build failures on i386, I think they are
worth reporting to identify that a package that is declared to work on
all architectures does not work on i386 (or does not completely work on
i386). Even if we don't have a great way to translate that to packages
relationships (maybe we should generalize something like Depends:
unsupported-architecture [i386]).

In the specific case of OOMs on 32b architectures, there were only a
handful of bugs so it's probably simpler to address them on a case by
case basis. #1091239 and #1103134 are two other ones, but removing
support for R on 32b architectures is discussed elsewhere.

So, unless you ask me to stop doing so, I will continue to file such
bugs; I will file them as severity:serious by default (unless I can
identify beforehand that they should be filed at a lower severity); I'm
totally fine with the severity being lowered either by the maintainer or
the release team.

Lucas

[toc] | [prev] | [next] | [standalone]

#390004

[Multipart message — attachments visible in raw view] — view raw

Hi Lucas,

Thanks for the reply, much appreciated.

On 17-04-2025 09:58, Lucas Nussbaum wrote:
> In general: when mass-filing bugs, I try hard to find the right balance
> between the time spent filing bugs, and the amount of errors I make.


I totally recognize that as I'm also filing a huge amount of QA bugs.

> the fact that the test suite fails on i386 exists
> independently from the severity assigned to that fact by the release
> team. Of course we don't need to track all "facts" in a bug tracker, but
> that one sounds useful enough to be tracked.


I agree. I was mostly discussing the severity indeed. I was just 
wondering (but missed to mention that explicitly in my reply) how hard 
or easy it would be to warn you before filing that this issue might be 
due to memory issues and hence file it as important or add additional 
text to the template. Maybe a paragraph about testing on i386 could be 
added, mentioning this explicitly? (this == i386 being low on memory 
space and downgrading is ok if maintainers think that's the right thing 
to do. The latter is of course always true, but I think some maintainers 
might be reluctant and see you as an authority on this matter).

> Regarding the case of arch:all build failures on i386, I think they are
> worth reporting to identify that a package that is declared to work on
> all architectures does not work on i386 (or does not completely work on
> i386). Even if we don't have a great way to translate that to packages
> relationships (maybe we should generalize something like Depends:
> unsupported-architecture [i386]).


Or Build-Depends? For if the package works, but the build doesn't.

> So, unless you ask me to stop doing so, I will continue to file such
> bugs; I will file them as severity:serious by default


Agree.

Paul

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.rc

csiph-web