Package request: liba2i

[alejandro-colomar]

Package name

liba2i

Package homepage

https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/

Description

This library provides wrapper functions around strtol(3) et al.

These APIs are simpler to use correctly than strtol(3), strtoul(3), strtoi(3), strtou(3), and other similar APIs.

They were developed internally in the shadow project:
https://github.com/shadow-maint/shadow/tree/master/lib/atoi

They've been moved to a separate repository to allow other projects to reuse these APIs to fix similar bugs to those fixed in shadow thanks to these APIs. That will also reduce the maintenance work on shadow.

Does the requested package meet the package requirements?

System, Compiled, Required

It will be required by future versions of shadow.
shadow-maint/shadow#1049

Is the requested package released?

Yes

I've released 0.10 today. I think it's ready for use by the general public, but will wait to release 1.0 after some feedback from at least some packagers, since you may find inconveniences that I wasn't able to see. I should have named it 1.0-rc1...

[alejandro-colomar]

Cc: @dataCobra , @dkwo , @sgn

See also:

• shadow: update to 4.16.0. #48813 (comment)
• https://lore.kernel.org/liba2i/sovz7apsg5dqg6npx2lg4qbrq5mnhfygalczhwt7twtxdqnpqp@a6cglzcng6ji/T/#u
• https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/tag/?h=liba2i-0.10
• http://www.alejandro-colomar.es/share/dist/liba2i/0/0.10/

[dkwo]

can shadow be built using this? or a later version?

[alejandro-colomar]

can shadow be built using this? or a later version?

Not yet. Since the liba2i library isn't packaged in any distros, I haven't added code to shadow to build with it. I don't want to do that change until a decent number of distros have packaged liba2i successfully.

Here's the draft PR for building shadow with liba2i:
shadow-maint/shadow#1049.

Future versions will do, but not yet.

[alejandro-colomar]

I've prepared a draft of an Arch PKGBUILD, for helping Arch package it. Maybe that helps you

pkgname=liba2i
pkgver=0.10
pkgrel=1
pkgdesc="string-to-numeric library"
arch=(x86_64)
url="https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/"
license=(LGPL-3.0-or-later WITH LGPL-3.0-linking-exception)
depends=(
  glibc
)
makedepends=(
  binutils
  gcc
  git
  groff
  pkgconf
  texlive-fontsextra
)
validpgpkeys=(
  A9348594CE31283A826FBDD8D57633D441E25BB5  # Alejandro Colomar <alx@kernel.org>
)

prepare() {
  cd $pkgname

  make CFLAGS="$CFLAGS" nothing
}

build() {
  local makebuildopts=()

  makebuildopts+=(EXTRAVERSION="-$pkgrel")
  makebuildopts+=(CFLAGS="$CFLAGS")

  cd $pkgname

  make "$makebuildopts" build-catman
  make "$makebuildopts" build-dev
  make "$makebuildopts" build-lib-shared
  make "$makebuildopts" build-man
  make "$makebuildopts" build-pdf

  make "$makebuildopts" check-catman
  make "$makebuildopts" check-lib
}

package() {
  local makepkgopts=()

  makepkgopts+=(EXTRAVERSION="-$pkgrel")
  makepkgopts+=(DESTDIR="$pkgdir")
  makepkgopts+=(prefix="/usr")

  cd $pkgname

  make "$makepkgopts" install-dev
  make "$makepkgopts" install-lib-shared
  make "$makepkgopts" install-man
  make "$makepkgopts" install-pdf
}

(Edited to use arrays)

---

