Best algorithm for bl-user-setup

johnraff · 2019-10-22 08:18:05

bl-user-setupis a script in bunsen-configs whose main purpose is to populate a new user's HOME with the default BL config files from /usr/share/bunsen/skel. It usually runs once only, then creates ~/.config/bunsen/bl-setup which inhibits any other runs. OK, this works fine for new installations.

With the new config files needed for Lithium, I thought it would be handy if users upgrading from Helium, upgrading an experimental Lithium or installing BL on an existing system via bunsen-meta-all could have just the new files added to their ~/.config, if they don't yet exist. This was done in /usr/bin/bunsenlabs-session, which is run when logging in. The list of files to check and possibly import is quite small so I don't think it slowed down login time at all. OK this also seemed to work OK.

But the other day malm reported that when tweaking jgmenu on a Lithium setup, even if he removed ~/.config/jgmenu/prepend.csv (some users might want to do this to get the standard non-BL jgmenu) the file was being put back again after every login. Of course this was because prepend.csv is one of those new files that get checked and imported by bunsenlabs-session. Hmm... OK let's check if ~/.config/jgmenu/ exists already, and only do the import if the whole directory is missing. That should cover tweakers while still giving new users the files they need.

Then I thought - why do this in bunsenlabs-session if bl-user-setup is doing the same kind of job? OK move the code over to bl-user-setup. But in talking to malm about this we also thought it would be nice if bl-user-setup's --refresh option was interactive, so users could say yes or no to each file that was about to be overwritten. So malm has written an improved bl-user-setup which does that, and adds some other options...

But I'm now thinking, before jumping into a complete rewrite,we might want to take a step back and think about exactly what this script ought to be doing, and when, and then how.

IE

1) Right now it's triggered from a file in /etc/X11/xsession.d so all users starting an X session will run it. Maybe better started from bunsenlabs-session, so on a multi-user system if user B doesn't want BL then as long as they never log into a BunsenLabs session they won't get the config files that user A wants?

2) Current script uses rsync - very fast efficient and powerful. malm's gets the file list with find and processes it with bash - slower but allows more detailed control. Think about such implementation details. cmp vs diff, maybe ignore whitespace? Take into account modification times?

3) Does the script need to overwrite files (current behaviour) or can it just import all skel files only if they don't exist in $HOME? Will any new users need any files rewriting? If that worked the new-files-import might not be needed.

4) OTOH what's the ideal behaviour for users who call 'bl-user-setup --refresh', that is when a package upgrade has come in and they want to get the new settings? If the file list is short, then answering yes/no for each one might be best.

5) Is there a nice generic way to deal with files like the unwanted prepend.csv situation, without having to code in fixes for each new case that turns up? Maybe a new flag file in ~/.config/bunsen to record that the new-file-import has been done, and not do it on every login?

Probably other things, but I just wanted to get this down on "paper".

johnraff · 2019-10-23 08:36:20

USE CASES

1) Default: A newly created user with only the files from /etc/skel (.bash_logout, .bashrc, .profile).
Copy in /usr/share/bunsen/skel/*
Only one file, .profile, needs to be overwritten, so a noclobber import would be fine, with just one special action to backup .profile.
Needs to be done once only, for new user. Controlled by creating ~/.config/bunsen/bl-setup.

2) Manual: User runs 'bl-user-setup --refresh', because config files have changed, or user has messed up stuff in ~/.
Re-do import, but now most/all the files already exist. Right now this is covered by making backups, but malm's script makes it interactive - asking y/n for each file which is different (usually a dozen or so).

Test of whether to overwrite: rsync uses checksums, J's script uses cmp (bit-by-bit comparison), another possibility is diff, with options to ignore space differences, another possibility is to compare modification times.

---
These are less common cases:

3) User following Lithium experimental, but a package upgrade brings improvements they want in ~/.
Main example was when we started using jgmenu, xbindkeys and a BunsenLabs session, which brought in 6 new files.
My first attempt at helping them upgrade was the code in bunsenlabs-session which checked for the 6 files on every login and imported the 6 files if they didn't exist. Hence the unwanted prepend.csv malm got.
Current fix is a special check for jgmenu files, not to import unless the whole ~/.config/jgmenu directory is missing. This works fine, but I'd like to find a general fix that would work for all apps. Below...

4) User is running Helium, but upgrades to Lithium. Almost same as 3), again they'll need some new files. Also, in this case there'll likely be a lot of other files that have changed.

5) Package upgrade changes some default config files.
Right now: post in forum, suggest running 'bl-user-setup --refresh' or check files manually.
Possible cases:
a) User has not changed any files from the default - actually very unlikely because eg Thunar and Geany are always writing in ~/.config, but anyway in this case it might be OK to trigger another import, making backups.
b) User has edited a file (can this be distinguished from an app changing a file?) - they won't want their settings destroyed without permission.
c) User has deliberately deleted a file. They don't want it putting back automatically!

Case 1) can be handled with a no-clobber import (don't touch existing files) because no files exist. Not a profound insight...

Case 2) is OK because everything is controlled by the user. But users don't want to be doing this kind of thing too often, certainly not on every login!

Cases 3), 4) & 5) need bl-user-setup to be triggered again, before it does whatever we've cleverly programmed it to do.

IDEA: Lithium sets a different flag file from Helium ~/.config/bunsen/bl-setup-lithium, or maybe writes something inside the file.

Extension of the second idea, every time bunsen-configs makes a major change it changes the string to look for in ~/.config/bunsen/bl-setup and writes the new string in there after running. So runs would happen only once in a while, and could even be interactive, unless we come up with a cool auto-import. Anyway, if the change means only adding some new files, that doesn't need to be interactive. Maybe modification times would give an idea of what to do?

dpkg does something sort of in this area when it handles conffiles (files under /etc) when package upgrades change them:
*) If sysadmin hasn't edited file, copy in new version, no questions.
*) Sysadmin changes, but package file unchanged, leave sysadmin's edits intact.
*) Both sysadmin and package have made changes, go into interactive mode.

Enough for today. Any (even derisive) comments welcome.

Last edited by johnraff (2019-10-23 09:32:49)

brontosaurusrex · 2019-10-23 13:23:58

^ I'll reread all this few times, but meantime;

I think the basic truth must be that user is aware that config files in its $HOME are changed/manipulated/overwriten and user must initiate this upgrade manually and overlook it (can't be automagic). Outside of $HOME stuff could be different.

I'am thinking there is a missing layer somewhere between /etc and $HOME.

It appears solution would be changes on atomic level, which means understanding smallest possible amount of info in every config file ...

damo · 2019-10-23 14:28:25

I like the idea of writing to the bl-setup file. It allows the possibility of looking at it to see what situation you are in regarding upgrades, or even a history of sorts if previous changes are commented out and kept.

malm · 2019-10-23 14:42:04

John

Great analysis!

I simply come at it from this lowly angle:

I like to regularly use bl-user-setup --refresh to keep my system tuned to the latest bunsen configs - particularly during phases of development and change.
I don't like the fact that bl-user-startup --refresh overwrites some config files which I've made changes to
The proposed patch allows us to control the 'refresh' file-by-file. With the --show-diff option, we can also see what's changed which helps understand what's going on.

Last edited by malm (2019-10-23 14:42:39)

hhh · 2019-10-23 22:20:21

malm wrote:

John
Great analysis!
I simply come at it from this lowly angle:
I like to regularly use bl-user-setup --refresh to keep my system tuned to the latest bunsen configs - particularly during phases of development and change.
I don't like the fact that bl-user-startup --refresh overwrites some config files which I've made changes to
The proposed patch allows us to control the 'refresh' file-by-file. With the --show-diff option, we can also see what's changed which helps understand what's going on.

+1, good summary, malm. In my case, I don't usually need an update of xbindkeys or the Openbox rc.xml config. Anything that changes keyboard shortcuts I, personally, don't want overwritten without my being aware that that's what's happening.

Last edited by hhh (2019-10-23 22:35:14)

johnraff · 2019-10-24 01:07:13

I think I've got it - or something that might eventually be IT.

Ideal user experience (maybe?):

Not to be pestered with questions at every login, or even at every package upgrade, but:

If they change (or delete) something in ~/ it's not messed with.
But if a new version of the file arrives in BLskel (/usr/share/bunsen/skel), they're asked if they want the new file or not. (Of course backups are always made of overwritten files.)
If they leave a config file at its default OOTB state, then when a new version comes it's assumed they're happy with the BL default (or don't care) and the file is updated, silently (but again backed up too).

If approval is needed for a change, either a yad popup (like what Thunar does when copying a bunch of files and some already exist) or else pop up a terminal window and do it there.

When to trigger bl-user-setup (b-u-s)?
The top of the script runs every time (as now) but instead of just checking for ~/.config/bunsen/bl-setup (b-s) it looks inside, to see if some changes have come to BLskel since the last look. The test could be a file (eg /etc/bunsen/configver) or just the version number of the latest installed bunsen-configs, to compare with b-s. After the run, it writes the new version into b-s.

If run, check each file in BLskel and its equivalent in ~/.

Cases (always backup overwritten files):

1) File in BLskel hasn't changed: do nothing, even if user's file is different (or deleted). Assume they changed it because they like it that way.
2) Files in BLskel and ~/ are the same: do nothing.
3) File in BLskel changed, but user file unchanged from default: silently overwrite user file with improved BL config.
4) File in BLskel changed, but user has also edited (or deleted) file: need to ask user what to do.

I think this should be doable, makybe using md5 checksums like dpkg with conffiles. I'll have a look at dpkg...

hhh · 2019-10-24 01:51:41

You're on fire, John. And nice input all around, gents.

malm · 2019-10-24 09:19:21

John
I like it.
(3) could be very useful.

johnraff · 2019-11-06 07:40:04

Was just thinking about this some more. (Notes for possible future developers.)
Have to bear in mind directories and symlinks.

Directories are simple enough, they either exist or not - no editing like files.
BL installs the xdg standards like Documents Music... but users might remove them, or rename Documents to documents so we have to be sure not to mess with their nice arrangement.
OTOH a future bunsen-configs dev might want to add a new directory.

So:
1) directory removed by user: leave it that way
2) new directory added by package: copy it in

Symlinks are a bit trickier. Tests will report about the link target, so skel/.icons will look like a directory, and testing has to be careful:

john@helium:~/projects/user-setup$ [[ -f skel/.icons ]] && echo yes || echo no
no
john@helium:~/projects/user-setup$ [[ -L skel/.icons ]] && echo yes || echo no
yes
john@helium:~/projects/user-setup$ [[ -d skel/.icons ]] && echo yes || echo no
yes

To copy a symlink as a symlink we need 'cp -P <link> <target>'.
Like directories, users might remove symlinks, but might also possibly edit them to point somewhere else. Again we have to be careful not to mess it all up.

---
Implementation

It's a three-way comparison we need:
1) User's current setup
2) bunsen-config's current skel/
3) The previous bunsen-config's skel/

It's not necessary to keep a copy of 3) - I think just a list of md5 sums is enough.
In fact dpkg already keeps a list of all the package's files in /var/lib/dpkg/info/bunsen-configs.md5sums so we can get skel/ with

grep 'usr/share/bunsen/skel' /var/lib/dpkg/info/bunsen-configs.md5sums > cache/skelsums

The last run of the script can also leave a copy of skelsums so we can easily tell with diff or cmp if anything has changed. So, the only checksums we'd need to calculate would be in $HOME, and even then only in a few cases - if the package's file had changed - so it might be quite fast.

Of course bunsen-configs.md5sums only refers to the regular files.
OTOH /var/lib/dpkg/info/bunsen-configs.list has all the files, directories and symlinks, so we could possibly use that to feed our 'for' loop, instead of the output of 'find'?

johnraff · 2019-11-07 07:07:01

Basically thinking out loud...
dpkg might not work so well because the system might have bunsen-configs-lite installed, if that turned out to be our way of providing a lightweight config set. Each package's dpkg info would have to be got separately and combined. Better get the info direct from /usr/share/bunsen/skel with 'find'.

johnraff · 2020-01-11 08:46:51

Just before we got into the test iso release I did quite a bit of work on this, but never posted it up here.

This is what I'm thinking atm (comments welcome):

General Flow
bl-user-setup is run on every user login but a test is done to see if anything has changed in /usr/share/bunsen/skel since the last login, ie due to a package upgrade of bunsen-configs or any other package that puts files in skel. This really won't be very often at all - maybe hardly ever - so as long as the test is fast then the user login won't be noticably slowed down much more than it is now with our flagfile check for ~/.config/bunsen/bl-setup

If a change is detected, then first the user is asked if they want to run the script at all. This is basically a courtesy (it's not polite to change a user's HOME without asking IMO) because the script will prompt the user anyway before overwriting any files they have modified, and backups will be made. Anyway, the algorithm more-or-less described above is run through.

First test
Make a tarball of /usr/share/bunsen/skel and pipe it to md5sum. (Then throw away the tarball.)
Compare the md5sum with a cached value from the last run. This only took 30ms or so on my old 1GB/Centrino laptop which I think might be an acceptable addition to startup time, no?

Like this:

skeldir="/usr/share/bunsen/skel"
cachedir="$HOME/.cache/bunsen/bl-setup
skelsum=$( tar -cf - -C "${skeldir%/*}" "${skeldir##*/}" | md5sum )
skelsum=${skelsum%% *}
# If skel directory unchanged since last run, exit.
[[ -f $cachedir/skelsum && $skelsum = $( <"$cachedir/skelsum" ) ]] && exit 0

