dnf and yum show different updates

Problem

I have started to use dnf in Fedora 20 more than yum. I do miss drpm and yum ps when using dnf but it works just fine. Today, I ran into a problem where yum and dnf saw different updates.

root @ codeghar [~] $ yum check-update
Loaded plugins: langpacks, ps, refresh-packagekit
updates/20/x86_64/metalink                                          |  16 kB  00:00:00     
updates                                                             | 4.6 kB  00:00:00     
updates/20/x86_64/primary_db                                        | 7.2 MB  00:00:02     
(1/2): updates/20/x86_64/updateinfo                                 | 660 kB  00:00:00     
(2/2): updates/20/x86_64/pkgtags                                    | 887 kB  00:00:05     

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates


root @ codeghar [~] $ dnf check-update

NetworkManager.x86_64                   1:0.9.9.0-28.git20131003.fc20               updates
NetworkManager-glib.x86_64              1:0.9.9.0-28.git20131003.fc20               updates
clutter.x86_64                          1.16.2-3.fc20                               updates
glibc.x86_64                            2.18-12.fc20                                updates
glibc-common.x86_64                     2.18-12.fc20                                updates
glibc-devel.x86_64                      2.18-12.fc20                                updates
glibc-headers.x86_64                    2.18-12.fc20                                updates
pango.x86_64                            1.36.1-2.fc20                               updates

Solution

There’s a forum post (dnf and yum seeing different updates) and one solution was to clear the caches.

root @ codeghar [~] $ yum clean expire-cache
Loaded plugins: langpacks, ps, refresh-packagekit
Cleaning repos: fedora updates
2 metadata files removed


root @ codeghar [~] $ dnf clean expire-cache
Cleaning repos: fedora updates
The enabled repos were expired

I then ran check-update on both yum and dnf and that solved the problem. dnf check-update needed to be run twice but it was no big deal.

root @ codeghar [~] $ dnf check-update
Error: Problem with repo 'updates': Cannot prepare internal mirrorlist: Curl error: Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f20&arch=x86_64


root @ codeghar [~] $ dnf check-update
Fedora 20 - x86_64 - Updates                               3.2 MB/s |  15 MB     00:04    

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates

root @ codeghar [~] $ yum check-update
Loaded plugins: langpacks, ps, refresh-packagekit
fedora/20/x86_64/metalink                                           |  18 kB  00:00:00     
updates/20/x86_64/metalink                                          |  16 kB  00:00:00     

NetworkManager.x86_64                       1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-glib.x86_64                  1:0.9.9.0-28.git20131003.fc20           updates
NetworkManager-openvpn.x86_64               1:0.9.9.0-0.1.git20140128.fc20          updates
NetworkManager-openvpn-gnome.x86_64         1:0.9.9.0-0.1.git20140128.fc20          updates
anaconda.x86_64                             20.25.16-1.fc20                         updates
anaconda-widgets.x86_64                     20.25.16-1.fc20                         updates
clutter.x86_64                              1.16.2-3.fc20                           updates
curl.x86_64                                 7.32.0-4.fc20                           updates
glibc.x86_64                                2.18-12.fc20                            updates
glibc-common.x86_64                         2.18-12.fc20                            updates
glibc-devel.x86_64                          2.18-12.fc20                            updates
glibc-headers.x86_64                        2.18-12.fc20                            updates
kernel.x86_64                               3.12.9-301.fc20                         updates
kernel-debug-devel.x86_64                   3.12.9-301.fc20                         updates
kernel-devel.x86_64                         3.12.9-301.fc20                         updates
kernel-headers.x86_64                       3.12.9-301.fc20                         updates
kernel-modules-extra.x86_64                 3.12.9-301.fc20                         updates
libcurl.x86_64                              7.32.0-4.fc20                           updates
pango.x86_64                                1.36.1-2.fc20                           updates

Install Arch Linux on ESX 5.5

I have been meaning to delve into Linux with Arch for a while. I’ve been using a VM in ESX to learn the install process. The installation has been pretty easy maybe because I have spent a fair number of years using Linux. The Arch wiki is an awesome resource and one mistake I keep making is not reading the whole page. This causes many headaches that could be avoided if I didn’t just gloss over the information.

Anyways, I wanted to provide a simple step-by-step tutorial to serve as a quick checklist. Remember that these steps can quickly get out of date as Arch moves fast. So always reference the Arch wiki first. Here are the major steps.

  1. Download Arch installer
  2. Create VM
  3. Boot VM and install Arch

I downloaded the dual 2013.12.01 version of the installer: archlinux-2013.12.01-dual.iso. The VM I created was of “type” Red Hat Enterprise Linux 6 (64-bit) and had 2 dual-core CPUs, 2GB memory, 100GB disk, and EFI was enabled. I attached the installer ISO and started the VM. These instructions begin from when you get the root console after boot up.

Initial Steps

Check to make sure EFI is recognized and working.

efivar -l

I didn’t have DHCP running so instead used static IP. Find the name of your NIC; mine was ens32.

ip link

Setup IP address and gateway

ip addr add 192.168.0.55/24 dev ens32

ip route add default via 192.168.0.1

Configure DNS.

echo "nameserver 8.8.8.8" >> /etc/resolv.conf

echo "search codeghar.com" >> /etc/resolv.conf

Disk Partitioning

Get the name of the disk. It was sda in my case.

lsblk

I used LVM because I wanted to learn a bit more about it. I also prefer to have a single root partition because it makes things easier for me. I used parted to partition my disk into four partitions: 1 for boot and 3 for root.

parted /dev/sda print

parted /dev/sda mklabel gpt

parted /dev/sda mkpart primary 1049KB 2GB

parted /dev/sda mkpart primary 2GB 19GB

parted /dev/sda mkpart primary 19GB 49GB

parted /dev/sda mkpart primary 49GB 99GB

parted /dev/sda set 1 boot on

parted /dev/sda set 2 lvm on

parted /dev/sda set 3 lvm on

parted /dev/sda set 4 lvm on

parted /dev/sda print

lsblk

LVM

pvdisplay

pvcreate /dev/sda2

pvcreate /dev/sda3

pvdisplay

vgdisplay

vgcreate vgcodeghar /dev/sda2

vgextend vgcodeghar /dev/sda3

vgdisplay

lvdisplay

lvcreate -L 25G vgcodeghar -n lvroot

lvdisplay

modprobe dm-mod

vgscan

vgchange -ay

Format the first partition as FAT32 because we’ll use it for /boot and EFI requires(?) the boot partition to be FAT32.

mkfs.fat -F32 /dev/sda1

mkfs.ext4 /dev/mapper/vgcodeghar-lvroot

Base Install

mount /dev/mapper/vgcodeghar-lvroot /mnt

mkdir -p /mnt/boot

mount /dev/sda1 /mnt/boot

pacstrap /mnt base

genfstab -U -p /mnt >> /mnt/etc/fstab

cat /mnt/etc/fstab

Base Configuration (Start)

arch-chroot /mnt

Base Configuration – Swap File

Instead of a swap partition I decided to use a swap file.

fallocate -l 4G /swapfile

chmod 600 /swapfile

mkswap /swapfile

swapon /swapfile

echo "/swapfile none swap defaults 0 0" >> /etc/fstab

cat /etc/fstab

Base Configuration – Locale

sed -i -e 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/g' /etc/locale.gen

locale-gen

echo LANG=en_US.UTF-8 > /etc/locale.conf

export LANG=en_US.UTF-8

Base Configuration – Time

ln -s /usr/share/zoneinfo/US/Pacific /etc/localtime

hwclock --systohc --utc

Base Configuration – Network

echo codeghar > /etc/hostname

cp /etc/netctl/examples/ethernet-static /etc/netctl/ens32.cfg

