--- Log opened Mon Nov 30 00:00:31 2020
00:41 -!- step_ [uid472302@gateway/web/irccloud.com/x-njtvgadxnqgdveft] has joined #lnp-bp
00:50 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-ikmgodggpbyfhqhv] has joined #lnp-bp
01:33 -!- dieeasy [uid472335@gateway/web/irccloud.com/x-hhvjhsmneymkaqzg] has joined #lnp-bp
03:22 < dr-orlovsky> Hi! Something really strange happens with builds. LNP/BP Core builds are failing on my local machines, both Mac OS and Ubuntu, and `cargo clear/update && rm -rf target` does not help. At the same time CI succeeds. Builds are done with `--all-features` flags
03:23 < dr-orlovsky> Failures are related to the fact that the system does not see `serde_with` crate reporting things like
03:23 < dr-orlovsky> error: Unknown field: `as`
03:23 < dr-orlovsky>    --> src/bp/bip32.rs:225:40
03:23 < dr-orlovsky>     |
03:23 < dr-orlovsky> 225 | #[cfg_attr(feature = "serde", serde_as(as = "DisplayFromStr"))]
03:23 < dr-orlovsky>     |                                        ^^
03:24 < dr-orlovsky> again, I am using `--all-features` and serde/serde_with crates are clearly there + CI builds the same thing w/o any problems. The changes in the failure lines were checked with `git blame` and were introduced many versions ago...
03:25 < dr-orlovsky> Does anyone experience(d) something similar? rah_149, zoe_, step_, dieeasy?
03:26 < dr-orlovsky> I was trying to sort and deal with all build issues for all crates altogether and went into this odd behavior. Already spent like two hours trying different things - nothing works
03:32  * zoe_ you may be experiencing problems related with cache. could you clean your `~/.cargo` directory? also a `rustup update` could be useful, sometimes I've solved building problems by giving this command (no sense for me, but it happened.  when I'll have time I'd like to dig more on how rust/cargo/rustup work in detail)
03:39 < dieeasy> faced many issues building `rust-lnpbp` both locally and in CI, have to admit it's not a clear nor consistent process and I had to wrestle with `Cargo.toml` a lot to find a configuration that works for linux/windows/mac/android/ios at the same time, so at least I'm happy CI is giving a working reference :`)
03:39 < dieeasy> locally, I also had to run `cargo clean` or remove `~/.cargo` to drop the cache
03:39 < dieeasy> also, running `cargo update` has been one of the main source of headaches for me, especially lately, when I had to bisect changes to `Cargo.lock` (not .toml) in order to reverse-engineer what I needed in Cargo.toml to have the project build (commit `e00c5751fa69b6ea5b52e794690b7d3a081f1354`)... so you could try reverting to the committed Cargo.lock and see if that works, if it makes sense in your context
03:43  * zoe_ also, a thing that may be not clear to everyone: `cargo build` uses deps locked in `Cargo.lock` but `cargo install` always tries to update deps, so, when using that, you can add `--locked` and/or `--frozen` to assure you're using the deps defined in the lock file and therefore to have the same behavior of `cargo build`
03:48 < raj_149> Maybe just delete and re-clone the git repo and start from scratch? Just throwing in options as I haven't encountered this issue before. Core is building fine at master in my local.
03:52 < dr-orlovsky> Thanks for the suggestions, tried all of them before, now `rm -rf ~/.cargo`, nothing works :(
03:53 < dr-orlovsky> dieeasy: Cargo system is painful, I heard lot of complains from Andrew Poelstra on it before from his multiple year eperience of managing rust-bitcoin; now witnessing all of them myself...
03:55 < dieeasy> > you can add `--locked` and/or `--frozen` to assure you're using the deps defined in the lock file
03:55 < dieeasy> that's also what I read from the docs (https://doc.rust-lang.org/cargo/commands/cargo-install.html) but the definition under "Manifest Options" contradicts what's in the "DESCRIPTION" paragraph, so I'm not sure cargo is doing what I think it is
03:55 < dieeasy> also, the docs for the `build` command only have `--locked` in the "Manifest Options" section, while the install also has what looks like a more specific definition in "DESCRIPTION" and is also under the "4.4 Package Commands" group so I kind of see it as a mistake in install's page... if you also feel there's a bug in the doc I can try to clarify that and eventually open an issue if needed
03:55 < dieeasy> if anyone is 100% certain about cargo behavior with respect to Cargo.lock, especially at check/build and install time, please feel free to share ;)
03:57 < dr-orlovsky> I am 100% uncertain
04:03 < dr-orlovsky> now this happens on CI as well: https://github.com/LNP-BP/rust-lnpbp/pull/154/checks?check_run_id=1473653936
04:04 < dr-orlovsky> seems like your local builds succeed just because you have older cache. Something got broken in serde_with few days ago I think
04:08 < dieeasy> that's a new error to me, I can only say CI (finally) built fine last time I touched itI can double check your results locally if you feel that would help
04:09 < dieeasy> s/itI/it; I/ (slipped on Enter key)
04:44 -!- marenkar [~marenkar@51.154.28.156] has joined #lnp-bp
04:44 < marenkar> Hello
07:06 < dr-orlovsky> I have found the reason: it's `serde_with_macros` crate which was updated from 1.2.2. to 1.3.0. We do not use it directly, but it's used by serde_with, which allows minor updates and this update is a buggy one. So each time you do cargo update on master you will get the same error
07:14 < dieeasy> shall we lock updates to patch versions only for packages causing trouble, leaving minors out? e.g. with ~1.2.2 it should update to the latest 1.2.x but avoid 1.3+
07:14 < dieeasy> of course this means having to manually update Cargo.toml files manually to receive the minor updates but it could be less of a hassle than dealing with broken updates if that happens a lot (I don't have a track record so don't know if this is an outlier or the norm)
07:59 -!- olga__ [uid458260@gateway/web/irccloud.com/x-zsnpqcrmpdxzhulk] has joined #lnp-bp
08:16 < step_> In RGB-node, as for 0.2.0-beta.3, contract-id is handled with mixed encoding: bech32 in the fungible subcommand and hex in genesis subcommand.  The hex format seems to be an older version, as stated here https://github.com/LNP-BP/rgb-sdk/pull/22#discussion_r524188452.
08:16 < step_> Is there a plan to update the genesis subcommand or will it be dropped completely to be part of the issuance tool?
08:24 < dr-orlovsky> step_: that's true, jut need to change Clap arg to use the proper conversion
08:24 < dr-orlovsky> the tool (https://github.com/pandoracore/bitcoin-pro) will not make RGB cli abandoned, so have to do that anyway
08:29 < step_> sure, but functionality under genesis subcommand seems to me more related to issuance workflow than regular usage. Anyways, I can offer to open an issue and try to look into it in the next days.
08:35 < dr-orlovsky> contract id will be used in the normal workflows as well. I can fix it really quick, but may be someone would like to try to play with the code and this sounds like a good first (or not that first) issue
11:16 < dr-orlovsky> New LNP/BP Core lib and RGB Node versions are released (0.2 Beta 3 and 4). They should solve known issues with previous builds; pls check that
13:58 -!- zoe_ [uid464843@gateway/web/irccloud.com/x-ikmgodggpbyfhqhv] has quit [Quit: Connection closed for inactivity]
14:25 -!- step_ [uid472302@gateway/web/irccloud.com/x-njtvgadxnqgdveft] has quit [Quit: Connection closed for inactivity]
17:54 -!- dieeasy [uid472335@gateway/web/irccloud.com/x-hhvjhsmneymkaqzg] has quit [Quit: Connection closed for inactivity]
--- Log closed Tue Dec 01 00:00:32 2020