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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Followup to the previous curl fixes; if we'd had an assertion
earlier debugging the failure would have been more obvious.
All of these are "should not fail" cases so asserting is
right.
Because curl_multi_cleanup may invoke callbacks, we effectively have
some circular references going on here. See discussion in
https://github.com/curl/curl/issues/14860
Basically what we do is the socket callback libcurl may invoke into a no-op when
we detect we're finalizing. The data structures are owned by this object and
not by the callbacks, and will be destroyed below. Note that
e.g. g_hash_table_unref() may itself invoke callbacks, which is where
some data is cleaned up.
Signed-off-by: Colin Walters <walters@verbum.org>
ref https://github.com/ostreedev/ostree/issues/3299
This won't fix that issue, but *if* this assertion triggers
it should give us a better idea of the possible codepaths
where it is happening.
Signed-off-by: Colin Walters <walters@verbum.org>
A couple fixes to make PRs and non-PRs work correctly:
* In a conditional expression, `true` or `false` are returned unless you
terminate both sides in a ternary. That was causing 2 strings to be
suffixed with `false` instead of an empty string.
* For a PR, we do actually want to cancel in progress runs since there's
no danger of breaking an in progress deployment.
* For PRs, just use the same `github-pages-pr` name for the artifact.
The important part is that it's not called `github-pages` where an in
progress deployment could pick it up. Otherwise it can use the same
name all the time.
In #3205, we introduced a check to skip re-generating the GRUB config if
we detect that static configs are in used by looking at bootupd's state.
Unfortunately this check is incomplete and does not account for present
but null entries in the JSON state file.
A proper fix would be to parse the JSON but this requires a larger code
change.
Fixes: https://github.com/ostreedev/ostree/issues/3295
Fixes: https://github.com/ostreedev/ostree/pull/3205
I was trying to check something with `-fsanitize=address`
and it warned about this memory leak. It's...subtle, basically
we were leaking when the same commit was added to the hash table.
But unfortunately fixing that then complicates ownership
over the return value; what we really want to use here is
`g_hash_table_steal_all_keys` but RHEL 9.4 is still rocking
`glib2-2.68.4` so we can't use it.
(Rust would mean we wouldn't have leaked anything here in the
first place...)
Signed-off-by: Colin Walters <walters@verbum.org>
Back in 2b8d586c5, /sysroot was changed to be a private mount so that
submounts of /var do not propagate back to the stateroot /var. That's
laudible, but it makes /sysroot different than every other shared mount
in the root namespace. In particular, it means that submounts of
/sysroot do not propagate into separate mount namespaces.
Rather than make /sysroot private, make /var a slave+shared mount so
that it receives mount events from /sysroot but not vice versa. That
achieves the same effect of preventing /var submount events from
propagating back to /sysroot while allowing /sysroot mount events to
propagate forward like every other system mount. See
mount_namespaces(7)[1] and the linux shared subtrees[2] documentation
for details on slave+shared mount propagation.
When /var is mounted in the initramfs, this is accomplished with
mount(2) syscalls. When /var is mounted after switching to the real
root, the mount propagation flags are applied as options in the
generated var.mount unit. This depends on a mount(8) feature that has
been present since util-linux 2.23. That's available in RHEL 7 and every
non-EOL Debian and Ubuntu release. Applying the propagation from
var.mount fixes a small race, too. Previously, if a /var submount was
added before /sysroot was made private, it would have propagated back
into /sysroot. That was possible since ostree-remount.service orders
itself after var.mount but not before any /var submounts.
1. https://man7.org/linux/man-pages/man7/mount_namespaces.7.html
2. https://docs.kernel.org/filesystems/sharedsubtree.htmlFixes: #2086
This tests the current behavior of making /sysroot a private mount so
that submounts on /var do not propagate back to /sysroot. It also shows
how submounts of /sysroot do not propagate into separate mount
namespaces for the same reason.
xref https://github.com/coreos/rpm-ostree/issues/5071
Hiding errors by default is painful. At least as of
recently in Fedora it looks like the command is nice
and quiet by default, I only see
```
Generating grub configuration file ...
Adding boot menu entry for UEFI Firmware Settings ...
done
```
Signed-off-by: Colin Walters <walters@verbum.org>
This is another warning from recently changed code from Coverity:
```
1. Defect type: OVERRUN
16. libostree-2024.7/src/libostree/ostree-repo-commit.c:823:7: overrun-buffer-arg: Overrunning array "target_checksum" of 65 bytes by passing it to a function which accesses it at byte offset 258 using argument "size" (which evaluates to 259). [Note: The source code implementation of the function has been overridden by a builtin model.]
```
I think this can only happen if the repository is corrupt; the
data shouldn't be that long. But fix this by passing the max
length we expect; this will ignore the rest currently.
Signed-off-by: Colin Walters <walters@verbum.org>
Similar to d528083cae - I don't
believe we actually had a leak here because `dirname` always
returns the same start pointer, but this makes Coverity
happy.
Signed-off-by: Colin Walters <walters@verbum.org>
