[2 in 1] datetime/exa issues

[MagaTailor]

I've managed to compile exa on ARM using rust 1.5 and --no-default-features but first had to fix this by casting to i64:

Compiling datetime v0.4.2
/tmp/.cargo/registry/src/github.com-48ad6e4054423464/datetime-0.4.2/src/system.rs:38:6: 38:15 error: mismatched types:
 expected `i64`,
    found `i32`
(expected i64,
    found i32) [E0308]
/tmp/.cargo/registry/src/github.com-48ad6e4054423464/datetime-0.4.2/src/system.rs:38     (tv.tv_sec, (tv.tv_nsec / 1000) as i16)
                                                                                          ^~~~~~~~~
/tmp/.cargo/registry/src/github.com-48ad6e4054423464/datetime-0.4.2/src/system.rs:38:6: 38:15 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `datetime`.

only to find -l option doesn't work:

$  ~/exa-20160211 -l
thread '<main>' panicked at 'Unable to determine time zone', src/libcore/option.rs:334
stack backtrace:
   1: 0xb6ddf9df - sys::backtrace::tracing::imp::write::h86e39446169e67d0Wnt
   2: 0xb6de2513 - panicking::log_panic::_<closure>::closure.39676
   3: 0xb6de1f47 - panicking::log_panic::h7e0ce1e7485944fbUpx
   4: 0xb6dd1b87 - sys_common::unwind::begin_unwind_inner::h1d39a3f983dfda740gs
   5: 0xb6dd2507 - sys_common::unwind::begin_unwind_fmt::h2f77b9962e7023ac6fs
   6: 0xb6ddf053 - rust_begin_unwind
   7: 0xb6def38f - panicking::panic_fmt::h48301c5acd531c5bZEK
   8: 0xb6d1580b - option::_<impl>::expect::expect::h2570453751442068436
                at src/libcore/macros.rs:28
   9: 0xb6d150bf - output::details::_<impl>::default::h8a8ad7389276de4aFic
                at src/output/details.rs:171
  10: 0xb6d19297 - output::details::_<impl>::view::h4851bbe4ecd53aaakjc
                at src/output/details.rs:191
  11: 0xb6d58303 - _<impl>::print_files::h4dce2bbed8c81fe4ZRe
                at src/main.rs:137
  12: 0xb6d592ab - _<impl>::print_dirs::hd6db41078e88377a1Me
                at src/main.rs:129
  13: 0xb6d572db - _<impl>::run::h8dfb0d815e94decaZJe
                at src/main.rs:77
  14: 0xb6d5a23b - main::ha86e656adc12d327HSe
                at src/main.rs:151

Is it related or maybe 1.5 is already too old?

[MagaTailor]

BTW, I remember remarking about ARM vs x86 binary size a few months ago - why is it so much bigger now on ARM even without git support?

884456   Oct  2 03:16 /home/odroid/exa
674512   Nov  3 20:24 /usr/local/bin/exa
2734920  Feb 11 15:04 /home/odroid/exa-20160211

[ogham]

Hmmm, I'm not sure. I've been adding more and more libraries to exa, and some of them (zoneinfo-data, for example) can get pretty big. I need to make some of them optional again.

[ogham]

Thanks for the backtrace. It checks /etc/localtime to try to determine the time zone; do you have this file?

[ogham]

Wait a minute, I thought I wrote that function to print out an error if it can't figure out which time zone to use, but I guess expect doesn't print out the error case. Let me fix...

[MagaTailor]

Yes, my system is set to local time but it seems the file contains some garbage! Probably the result of power outage and writeback journalling.

[ogham]

OK, I make sure we print out the error (in ogham/exa@252eba4) when it can't determine what the time zone is.

The file in /etc/garbage is a compiled binary file. exa tests if it's a symlink and tries to work out the time zone that way; otherwise, it tries to parse the file; otherwise, it fails with that error.

[MagaTailor]

Ah, ok! Let me try the patch. I'll close if everything is fine again.

[ogham]

👍

[MagaTailor]

What's the situation on the LFS front?

[ogham]

Large File Support? There's current a pull request for it that trades struct fields for accessors that should fix the file size problem.

[MagaTailor]

Wow, a mere 16 hours ago ;)

[MagaTailor]

Did you forget to push the updated crate to crates.io? It looks like it.