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
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 is surely
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
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 relevant
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 believe,
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.arch and debian/*.symbols
that
would be debian/*.symbols.kernel.
While it will fixes the problem due to the variation of the
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 should
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 common
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
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't make sense
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
Processing commands for [EMAIL PROTECTED]:
severity 452022 wishlist
Bug#452022: dpkg-dev: please ignore symbols differences on non-official
architectures
Severity set to `wishlist' from `serious'
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking
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
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 you the
14 matches
Mail list logo
