Functionality and Customization of the Meilix Metapackage meilix-default-settings

Meilix has is made of build file and metapackages. Build file is responsible for executing commands and successfully implementing the work of metapackages.

Metapackages in Meilix
Name of metapackages used in Meilix are: meilix-artwork, meilix-default-settings.

meilix-default-settings

meilix-default-settings have 3 major folders debian, etc and usr and a Makefile. We are only concerned with etc and usr folder here.
etc and usr folders are folders in which if changes are made that can be seen the ISO. One can assume this as two folders present in the root folder of a Linux Distro.

Its directory is like this:

meilix-artwork

meilix-artwork has 1 main folder named as usr which contain share folder in which plymouth configuration is made. One can make changes here and it will directly seen in the Linux Distro.

Its directory looks like this:

How these meta packages actually work?
To get the answer one has to jump into the debian folder of any of the metapackage. It contains a control file. This contains information of the metapackages.

Source: meilix-default-settings
Section: x11
Priority: extra
Maintainer: meilix <vanhonit@gmail.com>
Build-Depends: debhelper (>= 8.0.0)
Standards-Version: 3.9.2
Homepage: http://mbm.vn

Package: meilix-default-settings
Architecture: all
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: default settings for meilix
 Various system settings tailored for meilix.

One can update the metapackage from here and tweak with its depends. One come to know about the maintainer of the metapackage which can contacted in case of any issue. We can also know for which architecture this metapackage is made and about its description.
The whole debian does the work but after making any changes in the metapackage, it needs to be rebuild which is performed by debuild.sh. This is how a metapackages in Meilix works.

References:
Linux MetapackagesMatthartley from linux.com
Creating a MetapackageAjmitch from askubuntu.com

Updating of Linux Standard Base (lsb) and Shorten of log of Meilix Build

Updating the Linux Standard Base of the Meilix

Originally Meilix uses the Ubuntu mirror to fetch the Kernel source for the building of the Operating System. Therefore whenever a user type lsb_release -a for fetching the required information, they get the Ubuntu build info. The task is to change the config file to update the Linux Base Information from Ubuntu to Meilix.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty

We need to patch a file in the location meilix-default-settings/etc/lsb-release which contains the information of the lsb release and this will overwrite the original configuration of Meilix.
This is how the lsb-release file looks like now:

DISTRIB_ID=Meilix
DISTRIB_RELEASE=17.04
DISTRIB_CODENAME=meilix
DISTRIB_DESCRIPTION="Meilix 17.04"

We made the required changes in the file as shown above and the output is as follows:

Shorten the log length of Meilix in Travis

We are facing issues while deployment of Meilix ISO in Travis and the error follows is ReadTimeout Error. Example log of one of fail build is:

This error gets solved automatically and the the ISO gets deployment after 1 or 2 restart of the build. But this time the error doesn’t get solved and after several attempts of restart of build, the ISO doesn’t get deployed.

Reason behind the error:

Travis is taking a lot of time to build the ISO. Travis logs are exceeding the time limit.

Proposed solution:

Reduce the time of build or shift to a new CI.
Reduce the log of the build so as to get the log within 9999 lines.

Solution Implemented

The best solution is to reduce the number of lines used in the log and this will also reduce the time of the build.
I tried concealing some command outputs by appending >/dev/null 2>&1 to some of the commands that has long outputs and adding -y to the commands like:

apt-get -qq -y --purge install file-roller unrar

References

Wiki of Linux Standard Base
Linux Foundation lsb
Ubuntu answer to reduce log

Configuration for Auto-hiding Panel in Meilix with LXQt desktop

In the new LXQt desktop, we can intelligently hide the panel. For that purpose, we’ll just need to patch a new file in a location under the meilix-default-settings metapackage.
Originally the file lies in the lxqt folder of the .config of the OS with the name panel.conf like .config/lxqt/panel.conf but since we have to make changes in the metapackage, we need to patch it here meilix-default-settings/etc/skel/.config/lxqt/panel.conf. Files in etc/skel/ will be put in each users’ new home folder, a folder which does not exist yet when we build the ISO.

panel.conf

