On Mon, 2010-08-09 at 11:10 -0400, Stephen Powell wrote: > On Sat, 07 Aug 2010 11:02:21 -0400 (EDT), Moritz Muehlenhoff wrote: > > On Tue, Jul 27, 2010 at 09:11:16AM -0400, Stephen Powell wrote: > >> Hello, Bastian. Sorry to bother you. I reopened this bug log because > >> it appears to be installable only on the amd64 architecture. I tried > >> to install it today on the i386 architecture and it failed with the > >> original symptoms. I have subscribed to this bug log; so there's no > >> need to CC me. > > > > non-free is no longer autobuilt. > > I hadn't heard that, but from searching the archives it appears that > this has been the case at least as far back as 2002; so I don't think > that's the problem.
No. There was non-free autobuilding on unofficial hosts until some time last year. Since then, there has been some work on integrating it in to the official buildd architecture; that functionality is currently disabled due to it trying to build packages that weren't whitelisted. ibm-3270 doesn't appear to have been built for some time before that, however and isn't on the whitelist. > If I understand what's going on here, the problem > is that 3270-common has a dependency on libicu40 for all architectures > *except* amd64. For amd64, it has a dependency on libicu42 instead. > Both of these packages are free. The problem is that libicu40 exists > only in unstable and only for the m68k architecture. I think all that > needs to be done is to change the dependencies of the package to > depend on libicu42 for all architectures, not just for amd64, and to > eliminate the dependency on libicu40. The dependencies are generated during the package build process. The source package doesn't say "depend on libicu40", it says "install libicu-dev during the build" and the correct runtime dependency is then generated. The amd64 packages in unstable do not depend on libicu at all, which is ideal. Rebuilding to depend on libicu42 would not help - that no longer exists in unstable, due to the ongoing icu transition which we need to finish in the very near future. > > we could limit the availability to handbuilt versions for amd64 and > > i386 > > In the first place, I don't see the need for that, and in the second > place, I use this in the s390 architecture as well. Surely there must > be a way to cross-build a package for another architecture. If there > isn't, I can at least build an i386 and an s390 package for you from > source, but I can't sign them, since I am not a DD or a DM. Cross-built packages aren't suitable for the archive. Even if the package is suitable for hand-building on all of the architectures which would be required, this would still require someone with the time and will to do so, and there aren't porter boxes available for all architectures. > > and file removal bugs for the outdated binaries from Lenny. > > That would not be good. Currently, installing back-level versions > from Lenny is my only circumvention. Just make 3270-common depend > on libicu42 for all architectures and remove the dependency on libicu40. > That's not hard, is it? I assume Moritz meant squeeze, rather than lenny. As to your last question, see above. The problem is caused by the fact that the package isn't built for all architectures, and the ideal solution is for there to be no icu dependency. The available options right now are: 1) ibm-3270 gets removed from squeeze 2) Someone hand-builds and uploads the unstable packages on !amd64, filing removal requests for any remaining architectures. The new packages could then migrate to squeeze. 3) The icu transition gets pushed in to squeeze a) leaving the packages in squeeze broken and breaking the squeeze/amd64 packages in the process (as libicu42 will no longer exist). b) and ibm-3270 from unstable gets pushed in at the same time, allowing amd64 to stay installable but leaving other architectures broken. Even if we do 3, the problem will still need fixing before release. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
