Jonathan Lebon
Jonathan Lebon
One thing I briefly considered at first was just doing `set_ref` back to the `base_revision` before pulling. Though... it really feels like hacking around the problem instead of communicating exactly...
> Making this fix hard dependent on a new libostree is a bit problematic because yeah...the signing stuff needs more work. It's obviously less elegant but Yeah, I wasn't sure...
Requires: #2058 Requires: https://github.com/rpm-software-management/libdnf/pull/937
The feel I'm going for here is to match the UX from `cargo`. Reality is not so simple however, because there are (unsurprisingly) major differences between Rust packages and RPM...
A real example of what this fixes here: https://github.com/coreos/coreos-installer/pull/222.
OK, rebased this now and added a test! But there's an unrelated regression in libdnf: https://github.com/rpm-software-management/libdnf/pull/946 (should be an easy review!).
OK, this is ready to go now!
> symbol lookup error: /home/jenkins/agent/workspace/i_coreos_rpm-ostree_PR-2059-ZZV5BSNPBI7KHN6TOD4VPII6AMCVRJEJ5SWWOOQV6BF6COOJMIQQ/packaging/rpm-ostree-2020.1.89.g430653d1/.libs/librpmostree-1.so.1: undefined symbol: hy_goal_favor Hmm, weird. Not sure why it's not seeing it even though it seems like it is checking out and building the right...
Still no idea what's going on with this, but you're right it's related to our old friend `g-ir-scanner`. I haven't been able to reproduce this locally. Will dig in some...