[Debian-med-packaging] You pushed new upstream source but no Debian packaging (Was: [Git][med-team/bali-phy] Pushed new tag upstream/3.1.4+dfsg)

[Andreas Tille]

Hi Benjamin,

On Tue, May 22, 2018 at 12:49:09PM -0400, Benjamin Redelings wrote:
> 
> > I noticed your push of the new upstream source but no change in
> > packaging arrived in Git.  I wonder whether you might have some not yet
> > pushed commits on your side.
> Yes, that was the problem.

:-)
 
> >    Please also note:  While I'm observing the
> > commits I usually do not sponsor a package to the Debian mirror before I
> > get an explicite signal via mail asking for it.  Just commiting to Git
> > does not have the effect that a package is uploaded automatically.
> Actually, I didn't expect that a git push would somehow trigger an upload. 
> I was thinking about whether to develop and push another release 3.1.5
> before e-mailing you.

OK fine.  There was once a beginner who assumed pushing to Git is
sufficient for an upload and I wanted to clarify this.

> Given the build problems with 3.1.2, let's try and
> solve those first, and then I'll test a 3.1.5, push it, and ask for an
> upload.

Fine.
 
> > BTW, there are some issues for 3.1.2 on some architectures.  You can see
> > an overview on the package tracker[1].  This is the relevant part of the
> > build log on i386:
> Thanks, I have now incorporated the link to the build logs into my
> packaging-for-debian notes.
> 
> It looks like the problems fall into two categories
> (1) compilation problems: gcc runs out of virtual memory compiling a
> template-heavy c++ file.

Yes, that seems to be the case for 32bit architectures (at least those
logs I checked were 32 bit).
 
> I have reported this exact problem to gcc bugzilla here: see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80318
> 
> One work-around might be to stop compiling with '-g', and to stop building
> the debug symbols package.  I just checked and this gets compile-time and
> memory down to 40s / 2.3g.  I just checked that "-fno-var-tracking
> -fno-var-tracking-assignments" doesn't only gets the memory down to 4.6g.

This might be worth a try - may be depending from the architecture.  I'd
assume that amd64 is the most frequently used arch and having the debug
package there might be nice while suppressing it for the others does not
really harm.
 
> Disabling the package on 32-bit archs seems a  bit orthogonal to the
> problem, since the build could fail on 64-build archs if the RAM is too
> small.

I just was mentioning this from past experience with other projects
without diving into this actual problem.  Its very frequent these days
that software authors only consider 64 bit as valuable architectures.
We have several cases where we needed to introduce architecture
restrictions - it would be nice if this would be not needed here.
 
> Thoughts?  Is removing -g possible / frowned-upon?

Fine for me.  In your debian/rules file you can use:

BUILDARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)

...

ifeq ($(BUILDARCH),amd64)
        Do something for amd64
else
	Do something for other arches
endif

 
> (2) Test timeouts
> 
> We have one test that times out -- it doesn't actually fail.  It looks like
> the build machine is taking about 10 times longer per test than my laptop. 
> Is that expected?

Some of the autobuilders on weak architectures might take quite long.
In some cases it helps to contact the according proter team (mailing
list named like debian-ARCHITECTURE at lists.debian.org) and asking them
for either manually pick a specific (=more powerful) porterbox for
certain packages or set some parameters according to the problem.

> For example, the test that succeeds at 29s second runs in
> 3.1s on my laptop, and the test that times out at 30 second in the build log
> runs in 4.3 seconds on my laptop.

I do not consider this very astonishing.  Its just weaker hardware than
your laptop.
 
> So, I could adjust the meson.build file to allow (say) 2 minutes for the
> test that takes 3.1 seconds on my laptop, and (say) 3 minutes for the test
> that takes 4.3 seconds on my laptop.

That could be some sensible means.
 
> In summary, how about we wait to upload until a 3.1.5 that will hopefull fix
> some of the build problems on other archs?

I'm perfectly fine with waiting and dealing with these issues.  I simply
wanted to make sure that there are no wrong assumptions on your side.

Thanks for your detailed work on this package

      Andreas.

-- 
http://fam-tille.de