Debian packaging fails when cloned as a submodule

[alxroyer]

Describe the bug When frr.git is used as a submodule, the debian packaging procedure fails.

(put "x" in "[ ]" if you already tried following) [x] Did you check if this is a duplicate issue? [x] Did you test it on the latest FRRouting/frr master branch?

To Reproduce Steps to reproduce the behavior:

1. Within an existing git workspace, add frr.git as a submodule:

   git submodule add https://github.com/FRRouting/frr.git
   cd frr
   git checkout frr-7.1

2. Follow the procedure described by doc/developer/packaging-debian.rst, steps 4 & 6 (assuming all tools have already been installed):

   ./tools/tarsource.sh -V
   dpkg-buildpackage -uc -us

Backtrace Below the output of the dpkg-buildpackage command:

$ dpkg-buildpackage -uc -us
dpkg-buildpackage: info: source package frr
dpkg-buildpackage: info: source version 7.1-0
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by FRRouting-Dev <dev@lists.frrouting.org>
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
 fakeroot debian/rules clean
dh clean --with=systemd,autoreconf --parallel
   dh_testdir -O--parallel
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/escrim/debian-packaging/FRRouting/frr'
if test -f Makefile; then make redistclean; fi
rm -f debian/frr.init
rm -f debian/frr.service
make[1]: Leaving directory '/home/escrim/debian-packaging/FRRouting/frr'
   dh_autoreconf_clean -O--parallel
   dh_clean -O--parallel
    rm -f debian/debhelper-build-stamp
    rm -rf debian/.debhelper/
    rm -f debian/frr-doc.debhelper.log debian/frr-pythontools.debhelper.log debian/frr-rpki-rtrlib.debhelper.log debian/frr-snmp.debhelper.log debian/frr.debhelper.log
    rm -f -- debian/frr.substvars debian/frr-snmp.substvars debian/frr-rpki-rtrlib.substvars debian/frr-doc.substvars debian/frr-pythontools.substvars debian/files
    rm -fr -- debian/frr/ debian/tmp/ debian/frr-snmp/ debian/frr-rpki-rtrlib/ debian/frr-doc/ debian/frr-pythontools/
    find .  \( \( \
        \( -path .\*/.git -o -path .\*/.svn -o -path .\*/.bzr -o -path .\*/.hg -o -path .\*/CVS -o -path .\*/.pc -o -path .\*/_darcs \) -prune -o -type f -a \
            \( -name '#*#' -o -name '.*~' -o -name '*~' -o -name DEADJOE \
         -o -name '*.orig' -o -name '*.rej' -o -name '*.bak' \
         -o -name '.*.orig' -o -name .*.rej -o -name '.SUMS' \
         -o -name TAGS -o \( -path '*/.deps/*' -a -name '*.P' \) \
        \) -exec rm -f {} + \) -o \
        \( -type d -a -name autom4te.cache -prune -exec rm -rf {} + \) \)
 dpkg-source -b .
dpkg-source: error: can't build with source format '3.0 (git)': doesn't contain a git repository
dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 255

Versions

• OS Kernel: Debian 10
• FRR Version: frr-7.1

First analysis When frr.git is cloned directly, frr/.git is a directory which contains all git information. When frr.git is cloned as a submodule, frr.git/.git is a text file which content gitdir: ../.git/modules/frr tells where the actual gitdir is stored. I cannot say whether the failure comes from frr.git scripts, or the dpkg-source command, or the use of dpkg-source by the frr.git scripts.

[eqvinox]

I think this is an issue in dpkg-source. Also note that to build from git you need to run ./configure first because it auto-generates the changelog. (Edit: ./tools/tarsource.sh -V does that for you, sorry, I missed that.)

[eqvinox]

Closing since this is very likely a Debian tooling bug, not a FRR bug.