Step Outline For Rebuilding AUR Packages In Arch

Once again Arch updates for webkitgtk breaks gnucash. Gnucash is an accounting / cash application i depend on for keeping track of my expenses. It’s been moved from the official repos to the Arch User Repo or AUR. What this means for users is that responsibility for updates (including dependencies) passes solely to users. Any dependencies that get updates must be rebuilt. The only problem with webkitgtk rebuild is that it takes ages to build it. In my case it is 4 hours.

First, check if your system has the tools.
# sudo pacman -S base-devel git dev-tools –needed

Prepare the filesystem on which you will build the package.
# sudo mount -o remount,exec,suid /tmp
# sudo mkdir /tmp/source/chroot -p
# cd /tmp/source

Create the chroot.
# sudo mkarchroot chroot/root base-devel

It’s time to get the package sources.
# git clone “https://aur.archlinux.org/package_name.git”
# cd package_name_directory
# makechrootpkg -T -r ../chroot/
The -T flag creates a temporary chroot directory while the -r flag points to the original chroot directory.

You will have to repeat the steps above for all the packages that needed to be built and copy the *.pkg.tar.xz to the /var/cache/pacman/pkg diirectory. Copying the built package to the pacman cache directory means you don’t have to build all the packages again unnecessarily every time updates happen. You only build those packages affected.

Copy the *.pkg.tar.xz to /var/cache/pacman/pkg/.
# sudo cp *.pkg.tar.xz /var/cache/pacman/pkg/

Build the main package.
# makechrootpkg -T -r ../chroot/ -I /path-to-package/package_name.pkg.tar.xz

Install the package.
# sudo pacman -U /path-to-package/package_name.pkg.tar.xz

Update Firefox 57 –>> 58

Mozilla made a new version of Firefox browser available for download.

Problem With Mail Authentication In Evolution Mail

I encounter this pervasive and nagging bug in Evolution Mail’s strange relationship with its co-GNOME app called Seahorse (although this app goes by the name of Password And Keys now in GNOME 3.26). I have a secondary email account and I want to use it for sending mail (smtp) temporarily (just in this case). So I finished composing my email and clicked send. Then it asked me for my smtp password and I thought that was odd because I have been receiving my email in the inbox for this account. It’s unlikely a user would have a different password for login and another for sending email. But I found my password from my password manager and gave it the correct one ( copy and paste). And here it began, the Mail Authentication Failure window from Evolution continually asking for the password. I checked Seahorse for the password by entering a filter in the search bar. It has my password and it is the correct password. So what is happening here?

I found this same problem in the Ubuntu forum and Ask Ubuntu forum where there were several suggestions of deleting the email account in Evolution, or deleting the entry for the email account tokens in Seahorse. There was even a couple of patches introduced back in 2014 so it should be included in the latest version of Evolution Mail and Seahorse. But again here we are.

My last desperate attempt at fixing my problem comes through the GNOME Online Accounts where it is now just a tab in Settings.

So here goes. My first step was to close both Seahorse and Evolution. Then I opened Evolution, to verify the problem is still there. I might have logout too. But I don’t see the point.

I disabled the account. In my case I have only one account nagging me. So I disable it by going to ALT+E(dit), A(ccount) and choosing the account.

I opened the GNOME Online Accounts and choose the available services as you can see above. This is when I remember that I didn’t create an account here for GOA. Tip: if you have an account in Evolution and it didn’t come through GOA you might encounter this problem.

That’s it. Once the account is created in GOA, it appears in Evolution. And no nagging.

Add Support To Your Firefox For Torrent Files Magnet Links

I found it tedious to add magnet links manually to my torrent client, Transmission. By manually, I mean I right click on the magnet link icon on the torrent web site and copy the link to memory. Then I open Transmission and type CNTRL+U, then ENTER,twice. When I click that magnet link I want firefox to be able to transfer control to another application which can handle the type of file I’m clicking.

I found a solution in the Mozilla forums, thanks.

Open a new tab in firefox. Then go to about:config. Be careful when you’re editing your firefox config. In the search bar type handler.expose. Right click anywhere in the window and choose New–>>Boolean. In the new window popup, type Network.protocol-handler.expose.magnet. Then close the tab.

You should be able to click (normally) on the magnet link of that torrent web site and firefox will transfer control to your default torrent client. Otherwise a popup will prompt you to fill in your preferred torrent client.

Firefox Update 57.0.3.x –>> 57.0.4-1

