pijul_org / pijul

#89 pijul clone fails

Opened by bradley_hardy, on May 15, 2017
bradley_hardy commented on May 15, 2017

I'm on MacOS, and Pijul was installed with cargo install pijul.

RUST_BACKTRACE=1 pijul clone https://nest.pijul.com/pijul_org/pijul
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError("failed to lookup address information: nodename nor servname provided, or not known") }) }', src/libcore/result.rs:859
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: pijul::commands::remote::Remote::session
  10: pijul::main
  11: std::panicking::try::do_call
  12: __rust_maybe_catch_panic
  13: std::rt::lang_start
joeneeman commented on May 15, 2017

Looks like pijul got caught by a change in the regex crate's behavior. You can get around it by creating an account on the nest and then cloning using ssh. Alternatively, you can clone from my temporary github fork

pmeunier commented on May 16, 2017

I'm glad this is happening on other platforms as well. Since the syntax we were using is still documented in the regex crate documentation, and I was only observing the change on windows (should have cargo updated on linux), I was starting to think a bit too much about how the regex crate was implemented.

This is fixed in version 0.5.10, updated today.

@joeneeman: I'd be interested in hearing of your corruption issues. Is this related to the unsolvable conflicts in pijul/Cargo.lock?

pmeunier commented on May 16, 2017

Also, this is a duplicate of #79, closing now.