Rust 1.50.0 incorporated a Cargo change (rust-lang/cargo#8937) in
which cargo vendor erroneously changed permissions of vendored
crates. This was fixed in Rust
1.51.0 (rust-lang/cargo#9131). Unfortunately, this means that all
cargoSha256/cargoHashes produced during the Rust 1.50.0 cycle are
potentially broken.
This change updates cargoSha256/cargoHash tree-wide.
Fixes#121994.
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Reverted https://github.com/NixOS/nixpkgs/pull/115228 for kodi to avoid conflict.
It does not look like unzip would be used but not investigating now to speed up merge conflict resolution.
fcitx contains functionality to execute xmodmap when changing the
layout, which triggers if ~/.Xmodmap is present. However, this breaks
if xmodmap isn't present in fcitx's PATH.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
* format the expression and reorder to canonical order
* gobject-introspection is used for setup hooks so it should be in native inputs
* wrapPython is not necessary
* 1.5.11 switched from intltool to gettext
* We need PyGObject since it is not propagated by ibus anymore.
* With python.withPackage, we no longer need wrapPython.
* We need wrapGAppsHook still, to find GSettings schemas.
This fixes:
FAILED: obj/engine/engine.engine.o
clang++ -MMD -MF obj/engine/engine.engine.o.d -DOS_LINUX -DMOZC_BUILD -DCHANNEL_DEV -DENABLE_GTK_RENDERER -DNDEBUG -DQT_NO_DEBUG -DNO_LOGGING -DIGNORE_HELP_FLAG -DIGNORE_INVALID_FLAG -I/build/source/src -Igen -Igen/proto_out -Wall -Wno-char-subscripts -Wno-sign-compare -Wno-deprecated-declarations -Wwrite-strings -fPIC -fno-exceptions -fmessage-length=0 -fno-strict-aliasing -funsigned-char -include base/namespace.h -pipe -pthread -fno-omit-frame-pointer -fstack-protector --param=ssp-buffer-size=4 -Wtype-limits -O2 -Wno-deprecated -Wno-covered-switch-default -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=gnu++0x -std=gnu++0x -c ../../engine/engine.cc -o obj/engine/engine.engine.o
In file included from ../../engine/engine.cc:30:
In file included from /build/source/src/engine/engine.h:33:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/memory:62:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:66:
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:183:2: error: cannot decrement value of type 'mozc::ZeroQueryDict::iterator'
--__i;
^ ~~~
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:206:12: note: in instantiation of function template specialization 'std::__advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::__advance(__i, __d, std::__iterator_category(__i));
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2137:9: note: in instantiation of function template specialization 'std::advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::advance(__middle, __half);
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2190:19: note: in instantiation of function template specialization 'std::__equal_range<mozc::ZeroQueryDict::iterator, unsigned long, __gnu_cxx::__ops::_Iter_less_val, __gnu_cxx::__ops::_Val_less_iter>' requested here
return std::__equal_range(__first, __last, __val,
^
/build/source/src/prediction/zero_query_dict.h:213:17: note: in instantiation of function template specialization 'std::equal_range<mozc::ZeroQueryDict::iterator, unsigned long>' requested here
return std::equal_range(begin(), end(), iter.index());
^
1 error generated.
This fixes:
FAILED: obj/engine/engine.engine.o
clang++ -MMD -MF obj/engine/engine.engine.o.d -DOS_LINUX -DMOZC_BUILD -DCHANNEL_DEV -DENABLE_GTK_RENDERER -DNDEBUG -DQT_NO_DEBUG -DNO_LOGGING -DIGNORE_HELP_FLAG -DIGNORE_INVALID_FLAG -I/build/source/src -Igen -Igen/proto_out -Wall -Wno-char-subscripts -Wno-sign-compare -Wno-deprecated-declarations -Wwrite-strings -Wno-unknown-warning-option -Wno-inconsistent-missing-override -fPIC -fno-exceptions -fmessage-length=0 -fno-strict-aliasing -funsigned-char -pipe -pthread -fno-omit-frame-pointer -fstack-protector --param=ssp-buffer-size=4 -Wtype-limits -O2 -Wno-deprecated -Wno-covered-switch-default -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=gnu++0x -std=gnu++0x -c ../../engine/engine.cc -o obj/engine/engine.engine.o
In file included from ../../engine/engine.cc:30:
In file included from /build/source/src/engine/engine.h:33:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/memory:62:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:66:
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:183:2: error: cannot decrement value of type 'mozc::ZeroQueryDict::iterator'
--__i;
^ ~~~
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:206:12: note: in instantiation of function template specialization 'std::__advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::__advance(__i, __d, std::__iterator_category(__i));
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2137:9: note: in instantiation of function template specialization 'std::advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::advance(__middle, __half);
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2190:19: note: in instantiation of function template specialization 'std::__equal_range<mozc::ZeroQueryDict::iterator, unsigned long, __gnu_cxx::__ops::_Iter_less_val, __gnu_cxx::__ops::_Val_less_iter>' requested here
return std::__equal_range(__first, __last, __val,
^
/build/source/src/prediction/zero_query_dict.h:213:17: note: in instantiation of function template specialization 'std::equal_range<mozc::ZeroQueryDict::iterator, unsigned long>' requested here
return std::equal_range(begin(), end(), iter.index());
^
1 error generated.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299