Edit the file ens32.cfg and provide your static IP information.

nano /etc/netctl/ens32.cfg

Enable the configuration.

cd /etc/netctl

netctl enable ens32.cfg

Base Configuration – initram

Edit file /etc/mkinitcpio.conf and add lvm2 between block and filesystems in the HOOKS settings.

nano /etc/mkinitcpio.conf

Before:

HOOKS="base udev ... block filesystems ..."

After:

HOOKS="base udev ... block lvm2 filesystems ..."

mkinitcpio -p linux

Base Configuration – grub

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

pacman -S grub efibootmgr

There seems to be a bug where I couldn’t get grub to work properly. The solution was to add an entry to the /etc/default/grub file.

nano /etc/default/grub

Add to file:

GRUB_DISABLE_SUBMENU=y

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck

grub-mkconfig -o /boot/grub/grub.cfg

Base Configuration – User

Set root password.

passwd root

Create new user. I tried to follow the example of a user account from Fedora.

groupadd cguser

useradd -m -g cguser -G users,wheel,storage,power -s /bin/bash cguser

passwd cguser

Base Configuration – Remote Access

pacman -S openssh

Configure SSH to disable root access and make any other changes you want.

nano /etc/ssh/sshd_config

systemctl enable sshd.service

Base Configuration (End)

I like to use vim so I install it as well.

pacman -S vim

Exit out of the chroot.

exit

umount -R /mnt

reboot

First Boot

You should now be able to boot to Arch and login via console or SSH.

The Importance of a Pleasurable User Experience

I’ve been thinking of getting myself a Raspberry Pi and configuring it to be my home network wireless gateway. While researching all the hardware pieces to get I thought I should try to decide on a Linux distribution. That quest prompted this post.

I’ve been using Fedora 19 with KDE for a good while now in an ESX VM. It does all the things I need and then some. But beyond that it’s been a pleasure working with it. I love the organized output yum provides. Other features like delta rpms and yum ps are also useful and just nice. I find the systemd user experience to be fantastic. It’s easy and simple to use. SELinux hasn’t bothered me so far. I can’t wrap my head around firewalld just yet but it stays out of my way as well. Fedora’s policy of sticking to upstream defaults means I get a purer upstream experience in an integrated distro. This is not always a good thing because KDE really has cumbersome or missing default settings. But once set up properly, KDE just runs and runs. I am in a Windows environment at work and RDP is just natural to use. Fedora 19 with KDE runs well enough over RDP using the xrdp package. I do get some harmless(?) error messages when first logging in over RDP but my work continues unabated.

With the release of Fedora 20 Beta I decided to give GNOME a try. My first impression is that it has a really good design for the shell, albeit on the minimalist side, and has great keyboard shortcuts. Some default settings don’t make sense to me but exploring gsettings has fixed some of the ones I care about. For the kind of work I do I have found GNOME Shell 3.10 to be an absolute pleasure to work with. It stays out of my way and I can focus on the things that really matter. Unlike all the hoopla about “power users” disliking GNOME Shell’s minimalism I found it to be very refreshing.

Coming back to Raspberry Pi, I’m quite comfortable with Fedora these days. In fact, when I use CentOS 6.4 I miss a lot of the things I’ve gotten used to in Fedora. So my first choice for RPi is Fedora, or Pidora, the spin specially made for it. The downside is that Pidora is tracking Fedora 18 and I want something new. I had hoped Fedora 20 would support RPi out of the box but can’t find any information on it.

My second option for RPi is Raspbian, a spin of Debian. Having gotten used to yum and systemd I find apt-get/aptitude and /etc/init.d to be far less pleasurable to work with. They get the job done equally well but I don’t like using them all that much. It’s just a matter of preference. I tried to dabble with creating deb and rpm packages and my initial take was that rpm is easier to create and manage. I’ll keep Raspbian as a second option for my RPi because I have experience with Debian. But I’d also like the Debian project to focus a bit more on making their tools more “fun” to use. Adopting systemd will be a good first step.

