Re: 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 of testing/unstable could still use unison2.40.102 from stable (hoping there won't be any conflict in the near future) so that they would be able to sync with stable machines without requiring a backport of unison 2.48 in stable. This is what I currently do, but since the broken unison2.40.102 is still in testing/unstable, I had to downgrade then mark it as frozen in aptitude, so that the stable version is not replaced by the testing/unstable version. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: 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 previous Debian releases, but another change in OCaml 4.02 makes it incompatible anyway (both communicating unisons need to be compiled with the same version of OCaml in practice, which won't be the case any more when one side is Debian stable, and the other Debian testing). IMHO, that's a design flaw in Unison that cannot be easily fixed. A possible way out for stable (and old-stable) users could be to use 2.48 from backports, when 2.48 will be packaged and migrated to testing. No, 2.48 from backports will be compiled with stable's version of OCaml (4.01.0) whereas 2.48 from testing will (eventually) be compiled with testing's version of OCaml (4.02.3), making both versions incompatible. Oh, my understanding was that newer versions of Unison were not bound on an OCaml version anymore and have had worked a synchronization format which will work well with any OCaml version. Sorry if this is not the case. Personally, what I do when dealing with inter-release synchronization involves using schroot... I heard of people copying binaries around, and others recompiling unison locally on one system. I don't know which solution is the best. The situation sucks. It is possible to backport OCaml 4.02.3 (and lablgtk2 :-/) and use that from backports to build a compatible version of Unison. I realize this is a lot of work though. Regards, -- Mehdi
Re: 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 change in OCaml 4.02 makes it >> incompatible anyway (both communicating unisons need to be compiled with >> the same version of OCaml in practice, which won't be the case any more >> when one side is Debian stable, and the other Debian testing). IMHO, >> that's a design flaw in Unison that cannot be easily fixed. >> > > A possible way out for stable (and old-stable) users could be to use 2.48 > from backports, when 2.48 will be packaged and migrated to testing. No, 2.48 from backports will be compiled with stable's version of OCaml (4.01.0) whereas 2.48 from testing will (eventually) be compiled with testing's version of OCaml (4.02.3), making both versions incompatible. Personally, what I do when dealing with inter-release synchronization involves using schroot... I heard of people copying binaries around, and others recompiling unison locally on one system. I don't know which solution is the best. The situation sucks. Cheers, -- Stéphane
Re: 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 broken. There is nothing to fix. It works fine when talking to other stable servers. 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. The most recent "unison" package, version 2.48.3-1 in testing and unstable is not broken. Unfortunately it is not compatable with the version in stable. This is about letting stable users use the latest bleeding each version so that they can have compatability with unison 2.48 in unstable which is not broken. Which I believe is inline with what backports is for. -- Brian May
Re: 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 to >>>> provide compatibility with previous Debian releases, but >>>> another change in OCaml 4.02 makes it incompatible anyway (both >>>> communicating unisons need to be compiled with the same version >>>> of OCaml in practice, which won't be the case any more when one >>>> side is Debian stable, and the other Debian testing). IMHO, >>>> that's a design flaw in Unison that cannot be easily fixed. >>>> >>> >>> A possible way out for stable (and old-stable) users could be to >>> use 2.48 from backports, when 2.48 will be packaged and migrated >>> to testing. >> >> The backport is indeed a nice way out of this, the rebuild is >> straightforward (only tried for amd64). >> http://sousmonlit.zincube.net/~niol/apt/pool/main/u/unison/unison_2.48.3-1~bpo80+1.dsc >> >> >> This should be integrated in the backports.d.o repositories. > Backports is not for fixing bugs in stable. > Should the description from backports.d.o be adjusted then? For now, it reads: Backports are packages taken from the next Debian release (called "testing"), adjusted and recompiled for usage on Debian stable. Alternatively, can you please explain how this case doesn't fit? We didn't need to backport Unison in the past because it used to work well even with different OCaml versions. Now, this changed in 2.48 and we are not able to offer sync between Stable and Testing machines anymore. In fact, the "issue" was triggered by the fact that some internal structures changed in some OCaml modules rendering Unison <2.48 unusable with recent OCaml version. This is now fixed in Unison 2.48... hence the backport of Unison 2.48. But there is nothing to fix in Stable... My only doubt right now (about the backport) is about #805456. It would be great to hear about the submitter before exposing Unison 2.48 to users of stable. Regards, -- Mehdi
Re: 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 releases, but another change in OCaml 4.02 makes it > >> incompatible anyway (both communicating unisons need to be compiled with > >> the same version of OCaml in practice, which won't be the case any more > >> when one side is Debian stable, and the other Debian testing). IMHO, > >> that's a design flaw in Unison that cannot be easily fixed. > >> > > > > A possible way out for stable (and old-stable) users could be to use 2.48 > > from backports, when 2.48 will be packaged and migrated to testing. > > The backport is indeed a nice way out of this, the rebuild is > straightforward (only tried for amd64). > http://sousmonlit.zincube.net/~niol/apt/pool/main/u/unison/unison_2.48.3-1~bpo80+1.dsc > > This should be integrated in the backports.d.o repositories. Backports is not for fixing bugs in stable. Alex - Backports ftpmaster
Re: 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 >> incompatible anyway (both communicating unisons need to be compiled with >> the same version of OCaml in practice, which won't be the case any more >> when one side is Debian stable, and the other Debian testing). IMHO, >> that's a design flaw in Unison that cannot be easily fixed. >> > > A possible way out for stable (and old-stable) users could be to use 2.48 > from backports, when 2.48 will be packaged and migrated to testing. The backport is indeed a nice way out of this, the rebuild is straightforward (only tried for amd64). http://sousmonlit.zincube.net/~niol/apt/pool/main/u/unison/unison_2.48.3-1~bpo80+1.dsc This should be integrated in the backports.d.o repositories. Alex
Re: 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 another change in OCaml 4.02 makes it > incompatible anyway (both communicating unisons need to be compiled with > the same version of OCaml in practice, which won't be the case any more > when one side is Debian stable, and the other Debian testing). IMHO, > that's a design flaw in Unison that cannot be easily fixed. > A possible way out for stable (and old-stable) users could be to use 2.48 from backports, when 2.48 will be packaged and migrated to testing. My 2 cents, -- Mehdi
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
On Wed, Dec 9, 2015 at 14:02:41 +, Wookey wrote: > +++ Jakub Wilk [2015-12-09 14:47 +0100]: > > Looks like a fallout after #620112. > > This change in sbuild should be reverted. It didn't fix binNMU > > co-installability, and made binMNU changelog entries less helpful. > > It may not have fixed binNMU co-installability on its own, but it > looks to me as if it was a necessary part of solving that issue? Has > it been superceded by changes in changelog handling for binNMUs (I > vaguely recall some changes in this area but am not sure what the > current state is)? > > i.e it's not clear to me that this should simply be reverted because > it is 'misleading'. Not-breaking MA:same co-installability with > binNMUs is an important goal IMHO. > It's entirely unnecessary, because a binNMU's changelog now ends up in /usr/share/doc/$package/changelog.$arch.gz, which doesn't clash with other architectures since it's arch-qualified. So yes, the change in sbuild should be reverted. Cheers, Julien signature.asc Description: PGP signature
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
+++ Jakub Wilk [2015-12-09 14:47 +0100]: > * 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 > > >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 non-maintainer upload for amd64; no source changes. > >> * Rebuild against ncurses 6.0. > >> > >>-- amd64 / i386 Build Daemon (babin) Fri, > >>31 Jul 2015 09:50:21 +0200 > >Also, the date is misleading; it corresponds to the last sourceful > >upload, not the binNMU. > > Looks like a fallout after #620112. > This change in sbuild should be reverted. It didn't fix binNMU > co-installability, and made binMNU changelog entries less helpful. It may not have fixed binNMU co-installability on its own, but it looks to me as if it was a necessary part of solving that issue? Has it been superceded by changes in changelog handling for binNMUs (I vaguely recall some changes in this area but am not sure what the current state is)? i.e it's not clear to me that this should simply be reverted because it is 'misleading'. Not-breaking MA:same co-installability with binNMUs is an important goal IMHO. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: 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 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 non-maintainer upload for amd64; no source changes. * Rebuild against ncurses 6.0. -- amd64 / i386 Build Daemon (babin) Fri, 31 Jul 2015 09:50:21 +0200 ...which is strange, because unison doesn't use ncurses AFAICT. Not on amd64, but it does link to ncurses on some other architectures. This is probably unintentional. For example, I see this in the mips build log[0]: dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/unison2.32.52/usr/bin/unison-2.32.52 was not linked against libncurses.so.5 (it uses none of the library's symbols) Also, the date is misleading; it corresponds to the last sourceful upload, not the binNMU. Looks like a fallout after #620112. This change in sbuild should be reverted. It didn't fix binNMU co-installability, and made binMNU changelog entries less helpful. [0] https://buildd.debian.org/status/fetch.php?pkg=unison2.32.52&arch=mips&ver=2.32.52-7%2Bb1&stamp=1449193180 -- Jakub Wilk
Re: 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 4.02.3, where it > is no longer the case. unison2.32.52 should suffer from the same problem. Uhh, thanks for tracking this down. > 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. That would be a pity. > Moreover, this package was created to provide compatibility with > previous Debian releases, but another change in OCaml 4.02 makes it Unfortunately I am even running old-stable, but till now had no problems using 2.40 with the unison from old-stable. I will need to look into that how I can keep that running. Thanks a lot and all the best Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: 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 non-maintainer upload for amd64; no source changes. > * Rebuild against ncurses 6.0. > > -- amd64 / i386 Build Daemon (babin) Fri, > 31 Jul 2015 09:50:21 +0200 ...which is strange, because unison doesn't use ncurses AFAICT. Also, the date is misleading; it corresponds to the last sourceful upload, not the binNMU. 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 4.02.3, where it is no longer the case. unison2.32.52 should suffer from the same problem. 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 incompatible anyway (both communicating unisons need to be compiled with the same version of OCaml in practice, which won't be the case any more when one side is Debian stable, and the other Debian testing). IMHO, that's a design flaw in Unison that cannot be easily fixed. -- Stéphane
Re: tracking bin-num - broken unison due to binnmu upload
+++ Norbert Preining [2015-12-06 20:15 +0900]: > 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 are: > * is there a way to track down who uploaded -3+b1? They are normally just built on the buildds so no-one 'uploaded' it. Someone will have scheduled it via wanna-build (possibly for several architectures). I don't know if records are kept of who does that, but normally this isn't really useful info. > * what would be the proper steps to revert this broken behaviour? Work out why a version built at that moment in unstable is broken, but one built sometime earlier isn't, and fix the underlying issue. Simply scheduling a new binnmu will replace the current one, but if the underlying problem persists, that won't fix it. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
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 are: * is there a way to track down who uploaded -3+b1? * what would be the proper steps to revert this broken behaviour? Thanks Norbert (please Cc) PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Unison
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I wont to ask if there is something with the maintainer of unison. There are at least 3 important bugs where at least one of them can be fixed very easy as there is a working patch in the bug report. But nothing happens. The bugs are 309908, 310004 and 318132 where the problems are similar. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen <[EMAIL PROTECTED]> Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQvnRN5+OKpjRpO3lAQIr9gf+OwANnetCQJULmBc08CaRghzFctoklE+9 HVLNYnmoxLr1Pm7BPOdc6Gk3v5D+26XLAVGMfLj1KvYi8EPf9axQmqE5pdgWFXdj EC8VkQ8nrB2E2VZPSie8qq72K6SU/Rk640v/2kj0cGmzxvRF7fQQWvj+je6H8Mlk AkGEb+ZS+FkUv46svAuFJQNhlYna+WZuf+lonUatbIyHs2R152409z3duKuUAxhy T4H2O3G0HdGOBa646i1ZzWGBD8YJ+bPeCBfs2UYAzC/REjT96Ih9ZGScVx/NgaKH sfjxlenL2Cohd+14AbcWIcFYdKbgcj0lZCTq4TYlRjvt6INfm7+ZHw== =SBU5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
