| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This implies the following behavioural changes:
(1) Grub.configured will now change the value set by the first line it
finds that sets the value of its key, if one exists. Previously,
Grub.configured would unconditionally append to /etc/default/grub,
unless the key=value pair was already present.
(2) Grub.configured will comment out any further lines setting the
value of its key found further down the file.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
Code adapted from Grub.configured.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
I think none of the default shortcuts were being used, and I trimmed the
list down
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use git verify-commit to verify gpg signatures, rather than the old method
of parsing git log output.
These two methods should always have the same result. Note that
git verify-commit allows signatures with unknown validity, the same as
git log's "U" output which was accepted. So any key in the gpg keyring
is allowed to sign the commit. Propellor provides gpg with a keyring
containing only the allowed keys.
Needs git 2.0, which is in even debian oldstable.
This commit was sponsored by Ewen McNeill on Patreon.
|
|
now that compatability with ghc 7 is no longer needed.
Data.Type.Bool contains effectively the same stuff that was implemented
here, so removed my code.
Tried to use Data.Type.Equality instead of my EqT, but it seems to be some
other type of (type level) equality, and didn't compile. Instead went with
the simpler EqT implementation that newer ghc versions allow.
The rest of the changes are simply better syntax for defining type
families.
And upon using that syntax, ghc noticed that `type family a + b`
does not have kind "ab" like I wrote before, but is kind *.
Tested on debian stable with ghc 8.0.1.
This commit was sponsored by John Pellman on Patreon.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Apt.installedBackport would do this:
apt-get install -t stretch-backports foo bar
Apt.backportInstalled does this:
apt-get install foo/stretch-backports bar/stretch-backports
The Apt.installedBackport behaviour can install the dependencies of foo and bar
from stretch-backports even when the versions in stretch will satisfy the
dependencies of the backports of foo and bar. So this property can result in
very many more backports being installed on the host when intended. But the
number of installed backports should always be minimised.
Worse, whether this happens is highly dependent on the system state, and the
order in which other properties get ensured. For example,
& Apt.installed ["dgit"]
& Apt.installedBackport ["dgit"]
will install only dgit from stretch-backports, but unless debhelper and
devscripts happen to already be installed,
& Apt.installedBackport ["dgit"]
& Apt.installed ["dgit"]
will install dgit, debhelper, devscripts and maybe more from backports. This is
surprising, difficult to debug, and breaks the expectation that when the order
in which properties are ensured is not specified with connectives like
`requires` and `before`, ensuring them in any order will produce the same
result.
Property renamed because user configs should not silently break, as they would
if they did not list dependencies that must be installed from stable-backports.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
No such backport exists in the archive.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
