Package Details: libbacktrace-git r77.g9ae4f4a-1

Git Clone URL: https://aur.archlinux.org/libbacktrace-git.git (read-only, click to copy)
Package Base: libbacktrace-git
Description: Library to produce symbolic backtraces
Upstream URL: https://github.com/ianlancetaylor/libbacktrace
Licenses: BSD
Conflicts: libbacktrace
Provides: libbacktrace, libbacktrace.so
Submitter: Chocobo1
Maintainer: Chocobo1
Last Packager: Chocobo1
Votes: 12
Popularity: 0.31
First Submitted: 2019-04-16 04:00 (UTC)
Last Updated: 2023-11-04 16:34 (UTC)

Latest Comments

1 2 3 Next › Last »

xiota commented on 2023-11-08 22:44 (UTC)

License should go in $pkgdir/usr/share/licenses/$pkgname, not libbacktrace / ${pkgname%-git}. Convention is described at PKGBUILD.

The difference is of minor consequence, since it's the same project and the packages conflict. However, it could interfere with a script that checks licenses against installed packages.

As far as version number, sticking with r#.# is the correct decision. The 1.0 "release" and corresponding commit isn't well documented, so tracking revisions relative to it isn't really meaningful.

dreieck commented on 2023-04-12 12:56 (UTC)

According to upstream, the software has an official version number: 1.0 (it is written in the upstream's README.md: "This is version 1.0.").

So I suggest to prepend the official version number to $pkgver (auto-retrieved via pkgver()). Then the =$pkgver in the provides array also makes sense.

Here is an example of a pkgver() function that does this parsing:

pkgver() {
  cd "libbacktrace"

  _ver="$(grep -E '[Vv]ersion [0-9\.]+' README.md | head -n1 | sed -E -e 's|.*[Vv]ersion ([0-9\.]+)|\1|' -e 's|\.$||')"
  _rev="$(git rev-list --count HEAD)"
  _date="$(git log -1 --date=format:"%Y%m%d" --format="%ad")"
  _hash="$(git rev-parse --short HEAD)"

  if [ -z "${_ver}" ]; then
    error "Could not determine version."
    return 1
  else
    printf '%s' "${_ver}.r${_rev}.${_date}.${_hash}"
  fi
}

And another issue:

License BSD is not a common license according to /usr/share/licenses/common/. Please explicitly install the license file into /usr/share/licenses/${pkgname}/.

Thanks for maintaining!,
regards.

Chocobo1 commented on 2023-02-10 03:30 (UTC)

Cannot build package:

==> Starting prepare()... patching file configure.ac patching file Makefile.am Hunk #1 succeeded at 84 with fuzz 1. patching file configure.ac Hunk #1 succeeded at 568 (offset 30 lines). The next patch would create the file libbacktrace.pc.in, which already exists! Skipping patch. 1 out of 1 hunk ignored ==> ERROR: A failure occurred in prepare(). Aborting...

Command 'makepkg' failed to execute.

Seems makepkg doesn't remove unrelated files from the repository before building. Anyway I have temporarily patched it so it won't fail for now.

yochananmarqos commented on 2023-02-09 21:29 (UTC)

@zed123: The 0002-Add-pkg-config-file.patch is no longer needed as it was taken care of upstream.

My PKGBUILD

zed123 commented on 2023-02-09 20:46 (UTC)

Cannot build package:

==> Starting prepare()... patching file configure.ac patching file Makefile.am Hunk #1 succeeded at 84 with fuzz 1. patching file configure.ac Hunk #1 succeeded at 568 (offset 30 lines). The next patch would create the file libbacktrace.pc.in, which already exists! Skipping patch. 1 out of 1 hunk ignored ==> ERROR: A failure occurred in prepare(). Aborting...

Command 'makepkg' failed to execute.

abouvier commented on 2022-12-08 18:24 (UTC)

While we are at it, why don't they add -ffat-lto-objects to devtools build flags?

I believe it's because it slows down the compilation when LTO is enabled, but is only useful when packages contain static libraries.

Also this option is ignored when LTO is disabled, so there is no harm in adding it when a package always produces at least one static library. Which is implied with staticlibs.

Chocobo1 commented on 2022-12-08 16:17 (UTC) (edited on 2022-12-08 16:24 (UTC) by Chocobo1)

It's enabled in devtools: https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/config/makepkg/x86_64.conf#L97

I reckon devtools is for building "official repository packages". And AUR packages aren't viewed as official (this impression comes from a bug wrangler).

Quoting from README.md:

This repository contains tools for the Arch Linux distribution for building and maintaining official repository packages


Perhaps just disable it then?

I would rather not bother with it unless truly necessary. If people want to build with LTO then they should setup their default build flags properly. Also IMO injecting the build flag package-by-package doesn't scale well and doesn't feel right.

While we are at it, why don't they add -ffat-lto-objects to devtools build flags?

abouvier commented on 2022-12-08 15:35 (UTC)

It's enabled in devtools: https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/config/makepkg/x86_64.conf#L97

On the other hand staticlibs is disabled in both pacman and devtools by default :p

yochananmarqos commented on 2022-12-08 15:35 (UTC)

@Chocobo1: Yes, I'm aware it's not enabled by default with pacman. However, it is with devtools. Perhaps just disable it then?

options=('!lto')

Chocobo1 commented on 2022-12-08 15:22 (UTC) (edited on 2022-12-08 15:24 (UTC) by Chocobo1)

Please add export CFLAGS+=" -ffat-lto-objects" to the build() function to avoid mangling when stripping with LTO enabled.

No. LTO is not enabled by default: https://gitlab.archlinux.org/pacman/pacman/-/blob/v6.0.2/etc/makepkg.conf.in#L93

Use that flag for your own builds instead.