On Tue, 20 Nov 2007, Raphael Hertzog wrote:
> > Unfortunately I don't really like this idea because sbuild doesn't keep
> > environment variables, and I don't really want to patch sbuild every
> > time I want to update it instead of using the .deb package directly from
> > debian-admin.
>
> This i
On Tue, 20 Nov 2007, Riku Voipio wrote:
> On armel architecture, the symbol differences have usually been
> inlined softfloat symbols being exported. Which is additional symbols
> and would thus not break symbol checking (if I understood correctly).
Yes.
> What is more worrying is the lack of uno
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
Please read the bug log again. The supplementary symbols are not the
same on the different architectures, which causes some architectures to
have missing symbols compared to some others.
>>> In which case it doesn
Hi,
On armel architecture, the symbol differences have usually been
inlined softfloat symbols being exported. Which is additional symbols
and would thus not break symbol checking (if I understood correctly).
What is more worrying is the lack of unofficial arch information in mole.
Thus maintainers
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> >> Please read the bug log again. The supplementary symbols are not the
> >> same on the different architectures, which causes some architectures to
> >> have missing symbols compared to some others.
> >
> > In which case it doesn't make sense to have a
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>>> The issue is that some supplementary symbols are exported due to libtool
>>> working differently with C++ libs for apparently no good reasons. It is not
>>> really armel-specific (except for the fact that armel generated
>>>
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> > The issue is that some supplementary symbols are exported due to libtool
> > working differently with C++ libs for apparently no good reasons. It is not
> > really armel-specific (except for the fact that armel generated
> > supplementary symbols that
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>>> Though it's worth asking ourselves if it would make sense to have an
>>> intermediary fallback between debian/*.symbols. and debian/*.symbols
>>> that
>>> would be debian/*.symbols..
>> While it will fixes the problem due t
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> > Though it's worth asking ourselves if it would make sense to have an
> > intermediary fallback between debian/*.symbols. and debian/*.symbols
> > that
> > would be debian/*.symbols..
>
> While it will fixes the problem due to the variation of the ABI
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Raphael Hertzog wrote:
>> Note that this is a case where the API is supposed to be stable across
>> architectures... can you show me what the differences are and why they are
>> legitimate?
>>
>> Please show me the build-failure.
>
> FTR, here's the
Raphael Hertzog a écrit :
> On Tue, 20 Nov 2007, Aurelien Jarno wrote:
>> Even if it is not important for you that doesn't give you the right to
>> ignore the problem as you did until now.
>
> We've had only one unconclusive IRC discussion, that's not really ignoring
> the problem. And I still bel
On Tue, 20 Nov 2007, Raphael Hertzog wrote:
> Note that this is a case where the API is supposed to be stable across
> architectures... can you show me what the differences are and why they are
> legitimate?
>
> Please show me the build-failure.
FTR, here's the relevant output for kfreebsd:
dh_ma
On Tue, 20 Nov 2007, Aurelien Jarno wrote:
> Even if it is not important for you that doesn't give you the right to
> ignore the problem as you did until now.
We've had only one unconclusive IRC discussion, that's not really ignoring
the problem. And I still believe, you're over exagerating the pr
Raphael Hertzog a écrit :
> severity 452022 wishlist
> thanks
>
> On Mon, 19 Nov 2007, Aurelien Jarno wrote:
>> Package: dpkg-dev
>> Version: 1.14.8
>> Severity: serious
>
> Huh ?! I know it's important for you, but that doesn't make it RC.
Even if it is not important for you that doesn't give y
severity 452022 wishlist
thanks
On Mon, 19 Nov 2007, Aurelien Jarno wrote:
> Package: dpkg-dev
> Version: 1.14.8
> Severity: serious
Huh ?! I know it's important for you, but that doesn't make it RC.
> problem: it potentially breaks all unofficial architectures, as the
> symbols for those archit
Package: dpkg-dev
Version: 1.14.8
Severity: serious
Justification: Potentially breaks all unofficial architectures
The new dpkg-gensymbols is surely a great thing that will help the
release a lot, but it has been pushed into unstable with a *known*
problem: it potentially breaks all unofficial arc
16 matches
Mail list logo
