Skip to content

gentoo

Python-3.4 sur ma Gentoo habituée à Python-2.7

A la découverte de Python-3.4.0 sur une de mes install Gentoo 🙂 A ce jour (17/05/2014) Python-3.4 est encore masqué sous Gentoo, je vais l’installer sans modifier (volontairement) le package.keywords :

ACCEPT_KEYWORDS="~amd64" emerge -av =python-3.4*

[ebuild  NS    ] dev-lang/python-3.4.0:3.4 [2.7.5-r3:2.7, 3.3.3:3.3] USE="gdbm ipv6 ncurses readline sqlite ssl threads xml -build -examples -hardened -tk -wininst" 13,768 kB
GNU/Linux Magazine 171 (Mai 2014)
GNU/Linux Magazine 171 (Mai 2014)

J’utilisais jusque là python-2.7 uniquement, entendant ici ou là (notamment avec les développeurs Ansible) que Python >= 3.0 s’apparentait plutôt à un nouveau language qu’à une évolution de ce dernier.

C’est en lisant GNU/Linux Magazine 171 (Mai 2014) que je me retrouve tenté d’essayer la version 3.4  – entre-autres pour le module asyncio…

J’en profite par ailleurs pour parler de ce “Dr KissCool” visiblement adepte du troll et accompagné d’un humour de second et troisième degré. Je n’aime pas ce rédacteur, je ne remet pas en cause ses éventuels talents dans le domaine, mais je ne prends presque aucun plaisir à lire son blah blah trop souvent éloigné à mon goût de l’information technique recherchée dans ce genre de Mag.

Mes contenus sur ce blog sont probablement moins pertinents avec plus de fautes d’orthographes et grammaticales, mais personne ne paye pour les lires

Je n’oublie pas ensuite d’aller modifier le PYTHON_TARGETS dans make.conf que Gentoo consultera pour déterminer les version de python concernées par l’installation de nouveaux modules  :

PYTHON_TARGETS="python2_7 python3_3 python3_4"

Il faudrait ensuite théoriquement demander à Gentoo la recompilation de tous les modules python pour prendre en compte cette nouvelle branche :

 * You have just upgraded from an older version of Python.
 *
 * Please adjust PYTHON_TARGETS (if so desired), and run emerge with the --newuse or --changed-use option to rebuild packages installing python modules.

Tiens donc, jusque là, Gentoo préconisait l’utilisation de l’outil python-updater pour ça ; mais effectivement le résultat n’a pas l’air d’être pertinent :

# python-updater -- --pretend --tree --verbose
 * Starting Python Updater...
 * Main active version of Python:    2.7
 * Active version of Python 2:       2.7
 * Active version of Python 3:       3.3
 * Globally supported Python ABIs in installed repositories:
 *   gentoo:                         2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0
 *   sdfoverlay:                     2.4 2.5 2.6 2.7 3.1 3.2 3.3 2.5-jython 2.7-jython 2.7-pypy-1.7 2.7-pypy-1.8 2.7-pypy-1.9 2.7-pypy-2.0
 *   Adding to list: sys-libs/cracklib:0
 * emerge -Dv1 --keep-going sys-libs/cracklib:0 --pretend --tree --verbose

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild     U  ] sys-libs/cracklib-2.9.1 [2.8.19] USE="nls zlib -python -static-libs {-test%} (-build%)" PYTHON_TARGETS="python2_7%* (-python2_6)" 621 kB

Total: 1 package (1 upgrade), Size of downloads: 621 kB

par ailleurs, on constate que python-3.4 ne semble pas être listé dans les “Globally supported ABIs” ; cela à t’il donc un intérêt de recompiler les modules avec emerge ? essayons avec dev-python/django pour commencer :

emerge -av dev-python/django

[ebuild     U  ] dev-python/django-1.4.11 [1.4.8] USE="vhosts -mysql -postgres -sqlite {-test} (-doc%)" PYTHON_TARGETS="python2_7 (-python2_6%)" 7,571 kB
# equery files dev-python/django | grep 2.7 | tail -n 1
/usr/lib64/python2.7/site-packages/django/views/static.pyo
#
# equery files dev-python/django | grep 3.4 | tail -n 1
# 

à priori non, alors je m’arrête là et j’utilise python3.4 pour mes tests sans me soucier (et sans que cela ne perturbe) mes install stable via portage de python2.7 et python3.4 … Désolé si ce post est… inutile…

# python3.4
Python 3.4.0 (default, May 17 2014, 11:59:14)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 

Grub2 with GPT and BIOS on Gentoo

Too long time holding Grub2, and using Grub (called now “grub-legacy”).

On a fresh installed Gentoo system, here the links i used to setup it

  1. http://wiki.gentoo.org/wiki/GRUB2
  2. http://ubuntuforums.org/showthread.php?t=1736409
  3. http://www.gentoo.org/doc/fr/grub2-migration.xml

The importants things is that on a BIOS based system (not EFI), and using GPT partitions, you need to give grub a dedicated partition permitting him to store the “second stage” ; (in grub legacy, this code was placed on a kind of unofficial MBR extra-space).

