Re: [DNG] Announcing Devuan 4.0: Chimaera!
2021-10-21 10:22 Larry De Coste via Dng: > I too have a Nvidia GeForce 210 [GT218] that only reaches 70Hz with > the 340xx driver. The issue is the kernel. No kernels beyond 5.4 > support the 340xx driver natively. Some techies on EndeavourOS > found a way to do it with some kernels using Aur adaptions with > NVIDIA-Linux-x86_64-340.108.run. > > I haven succeeded yet with Devuan 4.0. So stuck with nouveau's > provided 60Hz. (: I have it working on chimaera after patching the NVIDIA installer with patches from arch: https://aur.archlinux.org/packages/nvidia-340xx/ Run The NVIDIA installer with --extract-only and apply the 000*-kernel-5.* patches, then run nvidia-installer from the extracted directory. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Announcing Devuan 4.0: Chimaera!
On Sat, 16 Oct 2021 20:01:06 +1100 Tom wrote among other things: |One thing that I couldn’t find in the Debian Bullseye release notes |is that the Nvidia 340xx legacy driver is no longer present in |Debian Bullseye/Devuan Chimaera. | |For anyone with older hardware only supported by the 340xx driver |the alternatives appear to be switching to nouveau driver on |Chimaera or stay on Beowulf with 340xx driver. | I too have a Nvidia GeForce 210 [GT218] that only reaches 70Hz with the 340xx driver. The issue is the kernel. No kernels beyond 5.4 support the 340xx driver natively. Some techies on EndeavourOS found a way to do it with some kernels using Aur adaptions with NVIDIA-Linux-x86_64-340.108.run. I haven succeeded yet with Devuan 4.0. So stuck with nouveau's provided 60Hz. (: -- Larry De Coste Pawtucket RI EE.UU. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi wirelessduck,
wirelessd...@gmail.com writes:
>> On 21 Oct 2021, at 22:47, Olaf Meeuwissen wrote:
>>
>> Hi wirelessduck,
>>
>> wirelessduck--- via Dng writes:
>>
> On 20 Oct 2021, at 20:45, Olaf Meeuwissen via Dng
> wrote:
I really looked into snapshotting but the etckeeper commit messages also
list which packages changed, like so (after I "beautified" the logging a
bit to suit my taste and needs)
commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
Author: olaf
Date: Mon Oct 11 21:48:25 2021 +0900
Committing changes in /etc after APT run
Package changes:
- debconf 1.5.71 all
+ debconf 1.5.71+deb10u1 all
- libgssapi-krb5-2 1.17-3+deb10u2 amd64
+ libgssapi-krb5-2 1.17-3+deb10u3 amd64
- libk5crypto3 1.17-3+deb10u2 amd64
+ libk5crypto3 1.17-3+deb10u3 amd64
- libkrb5-3 1.17-3+deb10u2 amd64
+ libkrb5-3 1.17-3+deb10u3 amd64
- libkrb5support0 1.17-3+deb10u2 amd64
+ libkrb5support0 1.17-3+deb10u3 amd64
- libmariadb3 1:10.3.29-0+deb10u1 amd64
+ libmariadb3 1:10.3.31-0+deb10u1 amd64
which gives me a chance to pinpoint any culprits and submit bug reports
if necessary with detailed info on the changed packages.
>>>
>>> Is this formatting configured in etckeeper or gitconfig? I would like
>>> to try and replicate. It looks very useful.
>>
>> TL;DR: in etckeeper.
>>
>> The etckeeper utility does a good job of collecting the package changes
>> out-of-the-box but the exact output is slightly different from what I
>> included above. The out-of-the-box behaviour includes the output of
>>
>> diff -U0 $before $after | egrep '^[-+]'
>>
>> where $before and $after are "files" with the output of
>>
>> dpkg-query -W -f '${Status}\t${Package} ${Version}\n' | \
>> egrep '(ok installed|ok config-files)' | cut -f2,3
>>
>> I've tweaked that a bit to insert a space after the '^[-+]' and run the
>> diff output through `sort -k2` so I get the before and after package
>> info closer together. I've also made a few very minor changes to start
>> the message with a capital and capitalized APT.
>>
>> Without my changes, the above would have looked something like
>>
>> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
>> Author: olaf
>> Date: Mon Oct 11 21:48:25 2021 +0900
>>
>> committing changes in /etc after apt run
>>
>> Package changes:
>> -debconf 1.5.71 all
>> +debconf 1.5.71+deb10u1 all
>> -libgssapi-krb5-2 1.17-3+deb10u2 amd64
>> +libgssapi-krb5-2 1.17-3+deb10u3 amd64
>> -libk5crypto3 1.17-3+deb10u2 amd64
>> -libkrb5-3 1.17-3+deb10u2 amd64
>> -libkrb5support0 1.17-3+deb10u2 amd64
>> +libk5crypto3 1.17-3+deb10u3 amd64
>> +libkrb5-3 1.17-3+deb10u3 amd64
>> +libkrb5support0 1.17-3+deb10u3 amd64
>> -libmariadb3 1:10.3.29-0+deb10u1 amd64
>> +libmariadb3 1:10.3.31-0+deb10u1 amd64
>>
>> BTW, the version in chimaera (and later) also includes a section that
>> lists the packages with configuration changes and includes the command
>> line invocation that triggered the changes.
>>
>> Oh, I've also made a few changes to record package changes if nothing
>> below /etc has changed.
>>
>> Hope this helps,
>
> Many thanks.
>
> I think the piping to sort alone is good enough that it should be
> implemented upstream. I wonder if there is any special ordering to the
> original non-sorted output as I can’t now see why you would want it
> unsorted?
The piping to sort relies on inserting a space. Without the space,
you'd be sorting on package version numbers, doh!, but yes, trying to
get this included upstream might be a good idea.
# `dpkg-query -W` already sorts on package name. It's just that diff
# only looks at what it gets. The `sort` I added is after the egrep.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
On Thu, Oct 21, 2021 at 6:47 AM Olaf Meeuwissen via Dng
wrote:
> Hi wirelessduck,
>
> wirelessduck--- via Dng writes:
>
> >> On 20 Oct 2021, at 20:45, Olaf Meeuwissen via Dng
> wrote:
> >>
> >> I really looked into snapshotting but the etckeeper commit messages also
> >> list which packages changed, like so (after I "beautified" the logging a
> >> bit to suit my taste and needs)
> >>
> >> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
> >> Author: olaf
> >> Date: Mon Oct 11 21:48:25 2021 +0900
> >>
> >> Committing changes in /etc after APT run
> >>
> >> Package changes:
> >> - debconf 1.5.71 all
> >> + debconf 1.5.71+deb10u1 all
> >> - libgssapi-krb5-2 1.17-3+deb10u2 amd64
> >> + libgssapi-krb5-2 1.17-3+deb10u3 amd64
> >> - libk5crypto3 1.17-3+deb10u2 amd64
> >> + libk5crypto3 1.17-3+deb10u3 amd64
> >> - libkrb5-3 1.17-3+deb10u2 amd64
> >> + libkrb5-3 1.17-3+deb10u3 amd64
> >> - libkrb5support0 1.17-3+deb10u2 amd64
> >> + libkrb5support0 1.17-3+deb10u3 amd64
> >> - libmariadb3 1:10.3.29-0+deb10u1 amd64
> >> + libmariadb3 1:10.3.31-0+deb10u1 amd64
> >>
> >> which gives me a chance to pinpoint any culprits and submit bug reports
> >> if necessary with detailed info on the changed packages.
> >
> > Is this formatting configured in etckeeper or gitconfig? I would like
> > to try and replicate. It looks very useful.
>
> TL;DR: in etckeeper.
>
> The etckeeper utility does a good job of collecting the package changes
> out-of-the-box but the exact output is slightly different from what I
> included above. The out-of-the-box behaviour includes the output of
>
> diff -U0 $before $after | egrep '^[-+]'
>
> where $before and $after are "files" with the output of
>
> dpkg-query -W -f '${Status}\t${Package} ${Version}\n' | \
> egrep '(ok installed|ok config-files)' | cut -f2,3
>
> I've tweaked that a bit to insert a space after the '^[-+]' and run the
> diff output through `sort -k2` so I get the before and after package
> info closer together. I've also made a few very minor changes to start
> the message with a capital and capitalized APT.
>
> Without my changes, the above would have looked something like
>
> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
> Author: olaf
> Date: Mon Oct 11 21:48:25 2021 +0900
>
> committing changes in /etc after apt run
>
> Package changes:
> -debconf 1.5.71 all
> +debconf 1.5.71+deb10u1 all
> -libgssapi-krb5-2 1.17-3+deb10u2 amd64
> +libgssapi-krb5-2 1.17-3+deb10u3 amd64
> -libk5crypto3 1.17-3+deb10u2 amd64
> -libkrb5-3 1.17-3+deb10u2 amd64
> -libkrb5support0 1.17-3+deb10u2 amd64
> +libk5crypto3 1.17-3+deb10u3 amd64
> +libkrb5-3 1.17-3+deb10u3 amd64
> +libkrb5support0 1.17-3+deb10u3 amd64
> -libmariadb3 1:10.3.29-0+deb10u1 amd64
> +libmariadb3 1:10.3.31-0+deb10u1 amd64
>
> BTW, the version in chimaera (and later) also includes a section that
> lists the packages with configuration changes and includes the command
> line invocation that triggered the changes.
>
> Oh, I've also made a few changes to record package changes if nothing
> below /etc has changed.
>
> Hope this helps,
>
Mr Olaf
(and the rest of devuan land)
I found apt-cacher-ng to be a useful tool in tracking updates and in
minimizing my bandwidth.
Would apt-cacher-ng work with etckeeper?
Suggestions please.
TIA
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Er, Not that way ? (was: Announcing Devuan 4.0: Chimaera!)
Hi spiralofhope, spiralofhope writes: > On Mon, 18 Oct 2021 18:52:05 +0900 > Olaf Meeuwissen via Dng wrote: > >> Might I suggest $HOME/bin :-) > > For me I've only had a few offline custom scripts in: > > $HOME/live/path > > If I thought about it further, I'd probably make it something more > obvious, like: > > $HOME/live/scripts/sh/in-path Hmm, I for one wouldn't call that more obvious :-) > Since I share (on GitHub), a crazy large number are in: > > /live/OS/shell-random/git/live/sh/scripts > /live/OS/shell-random/git/live/zsh/scripts > > I use live/zombie/dead because I use terms from tabletop roleplaying > necromancy to help visualize my data. If that helps you, fine. I'm not into that so organizing things that way would confuse the hell out of me. >> It's been 20+ years since "last century" ... > > I felt that. :( I didn't mean to imply people having grown old, just their ways of doing and/or organizing things. FWIW, I spent the larger half of my life in the last century (as of writing at least). Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Steve Litt writes: > Olaf Meeuwissen said on Mon, 18 Oct 2021 18:52:05 +0900 > >>Hi Steve, >> >>Steve Litt writes: > >>> On more thing. When *I* write a program, I never put it in /usr/bin >>> or /usr/local/bin or /opt. I have my own directory, called /d/bats >>> (last century it was called D:\BATS when I used Windows), to contain >>> all executables > > [snip] > >>Might I suggest $HOME/bin :-) > > ~/bin isn't ideal for two reasons: > > 1) It's integrated with all sorts of config, cache, and who knows what, >and can easily be lost or wiped out in a re-installation. In the case of $HOME/bin getting lost or wiped out in a re-installation I'd argue you have bigger problems than just losing $HOME/bin. You have most likely lost all of your $HOME, and maybe even other users' $HOME as well. Personally, I haven found it being "integrated with all sorts of config, cache and who knows what". Yes, if $HOME/bin is in my $PATH, that may affect some programs. In that case, it's a bug of my own making and I can fix it by removing $HOME/bin from my $PATH or renaming whatever program in $HOME/bin causes the trouble. FTR, most of my $HOME/bin consists of scripts or stuff that you might want to install in /usr/local/bin or /usr/local/sbin. In addition, I tend to choose script names carefully so as to not collide with things that are in the default $PATH. My $HOME/bin/emacs is an exception ;-) > 2) On a *personal* computer, a place to store all self developed data >is needed. On a *personal* computer, my *personal* directory is $HOME. $HOME/bin is therefore my *personal* collection of (self developed) programs. > I have nothing against the standard File Hierarchy System (FHS) for > servers. It works, it's stood the test of time for 40 years, and it's > standard. ACK. > How different things are on a *personal* computer. On a server, it's > all about the computer (virtual or metal), and the user is incidental. > On the personal computer, it's all about the user, and the computer is > incidental. > > On a server, it's just fine (sort of) to store all locally developed > and/or used data, config and executables under /usr/local. But on a > personal computer I sure wouldn't want to store my stuff in a directory > owned by root, or under a directory owned by root. I want it in a > directory fully navagable by slitt all the way down. Eh, isn't that what $HOME is all about? Giving you a place of your own, fully navigable and controllable by $USER (or $LOGNAME in case you're running from `cron` ;-). From what you write it sounds as if `root` owns your $HOME. That'd be really unusual because user accounts, by default, get a dedicated $HOME directory, owned by that user. You'd have to bend over backward to get the Devuan installer or `adduser` to do something else. olaf@quark:~$ echo $USER olaf olaf@quark:~$ ls -ld $HOME drwxr-xr-x 1 olaf olaf 1686 Oct 21 18:37 /home/olaf > So isn't that what /home/slitt is for? Not really. /home/slitt is a > huge, disorganized mess with data, config, cache, and all sorts of > other stuff. Ah! So the problem is really one of *personal* hygiene ;-P # Not saying I'm squeaky clean myself, mind you! > /home/slitt gets destroyed in every clean install, If "clean install" means wiping the partition table, then yes, same here (`sed 's/slitt/olaf/') but there are occasions where I don't do that and preserve the partition that holds `dirname $HOME` and remount it there. Especially when the machine caters to other users as well. > so I have a choice: > > 1) Do a mass copy of the old /home/slitt tree to the new one, and >probably mess up programs whose config system has changed. What's wrong with fixing issues as they are discovered? I haven't really run into many issues myself in the course of close to two decades. Some programs update their configuration files for you when they discover a version change, others only need a minor tweak. > 2) One by one search the tree for non-config files that are made by >Steve Litt. That this is time consuming is an annoyance. That it's >error prone is very, very bad. You could track your hand-crafted files elsewhere and copy from there (or symlink to it). Personally, I use vcsh in combination with myrepos to version control sets of configuration files. This lets me share my configuration tweak across machines and activate only those sets I need on a particular machine. > There's also the matter of backup. Do I really want to back up 40,000 > files worth of cache to back up my home grown data? Not this iteration > of Steve Litt. olaf@quark:~$ find -type f | wc -l 239613 olaf@quark:~$ find .cache/ -type f | wc -l 28202 # if I look harder I can bump this to ~32,000 I don't know what you use as your backup solution but I have found rsync in combination with .rsync-filter files to exclude stuff a quite decent solution for my $HOME. That is, after you get your .rsync-filter files in shape but
Re: [DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
> On 21 Oct 2021, at 22:47, Olaf Meeuwissen wrote:
>
> Hi wirelessduck,
>
> wirelessduck--- via Dng writes:
>
On 20 Oct 2021, at 20:45, Olaf Meeuwissen via Dng
wrote:
>>>
>>> I really looked into snapshotting but the etckeeper commit messages also
>>> list which packages changed, like so (after I "beautified" the logging a
>>> bit to suit my taste and needs)
>>>
>>> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
>>> Author: olaf
>>> Date: Mon Oct 11 21:48:25 2021 +0900
>>>
>>> Committing changes in /etc after APT run
>>>
>>> Package changes:
>>> - debconf 1.5.71 all
>>> + debconf 1.5.71+deb10u1 all
>>> - libgssapi-krb5-2 1.17-3+deb10u2 amd64
>>> + libgssapi-krb5-2 1.17-3+deb10u3 amd64
>>> - libk5crypto3 1.17-3+deb10u2 amd64
>>> + libk5crypto3 1.17-3+deb10u3 amd64
>>> - libkrb5-3 1.17-3+deb10u2 amd64
>>> + libkrb5-3 1.17-3+deb10u3 amd64
>>> - libkrb5support0 1.17-3+deb10u2 amd64
>>> + libkrb5support0 1.17-3+deb10u3 amd64
>>> - libmariadb3 1:10.3.29-0+deb10u1 amd64
>>> + libmariadb3 1:10.3.31-0+deb10u1 amd64
>>>
>>> which gives me a chance to pinpoint any culprits and submit bug reports
>>> if necessary with detailed info on the changed packages.
>>
>> Is this formatting configured in etckeeper or gitconfig? I would like
>> to try and replicate. It looks very useful.
>
> TL;DR: in etckeeper.
>
> The etckeeper utility does a good job of collecting the package changes
> out-of-the-box but the exact output is slightly different from what I
> included above. The out-of-the-box behaviour includes the output of
>
> diff -U0 $before $after | egrep '^[-+]'
>
> where $before and $after are "files" with the output of
>
> dpkg-query -W -f '${Status}\t${Package} ${Version}\n' | \
> egrep '(ok installed|ok config-files)' | cut -f2,3
>
> I've tweaked that a bit to insert a space after the '^[-+]' and run the
> diff output through `sort -k2` so I get the before and after package
> info closer together. I've also made a few very minor changes to start
> the message with a capital and capitalized APT.
>
> Without my changes, the above would have looked something like
>
> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
> Author: olaf
> Date: Mon Oct 11 21:48:25 2021 +0900
>
> committing changes in /etc after apt run
>
> Package changes:
> -debconf 1.5.71 all
> +debconf 1.5.71+deb10u1 all
> -libgssapi-krb5-2 1.17-3+deb10u2 amd64
> +libgssapi-krb5-2 1.17-3+deb10u3 amd64
> -libk5crypto3 1.17-3+deb10u2 amd64
> -libkrb5-3 1.17-3+deb10u2 amd64
> -libkrb5support0 1.17-3+deb10u2 amd64
> +libk5crypto3 1.17-3+deb10u3 amd64
> +libkrb5-3 1.17-3+deb10u3 amd64
> +libkrb5support0 1.17-3+deb10u3 amd64
> -libmariadb3 1:10.3.29-0+deb10u1 amd64
> +libmariadb3 1:10.3.31-0+deb10u1 amd64
>
> BTW, the version in chimaera (and later) also includes a section that
> lists the packages with configuration changes and includes the command
> line invocation that triggered the changes.
>
> Oh, I've also made a few changes to record package changes if nothing
> below /etc has changed.
>
> Hope this helps,
> --
> Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
> GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
> Support Free Softwarehttps://my.fsf.org/donate
> Join the Free Software Foundation https://my.fsf.org/join
Many thanks.
I think the piping to sort alone is good enough that it should be implemented
upstream. I wonder if there is any special ordering to the original non-sorted
output as I can’t now see why you would want it unsorted?
--
Tom
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] etckeeper: was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Hi wirelessduck,
wirelessduck--- via Dng writes:
>> On 20 Oct 2021, at 20:45, Olaf Meeuwissen via Dng wrote:
>>
>> I really looked into snapshotting but the etckeeper commit messages also
>> list which packages changed, like so (after I "beautified" the logging a
>> bit to suit my taste and needs)
>>
>> commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
>> Author: olaf
>> Date: Mon Oct 11 21:48:25 2021 +0900
>>
>> Committing changes in /etc after APT run
>>
>> Package changes:
>> - debconf 1.5.71 all
>> + debconf 1.5.71+deb10u1 all
>> - libgssapi-krb5-2 1.17-3+deb10u2 amd64
>> + libgssapi-krb5-2 1.17-3+deb10u3 amd64
>> - libk5crypto3 1.17-3+deb10u2 amd64
>> + libk5crypto3 1.17-3+deb10u3 amd64
>> - libkrb5-3 1.17-3+deb10u2 amd64
>> + libkrb5-3 1.17-3+deb10u3 amd64
>> - libkrb5support0 1.17-3+deb10u2 amd64
>> + libkrb5support0 1.17-3+deb10u3 amd64
>> - libmariadb3 1:10.3.29-0+deb10u1 amd64
>> + libmariadb3 1:10.3.31-0+deb10u1 amd64
>>
>> which gives me a chance to pinpoint any culprits and submit bug reports
>> if necessary with detailed info on the changed packages.
>
> Is this formatting configured in etckeeper or gitconfig? I would like
> to try and replicate. It looks very useful.
TL;DR: in etckeeper.
The etckeeper utility does a good job of collecting the package changes
out-of-the-box but the exact output is slightly different from what I
included above. The out-of-the-box behaviour includes the output of
diff -U0 $before $after | egrep '^[-+]'
where $before and $after are "files" with the output of
dpkg-query -W -f '${Status}\t${Package} ${Version}\n' | \
egrep '(ok installed|ok config-files)' | cut -f2,3
I've tweaked that a bit to insert a space after the '^[-+]' and run the
diff output through `sort -k2` so I get the before and after package
info closer together. I've also made a few very minor changes to start
the message with a capital and capitalized APT.
Without my changes, the above would have looked something like
commit dd9602a525e590f24ec19904248938e6ab76e999 (HEAD -> master)
Author: olaf
Date: Mon Oct 11 21:48:25 2021 +0900
committing changes in /etc after apt run
Package changes:
-debconf 1.5.71 all
+debconf 1.5.71+deb10u1 all
-libgssapi-krb5-2 1.17-3+deb10u2 amd64
+libgssapi-krb5-2 1.17-3+deb10u3 amd64
-libk5crypto3 1.17-3+deb10u2 amd64
-libkrb5-3 1.17-3+deb10u2 amd64
-libkrb5support0 1.17-3+deb10u2 amd64
+libk5crypto3 1.17-3+deb10u3 amd64
+libkrb5-3 1.17-3+deb10u3 amd64
+libkrb5support0 1.17-3+deb10u3 amd64
-libmariadb3 1:10.3.29-0+deb10u1 amd64
+libmariadb3 1:10.3.31-0+deb10u1 amd64
BTW, the version in chimaera (and later) also includes a section that
lists the packages with configuration changes and includes the command
line invocation that triggered the changes.
Oh, I've also made a few changes to record package changes if nothing
below /etc has changed.
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
