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

<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Le jeu. 17 avr. 2025 à 09:15, Paul Gevers &lt;<a href="mailto:elbrus@debian.org">elbrus@debian.org</a>&gt; a écrit :<br></

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Control: tags -1 moreinfo<br>

Hi Lucas,<br>

[Release Team member hat on]<br>

I always appreciate your QA work on rebuilding Debian, but I&#39;m wondering <br>
what the value is of filing out-of-memory FTBFS bugs on a 32 bit <br> architecture for source packages that only builds arch:all binaries. <br> arch:all binaries in Debian are build on 64 bits architectures with more <br> memory space than the 32 bits architectures, so I don&#39;t think it&#39;s worth <br>
the stress of the maintainers (of arch:all binaries only sources) to <br>
look into out-of-memory FTBFS RC problems on low address space systems <br>
(in this case it looks like assumptions in a test, but still). Related, <br> arch:all only source packages have no way to avoid you trying to build <br>
on i386. Can you please share your opinion? <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I haven&#39;t demoted the severity of the (currently one) bug I spotted just <br>
yet, to enable you to respond, but as you can see from my response, I&#39;m <br>
inclined to do that.<br></blockquote><div><br></div><div>About the bug itself: I&#39;m inclined to fix it - the test suite is already trimmed down</div><div>(because it would be too much resources to run it fully), so I can make sure</div><div>to not run
tests requiring 2gb+ of memory on 32-bits archs.</div><div><br></div><div>Jérémy</div></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

