rofiles-fuse: also pass mode for O_RDONLY

In the `O_RDONLY` case, we were calling `openat` without a mode
argument. However, it's perfectly legal (albeit unusual) to do
`open(O_RDONLY|O_CREAT)`. One such application that makes use of this is
`flock(1)`.

This was actually caught by `_FORTIFY_SOURCE=2`, and once we run
`rofiles-fuse` with `-f`, the message is clear:

```
*** invalid openat64 call: O_CREAT or O_TMPFILE without mode ***:
rofiles-fuse terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x7c8dc)[0x7f36d9f188dc]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f36d9fbfaa7]
/lib64/libc.so.6(+0x10019a)[0x7f36d9f9c19a]
rofiles-fuse[0x401768]
...
```

Without `_FORTIFY_SOURCE`, the file gets created, but its mode is
completely random.

I ran into this while investigating
https://github.com/projectatomic/rpm-ostree/pull/1003.

Closes: #1200
Approved by: cgwalters
Origin: upstream, 2017.12, commit:d4c7093e370843c57eab2f89f0c39ef449e6b32e

Gbp-Pq: Topic 2017.12
Gbp-Pq: Name rofiles-fuse-also-pass-mode-for-O_RDONLY.patch

tests: Reset umask to 022 while creating test repository

In test-basic-root.sh we make assertions about the permissions
of files like baz/cow, which were created without an explicit chmod.
We can't do that unless we control the permissions.

For some reason the "debomatic" autobuilder used to do some Debian
archive rebuilds does the entire build including build-time tests
as uid 0 with umask 002, which broke those assertions. This seems
a weird thing to do, and I've opened a bug, but it also seems
reasonable to fix this test.

This also lets us remove a couple of existing workarounds for the
same issue.

Bug-Debian: https://bugs.debian.org/876138
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1192
Approved by: cgwalters
Forwarded: https://github.com/ostreedev/ostree/pull/1192
Applied-upstream: 2017.12, commit:e3c3ec5dd91492e82c79223052443d038c60f41c

Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Reset-umask-to-022-while-creating-test-repository.patch

tests: Explicitly unset LANGUAGE after setting LC_ALL

As a GNU extension, LANGUAGE takes precedence over LC_ALL for
gettext(3) whenever the locale is not C, causing tests that grep for
specific English strings to fail when run in non-English locales.
The upstream glibc proposal for C.UTF-8 would give C.UTF-8 the same
special case as C here, but the implementation in Debian does not
currently have this, so we have to unset LANGUAGE too.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Forwarded: https://github.com/ostreedev/ostree/pull/1188
Applied-upstream: 2017.12, commit:223c940b46a4bb335665df7436566b73cdf0effd

Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Explicitly-unset-LANGUAGE-after-setting-LC_ALL.patch

tests: Fix JavaScript tests with gjs 1.50.0

In recent gjs, you can't declare a variable with "let" multiple times.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1178
Approved by: cgwalters
Forwarded: https://github.com/ostreedev/ostree/pull/1178
Applied-upstream: 2017.12, commit:1b430a776486d68be2d16a0ec53ad5512c604988

Gbp-Pq: Topic 2017.12
Gbp-Pq: Name tests-Fix-JavaScript-tests-with-gjs-1.50.0.patch

ostree (2017.11-2) unstable; urgency=medium

  * Replace patch with the version applied upstream in 2017.12
  * Standards-Version: 4.1.0 (no changes)
  * Add a patch to fix FTBFS in non-English locales
  * Add a patch to fix FTBFS if building as root with umask != 022,
    which for some reason debomatic does (Closes: #876138)
  * Add a patch from upstream to fix undefined behaviour with
    O_RDONLY|O_CREAT in rofiles-fuse

[dgit import unpatched ostree 2017.11-2]

Import ostree_2017.11-2.debian.tar.xz

[dgit import tarball ostree 2017.11-2 ostree_2017.11-2.debian.tar.xz]

Import ostree_2017.11.orig.tar.xz

[dgit import orig ostree_2017.11.orig.tar.xz]