Hi,

the current curl packaging uses pre-built artifacts from the upstream
tarball without regenerating them. Attempting to regenerate them by
running "make -f Makefile.aut" proceeds to call curl to download stuff
from ftp://ftp.unicode.org. To fix this, I added a build dependency on
unicode-data and symlinked the relevant files in the source tree to the
files shipped by the unicode-data package. While I was at it, my patch
also regenerates all the other files which were so far just copypasted
from the upstream tarball without verifying whether they can really be
built using Debian main. This is the patch:

diff -Nru less-590/debian/control less-590/debian/control
--- less-590/debian/control	2023-03-12 15:49:03.000000000 +0100
+++ less-590/debian/control	2024-02-08 23:12:54.000000000 +0100
@@ -4,7 +4,8 @@
 Maintainer: Milan Kupcevic <milan@debian.org>
 Build-Depends:
  debhelper (>= 12),
- libncurses-dev
+ libncurses-dev,
+ unicode-data
 Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/debian/less.git
 Vcs-Browser: https://salsa.debian.org/debian/less
diff -Nru less-590/debian/rules less-590/debian/rules
--- less-590/debian/rules	2023-02-12 11:17:35.000000000 +0100
+++ less-590/debian/rules	2024-02-08 23:16:58.000000000 +0100
@@ -12,3 +12,20 @@
 	dh_auto_configure -- \
 	  --with-regex=gnu \
 	  --with-editor=/usr/bin/editor
+
+execute_before_dh_auto_build:
+	mkdir -p unicode
+	ln -s /usr/share/unicode/UnicodeData.txt unicode/UnicodeData.txt
+	ln -s /usr/share/unicode/EastAsianWidth.txt unicode/EastAsianWidth.txt
+	make -f Makefile.aut
+
+execute_before_dh_auto_clean:
+	set -e; for t in "" echo key; do mv "less$$t.nro" "less$$t.bak"; done
+	make -f Makefile.aut clean
+	rm -f *.nro *.man help.c funcs.h defines.h.in configure
+	rm -f unicode/UnicodeData.txt unicode/EastAsianWidth.txt
+	[ ! -d unicode ] || rmdir unicode
+	set -e; for t in "" echo key; do mv "less$$t.bak" "less$$t.nro"; touch "less$$t.nro.VER" "less$$t.nro"; done
+
+execute_before_dh_auto_install:
+	make -f Makefile.aut distfiles


The stunt with preserving the *.nro files is necessary because the upstream
tarball does not ship the *.nro.VER files which are then made into *.nro files
by replacing @@VERSION@@ and @@DATE@@ with their respective values. Technically
this is a case where the original source is missing from the Debian tarball but
this replacement is probably trivial enough to not be a DFSG violation.

The patch could be made much simpler if you were using a tarball from the
upstream git instead of the distribution tarball which is missing sources but
you probably have your reasons for doing it this way.

Thanks!

cheers, josch

Control: retitle -1 building less from source fails the island test

The first sentence in my mail should've been

Apologies for the confusion!

cheers, josch

Hi Josch,

This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for
their official release package. It is nice to rebuild the build support,
but is not required nor always desired.

Milan

Hi,

Quoting Milan Kupcevic (2024-04-20 20:50:27)

what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?

Thanks!

cheers, josch

Hi Josch,

On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote:
[...]


Stunt lines injected in the building scripts would be very undesirable.

Milan

Quoting Milan Kupcevic (2024-04-20 21:46:14)

How about using the upstream git instead of the release tarball as the base for
the packaging?

Thanks!

cheers, josch

I would rather stick with the official release tarballs as they get
signed with the upstream developer's key.

Milan

Quoting Milan Kupcevic (2024-04-21 01:03:12)

I think we just recently had a long discussion in Debian about using the
upstream git as source for the packaging instead of the release tarball in the
light of how the recent xz-utils attack was performed. Maybe you can convince
upstream to sign their git commits and/or tags.

If you think there is nothing actionable about this bug, feel free to close it.

Thanks!

cheers, josch

Hi josch,

It's actually more than just commit/tag signing.  Upstream releases[1]
"RECOMMENDED" release and "BETA" versions, doesn't distinguish[2]
between them in Git tags[3], and tells users to get release versions as
tar archives[4] and only use the Git repository for developing less[5].

[1]: https://www.greenwoodsoftware.com/less/download.html
[2]: https://github.com/gwsw/less/issues/441
[3]: https://github.com/gwsw/less/tags
[4]: https://github.com/gwsw/less/issues/245#issuecomment-1012323104
[5]: https://github.com/gwsw/less/blob/5e425e2/README#L20