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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Nuke systemd source files for the same reasons as libcurl (see #1554).
Also noticed that libz-sys was doing this, though it's not new to this
patch.
For reference, see: https://github.com/projectatomic/rpm-ostree/pull/1554Closes: #1601
Approved by: cgwalters
The problem is building bindgen as part of our single run
locks serde to way old versions, and I want to use newer versions.
Since Fedora will now again ship a `cbindgen` package, let's
also support using it if we find it, saving ourselves
the cost of building it.
For distros that don't ship it (e.g. CentOS) for CI purposes
we build it. For downstream builds that are offline, rather
than vendor the cbindgen sources like we do with our main Rust,
let's just vendor the `rpmostree-rust.h` file as was suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=1608670
Closes: https://github.com/projectatomic/rpm-ostree/issues/1557Closes: #1573
Approved by: jlebon
The `curl-sys` crate includes with it a bundled copy of libcurl which is
used if `pkgconfig` doesn't find libcurl configuration files. In our
case, we always want to use the system libcurl. So filter it out. This
also drops our *compressed* tarball by 2.5M.
One tricky bit is that cargo crates include a checksum JSON that's read
by `cargo build` later on to validate the crate. So we need to do some
JSON surgery.
What made me look into this was that Koji builds were failing due to the
`%configure` macro including hardening bits that sub out e.g. all
`config.sub` and `ltmain.sh` files which then caused the checksum to
fail validation. This completely sidesteps that issue.
Closes: #1554
Approved by: cgwalters
The script already turned on `-e` later on. Make it conform to the
standard strict mode with the rest of the options right at the
beginning.
Closes: #1554
Approved by: cgwalters
I made a subtle change at the last minute with the previous PR
to use `*` for the glob instead of `.`, because the tmpdir had a `.tmp`
file I didn't want.
But - this caused us to miss the `.cargo` directory which has
the config file. And while I'd been testing builds with no network,
of course cargo was really pulling content from `~/.cargo`.
When I went to do a scratch build in Koji, that failed obviously.
I tested this makes things [work with a SRPM scratch](https://koji.fedoraproject.org/koji/taskinfo?taskID=27490830)
and in my dev container under `bwrap --unshare-net` with `mv ~/.cargo{,.orig}`.
Closes: #1394
Approved by: jlebon
This ends up being different than what landed in librsvg (that
was imported into ostree) because in rpm-ostree we've basically
been using `git archive`-based tarball generation rather than `make dist`
for a long time. And supporting `make dist` looks like it'd get into
handling the `libdnf` bits and walking into `cmake` land so...yeah
let's not do that.
The canonical sources are in git (recursively via submodule),
except for the Rust sources, which cargo can download dynamically,
and with this patch we support glomming all of that together
into a tarball.
(And turn off `make dist` so people understand how we do it)
Tested by `make -f Makefile.dist-packaging dist-snapshot`, then
copying the resulting tarball into a container with `--net=none`
and building there.
Closes: #1391
Approved by: jlebon
This allows non-root users access to the rpm-ostree daemon, which is
a pre-requirement for gnome-software rpm-ostree support.
Closes: #745Closes: #825
Approved by: cgwalters
We'll keep a copy here for now, though the canonical
version should be viewed as the Fedora dist-git.
Updated-by: Colin Walters <walters@verbum.org>
Closes: #667
Approved by: jlebon
Let's try out https://wiki.centos.org/ContainerPipeline
Having maintained Docker images for rpm-ostree seems kind of overdue.
(I didn't actually test the CP bits since I'm not sure how to do that)
Closes: #460
Approved by: jlebon
As long as we require uid 0, we should encourage people to run
`compose tree` in its current state inside a Docker/nspawn container.
I didn't spend a lot of time on this yet but it works. Am considering
switching to a CentOS base though.
Closes: #249
Approved by: giuseppe
This is in preparation for `rpm-ostree container`, which handles
unpacking RPMs as non-root.
At the moment, I'm copying code in from both ostree's libarchive bits
(fixable...may need to export some utility functions) and some
functions from libhif (harder, see:
http://lists.rpm.org/pipermail/rpm-ecosystem/2016-January/000297.html )
There's lots more cleanup to do here, but I don't want to block on the
resolution of the libhif changes.
Makefile.dist-packaging seems to assume to be run under packaging/ as
"make -C packaging -f Makefile.dist-packaging rpm" so ensure the
srcdir is set correctly to point to the parent directory.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Some downstreams want the ability to separate the compose tooling from
the client, for e.g. support reasons.
This approach supports generating a tarball without the source for the
compose command, and requires specifying a config option to disable
it.
This will move to a separate repository. This allows a clearer
separation between the core tool (which is shipped on client systems
too), and the compose infrastructure.
Furthermore, I want to make the autobuilder a Docker container.
This is somewhat similar to what we've been doing with Continuous; we
take the manifest.json, and turn it into a "snapshot". Except here
there is a notion of inheritance.
This gets stored into the tree as /usr/share/rpm-ostree/treefile.json.
Additionally, it goes into the autobuilder directory in
products-built.json. Though really we should split up that file,
since it will be kind of...large.
There are two major reasons:
1) I want to do things like process SELinux labels here, and that
type of thing is best done in C.
2) There are presently 3 languages in this code, and this takes us
down to just two.
