The functions in this script started as the ISO functions of the solydfixes script. As the rest of that script is not ISO related, moving these functions to a separate set of 'ISO management tools' seemed appropriate.
The --help option of the script currently provides this list of functions and options:
Usage: imt [OPTION/ARGUMENT]... General options: -c FILE use FILE as configuration file instead of imt.conf -h, --help display this text and exit -l open the log in an editor after the action -o [VAR=VALUE] set configuration variable directly -y use the --yes option with apt-get (see apt-get manpage) --remove [+log] remove an installed set, optionally including the log files Arguments with related options (if any): abort abort a running batch (cleanly - after current action) SPEC build build an ISO -P NUMBER specify the number of processor cores to use -s skip specified build actions SPEC chroot CMD execute a chrooted command in the specified build structure SPEC cmp compare installed packages in builds (32 versus 64 bit) -e compare /etc instead of the installed packages -f FILE compare a 32 bit set with a file instead of a 64 bit set use . for FILE to download the corresponding file SPEC diff FILE execute diff on the same file in specified builds get download the most recent version of this script list list the available unpacked ISO structures -i also show each structure's info file packages check the reference packages SPEC unpack [NAME] unpack an ISO, optionally naming a file or directory -v verbose - list all files being copied, modified or deleted SPEC update update the specified build -T update sources.list to Debian Testing instead of Jessie -e exclude specified update actions -p only show the first yes/no prompt (from apt-get) in a batch -t add 'testing' to the SolydXK repository line SPEC upload upload a built ISO and checksum file -m MONTH specify month (CCYYMM) if not current month -n NUMBER specify optional ordinal number (01-99) to add to month SPEC = specifying arguments (as in imt K cmp or imt ke32 update): K or k SolydK X or x SolydX E or e Enthusiast's Edition (implies -T for update) 32 32 bit 64 64 bit When a full specification is required, the speficying arguments MUST be given without spaces.
Version 3.0.1 of the script is available here (SHA256 hash is 5fc92612ba64d93c7f551922d4d44630dfa2289c53c58e7d103da10aedc3aaa9 - gpg signature is here). This links to a text file with some release history.
The imt unpack, update and build sequence can be mixed with the Constructor's Add, Upgrade and Build actions, but not under all circumstances. Unpacking/Adding is essentially the same process for both, but building is not. A lot of what the Constructor does before it actually starts building an ISO, is not done during imt's build action, but during update.
So it's ok to run imt's update and then Build using the Constructor, but doing Upgrade with the Constructor and then building with imt is a bad idea.
Most of my scripts are not distributed as Debian packages but supplied in tarballs. This means you cannot install them using your package manager, but have to download the tarballs and 'install' them yourself. Just create a directory called imt anywhere you like and extract the tarball to it, keeping the layout/structure intact. Any good file manager should do that automatically if you select 'Extract here' or 'Extract to...' from its context menu (yes, I know Thunar messes that up - I did write 'any good file manager'...).
You can run the script from the terminal, open on that directory, with ./imt command ... or from any other directory if you use the full pathname. If you create a symlink to the main script in /usr/local/bin or ~/bin, you can call it from anywhere with just imt.
Alternatively, you can 'install' the script properly, i.e. put the main script in /usr/local/bin and the rest in /usr/local/lib/imt (no package manager involved means using /usr/bin and /usr/lib/imt is out...). You can do that by running ./install from the directory you just created.
The imt tarball currently contains:
| lib/imt/overwrites | directory with templates for the update function |
| lib/imt/build | script for the build function |
| lib/imt/building-an-iso | a text file describing how to build a 32-bit SolydK ISO |
| lib/imt/functions | miscellaneous support functions |
| lib/imt/history | some notes about the development of the script (not as detailed as a change log) |
| lib/imt/imt.conf.example | an example of the main configuration file |
| lib/imt/settings | non user specific settings |
| lib/imt/trackers | list of torrent trackers from SolydXK Constructor |
| lib/imt/unpack | script for the unpack function |
| lib/imt/update | script for the update function |
| lib/imt/webseeds | list of urls of ISO seeds (backup in case pulling the real one from the website fails) |
| imt | the main script |
| install | script that takes care of installing or upgrading the set to a new version |
No README or manpage, sorry. This webpage will have to do.
Some items the script will create and use are scratch space (/tmp/imt.d), a directory for variable/cached data (/var/local/imt) and a log file (/var/log/imt.log). The latter can be opened in a graphical editor with the imt -l command (that's a lower case L, by the way).
The lib/imt subdirectory is the library directory. This is where the script expects to find all its support files. Keeping this in the unpacked imt directory is fine, but it is not where the script itself would put it.
The script uses a simple DNS call to check whether a new version is available. If there is one, it will tell you about it and you can download the new version from this site or use the command imt get to make the script download it itself. The get function will download the tarball and 'install' the script and support files in the default locations (see above). If the old version of the script is running from another directory called 'bin' (e.g. in your home directory), the new version will end up there. If necessary a 'lib/imt' directory will be created on the same path.
Removing the script and associated files and directories can be done with the command imt --remove. If you want the log files gone as well, use imt --remove +log. This command will work on an installed set and also on a set which is not actually installed but stored in a directory with the name of the script.
Be aware this command executes immediately (after asking your sudo password) and bluntly removes the entire script set. If you used one of its directories to store anything you want to keep, move it out of the way first.
You will need a properly set up imt.conf file before you can use the script. Use the imt.conf.example file from the tarball or create something yourself and make sure all the required variables have values that apply to your system. Also check out the reference packages section.
The script uses two files for configuration, imt.conf with the system specific configuration and settings with ISO related settings.
The script needs to know where the unpacked ISOs are stored on your machine. You should set this in the imt.conf file. This file should be placed in the .config subdirectory of your home directory, but it will also be found in the library directory. It will be read ('sourced') as if it's part of the script, so assigning values to variables must be done in the same way as in a regular shell script.
Be aware that if you change the values of the 'Script...' variables set at the start of the script, you run the risk of seriously messing up the script's functionality.
An example version of imt.conf is provided in the tarball. It starts like this:
# In this example, all ISO build directories are subdirectories of one single # directory, specified in BuildsPath, which will be used as a prefix when the # actual locations are set (in the array ISOBuild). If a k or x variable # contains a full path (i.e. starts with a /), this prefix will be omitted. # Remove or comment the variable for any ISO you don't have. # If any of these structures is on a device that may not be mounted initially, # be it an internal or external one, the pathname MUST start with either /mnt # (for internal devices) or /media (for external ones). The script uses this to # determine the tool to mount the device with (mount or udisksctl). Also, the # label of the relevant partition (ehd2-e0 in this example) must be part of the # pathname. BuildsPath=/media/ehd2-e0/iso k32=solydk32 k64=solydk64 x32=solydx32 x64=solydx64 ke32=solydkee32 ke64=solydkee64 xe32=solydxee32 xe64=solydxee64
Change this to reflect your own setup.
Other variables you can set in imt.conf are:
| BuiltISOsPath | directory where build ISOs should end up |
| ImagesPath | directory used to store (downloaded) disk images |
| RemoveReference | code or full pathname of file to use for comparing the ISO's /live/filesystem.packages-remove file |
| LocalBin | directory with executables which need to be accessible inside the chrooted build environment |
| AptCache | directory to use as apt cache for all build structures |
| NoEditor | set to 1 if you don't want the iso cmp result to be opened in a graphical editor |
| Server | used to indicate which of the Settings array items is the default |
| Settings | array of names of remote server settings files for uploads |
| BuildMirror | country code of repository mirror to use during build structure updates |
| LocalRepoISO | sources.list line for local repository - general packages |
| LocalRepoHold | sources.list line for local repository - held packages |
| LocalRepoPrio | pin priority lines for local repository |
| LocalRepoKeyID | fingerprint of local repository's GPG key |
| LocalRepoKeyFile | file with local repository's GPG key |
All of these are described in more detail below.
The -o option allows you to change these variables from the command line. For instance, if you have the BuildMirror variable set and the local repository turns out to be off line, you can add -o BuildMirror= to the command line to temporarily switch off the local mirror without having to change the imt.conf file. If you want to change more than one variable, you need to either put the entire sequence between quotes and use semicolons as separators (e.g. -o 'RemoveReference=/home/user/packages-remove;BuildMirror=') or use more than one -o option.
Of course, quotes are also necessary if the value you want to assign contains spaces. If you want that and assign more than one variable in the same -o option, you need two sets of quotes: double quotes around the value following the equals sign and single quotes to enclose the whole sequence (or the other way around). Spaces around the equals sign are a bad idea, by the way. This is shell script (bash) code, so it must conform to bash rules.
The second example in the previous paragraph illustrates something else you need to be aware of when you specify pathnames in the configuration files or on the command line. You cannot use ~/ to refer to your home directory as the script (mostly) runs as root.
Unlike imt.conf, the settings file is not supposed to be altered by the user. It is meant as a central location for various ISO related settings and is sourced immediately before imt.conf. It currently sets the following variables:
| BuildRemovals | whitespace separated list of files and directories to remove from BootPath and RootPath before building (build) |
| ChrootActions | Process format list of actions after dist-upgrade (update) |
| Firmware | Process format list of firmware drivers or driver installer packages |
| Hold_ | Process format list of packages to hold (update - main editions) |
| Hold_ee | Process format list of packages to hold (update - enthusiast's editions) |
| NotOrphaned | comma separated list of packages not to be treated as orphaned (update) |
| NotUnavailable | comma separated list of packages not to be treated as unavailable (update) |
| OffLine | whitespace separated list of packages to be stored in ISO's /boot/offline directory |
| ReferencePackages | whitespace separated list of packages and files to watch |
| ReleaseStable | main version number of Debian's current Stable release |
| ReleaseTesting | main version number of Debian's current Testing release |
| SyslinuxBinaries | whitespace separated list of binaries to copy to BootPath/isolinux (build) |
| UpdateRemovals | whitespace separated list if files and directories to remove from BootPath and RootPath (update) |
Several of these are described in more detail below.
The available functions are (this list is not in alphabetical but in logical order):
Be aware that you do not need to run the script with su or sudo. In fact, it may complain if you do, because it may need to pick up some information which is not available to root. If it needs root permissions for some action, it will make the necessary sudo call itself.
The ISO build structures maintained with this script are closely tied to the two main SolydXK editions, the 64-bit SolydK and SolydX. Any significant changes there should be reflected here, if possible. To help keep an eye on things, the script includes a 'watcher' functionality which will notice changes in certain files. This is used by the iso update function as long as the variable ScriptPackageCache is set, but it can be called separately as well: imt packages.
The variable ReferencePackages in settings contains a list of packages and files to check. If differences are detected, you'll have to figure out whether these are relevant yourself, though. They will show up as diffs in the logfile (/var/log/imt.log), by the way, so the first place to look is there.
Should you decide you do not want to use this functionality, you can disable it by adding the line unset -v ScriptPackageCache to imt.conf, which will remove the variable. If however you do want to use it, you should run imt packages at least once after setting up imt.conf, so the directory ScriptPackageCache points to is created.
By default, only 2 older versions of packages will be kept in the subdirectories of the directory set with ScriptPackageCache. You can change that by setting the variable ScriptMaxCached (in imt.conf). Set it to 0 and no maintenance will take place at all and you will have to remove older items (the directories with version numbers as names) yourself.
Keep in mind that you really need a host - or at least a virtual machine - tracking Debian Testing if you want to be able to create ISOs for the Enthusiast's Editions. Otherwise keeping up with the changes these editions go through could become quite hard.
Most of the code for this function is held in a file called unpack, which must exist in the script's library directory.
If you enter the command imt x64 unpack FILENAME-OF-ISO, the script will unpack the ISO file in the correct build structure. The file needs to be in the current directory or on ImagesPath (see below - current directory will take precendence) if no path is specified and the build structure needs to be set in imt.conf, using the BuildsPath and k or x variables as mentioned above.
If you specify a directory instead of a file, the script will scan this directory for suitable ISO files and present a list to choose from. If your system has a directory where you usually keep ISO files, you can specify this in imt.conf using the ImagesPath variable. The example file has:
# Set this to the directory in which you usually keep your ISO Image files. ImagesPath=/data/diskimages
You can then enter the unpack command without specifying a directory or file and the script will present a list of suitable files from the directory set in ImagesPath.
The -v option (imt -v x64 unpack) will make the script display the name of every file being handled as the ISO is unpacked. While this is a nice way to see what's going on, it will also slow down the process considerably.
This function shows a simple list of defined ISO build structures and whether there is actually anything in them. With the -i option, all available info files (/etc/solydxk/info) will also be shown: imt -i list.
You can limit the output to a selection of structures by specifying them. I.e. imt -i list ke32 ke64 will show info about the SolydK Enthusiast's Editions only.
Most of the code for this function is held in a file called update. The templates for the files to add or replace are stored in files in the overwrites directory. These items must exist in the script's library directory.
This function performs all kinds of update and cleanup actions, including but not limited to running apt-get update and dist-upgrade in a chrooted environment, removing orphaned or unavailable packages, downloading offline GRUB EFI packages and building the EFI modules.
The sources.list file is also checked (before the apt-get update). By default this should point to the Jessie or Stretch (Testing) repositories, for the main and Enthusiast's Editions respectively.
Some of the checks this function performs require more local configuration, to be done in imt.conf. If you want the script to warn you about certain important files changing, you should let it set up a package cache. By default this will be done in /var/local/imt/unpacked, but you can change that by changing the ScriptPackageCache variable (see also the imt packages description).
Another thing to check is which packages are to be removed after installation. This will not change often, but you can let the script keep an eye on any changes by providing a reference file. This can be a file specified by its full pathname, stored anywhere on your machine, or the corresponding file in one of the unpacked ISOs. In that case all you need to specify is the code of the ISO. The imt.conf example has this:
# If you want the update function to check the /live/filesystem.packages-remove # file, set this variable. You can use the file from one of the unpacked ISOs by # specifying its code (e.g. x64). Alternatively, enter a full pathname starting # with a slash to use a file stored anywhere on your machine. If you end that # name with an underscore, the suffix 'ee' will be added when the function # handles an Enthusiast's Edition ISO. # RemoveReference=x64
If you enter a pathname, it must start with a slash. If you specify a name ending in an underscore, the script will look for a file with that exact name when checking a Main Edition ISO and use that name with 'ee' added for an Enthusiast's Edition.
From the imt.conf example:
# Set this if you have a directory with executables you want to have access to # in the chrooted build environment. This directory will be bind mounted over # the ISO's /usr/local/bin. # LocalBin=/usr/local/bin # Set this if all build structures are to use the same cache for apt. # AptCache=/var/cache/apt/archives
In case you want to be able to access your own binaries or scripts and/or want to have one central apt cache inside the chrooted build structures. The AptCache setting can be quite useful if you have a lot of build environments you need to keep up to date.
By default, upgrading packages in the build structures is done using the default repositories. However, these are in the US and depending on where you are, this can be slow. For me personally, the Dutch mirrors are quite a bit faster. The BuildMirror variable can be used to change this. Be aware that SolydXK only has a limited set of mirrors, so using the code of your country may not work as expected for the SolydXK repository. The Debian repos is another story, but keep in mind that the Enthusiast's Editions use Debian's redirector.
# Optional (country) code. When this is set, the sources will be temporarily # switched to the local mirror in that country when an ISO structure is # updated/upgraded. This can speed up large package downloads considerably. # BuildMirror=nl
Please check your own system for useable country codes (a future version of this page may have something more useful here...).
If you want to include extra packages or use the function's hold action, you will have to set up a local repository. How to do that exactly is not something I intend to describe here. I will just assume you have already done it and want to make this function use it. Looking at the imt.conf example:
# Sources list, pin file and GPG key info for the local repository. How you set # this up on your machine is entirely up to you, as long as you keep in mind the # text in LocalRepoISO will get the suffix 'stable' or 'testing' depending on # the edition. # This repository will always be added, but may be empty. The 'Hold' repository # will only be added if the Hold_ or Hold_ee variable (set in settings) exists # and contains a Process string. # The texts will end up in a chrooted /etc/apt/sources.list.d/localhost.list and # .../preferences.d/localhost, temporary files that will not be added to the # ISO. The key will be added to the chrooted apt's key database and will be # removed from it during the cleanup immediately before the ISO is built. The # KeyId must be your key's fingerprint and the KeyFile the full name of a file # containing the key. # Uncomment the following lines to enable. # LocalRepoISO="deb http://localhost/pkg packages iso-" # LocalRepoHold="deb http://localhost/pkg packages iso-hold" # LocalRepoPrio="Package: *\nPin: release a=packages\nPin-Priority: 900" # LocalRepoKeyID= # LocalRepoKeyFile=
This references a local repository at localhost/pkg with a 'distribution' called packages and three sections: iso-stable, iso-testing and iso-hold. You can modify everything to suit you, except the stable and testing bit.
The update function tries to prevent the apt-get dist-upgrade from starting processes in the chrooted environment. It may not always succeed, so make sure to check the last section of this function's terminal output (i.e. the bit where it says 'looking for unwanted processes running in the chroot').
Also, never ever allow a GRUB upgrade to install anything in your main disk's MBR. An update-grub shouldn't hurt, but if you see configuration screens, triggered by grub-install, asking you where to install GRUB, DON'T!
One of the actions carried out is purging orphaned packages. This is done using deborphan and I've seen at least one occasion where this is a bit too enthusiastic. The variable NotOrphaned can be used to curb this. It should be set in settings and the relevant section in that file currently looks like this:
# Packages that must NOT be treated as orphaned - comma separated list NotOrphaned='baloo,libsysfs2,kde-config-touchpad,kde-window-manager,libqoauth1,libxcb-xtest0,polkit-kde-1,libkf5screen6'
Another cause of potentially undesirable behaviour is the removal of packages that are no longer in the repositories. This can be prevented with the NotUnavailable variable. Currently in settings:
# Packages that must NOT be treated as unavailable - comma separated list NotUnavailable='exaile,filezilla,ksh,steam,python-webkit,k3b,k3b-data,k3b-extrathemes,k3b-i18n,libk3b6,libk3b6-extracodecs'
It's possible to call the iso update function for a specific set of actions. For example, imt k32 update lists upgrade will just run apt-get update and apt-get dist-upgrade. The full list of available actions is (in sequence):
| keyword | action |
|---|---|
| ref-packages | check reference packages |
| ref-remove | compare ISO's boot/live/filesystem.packages-remove file with (unpacked) reference ISO's or specified file |
| ref-adjust | compare ISO's root/usr/lib/solydxk/system/adjust.py with host's |
| ref | do the previous three and exit - this one isn't part of a normal update sequence, of course... |
| sources | check sources.list |
| history | check update manager history |
| lists | perform apt-get update |
| hold | process any hold commands specified in Hold_ or Hold_ee (set in settings) |
| upgrade | perform apt-get dist-upgrade |
| firmware | check all required firmware packages are installed |
| actions | process actions specified in ChrootActions (set in settings) |
| unavailable | check unavailable packages |
| orphaned | check orphaned packages |
| plymouth | make sure the plymouth splash screen is correct |
| defaults | check SolydXK defaults (from solydxk-system c.a.) |
| databases | update databases like the apt-xapian index, the locate and GeoIP database and the pixbuf cache |
| firewall | make sure the firewall is set correctly |
| old-kernels | remove any old kernels |
| broken | check for broken packages |
| cleanup | clean up the apt cache and remove obsolete automatically installed packages |
| kernel-files | take note of the current kernel files |
| offline | update the offline package cache (uses OffLine - set in settings) |
| remove | remove unwanted items (uses UpdateRemovals - set in settings) |
| overwrite | replace or add certain files (templates in overwrites directory) |
| efi | build EFI boot files |
| greeter | update the LightDM greeter |
| live-user | make sure the live user is available to LightDM |
| lightdm-uid | set minimum UID for LightDM to 1000 |
If you use the -e option, the actions listed will be skipped. E.g. imt k32 -e update firmware will run every part of a normal update sequence, except checking the firmware.
If you want to run a (non graphical) command in the environment of one of the ISOs, you can start up the SolydXK Constructor and click the Edit button. The script offers the same functionality.
Say you want to update the package lists of the 32-bit SolydK build, just run imt k32 chroot apt-get update and watch the usual update text scroll by in your terminal window.
There are some limitations. As the function only chroots a single command at a time and not the entire terminal, you can't 'chain' commands with ; or &&. That is, something like imt k32 chroot apt-get update && apt upgrade won't work (and neither will enclosing the commands in accolades or parentheses).
Also, you need to make sure imt doesn't choke on any options the command might need. For instance, running 'apt-get -f install' would need to be entered as imt k32 chroot -- apt-get -f install. The two dashes tell imt to ignore any following options.
This checks which packages are installed on a 32-bit SolydXK ISO and are missing from the corresponding 64-bit one (and vice versa). It assumes you have at least the 32-bit ISO unpacked on your system somewhere. If you don't have a 64-bit ISO unpacked as well, you can run the comparison against a list of packages in a file. A copy of such a file will be available on this site, updated regularly, and can be downloaded by the script.
Some examples of use:
imt k cmp | compare SolydK 32-bit vs 64-bit when both are available unpacked |
imt k cmp -f list | compare if 64-bit is only available as list |
imt k cmp -f. | ditto - download list |
The result of the comparison can be found in /tmp/imt.d/result-k or /tmp/imt.d/result-x, depending on the SolydXK version. The script will attempt to open this file in your favourite (graphical) text editor, unless you uncomment the NoEditor=1 line in imt.conf.
If you've downloaded the 64-bit list, you should also find a result file with '-downloaded' tagged to the name in /tmp/imt.d. This is the result of a comparison carried out on the machine where the 64-bit list was produced and is provided as reference.
The resulting list is not meant as a ready-to-use recipy for packages to remove from or add to the 32-bit ISO. There will be differences, if only because the community decided to use the non-ESR versions of Firefox. Also, slightly different version numbers (in particular ones with something like '+b1' at the end) don't have to be an issue.
Check the list for obviously superfluous or missing packages and act accordingly, if necessary after consultation.
If you run imt -e k cmp, the script tries to go through the entire /etc structure of the 32-bit and 64-bit SolydK ISOs and report differences. [This functionality needs work to improve the handling of the comparison result and because of false 'positives'.]
This does not work with only one ISO unpacked, by the way. You really need them both.
This works both across architectures and across desktops.
For instance, the command imt k diff etc/wgetrc will produce a diff for the file /etc/wgetrc in the 32-bit and 64-bit SolydK build structures. With imt 32 diff etc/wgetrc the script will diff the same files in the 32-bit SolydK and SolydX structures.
Of course, this function is only usefull if you have those ISOs unpacked on your system.
Most of the code for this function is held in a file called build, which must exist in the script's library directory.
This function runs all the commands required to create an ISO image and an SHA256 checksum and torrent file. It uses what's available in the relevant build structure and creates the files for the current month. That is, in September 2016, imt k32 build would create solydk32_8_201609.iso, solydk32_8_201609.iso.sha256sum and solydk32_8_201609.iso.torrent.
The '8' in the names represents the main version number of Debian's Stable release. This is set in settings with the ReleaseStable variable.
The tracker and seed data needed for the torrent files is taken from the SolydXK Constructor and one of the SolydXK servers respectively. If either of those is not available, the supplied files trackers and webseeds will be used.
The resulting files will be placed in the corresponding build directory unless you set the BuiltISOsPath variable in imt.conf. From the example file:
# Only uncomment and set this if you want built ISOs to be stored in a separate # directory (otherwise they will end up in the corresponding build directory). # BuiltISOsPath=
By default, the build function will use half of the available processor cores to build the squashfs file. You can change this with the -P option. On a four core machine, imt -P4 build will use all cores. Be aware this may cause a bit of a strain on your machine and keep an eye on the processor temperature. Press Ctrl+C a couple of times to abort the process if things heat up too much.
The build function also has the option to run a specific set of actions only. However, actually building the ISO is not really suited for leaving bits out, so don't do that unless you know exactly what you are doing. The full list of available actions is (in sequence):
| keyword | action |
|---|---|
| date | check the build structure has been updated recently |
| kernel | copy kernel files to the live directory |
| syslinux | update syslinux binaries if necessary |
| installed | build a list of all installed packages (live/filesystem.packages) |
| memtest | disable memtest in the GRUB menu (chmod -x /etc/grub.d/20_memtest86+) |
| delete | delete various files that should not be in the ISO |
| gpg-key | remove the local repository's gpg key |
| fix-sources | restore the sources list if necessary |
| squashfs | create the new squashfs file |
| md5sums | build a list of md5sums for use by the integrity check (live system menu) |
| efiboot | create the El Torito boot image efiboot.img |
| isofs | build the hybrid ISO |
| checksum | create the sha256sum file |
| torrent | create the torrent file |
If you use the -s option, the actions listed will be skipped. E.g. imt k32 -s build torrent will run every part of a normal build sequence, except creating the torrent file (which is just about the only thing you can do without issues if you do not know exactly what you are doing...).
If you have upload access to the SolydXK repository, you can use this function to upload the built ISO and md5sum file. You'll need the lftp package and have to add some more settings to imt.conf. The example currently has this:
# Default Server=solydxk # This should point to a file containing server settings for ISO uploads. Settings[solydxk]=/srv/repo/solydxk-uploads-remote.ini # Alternatively, you can put all the settings in here and tell the script you # have done that with a full stop, i.e. # Settings[solydxk]=. # RemoteServer=server's hostname # RemoteUser=username # RemotePass=password (or use gkeyring)
It is unlikely you already have another ini file with server settings that you could link to as above, so adding the details to imt.conf itself is probably the easiest.
By default, the script will use the year and month of the current date to determine which files are to be uploaded, so in September 2016, just imt k32 upload should be enough to start uploading a file called solydk32_8_201609.iso (plus its sha256sum file). If you want to upload older files or files with an ordinal number after the month, use the -m and/or -n options (e.g. the August 2016 ISO with '02' added to the name: imt k32 upload -m 201608 -n 02).
If you want to use the upload function of the script, you'll need lftp (it's in the repository). The normal ftp client simply does not cut it for me. I use lftp with these additions to /etc/lftp.conf:
set cmd:save-cwd-history no set cmd:save-rl-history no set dns:order "inet" set ssl:check-hostname no set ssl:verify-certificate no set xfer:log yes set xfer:log-file "/var/log/lftp/transfer"
Not all of these are necessary, but the ssl ones may be useful if you connect to a server that, while supporting secure connections, hasn't been set up entirely correctly.
If you want logging and want to use lftp as non-root, you'll need to chmod the /var/log/lftp directory to 0777.
Under normal circumstances most of the functions mentioned above will be used separately. Some can be chained together or set to act on more than one build structure. Assuming you have these six ISOs unpacked, the command imt -y k32 x32 ke32 xe32 ke64 xe64 update build upload would update the structures, build the ISOs and upload them, all without manual intervention. Something like imt -y k32 x32 update or imt ke32 xe32 ke64 xe64 upload is also possible, i.e. you don't have to use the full run.
Batch functionality is only available for the update, build and upload functions.
It is not advisable to use this with Enthusiast's Editions in times of disruptive changes, like major KDE or gcc upgrades. You shouldn't use the -y option then anyway (it suppresses apt-get's confirmation questions) and preferably do update runs with just the list and upgrade actions to make sure nothing is going to break.
If you are confident nothing will break during the update phase of the batch, but you do want to check the first bit (i.e. the upgrade/remove/install list), you can use the -p option instead of -y. This will make the update function ask only the very first apt-get related confirmation.
As mentioned above, it's always possible to stop the script with Ctrl+C. However, that is not exactly a 'clean' abort, particularly if it happens during updating, in the middle of some action on the chrooted environment. You should only use it in case of an emergency.
To abort cleanly, with all temporary mounts and files removed, open another terminal window (or the Alt+F2 command line) and enter imt abort. This will create a flag file in the script's temporary directory. The main run of the script will pick that up and stop after the current action has been completed.
The imt script is provided under the EUPL, version 1.1, which is a FOSS licence, compatible with GPLv2.
The script is still being developed and future versions may be (very) different. As far as I'm aware, it does what it's supposed to do. Nevertheless, you use it entirely at your own risk. That said, if you find a bug, do get in touch with me and I'll see what I can do about it.
This section needs more work. For now, a short list of known issues will have to do: