On Mon, 09 Aug 2010 13:37:45 -0400 (EDT), Adam D. Barratt wrote: > 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: >>> 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.
OK. >> >> 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. It looks like you're right about that. I just downloaded the Squeeze version of the source code and built a binary package from it for i386. dpkg-deb -I reports that the package has a dependency on libicu42. And it installs and runs correctly. So it looks like Morris had the right idea. The binary packages have not been built in a while. And that's the cause of the problem. > 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. OK. >> ... 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. > ... > 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. I'm afraid you've lost me on this one. Pardon my denseness and my ignorance of what other things are going on in the Debian project that I either don't know about or don't understand, or both. As my experiments have shown, the current Squeeze source package builds and installs just fine on Squeeze. It just has to be built. It seems to me that something needs to be done to get these packages to autobuild again somehow. What needs to be done to make that happen? Whitelist the package? (whatever that means) Whitelist the package plus re-enabling the disabled functionality (with checks for whitelisted packages)? Why is this the wrong approach? >From what you've told me, that seems to be the way to go. Am I missing something? As for Sid, if there is no dependency on libicu at all, then they do not depend on libicu for any architecture, right? And the fact that libicu does not exist in Sid is no problem. Again, the packages just have to be built. It seems to me that the solution is to find some way to get the packages to autobuild again, as was done in the past. It seems to me that that will solve all the problems. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
