keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
c0081311dd
rpm-ostree/packaging/rpm-ostree.spec.in

212 lines
6.6 KiB
RPMSpec
Raw Normal View History

packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
# The canonical copy of this spec file is upstream at:
spec: Minor tweaks Rename URLs with `projectatomic` to `coreos`, expand the `Source0`, and move it down to be lower than `License` and `URL`.
2020-12-22 17:21:01 +03:00
# https://github.com/coreos/rpm-ostree/blob/master/packaging/rpm-ostree.spec.in
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
Summary: Hybrid image/package system
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
Name: rpm-ostree
Release 2021.5 New release `2021.5`.
2021-05-11 16:56:26 +03:00
Version: 2021.5
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
Release: 1%{?dist}
License: LGPLv2+
spec: Minor tweaks Rename URLs with `projectatomic` to `coreos`, expand the `Source0`, and move it down to be lower than `License` and `URL`.
2020-12-22 17:21:01 +03:00
URL: https://github.com/coreos/rpm-ostree
# This tarball is generated via "cd packaging && make -f Makefile.dist-packaging dist-snapshot"
# in the upstream git. It also contains vendored Rust sources.
Source0: https://github.com/coreos/rpm-ostree/releases/download/v%{version}/rpm-ostree-%{version}.tar.xz
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
ExclusiveArch: %{rust_arches}
spec: Add BuildRequires: make https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot (Upstreamed from https://src.fedoraproject.org/rpms/rpm-ostree/c/6e99dd065de3277de2b5027fb8b81c3743ba6d68?branch=master) Really, libdnf's `cmake` BR does pull it into the buildroot anyway right now. Though we do still need it as well.
2021-01-19 18:25:43 +03:00
BuildRequires: make
spec: Fix up conditionals for ELN The `rust-toolset` package does not exist in Fedora, so we cannot use it for BuildRequires. Change the conditional to exclude ELN from the %rhel conditional. Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
2020-05-22 21:33:46 +03:00
%if 0%{?rhel} && !0%{?eln}
BuildRequires: rust-toolset
%else
spec: Propagate Fedora default rustflags We got annobin (hardening) warnings in a downstream RPM analysis, I think this will help ensure that the Rust code is built with things like `-znow` etc.
2020-12-16 18:24:10 +03:00
BuildRequires: rust-packaging
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: cargo
BuildRequires: rust
%endif
Add --enable-sanitizers (not on by default yet) This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: https://github.com/rust-lang/rust/issues/39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
2021-02-03 00:54:38 +03:00
# Enable ASAN + UBSAN
%bcond_with sanitizers
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
# RHEL8 doesn't ship zchunk today. See also the comments
# in configure.ac around this as libdnf/librepo need to be in
# sync, and today we bundle libdnf but not librepo.
spec: Fix up conditionals for ELN The `rust-toolset` package does not exist in Fedora, so we cannot use it for BuildRequires. Change the conditional to exclude ELN from the %rhel conditional. Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
2020-05-22 21:33:46 +03:00
%if 0%{?rhel} && 0%{?rhel} <= 8
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
%bcond_with zchunk
%else
%bcond_without zchunk
%endif
Default to sqlite rpmdb backend on f34 There won't be any support for writing to the bdb backend in f34, so e.g. pkglayering won't work (and obviously even composes wouldn't work once the buildroot moves to f34). Instead of requiring the whole world to add an `rpmdb` key in their manifests, let's just add a compile flag for it, and tweak the spec file to use this flag on f34.
2020-12-22 01:27:52 +03:00
%if 0%{?fedora} >= 34
%define sqlite_rpmdb_default "--enable-sqlite-rpmdb-default"
%endif
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
# For the autofiles bits below
BuildRequires: /usr/bin/python3
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
# We always run autogen.sh
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: autoconf automake libtool git
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
# For docs
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: chrpath
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
BuildRequires: gtk-doc
BuildRequires: gnome-common
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: /usr/bin/g-ir-scanner
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
# Core requirements
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
# One way to check this: `objdump -p /path/to/rpm-ostree | grep LIBOSTREE` and pick the highest (though that might miss e.g. new struct members)
Add new `ex initramfs-etc` command This command allows users to cheaply inject configuration files in the initramfs stage without having to regenerate the whole initramfs (or even a new OSTree commit). This will be useful for configuring services involved in bringing up the root block device. ``` $ echo 'hello world' > /etc/foobar $ rpm-ostree ex initramfs-etc --track /etc/foobar Staging deployment... done Run "systemctl reboot" to start a reboot $ rpm-ostree status State: idle Deployments: ostree://fedora:fedora/x86_64/coreos/testing-devel Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z) Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b GPGSignature: (unsigned) InitramfsEtc: /etc/foobar ● ostree://fedora:fedora/x86_64/coreos/testing-devel Version: 32.20200716.dev.1 (2020-07-16T02:47:29Z) Commit: 9a817d75bef81b955179be6e602d1e6ae350645b6323231a62ba2ee6e5b9644b GPGSignature: (unsigned) $ reboot (boot into rd.break) sh-5.0# cat /etc/foobar hello world ``` See the libostree side of this at: https://github.com/ostreedev/ostree/pull/2155 Lots more discussions in: https://github.com/coreos/fedora-coreos-tracker/issues/94 Closes: #1930
2020-07-25 00:35:01 +03:00
BuildRequires: pkgconfig(ostree-1) >= 2020.7
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: pkgconfig(polkit-gobject-1)
Switch to taking JSON as input, generate "treefile" from products.json 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.
2014-02-13 03:26:31 +04:00
BuildRequires: pkgconfig(json-glib-1.0)
upgrade: Print out a summary of the package delta This requires us to link to hawkey.
2014-03-28 03:57:10 +04:00
BuildRequires: pkgconfig(rpm)
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: pkgconfig(libarchive)
BuildRequires: pkgconfig(libsystemd)
packaging: Update BRs
2014-11-15 02:07:47 +03:00
BuildRequires: libcap-devel
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: libattr-devel
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
# We currently interact directly with librepo (libdnf below also pulls it in,
# but duplicating to be clear)
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: pkgconfig(librepo)
packaging: Add some dependencies to spec
2014-01-16 07:22:49 +04:00
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
# Needed by curl-rust
BuildRequires: pkgconfig(libcurl)
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: cmake
BuildRequires: pkgconfig(expat)
BuildRequires: pkgconfig(check)
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
# We use some libsolv types directly too (libdnf below also pulls it in,
# but duplicating to be clear)
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
BuildRequires: pkgconfig(libsolv)
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
# We need g++ for libdnf
BuildRequires: gcc-c++
Release 2021.4
2021-04-12 21:00:14 +03:00
# more libdnf build deps (see libdnf's spec for versions; maintain ordering)
%global libsolv_version 0.7.17
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
%global libmodulemd_version 2.11.2-2
%global librepo_version 1.13.0
Release 2021.4
2021-04-12 21:00:14 +03:00
%global swig_version 3.0.12
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: swig >= %{swig_version}
spec: Bump libmodulemd version requirement This matches the latest bump in libdnf: https://github.com/rpm-software-management/libdnf/commit/763ccc3e33d01efc36a996308d7e5f9728e74f14
2020-02-21 18:58:31 +03:00
BuildRequires: pkgconfig(modulemd-2.0) >= %{libmodulemd_version}
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
BuildRequires: pkgconfig(librepo) >= %{librepo_version}
BuildRequires: libsolv-devel >= %{libsolv_version}
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: pkgconfig(json-c)
BuildRequires: pkgconfig(cppunit)
BuildRequires: pkgconfig(sqlite3)
BuildRequires: pkgconfig(smartcols)
Detect whether zchunk (zck) is available at build time We don't *actually* use this ourself, but librepo does, and libdnf gets confused if librepo doesn't support it. This is the case in RHEL8 currently. Basically what breaks is trying to use the Fedora EPEL repo (has zchunk metadata) on RHEL CoreOS. And we have a test in kola that does this today.
2019-10-17 00:02:45 +03:00
%if %{with zchunk}
BuildRequires: pkgconfig(zck) >= 0.9.11
%endif
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
BuildRequires: gpgme-devel
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
# Runtime libdnf deps
spec: Bump libmodulemd version requirement This matches the latest bump in libdnf: https://github.com/rpm-software-management/libdnf/commit/763ccc3e33d01efc36a996308d7e5f9728e74f14
2020-02-21 18:58:31 +03:00
Requires: libmodulemd%{?_isa} >= %{libmodulemd_version}
spec: Add more deps from libdnf It's important to track these closely to avoid odd runtime issues on clients. See previous commit for details.
2021-03-27 16:41:33 +03:00
Requires: libsolv%{?_isa} >= %{libsolv_version}
Requires: librepo%{?_isa} >= %{librepo_version}
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
# For now...see https://github.com/projectatomic/rpm-ostree/pull/637
# and https://github.com/fedora-infra/fedmsg-atomic-composer/pull/17
# etc. We'll drop this dependency at some point in the future when
# rpm-ostree wraps more of ostree (such as `ostree admin unlock` etc.)
Requires: ostree
Requires: bubblewrap
Requires: fuse
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
Requires: %{name}-libs%{?_isa} = %{version}-%{release}
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
%description
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
rpm-ostree is a hybrid image/package system. It supports
"composing" packages on a build server into an OSTree repository,
which can then be replicated by client systems with atomic upgrades.
Additionally, unlike many "pure" image systems, with rpm-ostree
each client system can layer on additional packages, providing
a "best of both worlds" approach.
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
%package libs
Summary: Shared library for rpm-ostree
%description libs
The %{name}-libs package includes the shared library for %{name}.
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
%package devel
Summary: Development headers for %{name}
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
Requires: %{name}-libs%{?_isa} = %{version}-%{release}
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
%description devel
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
The %{name}-devel package includes the header files for %{name}-libs.
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
%prep
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
%autosetup -Sgit -n %{name}-%{version}
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
%build
spec: Disable LTO
2020-07-29 18:44:39 +03:00
# gobject introspection does not work with LTO. There is an effort to fix this
# in the appropriate project upstreams, so hopefully LTO can be enabled someday
# Disable LTO.
%define _lto_cflags %{nil}
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
env NOCONFIGURE=1 ./autogen.sh
spec: Propagate Fedora default rustflags We got annobin (hardening) warnings in a downstream RPM analysis, I think this will help ensure that the Rust code is built with things like `-znow` etc.
2020-12-16 18:24:10 +03:00
# Since we're hybrid C++/Rust we need to propagate this manually;
# the %%configure macro today assumes (reasonably) that one is building
# C/C++ and sets C{,XX}FLAGS
export RUSTFLAGS="%{build_rustflags}"
Add --enable-sanitizers (not on by default yet) This way we at least get unit test coverage (which... our unit test coverage doesn't do much because our main code paths require privileges or virt). One main blocker to this is that rustc doesn't expose first-class support for this yet: https://github.com/rust-lang/rust/issues/39699 At a practical level this works when building in release mode but fails with `cargo test` for some reason; linker arguments being pruned? Not sure. So I was able to use this when composing to find a bug, but then for some other reason the client side apparently infinite loops inside libsolv. So we're not enabling this yet for those reasons, but let's land the build infrastructure now. ``` (lldb) thread backtrace * thread #4, name = 'pool-/usr/bin/r' * frame #0: 0x00007fd61b97200f libc.so.6`__memcpy_sse2_unaligned_erms + 623 frame #1: 0x00007fd61cbc88e6 libasan.so.6`__asan::asan_realloc(void*, unsigned long, __sanitizer::BufferedStackTrace*) + 214 frame #2: 0x00007fd61cc4b725 libasan.so.6`__interceptor_realloc + 245 frame #3: 0x00007fd61baec43e libsolv.so.1`solv_realloc + 30 frame #4: 0x00007fd61baf0414 libsolv.so.1`repodata_add_dirstr + 276 frame #5: 0x00007fd61bb6f755 libsolvext.so.1`end_element + 53 frame #6: 0x00007fd61b05855d libxml2.so.2`xmlParseEndTag1.constprop.0 + 317 frame #7: 0x00007fd61b063548 libxml2.so.2`xmlParseTryOrFinish.isra.0 + 888 frame #8: 0x00007fd61af7ed20 libxml2.so.2`xmlParseChunk + 560 frame #9: 0x00007fd61bb727e7 libsolvext.so.1`solv_xmlparser_parse + 183 frame #10: 0x00007fd61bb5ea0e libsolvext.so.1`repo_add_rpmmd + 254 frame #11: 0x000055a4fce7a5f5 rpm-ostree`::load_filelists_cb(repo=<unavailable>, fp=<unavailable>) at dnf-sack.cpp:444:23 frame #12: 0x000055a4fce7cad6 rpm-ostree`load_ext(_DnfSack*, libdnf::Repo*, _hy_repo_repodata, char const*, char const*, int (*)(s_Repo*, _IO_FILE*), _GError**) at dnf-sack.cpp:430:13 frame #13: 0x000055a4fce7df60 rpm-ostree`dnf_sack_load_repo at dnf-sack.cpp:1789:26 frame #14: 0x000055a4fce7eee9 rpm-ostree`dnf_sack_add_repo at dnf-sack.cpp:2217:28 frame #15: 0x000055a4fce7f0fb rpm-ostree`dnf_sack_add_repos at dnf-sack.cpp:2271:32 frame #16: 0x000055a4fce870ee rpm-ostree`dnf_context_setup_sack_with_flags at dnf-context.cpp:1796:29 frame #17: 0x000055a4fcdf757f rpm-ostree`rpmostree_context_download_metadata at rpmostree-core.cxx:1206:44 frame #18: 0x000055a4fcdf95c3 rpm-ostree`rpmostree_context_prepare at rpmostree-core.cxx:2001:48 frame #19: 0x000055a4fce54ab7 rpm-ostree`rpmostree_sysroot_upgrader_prep_layering at rpmostree-sysroot-upgrader.cxx:1018:38 frame #20: 0x000055a4fcdcb143 rpm-ostree`deploy_transaction_execute(_RpmostreedTransaction*, _GCancellable*, _GError**) at rpmostreed-transaction-types.cxx:1445:49 frame #21: 0x000055a4fcdba4cd rpm-ostree`transaction_execute_thread(_GTask*, void*, void*, _GCancellable*) at rpmostreed-transaction.cxx:340:34 frame #22: 0x00007fd61c58f7e2 libgio-2.0.so.0`g_task_thread_pool_thread + 114 frame #23: 0x00007fd61c3d7e54 libglib-2.0.so.0`g_thread_pool_thread_proxy.lto_priv.0 + 116 frame #24: 0x00007fd61c3d52b2 libglib-2.0.so.0`g_thread_proxy + 82 frame #25: 0x00007fd61b8af3f9 libpthread.so.0`start_thread + 233 frame #26: 0x00007fd61b9c9903 libc.so.6`__clone + 67 (lldb) ```
2021-02-03 00:54:38 +03:00
%configure --disable-silent-rules --enable-gtk-doc %{?sqlite_rpmdb_default} %{?with_sanitizers:--enable-sanitizers}
spec: Use make macros This pull request was create automatically for the f33 change: https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro (Upstreamed from https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/39).
2020-07-22 18:54:49 +03:00
%make_build
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
%install
spec: Use make macros This pull request was create automatically for the f33 change: https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro (Upstreamed from https://src.fedoraproject.org/rpms/rpm-ostree/pull-request/39).
2020-07-22 18:54:49 +03:00
%make_install INSTALL="install -p -c"
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
find $RPM_BUILD_ROOT -name '*.la' -delete
packaging: New directory with spec file
2014-01-16 06:54:48 +04:00
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
# I try to do continuous delivery via rpmdistro-gitoverlay while
# reusing the existing spec files. Currently RPM only supports
# mandatory file entries. What this is doing is making each file
# entry optional - if it exists it will be picked up. That
# way the same spec file works more easily across multiple versions where e.g. an
# older version might not have a systemd unit file.
cat > autofiles.py <<EOF
import os,sys,glob
os.chdir(os.environ['RPM_BUILD_ROOT'])
for line in sys.argv[1:]:
if line == '':
break
if line[0] != '/':
sys.stdout.write(line + '\n')
else:
files = glob.glob(line[1:])
if len(files) > 0:
sys.stderr.write('{0} matched {1} files\n'.format(line, len(files)))
sys.stdout.write(line + '\n')
else:
sys.stderr.write('{0} did not match any files\n'.format(line))
EOF
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
PYTHON=python3
if ! test -x /usr/bin/python3; then
PYTHON=python2
fi
$PYTHON autofiles.py > files \
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
'%{_bindir}/*' \
'%{_libdir}/%{name}' \
'%{_mandir}/man*/*' \
Move D-Bus conf file to $(datadir)/dbus-1/system.d Since D-Bus 1.9.18 configuration files installed by third-party should go in share/dbus-1/system.d. The old location is for sysadmin overrides. Closes: #1903 Approved by: jlebon
2019-09-16 18:51:13 +03:00
'%{_datadir}/dbus-1/system.d/*' \
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
'%{_sysconfdir}/rpm-ostreed.conf' \
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
'%{_prefix}/lib/systemd/system/*' \
'%{_libexecdir}/rpm-ostree*' \
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
'%{_datadir}/polkit-1/actions/*.policy' \
Add polkit support This allows non-root users access to the rpm-ostree daemon, which is a pre-requirement for gnome-software rpm-ostree support. Closes: #745 Closes: #825 Approved by: cgwalters
2017-06-09 13:52:01 +03:00
'%{_datadir}/dbus-1/system-services' \
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
'%{_datadir}/bash-completion/completions/*'
$PYTHON autofiles.py > files.lib \
'%{_libdir}/*.so.*' \
'%{_libdir}/girepository-1.0/*.typelib'
$PYTHON autofiles.py > files.devel \
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
'%{_libdir}/lib*.so' \
'%{_includedir}/*' \
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
'%{_datadir}/dbus-1/interfaces/org.projectatomic.rpmostree1.xml' \
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
'%{_libdir}/pkgconfig/*' \
'%{_datadir}/gtk-doc/html/*' \
'%{_datadir}/gir-1.0/*-1.0.gir'
doc: Add gtk-doc for new library
2015-04-09 00:20:50 +03:00
spec: Update from fedora dist-git 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
2017-03-07 17:00:56 +03:00
%files -f files
spec: Fix documentation files Follow-up to the recent licensing changes. This is the first spec file change since moving it upstream. Closes: #1900 Approved by: cgwalters
2019-09-06 21:38:59 +03:00
%doc COPYING.GPL COPYING.LGPL LICENSE README.md
packaging: Split off autobuilder to separate package
2014-02-24 02:27:56 +04:00
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
%files libs -f files.lib
packaging: Fix some rpmlint issues
2014-03-10 22:19:29 +04:00
packaging: Move canonical spec file here So this is a somewhat significant change, but I'd like to try having the canonical spec file upstream. A few reasons for this: 1. We integrate tightly with the distros we're destined for, and so we're in a pretty good position for knowing how the software should be packaged. 2. We can atomically change packaging along with the rest of the code. This has important ramifications, including that it'll be easier to integrate with continuous build services like Packit, but releases will also be less fraught with last-minute packaging fixes. 3. I'm playing with Jenkins pipelines and there I'd like to make RPMs the "artifact" that gets moved down the pipeline into later stages (e.g. `cosa build`). We could even eventually make it an actual external artifact so that anyone can easily download RPMs from any random PR for testing. (And in fact, with a thin yumrepo layer on top, it could be used to replace Packit/rdgo entirely). Not that this approach doesn't have issues as well (e.g. on the dist-git side, we'll need some minimal tooling to merge in the changelog), though I think it's worth trying out. Closes: #1900 Approved by: cgwalters
2019-09-06 22:25:27 +03:00
%files devel -f files.devel
Reference in New Issue Copy Permalink