Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 unofficial arch information in mole. You're welcome to help make it available. mole is hosted on merkel, its source code is on a public repository. Jeroen seemed to think that it shouldn't be too difficult to do. Jeroen, can you look into it? Thus maintainers are not aware of issues with their packages on unofficial archs until someeon files a bug. That's true even for official arches in many cases. :) Anyway, I have nothing against adding support for unofficial arches on mole but the unofficial arches need to be made available in some coherent archive to not have to hardcode an URL for each unofficial arch. Be that gnuab.org or doorstep.debian.net, it doesn't matter much. 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. One option would be to use dpkg-architecture provided variables: I know that, it's precisely because it's easy to do that I suggested it. If it's useful, I'll implement it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. FWIW, Ryan is not interested to add this feature. During the discussion, we came to the conclusion that we should rather avoid using debian/*.symbols files in favor of debian/*.symbols.arch when the package maintainer is not sure if there's going to be differences in the set of symbols for all architectures. He can use #include to avoid duplicating the content too many times. That way unofficial arch won't use symbols files until the maintainer explicitely added support for them. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 problem unless there are good reasons why exported API differ on unofficial architectures more than on official architectures (this could be the case for kfreebsd-*, I don't know). I guess it is also very important for the release team, because armel is supposed to be shipped with lenny in order to drop arm for lenny + 1. This architecture has to be kept in good shape. And we'll make sure to find a statisfying solution once you give me all the relevant infos to really understand how far reaching the problem is. debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). As already explained, this is the case. Mole doesn't provide symbols for unofficial architectures (which I can understand), so packages will never have the symbols file for unofficial architectures. Did you read what I wrote? I said it will not fail if the package provides only debian/*.symbols.arch. And note that I am speaking of real examples. Just try on libusb for example. On which architecture did you try? And how? Where do I have an account on an armel machine or a kfreebsd one? 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. I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? 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 a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 output for kfreebsd: dh_makeshlibs -V -plibusb-0.1-4 --add-udeb=libusb-0.1-udeb dpkg-gensymbols: warning: some symbols disappeared in the symbols file. dpkg-gensymbols: warning: debian/libusb-0.1-4/DEBIAN/symbols doesn't match completely debian/libusb-0.1-4/DEBIAN/symbols --- dpkg-gensymbolsCjbx1b 2007-11-20 08:40:47 +0100 +++ dpkg-gensymbolsa5oh1T 2007-11-20 08:40:47 +0100 @@ -8,7 +8,7 @@ [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 - [EMAIL PROTECTED] 0.1.12-7 +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 @@ -21,7 +21,7 @@ [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 - [EMAIL PROTECTED] 0.1.12-7 +#DEPRECATED: 2:0.1.12-7# [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 [EMAIL PROTECTED] 0.1.12-7 dh_makeshlibs: command returned error code 256 make: *** [binary-arch] Erreur 1 This proves that with we will have legitimate API difference between architectures who have differing kernels. I don't think it's representative of the majority of packages though. 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 ABI across kernels, I am not sure that is the problem we will see the most. The most problematic variations, will happens on the same kernel, as it could be seen from bugs #441736, #429600 or #342084. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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, you're over exagerating the problem unless there are good reasons why exported API differ on unofficial architectures more than on official architectures (this could be the case for kfreebsd-*, I don't know). I guess it is also very important for the release team, because armel is supposed to be shipped with lenny in order to drop arm for lenny + 1. This architecture has to be kept in good shape. And we'll make sure to find a statisfying solution once you give me all the relevant infos to really understand how far reaching the problem is. debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). As already explained, this is the case. Mole doesn't provide symbols for unofficial architectures (which I can understand), so packages will never have the symbols file for unofficial architectures. Did you read what I wrote? I said it will not fail if the package provides only debian/*.symbols.arch. The ABI can be different on non official architectures, even if mole only provide a common file for all official architectures. And note that I am speaking of real examples. Just try on libusb for example. On which architecture did you try? And how? Where do I have an account on an armel machine or a kfreebsd one? I did test on kfreebsd-i386, but history has prove that it can happens on other architecture: bugs #441736, #429600 or #342084. If you want to get access to a GNU/kFreeBSD machine, have a look to http://io.debian.net/ssh.html . 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. Please see http://temp.aurel32.net/libusb_0.1.12-7_kfreebsd-i386.build I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? 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 a feature that could be added to sbuild. I asked neuro on IRC, I'm waiting his answer. Cheers, -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 ABI across kernels, I am not sure that is the problem we will see the most. The most problematic variations, will happens on the same kernel, as it could be seen from bugs #441736, #429600 or #342084. Riku said in #441736: This is the same bug as on unixodbc, #429600, #342084. 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 be not exported according to the version script). In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 be not exported according to the version script). 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 symbols file and the problem is solved. In any case, having new symbols as is the case in those reports will not generate a failure with the default behaviour of dpkg-gensymbols unless the maintainer want those failures. Wrong. Some symbols are missing on armel: Error: incorrect soname libodbcinstQ.so.1, missing symbol: Base QGList::count() const In turn this is caused by a bug in libtool because that symbol should never have been exported on any arch... and on armel gcc was doing the right thing by inlining the function properly. So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. And if you want a permanent work-around, I already suggested the environment variable. I haven't seen any other better alternative yet. So it's still not representative of failures that we're likely to get due to dpkg-gensymbols (unless many maintainers decide to increase the level of checks, which I doubt. Furthermore maintainers that do that are likely reactive maintainer that will quickly integrate changes needed for unofficial architectures). As explained, it would have also failed on armel without increasing the level of checks. Because of a bug in libtool. I fail to see why we should be more lax just because libtool has bugs. That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 symbols file and the problem is solved. Except that the problem appearing only on unofficial architectures, mole provide a common symbols file. That is where the problem lies. If we manage to have common symbol set for hurd-i386 and all the other arches, then I think it should be doable to have the same symbol set on unofficial architectures (or at least a superset). So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. Even if the bug is present in all architectures, its effects are only visible on armel. And maintainers do not care about unofficial architectures, so the package will simply FTBFS. The fix is to remove one private symbol from the debian/*.symbols file so that the lack of the symbol doesn't generate a failure. This fix is trivial and can be done easily in a porter NMU without risking to break everything. libtool is buggy, and that is even more true for older versions. And if you look at the archive, you will see that most of libraries use an old libtool version. Indeed, but maybe the implementation of proper symbols versioning in the debian package will trigger the required relibtoolizing... because hurd-i386 also needs it in many cases. The library has to fixed, but the job of porters is not to fix general problems with libraries, we already have a lot of work to do in other domains. But if porters doesn't fix this, the maintainer will simply ignore the problem, even if a bug report is sent. If we follow your logic, we shouldn't do anything because maintainers are not doing their work. While there's some truth in that, I just can't accept this conclusion. That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. I totally agree it's better to fail in such cases, but it is better to fails on all architectures, so that the problem is not just ignored. If only... there's no way for me to know if a symbol was intendend to be private or not. So I can't do this. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 are not aware of issues with their packages on unofficial archs until someeon files a bug. I can also see that this potentially much bigger problem for hurd/kfreebsd. 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. One option would be to use dpkg-architecture provided variables: DEB_HOST_ARCH=armel DEB_HOST_ARCH_OS=linux DEB_HOST_ARCH_CPU=arm DEB_HOST_GNU_CPU=arm DEB_HOST_GNU_SYSTEM=linux-gnueabi DEB_HOST_GNU_TYPE=arm-linux-gnueabi Thus one can use DEB_HOST_ARCH for symbol files specific for one arch, DEB_HOST_ARCH_OS for kfreebsd/hurd DEB_HOST_ARCH_CPU when same set of symbols affects arm and armel or all Because of a bug in libtool. I fail to see why we should be more lax just because libtool has bugs. I think the pessimism to libtool comes from bugs like #347650 not getting solved over time.. mind you that bug would help with the same goal symbols file is working on - making transitions easier. For the c++ and -version-script bug, #430971 I think this might be much easier to fix. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. for most libraries, creating a version script should be be the same amount of work as separating private/public symbols in .symbols file. Also automatically generating .symbols file from version script should not be very hard. The big benefit of using version-scripts is that it makes dynamic linking much more faster, when the symbol tables have only the needed symbols. -- rm -rf only sounds scary if you don't have backups signature.asc Description: Digital signature
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 to have a common symbols file and the problem is solved. Except that the problem appearing only on unofficial architectures, mole provide a common symbols file. That is where the problem lies. If we manage to have common symbol set for hurd-i386 and all the other arches, then I think it should be doable to have the same symbol set on unofficial architectures (or at least a superset). You can get data for kfreebsd-i386, kfreebsd-amd64 and armel from gnuab.org. The repository is rsyncable, and we can even send a push signal. But that don't solve the problem for other unofficial architectures (what comes to mind is nexenta, sh4, m32r). So the initial problem is not armel-specific and I fail to see why we should ignore it when this failure enabled us to discover a bug in libtool. Even if the bug is present in all architectures, its effects are only visible on armel. And maintainers do not care about unofficial architectures, so the package will simply FTBFS. The fix is to remove one private symbol from the debian/*.symbols file so that the lack of the symbol doesn't generate a failure. This fix is trivial and can be done easily in a porter NMU without risking to break everything. libtool is buggy, and that is even more true for older versions. And if you look at the archive, you will see that most of libraries use an old libtool version. Indeed, but maybe the implementation of proper symbols versioning in the debian package will trigger the required relibtoolizing... because hurd-i386 also needs it in many cases. The library has to fixed, but the job of porters is not to fix general problems with libraries, we already have a lot of work to do in other domains. But if porters doesn't fix this, the maintainer will simply ignore the problem, even if a bug report is sent. If we follow your logic, we shouldn't do anything because maintainers are not doing their work. While there's some truth in that, I just can't accept this conclusion. You are changing the truth. I never said we shouldn't do anything, I proposed solutions so that the packages do not FTBFS on unofficial architectures. But you rejecting most them, instead trying to convince me there is no or very few problems. Also note that the main difference is that FTBFS are considered RC for official architectures, so if a maintainer don't do his/her job, others can NMU the package. That is not true for unofficial architecture, even if we managed to NMU some of them when the maintainer is clearly MIA. That said, we might want to have the possibility to flag private symbols in symbols file and have a mode where the disparition of private symbols doesn't cause a failure. Not sure about it. That is not a correct solution. If you are able to list private symbols, better not export them instead of flagging them. Yes, but that's not something I control. In fact, if that's what you want, it's better to fail so that we can report problems to maintainers who will then prod upstream to implement a version script or similar. I totally agree it's better to fail in such cases, but it is better to fails on all architectures, so that the problem is not just ignored. If only... there's no way for me to know if a symbol was intendend to be private or not. So I can't do this. Cheers, -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 architectures, as the symbols for those architectures are not available on mole and may vary a bit. This causes packages to fails to build in case of differences in the list of symbols, and will progressively break all unofficial architectures, even those that we want to *integrate as an official* architecture sooner or later. Listing all unofficial architectures on mole is not something really easy to do, but on the other hand as unofficial architectures don't have testing, we don't care about over-strict dependencies. As already suggested, please ignore new or missing symbols on unofficial architectures and generate a new symbols file in that case (the current list of official architectures is: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc). -- System Information: Debian Release: lenny/sid Architecture: kfreebsd-i386 (i686) Kernel: kFreeBSD 6.2-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 5.97-5.3 The GNU core utilities ii libc0.1 2.6.1-6GNU C Library: Shared libraries dpkg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 architectures are not available on mole and may vary a bit. This is not a justification. This causes packages to fails to build in case of differences in the list of symbols, and will progressively break all unofficial architectures, even those that we want to *integrate as an official* architecture sooner or later. You're too pessimistic IMO. If the package has debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). It will only fail if the package provides a debian/package.symbols file (i.e. common to all architectures) and if symbols listed in that file disappear on non-official architectures. As already suggested, please ignore new or missing symbols on unofficial architectures and generate a new symbols file in that case (the current list of official architectures is: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc). I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#452022: dpkg-dev: please ignore symbols differences on non-official architectures
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 right to ignore the problem as you did until now. I guess it is also very important for the release team, because armel is supposed to be shipped with lenny in order to drop arm for lenny + 1. This architecture has to be kept in good shape. problem: it potentially breaks all unofficial architectures, as the symbols for those architectures are not available on mole and may vary a bit. This is not a justification. This causes packages to fails to build in case of differences in the list of symbols, and will progressively break all unofficial architectures, even those that we want to *integrate as an official* architecture sooner or later. You're too pessimistic IMO. If the package has debian/package.symbols.arch files then it will not fail because it won't find a symbols file for the given architecture and will thus generate a brand new one (and the comparison will only find new symbols and it will not fail). As already explained, this is the case. Mole doesn't provide symbols for unofficial architectures (which I can understand), so packages will never have the symbols file for unofficial architectures. And note that I am speaking of real examples. Just try on libusb for example. It will only fail if the package provides a debian/package.symbols file (i.e. common to all architectures) and if symbols listed in that file disappear on non-official architectures. As already suggested, please ignore new or missing symbols on unofficial architectures and generate a new symbols file in that case (the current list of official architectures is: alpha amd64 arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sparc). I won't harcode such a behaviour in dpkg. However what is doable is have an environment variable that will override the check level that that the package is using. Then you just have to make sure that the buildd of the unofficial arches define that environment variable. Does that seem reasonable? 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. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
