Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Hi Andreas, I'm sorry, I seem to have missed this reply earlier. Thanks for your ping. On Sat, Jun 13, 2020 at 12:46:28PM +0200, Andreas Tille wrote: > On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote: > > > microbiomeutil fails to cross build from source, because it fails > > > running cdbfasta with an "Exec format error". > > I've just uploaded cdbfasta_1.00+git20181005.014498c+dfsg-1. > You did not specified the exact error of microbiomeutil, but if > you would specify the very command line we could add this to > autopkgtest of the package (in case this might help). The precise command is quite irrelevant. Any invocation of cdbfasta fails in the same way. The error happens before any actual code from the executable is run. Due to not being marked Multi-Arch something, the host architecture cdbfasta is installed and any ELF executable for the host architecture fails in roughly the same way. Either one gets a direct "Exec format error" or the shell tries running the ELF binary as a shell script. The problem is that we are trying to run a host architecture binary. The question now is: Does a build architecture cdbfasta behave exactly the same way as a host architecture cdbfasta if the host architecture one were actually runnable (e.g. using qemu)? You can rephrase this question as: | Is there any other way of interacting with cdbfasta or cdbyank where the | processor architecture would matter? To which you answered "I have no idea about these questions." This seems to be kind of a show stopper to making progress here. We need someone who has a good understanding of what this software does. > Please check again since from my naive point of view the package > should not cause any issues. Any package which is not Multi-Arch tagged and ships ELF binaries in $PATH can be a problem to cross building. cdbfasta is. (Possibly though the issue is infeasible to fix and we may end up closing the bug as wontfix. I don't think we're there yet.) Helmut
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Ping. Can we close this bug? Kind regards, Andreas. On Sat, Jun 13, 2020 at 12:46:28PM +0200, Andreas Tille wrote: > On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote: > > > microbiomeutil fails to cross build from source, because it fails > > > running cdbfasta with an "Exec format error". > > I've just uploaded cdbfasta_1.00+git20181005.014498c+dfsg-1. > You did not specified the exact error of microbiomeutil, but if > you would specify the very command line we could add this to > autopkgtest of the package (in case this might help). > > Please check again since from my naive point of view the package > should not cause any issues. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote: > > microbiomeutil fails to cross build from source, because it fails > > running cdbfasta with an "Exec format error". I've just uploaded cdbfasta_1.00+git20181005.014498c+dfsg-1. You did not specified the exact error of microbiomeutil, but if you would specify the very command line we could add this to autopkgtest of the package (in case this might help). Please check again since from my naive point of view the package should not cause any issues. Kind regards Andreas. -- http://fam-tille.de
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Hi Helmut, On Sat, Jun 13, 2020 at 06:53:04AM +0200, Helmut Grohne wrote: > > Getting in touch with you and the Debian Med mailing list since the > > answer is not clear to me. > > So can you give some more background about the file formats involved? > > As far as I can see, those FASTA files are always textual. Is that > correct? Yes. > It doesn't seem likely that anything architetcure-specific > would be found inside them. To the contrary, it seems like FASTA is an > exchange format. Is that also correct? As far as I know yes. > The output files of cdbfasta are binary. The README on github[1] says: > | The index files are now architecture independent, the same index file can be > | created and used on many different Unix platform (be it 32bit/64bit, > | big-endian or little-endian architectures) and even Windows. > > Is the cdbfasta in Debian recent enough to be covered by this? Does a > recent cdbfasta allow working with old, architecture-specific index > files created from earlier releases? > > Is there any other way of interacting with cdbfasta or cdbyank where the > processor architecture would matter? I have no idea about these questions. > [1] https://github.com/gpertea/cdbfasta, maybe updating the homepage of > cdbfasta to this would be good? The sourceforge page isn't that > helpful. I've updated Git and will check later. May be droping the outdated code copy of gclib by the Debian packaged version will solve the issue you observed. Kind regards Andreas. -- http://fam-tille.de
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Hi Andreas, On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote: > On Thu, Jun 11, 2020 at 06:26:47PM +0200, Helmut Grohne wrote: > > > > microbiomeutil fails to cross build from source, because it fails > > running cdbfasta with an "Exec format error". Usually, this indicates > > that the relevant package should be marked Multi-Arch: foreign. It is > > not entirely clear to me whether doing so is correct. Can you help me > > figure out? Please point out what is wrong below. > > > > Reading the cdbfasta manual page, it seems to be a tool for transforming > > file formats. Looking into microbiomeutil, it seems that the input > > format is textual. Textual file formats usually are > > architecture-independent. Then microbiomeutil installs the output files > > into an architecture-independent package. If those output files were > > architecture-dependent, then microbiomeutil would be wrong in doing so. > > This suggests that the marking should be correct. The question really > > is: Does the command line interface or input/output format of cdbfasta > > or cdbyank depend on the processor architecture it is being run on? If > > the answer is "no", please mark it Multi-Arch: foreign. If the answer is > > "yes", please close this bug. If the answer is not clear, please get in > > touch we me an we can figure out together. > > Getting in touch with you and the Debian Med mailing list since the > answer is not clear to me. So can you give some more background about the file formats involved? As far as I can see, those FASTA files are always textual. Is that correct? It doesn't seem likely that anything architetcure-specific would be found inside them. To the contrary, it seems like FASTA is an exchange format. Is that also correct? The output files of cdbfasta are binary. The README on github[1] says: | The index files are now architecture independent, the same index file can be | created and used on many different Unix platform (be it 32bit/64bit, | big-endian or little-endian architectures) and even Windows. Is the cdbfasta in Debian recent enough to be covered by this? Does a recent cdbfasta allow working with old, architecture-specific index files created from earlier releases? Is there any other way of interacting with cdbfasta or cdbyank where the processor architecture would matter? Helmut [1] https://github.com/gpertea/cdbfasta, maybe updating the homepage of cdbfasta to this would be good? The sourceforge page isn't that helpful.
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
On Thu, Jun 11, 2020 at 06:26:47PM +0200, Helmut Grohne wrote: > > microbiomeutil fails to cross build from source, because it fails > running cdbfasta with an "Exec format error". Usually, this indicates > that the relevant package should be marked Multi-Arch: foreign. It is > not entirely clear to me whether doing so is correct. Can you help me > figure out? Please point out what is wrong below. > > Reading the cdbfasta manual page, it seems to be a tool for transforming > file formats. Looking into microbiomeutil, it seems that the input > format is textual. Textual file formats usually are > architecture-independent. Then microbiomeutil installs the output files > into an architecture-independent package. If those output files were > architecture-dependent, then microbiomeutil would be wrong in doing so. > This suggests that the marking should be correct. The question really > is: Does the command line interface or input/output format of cdbfasta > or cdbyank depend on the processor architecture it is being run on? If > the answer is "no", please mark it Multi-Arch: foreign. If the answer is > "yes", please close this bug. If the answer is not clear, please get in > touch we me an we can figure out together. Getting in touch with you and the Debian Med mailing list since the answer is not clear to me. Kind regards Andreas. -- http://fam-tille.de
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Package: cdbfasta Version: 0.99-20100722-6 User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:microbiomeutil microbiomeutil fails to cross build from source, because it fails running cdbfasta with an "Exec format error". Usually, this indicates that the relevant package should be marked Multi-Arch: foreign. It is not entirely clear to me whether doing so is correct. Can you help me figure out? Please point out what is wrong below. Reading the cdbfasta manual page, it seems to be a tool for transforming file formats. Looking into microbiomeutil, it seems that the input format is textual. Textual file formats usually are architecture-independent. Then microbiomeutil installs the output files into an architecture-independent package. If those output files were architecture-dependent, then microbiomeutil would be wrong in doing so. This suggests that the marking should be correct. The question really is: Does the command line interface or input/output format of cdbfasta or cdbyank depend on the processor architecture it is being run on? If the answer is "no", please mark it Multi-Arch: foreign. If the answer is "yes", please close this bug. If the answer is not clear, please get in touch we me an we can figure out together. Helmut
