Re: suggesting dnarrange and lamassemble

[Frith, Martin]

Do any of lamassemble's dependencies (e.g. mafft) fail tests?


On Mon, Jul 11, 2022 at 3:36 PM Nilesh Patra  wrote:

> Hi again,
>
> On Sun, May 29, 2022 at 10:10:14PM +0900, Frith, Martin wrote:
> > Wow, amazingly fast!!!
>
> lamassemble fails its tests on i386 (see here[1]) -- could you fix
> accordingly?
>
> [1]:
> https://ci.debian.net/data/autopkgtest/testing/i386/l/lamassemble/22546451/log.gz
>
> --
> Best,
> Nilesh
>

Re: suggesting dnarrange and lamassemble

[Nilesh Patra]

On 7/11/22 12:26 PM, Frith, Martin wrote:

Sorry I lack experience with this, so I have some questions...


No prob.


Were the tests passing before? Was there a specific update after which they 
failed?


They were always failing on version 1.4.2 which is the only version I had every 
uploaded.


And they're still passing except on i386?


Yep. They pass on all archs except i386

https://qa.debian.org/excuses.php?package=lamassemble

--
Best,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Re: suggesting dnarrange and lamassemble

[Frith, Martin]

Sorry I lack experience with this, so I have some questions...
Were the tests passing before? Was there a specific update after which they
failed?
And they're still passing except on i386?

Have a nice day,
Martin


On Mon, Jul 11, 2022 at 3:53 PM Nilesh Patra  wrote:

> On Mon, Jul 11, 2022 at 03:41:41PM +0900, Frith, Martin wrote:
> > Do any of lamassemble's dependencies (e.g. mafft) fail tests?
>
> No.
> Neither mafft, nor last-align, links here[1,2]
>
> [1]: https://ci.debian.net/packages/m/mafft/unstable/i386/
> [2]: https://ci.debian.net/packages/l/last-align/unstable/i386/
>
> --
> Best,
> Nilesh
>

Re: suggesting dnarrange and lamassemble

[Frith, Martin]

Dear Nilesh and Debian Med
(cc MAFFT author Katohさん)

I have partly tracked down this lamassemble issue. First, I tested
lamassemble on x86_64: the tests passed as expected. Then, I recompiled
MAFFT after adding "-m32" to CFLAGS, which compiled it in 32-bit mode. Now,
the tests in
lamassemble/tests/lama-tests.sh
do not give the expected results, as you found.

So it seems that MAFFT sometimes outputs different results in 32-bit mode,
versus 64-bit mode.

I speculate that this is due to floating point calculations, which can
produce different results in 32-bit versus 64-bit mode. I think this is
because CPUs use "extended precision" in one mode but not the other. This
is arguably not a "bug". I guess this must be a frequently occurring issue,
how does Debian usually resolve it?

Have a nice day,
Martin

On Mon, Jul 11, 2022 at 3:36 PM Nilesh Patra  wrote:

> lamassemble fails its tests on i386 (see here[1]) -- could you fix
> accordingly?
>
> [1]:
> https://ci.debian.net/data/autopkgtest/testing/i386/l/lamassemble/22546451/log.gz
>

Re: suggesting dnarrange and lamassemble

[Nilesh Patra]

Hi Martin and Katoh,

On Mon, Jul 11, 2022 at 06:40:51PM +0900, Frith, Martin wrote:
> Dear Nilesh and Debian Med
> (cc MAFFT author Katohさん)
> 
> I have partly tracked down this lamassemble issue. First, I tested
> lamassemble on x86_64: the tests passed as expected. Then, I recompiled
> MAFFT after adding "-m32" to CFLAGS, which compiled it in 32-bit mode. Now,
> the tests in
> lamassemble/tests/lama-tests.sh
> do not give the expected results, as you found.

Thanks a lot for digging in!!

> So it seems that MAFFT sometimes outputs different results in 32-bit mode,
> versus 64-bit mode.
> 
> I speculate that this is due to floating point calculations, which can
> produce different results in 32-bit versus 64-bit mode. I think this is
> because CPUs use "extended precision" in one mode but not the other. This
> is arguably not a "bug". I guess this must be a frequently occurring issue,
> how does Debian usually resolve it?

For floating point issues on i386, usually using a `-ffloat-store` flag during
compilation does the trick. I compiled mafft on i386 chroot using the same and 
tried
testing but unfortunately that does not help (it fails with same errors)

If nothing comes up, I'll disable testing on i386.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: suggesting dnarrange and lamassemble

[Frith, Martin]

Hi Nilesh,

after some searching and experimentation, I think `-ffloat-store` doesn't
always solve this floating point issue.
But this seems to solve it: `-msse2 -mfpmath=sse`.

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

I hope that helps,
Martin


On Mon, Jul 11, 2022 at 7:56 PM Nilesh Patra  wrote:

> Hi Martin and Katoh,
>
> On Mon, Jul 11, 2022 at 06:40:51PM +0900, Frith, Martin wrote:
> > Dear Nilesh and Debian Med
> > (cc MAFFT author Katohさん)
> >
> > I have partly tracked down this lamassemble issue. First, I tested
> > lamassemble on x86_64: the tests passed as expected. Then, I recompiled
> > MAFFT after adding "-m32" to CFLAGS, which compiled it in 32-bit mode.
> Now,
> > the tests in
> > lamassemble/tests/lama-tests.sh
> > do not give the expected results, as you found.
>
> Thanks a lot for digging in!!
>
> > So it seems that MAFFT sometimes outputs different results in 32-bit
> mode,
> > versus 64-bit mode.
> >
> > I speculate that this is due to floating point calculations, which can
> > produce different results in 32-bit versus 64-bit mode. I think this is
> > because CPUs use "extended precision" in one mode but not the other. This
> > is arguably not a "bug". I guess this must be a frequently occurring
> issue,
> > how does Debian usually resolve it?
>
> For floating point issues on i386, usually using a `-ffloat-store` flag
> during
> compilation does the trick. I compiled mafft on i386 chroot using the same
> and tried
> testing but unfortunately that does not help (it fails with same errors)
>
> If nothing comes up, I'll disable testing on i386.
>
> --
> Best,
> Nilesh
>

Re: suggesting dnarrange and lamassemble

[Nilesh Patra]

On 7/11/22 6:14 PM, Frith, Martin wrote:

Hi Nilesh,

after some searching and experimentation, I think `-ffloat-store` doesn't 
always solve this floating point issue.
But this seems to solve it: `-msse2 -mfpmath=sse`.


Unfortunately I can't use these as it would violate i386 baseline that debian 
supports. (See here[1] for more details)
That'd be really old hw and probably the baseline should be raised a bit but as 
of now this would
lead to a critical bug.

I am halting i386 testing for lamassemble for now.
 

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html 

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html 



[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995194#20

--
Best,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Re: suggesting dnarrange and lamassemble

[Frith, Martin]

This also seems to work: `-mpc64`


On Mon, Jul 11, 2022 at 10:16 PM Nilesh Patra 
wrote:

> On 7/11/22 6:14 PM, Frith, Martin wrote:
> > Hi Nilesh,
> >
> > after some searching and experimentation, I think `-ffloat-store`
> doesn't always solve this floating point issue.
> > But this seems to solve it: `-msse2 -mfpmath=sse`.
>
> Unfortunately I can't use these as it would violate i386 baseline that
> debian supports. (See here[1] for more details)
> That'd be really old hw and probably the baseline should be raised a bit
> but as of now this would
> lead to a critical bug.
>
> I am halting i386 testing for lamassemble for now.
>
> > https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html <
> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html>
> > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html <
> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>
>
> [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995194#20
>
> --
> Best,
> Nilesh
>
>

Added autopkgtests for megadepth

[Mohd Bilal]

Hello team,

I have added autopkgtests for megadepth[1]. Requesting someone to review 
and sponsor my changes.


[1] - https://salsa.debian.org/med-team/megadepth

--
╭╮
│ Mohammed Bilal │
│ 2D65 BC1E B966 5A6E 97F9  730A B3F5 9452 8521 9E1F │
╰╯

Re: Added autopkgtests for megadepth

[Nilesh Patra]

On Mon, Jul 11, 2022 at 10:54:45PM +0530, Mohd Bilal wrote:
> Hello team,
> 
> I have added autopkgtests for megadepth[1]. Requesting someone to review and
> sponsor my changes.

Good!
Thanks, uploaded. However please take in a look at my second-last commit, helps
package get cross-building. In this case it was easy :)

> [1] - https://salsa.debian.org/med-team/megadepth

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)

[Shah, Amul]

Hi Andreas,
We discussed this in the group and a number of people were not comfortable with 
removing the current versioning scheme. Let me revise my explanation of our 
versioning:

GT.M’s versioning follows this scheme:
  DBVersion.Major-Minor[Patch]
- DBVersion corresponds to the database block version
- Major corresponds to a major feature change in the product
- Minor represents a minor/incremental feature change in the product
- Patch is an alphabet denoting an emergency single change release

What do other DB projects do in this case? Could we make the DB version a 
textual string and ignore it with respect to the version number?

Currently V6.3-014 has a FTBFS #1011722 logged against it. It would be good to 
get V7.0-003 in the testing stream to close the bug.

Thanks,
Amul

From: Shah, Amul 
Date: Friday, 06 17, 2022 at 04:04 PM
To: Andreas Tille , Debian Med Project List 

Subject: Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: 
fis-gtm: Multiple CVEs in fis-gtm)
Hi Andreas,
Thanks for changing the subject and dropping the bug tracker. I realized
my faux pas after the bug tracker replied to my email.

> > Could you remind me about what we are doing to cause this problem? Is it 
> > the installation path?
> > Or did you mean the below situation where there are two possible GT.M 
> > versions?
> > > aptitude search fis-gtm
> > p   fis-gtm 
> >   - metapackage for the latest version 
> > of FIS-GT.M database
> > i   fis-gtm-6.3-002 
> >   - package for FIS-GT.M database
> > p   fis-gtm-6.3-014 
> >   - package for FIS-GT.M database
>
> We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> package name for any mikro fis-gtm release to enable co-installation of
> all those packages.  I'm personally not convinced, that any single minor
> version bump needs to be installed on a typical Debian installation.
> This I would rather go with binary package names like fis-gtm-6.3  or
> fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> be "-003" next etc. the package is featuring.

[amul] I think we’re on the same page, to use MAJOR.MINOR in the package name.
Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this 
here at
FIS. I don’t see any reason why we cannot adopt the naming scheme that you
propose, fis-gtm-Major.Minor, which also matches what other projects use.

> However, I do not know anything about fis-gtm and its compatibility between
> micro versions - so may be I'm just on the wrong track while looking from
> a Debian packaging perspective.  My perspective is that I'm just scared
> by uploading to the new queue for every single micro version bump which
> always is causing unpredictable delays until the package gets accepted in

[amul] GT.M’s versioning follows this scheme:
Major.Minor-Increment[Patch]
- Major corresponds to the database block version
- Minor corresponds to a major feature change in the product
- Increment (micro) represents a minor feature change in the product
- Patch is an alphabet denoting an emergency single change release

[amul] GT.M database formats (major version) change infrequently. Inside a
database version, GT.M is tested in various upgrade<->downgrade scenarios.
Meaning that there should be no reason to not upgrade.

Thanks,
Amul


From: Andreas Tille 
Date: Friday, 06 17, 2022 at 04:44 AM
To: Shah, Amul , Debian Med Project List 

Subject: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: 
Multiple CVEs in fis-gtm)
Hi Amul,

Am Thu, Jun 16, 2022 at 05:58:54PM + schrieb Shah, Amul:
> > Please reconsider the "add any minor version bump leads to a new binary
> > file name" strategy.  This means that fis-gtm always needs to pass the
> > Debian new queue which always means that there is a hardly predictable
> > delay when the package will reach the distribution.
>
> Could you remind me about what we are doing to cause this problem? Is it the 
> installation path?
>
> Or did you mean the below situation where there are two possible GT.M 
> versions?
> > aptitude search fis-gtm
> p   fis-gtm   
> - metapackage for the latest version of 
> FIS-GT.M database
> i   fis-gtm-6.3-002   
> - package for FIS-GT.M database
> p   fis-gtm-6.3-014   
> - package for FIS-GT.M database

We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
package name for any mikro fis-gtm release to enable co-installation of

Re: Bug#1014647: ITP: abpoa -- adaptive banded Partial Order Alignment

[Étienne Mollier]

Hi Bastian,

Bastian Germann, on 2022-07-11:
> parsnp 1.7.4 does no longer need this because it comes with 
> https://github.com/marbl/parsnp/pull/117

Thank you for your interest and your notice, I'm pulling the
latest upstream version of parsnp, working just right without
python3-pyabpoa.

Hi ftpmaster, if you read this, the abpoa package in "new"
should not be too prioritary, unless someone stands up and
states the package is of interest to them.  ;)

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Soften The Glare - Yearning Heart/Mountain Of Hope


signature.asc
Description: PGP signature

Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: fis-gtm: Multiple CVEs in fis-gtm)

[Andreas Tille]

Hi Amul,

Am Mon, Jul 11, 2022 at 07:51:55PM + schrieb Shah, Amul:
> Hi Andreas,
> We discussed this in the group and a number of people were not comfortable 
> with removing the current versioning scheme. Let me revise my explanation of 
> our versioning:
> 
> GT.M’s versioning follows this scheme:
>   DBVersion.Major-Minor[Patch]
> - DBVersion corresponds to the database block version
> - Major corresponds to a major feature change in the product
> - Minor represents a minor/incremental feature change in the product
> - Patch is an alphabet denoting an emergency single change release
> 
> What do other DB projects do in this case?

The package name will be changed if the database format becomes incompatible.
This corresponds to my suggestions to name the package

   DBVersion.Major

(and leave out "-Minor[Patch]"

> Could we make the DB version a textual string and ignore it with respect to 
> the version number?

The point is that the package name should not change that frequently.
If you want to change the textual string than there is no advantage over
the current naming scheme.

> Currently V6.3-014 has a FTBFS #1011722 logged against it. It would be good 
> to get V7.0-003 in the testing stream to close the bug.

Can you tell me exactly what is the problem with simply choosing V7.0
for all V7.0 package releases and switch to V7.1 once this version is
released?  If the information about Minor + Patchlevel is relevant
for the user (but not for binary compatibility of the database) it
could be mentioned inside the package description which can be changed
more easily than the package name.  To make it clear what I mean I
propose the following patch against the current Git repository:


diff --git a/debian/control b/debian/control
index 15f2d39..fb077fb 100644
--- a/debian/control
+++ b/debian/control
@@ -61,7 +61,7 @@ Description: metapackage for the latest version of FIS-GT.M 
database
  .
  This metapackage always depends from the default fis-gtm version.
 
-Package: fis-gtm-7.0-002
+Package: fis-gtm-7.0
 Architecture: amd64 i386
 Multi-Arch: same
 Depends: ${shlibs:Depends},
@@ -71,7 +71,7 @@ Recommends: zlib1g
 Pre-Depends: ${misc:Pre-Depends}
 Provides: gtm,
   mumps
-Description: package for FIS-GT.M database
+Description: FIS-GT.M database version 7.0-002
  GT.M is a database engine with scalability proven in large real-time
  transaction processing systems that have thousands of concurrent
  users, individual database file sizes to the Terabyte range (with


(I understood that we should rather release -003 but this is not
commited yet.)

I think you realised that every single package change requires passing
the Debian new queue and the time this takes is simply not determined.
Due to that fact and the unfortunate naming scheme we end up with
extremely long cycles (currently with a long standing RC bug due to
several CVEs) which is not in the interest of our users.  I keep on
failing t understand why the minor version should be a part of the
package name which I have never seen in any other Debian package.

Kind regards

  Andreas.

> Thanks,
> Amul
> 
> From: Shah, Amul 
> Date: Friday, 06 17, 2022 at 04:04 PM
> To: Andreas Tille , Debian Med Project List 
> 
> Subject: Re: Naming scheme of fis-gtm binary packages (Was: Bug#1009900: 
> fis-gtm: Multiple CVEs in fis-gtm)
> Hi Andreas,
> Thanks for changing the subject and dropping the bug tracker. I realized
> my faux pas after the bug tracker replied to my email.
> 
> > > Could you remind me about what we are doing to cause this problem? Is it 
> > > the installation path?
> > > Or did you mean the below situation where there are two possible GT.M 
> > > versions?
> > > > aptitude search fis-gtm
> > > p   fis-gtm   
> > > - metapackage for the latest 
> > > version of FIS-GT.M database
> > > i   fis-gtm-6.3-002   
> > > - package for FIS-GT.M database
> > > p   fis-gtm-6.3-014   
> > > - package for FIS-GT.M database
> >
> > We (rather you, Bashkar and Luis Ibanez) decided to create a new binary
> > package name for any mikro fis-gtm release to enable co-installation of
> > all those packages.  I'm personally not convinced, that any single minor
> > version bump needs to be installed on a typical Debian installation.
> > This I would rather go with binary package names like fis-gtm-6.3  or
> > fis-gtm-7.0 no matter whether what mikro version "-002" currently - may
> > be "-003" next etc. the package is featuring.
> 
> [amul] I think we’re on the same page, to use MAJOR.MINOR in the package name.
> Neither Bhaskar nor Luis Ibanez are working on fis-gtm. Let me discuss this 
> here at
> FIS. I don’t see any reason why we cannot adopt the naming scheme th