# do stuff

# Update cache of skel checksum if script finishes with no errors
echo "$skelsum" > "$cachedir/skelsum"

johnraff · 2020-01-11 08:56:11

Test for new directory
Run find on skel (thanks malm!) and store the list in an array.
If there's a cached directory list, store that in an array too.
Sort each array so the comparisons will always match up, and use comm to detect any new entries which have appeared in skel.

dirs_to_copy=()

mapfile -t new_skel_dirs < <( find "$skeldir" -type d )

if [[ -f $cachedir/skel.dirs ]]
then
    mapfile -t old_skel_dirs < "$cachedir/skel.dirs"
    mapfile -t dirs_to_copy < <(comm -13 <(printf '%s\n' "${old_skel_dirs[@]}" | sort) <(printf '%s\n' "${new_skel_dirs[@]}" | sort))
else
    dirs_to_copy=("${new_skel_dirs[@]}")
fi

Symlinks
No problem here - we'll only copy in symlinks from skel which don't already exist in $HOME - so same code:

links_to_copy=()

mapfile -t new_skel_links < <( find "$skeldir" -type l )

if [[ -f $cachedir/skel.links ]]
then
    mapfile -t old_skel_links < "$cachedir/skel.links"
    mapfile -t links_to_copy < <(comm -13 <(printf '%s\n' "${old_skel_links[@]}" | sort) <(printf '%s\n' "${new_skel_links[@]}" | sort))