Ubuntu isn’t an option for RPi since they don’t support it just yet. I installed Ubuntu 13.10 in a VM to see how much it has changed since 12.04. I have to say the first thing I did was disable online searches in Dash, remove the Amazon icon from the launcher, and enable workspaces. These three things mean that Unity is no longer the same pleasurable experience it was in 12.04. Having used GNOME Shell 3.10 I missed the HUD but Unity’s “feature” of hiding the menu items became annoying quickly. It wasn’t so when I used 12.04 but KDE and GNOME Shell have made me realize you don’t really need to hide menu items even if you have HUD.

Ubuntu also has the issue of Upstart. It’s great to be able to use start/stop commands but not all services recognize them. I have to use start/stop, /etc/init.d, or service to start or stop my services. There’s no single method to do so. Enabling and disabling services is also cumbersome. I also dislike the policy of starting services right after installing or upgrading. Given these issues I find Ubuntu to not be a pleasurable experience anymore.

openSUSE 13.1 released today and it has some great things going for it. I haven’t tried it out but it’s because of one main thing: YaST. At the core of my being I find YaST to be a redundant tool for a lot of things, especially networking, firewall, and package management. I’d be very happy to skip YaST and just use CLI tools to manage most core things. I find those tools to provide a better experience than YaST’s CLI. I asked Jos Poortvliet, openSUSE’s community manager, on Twitter whether YaST was necessary and he said it wasn’t. I’ll take his word and try out openSUSE again, especially since they have a special build for RPi. I’ll revise my stance and make openSUSE my first choice for RPi. Maybe YaST will be helpful in creating my wireless gateway.

I also tried out Arch for the first time. It took me about 3-4 hours to make a customized list of steps to do a UEFI install as well as a BIOS install in a VM. I can say with all honesty that it wasn’t hard to install Arch at all since the wiki is so helpful. The wiki could be better but it’s still very useful. I thought that Arch’s simplicity and DIY nature would be a perfect fit for my RPi. I can install only the things I need and nothing more. I was excited.

And as I configured my VM further I realized I really have to do everything myself. Even the useradd command needs all the flags, compared to Fedora where you just provide the username. This brought me to my first crossroads: do I really want to create my own distro (so to speak) or have fun with setting up a wireless gateway? I think I’ll choose the latter. I want a distro to work out of the box which I can then use to do things other than creat emy own version of a Linux distro. Arch is a pleasure to use if you want to learn Linux but a burden if you want to use Linux to build something. I also feel like I want to go beyond re-inventing the wheel every time I do a new install, instead I want to build on top of the thousands of hours volunteers have spent building a solid distro, be it Fedora, openSUSE, Ubuntu, Debian, or whatever. I want to build a solution not a distro. I’ll still keep Arch as a candidate for my RPi because its simplicity is a very compelling factor.

So there you have it. I have tried to describe a pleasurable user experience by intertwining reviews of different distros with my needs for a wireless gateway using RPi. I find Fedora to be the most pleasurable distro today. It represents the hard work of a lot of upstream contributors in a package that’s friendly. It may not be the distro for new users but if I’m setting up a system for someone new to Linux, and I had to provide support for it, I’d use Fedora. For my RPi I’ll use openSUSE, Pidora, Raspbian, and Arch in that order. I’ll stop when I find the most pleasurable distro for that use case.

GNOME 3.10 Post Install Customization

With the release of Fedora 20 Beta I thought I’d give GNOME a try after having used KDE in Fedora 19. Although I’m still learning my way across the desktop environment, a few things struck with me immediately.

The GNOME design is minimal, to say the least. They have disabled a lot of features by default and some of them really bugged me. On the other hand, there were more default settings (especially keyboard shortcuts) than I found in KDE. Your best friends in GNOME are gsettings, gnome-tweak-tool, and dconf-editor, if you want to customize GNOME Shell. I’m finding out that they may not be enough, though.

