Joschka Seydell comments

Results 9 comments of


                                            Joschka Seydell

Concept: Separate Application / Container / Artifact Updates in RAUC

First of all: thanks for your efforts! rauc has already evolved to a quite impressive framework. Concerning the concept, I had a few questions coming up in my mind: _What...

I want to add a tutorials section to the documentation, starting with a tutorial on how to run and test RAUC locally

@Erik-Sovereign and @Zylatis, the issues you observed with `qemu-test` should be fixed on latest master after PR #1526 now. Maybe you could confirm whether the original issue persists?

Protect string comparisons against segfaults

I do acknowledge that `strlen` (or the EASTL variant of it, `CharStrlen`) may segfault, as this is allowed by the specification. What is far less obvious to me is the...

qemudriver: Allow machine-specific options and pre-start QMP commands

Thanks for the review and sorry for force-pushing so often - it looked easier to me to fix the one linting issue I overlooked when implementing the proposal from Rouven.

qemudriver: Allow machine-specific options and pre-start QMP commands

I shortly glimpsed into the failing pipeline and now I'm wondering whether some environment changes happened? The test_qemudriver is not able to locate qemu-system-arm...

qemudriver: Allow machine-specific options and pre-start QMP commands

Hmm, I'm actually not sure where this dependency is now coming from. It's not like the tests I want add depend on it. Maybe I forgot to inject the qemu_mock...

qemudriver: Allow machine-specific options and pre-start QMP commands

I think I found the culprit - a missing `qemu_version_mock` - I overlooked the dependency to this in the `get_qemu_base_args`. Unfortunately, I wasn't able to test the workflow locally -...

qemudriver: Allow machine-specific options and pre-start QMP commands

Makes sense. I haven't expected a proposal so early, thanks!

labgrid/qemudriver: tie QEMU and QMP monitor start/stop to on_activate()/on_deactivate()

Thanks for addressing this, @Bastian-Krause ! Seems indeed more adherent to the common design/usage patterns. I'll give it a closer look as soon as time permits.