RFS: stateserial -- Displays serial port modem status lines

2020-05-01 Thread 偉銘陳
Hi,

I found this package was orphaned for few years, and I also found a bug
with it.

I decided to become a new maintainer for this  package and followed the
instruction here(https://www.debian.org/devel/wnpp/index.html#howto-o).

I have retitled this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848564, and also I tried
to edit the files(changelog, control and source code) in package, finally I
use the command "dpkg-buildpackage -us -uc -d", then I got few files which
are attached in this email

Thank you very much for spending time reading this email, and I think the
next step that I should to is to find a sponsor to upload the package for
me, so I wrote this email. If there is anything that I did wrongly, please
let me know, I will do my best to fixed it.

Sincerely yours,

Aristo Chen


statserial_1.1-25.dsc
Description: Binary data


statserial_1.1-25_amd64.deb
Description: Binary data


statserial_1.1-25_amd64.changes
Description: Binary data


statserial_1.1-25.debian.tar.gz
Description: GNU Zip compressed data


Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library

2020-05-01 Thread Aaron Boxer
Hi Adam,
Thanks a lot for testing this I've fixed the build error - please try it
again when you have time.
Cheers,
Aaron

On Fri, May 1, 2020 at 7:21 PM Adam Borowski  wrote:

> On Wed, Apr 29, 2020 at 04:53:38PM -0400, Aaron Boxer wrote:
> >  * Package name: libgrokj2k
> >Version : 7.1.0-1
>
> > It builds those binary packages:
> >
> >   libgrokj2k1 - JPEG 2000 image compression/decompression library
> >   libgrokj2k1-dev - development files for Grok, a JPEG 2000 image library
> >   grokj2k-tools - command-line tools for the Grok JPEG 2000 library
>
> I'm afraid it doesn't build in a minimal chroot.
> Log attached.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
> ⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
> ⠈⠳⣄
>


Bug#959398: RFS: hmat-oss/1.2.0-2.1 [NMU, RC] -- dynamic libraries for HMat

2020-05-01 Thread Sudip Mukherjee
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "hmat-oss"

 * Package name: hmat-oss
   Version : 1.2.0-2.1
   Upstream Author : Jerome Robert 
 * URL : https://github.com/jeromerobert/hmat-oss
 * License : GPL-2+
 * Vcs : 
http://anonscm.debian.org/gitweb/?p=debian-science/packages/hmat-oss.git
   Section : science

It builds those binary packages:

  libhmat-oss1 - dynamic libraries for HMat
  libhmat-oss-dev - headers and development libraries for HMat
  libhmat-oss1-dbg - debug symbols for HMat

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/hmat-oss

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hmat-oss/hmat-oss_1.2.0-2.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix FTBFS. (Closes: #897768)


-- 
Regards
Sudip



Bug#956414: #956414: Upload a partially fixed version?

2020-05-01 Thread Svante Signell
On Mon, 2020-04-13 at 00:36 +0200, Svante Signell wrote:
> Hi again,
> 
> I saw that there was some complaints from lintian of the uploaded 
> version. I've fixed some of them. Upload again?
> 
> BTW: running lintian with the --pedantic flag does not show all
> issues as 956...@bugs.debian.org does. Which option(s) trigger all
> the output at the link?

Correction:
956...@bugs.debian.org -> https://mentors.debian.net/package/eudev

I got the tip by Lorenzo to use lintian -EviI --pedantic
.changes and that seems to find some of the lintian output to
the upload. How to get the full list?

After improving the package, do I need to increment the version from
3.2.9-7+debian1 to 3.2.9-7+debian2? Until now I have not got any
feedback or a sponsor yet.

Thanks!



Bug#955443: marked as done (RFS: libkibi/0.1.1-2.1 [NMU, RC] -- library for byte prefixes)

2020-05-01 Thread Debian Bug Tracking System
Your message dated Fri, 01 May 2020 10:36:05 -0400
with message-id <0f3ade0b0f089894238f54c7282aa70af527bd9e.ca...@debian.org>
and subject line Re: RFS: libkibi/0.1.1-2.1 [NMU, RC] -- library for byte 
prefixes
has caused the Debian Bug report #955443,
regarding RFS: libkibi/0.1.1-2.1 [NMU, RC] -- library for byte prefixes
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
955443: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955443
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libkibi"

 * Package name: libkibi
   Version : 0.1.1-2.1
   Upstream Author : Benjamin Drung 
 * URL : https://launchpad.net/libkibi
 * License : ISC
 * Vcs : https://anonscm.debian.org/cgit/collab-maint/libkibi.git
   Section : libs

It builds those binary packages:

  libkibi0 - library for byte prefixes
  libkibi-dbg - library for byte prefixes (debugging symbols)
  libkibi-dev - library for byte prefixes (development files)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libkibi

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkibi/libkibi_0.1.1-2.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs with GCC. (Closes: #925747)


-- 
Regards
Sudip
--- End Message ---
--- Begin Message ---
Hi,

On Tue, 31 Mar 2020 20:42:00 +0100 Sudip Mukherjee  wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libkibi"
> 
>  * Package name: libkibi
>Version : 0.1.1-2.1
> Changes since the last upload:
> 
>* Non-maintainer upload.
>* Fix ftbfs with GCC. (Closes: #925747)

Uploaded, thanks. Besides this fix, I also updated the Vcs-* fields and
migrate the packaging repo from Alioth to Salsa.

-- 
Best,
Boyuan Yang


signature.asc
Description: This is a digitally signed message part
--- End Message ---


Bug#956731: RFS: check/0.14.0-0.1 [NMU] -- unit test framework for C

2020-05-01 Thread Tobias Frost
Hi Christian,

it seems that check would be a candiate to be ITSed?
So if you are interested I would suggest to start the ITS process…

(Its ok if not, let me know, I will then take a look at the RFS.
However, it looks like that at least some of the changes are out of scope for an
NMU. Also, your changelog should close the cited bugs.)

-- 
Cheers,
tobi



Bug#951202: Response on your feedback

2020-05-01 Thread Leon Marz
Hi Jordan and Thomas, thank you for your kind advise. I updated the 
package with all the proposed changes. > Do you plan to try to maintain 
the package going forward? (Watch for > new upstream releases, work on 
bugs, etc?) Yes, I want to further maintain this package. > Do you have 
plans to manage the package files in git, perhaps on > salsa.debian.net? 
I'm not sure if it is allowed to start using salsa > for a project 
before it makes it into debian. The salsa FAQ is vague > on this point: 
> > https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa > > 
But I think it is often allowed. I know of at least 2 cases where a > 
repo was created for a package before it got included into Debian. I > 
expect some basic review of the package is probably good first, and > 
perhaps this email can serve for that. > > If not salsa.debian.net, you 
could still host it in a github repo and > include the links to it in 
the control file. (And, that could move to > salsa later too.) I do want 
to manage the package on salsa.debian.org. It would be nice, if you 
could create a repository and give me upload rights to it. My username 
is lmarz. - Leon




Re: Not all files in my package installed

2020-05-01 Thread Tong Sun
On Fri, May 1, 2020 at 4:17 AM Sven Hartge - s...@svenhartge.de
 wrote:
>
> Tong Sun  wrote:
>
> > --
> > $ ls -l `dpkg -L dbab` > /dev/null
> > ls: cannot access '/usr/share/doc/dbab/README.Debian': No such file or
> > directory
> > ls: cannot access '/usr/share/doc/dbab/changelog.Debian.gz': No such file
> > or directory
> > ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.intranet.conf': No such
> > file or directory
> > ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.service.conf': No such
> > file or directory
> > ls: cannot access '/usr/share/doc/dbab/dbab-squid.localnet.conf': No such
> > file or directory
> > ls: cannot access '/usr/share/doc/dbab/dbab-squid.service.conf': No such
> > file or directory
> > ls: cannot access '/usr/share/doc/dbab/dbab.md.gz': No such file or
> > directory
> > ls: cannot access '/usr/share/man/man8': No such file or directory
> > ls: cannot access '/usr/share/man/man8/dbab-svr.8.gz': No such file or
> > directory
> > ls: cannot access '/usr/share/man/man8/dbab-add-list.8.gz': No such file or
> > directory
> > ls: cannot access '/usr/share/man/man8/dbab-chk-list.8.gz': No such file or
> > directory
> > ls: cannot access '/usr/share/man/man8/dbab-get-list.8.gz': No such file or
> > directory
> > ls: cannot access '/usr/share/man/man8/dhcp-add-wpad.8.gz': No such file or
> > directory
> > --
>
> > What could possibly be wrong?
>
> Could be dpkg's path-include and path-exclude configuration on your
> local system, for example from localepurge.
>
> Does
>
>   rgrep "path-" /etc/dpkg
>
> return anything for you?

Ah~~~, thank you, thank you Sven, and David!

Indeed --

/etc/dpkg/dpkg.cfg.d/docker:path-exclude /usr/share/doc/*
/etc/dpkg/dpkg.cfg.d/docker:path-exclude /usr/share/man/*
. . .

I've been pulling my hair worrying something is wrong with my package!

phrew, THANKS!!



Re: Salsa respository e2tools eject

2020-05-01 Thread atzlinux

在 2020/5/1 下午7:00, Kyle Robbertze 写道:
> Hi,
>
> On 2020/05/01 12:36, atzlinux wrote:
>> Hi,
>>
>> Can somebody create the e2tools repository and give me master rights to
>> that repository? My username is atzlinux-guest.
>>
> Done - https://salsa.debian.org/debian/e2tools
>
> Cheers
> Kyle

Thanks!

Your reply is so quick!

I have the rights for e2tools and eject repos now,commit is OK.

-- 
肖盛文 Faris Xiao
微信:atzlinux
QQ:909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统:https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature


Re: Salsa respository eject rights apply

2020-05-01 Thread Kyle Robbertze
Hi,

On 2020/05/01 12:47, atzlinux wrote:
> Hi,
> 
>I'm new maintainer of the package eject[1],
> The git repository for eject is [2]. 
> 
> Can somebody give me master rights to the eject repository? 
> My username is atzlinux-guest.

Done

Cheers
Kyle

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



Re: Salsa respository e2tools

2020-05-01 Thread Kyle Robbertze
Hi,

On 2020/05/01 12:36, atzlinux wrote:
> Hi,
> 
> The repository for e2tools for which I am new maintainer, is sourced from 
> my personal SALSA git environment.
> I want to migrate to a public SALSA repository but I don't have the
> rights to do that.
> 
> Can somebody create the e2tools repository and give me master rights to
> that repository? My username is atzlinux-guest.
> 

Done - https://salsa.debian.org/debian/e2tools

Cheers
Kyle
-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze



Salsa respository eject rights apply

2020-05-01 Thread atzlinux
Hi,

   I'm new maintainer of the package eject[1],
The git repository for eject is [2]. 

Can somebody give me master rights to the eject repository? 
My username is atzlinux-guest.

Thanks a lot!

[1] https://tracker.debian.org/pkg/eject
[2] https://salsa.debian.org/debian/eject

-- 
肖盛文 Faris Xiao
微信:atzlinux
QQ:909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统:https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature


Salsa respository e2tools

2020-05-01 Thread atzlinux
Hi,

The repository for e2tools for which I am new maintainer, is sourced from 
my personal SALSA git environment.
I want to migrate to a public SALSA repository but I don't have the
rights to do that.

Can somebody create the e2tools repository and give me master rights to
that repository? My username is atzlinux-guest.

Thanks a lot!

-- 
肖盛文 Faris Xiao
微信:atzlinux
QQ:909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统:https://www.atzlinux.com



signature.asc
Description: OpenPGP digital signature


Re: Not all files in my package installed

2020-05-01 Thread Sven Hartge
Tong Sun  wrote:

> --
> $ ls -l `dpkg -L dbab` > /dev/null
> ls: cannot access '/usr/share/doc/dbab/README.Debian': No such file or
> directory
> ls: cannot access '/usr/share/doc/dbab/changelog.Debian.gz': No such file
> or directory
> ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.intranet.conf': No such
> file or directory
> ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.service.conf': No such
> file or directory
> ls: cannot access '/usr/share/doc/dbab/dbab-squid.localnet.conf': No such
> file or directory
> ls: cannot access '/usr/share/doc/dbab/dbab-squid.service.conf': No such
> file or directory
> ls: cannot access '/usr/share/doc/dbab/dbab.md.gz': No such file or
> directory
> ls: cannot access '/usr/share/man/man8': No such file or directory
> ls: cannot access '/usr/share/man/man8/dbab-svr.8.gz': No such file or
> directory
> ls: cannot access '/usr/share/man/man8/dbab-add-list.8.gz': No such file or
> directory
> ls: cannot access '/usr/share/man/man8/dbab-chk-list.8.gz': No such file or
> directory
> ls: cannot access '/usr/share/man/man8/dbab-get-list.8.gz': No such file or
> directory
> ls: cannot access '/usr/share/man/man8/dhcp-add-wpad.8.gz': No such file or
> directory
> --

> What could possibly be wrong?

Could be dpkg's path-include and path-exclude configuration on your
local system, for example from localepurge.

Does

  rgrep "path-" /etc/dpkg

return anything for you?

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.



Re: Not all files in my package installed

2020-05-01 Thread David Kalnischkies
On Thu, Apr 30, 2020 at 07:59:26PM -0400, Tong Sun wrote:
> What could possibly be wrong?

If that would be files in /etc I would point you to the configuration
management by dpkg (as a removed file is a configuration change, too,
so dpkg preserves it) – that isn't the case here, but someone else might
stumble over this thread.


In your case with /usr/share/doc and manpages effected: Is this
a container? It is relatively popular to use path-excludes in them,
so have a look at /etc/dpkg/dpkg.cfg and /etc/dpkg/dpkg.cfg.d/*.

There might be stanzas like:
path-exclude /usr/share/man/*
path-exclude /usr/share/doc/*
in there.

If that is the case, it has nothing to do with your package and
works as intended™.

(Disclaimer: If excludes by default are a good or bad idea can
highly depend on the usecase and is out of scope for my reply)


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

2020-05-01 Thread Jeffrey Walton
On Fri, May 1, 2020 at 3:05 AM Jeffrey Walton  wrote:
>
> On Fri, May 1, 2020 at 2:14 AM Andreas Tille  wrote:
> >
> >  ...
> > ==13209== Process terminating with default action of signal 10 (SIGBUS)
> > ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
> > ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
> > ==13209==by 0x11A6C4: Align (clustal-omega.c:1221)
> > ==13209==by 0x1171C8: MyMain (mymain.c:1192)
> > ==13209==by 0x113CCC: main (main.cpp:469)
>
> Here is line 346 in
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346:
>
> NewProgress(, LogGetFP(, LOG_INFO),
> "Ktuple-distance calculation progress", bPrintCR);
>
> For testing, change LogGetFP(, LOG_INFO) for stdout for testing. I.e.,
>
> NewProgress(, stdout,,
> "Ktuple-distance calculation progress", bPrintCR);
>
> It looks like LogGetFP retrieves an entry in an array of FILE*. From
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.h:
>
> typedef struct {
> /* the higher the level, the more priority it has. numbers must be
>  *  sequential
>  */
>
> /* array of function pointers */
> void (*prFunc[LOG_NUM_LEVELS]) (FILE *prFP, char *pcFormat,
> va_list rVArgList);
> FILE *prFP[LOG_NUM_LEVELS];
> char *prPrefix[LOG_NUM_LEVELS];
>
> /* everything above this level will be printed */
> int iLogLevelEnabled;
> } log_t;
>
> And 
> https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.c:
>
> FILE *
> LogGetFP(log_t *prLog, int iLevel)
> {
> assert(iLevel>=0 && iLevel<=LOG_NUM_LEVELS);
> return prLog->prFP[iLevel];
> }
>
> That should help determine if something is sideways in the log_t structure.

Also, I think this should be:

> FILE *
> LogGetFP(log_t *prLog, int iLevel)
> {
> assert(iLevel>=0 && iLevel return prLog->prFP[iLevel];
> }

That is, 'iLevel

Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

2020-05-01 Thread Jeffrey Walton
On Fri, May 1, 2020 at 2:14 AM Andreas Tille  wrote:
>
>  ...
> ==13209== Process terminating with default action of signal 10 (SIGBUS)
> ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
> ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
> ==13209==by 0x11A6C4: Align (clustal-omega.c:1221)
> ==13209==by 0x1171C8: MyMain (mymain.c:1192)
> ==13209==by 0x113CCC: main (main.cpp:469)

Here is line 346 in
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/pair_dist.c#L346:

NewProgress(, LogGetFP(, LOG_INFO),
"Ktuple-distance calculation progress", bPrintCR);

For testing, change LogGetFP(, LOG_INFO) for stdout for testing. I.e.,

NewProgress(, stdout,,
"Ktuple-distance calculation progress", bPrintCR);

It looks like LogGetFP retrieves an entry in an array of FILE*. From
https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.h:

typedef struct {
/* the higher the level, the more priority it has. numbers must be
 *  sequential
 */

/* array of function pointers */
void (*prFunc[LOG_NUM_LEVELS]) (FILE *prFP, char *pcFormat,
va_list rVArgList);
FILE *prFP[LOG_NUM_LEVELS];
char *prPrefix[LOG_NUM_LEVELS];

/* everything above this level will be printed */
int iLogLevelEnabled;
} log_t;

And https://salsa.debian.org/med-team/clustalo/-/blob/master/src/clustal/log.c:

FILE *
LogGetFP(log_t *prLog, int iLevel)
{
assert(iLevel>=0 && iLevel<=LOG_NUM_LEVELS);
return prLog->prFP[iLevel];
}

That should help determine if something is sideways in the log_t structure.

Jeff



Re: Bug#956324: Clustalo bus error on mipsel (Was: Bug#956324: python-biopython: FTBFS on mipsel)

2020-05-01 Thread Andreas Tille
Hi Matthew,

On Thu, Apr 30, 2020 at 05:53:29PM -0700, Matthew Fernandez wrote:
> 
> Is the priority goal here to simply ship a non-crashing clustalo mipsel 
> binary that BioPython can depend on? If so, maybe we can just disable 
> compiler optimisation (-O0) and this may avoid provoking the bus error. Of 
> course this doesn’t fix the underlying problem(s), but it looks as if 
> debugging this to its root cause is going to result in the Debian package 
> carrying a lot of invasive dquilt patches on top of upstream. OTOH I don’t 
> know the performance requirements of BioPython and maybe an unoptimised 
> clustalo is unacceptable to it.

I need to admit the priority goal is to be really sure that the clustalo
code has no hidden issues which might crash on architectures that are
used in practical applications.  I would have no problems to simply
exclude clustalo for mipsel architecture completely - if I could be sure
that it works properly.  So the major reason for this debugging session
is to make sure that clustalo runs properly *on all other* architectures
while loosing mipsel would be no real loss for practival usage of
clustalo and its rdepends.

To follow your hints I cared for -O0 optimisation flags (which is
possible via configure options which uncovers some syntax errors in
comments :-( which I fixed as well) and tried to rebuild on the mipsel
host provided by Debian.  Unfortunately the bus error remains.

Due to the advise here that valgrind works properly only for -O0 I'm
reposting the valgrind output here:


(sid_mipsel-dchroot)tille@eller:~/clustalo$ valgrind -s src/clustalo -i 
debian/tests/biopython_testdata/f002 --guidetree-out temp_test.dnd -o 
temp_test.aln --outfmt clustal --force
==13209== Memcheck, a memory error detector
==13209== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==13209== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==13209== Command: src/clustalo -i debian/tests/biopython_testdata/f002 
--guidetree-out temp_test.dnd -o temp_test.aln --outfmt clustal --force
==13209== 
==13209== Conditional jump or move depends on uninitialised value(s)
==13209==at 0x4007828: cached_fpabi_reject_phdr_p 
(dl-machine-reject-phdr.h:57)
==13209==by 0x4007828: elf_machine_reject_phdr_p 
(dl-machine-reject-phdr.h:217)
==13209==by 0x4008080: open_verify.constprop.0 (dl-load.c:1688)
==13209==by 0x4009D7C: _dl_map_object (dl-load.c:2181)
==13209==by 0x40011F8: map_doit (rtld.c:607)
==13209==by 0x401B2A8: _dl_catch_exception (dl-error-skeleton.c:196)
==13209==by 0x401B334: _dl_catch_error (dl-error-skeleton.c:215)
==13209==by 0x4001138: do_preload (rtld.c:778)
==13209==by 0x4002560: handle_preload_list (rtld.c:879)
==13209==by 0x4005B08: dl_main (rtld.c:1684)
==13209==by 0x401A094: _dl_sysdep_start (dl-sysdep.c:253)
==13209==by 0x400199C: _dl_start_final (rtld.c:447)
==13209==by 0x4001D44: _dl_start (rtld.c:539)
==13209== 
==13209== Invalid read of size 1
==13209==at 0x486F558: ??? (in 
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==13209==by 0x486F5F0: ??? (in 
/usr/lib/mipsel-linux-gnu/libargtable2.so.0.1.8)
==13209==  Address 0x4d655c5 is 0 bytes after a block of size 37 alloc'd
==13209==at 0x484B89C: malloc (in 
/usr/lib/mipsel-linux-gnu/valgrind/vgpreload_memcheck-mips32-linux.so)
==13209==by 0x134D1C: CkMalloc (util.c:83)
==13209== 
==13209== Invalid read of size 4
==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
==13209==by 0x11A6C4: Align (clustal-omega.c:1221)
==13209==by 0x1171C8: MyMain (mymain.c:1192)
==13209==by 0x113CCC: main (main.cpp:469)
==13209==  Address 0x8060 is not stack'd, malloc'd or (recently) free'd
==13209== 
==13209== 
==13209== Process terminating with default action of signal 10 (SIGBUS)
==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
==13209==by 0x11A6C4: Align (clustal-omega.c:1221)
==13209==by 0x1171C8: MyMain (mymain.c:1192)
==13209==by 0x113CCC: main (main.cpp:469)
==13209== 
==13209== HEAP SUMMARY:
==13209== in use at exit: 8,039 bytes in 34 blocks
==13209==   total heap usage: 112 allocs, 78 frees, 77,811 bytes allocated
==13209== 
==13209== LEAK SUMMARY:
==13209==definitely lost: 128 bytes in 2 blocks
==13209==indirectly lost: 0 bytes in 0 blocks
==13209==  possibly lost: 0 bytes in 0 blocks
==13209==still reachable: 7,911 bytes in 32 blocks
==13209== suppressed: 0 bytes in 0 blocks
==13209== Rerun with --leak-check=full to see details of leaked memory
==13209== 
==13209== Use --track-origins=yes to see where uninitialised values come from
==13209== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
==13209== 
==13209== 1 errors in context 1 of 3:
==13209== Invalid read of size 4
==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)