Hi, In the past week I worked on fixing packages which fail to build from source or are uninstallable due to dependency problems. There has not been much progress in the past week. On the one hand, there are now less packages in "failed" list, and these left are not easy to fix. On the other hand, there are a large number of "uninstallable" packages but I am not familiar to the way dependencies are fixed. Here are some of the packages that I looked into in the past week.
libsbml: This package depends on mono-runtime (>= 2.10.1). However, mipsel is not officially supported by mono developers, and there are some old versions available, built by community members. If no proper version is found for the package, then there is not much to do on this package. There are a number of similar cases. doris: It depends on triangle, but this package is not available. direnv: It depends on golang-go. Similar to mono, golang does not support mipsel. This leads to uninstallability of a number of packages. pycurl: It depends on both libgcrypt11-dev and libgcrypt20-dev, yet these two packages conflicts. I think it will be possible to eliminate the dependency on libgcrypt11-dev. ants: It depends on insighttoolkit4 which does not support mipsel, similar to mono and go. However, for some projects, it might be possible to look into the source and try to add support for mipsel. doublecmd: It depends on fp-utils. As fp-compiler comes from fpc and fpc depends on fp-compiler, it is not possible to build fpc directly. This leads to uninstallability of a number of packages. A cross-compilation may be needed. I am stuck on some "uninstallable" packages, because they are caused by similar reasons. This also means that as long as I can fix some of the important packages, a large number of packages can benefit. Some other work of last week: I uploaded patch for #746894 qapt: ftbfs with GCC-4.9. This bug is similar to the ones I dealt with sometime earlier. It is caused by change in symbols support in GCC-4.9. The fix is done through modifications of "symbols" files. As they affect Debian ports including MIPSEL, fixing them will lead to improvement in Debian port on MIPSEL. At the same time, fixing them is one good practice for me to get more familiar with the whole process of Debian package maintenance. In the coming week, I will focus on fixing packages which are "uninstallable" on mipsel port of Debian. Regards, Xilin _______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
