Re: gdpc: help needed to fix autopkgtest failure

Étienne Mollier <[email protected]> Wed, 28 Jan 2026 23:18:31 +0100
Newsgroups	gmane.linux.debian.devel.medical
Message-ID	<[email protected]>
Hi Yavor,

Yavor Doganov, on 2026-01-28:
> On Sun, 25 Jan 2026 22:17:14 +0200,
> Yavor Doganov wrote:
> > I ported gdpc to GTK 3 (#967379) but the autopkgtest fails on Salsa with:
> > ...
> > *** buffer overflow detected ***: terminated
> > Aborted
> > 
> > I cannot reproduce on amd64 and i386 (real steel) so I would
> > appreciate if someone could try and provide a gdb backtrace.
> 
> As I couldn't reproduce on 4 other machines (amd64, i386, ppc64el and
> s390x) I decided to run the problematic test from gdb in batch mode,
> hoping to obtain a backtrace.  Much to my regret, the test passes when
> run from gdb.  I suggest to leave it as it is for the time being; we
> may get something from the official CI runners.

I agree and even if nothing pops up today, tomorrow that might
come in handy when debugging a new breakage.  I'm not too sure
however whether autopkgtest environment will support dbgsym
packages on CI infrastructure.  Without touching my setup, I see
that I'm missing the appropriate dbgsym packages due to lacking
the configuration to contact the appropriate repository:

	The following packages have unmet dependencies:
	 satisfy:command-line : Depends: gdb but it is not going to be installed
	                        Depends: gdpc-dbgsym but it is not going to be installed or
	                                 libgtk-3-0t64-dbgsym but it is not installable
	                        Depends: libc6-dbg but it is not going to be installed
	                        Depends: libglib2.0-0t64-dbgsym but it is not installable
	                        Depends: procps but it is not going to be installed
	                        Depends: xauth but it is not going to be installed
	                        Depends: xvfb but it is not going to be installed
	                        Depends: gdpc but it is not going to be installed
	                        Depends: gdpc-examples but it is not going to be installed
	E: Unable to satisfy dependencies. Reached two conflicting assignments:
	   1. satisfy:command-line:amd64=1 is selected for install
	   2. satisfy:command-line:amd64 Depends libglib2.0-0t64-dbgsym
	      but none of the choices are installable:
	      [no choices]

Passing the below argument to the autopkgtest command resolves
the issue, in case someone else runs into this deployment error:

	--add-apt-source 'deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main'

> > I believe the architecture restriction which happened in the past
> > due to such failures (#981876) is unjustified and all those failures
> > were due to this bug (or bugs).
> 
> The package works perfectly fine on my scruffy AMD Duron (1300 MHz).
> There's nothing architecture-specific in it.  There is really no good
> reason to exclude architectures so I've set the Architecture field
> back to "any" and removed that field from debian/tests/control.

I have no objection to architectures reintroduction if they
work, but other team members may have a different opinion, given
the will to focus on most common architectures in use in
scientific fields.

Unrelated to Debian Med: there is a motherboard exposed behind
me that happens to have an AMD Duron still in the socket.  :)

> Would appreciate if a DD could review my changes and eventually upload
> the package.  I'm subscribed to the PTS and will watch for failures.

I have begun to scroll through your changes and I am very
impressed by the porting work you poured into it.  I have
dropped the ball on this package a while ago due to the lack of
upstream and my inexperience with graphical interfaces
development.  This package has still a pretty high popcon for a
Debian Med package: if your changes allow carrying gdpc in
further Debian releases, then many users will be able to
continue to use it.  Thank you!

I have yet to go through all your changes, but here is something
I noted that you might wish to adjust:

  * d/watch: instead of using the FakeWatchNoUpstream, it will
    be more economical to move to an Untrackable field that goes
    in the same paragraph as the Version field.  the Untrackable
    field takes as argument the reason why the package is not
    trackable and won't trigger any http request from uscan,
    which will exit immediately on parsing the debian-watch(5)
    file.

Other than that, I haven't seen any issue worth mentioning here.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <[email protected]>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-    on air: Beethoven - Variations sur un thème de Judas …
signature.asc (application/pgp-signature, 833 B)