else
    links_to_copy=("${new_skel_links[@]}")
fi

TODO: make sure there's no problem with files in $HOME which have the same name as a symlink in skel, or vice versa.

johnraff · 2020-01-11 09:01:37

Files
These need more attention because their content can change, so store the md5sum along with the filepath.
Use file's '+' option to do multiple md5sums in one call of the utility - saves a lot of time.
Generate a list of any files where the one in skel is new or different. The other tests will be done later.

files_to_copy=()

mapfile -t new_skel_files < <( find "$skeldir" -type f -exec md5sum '{}' '+' )

if [[ -f $cachedir/skel.files ]]
then
    mapfile -t old_skel_files < "$cachedir/skel.files"
    mapfile -t files_to_copy < <(comm -13 <(printf '%s\n' "${old_skel_files[@]}" | sort) <(printf '%s\n' "${new_skel_files[@]}" | sort))
else
    files_to_copy=("${new_skel_files[@]}")
fi

johnraff · 2020-01-11 09:19:00

File processing
I haven't done the directory and symlink functions yet, but they should be much simpler.

DESTDIR=${HOME}
g_force=f
g_addonly=f
copy_file() { # function to copy file, making backup if overwriting }
ask_user() { # function to get user permission for overwrite, terminal or yad }
log() { # function to write to a logfile }
# ask_user returns:
# 0 overwrite
# 1 skip
# 2 overwite all
# 3 skip all overwrites

for file in "${files_to_copy[@]#* ?}"
do
    destfile="$DESTDIR/${file#$skeldir/}"
    if [[ $g_force = t ]]
    then
        log "Overwriting $destfile"
        copy_file "$file" "$destfile"
        continue
    fi
    cachesum=
    for j in "${old_skel_files[@]}"
    do
        [[ $j = *\ "$file" ]] && {
            cachesum=${j%% *}
            break
        }
    done
    if [[ -f $destfile ]]
    then
        usersum=$(md5sum "$destfile")
        usersum=${usersum%% *}
    else
        usersum=0
    fi
    if [[ -z $cachesum ]] && [[ ! -e $destfile ]]
    then
        log "New file: $file, copying"
        cp "$file" "$destfile"
    elif [[ ${cachesum} = "${usersum}" ]]
    then
        log "User file $destfile unchanged from default, copying new file"
        copy_file "$file" "$destfile"
    else
        log "User has modified or removed $destfile."
        if [[ $g_addonly = t ]]
        then
            log "Skipping all user modified files"
            continue
        fi
        ask_user "$destfile"
        case $? in
        0)
            copy_file "$file" "$destfile"
            ;;
        1)
            log "Not overwriting $destfile"
            ;;
        2)
            copy_file "$file" "$destfile"
            g_force=t
            ;;
        3)
            g_addonly=t
            ;;
        esac
    fi
