|:: Re: [devuan-dev] Meeting notes 2021…|
|This message is part of the following thread:|
|the complete thread tree sorted by date|
> ### Xenguy > * Now that this area is cleaned up again, it occurs to me to ask: how > should we be using this section of our meeting minutes? > * I assume that 'Old Business' == 'Unfinished Business'? > * (gl) Yes. A short note is sufficient to remind us after it has > been discussed once.~~Your text here~~ > * e.g. In a recent meeting we discussed Tor/Onion links; should we > be rolling that kind of topic over, from meeting to meeting, in this > section? Or is this section to simply remain unused? > * (gl) What was the outcome you desired? Whether to keep it or > not or create a new one? It should have been solved by now if it was > important. I have not seen any recent complaints about Tor so > assume it is a transient issue but I also think I remember > someone mentioning that the tor address format has changed. > * (Xenguy) This may be evidence of my concern: we may have lost > the thread on this topic.
> ### mason > * I'd like to empty out the IRC ban and quiet lists and have them > start fresh. I'd like us to reconsider using one of the systems that > expire bans and quiets automatically after a (per-incident as needed) > settable time. Should be easy to set up, and will give people a > chance to rehabilitate. > * (Xenguy) What would a suitable 'interval' be I wonder? > * (fsr) As I understand the current setup, if anyone places a ban, > that person needs to be the one to remove it. One concern I have > is that with auto-removal, we might be tempted to ban people more > easily, since we don't have to rememeber to remove it.
> ### golinux > * Offer to translate the website in Russian: > https://dev1galaxy.org/viewtopic.php?id=4279 Problem is that the > site is not static so any translation could quickly become stale. > What is the current state of on-the-fly translators? > * tito's [buster-to-beowulf migration > script](https://gitea.devuan.dev/farmatito/migration) is now in > gitea. But there have been no further email updates or reports from > users trying it. Thoughts? > * (Xenguy) More testers are needed generally. Once my Qemu is set > up, I should be able to help with this. See also fsr's comment below > about using tito's script.
> ### rrq (will be very short of time this time) > * chimaera-security is "needed" by installer; doesn't break > installation, but the lack of it attracts a scary red warning > dialog. (chimaera-updates is also expected but lacking it doesn't > gain a warning) > * tried migration buster 10.9 fresh install -> chimaera and it seemed > easy enough though required some persistence to get rid of systemd. > I focused more on getting my un-merge-usr script to work (which really > is something all sensible debian users should deploy) > * (Xenguy) What is the script for? > * (gl) IIUC it is to "un-merge-usr" which happens as default in > Debian. Devuan does not merge them as default. > * (rrq) yes; to undo the file structure destruction that a > debian installation brings, with links like /bin -> usr/bin instead of > "proper" directories for /bin, /sbin, /lib, /lib32, /libx32 > and /lib64, and which thereby merges the content that installs into > those directories; i.e. anything installed to /bin gets > deposited into /usr/bin and so forth respectively.
> ### Xenguy > * **mason**: Confirm whether mason recently used the existing > [buster-to-beowulf](https://www.devuan.org/os/documentation/dev1fanboy/en/buster-to-beowulf) > documentation successfully? > * (fsr) I used v.1.8 of migrate.sh to migrate buster with mate to > beowulf. It was easy, smooth and fast. There were some > instructions at the end for things to do after reboot. I had to look > inside the script after reboot to remember them. It sets pin-priority > to 900. Don't we use 500 as default?
1) place an info.txt file in the user's/root home dir 2) place a stage2.sh script in the user's/root home dir to be run after reboot. Just tell me what is the preferred way, I propend for n.1.