Bug#1116671: marked as done (nmu: mlton_20210117+dfsg-3)
Your message dated Tue, 30 Sep 2025 09:31:07 +0200
with message-id <d4c60f4b-9fb1-40d3-bded-ec93c51ef7a9@debian.org>
and subject line Re: Bug#1116671: nmu: mlton_20210117+dfsg-3
has caused the Debian Bug report #1116671,
regarding nmu: mlton_20210117+dfsg-3
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
1116671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116671
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: binnmu
nmu mlton_20210117+dfsg-3 . ANY . unstable . -m "Rebuild on buildds"
Hi,
mlton is in a sorry state. It has an FTBFS bug claiming that it
segfaults in tests, but that bug predates the most recent upload. That
last upload is a fully binary upload for all architectures, because it
needed to be bootstrapped. This suggests that it might actually build
(as various arm binaries were included in said upload). Not being built
on buildds is one of several reasons that prevents testing migration. I
suggest NMUing it everywhere. Then, one reason goes away and we may see
whether it still FTBFS anywhere.
Helmut
--- End Message ---
--- Begin Message ---
On 29/09/2025 12:04, Helmut Grohne wrote:
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: binnmu
nmu mlton_20210117+dfsg-3 . ANY . unstable . -m "Rebuild on buildds"
Hi,
mlton is in a sorry state. It has an FTBFS bug claiming that it
segfaults in tests, but that bug predates the most recent upload. That
last upload is a fully binary upload for all architectures, because it
needed to be bootstrapped. This suggests that it might actually build
(as various arm binaries were included in said upload). Not being built
on buildds is one of several reasons that prevents testing migration. I
suggest NMUing it everywhere. Then, one reason goes away and we may see
whether it still FTBFS anywhere.
Scheduled.
Emilio
--- End Message ---
Reply to: