Thread: MobilityDB 1.2.0 - New upstream version

Hi All,

MobilityDB has released 1.2.0 and I have pushed a commit to Salsa to
update the Debian package. I've run a build on PGDG and there was a
failure on bullseye arm64 but this was caused by a network timeout when
downloading one of the dependencies.

I'd like to request a review and upload, as cycles permit.

Let me know if anything needs changes.

Thanks,

-- Bradford

Re: Bradford Boyle
> MobilityDB has released 1.2.0 and I have pushed a commit to Salsa to
> update the Debian package. I've run a build on PGDG and there was a
> failure on bullseye arm64 but this was caused by a network timeout when
> downloading one of the dependencies.

Hi Bradford,

I finally uploaded this. As MobilityDB just entered unstable, I also
uploaded it there, it will have to clear new for the PG17 transition.

It looks like the package needs some updates for the recent PST-PDT
timezone juggling, but I ignored that for now since we need to wait
for NEW anyway.

Thanks,
Christoph

Re: Esteban Zimanyi
> Dear all
> Please let us know whether we can do anything to remove this "unstable"
> label on MobilityDB.

Check if you need to do something similar to PG b8ea0f675f35c3f0c2c.

Christoph

Hi,

Re: Christoph Berg
 > Check if you need to do something similar to PG b8ea0f675f35c3f0c2c.

We have just pushed a commit [1] to master that changes the timezone 
from PST8PDT to America/Los_Angeles like in the PG commit.
It did not change any of our tests and I could not test this on 2024b, 
but I hope this is sufficient.
Can you test if this works using our master branch, or should I backport 
this to stable-1.2?
We will wait until this is fixed before producing the final v1.2.0 release.
Also, should I backport this to stable-1.1 and produce a bugfix release 
v1.1.3?

Best,
Maxime

[1] 
https://github.com/MobilityDB/MobilityDB/commit/f760a035941dd70023f6a0ca577c27d326f82f3b

On 15/10/2024 16:17, Christoph Berg wrote:
> Re: Esteban Zimanyi
>> Dear all
>> Please let us know whether we can do anything to remove this "unstable"
>> label on MobilityDB.
> Check if you need to do something similar to PG b8ea0f675f35c3f0c2c.
>
> Christoph
>
>

Re: SCHOEMANS Maxime
> It did not change any of our tests and I could not test this on 2024b, 
> but I hope this is sufficient.
> Can you test if this works using our master branch, or should I backport 
> this to stable-1.2?

Hi Maxime,

it does fix the problems in my local build, so that fix was enough. I
cherry-picked it into the Debian package, so you don't have to do
anything for now.

> We will wait until this is fixed before producing the final v1.2.0 release.
> Also, should I backport this to stable-1.1 and produce a bugfix release 
> v1.1.3?

It will fail in 1.1 soon. I don't know your stable support policy, but
it sounds like it should get at least into the next release.

Christoph

Re: Christoph Berg
 > It will fail in 1.1 soon. I don't know your stable support policy, but
 > it sounds like it should get at least into the next release.

 From what I understand this is only related to the CI tests, right?
So there is no rush to produce a bugfix release for 1.1 since this 
doesn't affect the user, or am I getting this wrong?
I will cherry-pick the commit to add it to each of our stable-1.* 
branches anyways, but I probably won't create a v1.1.3 just for this.
It will be included in the v1.2.0 release, which I am planning to 
produce in the coming days.

Thanks,
Maxime

Hi,

MobilityDB has landed in Debian, but there's some problems with the
testsuite on various architectures:

On amd64, the 096_tnpoint_spatialrels_tbl test is just slow:

733s 111/114 Test #112: 096_tnpoint_spatialrels_tbl .......   Passed  431.44 sec

https://ci.debian.net/packages/m/mobilitydb/testing/amd64/53684017/

On riscv64, it times out:

2933s         Start 110: 095_tnpoint_aggfuncs_tbl
2959s 109/114 Test #110: 095_tnpoint_aggfuncs_tbl ..........   Passed   25.99 sec
2959s         Start 111: 096_tnpoint_spatialrels
2960s 110/114 Test #111: 096_tnpoint_spatialrels ...........   Passed    0.92 sec
2960s         Start 112: 096_tnpoint_spatialrels_tbl
4460s 111/114 Test #112: 096_tnpoint_spatialrels_tbl .......***Timeout 1500.13 sec
4460s -- TEST_DIR: /tmp/test-17/tmptest
4460s -- TEST_DIR_DB: /tmp/test-17/tmptest/db
4460s -- TEST_DIR_LOCK: /tmp/test-17/tmptest/lock
4460s -- TEST_DIR_LOG: /tmp/test-17/tmptest/log
4460s -- TEST_DIR_OUT: /tmp/test-17/tmptest/out
4460s
4460s         Start 113: 097_tnpoint_tempspatialrels
4462s 112/114 Test #113: 097_tnpoint_tempspatialrels .......   Passed    1.42 sec
4462s         Start 114: 097_tnpoint_tempspatialrels_tbl
4466s 113/114 Test #114: 097_tnpoint_tempspatialrels_tbl ...   Passed    3.90 sec
4466s         Start   2: teardown
4466s 114/114 Test   #2: teardown ..........................   Passed    0.33 sec
4466s
4466s 99% tests passed, 1 tests failed out of 114
4466s
4466s Total Test time (real) = 4138.23 sec
4466s
4466s The following tests FAILED:
4466s     112 - 096_tnpoint_spatialrels_tbl (Timeout)
4466s Errors while running CTest

https://ci.debian.net/packages/m/mobilitydb/testing/riscv64/53697395/

On s390x, things don't work at all:

https://ci.debian.net/packages/m/mobilitydb/testing/s390x/53683957/


Assuming big-endian just doesn't work, we can disable s390x and
friends. But 096_tnpoint_spatialrels_tbl is a pain point - would it be
possible to speed that test up such that it passes in, say, under a
minute on amd64? Then it would likely be fast enough to pass on
riscv64 as well.

Christoph

On Tue, Oct 29, 2024 at 12:06 PM Christoph Berg <myon@debian.org> wrote:
> But 096_tnpoint_spatialrels_tbl is a pain point - would it be possible
> to speed that test up such that it passes in, say, under a minute on
> amd64? Then it would likely be fast enough to pass on riscv64 as well.

I am not familiar enough with 096_tnpoint_spatialrels_tbl to know if it
can be sped up beyond just omitting some of the queries in the test
script. I can change the autopkgtest to omit this case if we want to
minimize the performance impact on the build infrastructure.

--Bradford

On Wed, Nov 6, 2024 at 7:33 AM Esteban Zimanyi <estebanzimanyi@gmail.com> wrote:
>
> We have added a commit to the version stable-1.2.
> Could you please tell us whether this commit is enough or whether we should do a bug-fix release?
> Many thanks for identifying this problem.

I've cherry-picked b3fed5b2a from stable-1.2 and pushed an updated
package to salsa.debian.org. It looks like this signiticantly decreased
the run time for the test. On pgdg, the run time for
096_tnpoint_spatialrels_tbl is under 2 seconds for sid amd64 and PG17.

--Bradford

Re: Bradford Boyle
> On Wed, Nov 6, 2024 at 7:33 AM Esteban Zimanyi <estebanzimanyi@gmail.com> wrote:
> >
> > We have added a commit to the version stable-1.2.
> > Could you please tell us whether this commit is enough or whether we should do a bug-fix release?
> > Many thanks for identifying this problem.
> 
> I've cherry-picked b3fed5b2a from stable-1.2 and pushed an updated
> package to salsa.debian.org. It looks like this signiticantly decreased
> the run time for the test. On pgdg, the run time for
> 096_tnpoint_spatialrels_tbl is under 2 seconds for sid amd64 and PG17.

Looking good indeed, thanks!

New releases are generally nice, but the cherry-pick is enough for now.

Christoph