[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)

Hi Adam,

Thanks for taking a look.

On Mon, Jun 8, 2020 at 5:29 PM Adam Borowski <kilobyte@angband.pl> wrote:
> On Mon, Jun 08, 2020 at 07:37:26AM +0200, Stephen Sinclair wrote:
> >  * Package name    : siconos
> >    Version         : 4.3.0+dfsg-1
> But
> > Testing this package requires fclib 3.1.0+dfsg-1, which also needs
> > sponsorship.  It can be found here:
> >
> >   https://mentors.debian.net/package/fclib
> so thats actually two RFSes in one.  And there are problems with fclib.

I'm not sure what the right protocol is in this case, to be honest.
Should I have issued two RFSes or done this one differently?

> > Changes since the last upload:
> >
> >    * New upstream version. (Closes: #962219) (Closes: #961735)
> >    * Add dependencies libboost-timer-dev, libboost-chrono-dev.
> >    * Depend on openblas and lapacke instead of atlas.
> >    * Require fclib 3.1.0
> >    * Update location of install paths.
> >    * Enable WITH_GENERATION, now required for serialization.
> >    * Install new siconos_export_raw_data tool.
> >    * Fix cmake import targets to allow independent packages.
> >    * Update patches for new upstream version.
> >    * Add a flag for gfortran to avoid a regression in GCC-10.
> >      (Closes: #957794)
> >    * Remove unused build rule for swig3.0 symlink.
> >    * Remove non-existent files from debian/copyright.
> >    * Rewrite patch descriptions using gbp pq.
> >    * Fix a Python warning about using 'is' with a literal.
> It looked ok on my box, and passed both all automated and manual review I've
> done.  But, it fails on some of official buildds: at least on amd64 arm64
> x32.
> I seem unable to reproduce the FTBFS locally -- in 15 tries on amd64, 1 on
> arm64, all passed.
> Thus, you'd need to investigate and fix that one in fclib first.

I'm very confused about the error on buildd because I have indeed
built the package many times with a fresh debootstrap without such a
segfault.  I will investigate and try to reproduce.

I did my best to avoid problems but it seems I have missed something,
I'd like to understand the difference between buildd and my own
configuration to avoid this happening in the future.

By the way Siconos due to its nature has been quite hard to get
working on any architecture other than amd64 unfortunately.  Is there
a way to mark the package as amd64-only?
In the meantime I try to find solutions for other architectures but it
is slow going.

> It'd be good if you filed a separate RFS for that.  Let's leave this one
> for siconos 4.3.0+dfsg-1

Okay that sounds like a reasonable approach given this problem.


Reply to: