| Commit message (Collapse) | Author | Age |
|\ |
|
| |\
| | |
| | | |
linux-testing: 5.5-rc2 -> 5.5-rc3
|
| | | |
|
| |\ \
| | | |
| | | | |
iwd: 1.2 -> 1.4
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | |
| | |
| | |
| | | |
https://hydra.nixos.org/build/108688065
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Idea shamelessly stolen from 4e60b0efae56cc8e1a8a606a5a89462c38aba305.
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.
|
| |\ \
| | |/
| |/| |
firmware-linux-nonfree: 2019-10-22 -> 2019-12-15
|
| | | |
|
| |\ \
| | | |
| | | | |
multipath-tools: Fix prefix
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
udev rules and manpages in section 8 were installed into $out/usr
Results in the following derivation output diff:
lib/systemd/system
lib/systemd/system/multipathd.service
lib/systemd/system/multipathd.socket
+lib/udev
+lib/udev/kpartx_id
+lib/udev/rules.d
+lib/udev/rules.d/11-dm-mpath.rules
+lib/udev/rules.d/11-dm-parts.rules
+lib/udev/rules.d/56-multipath.rules
+lib/udev/rules.d/66-kpartx.rules
+lib/udev/rules.d/68-del-part-nodes.rules
sbin
share
share/man
@@ -79,25 +87,14 @@
share/man/man3/mpath_persistent_reserve_out.3.gz
share/man/man5
share/man/man5/multipath.conf.5.gz
+share/man/man8
+share/man/man8/kpartx.8.gz
+share/man/man8/mpathpersist.8.gz
+share/man/man8/multipath.8.gz
+share/man/man8/multipathd.8.gz
usr
usr/include
usr/include/libdmmp
usr/include/libdmmp/libdmmp.h
usr/include/mpath_cmd.h
usr/include/mpath_persist.h
-usr/lib
-usr/lib/udev
-usr/lib/udev/kpartx_id
-usr/lib/udev/rules.d
-usr/lib/udev/rules.d/11-dm-mpath.rules
-usr/lib/udev/rules.d/11-dm-parts.rules
-usr/lib/udev/rules.d/56-multipath.rules
-usr/lib/udev/rules.d/66-kpartx.rules
-usr/lib/udev/rules.d/68-del-part-nodes.rules
-usr/share
-usr/share/man
-usr/share/man/man8
-usr/share/man/man8/kpartx.8.gz
-usr/share/man/man8/mpathpersist.8.gz
-usr/share/man/man8/multipath.8.gz
-usr/share/man/man8/multipathd.8.gz
|
| | |/
| |/| |
|
| | | |
|
| |\ \
| | | |
| | | | |
health-check: 0.03.03 -> 0.03.04
|
| | | | |
|
| |\ \ \
| | | | |
| | | | | |
alfred: 2019.3 -> 2019.5
|
| | |/ / |
|
|\| | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | | |
| | | | | |
sysdig: 0.26.4 -> 0.26.5
|
| | |/ / |
|
| |\ \ \
| | |/ /
| |/| | |
nvidia_x11: 440.36 -> 440.44
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| |\| | |
|
| | |\ \
| | | | |
| | | | | |
fetchFromGitiles: init
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is only the easy cases -- some fetchgit uses that point to
Gitiles instances are in generated code, where the generating code
would have to know in advance if it was fetching from Gitiles or not.
I don't think this is worth it.
|
| |\| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This doesn't actually update the kernel, just the linux-libre
deblobbing scripts, but it should mean that automatic updaters keep
the deblobbing scripts up to date. So even if deblobbing scripts for
a new kernel version are not available immediately after release, they
should be updated automatically soon enough once available.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
update-libre.sh doesn't commit by default so that it can be used as an
updateScript, where I don't think auto-committing is the norm.
The generated commit messages say "linux-libre_latest" rather than
"linux-libre", because even though linux-libre will also be rebuilt,
it's linux-libre_latest that is more likely to need it.
|
| | | | | |
|
| |\| | | |
|
| | | | | |
|