To: 1103113@bugs.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tRty0EDJP8A85ylibeNmwnKc
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgTHVjYXMsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LCBtdWNoIGFwcHJlY2lhdGVkLg0K DQpPbiAxNy0wNC0yMDI1IDA5OjU4LCBMdWNhcyBOdXNzYmF1bSB3cm90ZToNCj4gSW4gZ2Vu ZXJhbDogd2hlbiBtYXNzLWZpbGluZyBidWdzLCBJIHRyeSBoYXJkIHRvIGZpbmQgdGhlIHJp Z2h0IGJhbGFuY2UNCj4gYmV0d2VlbiB0aGUgdGltZSBzcGVudCBmaWxpbmcgYnVncywgYW5k IHRoZSBhbW91bnQgb2YgZXJyb3JzIEkgbWFrZS4NCg0KDQpJIHRvdGFsbHkgcmVjb2duaXpl IHRoYXQgYXMgSSdtIGFsc28gZmlsaW5nIGEgaHVnZSBhbW91bnQgb2YgUUEgYnVncy4NCg0K PiB0aGUgZmFjdCB0aGF0IHRoZSB0ZXN0IHN1aXRlIGZhaWxzIG9uIGkzODYgZXhpc3RzDQo+ IGluZGVwZW5kZW50bHkgZnJvbSB0aGUgc2V2ZXJpdHkgYXNzaWduZWQgdG8gdGhhdCBmYWN0 IGJ5IHRoZSByZWxlYXNlDQo+IHRlYW0uIE9mIGNvdXJzZSB3ZSBkb24ndCBuZWVkIHRvIHRy YWNrIGFsbCAiZmFjdHMiIGluIGEgYnVnIHRyYWNrZXIsIGJ1dA0KPiB0aGF0IG9uZSBzb3Vu ZHMgdXNlZnVsIGVub3VnaCB0byBiZSB0cmFja2VkLg0KDQoNCkkgYWdyZWUuIEkgd2FzIG1v c3RseSBkaXNjdXNzaW5nIHRoZSBzZXZlcml0eSBpbmRlZWQuIEkgd2FzIGp1c3QgDQp3b25k ZXJpbmcgKGJ1dCBtaXNzZWQgdG8gbWVudGlvbiB0aGF0IGV4cGxpY2l0bHkgaW4gbXkgcmVw bHkpIGhvdyBoYXJkIA0Kb3IgZWFzeSBpdCB3b3VsZCBiZSB0byB3YXJuIHlvdSBiZWZvcmUg ZmlsaW5nIHRoYXQgdGhpcyBpc3N1ZSBtaWdodCBiZSANCmR1ZSB0byBtZW1vcnkgaXNzdWVz IGFuZCBoZW5jZSBmaWxlIGl0IGFzIGltcG9ydGFudCBvciBhZGQgYWRkaXRpb25hbCANCnRl eHQgdG8gdGhlIHRlbXBsYXRlLiBNYXliZSBhIHBhcmFncmFwaCBhYm91dCB0ZXN0aW5nIG9u IGkzODYgY291bGQgYmUgDQphZGRlZCwgbWVudGlvbmluZyB0aGlzIGV4cGxpY2l0bHk/ICh0 aGlzID09IGkzODYgYmVpbmcgbG93IG9uIG1lbW9yeSANCnNwYWNlIGFuZCBkb3duZ3JhZGlu ZyBpcyBvayBpZiBtYWludGFpbmVycyB0aGluayB0aGF0J3MgdGhlIHJpZ2h0IHRoaW5nIA0K dG8gZG8uIFRoZSBsYXR0ZXIgaXMgb2YgY291cnNlIGFsd2F5cyB0cnVlLCBidXQgSSB0aGlu ayBzb21lIG1haW50YWluZXJzIA0KbWlnaHQgYmUgcmVsdWN0YW50IGFuZCBzZWUgeW91IGFz IGFuIGF1dGhvcml0eSBvbiB0aGlzIG1hdHRlcikuDQoNCj4gUmVnYXJkaW5nIHRoZSBjYXNl IG9mIGFyY2g6YWxsIGJ1aWxkIGZhaWx1cmVzIG9uIGkzODYsIEkgdGhpbmsgdGhleSBhcmUN Cj4gd29ydGggcmVwb3J0aW5nIHRvIGlkZW50aWZ5IHRoYXQgYSBwYWNrYWdlIHRoYXQgaXMg ZGVjbGFyZWQgdG8gd29yayBvbg0KPiBhbGwgYXJjaGl0ZWN0dXJlcyBkb2VzIG5vdCB3b3Jr IG9uIGkzODYgKG9yIGRvZXMgbm90IGNvbXBsZXRlbHkgd29yayBvbg0KPiBpMzg2KS4gRXZl biBpZiB3ZSBkb24ndCBoYXZlIGEgZ3JlYXQgd2F5IHRvIHRyYW5zbGF0ZSB0aGF0IHRvIHBh Y2thZ2VzDQo+IHJlbGF0aW9uc2hpcHMgKG1heWJlIHdlIHNob3VsZCBnZW5lcmFsaXplIHNv bWV0aGluZyBsaWtlIERlcGVuZHM6DQo+IHVuc3VwcG9ydGVkLWFyY2hpdGVjdHVyZSBbaTM4 Nl0pLg0KDQoNCk9yIEJ1aWxkLURlcGVuZHM/IEZvciBpZiB0aGUgcGFja2FnZSB3b3Jrcywg YnV0IHRoZSBidWlsZCBkb2Vzbid0Lg0KDQo+IFNvLCB1bmxlc3MgeW91IGFzayBtZSB0byBz dG9wIGRvaW5nIHNvLCBJIHdpbGwgY29udGludWUgdG8gZmlsZSBzdWNoDQo+IGJ1Z3M7IEkg d2lsbCBmaWxlIHRoZW0gYXMgc2V2ZXJpdHk6c2VyaW91cyBieSBkZWZhdWx0DQoNCg0KQWdy ZWUuDQoNClBhdWwNCg0K

--------------tRty0EDJP8A85ylibeNmwnKc--

-----BEGIN PGP SIGNATURE-----

wsB5BAABCAAjFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmgAvqYFAwAAAAAACgkQnFyZ6wW9dQrN 1ggAwzkYjkoIfhPf31MNeDm96bkBHykyX3oP2m6D59G+UQav00jEht2vsWaEkUGFF7IlOebQ5GeF bjGWhhIyywVnNDOI5xNn3hdPTHuyyU5B8PoilWjlsLYHawcJz+JZwQKF8Vj9hL/zkKWLv6jK/bA0 lWFvMtyR90dJEkijPSeZgEk/bzcS6HoFSMpEpxgQ5FlYxA+8pOnr9El2ZV9T3aTjJe3cxT3U3D2v aS4xDGD63cL3pEzXDPxacX3QmIgNx6WCNsPEhWnkQYSjoHpHw12entQYbzI1M0xAYcA135Hxa0t8 j63tnZbQs/jgx2CsIXc2Qmc/nkFPsYqvMi1kZ0TJkw==
=IX+G
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)