1. [panel1]
2. alignment=-1
3. animation-duration=0
4. background-color=@Variant(\0\0\0\x43\0\xff\xff\0\0\0\0\0\0\0\0)
5. background-image=
6. desktop=0
7. font-color=@Variant(\0\0\0\x43\0\xff\xff\0\0\0\0\0\0\0\0)
8. hidable=true
9. iconSize=22
10. lineCount=1
11. lockPanel=false
12. opacity=100
13.panelSize=32
14. plugins=mainmenu, desktopswitch, quicklaunch, taskbar, tray, statusnotifier, mount, volume, clock, showdesktop
15. position=Bottom
16. show-delay=0
17. width=100
18. width-percent=true

In the line number 8 , hidable=true is doing all the jobs. It is the only line which hides the panel by default.

How we find this approach?
Originally LXQt panel is not hidden, they are shown by default. I first try to locate panel.conf file which will carry out the configuration for the panel. I try to find the code responsible for hiding the panel, but I can’t find that. Then I copied the panel.conf in a file and then by GUI I hide the panel and reopen the config file. Then I compare the changes between this file and the old config.panel file in which I found that the new file has a new line hidable=true. We introduced the changes in this PR.

How this approach actually work?
We are using meilix-default-settings metapackage to make the things work. We made an .config file which contains the configuration file. And the .config file is present under skel folder which gets copied under the home folder of the user. Thus ultimately we get a configuration file which will overwrite the original one to get the desired changes.

Other Uses of panel.conf
The file panel.conf could be used to customize all related settings to the LXQT panel, like its alignment, volume bar, quick launch, show desktop, etc.

References:
LXQt panel hiding
Customize LXQt desktop

Debuilding the meilix-default-settings Metapackage

In the Meilix code repository you find a metapackage named meilix-default-settings which contains custom settings in directories as debian, etc, and user. In these directories one can make changes to make them be included in the build ISO. As Meilix runs on Debian we package our custom user settings in a Debian package to be installed along all the other software packages. The process and utility to make a Debian package is called debuild.

Directories in the meilix-default-settings:

What is debuilding?

It’s Debian slang for “making a deb package” and that stirred quite some confusion in our communications. Debuild is actually a rebuilding of the metapackage. But as to rebuild the Debian package you usually type debuild -uc -us therefore I stick to the language

Suppose someone has edited a configuration file in the metapackage according to its desires to achieve a specific result in the ISO it won’t get in unless he rebuilds the metapackage.He has not only to edit the metapackage but also to rebuild it to get the desired output in the ISO. To make the process automated, we have made a tiny script which will debuild the metapackages during each and every build, we only need to modify the metapackage.

Actually the first meilix-default-settings folder is the only metapackage and inside of it is the sub-metapackage which is responsible to get the changes applied in the ISO. To see a change in the ISO, we only need to edit the meilix-default-settings usr or etc folder in the first layer. Then, we need to debuild the metapackages.

Code-Base:

This file is present here

1. #!/bin/bash
2. rm meilix-default-settings_*                                    
3. cd meilix-default-settings                                      
4. debuild -uc -us

Let’s go through the whole code base line by line:
Line 2 deletes the previous meilix-default-settings binary packages.
Line 3 in this we changed our directory to the metapackage folder that is of our concern.
Line 4 is the most important line, it builds the whole metapackage and brings back all the binary packages and metapackages after making the desired changes.

Follow the example below to know that actually how it works:

This pull request is responsible to turn off system sounds by default in the generated ISO. Pull Requests files in which I only edited the this file and rest of the files get changes in the process of debuilding the metapackage (ignore .travis.yml file).

References:
Required files under debian directory
Debian directory guideline

How to make changes in Meilix Without rebuilding the ISO

We were building Meilix from build scripts from webapp which was taking 20 minutes approx. So to reduce that time we had an idea of using a pre built ISO as it requires fewer resources and less time as compared to the building the ISO from build script and makes modifications in it which would take less time after testing it took approx 8 minutes. The following steps were followed to edit Meilix ISO.

We require following packages for unpacking and repacking the ISO.

  • squashfs-tools
  • Genisoimage

Let’s start by unpacking the ISO. For that, we first mount the ISO.

sudo mount -o loop meilix-zesty-20170611-i386.iso mnt/

 

