Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Nilesh Patra]

On Thu, Feb 01, 2024 at 01:55:21PM +0100, Sébastien Jodogne wrote:
> Even if I'm tagged as the maintainer of "orthanc-python", I don't know
> how autopkgtest/flaky works (I haven't implemented such tests by
> myself).

This is the script that runs for tests:


https://salsa.debian.org/med-team/orthanc-python/-/blob/master/debian/tests/run-unit-test?ref_type=heads

This is a basic script that should work and did work at least locally -- note 
that I only "sponsored"
an upload for this package and did not delve very deep into the working detaiks.

IDK why the logs are incomplete though.

> I consequently forward your message to the Debian Med mailing
> list, as I cannot help on this bug by myself.

If you prefer, we can drop this test altogether and test locally before each 
upload.


signature.asc
Description: PGP signature

Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with

[Sébastien Jodogne]

Hello,

Even if I'm tagged as the maintainer of "orthanc-python", I don't know
how autopkgtest/flaky works (I haven't implemented such tests by
myself). I consequently forward your message to the Debian Med mailing
list, as I cannot help on this bug by myself.

Regards,
Sébastien-

> I looked at the results of the autopkgtest of your package. I noticed
> that it regularly fails on several architectures because it currently
> blocks glibc. Unfortunately the log seems to be missing the actual
> problem as it ends with:
>   45s W0131 12:12:35.955520 MAIN FromDcmtkBridge.cpp:382]
> Loading external DICOM dictionary: "/usr/share/libdcmtk17/private.dic"
>   45s Test failed with
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

Re: User input needed: Stop supporting 32 bit architectures with emboss (Was: emboss-lib: identified for time_t transition but no ABI in shlibs)

[Andreas Tille]

Hi again,

I've filed bug #1062371

RM: emboss [armel armhf i386 hppa m68k powerpc sh4] -- ROM; No support of 
32 bit architectures any more

Kind regards
Andreas.

Am Wed, Jan 31, 2024 at 07:53:26AM +0100 schrieb Andreas Tille:
> Hi again,
> 
> besides my suggested solution to split up emboss-lib again (and when
> doing so make the package emboss-lib a metapackage depending from single
> packages to match all its rdepends) I wonder whether we should provide
> EMBOSS for 64 bit architectures only.  While we probably need to file a
> lot of removal requests to 32 bit packages of its rdepends it somehow
> fits the reality that these days nobody seriously runs emboss on 32bit
> architectures.  As explained in the according wiki page[1] other binary
> distros are dropping 32-bit at all and Debian rather cares for
> automotive, IOT, TVs, routers, plant control, building
> monitoring/control, cheap Android phones - nothing that is using EMBOSS.
> 
> I would really like to get some input from *our users* here on the
> Debian Med list since I need your response to draw a sensible decision.
> 
> Kind regards
> Andreas.
> 
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
> 
> Am Fri, Jan 26, 2024 at 10:44:09AM +0100 schrieb Andreas Tille:
> > Hi Charles,
> > 
> > I wonder how we can properly solve this bug.  In the early stage of
> > Emboss packaging obviously the packages
> > 
> >libajax6,
> >libajax6-dev,
> >libnucleus6,
> >libnucleus6-dev
> > 
> > existed (thus the remaining Conflicts/Replaces on emboss-lib which can
> > probably be removed right now).  I wonder whether we should restore those
> > single library package per shared library + devel package, merge
> > static+shared library in one package or even merge
> > 
> >libacd 6 emboss-lib (>= 6.6.0+dfsg)
> >libajax 6 emboss-lib (>= 6.6.0+dfsg)
> >libajaxdb 6 emboss-lib (>= 6.6.0+dfsg)
> >libajaxg 6 emboss-lib (>= 6.6.0+dfsg)
> >libensembl 6 emboss-lib (>= 6.6.0+dfsg)
> >libnucleus 6 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss6
> > 
> >libepcre 7 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss-pcre7 (ugly since its a code copy of pcre3 but well,
> > that's another battle field) and
> > 
> >libeplplot 3 emboss-lib (>= 6.6.0+dfsg)
> > 
> > in libemboss-plplot3 to express the proper sonames inside the library
> > package names.  Any more sensible suggestion is pretty welcome.
> > 
> > Kind regards
> > Andreas.
> > 
> > -- 
> > http://fam-tille.de
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de