How docker works now.

When you build a docker container using only docker tools, what you are actually doing is building a bunch of layers. Great. Layers is a good idea. You get to build a bunch of docker images that have a lot of similar layers, so you only have to build the changes when you update containers. But what you end up with is this really hard to read ugly Dockerfile that is hard to leave because it tries to put a bunch of commands on the same line.

# from https://www.drupal.org/requirements/php#drupalversions FROM php:7.0-apache  RUN a2enmod rewrite  # install the PHP extensions we need RUN apt-get update && apt-get install -y libpng12-dev libjpeg-dev libpq-dev      && rm -rf /var/lib/apt/lists/*      && docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr      && docker-php-ext-install gd mbstring opcache pdo pdo_mysql pdo_pgsql zip  # set recommended PHP.ini settings # see https://secure.php.net/manual/en/opcache.installation.php RUN {          echo 'opcache.memory_consumption=128';          echo 'opcache.interned_strings_buffer=8';          echo 'opcache.max_accelerated_files=4000';          echo 'opcache.revalidate_freq=60';          echo 'opcache.fast_shutdown=1';          echo 'opcache.enable_cli=1';      } > /usr/local/etc/php/conf.d/opcache-recommended.ini  WORKDIR /var/www/html  # https://www.drupal.org/node/3060/release ENV DRUPAL_VERSION 8.2.6 ENV DRUPAL_MD5 57526a827771ea8a06db1792f1602a85  RUN curl -fSL "https://ftp.drupal.org/files/projects/drupal-${DRUPAL_VERSION}.tar.gz" -o drupal.tar.gz      && echo "${DRUPAL_MD5} *drupal.tar.gz" | md5sum -c -      && tar -xz --strip-components=1 -f drupal.tar.gz      && rm drupal.tar.gz      && chown -R www-data:www-data sites modules themes 

Here is a Dockerfile that is used to build a mysqld container. The RUN command in the middle is just really convuluted and I just can't imagine trying to write a container like this. But what if you could use salt to configure your docker container to do the same thing.

Using Salt States

NOTE: This is all to be added in the Nitrogen release of salt, but you should be able to drop-in the dockerng state and module from develop once this PR is merged.

It is worth mentioning that this is a contrived example, because one of the requirements to use dockerng.call is to have python installed in the docker container. So for the salt example you will need to build a slightly modified parent container using the following command.

docker run --name temp php:7.0-apache bash -c 'apt-get update && apt-get install -y python' && docker commit temp php:7.0-apache-python && docker rm temp

Now, this shouldn't be a problem when building images. This just allows for managing the layers. If I were to do this, I would take the debian image, and use salt states to setup apache and the base stuff for building the modules and things and then run the following state.

Build Drupal Image:   dockerng.image_present:     - name: myapp/drupal     - base: php:7.0-apache-python     - sls: docker.drupal 

Then this would build the image with my salt://docker/drupal.sls state.

{%- set exts = ('gd', 'mbstring', 'opcache', 'pdo', 'pdo_mysql', 'pdo_pgsql', 'zip') %} {%- set DRUPAL_VERSION = '8.2.6' %} {%- set DRUPAL_MD5 = '57526a827771ea8a06db1792f1602a85' %}  enable rewrite module:   apache_module.enabled:     - name: rewrite  install extensions:   pkg.latest:     - names:       - libpng12-dev       - libjpeg-dev       - libpq-dev    cmd.run:     - names:       - docker-php-ext-configure gd --with-png-dir=/usr --with-jpeg-dir=/usr:         - prereq:           - cmd: docker-php-ext-install gd       {%- for ext in exts %}       - docker-php-ext-install {{ext}}:         - creates: /usr/local/etc/php/conf.d/{{ext}}.ini       {%- endfor %}  configure opcache:   file.managed:     - name: /usr/local/etc/php/conf.d/opcache-recommended.ini     - contents: |         opcache.interned_strings_buffer=8         opcache.max_accelerated_files=4000         opcache.revalidate_freq=60         opcache.fast_shutdown=1         opcache.enable_cli=1  get drupal:   archive.extracted:     - name: /var/www/html     - source: https://ftp.drupal.org/files/projects/drupal-{{DRUPAL_VERSION}}.tar.gz     - source_hash: md5={{DRUPAL_MD5}}     - user: www-data     - group: www-data     - enforce_toplevel: False     - options: --strip-components=1 

And we are done. In my honest opinion, this is significantly easier to read. First we enable the rewrite module. Then we install the packages for compiling the different php extensions. Then we use the built in docker-php-ext-* to build the different php modules. And we put the opcache recommended plugins in place. Lastly we download and extract the drupal tarball and put it in the correct place.

There is one caveat, right now we do not have the ability to build in the WORKDIR and ENV variables, so those will have to be provided when the container is started.

Start Drupal Container:   dockerng.running:     - name: drupal     - image: myapp/drupal:latest     - working_dir: /var/www/html 

I am going to look into adding those for the dockerng.create command that is used to create the starting container for the sls_build so that they can be saved for the image.

Original Article

Long time no post on my blog, but this time I have to.
Finally I was able to release a first alpha version of my Android app "23 viewer". It's in an early alpha stage, but it can be used to browse the subscriptions of your contacts in the 23 photo community, to favor a photo, to comment on photos and to see the EXIF data of a photo.
You can find the apk package for Android on the github release page here: https://github.com/isenmann/23viewer/releases
To give you some short impression, here are some screenshots of the app:

You will need an account on 23 to use the app, otherwise you are not able to do anything in the app or to see something. If you using 23, give me some feedback via github or email. Thanks and have fun with the app.

Original Article

Due to the decreasing popularity of i686 among the developers and the community, we have decided to phase out the support of this architecture.

The decision means that February ISO will be the last that allows to install 32 bit Arch Linux. The next 9 months are deprecation period, during which i686 will be still receiving upgraded packages. Starting from November 2017, packaging and repository tools will no longer require that from maintainers, effectively making i686 unsupported.

However, as there is still some interest in keeping i686 alive, we would like to encourage the community to make it happen with our guidance. The arch-ports mailing list and #archlinux-ports IRC channel on Freenode will be used for further coordination.

The [multilib] repository will not be affected by this change.

Original Article

The new version comes with the following changes:

  • xf86-input-libinput is the default input driver, however synaptics, evdev and wacom are still available.

  • These packages are deprecated and moved to AUR: xf86-input-joystick, xf86-input-acecad, xf86-video-apm, xf86-video-ark, xf86-video-chips, xf86-video-glint, xf86-video-i128, xf86-video-i740, xf86-video-mach64, xf86-video-neomagic, xf86-video-nv, xf86-video-r128, xf86-video-rendition, xf86-video-s3, xf86-video-s3virge, xf86-video-savage, xf86-video-siliconmotion, xf86-video-sis, xf86-video-tdfx, xf86-video-trident, xf86-video-tseng

Original Article

The TalkingArch Iso

The TalkingArch team is proud to present the first TalkingArch iso of 2017. This one is the second to fix a problem with Portaudio that was causing Espeak to crash. It comes with the latest packages, including Linux kernel 4.8.13. Find it in the usual place.

Social Media

TalkingArch is now on Twitter. Follow us, tweet @ us, or even retweet release announcements, which will post there as well as here. All other ways of contacting TalkingArch still work; nothing is going away.

The Fall of i686

There has been significant talk over the past 2 to 3 weeks on the Arch Linux e-mail list about dropping support for the i686. architecture. The upshot of the discussion is that by the end of this year, no further i686 packages will be uploaded to the official repositories. To that end, Arch will most likely be producing only x86_64 isos starting in February, ending the dual architecture builds. Because TalkingArch stays as close to Arch as is possible, if Arch does stop producing dual architecture builds in February, TalkingArch will do the same. However, if an i686 version is needed, as long as packages are still being uploaded to the official repositories, an i686 build of TalkingArch can be made available upon request. That said, it will still be possible for some months to use this dual architecture build to install Arch Linux until such time as they remove i686 packages from the repositories, and that link will continue to work as long as it is usable. Thanks for the support over the years, and we look forward to serving you the latest and greatest TalkingArch for many years to come.

Original Article