[gentoo-dev] RFC: l10n.eclass
Today I would like to present to you my proposal for a new eclass with helper functions for treating localizations: l10n.eclass (see the attached file or [1]). Its functionality can be used in other eclasses (such as qt4-r2 and cmake-utils) as well as directly in ebuilds. In order to keep the code simple, and prevent double loops and extra variables (such as currently used in the media-video/smplayer ebuild), I am proposing that we should add any missing long-form locales to profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de'). This also means that users may have to expand their LINGUAS setting in make.conf (e.g. LINGUAS=de en - LINGUAS=de de_DE en en_US) to cover the different variants used in packages. If you have any comments, spot any mistakes, or have proposals for improvement, I would love to hear it! I would especially love from maintainers of complicated packages such as libreoffice-l10n, if there is any additional functionality that we could include in this eclass to make their job simpler. 1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin l10n.eclass Description: Binary data
Re: [gentoo-dev] DESCRIPTION in eclasses
On Wed, 18 Jul 2012, Ciaran McCreesh wrote:
Many eclasses (eutils being the most prominent example) contain:
DESCRIPTION=Based on the ${ECLASS} eclass
Is this of any use?
The reason that sort of thing is there is because in the olden days
before we had specs or EAPIs or anything like that, eclasses were
originally designed and implemented as classes in an OO type manner.
The idea was that there would be a base eclass, and then you'd derive
kde, gnome etc eclasses from there, all in a nice hierarchy, and
you'd be expected to override variables like DESCRIPTION as you go
down the tree.
As it turns out, eclasses ended up being used in a completely different
way. But you still see bits of the original idea cropping up, such as
in the words class and inherit and base.
Thanks, this explains why these DESCRIPTIONs are there.
But history left aside, are they still useful today? If not, then they
should be removed.
Ulrich
Re: [gentoo-dev] net-misc/rabbitmq-server up for grabs
I'll take it tho I don't use it. If someone else want it feel free to ping me, I share my toys. Cheers Ultra On 18/07/2012 18:37, Benedikt Böhm wrote: All, i'm not using rabbitmq-server except as a dependency for app-admin/chef and i've no interest or time to fix it. Feel free to take it. Regards, Bene
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 4:05 PM, Alec Warner anta...@gentoo.org wrote: I'm not really following your logic here, so forgive me. I completely understand why folks do not say, rebuild their kernel when it is updated (kernel configs are annoying.) However lets say I have coreutils in / and coreutils in my initramfs. I upgrade coreutils from v1 to v2. Are you saying that you are too afraid to update coreutils in / and then also update it in the initramfs (probably by running $TOOL to copy coreutils from / to initramfs-root.) As others have mentioned, coreutils doesn't impact the initramfs much anyway, though other tools like mdadm/lvm/etc are more likely to. I think the more practical issue is that it isn't straightforward to do in an automated way. I suppose we could keep an always-up-to-date kernel and initramfs SOMEWHERE, but that won't necessarily be where the user boots it from. Also, we need flexibility as users tend to tweak these things - dracut has lots of options for how the initramfs is built, users might use any of several initramfs implementations, and the kernel config is frequently tweaked, and doesn't always work if you just do a make oldconfig. Usually the way other distros make all of this work is by making everything generic and not support configurability. Rich
Re: [gentoo-dev] DESCRIPTION in eclasses
On Thu, 19 Jul 2012 08:57:09 +0200
Ulrich Mueller u...@gentoo.org wrote:
Thanks, this explains why these DESCRIPTIONs are there.
But history left aside, are they still useful today? If not, then they
should be removed.
DESCRIPTION=Based on the ${ECLASS} eclass is never a sufficient
description for a package. So clearly pointless here.
Currently only KEYWORDS are banned from eclasses. I would add
DESCRIPTION and LICENSE to this list as well. DESCRIPTION is individual
to the package and it should never be to much work to come up with a
short description and LICENSE in eclasses greatly increases the chances
for the final listed licenses to be wrong. We have seen the latter
happening with the enlightenment.eclass.
signature.asc
Description: PGP signature
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 14:45:39 +0800
Ben de Groot yng...@gentoo.org wrote:
Today I would like to present to you my proposal for a new eclass with
helper functions for treating localizations: l10n.eclass (see the
attached file or [1]). Its functionality can be used in other eclasses
(such as qt4-r2 and cmake-utils) as well as directly in ebuilds.
In order to keep the code simple, and prevent double loops and extra
variables (such as currently used in the media-video/smplayer ebuild),
I am proposing that we should add any missing long-form locales to
profiles/desc/linguas.desc (e.g. 'de_DE' in addition to short 'de').
This also means that users may have to expand their LINGUAS setting in
make.conf (e.g. LINGUAS=de en - LINGUAS=de de_DE en en_US) to
cover the different variants used in packages.
If you have any comments, spot any mistakes, or have proposals for
improvement, I would love to hear it! I would especially love from
maintainers of complicated packages such as libreoffice-l10n, if there
is any additional functionality that we could include in this eclass
to make their job simpler.
1: https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.
Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.
for locale in ${PLOCALES}; do
if use linguas_${locale}; then
enabled_locales+= ${locale}
else
disabled_locales+= ${locale}
fi
done
First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On 07/18/2012 02:25 PM, Michael Mol wrote: 1) There are no truly mature tools for automatically generating and installing an initramfs based on system requirements. Canek likes to recommend dracut, which still isn't marked stable. I've gotten stable genkernel to work reasonably, but its error reporting is terrible. Please file a bug report and CC me on it. I will be more than happy to improve this for you. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: l10n.eclass
On 19 July 2012 21:14, Ralph Sennhauser s...@gentoo.org wrote:
I assume the P in PLOCALS stands for package. Not that obvious if you
ask me. L10N_LOCALS would at least tell me which eclass this variable
belongs to.
Yes, as P is widely used to refer to the package. I wanted something to
reflect that these are the locales offered by the package.
Instead of using LINGUAS you should make use of the use function to get
your cross sections. ie.
for locale in ${PLOCALES}; do
if use linguas_${locale}; then
enabled_locales+= ${locale}
else
disabled_locales+= ${locale}
fi
done
First, this is guaranteed by PMS and so independent of package manager
and second, you do not have to care about locales in LINGUAS which are
invalid for the package. Could be that Portage re-exports a sanitized
LINGUAS tough, but I doubt it.
This is a good suggestion, as it makes things simpler and more along
expected lines.
I got a few more suggestions on IRC, and I have updated the eclass
accordingly. Please check the attached new version, also available at
https://gitorious.org/gentoo-qt/qt/blobs/master/eclass/l10n.eclass
--
Cheers,
Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin
l10n.eclass
Description: Binary data
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, 19 Jul 2012 15:14:22 +0200 Ralph Sennhauser s...@gentoo.org wrote: First, this is guaranteed by PMS and so independent of package manager and second, you do not have to care about locales in LINGUAS which are invalid for the package. Could be that Portage re-exports a sanitized LINGUAS tough, but I doubt it. With EAPI 5, LINGUAS will be intersected with IUSE (but with the linguas_ bit stripped off). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Opinion against /usr merge
On Wed, Jul 18, 2012 at 07:04:15PM -0700, Olivier Cr?te wrote The rescue system should be entirely separate from the main system, so it survives mishandled upgrades. So having that should not hinder how your main system is built. So you should have it as a separate partition or you can even have it an initramfs (ie, in a single file on the main system). If you want *REALLY* entirely separate from the main system, you should be looking at a rescue CD or bootable USB key. That's about as safe as you can get. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Opinion against /usr merge
On Thu, 19 Jul 2012 07:05:39 -0400 Rich Freeman ri...@gentoo.org wrote: As others have mentioned, coreutils doesn't impact the initramfs much anyway, though other tools like mdadm/lvm/etc are more likely to. I think the more practical issue is that it isn't straightforward to do in an automated way. I suppose we could keep an always-up-to-date kernel and initramfs SOMEWHERE, but that won't necessarily be where the user boots it from. Also, we need flexibility as users tend to tweak these things - dracut has lots of options for how the initramfs is built, users might use any of several initramfs implementations, and the kernel config is frequently tweaked, and doesn't always work if you just do a make oldconfig. Usually the way other distros make all of this work is by making everything generic and not support configurability. Rich For me, the issue isn't so much that it's *hard* to rebuild an initramfs as that it's not obvious *when* to do so. For the kernel, this is a trivial problem: when sys-kernel/gentoo-sources bumps, rebuild the kernel. For an initramfs, when do I rebuild? When there's a new, what? Coreutils? Mdadm? LVM? Glibc? Busybox? Something-firmware? What about any less-obvious libraries they might link to, like zlib or something? All of those things are presumably in my initramfs, but there's no canonical list I'm aware of that tells me if one of the packages in this list updates, you must rebuild your initramfs if you wish to take advantage of the upgrade. Chris
Re: [gentoo-dev] RFC: l10n.eclass
On 07/19/2012 06:14 AM, Ralph Sennhauser wrote: Could be that Portage re-exports a sanitized LINGUAS tough, but I doubt it. Portage does sanitize it if there are any linguas_* flags in IUSE, otherwise it lets the variable pass through without sanitizing it. -- Thanks, Zac
[gentoo-dev] UTF-8 locale by default
I recently discovered that I for some reason haven't noticed the warning about setting the locale to utf-8 in the gentoo handbook for obviously several years; thus i was still running all my systems in a POSIX locale since i never cared much about it. However, since I noticed, I talked to several people about it; all of them stating as first response: Not shipping with a utf-8 locale turned on by default nowadays probably is a bug in your distro. While thinking about this and recognizing that indeed recent distributions ship with some UTF-8 locale by default, I tend to agree on that statement. Though, google brings up a lot of good documentation about how to change the locale, I couldn't find something that tells why stage3 is still delivered with posix locale set. Is there a reason for not using at least en_US.UTF-8 as a sane default value? BR, SaCu
[gentoo-dev] Last rites: media-gfx/gnome-scan
# Alexandre Rostovtsev tetrom...@gmail.com (19 Jul 2012) # Fails to scan with recent sane-backends; fails to build with gegl-0.2; # inactive upstream. # Users should switch to another scanning utility, e.g. media-gfx/simple-scan. # Removal in 30 days (bug #421957) media-gfx/gnome-scan
Re: [gentoo-dev] UTF-8 locale by default
Sascha Cunz schrieb: Is there a reason for not using at least en_US.UTF-8 as a sane default value? It has been discussed some time ago already. Setting LANG=en_US.UTF-8 would mess with collation rules, measurementpaper units etc. which has the potential to make users outside USA unhappy. It might make sense to set LC_CTYPE=en_US.UTF8 but even so, transliteration may give you unexpected results. To illustrate this, try running echo äå | LC_CTYPE=en_US.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 echo äå | LC_CTYPE=da_DK.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 echo äå | LC_CTYPE=de_DE.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8 and compare the output. For the previous discussion, see this thread: http://archives.gentoo.org/gentoo-dev/msg_2ffb7ea72e6209439600c371f6fc071d.xml Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] UTF-8 locale by default
On Thu, 19 Jul 2012, Sascha Cunz wrote: Is there a reason for not using at least en_US.UTF-8 as a sane default value? Because there's no one-size-fits-all locale, but it is specific to every system so the user must configure it? The matter was recently discussed in this mailing list [1] and also in the March 2012 council meeting [2], and as a result the docs team has amended the respective section [3] of the handbook. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_2ffb7ea72e6209439600c371f6fc071d.xml [2] http://www.gentoo.org/proj/en/council/meeting-logs/20120313.txt [3] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1chap=8
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, Jul 19, 2012 at 5:13 PM, Zac Medico zmed...@gentoo.org wrote: On 07/19/2012 06:14 AM, Ralph Sennhauser wrote: Could be that Portage re-exports a sanitized LINGUAS tough, but I doubt it. Portage does sanitize it if there are any linguas_* flags in IUSE, otherwise it lets the variable pass through without sanitizing it. That's good; we definitely don't want to sanitize it if there are no linuguas_* flags in IUSE. This would break LINUGUAS support for many autotools/gettext based packages, where the autotools code parses LINGUAS directly and the ebuild does nothing with it.
Re: [gentoo-dev] RFC: l10n.eclass
On Thu, Jul 19, 2012 at 2:45 AM, Ben de Groot yng...@gentoo.org wrote: Today I would like to present to you my proposal for a new eclass with helper functions for treating localizations: l10n.eclass (see the attached file or [1]). Its functionality can be used in other eclasses (such as qt4-r2 and cmake-utils) as well as directly in ebuilds. In a previous thread, I proposed that the linguas_* use flags should default to enabled (IUSE=+linguas_en_US ...). This would cause LINGUAS use-expand behavior to more closely mimic the behavior of the gettext autoconf macros (/usr/share/aclocal/po.m4). If LINGUAS is unset, all translations are installed. If LINGUAS is set a subset of translations are install. If LINGUAS is set to the empty string, no translations are installed.