Anyways, the things that I changed right away were:

  • Show date in the top bar/panel
    gsettings set org.gnome.desktop.interface clock-show-date true
  • Show seconds in the top bar/panel
    gsettings set org.gnome.desktop.interface clock-show-seconds true
  • Show logout option
    gsettings set org.gnome.shell always-show-log-out true
  • Open File dialog should show home directory not recent files. The default value is ‘recent’.
    gsettings set org.gtk.Settings.FileChooser startup-mode 'cwd'
    Relevant file is /usr/share/glib-2.0/schemas/org.gtk.Settings.FileChooser.gschema.xml

You may also want to install gnome-tweak-tool and dconf-editor.

su -c 'yum install gnome-tweak-tool dconf-editor'

These are GUI tools to help you customize the Shell. If you want to stick with CLI then run gsettings list-recursively and explore all the available options.

virtualenv with Python 3 using venv

Python 3 comes with its own virtualenv built in, and it’s called venv. Using it is fairly simple and quick. Make sure you have installed Python 3 on your system. Also make sure you have installed the Python 3 development library for your distribution. For example, install python3-devel on Fedora and python3-dev on Ubuntu.

Then run the following command to create your virtualenv.

cg@codeghar [~] $ pyvenv ~/myvenv

Note: In Ubuntu 14.04 (attempted on 2014-04-17) you may get an error:

cg@codeghar [~] $ pyvenv-3.4 ~/myvenv
Error: Command '['/home/cg/myvenv/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

To work around it, make sure you use the --without-pip flag, like so pyvenv-3.4 ~/myvenv --without-pip.

If you do an ls you’ll notice that the python you used to create this virtualenv is copied into your virtualenv. Thus your virtualenv will continue to use its local copy. You now need to “activate” this virtualenv.

cg@codeghar [~] $ source ~/myvenv/bin/activate

Sidebar: At some point you’ll want to “deactivate” your virtualenv. To do this just run the deactivate command.

Next step is to install setuptools. At one point Distribute was set to replace/supersede setuptools but that’s not the case anymore. Don’t worry, we’ll still use pip but to first get pip we need setuptools.

cg@codeghar [~] $ cd ~/myvenv

cg@codeghar [~/myvenv] $ mkdir pypioffline

cg@codeghar [~/myvenv/pypioffline] $ cd pypioffline

The latest version of setup tools at the time of writing was 1.1.6 so we’ll download it to the temporary/optional directory pypioffline.

cg@codeghar [~/myvenv/pypioffline] $ curl -O https://pypi.python.org/packages/source/s/setuptools/setuptools-1.1.6.tar.gz

cg@codeghar [~/myvenv/pypioffline] $ tar xvzf setuptools-1.1.6.tar.gz

cg@codeghar [~/myvenv/pypioffline] $ cd setuptools-1.1.6

cg@codeghar [~/myvenv/pypioffline/setuptools-1.1.6] $ python ez_setup.py

cg@codeghar [~/myvenv/pypioffline/setuptools-1.1.6] $ easy_install pip

That’s pretty much it.

venv — Creation of virtual environments

Install Python 3 locally under /home directory in CentOS 6.4

First off, why would you want to install local Python 3? There could be many reasons, some of which may be:

  • You don’t want to touch the system-installed Python
  • You don’t have root privileges
  • You want to run your private/personal scripts without affecting other users on the system
  • You want to run multiple versions of Python not available on your system

For whatever the reasons you want to install Python locally in your home directory, it’s not as difficult as I had first thought it to be. This is a good alternative especially since Python3 is not officially available in CentOS 6.4.

There are four major steps:

  1. Install Development Tools
  2. Download Python Source Code
  3. Compile and Install Python
  4. Modify your $PATH

Install Development Tools

You will need some tools to compile Python. The easiest way to obtain them in CentOS is to install the ‘Development Tools’ group.

cg@codeghar [~] $ su -c 'yum groupinstall "Development Tools"'