done

I've tested this a bit and it seems to be heading in the right direction.

Those functions mentioned above:

copy_file() {
    local src dest
    src=$1
    dest=$2
    if [[ -e $dest ]]
    then
        log "Overwriting $dest, backing up old file as ${dest}${bkp_sfx}"
        mv "$dest" "${dest}${bkp_sfx}"
    fi
    cp "$src" "$dest"
}

ask_user(){
    if [[ -t 0 && -t 1 ]] # on terminal
    then
        echo "You have modified this file:
$1
Overwrite with the new version?"
        while true
        do
        echo "y: overwrite
n: skip this one
a: overwrite all
s: skip all
(Default is skip.)"
            read -r -p 'y/N/a/s: '
            case "${REPLY^}" in
            Y) return 0;;
            N|'') return 1;;
            A) return 2;;
            S) return 3;;
            esac
        done
    else
        title="BunsenLabs User Setup"
        winicon="distributor-logo-bunsenlabs"
        msg="<b>User Setup</b>

You have modified this file:
$1
Overwrite with the new version, or skip?"
        yad --center --undecorated --borders=20 --window-icon="$winicon"\
        --title="$title" --text="$msg"\
        --button='Overwrite':0 --button='Skip':1 --button='Do All':2 --button='Skip All':3
    fi
}

log() {} # not written yet

TODO: Those .template files - the ones that need a hard-coded user file path - complicate things quite a bit. It would be nice if .gtk-bookmarks and nitrogen's nitrogen.cfg took generic paths like ~/ or $HOME...

malm · 2020-01-11 10:18:32

Hi John

Yes, I think we're pretty aligned on this.

Getting the visibility of changed files and ability to say yes/no on individual files is very powerful.

If we run it on every boot, I would suggest just iterating over a smaller number of hand-picked files, as many config files are changed 'in the background', e.g. xfce-power-manager.xml

I run bl-user-setup --refresh this morning only expecting tint2rc and jgmenurc to have changed, but founds that lots were different from the skel/ directory.

Yes, the .templates files are a bit annoying. The only thing I can think of is to iterate over all files and treating them as an edge-case there. They are always going to upset rsync, md5sum, et al.

johnraff · 2020-01-12 07:57:17

@malm

malm wrote:

If we run it on every boot, I would suggest just iterating over a smaller number of hand-picked files, as many config files are changed 'in the background', e.g. xfce-power-manager.xml
I run bl-user-setup --refresh this morning only expecting tint2rc and jgmenurc to have changed, but founds that lots were different from the skel/ directory.

This is the main problem that the new algorithm is meant to solve:

1a) If USER removes a file that originally came from skel/, script does not re-import it.

1b) If USER changes a file so it's now different from the one in skel/, the script leaves it alone.

1c) If a file disappears from skel/ (because it's obsolete), script does not remove it from USER's home.
(This could be a case for asking USER for permission, then removing the file.)

2a) If a new file appears in skel/ that's not in $HOME, script silently imports it.

2b) If a file changes in skel/ (package upgrade) but user's file is still the BL default (unchanged since first install), then USER's file will be silently updated.

Since there will be a permission request right at the start of the script (but only if the script has something to do), my feeling is that individual prompting/confirmation is not needed in these two cases, but I'm ready to be convinced otherwise.

3) If file has been changed both by USER and in skel/, script asks what to do.

I think only a very small number of files will likely be in case 3), and very infrequently, especially once the pre-release beta testing is over. OTOH it would be nice to have a mechanism like this in place during the beta-testing, so we won't have to keep asking users to refresh their files manually.

---

Yes, the .templates files are a bit annoying. The only thing I can think of is to iterate over all files and treating them as an edge-case there. They are always going to upset rsync, md5sum, et al.

Yes, annoying indeed.

GTK bookmarks need an absolute file path of the form file:///home/<username>/<directory> and nothing else ($HOME ~/ or relative path) seems to work. Likewise for the wallpapers directory in ~/.config/nitrogen/nitrogen.cfg. So we're stuck with rewriting those two files, or any other files that might come up in the future needing the same treatment. I think we could do it two ways:

A) Handle the .template files along with everything else, and allow the .template file to remain in $HOME along with the "real" file. Don't rewrite file.template as we do now but leave it in template form and write the "real" file from it with sed. (The "real" file is not in the list of files to check of course.) If a change in file.template is detected in skel/, apply the same algorithm above and if the decision is to update the file, then also redo the sed command to update the "real" file.

This works as long as USER doesn't delete file.template - as they're quite entitled to do of course - in that case a prompt will need to be be triggered, even though in the standard algorithm a non-existing USER file is usually a candidate for a silent import.

B) (simpler) Don't handle the .template files at all. Do the initial import on USER's first boot, then ignore them.

Since there are only two files here, either method might be OK. The GTK bookmarks file will likely be soon changed by USER, but unlikely to get an update from our end IMO. We certainly don't want to keep resetting it back to default, which would be quite irritating. I don't see a lot happening with nitrogen.cfg on either side.

I'll try to implement A) but if it's too messy, B) is a fallback.

---
BTW I discovered today that the default location of GTK bookmarks is now $XDG_CONFIG_HOME/gtk-3.0/bookmarks so we need to change that anyway.

And thanks for all your help! A lot of your code will remain in the new script.

Last edited by johnraff (2020-01-13 03:43:34)

johnraff · 2020-01-12 08:12:03

Need two modes

It just ocurred to me last night:

1) Initial install: HOME needs to be populated before X and the Window Manager are started. Otherwise user would have to log out and in again to see the BL setup.

2) Post-install changes: we need a running X session (or at least a TTY, though that would be less pretty) so we can interact with the user and get permission to overwrite files.

So case 1) will have to be non-interactive - just do everything without questions - and we'll still need the flag in ~/.config/bunsen for running case 1) only once even if case 2) is run on every login.

Complicates things a bit.

...but doable of course.

Last edited by johnraff (2020-01-13 03:35:14)

johnraff · 2020-01-13 03:45:13

malm wrote:

I think we're pretty aligned on this.

I'm using a lot of your code here.

Last edited by johnraff (2020-01-13 05:11:19)

johnraff · 2020-01-13 09:54:18

malm wrote:

...upset rsync, md5sum, et al.

rsync! It's used in the original script but was dropped in favour of find to give us more flexibility. But I now wonder if rsync's --list-only option might be used to generate the file lists instead, maybe with more interesting options.
Time to test a bit...

EDIT: But no, we need to compare skel/ with the user's cached record of it, not with HOME itself, so rsync won't help much.

Last edited by johnraff (2020-01-13 15:33:08)

#1 2019-10-22 08:18:05

Best algorithm for bl-user-setup

#2 2019-10-23 08:36:20

Re: Best algorithm for bl-user-setup

#3 2019-10-23 13:23:58

Re: Best algorithm for bl-user-setup

#4 2019-10-23 14:28:25

Re: Best algorithm for bl-user-setup

#5 2019-10-23 14:42:04

Re: Best algorithm for bl-user-setup

#6 2019-10-23 22:20:21

Re: Best algorithm for bl-user-setup

#7 2019-10-24 01:07:13

Re: Best algorithm for bl-user-setup

#8 2019-10-24 01:51:41

Re: Best algorithm for bl-user-setup

#9 2019-10-24 09:19:21

Re: Best algorithm for bl-user-setup

#10 2019-11-06 07:40:04

Re: Best algorithm for bl-user-setup

#11 2019-11-07 07:07:01

Re: Best algorithm for bl-user-setup

#12 2020-01-11 08:46:51

Re: Best algorithm for bl-user-setup

#13 2020-01-11 08:56:11

Re: Best algorithm for bl-user-setup

#14 2020-01-11 09:01:37

Re: Best algorithm for bl-user-setup

#15 2020-01-11 09:19:00

Re: Best algorithm for bl-user-setup

#16 2020-01-11 10:18:32

Re: Best algorithm for bl-user-setup

#17 2020-01-12 07:57:17

Re: Best algorithm for bl-user-setup

#18 2020-01-12 08:12:03

Re: Best algorithm for bl-user-setup

#19 2020-01-13 03:45:13

Re: Best algorithm for bl-user-setup

#20 2020-01-13 09:54:18

Re: Best algorithm for bl-user-setup

Board footer