Now we extract the content of the ISO into a directory extract-cd and extract the squash file system and move it to edit folder to prepare chroot.

sudo rsync --exclude=/casper/filesystem.squashfs -a mnt/ extract-cd
sudo unsquashfs mnt/casper/filesystem.squashfs
sudo mv squashfs-root edit

 

Now we can chroot and do the editing we require to do in the ISO.

sudo mount -o bind /run/ edit/run
sudo cp /etc/hosts edit/etc/
sudo mount --bind /dev/ edit/dev
sudo chroot edit

 

After doing the changes in chroot. For doing changes we can make a separate script to be executed inside the chroot.

exit
EOF
sudo umount edit/dev

 

After completing all the changes we required in the ISO the important part comes that is repacking the ISO with the applied changes.

Regenerate the manifest.

sudo chmod +w extract-cd/casper/filesystem.manifest
sudo su <<HERE
chroot edit dpkg-query -W --showformat='${Package} ${Version}\n' > extract-cd/casper/filesystem.manifest <<EOF
exit
EOF
HERE
sudo cp extract-cd/casper/filesystem.manifest extract-cd/casper/filesystem.manifest-desktop
sudo sed -i '/ubiquity/d' extract-cd/casper/filesystem.manifest-desktop
sudo sed -i '/casper/d' extract-cd/casper/filesystem.manifest-desktop

 

Now we compress the file system we have just edited.
For higher compression we can increase the block size or use xz but that will increase the cost of compression time so we didn’t choose it for Meilix as we required a faster method.

sudo mksquashfs edit extract-cd/casper/filesystem.squashfs -noappend

 

Now we are going to calculate the MD5 sums again for the changes and replace them with the older MD5 sums.

cd extract-cd/ && find . -type f -not -name md5sum.txt -not -path '*/isolinux/*' -print0 | xargs -0 -- md5sum > md5sum.txt

 

Last step is to go in the edit directory and generate the ISO.

mkisofs \
    -V "Custom Meilix" \
    -r -cache-inodes -J -l \
    -b isolinux/isolinux.bin \
    -c isolinux/boot.cat \
    -no-emul-boot -boot-load-size 4 -boot-info-table \
    -o ../meilix-i386-custom.iso .

 

This covers all the steps need to make changes in Meilix without rebuilding ISO.

Resources:

Sending e-mail from linux terminal

So while finalizing the apk-generator for my GSoC project, I faced a roadblock in sending the generated App to the organizer.

Normally the build takes around 10–12 minutes, so asking the user to wait for that long on the website and then providing him/her with a download link did not feel like a good option. (amirite?)

So I and Manan Wason thought of a different approach to this problem, which was to email the generated app to the organzier.

For doing this, we used 2 handy tools MSMTP and Mutt.
We can use MSMTP to send email but unfortunately we cannot include attachments, so we used Mutt to help us send email with attachments from the command line.
So hang tight and follow the rest of the guide to start sending emails from your terminal and get yourself some developer #swag

Step 1 : Installation

Use the following commands to install MSMTP and Mutt

sudo apt-get -y install msmtp
sudo apt-get -y install ca-certificates
sudo apt-get -y install mutt

We need to have a file that contains Certificate Authority (CA) certificates so that we can connect using SSL / TLS to the email server.

Step 2 : Configuring MSMTP

Now we’ll MSMTP configuration on /etc/msmtprc with the content below. NOTE : You will have to enter your username and password on this file so make sure to make this file private.

Lets first open this file

nano /etc/msmtprc

Next, add following text to the file,

account default
tls on
tls_starttls off
tls_certcheck off
auth on
host smtp.mail.yahoo.com (change this to smtp.gmail.com for gmail)
user username
password password
from [email protected]
logfile /var/log/msmtp.log

NOTE : Refrain from using gmail as they might terminate your account for sending email via MSMTP.

For configuring mutt, we’ll use a similar command to edit the file located at /root/.muttrc

nano /root/.muttrc

Add following text to it which specifies the MSMTP account to use for sending email

set sendmail=”/usr/bin/msmtp”
set use_from=yes
set realname=”MY Real Name”
set [email protected]
set envelope_from=yes

