Bug#899189: nmu: unison_2.48.3-1
On Tue, 2018-07-10 at 15:00 +0200, Stéphane Glondu wrote: > On 06/07/2018 03:15, Cyril Brulebois wrote: [...] > > > with extra unfriendly debug messages (hey, look at those in the > > > github > > > bug tracker, the ones we wanted to get rid of). > > > > > > I thought I'd mention the possibly surprising outcome for people > > > not > > > following debian-release@ closely. > > > > Also, that seems to completely invalidate the on-disk cache, which > > is > > likely the reason why the first run with an upgraded version (on > > either > > side, by the way) can take several (dozens of) minutes instead of a > > couple of seconds. > > Indeed. Care must be taken at each upgrade of Unison, I think Unison > users are aware of that. This is not specific to Debian. What was > specific to Debian was the situation of Unison compiled with a > version > of OCaml different from the one that is being distributed alongside, > which this binNMU is meant to fix. > > > It might have been a good idea to mention that in the binNMU > > request. It > > might also be a good idea to document those consequences in some > > way. > > Sorry. Where would be a good place to document this, now? If it had been noticed earlier, I'd have suggested a source upload with a NEWS file explaining the issues. We /could/ add a note to the point release announcement mail, although that's a fairly unusual occurrence for an individual package. Regards, Adam
Bug#899189: nmu: unison_2.48.3-1
On 06/07/2018 03:15, Cyril Brulebois wrote:
>> For the sake of completeness, here's an extra data point. If someone
>> ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1 (hosts
>> with s-p-u enabled, but not dist-upgraded at the same time), one can
>> get this very issue:
>> | Uncaught exception Failure("input_value: bad bigarray kind")
This is expected.
>> with extra unfriendly debug messages (hey, look at those in the github
>> bug tracker, the ones we wanted to get rid of).
>>
>> I thought I'd mention the possibly surprising outcome for people not
>> following debian-release@ closely.
>
> Also, that seems to completely invalidate the on-disk cache, which is
> likely the reason why the first run with an upgraded version (on either
> side, by the way) can take several (dozens of) minutes instead of a
> couple of seconds.
Indeed. Care must be taken at each upgrade of Unison, I think Unison
users are aware of that. This is not specific to Debian. What was
specific to Debian was the situation of Unison compiled with a version
of OCaml different from the one that is being distributed alongside,
which this binNMU is meant to fix.
> It might have been a good idea to mention that in the binNMU request. It
> might also be a good idea to document those consequences in some way.
Sorry. Where would be a good place to document this, now?
Cheers,
--
Stéphane
Bug#899189: nmu: unison_2.48.3-1
On Fri, 2018-07-06 at 03:15 +0200, Cyril Brulebois wrote:
> Hey again,
>
> Cyril Brulebois (2018-07-06):
> > For the sake of completeness, here's an extra data point. If
> > someone
> > ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1
> > (hosts
> > with s-p-u enabled, but not dist-upgraded at the same time), one
> > can
> > get this very issue:
> > > Uncaught exception Failure("input_value: bad bigarray kind")
> >
> > with extra unfriendly debug messages (hey, look at those in the
> > github
> > bug tracker, the ones we wanted to get rid of).
> >
> > I thought I'd mention the possibly surprising outcome for people
> > not
> > following debian-release@ closely.
>
> Also, that seems to completely invalidate the on-disk cache, which is
> likely the reason why the first run with an upgraded version (on
> either
> side, by the way) can take several (dozens of) minutes instead of a
> couple of seconds.
>
> It might have been a good idea to mention that in the binNMU request.
> It might also be a good idea to document those consequences in some
> way.
>
Stéphane, any comments on this?
Regards,
Adam
Bug#899189: nmu: unison_2.48.3-1
Hey again,
Cyril Brulebois (2018-07-06):
> For the sake of completeness, here's an extra data point. If someone
> ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1 (hosts
> with s-p-u enabled, but not dist-upgraded at the same time), one can
> get this very issue:
> | Uncaught exception Failure("input_value: bad bigarray kind")
>
> with extra unfriendly debug messages (hey, look at those in the github
> bug tracker, the ones we wanted to get rid of).
>
> I thought I'd mention the possibly surprising outcome for people not
> following debian-release@ closely.
Also, that seems to completely invalidate the on-disk cache, which is
likely the reason why the first run with an upgraded version (on either
side, by the way) can take several (dozens of) minutes instead of a
couple of seconds.
It might have been a good idea to mention that in the binNMU request. It
might also be a good idea to document those consequences in some way.
Cheers,
--
Cyril Brulebois (k...@debian.org)
Bug#899189: nmu: unison_2.48.3-1
Hi,
Stéphane Glondu (2018-05-20):
> Currently, Unison in Stretch is compiled with OCaml 4.01.0 (at least
> on i386), while OCaml in Stretch is 4.02.3. This triggers a subtle
> interoperability bug more often than it should, and led to too much
> lost time in my opinion (e.g. see [1] and [2]).
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802919
> [2] https://github.com/bcpierce00/unison/issues/94
>
> I don't know if it is acceptable to do binNMUs in stable (I probably
> can do it myself), so I'm asking here :-)
>
> nmu unison_2.48.3-1 . ANY . stretch . -m "Recompile with ocaml version in
> stretch"
For the sake of completeness, here's an extra data point. If someone
ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1 (hosts
with s-p-u enabled, but not dist-upgraded at the same time), one can
get this very issue:
| Uncaught exception Failure("input_value: bad bigarray kind")
with extra unfriendly debug messages (hey, look at those in the github
bug tracker, the ones we wanted to get rid of).
I thought I'd mention the possibly surprising outcome for people not
following debian-release@ closely.
Cheers,
--
Cyril Brulebois (k...@debian.org)
Bug#899189: nmu: unison_2.48.3-1
Control: tags -1 stretch On 20/05/18 16:17, Stéphane Glondu wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Hi, > > Currently, Unison in Stretch is compiled with OCaml 4.01.0 (at least > on i386), while OCaml in Stretch is 4.02.3. This triggers a subtle > interoperability bug more often than it should, and led to too much > lost time in my opinion (e.g. see [1] and [2]). > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802919 > [2] https://github.com/bcpierce00/unison/issues/94 > > I don't know if it is acceptable to do binNMUs in stable (I probably > can do it myself), so I'm asking here :-) Please don't do it yourself. binNMUs for (old)stable should be done by a SRM. Cheers, Emilio
Bug#899189: nmu: unison_2.48.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, Currently, Unison in Stretch is compiled with OCaml 4.01.0 (at least on i386), while OCaml in Stretch is 4.02.3. This triggers a subtle interoperability bug more often than it should, and led to too much lost time in my opinion (e.g. see [1] and [2]). [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802919 [2] https://github.com/bcpierce00/unison/issues/94 I don't know if it is acceptable to do binNMUs in stable (I probably can do it myself), so I'm asking here :-) nmu unison_2.48.3-1 . ANY . stretch . -m "Recompile with ocaml version in stretch" Cheers, -- Stéphane -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
