> > > Hmm, simply "./autogen.sh && ./configure && make -j" does build it
> > > for me (though with some warnings), using stretch. Does that work
> > > for you? If so, it must be something in the Debian rules; otherwise
> > > it seems to be difference between stable and testing which may be
> > >
Em qua, 21 de nov de 2018 às 01:54, Manuel A. Fernandez Montecelo
escreveu:
>
> Hi Evgeny,
>
> 2018-11-19 23:44 Evgeny Kapun:
> >Package: libftgl2
> >Version: 2.3.0-3
> >
> >After updating libftgl2 from version 2.1.3~rc5-5 to version 2.3.0-3, text
> >rendering in Megaglest is broken. Text is
Em sex, 8 de fev de 2019 às 02:09, Manuel A. Fernandez Montecelo
escreveu:
>
> Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach
> escreveu:
> >
> > > I checked and everything looks all right, but I've been fighting for
> > > 1+ hours because it cannot generate the ftgl.pdf documentation.
> >
Em sex, 8 de fev de 2019 às 01:35, Frank Heckenbach
escreveu:
>
> > I checked and everything looks all right, but I've been fighting for
> > 1+ hours because it cannot generate the ftgl.pdf documentation.
>
> Hmm, simply "./autogen.sh && ./configure && make -j" does build it
> for me (though with
> I checked and everything looks all right, but I've been fighting for
> 1+ hours because it cannot generate the ftgl.pdf documentation.
Hmm, simply "./autogen.sh && ./configure && make -j" does build it
for me (though with some warnings), using stretch. Does that work
for you? If so, it must be
Em qui, 7 de fev de 2019 às 22:47, Frank Heckenbach
escreveu:
>
> > The idea of using both RenderDefault() and RenderBasic() as well as
> > the flag, would equally work if you have just Render() and the
> > behaviour of one render or the other nested in an "if/else" based on
> > the flag.
> The idea of using both RenderDefault() and RenderBasic() as well as
> the flag, would equally work if you have just Render() and the
> behaviour of one render or the other nested in an "if/else" based on
> the flag. Whatever makes more sense to you. I suggested it because
> in that way it is
Em qui, 7 de fev de 2019 às 04:32, Frank Heckenbach
escreveu:
>
> > > My suggestion of 2018-11-25 still stands. But if you want me to do
> > > my part of it, please do your review quickly and tell me soon
> > > (or, if it's indeed necessary for the soft freeze, immediately) to
> > > avoid running
> > My suggestion of 2018-11-25 still stands. But if you want me to do
> > my part of it, please do your review quickly and tell me soon
> > (or, if it's indeed necessary for the soft freeze, immediately) to
> > avoid running out of time.
>
> Your plan sounds OK. Changing packages after the
Em qua, 6 de fev de 2019 às 04:15, Frank Heckenbach
escreveu:
>
> > Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> > escreveu:
> > >
> > > According to https://release.debian.org/buster/freeze_policy.html:
> > >
> > > 2019-01-12 - Transition freeze
> > >
> > > Is there still time yet to
> Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
> escreveu:
> >
> > According to https://release.debian.org/buster/freeze_policy.html:
> >
> > 2019-01-12 - Transition freeze
> >
> > Is there still time yet to get a fix in, or is it FUBAR already?
>
> Transition freeze means ABI changes in
Em qui, 3 de jan de 2019 às 22:56, Frank Heckenbach
escreveu:
>
> According to https://release.debian.org/buster/freeze_policy.html:
>
> 2019-01-12 - Transition freeze
>
> Is there still time yet to get a fix in, or is it FUBAR already?
Transition freeze means ABI changes in libraries are
According to https://release.debian.org/buster/freeze_policy.html:
2019-01-12 - Transition freeze
Is there still time yet to get a fix in, or is it FUBAR already?
Frank
Hi Manuel,
> > That seems to me the best solution indeed. So I can offer this:
> >
> > - I add these two new versions for all functions involved (quite a
> > few); we'd just need to agree about naming ("old" and "new" won't
> > do, since in this complicated situation it's not even clear which
Hi Frank,
Em dom, 25 de nov de 2018 às 18:29, Frank Heckenbach
escreveu:
>
> : Perhaps the only sane way out is to add *two* new versions of each
> : rendering function, one with each behaviour, and deprecate the old
> : ones entirely. This will require changes in all applications (if
> : only
Hi,
coming back to my own mail, after thinking about it some more:
: > And I think that the default would have to be the old behaviour, yes,
: > because after many years behaving in that way the applications must
: > have learned to adapt or cope, and no one knows that they have to use
: > a
Hi,
> Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
> escreveu:
> >
> > > I think that we should revert this change for the time being, though,
> > > because if it was working in this way for about a decade and the
> > > programs using FTGL worked "fine" despite having some bug there,
> >
Hi,
Em qua, 21 de nov de 2018 às 15:15, Frank Heckenbach
escreveu:
>
> > I think that we should revert this change for the time being, though,
> > because if it was working in this way for about a decade and the
> > programs using FTGL worked "fine" despite having some bug there,
>
> Sorry, they
Hi,
> I think that we should revert this change for the time being, though,
> because if it was working in this way for about a decade and the
> programs using FTGL worked "fine" despite having some bug there,
Sorry, they did *NOT* all work fine, see my bug report. And if we
apply my patch from
19 matches
Mail list logo