~]$ sudo pacman -Syu
[sudo] password for USER:
:: Synchronizing package databases…
core is up to date
extra 1639.0 KiB 144K/s 00:11 [#####################################] 100%
community 4.2 MiB 115K/s 00:37 [#####################################] 100%
DEB_Arch_Extra 1994.0 B 0.00B/s 00:00 [#####################################] 100%
DEB_Arch_Extra.sig 280.0 B 0.00B/s 00:00 [#####################################] 100%
:: Starting full system upgrade…
resolving dependencies…
looking for conflicting packages…

Packages (4) firefox-57.0.4-1 python-setuptools-1:38.4.0-1 subversion-1.9.7-4 whois-5.2.20-1

Updates for firefox 57.0.3 to 57.0.4-1 includes patches for mitigating Meltdown and Spectre. While operating system vendors are pushing patches for their users it isn’t clear how much is enough to stop the exploits. Some say this problem with kernel memory leaks due to aggressive processor action will continue until a firmware update or if the user just buys another non-Intel processor. Researchers say that most AMD processors are immune to the exploits. ARM and Raspberry processors are immune to the exploits too. It is also clear now that these patches will have performance hits especially with virtual machines, meaning those being used in cloud services.

Tech Joke..

What is 2 + 2 ?

Intel: 5

AMD: 4

Intel: Ok he’s right but we were first.

Edit: It has been 4 days since I post this. All the major chip vendors are affected. I repeat, all major chip vendors are affected. The performance hit from the patches will be the greatest on VM because users share the CPU.

Massive Vulnerability Resulting In Meltdown and Specter Attacks

I planned to update Arch every 10 days but since updating some 3 days ago, news of a massive vulnerability in the chip processor all computers use came out. There are two demonstrated attacks called Meltdown and Specter. So let me use the language of the OpenSuse security patch email here to explain what these are.

CVE-2017-5753 / “SpecŧreAttack”: Local attackers on systems with modern

CPUs featuring deep instruction pipelining could use attacker
controllable speculative execution over code patterns in the Linux
Kernel to leak content from otherwise not readable memory in the same
address space, allowing retrieval of passwords, cryptographic keys and
other secrets.

This problem is mitigated by adding speculative fencing on affected code
paths throughout the Linux kernel.

– CVE-2017-5715 / “SpectreAttack”: Local attackers on systems with modern
CPUs featuring branch prediction could use mispredicted branches to
speculatively execute code patterns that in turn could be made to leak
other non-readable content in the same address space, an attack similar
to CVE-2017-5753.

This problem is mitigated by disabling predictive branches, depending
on CPU architecture either by firmware updates and/or fixes in the
user-kernel privilege boundaries.

Please also check with your CPU / Hardware vendor on updated firmware
or BIOS images regarding this issue.

As this feature can have a performance impact, it can be disabled using
the “nospec” kernel commandline option.

– CVE-2017-5754 / “MeltdownAttack”: Local attackers on systems with modern
CPUs featuring deep instruction pipelining could use code patterns in
userspace to speculative executive code that would read
otherwise read protected memory, an attack similar to CVE-2017-5753.

This problem is mitigated by unmapping the Linux Kernel from the user
address space during user code execution, following a approach called
“KAISER”. The terms used here are “KAISER” / “Kernel Address Isolation”
and “PTI” / “Page Table Isolation”.

Note that this is only done on affected platforms.

This feature can be enabled / disabled by the “pti=[on|off|auto]” or
“nopti” commandline options.

Linux distros have pushed patches so I’m doing an update today. I’m updating my mirrors first with.

$ reflector –latest 8 –protocol https –sort rate –save /etc/pacman.d/mirrorlist

Then I update my system with —

$ pacman -Syu

I should be receiving the same patch that OpenSuse pushed to their users.

DNScrypt

It is important to encrypt your dns traffic. That’s the queries from your computer to a dns server. My dns resolv.conf contains:

nameserver 8.8.8.8
nameserver 203.111.231.106

I went ahead and installed dnscrypt-proxy package from the official repository. To check files for dnscrypt-proxy type this in the terminal. $ sudo pacman -Ql dnscrypt-proxy. It will be /etc/dnscrypt-proxy.conf. The config file for dnscrypt is explicit and looks like this essentially:

ResolverName random

You can change “random” to a specific dnscrypt-proxy name from /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv. I recommend this because I encounter a “unable to read” error in the logs when I try it the “random” way. Use chattr +i “path-to-file” to set the property of the file to read-only. NetworkManager will try to modify /etc/resolv.conf. Modify this file to:

nameserver 127.0.0.1

Use dig to check the status of your dns server.

# dig 127.0.0.1 google.com

Enable and start dnscrypt-proxy service in systemd.

Check the logs in Arch with:

$ sudo journalctl | grep dnscrypt-proxy

SMTP Is Now Working With S-nail (Simple Sendmail)

The new Arch install needs to be able to send email to an outside smtp server. Or use an outside smtp server like my google account. Arch has s-nail by default and could out of the box send mail within its own network. But what I’m talking about is using Google smtp to send mail. The configuration file for s-nail are /etc/mail.rc and ~/HOME/.mailrc.

I began my config file with these in it.

set smtp=smtp://email_addr:password-app ##colon separated values

I saved the text file in ~/.mailrc. Then do a test send mail with the -d flag on to see what’s happening wrong. It will tell you what’s being loaded and line by line call of the config file. This is how my config file looks now with my goals accomplished.

set smtp-use-starttls
set smtp=smtp://smtp.gmail.com:587
set smtp-auth=login
set smtp-auth-user=USERNAME
set smtp-auth-password=<password-app>
set from=”USER_EMAIL_ADDR<hostname.domain>”

For Google Mail it is important that you use the app password for the 2-way authentication in the Google web site. For the hostname.domain you can use your name but I like to use my hostname.