Bug#807019: tracking bin-num - broken unison due to binnmu upload

On 2016-01-03 16:54:40 +1100, Brian May wrote: > The package called "unison2.40.102" version 2.40.102-3+b1 in testing and > unstable is broken. This broken package is not in stable. If it can't > get fixed, it probably should get removed. Yes, I think that it should be removed ASAP. Thus, users

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Le 22/12/2015 00:38, Mehdi Dogguy a écrit : >> The change done in unison 2.48 to overcome this looks pretty big... I'm >> not sure I'll be able/willing to provide a unison2.40.102 any more. >> Moreover, this package was created to provide compatibility with >> previous Debian releases, but another

Bug#807019: tracking bin-num - broken unison due to binnmu upload

On 2016-01-04 17:24, Stéphane Glondu wrote: Le 22/12/2015 00:38, Mehdi Dogguy a écrit : The change done in unison 2.48 to overcome this looks pretty big... I'm not sure I'll be able/willing to provide a unison2.40.102 any more. Moreover, this package was created to provide compatibility with

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Alexander Wirt writes: >> This should be integrated in the backports.d.o repositories. > Backports is not for fixing bugs in stable. I think there is a misunderstanding here. This is not about fixing unison in stable. "unison" 2.40.102-2 in stable works fine. It is not

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Hi, On 29/12/2015 11:13, Alexander Wirt wrote: > On Tue, 29 Dec 2015, Alexandre Rossi wrote: > >> Hi, >> The change done in unison 2.48 to overcome this looks pretty big... I'm not sure I'll be able/willing to provide a unison2.40.102 any more. Moreover, this package was created

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Hi, >> The change done in unison 2.48 to overcome this looks pretty big... I'm >> not sure I'll be able/willing to provide a unison2.40.102 any more. >> Moreover, this package was created to provide compatibility with >> previous Debian releases, but another change in OCaml 4.02 makes it >>

Bug#807019: tracking bin-num - broken unison due to binnmu upload

On Tue, 29 Dec 2015, Alexandre Rossi wrote: > Hi, > > >> The change done in unison 2.48 to overcome this looks pretty big... I'm > >> not sure I'll be able/willing to provide a unison2.40.102 any more. > >> Moreover, this package was created to provide compatibility with > >> previous Debian

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Hi, On 07/12/2015 16:23, Stéphane Glondu wrote: > > The change done in unison 2.48 to overcome this looks pretty big... I'm > not sure I'll be able/willing to provide a unison2.40.102 any more. > Moreover, this package was created to provide compatibility with > previous Debian releases, but

Bug#807019: tracking bin-num - broken unison due to binnmu upload

* Stéphane Glondu , 2015-12-07, 16:23: * is there a way to track down who uploaded -3+b1? For "who", I don't know. BinNMU are usually scheduled by the Release Team. This package was part of the ncurses transition: https://release.debian.org/transitions/html/ncurses.html

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Le 06/12/2015 12:15, Norbert Preining a écrit : > * is there a way to track down who uploaded -3+b1? For "who", I don't know. But for "why", cf /usr/share/doc/unison2.40.102/changelog.Debian.amd64.gz: > unison2.40.102 (2.40.102-3+b1) sid; urgency=low, binary-only=yes > > * Binary-only

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Dear Stéphane, > But I now understand the problem: unison2.40.102 uses Obj.magic (i.e. an > unsafe coercion) to cast a format string into a string. The previous > unison version was compiled with OCaml 4.01.0, where format strings were > indeed strings. The new version was compiled with OCaml

Bug#807019: tracking bin-num - broken unison due to binnmu upload

Dear all, (please Cc) is there a way to track down who create a binnmu? Currently unison2.40.102 is broken on sid and segfaults (see bug report in Cc), and that is solely caused by the binnmu 2.40.102-3+b1 because several people confirmed that -3 works without problems. My questions