On Mon, Sep 28, 2020 at 05:19:33AM +0200, Guillem Jover wrote: > Hi! > > On Sun, 2020-09-27 at 22:53:13 +0200, Bill Allombert wrote: > > On Sun, Sep 27, 2020 at 08:58:00PM +0200, Lucas Nussbaum wrote: > > > During a rebuild of all packages in sid, your package failed to build > > > on amd64. > > > > > > > dpkg-source: error: pathname > > > > '/<<PKGBUILDDIR>>/debian/gaproot/pkg/AtlasRep' points outside source > > > > root (to '/<<PKGBUILDDIR>>') > > > $ apt-get source gap-atlasrep > > Fetched 1351 kB in 2s (722 kB/s) > > dpkg-source: info: extracting gap-atlasrep in gap-atlasrep-2.1.0 > > dpkg-source: info: unpacking gap-atlasrep_2.1.0.orig.tar.bz2 > > dpkg-source: info: unpacking gap-atlasrep_2.1.0-2.debian.tar.xz > > dpkg-source: info: using patch list from debian/patches/series > > dpkg-source: info: applying doc-makefile > > dpkg-source: info: applying default-dir > > dpkg-source: error: pathname > > 'gap-atlasrep-2.1.0/debian/gaproot/pkg/AtlasRep' points outside source > > root (to '/tmp/gap-atlasrep-2.1.0') > > E: Unpack command 'dpkg-source --no-check -x gap-atlasrep_2.1.0-2.dsc' > > failed. > > > > There is no rationale to reject such a symlink which does not point > > _outside_ the source root, but _to_ the source root. > > This leads to a spurious FTBFS. > > Right, this is due to a regex not matching when the basedir is the > same as the canonicalized symlink target. I've fixed this, but need to > adapt the new test case. > > > Also I am concerned that developers might need to unpack old packages > > with symlinks in them. There should be a way to do it, if only to fix > > the packaging. > > I guess it might make sense indeed to disable this when running under > --no-check.
Another issue is that dpkg-source -b still allows to build such packages in the first place. So I am not completly sure about why you need to check symlinks. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
