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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This follows the pattern used by e.g. glib. If people (commonly
embedded systems) don't want docs, we should support that.
Pull request: #235
Approved by: jlebon
I'd like to use Homu immediately as a replacement for the github merge
button, because I really dislike merge commits for single patches.
I think it shouldn't be too hard to unify our existing PR testing with
this.
This generates a docker image that contains a cached blob of RPMs, so
it's easy to test compose tree.
It's hacky and ugly, but it's better than nothing.
libgsystem has long been deprecated, so this is a small step for man,
and not really a gigantic leap at all for anyone but hey, at least I
changed something in git today.
When running the tests by hand, I wanted to be able to source
`libtest.sh` from a running shell. Make this slightly easier by
allowing one to set `SRCDIR`, since `$0` won't work.
While I was debugging the tests, I wanted to run the daemon
interactively under gdb but still on the session. In our previous
logic this was only possible if we were exec'd by dbus-daemon which
made attaching gdb annoying.
Let's honor the environment variable consistently on client and
server.
This was a semantic change could potentially impact a lot of users who
weren't aware of the new '77 == unchanged' status and would treat it
as an error.
We retain the 77 for `--check` as I feel it's likely fewer people were
scripting that, and the ones that were would more quickly adapt to the
change.
As part of this, change the logic for detecting a change to be more
explicit by comparing the defaults. I think this will fix a potential
bug where we could get a property change notification even if nothing
changed.
Now that the internal reading methods operate on the mainloop, and we
know there can only be one write transaction at a time, it should be
safe to drop the internal mutexes (and multithreading).
Updates to the `OstreeSysroot` instance and DBus API all happen off
the mainloop now. The write transactions now use a separate
`OstreeSysroot` instance, and do not perform any changes to process
state on their own. We always reload state from disk.
I think this is a lot simpler to reason about from a correctness point
of view, at a likely negligble loss in performance for read
transactions.
I'd like to move towards a model where internal worker threads don't
touch the "main context data", i.e. we only use message passing (via
main contexts). This means we wouldn't use a mutex.
I find this model to be significantly simpler to reason about.
Every transaction runs in a thread now, and there's no real drawback
to consistently creating a main context to go with it always. Most
of the transaction types now do a pull, which needs it.
Now that we have `ostree_sysroot_load_if_changed()`, we know more
precisely (and cheaply) when things change. Use inotify to detect
changes as before, but we don't need a timeout because all we do is
call `fstatat()` which is basically free; the inode is going to be in
memory.
This will hopefully help with
https://github.com/projectatomic/rpm-ostree/issues/220
but more investigation is needed.
We were loading the list of osnames by walking the FS, but it's a lot
simpler to just extract the set of known osnames from the deployment
array.
This is part of an effort to unify the "sync cached state with disk"
code in order to address race conditions.
We can't rely on the the GLib hash functions not changing (or being
stable across host systems). Basically here we have a "stringified"
deployment...it might be simpler to just declare this stable.
For the columns that can vary in width, check that the minimum width of
the column is at least the length of the column header. Otherwise, we
can run in a situation where some columns are stuck to each other. The
trivial strlen() should be optimized to a constant by the compiler.
The 'testenv' target enters an environment in which a tmpdir is created
and the daemon is set up and started. This is useful for easy testing.
$ make -j4 && make install
$ make testenv
===== ENTERING TESTENV =====
$ # now we can easily test our new code
$ # we can even make use of helper funcs
$ source ../tests/libtest.sh
$ setup_os_repository archive-z2 syslinux
$ exit
===== EXITING TESTENV =====
The libtest.sh script is aware of whether a tmpdir needs to be created
or not for the test. Make use of this in setup-session.sh so that we're
sure we're in the right directory before creating the sysroot dir.
Running `make check` would fail because test-ucontainer.sh uses
test-repo, which points directly to the installed_testdir, where it is
not installed yet.
We make another processed version of test-repo.repo.in which instead
points to the repo in the srcdir and make use of that in
test-ucontainer.sh.
There are probably other ways of solving this, but this is the one that
jumped out at me.
There are many reasons why the daemon may not be able to start up. An
initialization error doesn't/shouldn't reflect a programming mistake,
but instead a runtime issue in the environment.
Thus, if we fail to start the daemon, we shouldn't use g_error(), which
dumps core. We should instead print the GError and clean up as nicely as
we can.
Resolves https://github.com/projectatomic/rpm-ostree/issues/194.
Right now we're doing the /etc -> /usr/etc inside the RPM import, but
we might as well do the /usr/local bits in both. Also, use
/usr/share/rpm by default for treecompose too so that is unified.
Other things like systemd unit files and kernel handling are only
going to be used for host side composes.
I debated config file formats a lot. JSON is fairly awkward for
humans to write, and really painful to parse from C. YAML is nice,
but also painful from C.
Both are fairly overpowered for what we really need. Keyfiles
(desktop spec, `GKeyFile`) have a lot of limitations, but at least
it's used by systemd and `.desktop` files, and we already have a
parser.
We still parse the JSON treefiles, but internally convert them to
`GKeyFile` (which is in turn converted to `GVariant` for a canonical
form).
