We now build a docker base container based on debian sid (where the very
latest packages are available). That base container is updated once a
month, or whenever travis-build.Dockerfile or debian/control change, but
re-used for subsequent travis runs. While the initial build might take
up to 15 minutes, subsequent builds typically run in a minute or two.
All the different steps that we run on travis are now factored into
separate scripts in the travis/ directory.
Switching to docker should also help with issue #2174.
Rather than just toggling the fullscreen modes, allow to set them
directly with:
fullscreen enable|toggle [global]
fullscreen disable
For compatibility, retain the previous command and its toggling behavior:
fullscreen [global]
fixes#1120
I think instead of maintaining distribution-specific patches forever,
it’s a bit easier to have them applied upstream, especially since they
don’t break anything.
fixes#876
Harald mentioned he was surprised about the locales we recommend in the
.xsession example, so I’ve re-investigated.
Here is the test program I have used:
#include <stdio.h>
#include <locale.h>
int main() {
/* SUSv2 setlocale(3) says:
* Internationalised programs must call setlocale() to initiate
* a specific language operation. This can be done by calling
* setlocale() as follows: */
setlocale(LC_ALL, "");
printf("LC_NUMERIC is %s\n", setlocale(LC_NUMERIC, NULL));
}
Then, I have unset LANG and LC_*:
midna /tmp $ env | grep LANG
midna /tmp $ env | grep LC
midna /tmp $
Now, observe that LC_ALL overwrites all specific LC variables:
midna /tmp $ LC_ALL=de_DE.UTF-8 LC_NUMERIC=en_DK.UTF-8 ./localetest
LC_NUMERIC is de_DE.UTF-8
However, LANG does not:
midna /tmp $ LANG=de_DE.UTF-8 ./localetest
LC_NUMERIC is de_DE.UTF-8
midna /tmp $ LANG=de_DE.UTF-8 LC_NUMERIC=en_DK.UTF-8 ./localetest
LC_NUMERIC is en_DK.UTF-8
This is consistent with what perldoc perllocale says:
http://perldoc.perl.org/perllocale.html#ENVIRONMENT
This is useful for third-party scripts which require certain features
and want to error out cleanly when they are run with an old i3 version.
Additionally, i3 --version might be different from what’s actually
running (an old version of the binary), so i3-msg -t get_version will be
the best way to figure out the i3 version you are actually running from
this commit on.
Michael Stapelberg