[Debichem-devel] Bug#889906: xcrysden FTBFS with libtogl-dev 2.0-1

[Andreas Tille]

Hi Anton,

as the person who caused that issue I wonder whether you decided for one
of the options Daniel has mentioned below and whether you might possibly
need some help.  I'd personally prefer option 3).

Please let me know if I could be of any help

     Andreas.

On Wed, Feb 21, 2018 at 11:55:33AM +0100, Daniel Leidert wrote:
> Hi,
> 
> you wrote:
> > On Thu, 2018-02-08 at 18:12 +0200, Adrian Bunk wrote:
> [..]
> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xc
> >> rysden.html
> >>
> >> ...
> >> xcAppInit.c: In function 'Xcrys_Init':
> >> xcAppInit.c:511:5: error: unknown type name 'Togl_CmdProc'
> >>      Togl_CmdProc *proc;
> >>      ^~~~~~~~~~~~
> >
> > I suspect the problem may be this: xcrysden should not use the libtogl-
> > dev, because it uses modified togl sources that are included within its
> > sources. It should be compiled with that modified togl files instead.
> 
> Please read this short policy section about convenience copies:
> https://www.debian.org/doc/debian-policy/#convenience-copies-of-code
> 
> I wasn't aware, that you modified the shipped sources. Did you modify
> other libary sources as well?
> 
> BTW: The mess has been caused by the uncoordinated upload of togl 2.0,
> which uses a different API then togl version 1.7. Because of this upload,
> libtogl1 will also disappear soon, making xcrysden not just unbuildable
> but uninstallable too. There doesn't seem to be any effort by the person(s)
> responsible for this issue to fix it, which IMO only leaves these choices:
> 
> 1) Turn to the Debian release managers and/or the TC to restore togl 1.7.
> There are pros and cons here and I'm not sure, this works.
> 
> 2) Make an exception for xcrysden and build it against the internal copy of
> togl 1.7. However, in this case it becomes mandatory that you as the
> upstream author of xcrysden take over complete reponsibility for the copy of
> togl you ship, including bug fixing. The first step towards this is to apply
> all bug-fixes included in the last togl 1.7 Debian package into your
> internal copy and make a new release of xcrysden.
> 
> 3) Alternatively you could port xcrysden to togl 2.0 (seems this release is
> also pretty old, so every modern system could have it). I'd suggest to not
> modify the togl sources but build custom functions on top of it, if you need
> modifications or new functionality. If you encounter bugs, pleaes tell us,
> so this can be fixed in the library package.
> 
> 3.1) There is maybe an actively maintained development version 2.1 of togl
> in the netgen sources. It might work to package this netgen version and
> create the togl header and library package from this copy and build xcrysden
> against it. It would require that you choose to use this togl copy.
> 
> 4) Last possibility is to remove xcrysden from Debian.
> 
> I'd prefer possibility 2) or 3) or 3.1) over 1) or 4).
> 
> HTH and regards, Daniel
> 
> 

-- 
http://fam-tille.de