Secondly, i don’t like the way that Grub2 is defaultly provided on linux distributions : /etc/grub.d/* now hold scripts executed in alphabetic order, and their outputs are concatenated to build the configuration. (Note that /etc/defaults/grub also hold some new configuration entries instead keeping theses variables in /etc/grub.d scripts).

To be opposite as myself few lines after, it’s not a bad way to proceed, so let’s go with that :

# kernel-default is not a special kernel name
#  searched by grub2 scripts
# but grub2 scripts search only
#  kernels starting by "kernel-" and "vmlinuz-"

cd /boot
ln -s linux-3.4.56 kernel-default

# partitioning a disk for Grub2 over BIOS/GPT :

# be sure to have an empty GPT partition table :
parted --script --align optimal /dev/sda mklabel gpt
parted --script --align optimal /dev/sda mklabel msdos
parted --script --align optimal /dev/sda mklabel gpt

# our partition needed because of grub2 overs BIOS/GPT
parted --script --align optimal /dev/sda mkpart primary ext2 0% 8MiB

# /boot
parted --script --align optimal /dev/sda mkpart primary ext2 8MiB 192MiB

# swap and root
parted --script --align optimal /dev/sda mkpart primary linux-swap 192MiB 704MiB
parted --script --align optimal /dev/sda mkpart primary ext3 704MiB 100%

# make /boot flagged "boot"
parted --script --align optimal /dev/sda set 2 boot on

# make /dev/sda1 out bios_grub partition
parted --script --align optimal /dev/sda set 1 bios_grub on

# check everything
parted --script --align optimal /dev/sda print


# will install grub files in /boot/grub
grub2-install --grub-setup=/bin/true /dev/sda

# will execute /etc/grub.d scripts
grub2-mkconfig -o /boot/grub/grub.cfg

# writing boot sector 
grub2-install /dev/sda

Hope this will help someone 🙂

gentoo atom regexps (ebuild name and versions)

Working on the Ansible Gentoo Portage emerge module, i’m testing some regexp for matching an atom string.

Atom is a Gentoo Portage pkgcore term.
An atom is a string representing a package name, and, optionally, it version range or version, the ebuild revision, the slot or slot and subslot.

To permit the future ansible module to handle the atom to be a parameter, i have to write some regexp for matching different atom alternative.

The first cases are simply to list, by parsing /usr/portage for avaiables packages, and atom : (here a simple bash/gawk/perl script to check the regexp)

#!/bin/bash

reg_ebuild_without_version='/^([a-z0-9\-]+)\/([a-zA-Z0-9\_\+\-]+)$/'
reg_ebuild_with_version='/^=?([a-z0-9\-]+)\/([a-zA-Z0-9\_\+\-]+)\-([^\-]+(\-r\d+)?)$/'

# this re
find /usr/portage/ -mindepth 2 -maxdepth 2 -type d | \
        gawk -F '/usr/portage/' '{ print $2; }' | \
        perl -pi -e "while(){ next if(${reg_ebuild_without_version}); print; }"

# this regexp must match a app-category/ebuild-name-X.Y.Z-rN
find /usr/portage/ -mindepth 3 -maxdepth 3 -type f -name '*.ebuild' | \
        perl -pi -e 's/\.ebuild$//g;' | \
        gawk -F '/usr/portage/' '{ print $2; }' | \
        gawk -F '/' '{ printf "%s/%s\n",$1,$3 }' | \
        perl -pi -e "while(){ next if(${reg_ebuild_with_version}); print; }"

Thoses regexp are not enougth to match any differents atom.

Some on the missing ones are already testing in the non-finished first version of the emerge module :

davixx/ansible/library/emerge (2013-01-20 version)

I hope, within 7 days, to finish the emerge_parse_atom function for handling successfully  almost 5-6 atom string cases.

gentoo fcron and system crontab

After a new install of gentoo with fcron-3 :

  • there is no /etc/crontab file ; and is it wanted (by default).
  • also, system crontab must not be setup in root crontab’s, but in systab  crontab, using the check_system_crontabs tool.
  • finally, note that by default, /etc/cron.* is not handled by fcron.

So, if you wanna to add support for /etc/cron.* you can :

  • Add this line in a new /etc/crontab (or in an existing if there is no equivalent lines already) :
%hourly * /bin/run-parts /etc/cron.hourly
%daily * * /bin/run-parts /etc/cron.daily
%weekly * * /bin/run-parts /etc/cron.weekly
%monthly * * * /bin/run-parts /etc/cron.monthly
  • Last point do nothing, just a file is updated, not any crontab.
  • Now you call the tool :
check_system_crontabs -v -i -f
  • This command will create or update dynamically the crontab of the systab user (needed by fcron for system crontab, created by the gentoo ebuild)
  • You can after check that the generated systab crontab is the concatenation of your /etc/crontab, any /etc/cron.d/ entry, and a call to the check_system_crontabs tool himself to update – if needed – the crontab – every ten minutes (in fact, for this laspoint, he use the content of /etc/fcron/fcrontab file) :
fcrontab -usystab -l