Package Details: sxiv-git 2016.08.08-1

Git Clone URL: (read-only)
Package Base: sxiv-git
Description: Simple (or small or suckless) X Image Viewer
Upstream URL:
Licenses: GPL2
Conflicts: sxiv
Provides: sxiv
Submitter: None
Maintainer: jasonwryan
Last Packager: jasonwryan
Votes: 31
Popularity: 0.072021
First Submitted: 2011-01-23 13:55
Last Updated: 2016-08-10 07:16

Dependencies (5)

Required by (2)

Sources (1)

Latest Comments

jasonwryan commented on 2017-02-02 20:01

cutuchiqueno I just create a separate branch that contains my config.h and then I can git pull from here without overwriting that file, checkout that branch and then build against head and my customisations are applied.

cutuchiqueno commented on 2017-02-02 09:40

can you explain quickly how to use a custom config.h while using this PKGBUILD? I had a log at the file but did not understand it enough to get the information out of it and also searched the corresponding forum without finding the necessary information. Thx.

jasonwryan commented on 2016-08-10 07:19

Thanks sekret: updated.

sekret commented on 2016-08-10 05:48

Hey Jason, please make some changes to the PKGBUILD:

Remove the install file. It's not needed anymore, because it does, what now hooks do. Namcap will show you this aswell.

Please change the depends line to

depends=('imlib2' 'libexif' 'libxft' 'hicolor-icon-theme')

This was done by reading namcap's output. Especially libxft is absolutely required, the package doesn't even build without it!

mkoskar commented on 2014-10-24 11:25

@jasonwryan: I see, I've missed that info in man page. Good to know. Ok no problem, I maintain my clone anyway because of 'config.h', just wanted to minimize tweaks I do. Still though, I'm wondering if there is another, more suitable way how to do this. Probably is not very common use case. Thanks ;)

jasonwryan commented on 2014-10-24 09:27

@mkoskar given that $startdir is deprecated and its use "strongly discouraged" (man pkgbuild), I am inclined to leave things as they are for the time being. I agree it is not ideal, but it sucks the least, as far as I can tell.

mkoskar commented on 2014-10-24 07:54

@jasonwryan: Sorry for late response ... I don't think there are any advantages per se, but if you think of it SRCDEST doesn't make sense here really I believe, because the 'config.h' in this case is not a 'source' file (otherwise it would be listed in source array). In fact it's a kind of trick when build "depends" on something outside of regular sources (which normally shouldn't be the case). So we can either pretend it's a source and say packager has to ensure to copy it into SRCDEST (or $srcdir in that case is more correct), or we say it's not source at all and rather it is something living somewhere else. I've suggested BUILDDIR because it was working for me, but realized it can be changed too an it is probably frequent use-case? I've did some testing now, and found out that regardless where SRCDEST and BUILDDIR are pointing $startdir always points to original location from which `makepkg` is run, so I think it is reasonable and justified to use $startdir here. It could be that there is some better solution to this though ;).

jasonwryan commented on 2014-10-18 06:55

@mkoskar What advantage is there to preferring BUILDDIR over SRCDEST (apart from in your case)? The VCS guidelines seem to prefer the former:

mkoskar commented on 2014-10-16 18:32

@jasonwryan: I've found out that $SRCDEST doesn't work for me since I have set it to point to global cache directory. Figured out that $BUILDDIR is want we want. If you fancy you can grab fixed version ($SRCDEST -> $BUILDDIR, + removing some trailing whitespace) from <>. Thanks!

jasonwryan commented on 2014-10-12 06:53

Thanks sekret. I'm going to leave things as they are for the time being; I appreciate the suggestions, but unless there is something particularly broken about this approach, I see no compelling reason to change it.

sekret commented on 2014-10-10 21:24

An even better way to handle the config.h (in my opinion) is e.g.
I put the config.h into the sources, BUT
1. made the checksum being skipped
2. made a custom config.h to be opted in

That way those of you who don't want to customize anything in the config.h, the package will always work and the only disadvantage is that you have to download that file when getting the sources from here. VERY small disadvantage! ;)

For those of you who DO use a custom config.h, all you have to do is remove the # in the prepare function and of course keep your config.h up to date by yourself.

Why not just search for the config.h in $SRCDEST? Well, this can be set to a different location in /etc/makepkg.conf which e.g. I do, I'm sure many others as well. For those of you who don't do that, give it some thought, it really makes sense. This means that in case of a custom SRCDEST you would have to have all your config.h files (from dwm, sxiv, $(other suckless projects) ) in $SRCDEST, which we all know is impossible, since the filename is the same for all of them.

I know this is something to be debated about, but since this above described method was suggested by devs in the comments of some package here in the AUR (sorry for not being able to find it right now..) I think it's worth mentioning.

One other thing, I want to suggest to use

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

in the pkgver function. Using the date is nice to see how active the project is, but the real info lies in the above command.

Ok that was a lot now! All just suggestions!

jasonwryan commented on 2014-10-10 20:19

@mkoskar: yes, you are right. I have updated the PKGBUILD. Cheers.

mkoskar commented on 2014-10-10 12:06

I think it would make more sense to not distribute `config.h` in the package (meaning as a 'source'). `prepare` would just copy one if you happen to have it in your source directory, if not some message could be emitted. As of now the `config.h` is outdated, which is expected since this is 'development' package. But then that may (and does) lead to compile errors.

quite commented on 2014-08-02 14:34

Okay, that was a change upstream. -a is now needed to play on start

quite commented on 2014-08-02 14:33

For some reason, when I compile this package I get an sxiv that doesn't play gif animation, but just shows the first frame. The community/sxiv plays them on my system. Anybody else having this problem?

jasonwryan commented on 2014-07-26 22:05

Thanks lolilolicon: I've included your changes.

lolilolicon commented on 2014-07-26 07:08

Hmm, seems it's useless to install those icons, since the .desktop file says NoDisplay=true

lolilolicon commented on 2014-07-26 04:56

Hi jason, sxiv ships icons now, consider adding this to package(),

make -C icon PREFIX="/usr" DESTDIR="$pkgdir" install

with that, we also need

gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor

in the install scriptlet.

Another thing, optdepends are referring to commands config.def.h while they're now moved to external exec scripts (which are by default not activated). I perosonlly just remove optdepends altogether.

jasonwryan commented on 2014-07-24 18:25

Thanks karol: updated.

karol_007 commented on 2014-07-24 10:41

I think after recent changes we need a new config.h:

Mentat commented on 2014-07-17 22:03

