| Commit message (Collapse) | Author | Age |
| |
|
|\
| |
| | |
Initial implementation of vc4 cross-compile
|
| | |
|
|\ \
| | |
| | | |
mkcert: 1.4.0 -> 1.4.1
|
| | |
| | |
| | |
| | | |
Co-authored-by: Joh <jonringer@users.noreply.github.com>
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is required to run `travis console` but is not part of the upstream
dependency list. Upstream is also not compatible with pry 0.12+ and
breaks with this error `uninitialized constant Pry::SIMPLE_PROMPT`.
Fixes #73238
|
|\ \ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Alioth is now offline -> https://wiki.debian.org/Salsa/AliothMigration
Sources moved to other forges (Salsa for example)
Some release tarballs are available on alioth-archive.debian.org
|
|\| | |
|
| | | |
|
| |\ \
| | | |
| | | | |
treewide: add missing descriptions & homepages
|
| | | | |
|
| | | | |
|
|\| | | |
|
| |\ \ \
| | | |/
| | |/| |
|
| | | | |
|
| | | | |
|
| | |/ |
|
| |\|
| | |
| | |
| | | |
~4k rebuilds on each Linux.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* argbash: init at 2.8.1
* changed name to pname
* updated sha256 hash
|
| | |\
| | | |
| | | | |
stm32cubemx: init at 5.3.0
|
| | | | |
|
|\| | | |
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* sysbench: 1.0.17 -> 1.0.18 (#72685)
* sysbench: set meta.homepage
+ cleanup build inputs (vim isn't needed since 1.0.12)
+ enable parallel building
|
|\ \ \ \
| |/ / /
|/| | | |
treewide: `set -u` everywhere
|
| | | |
| | | |
| | | |
| | | |
| | | | |
If these aren't defined, the stdenv defaults are used in the `*Phase`
case, or no extra phases are done, in the `*Phases` case.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
automake 1.15 uses a bundled version of help2man from 2012 that
does not support the SOURCE_DATE_EPOCH environment variable.
This means that the build date is included in the generated
documentation, breaking reproducibility.
This changes adds the SOURCE_DATE_EPOCH support from the current
help2man to the version bundled in automake 1.15.
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |/ / |
|
|\| | |
|
| | |
| | |
| | |
| | | |
Changelog: https://github.com/cycloidio/terracognita/releases/tag/v0.2.0
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To get python3 support. #63174 flipped itstool to python3, but itstool
doesn't support python3 until 2.0.3 (and perhaps does not support it
well until 2.0.5).
Pressing forward instead of rolling back at worldofpeace's suggestion,
who mentions that other distros seem to be able to ship recent versions
of itstool.
Tensions in this space seem two-fold. One set centers around libxml2
being a low-level C library with sharp edges, manual memory management,
and performance concerns; the python libxml2 wrapper being quite thin
(the most dubious character in this drama); and python's sentiment that
it ought to be quite hard to crash the interpreter casually. This comes
to a head in https://gitlab.gnome.org/GNOME/libxml2/issues/12 , where a
use-after-free problem in idiomatic-looking python code is declared
working-as-designed.
The other set is around python3 being more UTF-8-aware than libxml2's
python wrapper, such as https://bugzilla.gnome.org/show_bug.cgi?id=789714
and https://src.fedoraproject.org/rpms/libxml2/blob/master/f/libxml2-2.9.8-python3-unicode-errors.patch
itstool is caught in this crossfire merely for being a widely-used
python program that uses XML.
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| | |
Semi-automatic update generated by
https://github.com/ryantm/nixpkgs-update tools. This update was made
based on information from
https://repology.org/metapackage/sccache/versions
|
| |
| |
| |
| |
| |
| |
| | |
Semi-automatic update generated by
https://github.com/ryantm/nixpkgs-update tools. This update was made
based on information from
https://repology.org/metapackage/lttng-tools/versions
|
|\ \ |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
pwndbg is a Python module for gdb. The built-in interpreter is used and
pwndbg offers additional routines. Packaging this is tricky because that
interpreter needs to be used. Using `python3.withPackages` won't work.
By setting `NIX_PYTHONPATH`, the interpreter should pick up pwndbg and
its dependencies.
If `NIX_PYTHONPATH` does not function we can fall back to `PYTHONPATH`.
An example of when that won't work is if pwndbg runs a script of itself
in a subshell. `NIX_PYTHONPATH` would be unset, but `PYTHONPATH` not.
|
|\| | |
|
| |\ \
| | | |
| | | | |
arcanist: 20180916 -> 20190905
|
| | | | |
|
|\| | | |
|
| |\| | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Semi-automatic update generated by
https://github.com/ryantm/nixpkgs-update tools. This update was made
based on information from
https://repology.org/metapackage/swig/versions
|
| | |\ \
| | | |/
| | |/| |
hydra-cli: fix the cargoSha256 hash
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This might be related to the way cargo fetches sources since the old
hash still works on the original PR (before being rebased onto master by
the merge action).
See
- https://github.com/NixOS/nixpkgs/pull/67680
- https://hydra.nixos.org/build/102205464/nixlog/2
|