Package Details: i3blocks-contrib-git 2.0.0.r5.g7f601f8-1

Git Clone URL: https://aur.archlinux.org/i3blocks-contrib-git.git (read-only, click to copy)
Package Base: i3blocks-contrib-git
Description: Official repository of community contributed blocklets
Upstream URL: https://github.com/vivien/i3blocks-contrib
Licenses: GPL3
Groups: i3
Conflicts: i3blocks-contrib
Provides: i3blocks-contrib
Submitter: matoro
Maintainer: sshaikh
Last Packager: sshaikh
Votes: 3
Popularity: 0.000000
First Submitted: 2019-09-09 12:28 (UTC)
Last Updated: 2021-08-19 11:21 (UTC)

Dependencies (50)

Required by (0)

Sources (1)

Pinned Comments

sshaikh commented on 2021-08-16 11:28 (UTC) (edited on 2021-08-16 11:52 (UTC) by sshaikh)

@thiagowfx

The i3blocks-contrib repo contains the source code for various contributed to be used by i3blocks. As per upstream[1] they are not meant to be used "raw" by cloning but in fact are meant to be selectively built/copied into an existing script directory.

This allows upstream's default/example config to work correctly, as block names are by default taken from filenames in the script directory (ie it doesn't handle subfolders elegantly). So to answer your question directly, the difference between this package and i3blocks-contrib-git is that the latter simply clones and copies the repo (sub directories and all), while this one "flattens" it into an appropriate script directory.

There's more discussion in upstream's issue #255[2], including the inspiration for the code in this PKGBUILD.

@a821

I have raised this (as well as offering a solution) on i3blocks-contrib-git's AUR page[3], but received no meaningful response. As I was unable to determine if this was by design/preference or that the users of this package were actively expected to configure their systems in a way contrary to upstream, I didn't feel it was appropriate to adopt and correct it in a way that would break it for an existing audience. And so I uploaded an alternative package.

Hope that helps!

[1]https://github.com/vivien/i3blocks-contrib/wiki/Installation [2]https://github.com/vivien/i3blocks-contrib/issues/255 [3]https://aur.archlinux.org/packages/i3blocks-contrib-git/#comment-776755

Latest Comments

« First ‹ Previous 1 2 3 Next › Last »

a821 commented on 2021-08-16 12:55 (UTC) (edited on 2021-08-16 13:05 (UTC) by a821)

@sshaikh If upstream changes will cause breakage in users setup, IMO, they should be responsible for their systems (specially in this case as this is a VCS package and breakage is expected) as arch packages aim to be close to upstream (ie, not heavily patched as other distros). If the current maintainer had disagreed with those changes, then he would've said something, but because he didn't, then I would've guessed that he is not really taking care of the package and an orphan request would've made sense to me...

BTW, the compilation should be done in build(), not package(), and in pkgver(), the git line can be simplified to git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' (no need for VAR)

Edit: corrected git command...

sshaikh commented on 2021-08-16 11:28 (UTC) (edited on 2021-08-16 11:52 (UTC) by sshaikh)

@thiagowfx

The i3blocks-contrib repo contains the source code for various contributed to be used by i3blocks. As per upstream[1] they are not meant to be used "raw" by cloning but in fact are meant to be selectively built/copied into an existing script directory.

This allows upstream's default/example config to work correctly, as block names are by default taken from filenames in the script directory (ie it doesn't handle subfolders elegantly). So to answer your question directly, the difference between this package and i3blocks-contrib-git is that the latter simply clones and copies the repo (sub directories and all), while this one "flattens" it into an appropriate script directory.

There's more discussion in upstream's issue #255[2], including the inspiration for the code in this PKGBUILD.

@a821

I have raised this (as well as offering a solution) on i3blocks-contrib-git's AUR page[3], but received no meaningful response. As I was unable to determine if this was by design/preference or that the users of this package were actively expected to configure their systems in a way contrary to upstream, I didn't feel it was appropriate to adopt and correct it in a way that would break it for an existing audience. And so I uploaded an alternative package.

Hope that helps!

[1]https://github.com/vivien/i3blocks-contrib/wiki/Installation [2]https://github.com/vivien/i3blocks-contrib/issues/255 [3]https://aur.archlinux.org/packages/i3blocks-contrib-git/#comment-776755

a821 commented on 2021-08-16 11:27 (UTC)

Given that the maintainer of i3blocks-contrib-git has not replied/reacted to any of last comments, I would've submitted an orphan request instead of making another package as the guidelines states.

thiagowfx commented on 2021-08-16 02:04 (UTC)

https://wiki.archlinux.org/title/AUR_submission_guidelines:

Check the AUR if the package already exists. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained or the maintainer is unresponsive, the package can be adopted and updated as required. Do not create duplicate packages.

How is this package different from i3blocks-contrib-git?

sshaikh commented on 2021-04-27 17:27 (UTC) (edited on 2021-04-27 17:27 (UTC) by sshaikh)

Further to my last comment, I've been using:

package () {
  cd "${pkgname}"
  install -d "${pkgdir}"/usr/lib/i3blocks

  for tobuild in $(find . -mindepth 2 -type f -name 'Makefile');
  do
    pushd $(dirname $tobuild)
    make
    popd
  done

  find . -type f -executable -not -path './.git/*' -exec install {} "${pkgdir}"/usr/lib/i3blocks/ \;
}

Feel free to use the above, or if it's not desired here I'll upload a PKGBUILD that does.

abouvier commented on 2020-11-24 02:30 (UTC)

The v prefix should be removed from the version string.

sshaikh commented on 2020-11-21 18:56 (UTC)

According to https://github.com/vivien/i3blocks-contrib/issues/255, scripts are intended to lay "flat" in lib and not in subdirectories. Because the directory name doesn't have to be the same as the script name, using $BLOCK_NAME/$BLOCK_NAME in configs isn't guaranteed to work.

hashworks commented on 2019-09-09 20:27 (UTC)

@treeshateorcs: Yeah, that's fixed in the patch.

treeshateorcs commented on 2019-09-09 20:20 (UTC)

amixer is in the alsa-utils package

lm-sensors package is actually called lm_sensors, no wonder it's red

hashworks commented on 2019-09-09 19:25 (UTC)

I screwed up some optional dependencies. My bad!

Patch: https://fb.hash.works/B2FGi5BX/

« First ‹ Previous 1 2 3 Next › Last »