• You may want to not build and install the PDF manual (it's just a PDF generated from the manual pages).

• In case you want a static library, you can also build and install it with *-lib-static.

[sgn]

Here is a working template (I guess).

# Template file for 'liba2i'
pkgname=liba2i
version=0.10
revision=1
build_style=gnu-makefile
make_build_args="prefix=/usr"
make_build_target="build-dev build-lib-shared build-man"
make_check_target="check-lib"
hostmakedepends="pkgconf"
short_desc="Library provides wrapper functions around strtol(3) et al"
maintainer="Đoàn Trần Công Danh <congdanhqx@gmail.com>"
license="LGPL-3.0-or-later WITH LGPL-3.0-linking-exception, Linux-man-pages-copyleft"
homepage="https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git"
distfiles="https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/snapshot/liba2i-${version}.tar.gz"
checksum=26b87910a1618f80c371eaf9f8943b7c6d12c4fbb1a54656b7e2e28fd599cc00
make_use_env=yes
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
# No idea why liba2i want to link with different -O
CFLAGS="-Wno-error=cpp"

post_patch() {
	sed -i '
		/^CC :=/d
		/-O3 /d
		/^CFLAGS/s/:=/+=/
	' share/mk/configure/build-depends/gcc/cc.mk
	sed -i '/^LDFLAGS /s/:=/+=/' share/mk/configure/build-depends/binutils/ld.mk
	sed -i '/[.]SILENT/d' GNUmakefile
	sed -i "/^VERSION.*=/s/=.*/= ${version}/" share/mk/configure/version.mk
	sed -i "s/HIDE_ERR.*/HIDE_ERR :=/" share/mk/configure/verbose.mk
}

liba2i-devel_package() {
	depends="${sourcepkg}>=${version}_${revision}"
	short_desc+=" - development files"
	pkg_install() {
		vmove usr/share/man/man3 
		vmove usr/include
		vmove usr/lib/pkgconfig
		vmove "usr/lib/*.a"
		vmove "usr/lib/*.so"
	}
}

• I'm not sure why liba2i tries to link with different level, and -Werror=cpp messed with our -D_FORTIFY_SOURCE=2
• I think distro don't want -O3, also, I override CC and CFLAGS with sed
• I override LDFLAGS with sed too, for distro flags.
• I removed SILENT, because I want to see the command used to build. It would be nice if you could provide a detail build if V=1 is passed (like autotools), I think this project is better built with autotools or ninja
• liba2i seems to require Git for getting version information, and it's expected to be built from a Git repository, otherwise, we will run to liba2i.so. too many level of symlinks because it will link into itself.
• SONAME liba2i.so.0 but there are no link from liba2i.so.0 to liba2i.so.0.10 on installation
• PKG_CONFIG := pkgconf unless I am mistaken, this will force pkgconf, instead of environment of PKG_CONFIG, no?
• I'm not sure if I did anything wrong, however, if prefix=/usr not passed to make during build step, liba2i.pc has prefix=/usr/local
• build-catman requires groff but not our version of groff.

  an.tmac:.tmp/man/man3/a2i.3:5: style: .TH missing fourth argument; suggest package/project name and version (e.g., "groff 1.23.0")

[alejandro-colomar]

Here is a working template (I guess).

Thanks!

* I'm not sure why `liba2i` tries to link with different level,

I'm not sure what of you mean by "tries to link with different level".

I link by default with -O3, because it's the fastest, but if you want to override that, you can pass EXTRA_CFLAGS=-O2 to the make command to append to the default cflags, or CFLAGS=-O2 to override all cflags.

(If that interface isn't good, we can discuss it. Sorry if I don't know standard practices well; this is the first library of mine that is being packaged.)

warning _FORTIFY_SOURCE requires compiling with optimization (-O)
No idea why liba2i want to link with different -O

AFAIK, _FORTIFY_SOURCE works with higher optimization levels.

See for example in gcc(1):

     -foptimize-strlen
         Optimize various standard C string functions (e.g. "strlen",
         "strchr" or "strcpy") and their "_FORTIFY_SOURCE" counterparts
         into faster alternatives.

         Enabled at levels -O2, -O3.

and -Werror=cpp messed with our -D_FORTIFY_SOURCE=2

Yup, upstream we have -Werror for commodity, but I expect downstream to sed(1) it out, or pass EXTRA_CFLAGS="-Wno-error"; whichever you prefer.

* I think distro don't want `-O3`,

Ok.

also, I override CC and CFLAGS with sed

Ok. Should the Makefile read those from the environment? Or do you pass them explicitly?

* I override `LDFLAGS` with `sed` too, for distro flags.

Same question.

* I removed `SILENT`, because I want to see the command used to build.

You can pass --debug=print (with a recent-ish make(1); I think it was make 4.4). (But feel free to remove .SILENT if you always want to see it.)

It would be nice if you could provide a detail build if V=1 is passed (like autotools),

With a recent GNU make(1), that's --debug=print. See make(1):

     --debug[=FLAGS]
          Print debugging information in addition to normal processing.
          If the FLAGS are omitted, then the behavior is the same as if
          -d was specified.  FLAGS may be any or all of  the  following
          names,  comma‐  or space‐separated.  Only the first character
          is significant: the rest may be omitted: all for  all  debug‐
          ging  output  (same  as using -d), ...
          ...,  print shows all recipes that are run even if they
          are silent, and why shows the reason make decided to  rebuild
          each  target.   Use  none  to  disable all previous debugging
          flags.

I think this project is better built with autotools or ninja

Ugh, I'm unable to use those tools productively. Sorry. :)

But I'll try to make it easy for you with the GNUmakefile.

* `liba2i` seems to require Git for getting version information, and it's expected  to be built from a Git repository, otherwise, we will run to `liba2i.so. too many level of symlinks` because it will link into itself.

Hmmmm, did you get the source code from the released tarball? Or from the git repository?

The released tarball has the version hardcoded, so you shouldn't need git.

Maybe you downloaded the tarball that git produces? Please don't use that one.

If you run from the git repository, the version is taken from git, but during make dist, the version is stamped into the build system:

$(_DISTVERSION): $(MAKEFILEDIR)/configure/version.mk $(MK) $(FORCE_DISTVERSION) | $$(@D)/
	$(info	$(INFO_)SED		$@)
	<$< \
	$(SED) 's/^VERSION *:=.*/VERSION := $(VERSION)/' \
	| $(SED) 's/^DISTDATE *:=.*/DISTDATE := $(DISTDATE)/' \
	| $(INSTALL_DATA) -T /dev/stdin $@

* `SONAME               liba2i.so.0` but there are no link from `liba2i.so.0` to `liba2i.so.0.10` on installation

As far as I know, that's the job of ldconfig(8); isn't it?

alx@debian:~/src/alx/liba2i/main$ sudo rm /usr/local/lib/liba2i.*
alx@debian:~/src/alx/liba2i/main$ sudo make install-lib-shared
INSTALL		/usr/local//lib/liba2i.so.0.10-1-g3420708a2
LN		/usr/local//lib/liba2i.so
alx@debian:~/src/alx/liba2i/main$ ls /usr/local/lib/liba2i.*
/usr/local/lib/liba2i.so  /usr/local/lib/liba2i.so.0.10-1-g3420708a2
alx@debian:~/src/alx/liba2i/main$ sudo ldconfig 
alx@debian:~/src/alx/liba2i/main$ ls /usr/local/lib/liba2i.*
/usr/local/lib/liba2i.so    /usr/local/lib/liba2i.so.0.10-1-g3420708a2
/usr/local/lib/liba2i.so.0

If I should create it, I'm okay with that; I just didn't know it. Should I?

* `PKG_CONFIG := pkgconf` unless I am mistaken, this will force `pkgconf`, instead of environment of `PKG_CONFIG`, no?

You can override it by explicitly passing make PKG_CONFIG="$PKG_CONFIG" (or PKGCONF="$PKG_CONFIG"; whatever you prefer). Should I read the environment? If so, I'll do. I just wanted to not read too much, so I preferred to be cautious.

* I'm not sure if I did anything wrong, however, if `prefix=/usr` not passed to `make` during build step, `liba2i.pc` has `prefix=/usr/local`

That's correct. GNU coding standards say that the default prefix should be /usr/local.

See:
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

* `build-catman` requires `groff` but not our version of `groff`.

Indeed, it needs groff-1.23.0. Do you have plans to package that?

I could also tweak the pages to work with older groff, but you'll also need 1.23.0 for the Linux man-pages soonish, so I'd recommend upgrading it.

(Edit: I've modified the manual page so that it works with old groff-1.22.4. I'll release 0.11 soon with that change. Still, I recommend upgrading groff to 1.23.0. It fixed many many bugs.)

  > an.tmac:.tmp/man/man3/a2i.3:5: style: .TH missing fourth argument; suggest package/project name and version (e.g., "groff 1.23.0")

Hummm. I don't know why you're seeing this problem. I don't in my system. I'll check. Maybe it has to do with the version problem that you mentioned?

[alejandro-colomar]

FWIW, I've added -D_FORTIFY_SOURCE=2 to CPPFLAGS upstream, and I don't get any warnings (using gcc-13).

https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/commit/?id=828dd1d21b304f184f9081652635de0589606979

[alejandro-colomar]

liba2i-1.0-rc1 is out, and this time there's a release tarball at <kernel.org>:

https://kernel.org/pub/software/libs/liba2i/1/1.0/1.0-rc1/

[sgn]

I'm not sure what of you mean by "tries to link with different level".

I link by default with -O3, because it's the fastest, but if you want to override that, you can pass EXTRA_CFLAGS=-O2 to the make command to append to the default cflags, or CFLAGS=-O2 to override all cflags.

	$(info	$(INFO_)LD		$@)
	for opt in g 0 1 2 s z 3 fast; do \
	$(LD) $(LDFLAGS) -O$$opt -o $*.O$$opt.so.$(DISTVERSION) $(TU_c) $(LDLIBS); \
	done

(If that interface isn't good, we can discuss it. Sorry if I don't know standard practices well; this is the first library of mine that is being packaged.)

I think most distro wants their CFLAGS picked from CFLAGS environment variable, and projects' CFLAGS append or prepend that one, we can use other flags if needed from project.

Ok. Should the Makefile read those from the environment? Or do you pass them explicitly?

I think it is better to be picked up from environment variables, and project can append whatever necessary for them into that CFLAGS. If project uses CFLAGS =, it's prefered over environment variables, (but lost to command line arguments, but this one will override all CFLAGS from project).

* `liba2i` seems to require Git for getting version information, and it's expected  to be built from a Git repository, otherwise, we will run to `liba2i.so. too many level of symlinks` because it will link into itself.

Hmmmm, did you get the source code from the released tarball? Or from the git repository?

The released tarball has the version hardcoded, so you shouldn't need git.

Maybe you downloaded the tarball that git produces? Please don't use that one.

I downloaded from https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/
I don't know if I can download from anywhere else.

If you run from the git repository, the version is taken from git, but during make dist, the version is stamped into the build system:

OK, I should take it from https://mirrors.edge.kernel.org/pub/software/libs/liba2i/ instead.

• SONAME liba2i.so.0 but there are no link from liba2i.so.0 to liba2i.so.0.10 on installation
  As far as I know, that's the job of ldconfig(8); isn't it?

I think it's your jobs. All other softwares create its SONAME link.

You can override it by explicitly passing make PKG_CONFIG="$PKG_CONFIG" (or PKGCONF="$PKG_CONFIG"; whatever you prefer). Should I read the environment? If so, I'll do. I just wanted to not read too much, so I preferred to be cautious.

Users also don't want to type too much to build. If they have PKG_CONFIG in environment, they would want it to be used.
Otherwise, why would they bother to poison their environment?

* I'm not sure if I did anything wrong, however, if `prefix=/usr` not passed to `make` during build step, `liba2i.pc` has `prefix=/usr/local`

That's correct. GNU coding standards say that the default prefix should be /usr/local.

See: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

Yes, default prefix is /usr/local. But in installation step, we passed prefix=/usr but the liba2i.pc file still has prefix=/usr/local if we didn't also passed prefix=/usr during build.

* `build-catman` requires `groff` but not our version of `groff`.

Indeed, it needs groff-1.23.0. Do you have plans to package that?

Eventually, someone will package that, I don't have any interest on that things :-p
Our default typesettings system is mandoc, fwiw.

I could also tweak the pages to work with older groff, but you'll also need 1.23.0 for the Linux man-pages soonish, so I'd recommend upgrading it.

Can you list those man-pages that need new groff? So I can check if it works with mandoc? Because mandoc is our default.

an.tmac:.tmp/man/man3/a2i.3:5: style: .TH missing fourth argument; suggest package/project name and version (e.g., "groff 1.23.0")
Hummm. I don't know why you're seeing this problem. I don't in my system. I'll check. Maybe it has to do with the version problem that you mentioned?

I have no idea either.

[sgn]

FWIW, I've added -D_FORTIFY_SOURCE=2 to CPPFLAGS upstream, and I don't get any warnings (using gcc-13).

https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/commit/?id=828dd1d21b304f184f9081652635de0589606979

We do it a bit unconventional here, we passed -D_FORTIFY_SOURCE=2 to CFLAGS

[sgn]

(Edit: I've modified the manual page so that it works with old groff-1.22.4. I'll release 0.11 soon with that change. Still, I recommend upgrading groff to 1.23.0. It fixed many many bugs.)

  > an.tmac:.tmp/man/man3/a2i.3:5: style: .TH missing fourth argument; suggest package/project name and version (e.g., "groff 1.23.0")

This problem goes away with 1.0-rc1, thanks.

[sgn]

Anyway, since your project wants GNU make explicitly, I think it's better to use GNUMAKEFLAGS instead of MAKEFLAGS to avoid:

make[1]: warning: undefined variable 'GNUMAKEFLAGS'

[dkwo]

btw, void linux already has groff 1.23.0 in its repo.

[alejandro-colomar]

Anyway, since your project wants GNU make explicitly, I think it's better to use GNUMAKEFLAGS instead of MAKEFLAGS

This makes sense on its own. I've applied a patch for that.

to avoid:

make[1]: warning: undefined variable 'GNUMAKEFLAGS'

Even after that change, this warning still appears. AFAIK, it's a bug in GNU make(1), and there's nothing we can do.

Cc: @madscientist