That’s it!
Now lets get ready for the fun part, SENDING THOSE EMAILS 😀

Step 3 : Sending

Now, there are 2 cases that might arise while sending the email,

1 : Sending without attachment

This is pretty straightforward and can be done with either MSMTP or Mutt.

Using MSMTP

printf “To: [email protected]: [email protected]: Testing MSMTPnnHello there. This is email test from MSMTP.” | msmtp [email protected]

Entering the following code will send the email to the recipient and also display the sent email in the terminal.

Using Mutt

mutt -s “Testing Mutt” — [email protected] < /path/to/body.txt

NOTE : ‘body.txt’ is the file whose contents will be used in the body of the email that will be sent to ‘[email protected]’.

2 : Sending WITH an attachment

Unlike the previous case, this can be done ONLY using Mutt and the code used is

mutt -a /path/to/attachment.txt -s “Testing Mutt — [email protected] < /path/to/body.txt

The syntax is similar to the above case where we sent the email without attachments.

So well, that it then!
If you followed the instructions carefully, you will have a working email client built into your terminal!
Pretty cool right?

So that’s it for this week, hope to catch you next week with some more interesting tips and tutorials.

Linux Foundation Certification at FOSSASIA 2015 in Singapore

We’re happy to bring you good news from the Linux Foundation in cooperation with OlinData: You can take a Linux Foundation exam at FOSSASIA Singapore for a special one-time 33% discount. It is possible to get yourself certified for both the Linux Foundation Certified Engineer (LFCE) and the Linux Foundation Certified System Administrator (LFCS). We’ll have a dedicated room on Saturday March 14, 2015 at Blk71 where you can sit down in all quietness and take the examination so you can walk away with one of the highest quality Linux Certification in the industry.

A Linux Foundation Certified System Administrator (LFCS) has the skills to do basic to intermediate system administration from the command-line for systems running Linux. Linux Foundation Certified System Administrators are knowledgeable in the operational support of Linux systems and services. They are responsible for first line troubleshooting and analysis, and decide when to escalate issues to engineering teams. More information here: training.linuxfoundation.org/certification/lfcs

If you want to make sure you are prepared for the LFCS exam we have a great deal for you: By taking a special edition of the online self-paced course for the LFCS certification, you’ll be well prepared for the LFCS certification and at the same time supporting FOSSASIA: The Linux Foundation has promised to sponsor 100 USD for each online course sold. Please go here for more information and Sign Up Now.

A Linux Foundation Certified Engineer (LFCE) possesses a wider range and greater depth of skills than the Linux Foundation Certified System Administrator (LFCS). Linux Foundation Certified Engineers are responsible for the design and implementation of system architecture. They provide an escalation path and serve as Subject Matter Experts (SMEs) for the next generation of system administration professionals. More information here: http://training.linuxfoundation.org/certification/lfcs

Meetup of Beijing Linux User Group with Dang Hong Phuc from FOSSASIA

Hong Phuc Dang FOSSASIA, Women in IT Asia

Please join our FOSSASIA Bejinglug meetup with Dang Hong Phuc in Bejing, China on December 6, 2015. Hong Phuc will give insights about the FOSSASIA network, the programs of FOSSASIA and the FOSSASIA summit 2015 in Singapore.

FOSSASIA runs contributors, Open Source developers and hardware maker programs in cooperations with companies and communities such as Google Summer of Code and Google Code-In (current Code-In program until January 19).

For our programs in 2015 we are looking for mentors and students of Open Technology projects who would like to join us and register their groups on the FOSSASIA community network.

The FOSSASIA summit will take place from March 13-15 in Singapore. The call for papers is open until December 20. If you are interested to present at the event, please register here: fossasia.org/speaker-registration/

Time: 18:00
Date: Saturday, December 6, 2014
Location: Jazz Island Coffee (爵士岛咖啡二楼)
Address (Chinese): 东城区东直门内大街东扬威街11号楼(来福士大厦对面北侧)
Map: mapbar (via dianping)
Subway: Dongzhimen Exit A
Phone: 010-8406-1040

Links:

Beijinglug Announcement: http://beijinglug.org/…

FOSSASIA Community Network: http://fossasia.net

