IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If one wants to set up a mount for `/var` in `/etc/fstab`, it
won't be mounted since `ostree-prepare-root` set up a bind mount for
`/var` to `/sysroot/ostree/$stateroot/var`, and systemd will take
the already extant mount over what's in `/etc/fstab`.
There are a few options to fix this, but what I settled on is parsing
`/etc/fstab` in a generator (exactly like `systemd-fstab-generator` does),
except here we look for an explicit mount for `/var`, and if one *isn't* found,
synthesize the default ostree mount to the stateroot. Another nice property is
that if an admin creates a `var.mount` unit in `/etc` for example, that will
also override our mount.
Note that today ostree doesn't hard depend on systemd, so this behavior only
kicks in if we're built with systemd *and* libmount support (for parsing
`/etc/fstab`). I didn't really test that case though.
Initially I started writing this as a "pure libc" program, but at one point
decided to use `libostree.so` to find the booted deployment. That didn't work
out because `/boot` wasn't necessarily mounted and hence we couldn't find the
bootloader config. A leftover artifact from this is that the generator code
calls into libostree via the "cmd private" infrastructure. But it's an easy way
to share code, and doesn't hurt.
Closes: #859
Approved by: jlebon
There are currently no unstable APIs, but some will be added in
following commits. They will be built and exposed in the libostree
global symbol list iff configured with --enable-experimental-api.
Distributions should not package OSTree with --enable-experimental-api.
This is designed for previewing new APIs on controlled platforms; any of
the APIs hidden behind this option may be changed or removed at any
point.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #832
Approved by: cgwalters
The major reason to do this is that running tests *both* installed
and uninstalled in our CI is a mostly pointless waste of time.
Particularly given we have a few expensive tests.
We *do* have tests that only run uninstalled (since they require
the source code) like `test-symbols.sh`.
Hence, add `--enable-installed-tests=exclusive` to mean *only* do installed for
most tests.
We'll still have uninstalled coverage via the Travis/Debian configs, and we
could perhaps do another build with a subset of uninstalled tests, but I'm not
really concerned about it.
I'd like to do a renewed push for the InstalledTests model since
I feel it's just fundamentally better. (`g-d-t-r` kind of sucks,
but then so does the automake runner).
Also while we're here - fix the CI to use the correct context,
which started this mess.
Closes: #837
Approved by: dbnicholson
This commit won't actually *be* 2017.5 since due to the way our infrastructure
works, we still want to increment git master to 2017.5.
See https://github.com/ostreedev/ostree/pull/800Closes: #800
Approved by: jlebon
(Also rename the other CI contexts to be more consistent)
We pass this right now. I just noticed an instance of this in bwrap, and I think
we should be trying to match the RPM build baseline.
Closes: #765
Approved by: jlebon
This actually worked before because `pkg-config --cflags openssl`
is empty, and the linker was satisfying `-lssl -lcrypto` from our
indirect dependencies.
Also, in fact we *currently* just want `pkg-config libcrypto` i.e.
`-lcrypto`, since we aren't actually using openssl to speak TLS.
This doesn't actually matter on Fedora at least since they're both in the
`openssl-libs` package, but they are separate for a reason.
Closes: #749
Approved by: jlebon
Add an OpenSSL backend to the checksum input stream, which is where we do a lot
of checksumming (object commit, static deltas).
The raw OpenSSL performance is
[approximately double](https://gist.github.com/cgwalters/169349fd1c06fd4fb4d3a7ce33303222) on
my laptop; not only does OpenSSL have e.g. hand-tuned x86_64 assembly, the
current implementation uses the
[Intel SHA extensions](https://en.wikipedia.org/wiki/Intel_SHA_extensions).
Another reason to do this is I was idly thinking about adding
[Curve25519](https://en.wikipedia.org/wiki/Curve25519) signatures (like e.g.
Alpine does) instead of/in addition to GPG. The rationale for that is
that GPG is pretty heavyweight, both in code footprint and the simple
fact that EC keys are way smaller.
I didn't benchmark ostree with this; we have bigger performance problems
really like the fact we just malloc way too much. But, it's a step
in the right direction I think in combination with the libcurl work
where we're linking to openssl anyways.
Closes: #738
Approved by: jlebon
This goes farther along the path of deprecating it; consumers should
have been ported at this point. Though probably a lot of people
may still use `rpm-ostree-toolbox`.
Closes: #723
Approved by: jlebon
OSTree currently provides no way to inspect the versioning
information at run time, being only available at compile
time through pkg-config.
This is a problem for e.g. Flatpak, that needs to check
whether the 'update-frequency' option is available. Checking
at compile time isn't great since it's not looking for new
symbols, but only if an optional feature is present.
This commit, then, adds a new header that is generated
at compile time, exposing OSTree's versioning information.
Closes: #728
Approved by: cgwalters
It's been almost a month, I think the current git is working well and
not too risky. We have some new API additions which I think the
various consumers of them are going to want.
Closes: #726
Approved by: jlebon
I've seen code in a few places that I think on balance is definitely better this
way. Some of our functions have huge variable declaration sections.
This change includes one small example where we could start using declarations
after statements.
A concern I had was - how does this interact with `__attribute__((cleanup))` and
early returns? I tested it, and AFAICS the behavior is what you'd expect - the
cleanup function isn't called if its variable isn't reachable.
Closes: #718
Approved by: jlebon
If --enable-man=maybe (the default), and xsltproc is not available, the
configuration code would check for it, correctly set enable_man=no, then
incorrectly overwrite that with enable_man=yes, which would result in
later trying to execute $(XSLTPROC) when it’s empty.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #720
Approved by: cgwalters
https://github.com/ostreedev/ostree/pull/705 broke the build
on CentOS 7 which only has util-linux 2.23.
When I was thinking about this, I realized that there must really be a way to
make this safe even for older versions. Looking at that version of util-linux,
all we need to do is invert the order of frees so we `mnt_free_table()` *before*
`mnt_free_cache()`, like util-linux does:
https://github.com/karelzak/util-linux/blob/stable/v2.23/sys-utils/eject.c#L1131
We still use the `_unref()` versions if available. I also fixed
the ordering there too for double plus redundant safety.
Closes: #712
Approved by: jlebon
I learned today that `docker version` does this and I really like
the idea. While we have the patient open, also add the gitrev
with code taken from https://github.com/projectatomic/rpm-ostree/pull/584Closes: #691
Approved by: giuseppe
We should get a release out to try to keep with at least a once-a-month cadence.
This one has some exciting stuff like libcurl and Rust, and various bugfixes.
Also importantly I want to cut this *before* we land some other bigger stuff, so
rpm-ostree can start using the reload_config API etc.
Closes: #685
Approved by: jlebon
For rpm-ostree, we already link to libcurl indirectly via librepo, and
only having one HTTP library in process makes sense.
Further, libcurl is (I think) more popular in the embedded space. It
also supports HTTP/2.0 today, which is a *very* nice to have for OSTree.
This seems to be working fairly well for me in my local testing, but it's
obviously brand new nontrivial code, so it's going to need some soak time.
The ugliest part of this is having to vendor in the soup-url code. With
Oxidation we could follow the path of Firefox and use the
[Servo URL parser](https://github.com/servo/rust-url). Having to redo
cookie parsing also sucked, and that would also be a good oxidation target.
But that's for the future.
Closes: #641
Approved by: jlebon
This is an initial drop of "oxidation", or adding implementation
of components in Rust. The bupsplit code is a good target - no
dependencies, just computation.
Translation into Rust had a few twists -
- The C code relies a lot on overflowing unsigned ints, and
also on the C promotion rules for e.g. `uint8_t -> int32_t`
- There were some odd loops that I introduced bugs in while
translating...in particular, the function always returns `len`,
but I mistakenly translated to `len+1`, resulting in an OOB
read on the C side, which was hard to debug.
On the plus side, an off-by-one array indexing in the Rust code paniced nicely.
In practice, we'll need a lot more build infrastructure to make this work, such
as using `cargo vendor` when producing build artifacts for example. Also, Cargo
is yet another thing we need to cache.
Where do we go with this? Well, I think we should merge this, it's not a lot of
code. We can just have it be an alternative CI target. Should we do a lot more
right now? Probably not immediately, but I find the medium/long term prospects
pretty exciting!
Closes: #656
Approved by: jlebon
There are many motivating factors. The biggest is simply that at a practical
level, the command line is not sufficient to build a real system. The docs say
that it's a demo for the library. Let's make that more obvious, so people don't
try to use `ostree admin upgrade` for their real systems, and also don't use
e.g. `ostree commit` on the command line outside of test suites/quick hacking.
This change will also help clarify the role of rpm-ostree, which we will likely
be renamed to "nts". Then use of the term "ostree" will become much clearer. And
similarly for other people writing upgraders, they can say they use libostree.
I didn't try to change all of the docs and code at once, because it's going to
lead to conflicts.
The next big steps are:
- Rename the github repo (github will inject a redirect)
- Look at supporting a build where we don't do `ostree admin`, or at least
it's only built for tests. We may want to split it off as a separate binary
or so? That way people with their own upgraders don't need to ship it.
Closes: #659
Approved by: jlebon
Unfortunately, introspection uses dlopen(), which doesn't quite
work when the DSO is compiled with ASAN but the outer executable
isn't.
Trying to inject LD_PRELOAD=libasan means the outer executable has to
be leak free...which, yeah, I'm not going to get into running ASAN
today on gjs or pygobject.
So, let's skip those tests - ideally, we still run them in some other
context without the sanitizers. The coverage we have from them is
middling anyways.
Closes: #622
Approved by: jlebon
This pulls in a new compilation flag for wrpseudo compatibility. Also
note we need to add some includes since glnx-libcontainer went away,
and with it some includes for `sys/mount.h` etc.
Closes: #522
Approved by: cgwalters
If the `--with-static-compiler=musl-gcc` configure flag is given.
ostree-prepare-root can be used as init in a system without a populated
/lib. To support this use case we need to link statically as we will be
unable to locate libc.so at run time if it's not installed in /lib.
We support building ostree-prepare-root with a different compiler to the
rest of ostree so we can use musl rather than glibc. This reduces the size
of the executable significantly: from ~700K -> ~30K. We have to use
`_SCRIPTS` here to get autotools to install this as an executable but
without generating rules to make it itself which we have specified
manually.
See https://lists.gnu.org/archive/html/help-gnu-utils/2007-01/msg00007.html
for advice on using autotools in this manner.
Closes: #477
Approved by: cgwalters
Lots and lots of preparation led to this moment - when nothing
apparent changes for users! Woo!
But seriously, having the extra dependency is a minor annoyance, and
in the big picture I think the libgsystem idea was wrong - we need to
land things in GLib, and use git submodules for API-unstable or
Linux-specific sharing. For a lot of OSTree, the libgsystem `GFile*`
orientation was also wrong, we really want fd-relative.
Closes: #444
Approved by: jlebon
I want to add `-Werror=int-conversion`, but it's only available in
newer GCC versions. So let's start autodetecting available compiler
flags.
Closes: #431
Approved by: giuseppe
In general this is even cleaner now, though it was better after I
extracted a helper function for the "write tempfile with contents"
bits that were shared between metadata and regular file codepaths.
Closes: #369
Approved by: jlebon
This was the last caller of libgsystem that isn't
`gs_file_get_path_cached()`. I think the use case ostree has where
the same code can be called via command line and via a shared library
*and* via a daemon is rather unusual, so let's just copy the code for
logging from libgsystem into here.
For example rpm-ostree hard depends on a daemon mode, so it'll just
use `sd_journal` directly.
Closes: #341
Approved by: jlebon
The AC_PROG_YACC already does the checking for us, so we don't need to
use AC_CHECK_PROGS (which wasn't working anyway because autoconf didn't
run the check thinking it was cached already from the earlier
AC_PROC_YACC, so we didn't get the default ":" value)
Closes: #325
Approved by: cgwalters
It's actually just easier for build systems (e.g. rpm-ostree)
using dracut to use `--add ostree` rather than indirecting
through the conf file.
This makes it easier for yum-managed systems to install ostree without
side effects.
Closes: #279
Approved by: gatispaeglis
