Santiago Vila dixit:
>The library was included in gettext-base but it was splitted to its
>own package in version 0.18.1.1-6 and a compatibility dependency was
>added.
Ah.
>We could drop this dependency for stretch, yes, but even in such case
OK.
>I don't have an answer for that, but for very
On Sat, Aug 08, 2015 at 10:21:23PM +, Thorsten Glaser wrote:
> Santiago Vila dixit:
>
> >In the meantime there is nothing to fix because there is not a *single*
> >package in debian linked against this library.
>
> … wait, what? Why is the package then installed on all systems, even
> in the
Santiago Vila dixit:
>Ports that do not even exist yet will definitely need a working gcc-5
>if they ever expect to be released architectures some day.
>
>So the natural thing to do (which I think it is what we have always done,
>but I may be wrong) is to use unstable as their starting point, not
Santiago Vila dixit:
>In the meantime there is nothing to fix because there is not a *single*
>package in debian linked against this library.
… wait, what? Why is the package then installed on all systems, even
in the supposedly clean and minimal buildd chroot?
bye,
//mirabilos
--
>> Why don't
Santiago Vila dixit:
>In the meantime there is nothing to fix because there is not a *single*
>package in debian linked against this library.
Ah, okay then.
Then I agree with the severity downgrade, too.
(Still… building GCC takes about a week, so we could not have
been earlier. Plus it’s about
On Sat, Aug 08, 2015 at 09:45:33PM +, Thorsten Glaser wrote:
> including ports that don’t yet exist.
Hmm. I don't think we should really worry about that case.
Ports that do not even exist yet will definitely need a working gcc-5
if they ever expect to be released architectures some day.
So
On Sat, Aug 08, 2015 at 09:45:33PM +, Thorsten Glaser wrote:
> I would like to hear from either of you two how we can fixup the
> situation for m68k in the meantime.
In the meantime there is nothing to fix because there is not a *single*
package in debian linked against this library.
This is
Matthias Klose dixit:
>the package maintainers. Halt the buildds and re-enable them once you have
>updated your buildds.
Erm. This is so wrong on several counts.
• What builds gcc-5 if not the buildds?
• There *will* be people later who build packages for other,
e.g. new (think arm64) archite
Control: severity -1 wishlist
On 08/08/2015 09:25 PM, Thorsten Glaser wrote:
> Source: gettext
> Version: 0.19.5.1-1
> Severity: grave
> Justification: renders package unusable
>
> I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
> This cannot be, because we haven’t started
On Sat, Aug 08, 2015 at 07:25:14PM +, Thorsten Glaser wrote:
> Source: gettext
> Version: 0.19.5.1-1
> Severity: grave
> Justification: renders package unusable
>
> I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
> This cannot be, because we haven’t started the GCC 5 tra
Source: gettext
Version: 0.19.5.1-1
Severity: grave
Justification: renders package unusable
I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
This cannot be, because we haven’t started the GCC 5 transition yet (I
know because src:gcc-defaults is currently building on one of my
11 matches
Mail list logo