@jason, thanks for your precision (yes it's a very good and pratical reason) and to have make the fix.

jasonwryan commented on 2014-07-17 20:52

@Mentat for the reason why it is packaged, see:

As to why it was not the default, that was a packaging error on my part. I have fixed it now, thanks for the heads up.

Mentat commented on 2014-07-17 13:09

@jason, can I ask you why you maintain a specfic config.h ?
As I was unaware (my fault) about changes, and write an issue about keyhandler 'XK_s' in place of 'XK_x'

jasonwryan commented on 2014-06-16 09:02

Thanks sekret: bert added libexif back in last week*; I had been meaning to update... :p


sekret commented on 2014-06-16 08:40

Hi Jason, look what I got:

$ namcap sxiv-git-2014.06.15.g5d0679b-1-x86_64.pkg.tar.xz
sxiv-git W: Dependency libexif detected but optional (libraries ['usr/lib/'] needed in files ['usr/bin/sxiv'])

orschiro commented on 2014-04-08 22:01


In fact know I completely understood what you meant. I overlooked that config.h is provided in the tarball and is not cloned from the repo.

Thank you!

jasonwryan commented on 2014-04-08 21:48


It builds fine here. I have uploaded a tarball with the updated config.h (which is just copied from config.def.h): you really shouldn't need your hand held for this...

orschiro commented on 2014-04-08 21:42


I usually know how to maintain the git version. But even downloading the archive, extracting it and running makepkg fails with the same error although in that case there is no local config.h present.

jasonwryan commented on 2014-04-08 20:41


Diff your config.h and bert's config.def.h and work it out yourself. Or move to a non-git version if you aren't able to track changes to the application.

sekret commented on 2014-04-08 20:40

No, my advise is to merge the changes in config.def.h to your config.h.

What I do is

git clone sxiv-git git
vimdiff config.h git/config.def.h

and after updates

cd git
git pull
cd ..
# if config.def.h is among the updated files, do
vimdiff config.h git/config.def.h

and apply the changes, but keep mine. You always have to do this in whatever way, because if you don't, sxiv probably doesn't build anymore.

This needs to be done as well with e.g. dwm-git, st-git, ... In short: With packages, which provide configuration through config.h. Except of course if you don't do any customisations and don't have a config.h, then you'll be fine.

orschiro commented on 2014-04-08 20:34


So your advice is to stick to the old config.h?

What needs to be updated to make it working with the new one?

sekret commented on 2014-04-08 19:35

Yes and no. Yes if I use my old config.h, no if I update it according to the new config.def.h

orschiro commented on 2014-04-08 19:32

Anyone else having problem to build it?

aura >>= Building `sxiv-git`...
aura >>= Well, building `sxiv-git` failed.
aura >>= Dumping makepkg output in 3.. 2.. 1..
==> Making package: sxiv-git 522.653a6ee-1 (Di 8. Apr 21:31:13 CEST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Cloning sxiv git repo...
Cloning into bare repository '/var/cache/pacman/pkg/sxiv-git30288/sxiv-git/sxiv'...
-> Found config.h
==> Validating source files with sha256sums...
sxiv ... Skipped
config.h ... Skipped
==> Extracting sources...
-> Creating working copy of sxiv git repo...
Cloning into 'sxiv'...
==> Starting pkgver()...
==> Updated version: sxiv-git 524.e685859-1
==> Starting prepare()...
==> Starting build()...
image.c: In function ‘img_init’:
image.c:82:12: error: ‘ANTI_ALIAS’ undeclared (first use in this function)
img->aa = ANTI_ALIAS;
image.c:82:12: note: each undeclared identifier is reported only once for each function it appears in
image.c:83:15: error: ‘ALPHA_LAYER’ undeclared (first use in this function)
img->alpha = ALPHA_LAYER;
make: *** [image.o] Error 1
==> ERROR: A failure occurred in build().

gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -std=c99 -Wall -pedantic -O2 -I/usr/include -D_XOPEN_SOURCE=500 -DHAVE_GIFLIB -DVERSION=\"git-20140406\" -c -o commands.o commands.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -std=c99 -Wall -pedantic -O2 -I/usr/include -D_XOPEN_SOURCE=500 -DHAVE_GIFLIB -DVERSION=\"git-20140406\" -c -o exif.o exif.c
gcc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -std=c99 -Wall -pedantic -O2 -I/usr/include -D_XOPEN_SOURCE=500 -DHAVE_GIFLIB -DVERSION=\"git-20140406\" -c -o image.o image.c
Makefile:20: recipe for target 'image.o' failed

Anonymous comment on 2012-12-30 13:25

Ok, I looked into the Makefile and I understand why this is to be prefered.

It doesn't change anything, but since I have the strong feeling that you won't give up until I change it, I changed it ;)

Everything ok now? I'm always open for suggestions.

baskerville commented on 2012-12-30 11:56

Please see:

(This recommendation is coming from Judd Vinet.)

Anonymous comment on 2012-12-30 11:14

I follow upstream's describtion how to change the install directory. Please look it up at the project's github page.

baskerville commented on 2012-12-30 10:42

Instead of:
make PREFIX="$pkgdir/usr" install
I would prefer:
make PREFIX=/usr DESTDIR="$pkgdir" install

Anonymous comment on 2012-12-29 18:17

Concerning GPLv2 vs GPL2, please take a look at the licenses package. That's why it has to be "GPL2".

I took the example PKGBUILD for git packages from the abs package and did a remake of the package. This should solve everything. From my point of view this package is perfect. If there are passages in it you would do differently, I need you to respect that everybody has his own style.

baskerville commented on 2012-12-29 17:50

Thanks, you're right about the license.

Could you take all the other changes too?

There's still a lot of typos ('X' is not 'x', 'GPLv2' is not 'GPL2', etc.), indentation problems, unnecessary messages, double quotes, etc.

Anonymous comment on 2012-12-24 01:13

I like your modifications, so I added most of them. Thanks!

giflib isn't needed as a dependency, since imlib2 already depends on giflib.
The license file isn't required in the package, since the gpl2 license is already provided by the licenses package. We only have to provide licenses which aren't in the licenses file.

baskerville commented on 2012-12-23 20:41

I've made a few improvements to the PKGBUILD:
- Added 'giflib' to the dependencies (cf. ef0ed3226428c00507e76bdda77c522729ed6809).
- Added 'git' to the make dependencies.
- Copied `LICENCE` and `sxiv.desktop` to the appropriate places.
Please grab it here:

baskerville commented on 2012-12-23 20:38

I've made a few improvements to the PKGBUILD:
- Added 'giflib' to the dependencies (cf. ef0ed3226428c00507e76bdda77c522729ed6809).
- Added 'git' to the make dependencies.
- Copied `LICENCE` and `sxiv.desktop` to the appropriate places.
Please grab it here:

Anonymous comment on 2012-03-04 21:29

Updated again, because the optdepends were out of date

Anonymous comment on 2011-09-15 15:30

If the maintainer decides to disable exif by default, I respect that decision. It's the arch way to provide the packages as vanilla as possible and so do I here. The default config.h has exif disabled, so this package here provides this as default. It's the user's choice, that's why I put libexif and giflib in the optdepends so the user can see this when viewing the PKGBUILD or after the installation. After that he can change the settings accordingly. I provide all possibliities in the PKGBUILD to build sxiv the way you want (custom config.h).

I enabled both exif and gif animations, because I want it that way. But as said before, I want the PKGBULID to install sxiv as intended by upstream.

quite commented on 2011-09-15 14:11

I know perfectly well how enable exif, that wasn't the question.

My question concerned the reason for exif not being enabled automatically by the PKGBUILD (by rewriting config.h). Do you for example think that people generally don't want exif? Or why?

Anonymous comment on 2011-09-15 13:42

Exif is being enabled in the config.h. That's why this is optional. If you want exif to be enabled, you'll have to use a custom config.h. Copy the default one to the directory where the PKGBUILD is being saved and edit it to your likings. Then you should also change the PKGBUILD to put libexif into the depends line and remove it from the optdepends line. The same with animated gif support.

quite commented on 2011-09-15 10:43

Any reason for not enabling exif in the PKGBUILD?

baskerville commented on 2011-09-13 09:00

Oops: those settings are now in config.h.

Anonymous comment on 2011-09-10 21:31

Thanks a lot dude! :) According to the libgif is a dependency as well, but I didn't include it, since it's already satisfied. Just in case anybody's wondering.

baskerville commented on 2011-09-10 20:26

To have gif and exif support (see

Anonymous comment on 2011-06-30 17:28

Improved the PKGBUILD, e.g. for the usage of a custom config.h