On 10/05/2010 01:56 PM, Michael Hope wrote:
On Wed, Oct 6, 2010 at 12:20 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please:
- Mention the idea to upstream to see if anyone disagrees
- See if anyone upstream has other ARM or x86 patches to include
- Test under ARM Thumb-2, i686, and x86_64
- Spin a tarball to go out with the 2010.11 release.
NB: If we spin a tarball which is more than an upstream snapshot (e.g. we include patches from the mailing-list), we should rename it (for instance "ltrace-linaro")
Hmm. There's a conflict there. One requirement is to be 'traceable back to the upstream version'. If we pick up random patches then that is hard and calling it ltrace-linaro makes sense. However, we also want later upstream ltrace release to automatically obsolete ours.
If we release a 'ltrace-linaro', which turns into the Ubuntu package 'ltrace-linaro', can it be superseded by a later 'ltrace' release?
Personally, I think the simplest/best solution will be to encourage upstream to release a new version. At the very least, I would like to see all of the needed patches make it into an official upstream Git tree, which presently seems unlikely to happen soon without some help. Certainly, I believe that Linaro should avoid maintaining this type of secondary project indefinitely, and that is exactly what I see happening unless something changes with the upstream project.
I sent an e-mail to the ltrace-devel list today to encourage one of the recent contributors to begin preparing a new tree for the purposes of release, as he has been waiting patiently for almost a year in the hope that the maintainer will reappear and handle that task. There are literally dozens of patches that basically have been ignored during the past year which I think deserve to be committed, so I also directly encouraged the ltrace community to consider adopting a new maintainer and begin moving forward again. At the very least, I have turned the situation into a fire for the current maintainer that can't be ignored.
Meanwhile, I have been trying to determine why I am getting lots of segfaults when running the test suite on an ARM test machine. On the upside, the x86 test suite works fine after a couple of the outstanding patches were applied to my tree, but they didn't solve the problems that I am seeing on ARM. I will continue to investigate these issues and brace myself for the possibility that I might need to spin a Linaro release.
I wonder whether we should start some list of target distros for which we build binaries like this one, or valgrind or qemu or simply the toolchain
I'm talking about similar things with Steve Langaseck. My minimum is GCC and GDB native and cross on Ubuntu Lucid. Past that would be Fedora, then openSUSE, then Windows 7. I'd like the Ubuntu packages to actually be Debian packages that work well with Ubuntu.
I presume this will all be readily automated?