FOSSASIA Summit Speaker Registration: http://fossasia.org/speaker-registration/

FOSSASIA Code-In: http://www.google-melange.com/gci/org/google/gci2014/fossasia

Meilix System Lock released

We released the first version 0.1 of Meilix System Lock. It is an application that can lock or “freeze” your system.

The application is based on Ofris, but it offers more features like a simple graphic interface to lock or unlock the system. Main developer is Hon Nguyen (Vanhonit) from Vietnam, who started the tool as part of his Google Summer of Code project for FOSSASIA.

The sourcecode is here on github: https://github.com/meilix/systemlock

A couple of Meilix System Lock Screenshots.

Meilix System Lock

How to create a Fedora spin – Developer Meet Up in Hong Kong

Hon Nguyen (Vietnam), Dicky (Hong Kong), Hong Phuc (Vietnam) (from right to left)

Dicky (Hong Kong) and Mathieu Bridon (France)

At our meet ups at GNOME.Asia in Hong Kong it was great to meet developers from different continents. One thing we were particularly interested in is, how to create a custom Linux based on Fedora Linux.

Well, we were lucky to meet Mathieu Bridon (Blog). There are some pictures below. Even though some pictures might look just like socializing in a pub, we actually took quite late until the eve to learn about using Kickstart files to create our own custom Linux. Thank you! So the how to of Mathieu below first.

== Building your downstream distro ==

From a Fedora system:
    # yum install spin-kickstarts pungi

See the kickstarts used to create the various Fedora spins in:
    /usr/share/spin-kickstarts/*

Use that as examples, the actual kickstart doc is at:
    http://fedoraproject.org/wiki/Anaconda/Kickstart

Then once you have your kickstart file:
    # pungi -c [your kickstart file]

(see pungi -h for all the options)

== Avoiding trademark issues ==

Replace fedora-logos by generic-logos to avoid the Fedora trademarks.

Clone the git repository for the package spec file:
$ fedpkg clone -a generic-logos
$ cd generic-logos

Fetch the source tarball:
$ fedpkg sources

Make your own tarball following the layout and file names.

Rename the spec file (and change the Name: tag):
Name:       xmario-logos
Version:    17.0.0
[… snip …]
Source0:    https://fedorahosted.org/released/%{name}/%{name}-%{version}.tar.bz2

See how the tarball is named like the spec file?

Rebuild:
$ fedpkg mockbuild

== Caching packages ==

1. Synchronize the whole repository:
$ yum install yum-utils
$ reposync -r fedora -r updates -p /path/to/repository_cache

2. Keep in cache the packages you install:
  1. set keepcache=1 in /etc/yum.conf
  2. install, update,…
  3. $ find /var/cache/yum -name ‘*.rpm’

3. Download packages:
$ yum install yum-utils
$ yumdowloader foo
$ yumdownloader –resolve foo

Some different approaches to repo caching:
http://yum.baseurl.org/wiki/YumMultipleMachineCaching

 

If you need to make an install media (not live), you’ll have to maintain
a trivial patch to anaconda.

$ fedpkg clone -a anaconda
$ cd anaconda
$ fedpkg prep
$ cd anaconda-$version
$ git init
$ git add .
$ git commit -m prepped
$ cp pyanaconda/installclasses/{fedora.py,xmario.py}

Replace all occurences of “fedora” by “xmario” in the file you copied,
and give it a **higher** priority (bigger number) than all other install
classes so that yours is used.

Create a patch that adds your modifications. I like to use git for that,
but you can just use the diff command if you prefer:
$ git commit -a -m “Create our install class for X-Mario”
$ git format-patch HEAD~1
$ mv 0001-*.patch ..
$ cd ..

Add the patch to the spec file header:
    [… snip …]
    Patch1000000: 0001-blabla.patch
    [… snip …]

Apply at the end of %setup:
    %patch1000000 -p1

Bump the “Release:” tag and add a changelog message in %changelog.

Commit to git:
$ git add 0000*.patch anaconda.spec
$ git commit -m “Bla bla bla commit message”

Rebuild:
$ fedpkg mockbuild

More about fedpkg:
http://fedoraproject.org/wiki/Using_Fedora_GIT

Mathieu Bridon and Sammy Fung (HK)