Building & Compiling [Solved]

Tending to a few things that have to be dealt with. Taking a break for a while.
Be back to continue the build and compile of Krita soon.
If you stuck let us know, inspired by your idea and joy I'm considering to join Debian team as package maintainer.
There is a procedure for new members and I'm not fully sure I want this, but I think I'll try out.

Doing this stuff is cool because it's great to give something in return for having free software that others contributed.
 


If you stuck let us know, inspired by your idea and joy I'm considering to join Debian team as package maintainer.
There is a procedure for new members and I'm not fully sure I want this, but I think I'll try out.

Doing this stuff is cool because it's great to give something in return for having free software that others contributed.
Yup, if any bewilderment hits I'll be sure to hail you and the team here.

Good to hear mate.

You never know, one of the developers/team leaders on the Debian Team may see your skills and give you an offer you wouldn't want to pass up.

Cool stuff indeed and yes, it is great to give back.
This is why I write articles for Linux.
 
Cool stuff indeed and yes, it is great to give back.
This is why I write articles for Linux.
I know just where you're coming from, mate.

It's why I produce so many re-packaged apps in 'portable' format for the Puppy community (many of which I unearth in the dimmer, dustier corners of t'internet), along with numerous home-brewed utilities'n'stuff.

I was made to feel so welcome by the very friendly regulars when I first joined over a decade ago, along with being given SO much help and assistance in the early days that it was only natural for me to want to contribute back myself as soon as I was able to.

Which I did......with a vengeance! And I haven't quit yet....


Mike. :p
 
I know just where you're coming from, mate.

It's why I produce so many re-packaged apps in 'portable' format for the Puppy community (many of which I unearth in the dimmer, dustier corners of t'internet), along with numerous home-brewed utilities'n'stuff.

I was made to feel so welcome by the very friendly regulars when I first joined over a decade ago, along with being given SO much help and assistance in the early days that it was only natural for me to want to contribute back myself as soon as I was able to.

Which I did......with a vengeance! And I haven't quit yet....


Mike. :p
I respect your dedication and have admiration for your efforts.

Like you, when I joined the Slackware Community I was given so much favor and assistance it was an abundance I'd never seen before.

That was the force that drove me to helping others learn Linux.
 
Restarting the docker daemon is somewhat of a mystery as the command line returns command not found.

Code:
root@devartbox:~# systemctl restart docker --storage-driver=overlay2
-bash: systemctl: command not found

Code:
docker restart --storage-driver=overlay2
unknown flag: --storage-driver
See 'docker restart --help'.

If I can't get the docker restarted I'll have to edit this file:

Code:
oot@devartbox:~# cat  /etc/default/docker
# Here in Debian, this file is sourced by:
#   - /etc/init.d/docker (sysvinit)
#   - /etc/init/docker (upstart)
#   - systemd's docker.service

# Use of this file for configuring your Docker daemon is discouraged.

# The recommended alternative is "/etc/docker/daemon.json", as described in:
#   https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file

# If that does not suit your needs, try a systemd drop-in file, as described in:
#   https://docs.docker.com/config/daemon/systemd/

The edit that's recommended is:
Code:
[Service]
EnvironmentFile=-/etc/default/docker
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// $OPTIONS \
      $DOCKER_STORAGE_OPTIONS \
      $DOCKER_NETWORK_OPTIONS \
      $BLOCK_REGISTRY \
      $INSECURE_REGISTRY \
      $DOCKER_OPTS

Here:
 
Last edited:
From the Krita instructions:

All the docker images and containers are by default stored in a special docker-daemon controlled folder under /var directory. You might not have enough space there for building Krita (it needs about 10 GiB). In such a case it is recommended to move the docker imagesfolder into another location, where there is enough space.

Once the docker is restarted I need to stop the docker in order to edit the config file.

Code:
{
    "data-root" : "/path/where/you/want/to/store/docker/images/"
}
 
root@devartbox:~# systemctl restart docker --storage-driver=overlay2 -bash: systemctl: command not found
It's really strange this is not found but in any case you should not build any code as root.

If building something requires root privileges then it's best to use fakeroot, this should work for normal bare metal builds but not sure for docker.

I never used docker so can't say if it will work nor can I help you with docker without reading docs and testing it but docker isn't my thing. :(

If I can't get the docker restarted I'll have to edit this file:
All the docker images and containers are by default stored in a special docker-daemon controlled folder under /var directory.
All this deprecated docker stuff requires reading docker docs to update things and to configure it properly, it appears either krita docs or build scripts are out of date so you'll have to handle that somehow before build.
 
Normally you wouldn't place the "build" binaries in your docker container. You can have external persistent storage in docker.
You can even mount a directory on your host system. All your build tools live in the container, but the source code and compiled
binaries usually live outside the container. It isn't a hard and fast rule. You don't have to do it this way. But it makes life easier,
because now I have space for anything I want to build.

Usually, I run my git directories or un'tar'd.gz make command ( or whatever ) frpm my host computer.
In rare cases another container. But I don't know that I've ever built something inside the same container.
 
It's really strange this is not found but in any case you should not build any code as root.

If building something requires root privileges then it's best to use fakeroot, this should work for normal bare metal builds but not sure for docker.

I never used docker so can't say if it will work nor can I help you with docker without reading docs and testing it but docker isn't my thing. :(



All this deprecated docker stuff requires reading docker docs to update things and to configure it properly, it appears either krita docs or build scripts are out of date so you'll have to handle that somehow before build.
I should have had my brain more engaged this morning, sorry.

Devuan doesn't have systemd. It uses the SysVinit instead.
I'll look up fakeroot, thanks.

Might be able to change the build script, not sure yet.
 
Thanks @CaffeineAddict for reminding me not to build code as root.
In that case I hadn't gotten to the build yet. I was attempting to restart docker with the systemctl cmd.

Men built and compiled years w/0 systemd in place so I think I've got some reading to do.
Devuan may not be the best os to build/compile on.

Later today I'll look in the Debian repo and see if I can find a src tar.bz of Krita
-------------------------------------------------------------------------------

@dos2unix: docker is new to me so I'll have to do some reading.
I can appreciate keeping the build binaries in a containerized environment.

If the src code and compiled binaries go outside the container, say in lib64 and etc...how would I direct them to a specified directory to go to instead?

Does that have to be done before or during the build?
 
Later today I'll look in the Debian repo and see if I can find a src tar.bz of Krita
On debian it's really easy to build it, here is the package from testing:

On that link above you have tar.gz files but my preferred method is to use apt to get sources and then build a backport,
instructions are here:

Once you have built the backport *.deb file you can extract it, keep the binaries only and throw away the rest.

---

Otherwise you can as well go the hard way and manually build downloaded sources and build without debian build system (and ofc. without docker)

Choose your method, red pill or blue pill? :)
 
On debian it's really easy to build it, here is the package from testing:

On that link above you have tar.gz files but my preferred method is to use apt to get sources and then build a backport,
instructions are here:

Once you have built the backport *.deb file you can extract it, keep the binaries only and throw away the rest.

---

Otherwise you can as well go the hard way and manually build downloaded sources and build without debian build system (and ofc. without docker)

Choose your method, red pill or blue pill? :)
Thanks. I'll go dpkg happy to see if the 12 plus dependencies are installed. Then see if the recommended are installed as well. I won't need trans coding or streaming but I'll consider the pkg to manage device colour profiles.

I'll go with the blue pill tomorrow morning.;)
 
Last edited:
Thanks. I'll go dpkg happy to see if the 12 plus dependencies are installed.
They should be installed automatically as long as the component you're downloading from (ex. testing) has all dependencies already present, if not you'll need to backport them as well.

And btw. the linked site in my previous post will instruct you to install packaging-dev which will in turn install debian-keyring package which is used by build system to verify md5 signatures of downloaded sources automatically.

However problem with debian-keyring package is that it may be out of date, in other words the certificates in that package are not authoritative.

Therefore the procedure for this step if you want to be pedantic regarding md5 sums is as follows:

Bash:
sudo apt install gpg kleopatra rsync

# Download authoritative debian public keys and add them to local gpg keyring (with kleopatra GUI)
rsync -az --progress keyring.debian.org::keyrings/keyrings/ ~/Downloads

Kleopatra is GUI to manage certificates, open it from desktop start menu and import all certificates downloaded with rsync from ~/Downloads directory.
This will take some time to import them all.

Next when done check signature using local keyring added by rsync:

Bash:
cd /path/to/downloaded/krita/sources/directory
dscverify --verbose --keyring ~/.gnupg/pubring.kbx ./*.dsc

Should print out that sources are verified by some X certificate, depending on who is maintainer of krita package.
 
Prerequisites satisfied.:)

Code:
The following additional packages will be installed:
  cgroupfs-mount containerd criu git git-man iptables liberror-perl
  libintl-perl libintl-xs-perl libip6tc2 libmodule-find-perl
  libmodule-scandeps-perl libnet1 libprotobuf-c1 libterm-readkey-perl
  needrestart openssh-client python3-protobuf runc tini wmdocker
Suggested packages:
  containernetworking-plugins docker-doc aufs-tools debootstrap rinse
  rootlesskit zfs-fuse | zfsutils-linux git-daemon-run | git-daemon-sysvinit
  git-doc git-email git-gui gitk gitweb git-cvs git-mediawiki git-svn
  firewalld needrestart-session | libnotify-bin keychain libpam-ssh
  monkeysphere ssh-askpass
The following NEW packages will be installed:
  cgroupfs-mount containerd criu docker docker.io git git-man iptables
  liberror-perl libintl-perl libintl-xs-perl libip6tc2 libmodule-find-perl
  libmodule-scandeps-perl libnet1 libprotobuf-c1 libterm-readkey-perl
  needrestart openssh-client python3-protobuf runc tini wmdocker
0 upgraded, 23 newly installed, 0 to remove and 0 not upgraded.
Need to get 77.6 MB of archives.

Decided to go with Docker to keep things simple.

**Krita needs about 10 Gig's for the Docker images and containers.
Looks like (if I'm not mistaken) I'll have to re-partition /dev/sdb1.

Code:
Filesystem      Size  Used Avail Use% Mounted on
udev            8.3G     0  8.3G   0% /dev
tmpfs           1.7G  1.7M  1.7G   1% /run
/dev/sdb1       966G   28G  889G   3% /
tmpfs           8.4G     0  8.4G   0% /dev/shm
tmpfs           5.3M   13k  5.3M   1% /run/lock
tmpfs           1.7G   74k  1.7G   1% /run/user/1000

Suggestions welcome-:)
 
I haven't gotten to the build yet, however, making good progress.

Code:
Setting up python3-pip-whl (23.0.1+dfsg-1) ...
Setting up python3-lib2to3 (3.11.2-3) ...
Setting up python3-distutils (3.11.2-3) ...
Setting up python3.11-venv (3.11.2-6+deb12u2) ...
Setting up python3-venv (3.11.2-1+b1) ...
Scanning processes...                                                           
Scanning processor microcode...                                                 
Scanning linux images...                                                       

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

python3-venv package is used for bootstrapping the dependencies on the host system before building the docker image, so you need to have it preinstalled.
 
Downloading Krita src's--

Code:
debian-box:~$ dpkg -L python3-venv
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python3-venv
@debian-box:~$ git clone https://invent.kde.org/dkazakov/krita-docker-env krita-auto-1
Cloning into 'krita-auto-1'...
warning: redirecting to https://invent.kde.org/dkazakov/krita-docker-env.git/
remote: Enumerating objects: 416, done.
remote: Counting objects: 100% (69/69), done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 416 (delta 63), reused 51 (delta 51), pack-reused 347 (from 1)
Receiving objects: 100% (416/416), 57.62 KiB | 324.00 KiB/s, done.
Resolving deltas: 100% (266/266), done.
@debian-box:~$ cd krita-auto-1
@debian-box:~/krita-auto-1$ mkdir persistent

I need to decide on the src's /path/to/krita on my system. Got a 1 TB HDD for this Debian install so there's plenty of room. Thinking before I proceed.

Code:
cp -r /path/to/sources/krita ./persistent/krita
 
Stuck here:
Code:
cp -r /path/to/sources/krita ./persistent/krita

Code:
@debian-box:~/krita-auto-1$ ls
bin           Dockerfile  README.md     user-hooks.d
default-home  persistent  ubuntu-focal
@debian-box:~/krita-auto-1$ find persistent
persistent

Do I need to create another krita directory?
 
Have you downloaded tar archives from debian site manually?

If so then you need to copy one archive to another into debian/rules
No. I got them from:
Code:
git clone https://invent.kde.org/dkazakov/krita-docker-env krita-auto-1
 
No. I got them from
Do I need to create another krita directory?
Preferably you want a build directory which should be automatically created by build scripts, but since this is a cloned repo to which you I assume have no write permissions (from upstream owner) you can just build inside it.
And then if you need to undo just delete it and clone again.

If you plan to make changes to code it would be better to create a fork if it's supported on their git site, or otherwise push to your private repo somewhere and create a build branch, then you can switch from clean source tree branch to build branch without affecting original code.
 

Staff online

Members online


Top