The bug with svn2git 1.0.8 was a regression that broke support for (non-ASCII) UTF-8 author names in identity maps. That’s fixed in dev-vcs/svn2git-1.0.8-r1 in Gentoo. I sent the patch upstream and to the Debian package maintainer, too.

For svneverever, a directory that re-appeared after deletion was reported to only live once, e.g. the output was

(2488; 9253)  /projects
(2490; 9253)      /java-config-2
(2490; 2586)          /trunk

if directory /projects/java-config-2/trunk/ got deleted at revision 2586, no matter if was re-created later. With 9253 revisions in total, the correct output (with svneverever 1.2.2) is:

(2488; 9253)  /projects
(2490; 9253)      /java-config-2
(2490; 9253)          /trunk

That’s fixed in svneverever 1.2.2.

If svneverever is of help to you, please support me on Flattr. Thanks!

sudo layman -a betagarden
sudo emerge -av media-gfx/LightZone

What you get is LightZone 100% built from sources, no more shipped .jar files included.

One word of warning: the software has not seen much testing in this form, yet. So if your pictures mean a lot you, make backups before. Better safe than sorry.

Ingredients:

• KVM (or QEMU) — i.e. package app-emulation/qemu-kvm or app-emulation/qemu
• GNU parted — package sys-block/parted
• kpartx — from sys-fs/multipath-tools
• GNU GRUB 2 — sys-boot/grub:2

Despite care and best intents: For what comes next, NO WARRENTY of any kind! sudo and root permission stuff is involved.

First, let’s install the required software:

$ sudo GRUB_PLATFORMS='pc' emerge --update sys-boot/grub:2 \
    sys-fs/multipath-tools sys-block/parted app-emulation/qemu-kvm
[..]

Now, let’s create a sparse, virtual hard disk of 500MB in size and create a partition table with a single partition covering all available space. We use bash syntax to do the math.

$ touch grub-theme-disk

$ truncate --size=$((500*1024**2)) grub-theme-disk

$ /usr/sbin/parted grub-theme-disk mklabel msdos
WARNING: You are not superuser.  Watch out for permissions.

$ /usr/sbin/parted grub-theme-disk mkpart primary ext2 0% 100%
WARNING: You are not superuser.  Watch out for permissions.

Next, we make a block device for that partition and format it as ext2. We also store the location of the whole disk and the partition in dedicated variables for re-use.

$ sudo kpartx -p p -a -v grub-theme-disk
add map loop0p1 (254:9): 0 1021952 linear /dev/loop0 2048

$ GRUB_PART=/dev/mapper/$(sudo kpartx -p p -l grub-theme-disk \
    | grep -oE 'loop[0-9]p1')

$ GRUB_DEV=$(sudo kpartx -p p -l grub-theme-disk | grep -oE '/dev/loop[0-9]')

$ echo "${GRUB_DEV}, ${GRUB_PART}"
/dev/loop0, /dev/mapper/loop0p1

$ sudo mkfs.ext2 "${GRUB_PART}"
mke2fs 1.42.4 (12-June-2012)
[..]
Writing superblocks and filesystem accounting information: done

Now we mount the file system and create a minimal GFX GRUB 2 config in it using theme “starfield” that comes shipped with GRUB 2. For the menu, two dummy entries to restart and shutdown the machine are used.

$ mkdir grub-theme-disk-root

$ sudo mount "${GRUB_PART}" grub-theme-disk-root

$ sudo mkdir -p grub-theme-disk-root/boot/grub2/

$ cat <<"GRUB_CFG" | sudo sh -c 'cat > grub-theme-disk-root/boot/grub2/grub.cfg'
set theme=$prefix/themes/starfield/theme.txt
insmod all_video
insmod gfxterm
insmod png
terminal_output gfxterm
menuentry Reboot { reboot }
menuentry Shutdown { halt }
GRUB_CFG

We are ready to install GRUB 2. That includes copying files to /boot/grub2 (e.g. the starfield theme) as well as writing the bootloader to the master boot record of the virtual disk file (or more precisely the related loop device). We need to flush the write cache using the “sync” command so we do not boot from half-flushed data in the next step.

$ sudo grub2-install --boot-directory=grub-theme-disk-root/boot "${GRUB_DEV}"
Installation finished. No error reported.

$ sync

At that point, our disk image is ready to be booted as hard drive by KVM (or QEMU):

$ sudo qemu-kvm -hdd "${GRUB_DEV}"

You should see something like this (click to enlarge):

Now for the most important part:

If you do make a theme please make sure the overall theme is legally sound! For instance that means:

1. If you use the original, rendered “g” Gentoo logo, the related files have to comply with the CCPL-Sampling-Plus-1.0 license.
2. If you use Larry the cow graphics, the theme has to comply with the CC-BY-SA/2.5 license.

This can hardly be over-emphasized. If you fail to respect licenses properly Gentoo will not be able to include your theme anywhere, really. Other than that, happy theming! Feel free to post links to your Gentoo GRUB 2 themes in the comments below.

For more graphical building blocks and logos that you might want to use, please check out the Gentoo Artwork page and the vector remake of GDM 2.x background “gentoo-cow”.

The theming file format of GRUB 2 is described in detail in the official GRUB manual.

With that remade vector version you ca

• make razor-sharp renderings for any resolution you like
• adjust colors for yourself with high quality results despite little effort
• distribute any derivative works under CC-BY-SA/2.5

Maybe someone likes to base a (legally sound) GDM 3.x or GRUB 2 theme on it… ?!
If you need help setting up an efficient GRUB 2 theming playground, please get in touch.

Download SVG

# ebuild foobar-1.2.ebuild manifest prepare
# ebuild foobar-1.3.ebuild manifest prepare

and throw Meld at both outputs

# meld /var/tmp/portage/[..]/foobar-1.2/work/foobar-1.2/ \
       /var/tmp/portage/[..]/foobar-1.3/work/foobar-1.3/ &

Meld makes it easy to see what has changed and (especially) what has not changed. With sole diff -r that would be difficult.

I usually start by inspecting changes to configure.ac. If upstream did a good job that diff tells what dependencies to touch, already. Near the left and right margin you can see where else the file has been modified. No need to scroll-search down for more: you already know what you get.

The NEWS and ChangeLog files usually offer pointers of interest, too.

If my hint on Meld made a single Gentoo packager juggler’s life easier or more efficient, I have achieved what I was aiming for. Sorry for the noise to everyone else.

PS: The second preview image up there has been losslessly reduced by 40% in size just by running it through optipng -o7.

overlint is a simple command line tool. From a technical view point it reports

• which version bumps from the overlay are missing from the main tree (e.g. the overlay has 7.1 but the main tree has 7.0, only),
• which revision bumps are missing from the main tree (e.g. the overlay has 3.0-r1 but the main tree has 3.0, only), and
• which exact same revisions exist in both trees with differing ebuilds.

On a higher level these findings often indicate that

• certain changes are still to be integrated with the Gentoo main tree to benefit a wider audience and/or that
• an ebuild appeared in an overlay first but can be removed now as the Gentoo main tree has grown an equivalent (or identical) copy.

As a consequence overlint has two main use cases, each with a different user audience:

• Overlay maintainers can use overlint to better keep their overlay in shape.
• Gentoo developers and proxy maintainers can use overlint to detect valuable patches missing from the main tree.

Here is example output of overlint 0.4.1 for the calculate overlay:

# overlint-cli /var/lib/layman/calculate/
===============================================================
Version bumps missing from Gentoo main tree
===============================================================
net-misc/
  italc :: 1.0.13, 2.0.0
net-print/
  foo2zjs :: 20081129, 20110512
net-wireless/
  madwifi-ng :: 0.9.4.4178.20120131
  madwifi-ng-tools :: 0.9.4.4178.20120131

===============================================================
Revision bumps missing from Gentoo main tree
===============================================================
app-arch/
  unzip :: 6.0-r9
app-text/
  wgetpaste :: 2.18-r1

===============================================================
Ebuils that differ at same revision
===============================================================
app-forensics/
  unhide :: 20110113
dev-util/
  bin_replace_string :: 0.2
  qt-creator :: 2.4.1
sys-auth/
  pam_keystore :: 0.1.3
sys-block/
  tw_cli :: 9.5.3
sys-boot/
  grub :: 1.99-r2
sys-libs/
  talloc :: 2.0.7
virtual/
  linux-sources :: 0

To get it run:

# sudo emerge -av app-portage/overlint

The source code is up on http://git.overlays.gentoo.org/gitweb/?p=proj/overlint.git;a=summary. For small patches just send them along, for bigger ones get in touch before the work, please. Thanks!

• a detailed reply by Mike Edenfield (quoted below)
• a hint on app-admin/localepurge by walt/w41ter

As I liked the explanation by Mike, I asked for permission to quote it as CC-BY-SA/3.0 here, which he confirmed:

Different packages include different levels of support for filtering their installed localization messages, typically one of “install everything”, “install what’s requested”, or “whats a locale?”

The reason you mostly have files under LC_MESSAGES is because that’s 99% of what is needed to localize a package. The files in there are string resource packages, translations of the strings used by the program, which are picked up by the localization library (gettext) automatically based on your locale settings. (coreutils installs file into LC_TIME for locales with date/time formatting requirements; I don’t think I’ve ever seen any other locale files.)

The standard way to inform a package which languages you want is to set your LINGUAS variable in /etc/make.conf to the locale name(s) you want installed (without the charset specifier). LINGUAS works like any other portage expansion variables: for those packages that support it, you get a set of USE-flag-like language keywords set on build. (LINGUAS is the well-known environment variable used by most autotools-based packages to select languages, but portage provides support above and beyond that.)

Unfortunately, proper locale support is spotty — mostly due to upstream maintainers being too lazy to properly add it to their builds. Instead, the package will install every message file it has available all the time.

You can safely delete any folders from /usr/share/locale for locales that you don’t have installed, since the normal locale support in glibc will never ask for them. But they’ll just get put back next time you upgrade the package.

–Mike

>=gnome-base/gdm-3
>=gnome-base/gnome-control-center-3
>=gnome-base/libgnomekbd-3
>=net-wireless/gnome-bluetooth-3
>=gnome-base/gnome-settings-daemon-3

and re-emerged the latest 2.x versions of these packages. Works.