1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

  • Bug#1076863: dpkg-deb: Weird errors from dpkg-deb while building some p

    From Santiago Vila@1:229/2 to All on Wed Jul 24 13:40:02 2024
    XPost: linux.debian.bugs.dist
    From: sanvila@debian.org

    reassign 1076863 dpkg-dev
    found 1076863 1.22.8
    thanks

    Hi. More about this:

    In package "dutch", file debian/hunspell-nl/DEBIAN/control during build is like this:

    Package: hunspell-nl
    Source: dutch (1:2.20.19-2)
    Version: 2:
    Architecture: all
    [...]

    This is generated in this debian/rules line:

    dh_gencontrol -p hunspell-nl -- -v2:$(DEB_VERSION_UPSTREAM_REVISION)

    but the same debian/rules has this at the beginning:

    include /usr/share/dpkg/pkg-info.mk

    and that's where DEB_VERSION_UPSTREAM_REVISION is supposed to be defined.

    So it seems as if the expression which defines DEB_VERSION_UPSTREAM_REVISION
    in pkg-info.mk is broken in the last release.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Santiago Vila@1:229/2 to All on Wed Jul 24 12:30:01 2024
    XPost: linux.debian.bugs.dist
    From: sanvila@debian.org

    Package: dpkg
    Version: 1.22.8

    Hello Guillem et al.

    While building some packages I get weird errors like this:

    dpkg-deb: building package 'aspell-nl' in '../aspell-nl_2.20.19-2_all.deb'. dpkg-deb: building package 'idutch' in '../idutch_2.20.19-2_all.deb'.
    dpkg-deb: error: parsing file 'debian/hunspell-nl/DEBIAN/control' near line 3 package 'hunspell-nl':
    'Version' field value '2:': nothing after colon in version number dh_builddeb: error: dpkg-deb --build debian/hunspell-nl .. returned exit code 2

    (the above is for package "dutch")

    This seems more a dpkg bug (maybe related with epoch handling) than a bug in dutch,
    but I'm not sure. Can you check?

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Santiago Vila@1:229/2 to All on Wed Jul 24 14:10:03 2024
    XPost: linux.debian.bugs.dist
    From: sanvila@debian.org

    severity 107686 serious
    affects 107686 src:dsda-doom src:dutch src:fonts-urw-base35 src:pd-mrpeach thanks

    I assume this is a regression, raising to serious because it makes other packages to FTBFS.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Santiago Vila on Wed Jul 24 14:40:03 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Control: forcemerge -1 1076939

    Hi!

    On Wed, 2024-07-24 at 12:17:21 +0200, Santiago Vila wrote:
    Package: dpkg
    Version: 1.22.8

    While building some packages I get weird errors like this:

    dpkg-deb: building package 'aspell-nl' in '../aspell-nl_2.20.19-2_all.deb'. dpkg-deb: building package 'idutch' in '../idutch_2.20.19-2_all.deb'. dpkg-deb: error: parsing file 'debian/hunspell-nl/DEBIAN/control' near line 3 package 'hunspell-nl':
    'Version' field value '2:': nothing after colon in version number dh_builddeb: error: dpkg-deb --build debian/hunspell-nl .. returned exit code 2

    (the above is for package "dutch")

    This seems more a dpkg bug (maybe related with epoch handling) than a bug in dutch,
    but I'm not sure. Can you check?


    On Wed, 2024-07-24 at 14:10:48 +0200, Jonas Smedegaard wrote:
    Package: dpkg-dev
    Version: 1.22.8
    Severity: important

    It looks like recent changes to dpkg-dev affects a bunch of packages
    that I maintain.

    Concretely, the package radicale now fails to build, as it passes an
    empty version number to help2man. This was reported as bug#1076915.
    Seemingly related bug#1076568 made me try downgrade dpkg-dev, and
    indeed with dpkg-dev 1.22.6 the variable DEB_VERSION_UPSTREAM_REVISION
    again resolves correctly.

    It looks like recent dpkg-dev offers variable expansion only inside
    make rules, not for make code declares "at the core", outside of make
    rules.

    Many of the packages I maintain rely on the ability to resolve variables
    also at the core of the makefile. I am not furiously against changing my packaging patterns, but I imagine I am not the only one, so I guess such change needs more care and documentation (or perhaps just pointing me to
    the elaborate documentation that I have totally missed).

    Both look like the same problem, which would be a regression from the
    recent rework of the Makefile fragments. I'm CCing Nicolas as a
    heads-up, and I'm looking into this to try to do a quick fix upload.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Guillem Jover on Wed Jul 24 16:40:01 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Wed, 2024-07-24 at 14:37:53 +0200, Guillem Jover wrote:
    Both look like the same problem, which would be a regression from the
    recent rework of the Makefile fragments. I'm CCing Nicolas as a
    heads-up, and I'm looking into this to try to do a quick fix upload.

    So there's something wrong with the variables evaluation, and the
    following change makes these packages build again, but I don't
    understand yet what's wrong with the first ifdef conditional arm.
    And neither why the test suite didn't catch this, as it is
    supposedly testing w/ and w/o SOURCE_DATE_EPOCH being set.
    (I'll go for lunch now, so if someone else can have a look that'd
    also be appreciated. :)

    ,---
    diff --git i/scripts/mk/pkg-info.mk w/scripts/mk/pkg-info.mk
    index ddda4f736..a2eb0d5fe 100644
    --- i/scripts/mk/pkg-info.mk
    +++ w/scripts/mk/pkg-info.mk
    @@ -28,18 +28,8 @@ dpkg_parsechangelog_run = $(eval $(shell dpkg-parsechangelog | sed -n '\
    $$(eval DEB_VERSION_UPSTREAM:=\2\4)/p;\
    s/^Timestamp: \(.*\)/$$(eval SOURCE_DATE_EPOCH?=\1)/p'))

    -ifdef SOURCE_DATE_EPOCH
    - dpkg_lazy_eval ?= $(eval $(1) = $(2)$$($(1)))
    - $(call dpkg_lazy_eval,DEB_DISTRIBUTION,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_SOURCE,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_VERSION,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_VERSION_EPOCH_UPSTREAM,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_VERSION_UPSTREAM,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_UPSTREAM_REVISION,$$(dpkg_parsechangelog_run)) -else
    - # We need to compute the values right now.
    - $(dpkg_parsechangelog_run)
    -endif
    +# We need to compute the values right now.
    +$(dpkg_parsechangelog_run)
    export SOURCE_DATE_EPOCH

    endif # dpkg_pkg_info_mk_included
    `---

    Thanks
  • From Guillem Jover@1:229/2 to Guillem Jover on Wed Jul 24 17:20:01 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi

    On Wed, 2024-07-24 at 16:35:44 +0200, Guillem Jover wrote:
    On Wed, 2024-07-24 at 14:37:53 +0200, Guillem Jover wrote:
    Both look like the same problem, which would be a regression from the recent rework of the Makefile fragments. I'm CCing Nicolas as a
    heads-up, and I'm looking into this to try to do a quick fix upload.

    So there's something wrong with the variables evaluation, and the
    following change makes these packages build again, but I don't
    understand yet what's wrong with the first ifdef conditional arm.
    And neither why the test suite didn't catch this, as it is
    supposedly testing w/ and w/o SOURCE_DATE_EPOCH being set.
    (I'll go for lunch now, so if someone else can have a look that'd
    also be appreciated. :)

    I think the attached patch might be better.

    Thanks,
    Guillem

    diff --git i/scripts/mk/pkg-info.mk w/scripts/mk/pkg-info.mk
    index ddda4f736..c999d2d3c 100644
    --- i/scripts/mk/pkg-info.mk
    +++ w/scripts/mk/pkg-info.mk
    @@ -8,6 +8,9 @@
    # DEB_VERSION_UPSTREAM: package's upstream version.
    # DEB_DISTRIBUTION: distribution(s) listed in the current debian/changelog
    # entry.
    +# DEB_TIMESTAMP: source package relase date as seconds since the epoch as
    +# specified in the latest debian/changelog entry (since dpkg 1.22.9),
    +# although you are probably looking for SOURCE_DATE_EPOCH instead.
    #
    # SOURCE_DATE_EPOCH: source release date as seconds since the epoch, as
    # specified by <https://reproducible-builds.org/specs/source-date-epoch/> @@ -26,20 +29,12 @@ dpkg_parsechangelog_run = $(eval $(shell dpkg-parsechangelog | sed -n '\
    $$(eval DEB_VERSION_EPOCH_UPSTREAM:=\1\2\4)\
    $$(eval DEB_VERSION_UPSTREAM_REVISION:=\2\3)\
    $$(eval DEB_VERSION_UPSTREAM:=\2\4)/p;\
    - s/^Timestamp: \(.*\)/$$(eval SOURCE_DATE_EPOCH?=\1)/p'))
    + s/^Timestamp: \(.*\)/$$(eval DEB_TIMESTAMP:=\1)/p'))

    -ifdef SOURCE_DATE_EPOCH
    - dpkg_lazy_eval ?=
  • From Michael Tokarev@1:229/2 to guillem@debian.org on Thu Jul 25 09:10:01 2024
    XPost: linux.debian.bugs.dist
    From: mjt@tls.msk.ru

    On Wed, 24 Jul 2024 16:35:43 +0200 Guillem Jover <guillem@debian.org> wrote:

    So there's something wrong with the variables evaluation,

    - $(call dpkg_lazy_eval,DEB_VERSION_UPSTREAM,$$(dpkg_parsechangelog_run))
    - $(call dpkg_lazy_eval,DEB_UPSTREAM_REVISION,$$(dpkg_parsechangelog_run))

    Here was the wrong: variable is named
    DEB_VERSION_UPSTREAM_REVISION,
    not
    DEB_UPSTREAM_REVISION.

    I found this yesterday the hard way.

    When referencing any other version-related variable first, this
    issue goes away.

    But it doesn't really matter anymore, once this part is removed.

    FWIW.

    /mjt

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)