Automate building RPMs and DEBs as well as other artifacts on multiple Linux distributions, versions and architectures using Docker/Podman
License: MIT License
pkger is a tool that automates building RPMs, DEBs, PKG, APK and other packages on multiple Linux distributions, versions and architectures with the help of Docker or Podman.
To learn more about pkger head over to the user guide.
example directory of master branch
Thanks for creating this awesome project!
I'm hoping to use pkger to build packages that are hosted on a private git server. Based on my understanding, the easiest way for me to do this right now would be to include my SSH key that is authorized to access the git server in my docker image. However, this is a little messy and could create security issues. It seems like forwarding the SSH agent to the docker container would be the right way to do this. What do you think?
Currently, the build uses a generated key with abuild-keygen
pkger/pkger-core/src/build/package/apk.rs
Lines 115 to 122 in 859519f
When building multiple packages the output gets way too unreadable. A better way to present it would perhaps be a dynamic progress bars for each build and a log file with the build output.
Currently the state file is saved in the current working directory when pkger is executed. It would be nice if the systems cache directory could be used to store the file.
This seems like the best approach:
https://docs.rs/dirs/3.0.2/dirs/fn.cache_dir.html
Images don't appear in docker after using build_image()
When joining all builds display at the end which builds failed and which succeded.
Running pkger build produces:
WARN no recipes to build
However, pkger list recipes outputs a non-empty list. I can share the whole trace from pkger build, but it seems like the important part is just this:
TRACE opts=Opts {
quiet: false,
debug: false,
trace: true,
filter: None,
config: None,
command: Build(
BuildOpts {
recipes: [],
simple: None,
images: None,
docker: None,
all: false,
no_sign: false,
},
),
}
Export helpful environment variables for use during build or install.
For example:
$PKGR_OS os of the container$PKGR_OS_VER version of the os$PKGR_BLD_DIR build directory where source is downloaded toThis would allow adding some logic to the recipes based on the container that is ran.
Currently each build has to reinstall all the dependencies. Perhaps there should be a transitive image created from base image that contains all the dependencies and cached for later use. Might make images state that are reconsidered in #29 actually useful.
It would be ncie if there was a way to delete an image definition with it's files or recipes.
$ pkger rm image centos8root@b5e17de87967:/tmp# dpkg -i curl_7.67.0-0.deb
dpkg-deb: error: 'curl_7.67.0-0.deb' is not a Debian format archive
dpkg: error processing archive curl_7.67.0-0.deb (--install):
dpkg-deb --control subprocess returned error exit status 2
Errors were encountered while processing:
curl_7.67.0-0.deb
Check if it runs on Windows and add binaries to release workflow
As in the title, there should be a subcommand that doesn't require an images directory, dynamically creates the image as needed and builds the desired package.
Documentation states builds for custom images should also use "per-image" options from 'pkger-rpm' or 'pkger-deb' for recipe params like build, build-depends, patches, etc.
But they don't.
Create recipe containing
metadata:
name: test
... (other required fields)
build_depends:
all: [ ]
pkger-rpm: [bison]
pkger-deb: [bison]
depends:
all: [gawk]
pkger-rpm: [bison]
pkger-deb: [bison]
build:
steps:
- cmd: mkdir -p ${PKGER_OUT_DIR}/opt/test && touch ${PKGER_OUT_DIR}/opt/test/a
- cmd: bison --help
Define custom image (in global config and in images) for example as:
- name: rocky8
target: rpm
os: Rocky
Run build for image rocky8 with pkger build -i rocky8 -- test
Build fails with
[ERROR][2022-12-02T21:50:32.996Z][test][7.86.0][rocky8] /bin/sh: bison: command not found
(because bison package was not installed during build preparation steps).
When bison package is specified explicitly for rocky8, it's properly installed.
The same effect is for debianoids and pkger-deb clause.
Simple builds (-s rpm / -s deb) work properly.
The same problem I observed for build-depends recipe option. I did not checked other params that accept per-image values, but I suspect the problem also occurs for them.
Figure out a way to store it in the recipe.toml.
For now it's not possible to build for both Debian and RedHat targets if there is a dependency whose name varies based on os. For example libssl-dev on Debian and openssl-devel on RedHat.
This way users could still run with SSH host key verification enabled which is a much more secure way to operate.
It would be nice if there was a way to change the current directory to the directory of an image or recipe like:
~ $ pkger cd recipe rocky8
~/recipes/rocky8 $This feature would allow creating a base recipe that has all common fields shared across many packages and reduce code duplication. For example, packaging python and creating python-38, python-39, python-310 packages would only require a base recipe python and would only override fields like version and name.
Base recipe <recipes_dir>/python/recipe.yml:
metadata:
name: python
description: '...'
maintainer: 'Name Surname <[email protected]>'
...
build:
...Child recipe <recipes_dir>/python-39/recipe.yml:
from: python
metadata:
name: python-39
version: 3.9.6Child recipe <recipes_dir>/python-38/recipe.yml:
from: python
metadata:
name: python-38
version: 3.8.2All child recipes share not specified fields with the base recipe python specified in from:
Currently it can be manually entered by the user which could create erroneous packages.
patches:
- gcc11-alt-compat-test.patch
- gcc11-d-shared-libphobos.patch
...
During build I can see in output:
[INFO ][2022-12-01T18:08:10.576Z][sfx-gcc11][11.3.0][rocky8] applying patches
[ERROR][2022-12-01T18:08:10.599Z][sfx-gcc11][11.3.0][rocky8] /bin/sh: /tmp/sfx-gcc11-tmp-1669918080/patches/gcc11-alt-compat-test.patch: No such file or directory
[WARN ][2022-12-01T18:08:10.600Z][sfx-gcc11][11.3.0][rocky8] applying patch Patch { patch: "gcc11-alt-compat-test.patch", strip: 0, images: None } failed, reason = command failed with exit code 1
Error:
/bin/sh: /tmp/sfx-gcc11-tmp-1669918080/patches/gcc11-alt-compat-test.patch: No such file or directory
...
... and so on for all patches.
And build continues like nothing wrong happened.
As I looked into container, patches are uploaded to /tmp/sfx-gcc11-tmp-1669918080/patches.tar/ directory, /tmp/sfx-gcc11-tmp-1669918080/patches is empty
I see 2 problems here:
It seems as if it skiped the exec_build_steps part where this directory with the binary is created.
Backtrace:
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running `target/debug/pkger -d 'http://0.0.0.0:2376' -c example/conf.toml pkger`
ERROR pkger > image ubuntu_not_latest doesn't have Dockerfile in it's root directory
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
ErrorMessage { msg: "failed to exec step [\"bash\", \"/tmp/move_files.sh\"] in container pkger-ubuntu_latest-1578297507
- CmdOut { out: \"mv: cannot stat \\\'/opt/pkger/*\\\': No such file or directory\\r\\n\", info:
ExecInspect { can_remove: false, container_id: \"18c00ad70efb2cc668cb0874f416ab6cd4fd5c2b68f0aa1f77a76b30bbeba9cb\", detach_keys: \"\",
exit_code: 1, id: \"6eacd1328b17a77ed0dd15c77da77b842fc069c34d52b418f5f105c1a890b75f\",
open_stderr: true, open_stdin: false, open_stdout: true, process_config: Some(Object({\"arguments\":
Array([String(\"/tmp/move_files.sh\")]), \"entrypoint\": String(\"bash\"), \"privileged\": Bool(false), \"tty\": Bool(true)})), running: false, pid: Some(104416) } }" }
stack backtrace:
0: failure::backtrace::internal::InternalBacktrace::new
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.6/src/backtrace/internal.rs:46
1: failure::backtrace::Backtrace::new
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.6/src/backtrace/mod.rs:121
2: <failure::error::error_impl::ErrorImpl as core::convert::From<F>>::from
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.6/src/error/error_impl.rs:19
3: <failure::error::Error as core::convert::From<F>>::from
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.6/src/error/mod.rs:36
4: failure::error_message::err_msg
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.6/src/error_message.rs:12
5: pkger::Pkger::exec_step::{{closure}}
at <::failure::macros::format_err macros>:1
6: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
7: std::future::set_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:79
8: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
9: std::future::poll_with_tls_context::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
10: std::future::get_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:111
11: std::future::poll_with_tls_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
12: pkger::Pkger::handle_deb_build::{{closure}}
at src/lib.rs:591
13: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
14: std::future::set_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:79
15: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
16: std::future::poll_with_tls_context::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
17: std::future::get_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:111
18: std::future::poll_with_tls_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
19: pkger::Pkger::build_recipe::{{closure}}
at src/lib.rs:488
20: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
21: std::future::set_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:79
22: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
23: std::future::poll_with_tls_context::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
24: std::future::get_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:111
25: std::future::poll_with_tls_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:121
26: pkger::main::{{closure}}
at src/main.rs:31
27: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
28: std::future::set_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:79
29: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
30: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:139
31: tokio::runtime::global::with_state::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:100
32: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
33: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
34: tokio::runtime::global::with_state
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:83
35: tokio::runtime::global::with_basic_scheduler
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:62
36: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:122
37: tokio::runtime::Runtime::block_on::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/mod.rs:419
38: tokio::runtime::global::with_state::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:100
39: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
40: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
41: tokio::runtime::global::with_state
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:83
42: tokio::runtime::global::with_basic_scheduler
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:62
43: tokio::runtime::basic_scheduler::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:174
44: tokio::runtime::spawner::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/spawner.rs:30
45: tokio::runtime::handle::Handle::enter::{{closure}}::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:36
46: tokio::time::clock::Clock::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/time/clock.rs:30
47: tokio::runtime::time::variant::with_default
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/time.rs:43
48: tokio::runtime::handle::Handle::enter::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:36
49: tokio::runtime::blocking::pool::Spawner::enter::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/blocking/pool.rs:194
50: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
51: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
52: tokio::runtime::blocking::pool::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/blocking/pool.rs:179
53: tokio::runtime::handle::Handle::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:33
54: tokio::runtime::Runtime::block_on
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/mod.rs:416
55: pkger::main
at src/main.rs:21
56: std::rt::lang_start::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
57: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:48
std::panicking::try::do_call
at src/libstd/panicking.rs:287
58: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:78
59: std::panicking::try
at src/libstd/panicking.rs:265
std::panic::catch_unwind
at src/libstd/panic.rs:396
std::rt::lang_start_internal
at src/libstd/rt.rs:47
60: std::rt::lang_start
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
61: main
62: __libc_start_main
63: _start
', src/libcore/result.rs:1165:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:77
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:61
4: core::fmt::write
at src/libcore/fmt/mod.rs:1028
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:65
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:50
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:188
9: std::panicking::default_hook
at src/libstd/panicking.rs:205
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:464
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:373
12: rust_begin_unwind
at src/libstd/panicking.rs:302
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:139
14: core::result::unwrap_failed
at src/libcore/result.rs:1165
15: core::result::Result<T,E>::unwrap
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libcore/result.rs:933
16: pkger::main::{{closure}}
at src/main.rs:31
17: <std::future::GenFuture<T> as core::future::future::Future>::poll::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
18: std::future::set_task_context
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:79
19: <std::future::GenFuture<T> as core::future::future::Future>::poll
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/future.rs:43
20: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:139
21: tokio::runtime::global::with_state::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:100
22: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
23: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
24: tokio::runtime::global::with_state
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:83
25: tokio::runtime::global::with_basic_scheduler
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:62
26: tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:122
27: tokio::runtime::Runtime::block_on::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/mod.rs:419
28: tokio::runtime::global::with_state::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:100
29: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
30: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
31: tokio::runtime::global::with_state
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:83
32: tokio::runtime::global::with_basic_scheduler
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/global.rs:62
33: tokio::runtime::basic_scheduler::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/basic_scheduler.rs:174
34: tokio::runtime::spawner::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/spawner.rs:30
35: tokio::runtime::handle::Handle::enter::{{closure}}::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:36
36: tokio::time::clock::Clock::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/time/clock.rs:30
37: tokio::runtime::time::variant::with_default
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/time.rs:43
38: tokio::runtime::handle::Handle::enter::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:36
39: tokio::runtime::blocking::pool::Spawner::enter::{{closure}}
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/blocking/pool.rs:194
40: std::thread::local::LocalKey<T>::try_with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:262
41: std::thread::local::LocalKey<T>::with
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/thread/local.rs:239
42: tokio::runtime::blocking::pool::Spawner::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/blocking/pool.rs:179
43: tokio::runtime::handle::Handle::enter
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/handle.rs:33
44: tokio::runtime::Runtime::block_on
at /home/wojtek/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.2.6/src/runtime/mod.rs:416
45: pkger::main
at src/main.rs:21
46: std::rt::lang_start::{{closure}}
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
47: std::rt::lang_start_internal::{{closure}}
at src/libstd/rt.rs:48
48: std::panicking::try::do_call
at src/libstd/panicking.rs:287
49: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:78
50: std::panicking::try
at src/libstd/panicking.rs:265
51: std::panic::catch_unwind
at src/libstd/panic.rs:396
52: std::rt::lang_start_internal
at src/libstd/rt.rs:47
53: std::rt::lang_start
at /rustc/73528e339aae0f17a15ffa49a8ac608f50c6cf14/src/libstd/rt.rs:61
54: main
55: __libc_start_main
56: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
For example allow prepending @:image_name or something else to identify where the command should be run. Maybe allow grouping like this: @:{image1, image2, image3}
It would be nice if there was a way to easily copy a recipe or image like
$ pkger copy recipe gcc10 gcc11 This would be much more elegant and would act similar to the SSH socket that got introduced in #58 . This seems like the best guide to forwarding the GPG agent.
From initial tests it did not work for me when I did the following:
# Add required option to sshd config
sudo echo "StreamLocalBindUnlink yes" >> /etc/ssh/sshd_config
sudo systemctl restart sshd
# make sure the agent is running on the host
gpg-connect-agent /bye
# start the container
docker run -it --rm -v $(gpgconf --list-dirs agent-extra-socket):/root/.gnupg/S.gpg-agent debian:10And in the container
chmod 700 /root/.gnupg
chown root:root /root/.gnupg/S.gpg-agent
apt -y update && apt -y install gnupg2
gpg2 --list-keysWill have to take a deeper look at this.
Currently the images state is not very well implemented and might as well serve no purpose.
I have a patch file in my recipe dir that I am trying to apply using the patches metadata key, like so:
patches:
- streamVideoRTP.patch
However, the path to the patch incorrectly contains recipe.yml.
INFO mkdir: created directory '/tmp/boneCV-tmp-1626722182/patches'
TRACE using patch from recipe_dir, patch=/home/jonah/melizalab/lab_packages/recipes/boneCV/recipe.yml/streamVideoRTP.patch
DEBUG adding, entry=/home/jonah/melizalab/lab_packages/recipes/boneCV/recipe.yml/streamVideoRTP.patch
ERROR job failed, id=pkger-boneCV-linux-armv7a-1626722182, reason=Not a directory (os error 20), duration=0.90834755s
TRACE saving images state
It looks like Recipe::new expects to receive the path to the recipe_dir but is instead given the path to the recipe file:
https://github.com/wojciechkepka/pkger/blob/6bcc455f2503a2b8506508b7dfa40e80b512494e/pkger-core/src/recipe/mod.rs#L75-L76
Allow spawning a "worker" unit per image.
Sometimes, a recipe can have the same build instructions for multiple versions and creating multiple recipes is the only way to solve this currently. It would be nice if there was a way to specify multiple versions and then when building this recipe a specific version would have to be used otherwise all versions would build. For example:
$ pkger build my-recipe==1.9.2would only build this specific version, while:
$ pkger build my-recipewould build all available versions. Multiple version build should also be supported like:
$ pkger build my-recipe==1.9.2 my-recipe==1.8.0Sorry, this is an awkward way to reach out, but the email listed on your github didn't work and your website appears to be down.
I noticed that you have ownership of the "rpmspec" crate but that the crates got yanked and the repository deleted.
https://crates.io/crates/rpmspec
I'm curious if you would be OK with allowing us to use the crate name, and potentially continue maintaining your library?
We're working on a specfile parsing library and "rpmspec" is the most obvious name. But making a building and parsing library would be great, too, and we'd be interested in continuing your work on that portion also.
https://github.com/rpm-rs/rpmspec-rs
If you would rather not, that is perfectly OK (of course). But if you're not using it and it's something you're open to, let me know. Thanks.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.