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]
