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 th
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