On Mon, 2024-02-26 at 20:10:20 +0100, Sebastian Andrzej Siewior wrote: > On 2024-02-26 19:23:58 [+0100], Guillem Jover wrote: > > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the > > > memory usage limit of 1400 MiB > > > | 89s +xz: Reduced the number of threads from 16 to 8 to not exceed the > > > memory usage limit of 1400 MiB > > > | 89s 4. deb-format.at:511: FAILED (deb-format.at:518) > > > > > > Allowing output on stderr would be a possible tix. > > > > Hmm, that's warning is unfortunate, and a quick check at the xz code > > didn't reveal a way to only suppress it. :/ > > > > For dpkg, I'd like to either not get the warning or being able to tell xz > > that even if the threads are reduced, that's ok and it should not warn > > about that (but that would then require depending on a new enough > > version supporting that, perhaps that could be suppresses instead via > > an envvar) so that? > > Could poke upstream.
Thanks! > > Ignoring stderr could be a workaround, but I'd need to do something as > > well for the libdpkg code and the perl code calling xz, which will get > > very annoying. > > > > This is also going to get in the way of migrating both xz and dpkg > > (which seems like would need to be uploaded today for the time64 > > transition). > > > > Or perhaps that warning could be disabled for now in Debian until things > > are sorted out with upstream? > > Falling back to -T1 in order to keep the previous is not an option? I'm not sure I understand what you are saying. Do you mean dpkg would fallback to pass -T1 (maybe you mean -T+1, otherwise we might get unreproducible output due to switching to single-threaded)? And fallback on what condition? Ah, I think you mean to pass -T+1 to the xz invocations for the test suite, right, that could workaround the issue there indeed. Thanks, I think I'll do that for now. > Let me try to sell this "we move this warning to verbose" to upstream in > the meantime… That would actually be great! > > (Had not seen this test suite failure yet, as I've got xz on hold due > > to the breaks on pristine-tar, but would probably stumble over it > > during the release process anyway I guess, so thanks for the heads up!) > > This poped up on xz debci only armel and armhf. Perhaps I'll not see it in my local tree then, but I think the dpkg failure will at least block xz migration, but thinking about it now, probably not dpkg's migration. So this might not be blocking for dpkg. (Sorry if this sounded alarming, but didn't want to add new roadblocks to the time64 transition from the dpkg side! :D) Thanks, Guillem