You also need some libraries that Python uses to provide “batteries included” support.

cg@codeghar [~] $ su -c 'yum install openssl-devel bzip2-devel expat-devel gdbm-devel readline-devel sqlite-devel'

Download Python Source Code

Head over to Python.org and download the version you want to install. For this post I used Python 3.3.2.

cg@codeghar [~] $ curl -O http://python.org/ftp/python/3.3.2/Python-3.3.2.tar.bz2

Now just un-tar the file so you can use its contents.

cg@codeghar [~] $ tar xvf Python-3.3.2.tar.bz2

You should see these two items in your home directory:

cg@codeghar [~] $ ls

Python-3.3.2  Python-3.3.2.tar.bz2

Compile and Install Python

You now have Python source and tools to compile it. Change directory to the un-tar’ed source code.

cg@codeghar [~] $ cd Python-3.3.2

Run configure.

cg@codeghar [~/Python-3.3.2] $ ./configure

Create a directory where you will install your local Python.

cg@codeghar [~/Python-3.3.2] $ mkdir -p ~/usr/local

Compile and install Python to the directory you just created.

cg@codeghar [~/Python-3.3.2] $ make altinstall prefix=$HOME/usr/local exec-prefix=$HOME/usr/local

Modify your $PATH

You now want to add ~/usr/local/bin to your $PATH so you don’t have to enter the full path to the Python binary every time you want to use it. Change directory to where local Python binary is located.

cg@codeghar [~/Python-3.3.2] $ cd ~/usr/local/bin

Create an alias so you can refer to it as python3. This is optional but I like to do it because I can then use python to refer to the Python that came with CentOS and python3 to refer to my locally installed Python3.

cg@codeghar [~/usr/local/bin] $ ln -s python3.3 python3

Now add this path to your $PATH environment variable. Notice that we add the new path before existing $PATH. This is so that our local Python is always used before any other.

cg@codeghar [~/usr/local/bin] $ echo "export PATH=\$HOME/usr/local/bin:\$PATH" >> ~/.bashrc

When you open a new terminal window, or log off and then log on, or (even better) run source ~/.bashrc, you can run the following commands to see that your local Python is now on your path.

cg@codeghar [~] $ which python3.3

~/usr/local/bin/python3.3

cg@codeghar [~] $ which python3

~/usr/local/bin/python3

cg@codeghar [~] $ which python

/usr/bin/python

You can even run your local Python.

cg@codeghar [~] $ python3

Python 3.3.2 (default, Sep 26 2013, 15:30:36) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print ("Hello World!")
Hello World!
>>> 

Conclusion

You can now run your local Python. There’s no need to keep the tar file and the source code around. You may want to delete them.

cg@codeghar [~] $ rm -rf ~/Python-3.3.2

cg@codeghar [~] $ rm ~/Python-3.3.2.tar.bz2

Another thing to consider is virtual environments, virtualenv or venv (in Python 3). Since Python3 comes with its built-in venv, just create an alias for its binary as well.

cg@codeghar [~] $ cd ~/usr/local/bin

cg@codeghar [~/usr/local/bin] $ ln -s pyvenv-3.3 pyvenv

There’s one more modification you need to make to get pyvenv to work. Open the file and change the path to your locally installed Python.

cg@codeghar [~/usr/local/bin] $ vim pyvenv-3.3

Original line is:

#!/usr/local/bin/python3.3

After changing it should look something like:

#!/home/cg/usr/local/bin/python3.3

You can now use this local pyvenv to create your virtualenvs.

Hat Tips

How to install locally python on linux home directory?; Installing Python 3 on CentOS/Redhat 5.x From Source; UNIX / Linux: Set your PATH Variable using set or export command; .bash_profile vs .bashrc; RHEL / CentOS Linux Install Core Development Tools Automake, Gcc (C/C++), Perl, Python & Debuggers

Follow

Get every new post delivered to your Inbox.

Join 31 other followers