Package Details: firejail-git 0.9.72.r721.g37e40e020-1

Git Clone URL: (read-only, click to copy)
Package Base: firejail-git
Description: Linux namespaces sandbox program (GIT version)
Upstream URL:
Licenses: GPL2
Conflicts: firejail
Provides: firejail
Submitter: Lynthium
Maintainer: algebro
Last Packager: algebro
Votes: 21
Popularity: 0.150881
First Submitted: 2015-09-01 14:50 (UTC)
Last Updated: 2023-11-10 16:46 (UTC)

Dependencies (3)

Required by (33)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

algebro commented on 2023-11-10 16:48 (UTC)

Thanks for the help all--I've updated the package to use the recommended pkgver command. Seems to work OK on my end but let me know if you have any issues.

xiota commented on 2023-10-26 01:25 (UTC)

@algebro Please update pkgver() to use:

git describe --long --tags --exclude='*[a-z][a-z]*' | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

This counts revisions since the release, rather than total commits. In addition to being in accordance with VCS package guidelines, it makes determining the difference between release and git versions easier.

Since a new release has been tagged since the last update and the current pkgver() is producing broken version strings, like landlock.split.r9719.30c30f57f, there is no need to add or increment epoch.

glitsj16 commented on 2023-10-26 01:09 (UTC)

@xiota Confirmed. Apologies for the confusion.

xiota commented on 2023-10-26 00:37 (UTC) (edited on 2023-10-26 00:38 (UTC) by xiota)

This is a problem with the PKGBUILD. It just recently started happening. Clean chroot. No cache.

==> Starting pkgver()...
==> Updated version: firejail-git landlock.split.r9719.30c30f57f-1
==> Sources are ready.

As far as I can tell, it is the master branch.

glitsj16 commented on 2023-10-25 21:48 (UTC)

@xiota You must have cloned while upstream cut the landlock branch. See Make sure you're cloning the master branch or things will break.

xiota commented on 2023-10-25 08:25 (UTC)

pkgver() is producing versions like landlock.split.r9719.30c30f57f:

$ printf "%s.r%s.%s" "$(git describe --tags --abbrev=0)" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" | sed 's/^v//;s/-/./g'

$ git describe --long --tags --exclude='*[a-z][a-z]*' | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

xiota commented on 2023-06-09 20:41 (UTC)

@glitsj16 Some projects have broken tagging practices that require more complicated commands to find the right version string. Was wondering if that might have been an issue with this package in the past. If not, the simpler command potentially avoids future issues. I've encountered packages with broken pkgver() (that presumably worked in the past).

glitsj16 commented on 2023-06-09 19:35 (UTC)

@xiota Yes, by "firejail version" I was referring to the 0.9.72 part. I'll try to find some time during the upcoming weekend to dig through my notes and revisit this topic. Thanks for bringing it up!

xiota commented on 2023-06-09 19:01 (UTC) (edited on 2023-06-09 19:04 (UTC) by xiota)

@glitsj16 No problems on my side. Just looks complicated for similar output when upstream tagging isn't broken.

(A) Existing pkgver() output: 0.9.72.r9418.a7dff2521

(B) Output from the git describe command: 0.9.72.r414.ga7dff2521

In both, the release version (0.9.72) and git commit (a7dff2521) are referenced. (B) prepends g to the commit, which is the convention established by the VCS package guidelines.

The main difference is mainly that (A) gives total number of commits, while (B) gives number of commits after 0.9.72 was released. Switching pkgver() commands would temporarily break version monotonicity, which would be restored at the next release.

By "firejail version" are you referring to the 0.9.72 part? Or does firejail internally use version strings exactly like (A)?

glitsj16 commented on 2023-06-09 17:44 (UTC)

@xiota Fair question. I do try to follow Arch packaging standards. In this case I decided to diverge and use a pkgver that includes the firejail version to make it easier for upstream to decipher user issues on its tracker. Although there's a 'guided' template for opening issues, it's still quite common that users neglect it. Which causes unnecessary slow-downs in communication and irritations for the Firejail team, still mostly people who volunteers. Is this causing any problems on your side?