| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
* Revert adler32
* Fix checksum
|
|
|
|
|
|
|
|
vauxhall (my laptop) now has an additional screen connected at home,
but sometimes I use that screen for my desktop computer (nugget).
This refactors the randr configuration for EXWM to support somewhat
more dynamic, multi-monitor layouts and adds key bindings to toggle
between some of the different configurations I want.
|
|
These patches enable hardware-accelerated video decoding, which is
useful for Stadia.
The main issue with this is that Hydra doesn't currently cache
Chromium with these patches, which means that it is built from scratch
which takes in the order of 5 hours on an otherwise unused nugget.
|
|
|
|
|
|
Fix padding algorithm for CBC mode
|
|
Due to the lack of a parenthesis, the packets were getting 16 bytes larger than necessary.
|
|
|
|
|
|
The install-multi-user script uses blue, green, and red colors, as
well as bold and underline, to add helpful formatting that helps
structure its rather voluminous output.
Unfortunately, the terminal escape sequences it uses are not quite
well-formed. The relevant information is all there, just obscured
by some extra noise, a leading parameter `38`. Empirically, the
result is:
* On macOS, in both Terminal.app and iTerm2, the spurious `38` is
ignored, the rest of the escape sequence is applied, and the colors
show up as intended.
* On Linux, in at least gnome-terminal and xterm, the spurious `38`
and the next parameter after it are ignored, and what's left is
applied. So in the sequence `38;4;32`, the 4 (underline) is
ignored but the 32 (green) takes effect; in a more typical sequence
like `38;34`, the 34 (blue) is ignored and nothing happens.
These codes are all unchanged since this script's origins as a
Darwin-only script -- so the fact that they work fine in common macOS
terminals goes some way to explain how the bug arose.
Happily, we can make the colors work as intended by just deleting the
extra `38;`. Tested in all four terminals mentioned above; the new
codes work correctly on all of them, and on the two macOS terminals
they work exactly the same as before.
---
In a bit more technical detail -- perhaps more than anyone, me
included, ever wanted to know, but now that I've gone and learned it
I'll write it down anyway :) -- here's what's happening in these codes:
An ECMA-48 "control sequence" begins with `\033[` aka "CSI", contains
any number of parameters as semicolon-separated decimal numbers (plus
sometimes other wrinkles), and ends with a byte from 0x40..0x7e. In
our case, with `m` aka "SGR", "Select Graphic Rendition".
An SGR control sequence `\033[...m` sets colors, fonts, text styles,
etc. In particular a parameter `31` means red, `32` green, `34` blue,
`4` underline, and `0` means reset to normal. Those are all we use.
There is also a `38`. This is used for setting colors too... but it
needs arguments. `38;5;nn` is color nn from a 256-color palette, and
`38;2;rr;gg;bb` has the given RGB values.
There is no meaning defined for `38;1` or `38;34` etc. On seeing a
parameter `38` followed by an unrecognized argument for it, apparently
some implementations (as seen on macOS) discard only the `38` and
others (as seen on Linux) discard the argument too before resuming.
(cherry picked from commit 7313aa267b5be1e5264e4577e7bc3daec2fef282)
|
|
The ssh client is lazily started by the first worker thread, that
requires a ssh connection. To avoid the ssh client to be killed, when
the worker process is stopped, do not set PR_SET_PDEATHSIG.
(cherry picked from commit 3e347220c82d1537723f49aa03a93a6f9d294417)
|
|
(cherry picked from commit d1b238ec3cd74d652af46f577f992c9a44ac8e32)
|
|
If the `throw` is reached, this means that execvp into `ssh` wasn’t
successful. We can hint at a usual problem, which is a missing `ssh`
executable.
Test with:
```
env PATH= ./result/bin/nix-copy-closure --builders '' unusedhost
```
and the bash version with
```
env PATH= ./result/bin/nix-copy-closure --builders '' localhost
```
(cherry picked from commit 38b29fb72ca4a07afbec1fd5067f59ca7d7f0fab)
|
|
(cherry picked from commit 12556e570924315eb25ad6057b6c2c5162955e4f)
Signed-off-by: Domen Kožar <domen@dev.si>
|
|
Includes the expression of the condition in the assertion message if
the assertion failed, making assertions much easier to debug. eg.
error: assertion (withPython -> (python2Packages != null)) failed at pkgs/tools/security/nmap/default.nix:11:1
(cherry picked from commit 307bcb9a8e7a16bfc451e055a620b766df9d3f7d)
Signed-off-by: Domen Kožar <domen@dev.si>
|
|
When encountering an unsupported protocol, there's no need to retry.
Chances are, it won't suddenly be supported between retry attempts;
error instead. Otherwise, you see something like the following:
$ nix-env -i -f git://git@github.com/foo/bar
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 335 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 604 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 1340 ms
warning: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1); retrying in 2685 ms
With this change, you now see:
$ nix-env -i -f git://git@github.com/foo/bar
error: unable to download 'git://git@github.com/foo/bar': Unsupported protocol (1)
(cherry picked from commit c976cb0b8ab5d0f2c4ab8c9826fc7db56e2f1b3e)
Signed-off-by: Domen Kožar <domen@dev.si>
|
|
Hopefully fixes #3278.
(cherry picked from commit 1ab8d6ac1861e9405ae34af3deb681020c03e82d)
Signed-off-by: Domen Kožar <domen@dev.si>
|
|
|
|
* Removed PyCRC as dependency; implemented CRC16 directly
* replace crc16 with integrated function
* Added self to calculate crc
|
|
... how did I not have protobuf-mode installed? What?
|
|
|
|
* Add support for RM4 0x62bc
* Fix device name
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is now part of nixpkgs itself.
|
|
|
|
The queue size setting will drop frames if the encoding starts to lag
behind, which should prevent delay from being introduced on the
serving side.
Maybe.
|
|
This makes it possible to live-stream various things at rtmp://tazj.in/tvl
|
|
This changed due to the router replacement.
|
|
|
|
This kernel module creates a fake video input device to which I can
stream various things, such as screen grabs or qyliss' video stream
for TVL.
|
|
Builds ffmpeg with CUDA Toolkit as a dependency, which includes a
library called "libnpp" that provides something related to hardware
accelerated video stream resizing.
v0v
|
|
By randomly copy & pasting options that are impenetrable to mere
mortals from NVIDIA's developer blog and a bunch of gists scattered
throughout the internet, Andi and I managed to "get this to work".
The idea is that the x11grab stream should be resized into 720p (which
is the maximum supported by Google Meet), but with hardware
acceleration.
|
|
|
|
|
|
|
|
Accidentally dropped a key parameter, also restored interactive
functionality via prefix arguments..
|
|
Modifies notmuch-show-open-or-close-subthread to take a parameter
instead of using prefix to toggle the argument, and binds that
function to C-, and C-. in notmuch-show-mode-map to enable convenient
collapsing/uncollapsing of subthreads from point.
|
|
Does what it says on the tin.
|
|
Setting the GOROOT_FINAL environment variables replaces the absolute
location of the Go standard library sources in the final build
artefacts with a fake location (in this case starting with
go/src/...).
This is despite the documentation for 'trimpath' (in 'go tool
compile') stating that it would affect all source paths: That's only
true for user code!
I figured this out by reading through the implementation of the other
'trimpath' (in 'gob build'):
https://go-review.googlesource.com/c/go/+/173345
|
|
|
