[gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 4:34 PM, Aisha Tammy wrote: > On 12/23/20 3:01 PM, Michael Orlitzky wrote: >> On 12/23/20 1:14 PM, Aisha Tammy wrote: >>> >>> I've recently had the same problem for TACC/Lmod which uses >>> autotools to get lua versions and lua.cpath and lua.path and did infact >>> manage >>> to push the horrendously large patch upstream - >>> https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744ddb5073a >>> >>> Maybe something similar can work for your use case? >> >> Yes, patching the build system works. >> > > Ah, I was unclear. > I meant this kind of patch would not be something that > upstream will hate, as it is backwards compatible. > That's the biggest problem with creating large backwards > compatible patches >.< > >> >>> The problem with just using -L/path/to/lua/lib/ -llua would be loading >>> library at runtime, unless autotools is smart enough to actually change this >>> CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua. >>> I am not sure how intelligent autotools is to be able to do this or not. >>> >> >> We already add entries to /etc/ld.so.conf to make things like slotted LLVM >> work. >> > > Hmm, how would that work? > I have package A with a binary /usr/bin/binA linked to liblua51.so (which in > your suggestion would change to /usr/lib64/lua5.1/liblua.so) and > and /usr/bin/binB linked to liblua52.so (or /usr/lib64/lua5.2/liblua.so). > I don't see any ordering of /usr/lib64/lua5.1/ and /usr/lib64/lua5.2/ > that allows for binA and binB to find their correct lua libraries. > (This doesn't need to be for binaries, other shared libraries even) > > Admittedly, I am not a lua or linker expert... > > Aisha > > My intention with the suggestion was that the actual library be stored in /usr/lib64/liblua52.so (or whatever the appropriate name is), but a symlink used for linking be stored in /usr/lib64/lua5.2/liblua.so. When you pass "-L /usr/lib64/lua5.2 -llua" to the compiler, it will find the file /usr/lib64/lua5.2/liblua.so and read the DT_SONAME entry in it. That will cause the linker to store "liblua52.so" as a DT_NEEDED entry in the executable. At runtime, the runtime linker ld.so (/lib64/ld-linux-x86-64.so.2) will read the DT_NEEDED entry, and try to find the library liblua52.so, which is in /usr/lib64, so it will be found without any ld.so.conf tricks. This requires no special runtime support, as the actual name the compiler/linker will end up storing in the output contains the proper version. This means that if /usr/bin/binA linked to liblua51.so (via the linker finding /usr/lib64/lua5.1/liblua.so) and /usr/bin/binB linked to liblua52.so (likewise), they would both be able to find the correct libraries, as the DT_SONAMEs are different. Jonathan Callen
[gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve
On 12/23/20 9:10 AM, Michael Orlitzky wrote:
> On 12/23/20 8:35 AM, Jaco Kroon wrote:
>> Michael,
>>
>> I'm busy disecting what Marek has done for asterisk as I need to make
>> that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
>> merely the one he did it for - perhaps that would be helpful for you as
>> well?
>>
>> I don't know lua at all.
>>
>> Anyway, I'm on IRC as jkroon if you'd like to exchange notes. I don't
>> particularly like the patch Marek did as I'll NEVER be able to push that
>> upstream. The patch will work for us, but as a policy I highly prefer
>> patches which I can get unstreamed such that we don't need to carry them
>> more than one or two versions.
>
> Agreed. This is more of a system library packaging issue than anything
> to do with Lua specifically.
>
>
>> I'd prefer to patch upstream to keep it's behaviour of detecting a lua
>> version, but have a --with-lua(version)? type argument that can take an
>> optional argument which will then be the version, but --with-* generally
>> takes a prefix where the include and lib folders can be found ... and
>> I'd prefer to depend on pkg-config as primary and fallback to the
>> ./configure mess which tries to guess at things ...
>>
>
> This is exactly what I'm trying to get across. Support for multiple
> versions of libraries in weird locations is not a new thing. Generally,
> you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running
> ./configure and everything will just work with your header files and
> libraries in the non-standard paths /foo/bar and /baz/quux,
> respectively. Those paths take precedence over the defaults (if used
> correctly...), so you can use them to override the default version of a
> library and compile/link against a specific copy if you need to do that.
> Likewise, one could prepend a path to PKG_CONFIG_PATH to override the
> version that will be detected via pkg-config.
>
> The problem that we've gotten ourselves into is that we've copied Debian
> by not only relocating the library, but renaming it (and its *.pc file)
> entirely. There is no good way to tell an autotools build system that
> you've renamed a library completely, and that it should prefer the
> renamed version over the standard one if the standard one also exists.
>
> If you want to build against the eselected version of Lua on Gentoo,
> then eselect-lua makes everything OK. It creates symlinks from the
> standard names to the nonstandard ones, and everything just works. But
> if you want to build against a specific, not-eselected version of Lua?
> You have to tell the build system what to do. The eselected version
> lives in the correct locations (via those symlinks), so the build system
> is going to want to find that first. If the eselected version is not the
> one you want to build against, oops. Then, since the version you
> *do* want to link against has the wrong name, you have to tell the build
> system to link against it somehow. You can't simply override the
> PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't
> just override the library search path, because our libraries have the
> wrong names.
>
> The work I've done so far for OpenDKIM does nothing to address these
> larger problems. If lua.pc is on the system, it will get used first,
> regardless of the version you actually want to build against. AFAIK
> there's no good way around this without patching.
>
> If the libraries (and pkg-config files?) were installed to
> subdirectories instead, then the standard method of overrides could be
> used to build against a specific version, rather than requiring every
> upstream build system to support our weird layout.
>
>
One way this could be done without breaking things might be to create a
subdirectory of /usr/$(get_libdir) for each version of Lua and creating
a liblua.a and/or liblua.so symlink in that directory pointing to the
liblua${VERSION}.* file in /usr/$(get_libdir). Then you could simply
point those build systems at that directory and they would still use the
correct version. As a hack in an ebuild, you probably could just create
such a setup in (subdirectories of) ${T}, pointing liblua.a, liblua.so,
and lua.pc at the appropriately-versioned files.
Jonathan Callen
[gentoo-dev] Re: [PATCH 6/6] toolchain-funcs.eclass: deprecate gen_usr_ldscript
On 7/14/19 11:31 PM, Michał Górny wrote:
> On Sun, 2019-07-14 at 19:50 -0400, Mike Gilbert wrote:
>> Signed-off-by: Mike Gilbert
>> ---
>> eclass/toolchain-funcs.eclass | 15 ---
>> 1 file changed, 4 insertions(+), 11 deletions(-)
>>
>> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
>> index 2e027015c684..7bd90bb4e4a0 100644
>> --- a/eclass/toolchain-funcs.eclass
>> +++ b/eclass/toolchain-funcs.eclass
>> @@ -950,18 +950,11 @@ tc-enables-ssp-all() {
>> # @FUNCTION: gen_usr_ldscript
>> # @USAGE: [-a]
>> # @DESCRIPTION:
>> -# This function generate linker scripts in /usr/lib for dynamic
>> -# libs in /lib. This is to fix linking problems when you have
>> -# the .so in /lib, and the .a in /usr/lib. What happens is that
>> -# in some cases when linking dynamic, the .a in /usr/lib is used
>> -# instead of the .so in /lib due to gcc/libtool tweaking ld's
>> -# library search path. This causes many builds to fail.
>> -# See bug #4411 for more info.
>> -#
>> -# Note that you should in general use the unversioned name of
>> -# the library (libfoo.so), as ldconfig should usually update it
>> -# correctly to point to the latest version of the library present.
>> +# This function is deprecated. Use the version from
>> +# usr-ldscript.eclass instead.
>> gen_usr_ldscript() {
>> +ewarn "${FUNCNAME}: Please migrate to usr-ldscript.eclass"
>> +
>> local lib libdir=$(get_libdir) output_format="" auto=false
>> suffix=$(get_libname)
>> [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
>>
>
> Wouldn't this trigger when both toolchain-funcs and usr-ldscript are
> inherited, in reverse order?
>
I thought the same at first, but it looks like it will work because
usr-ldscript inherits toolchain-funcs and both eclasses have include
guards, so the toolchain-funcs version will always be overridden by
usr-ldscript, if the later is inherited at all. I'm not sure how
fragile this construct is, though.
--
Jonathan
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] eclass/kernel-2.eclass: Remove use of tr in global scope
On 08/30/2017 08:02 PM, Mike Pagano wrote:
> As per PMS remove calls to external command 'tr' in global scope
> See bug #629106
>
> Signed-off-by: Mike Pagano
> ---
> eclass/kernel-2.eclass | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 09409ab1f..cdc8c4043 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -1410,7 +1410,7 @@ getfilevar() {
>
> detect_arch() {
>
> - local ALL_ARCH LOOP_ARCH COMPAT_URI i
> + local ALL_ARCH LOOP_ARCH COMPAT_URI TC_ARCH_KERNEL
>
> # COMPAT_URI is the contents of ${ARCH}_URI
> # ARCH_URI is the URI for all the ${ARCH}_URI patches
> @@ -1418,6 +1418,7 @@ detect_arch() {
>
> ARCH_URI=""
> ARCH_PATCH=""
> + TC_ARCH_KERNEL=""
> ALL_ARCH="ALPHA AMD64 ARM HPPA IA64 M68K MIPS PPC PPC64 S390 SH SPARC X86"
>
> for LOOP_ARCH in ${ALL_ARCH}; do
> @@ -1425,9 +1426,10 @@ detect_arch() {
> COMPAT_URI="${!COMPAT_URI}"
>
> [[ -n ${COMPAT_URI} ]] && \
> - ARCH_URI="${ARCH_URI} $(echo ${LOOP_ARCH} | tr '[:upper:]'
> '[:lower:]')? ( ${COMPAT_URI} )"
> + ARCH_URI="${ARCH_URI} ${LOOP_ARCH,,}? ( ${COMPAT_URI} )"
>
> - if [[ ${LOOP_ARCH} == "$(echo $(tc-arch-kernel) | tr '[:lower:]'
> '[:upper:]')" ]]; then
> + TC_ARCH_KERNEL=$(tc-arch-kernel);
> + if [[ ${LOOP_ARCH} == ${TC_ARCH_KERNEL^^} ]]; then
>
>
Unfortunately, the ${VAR,,} and ${VAR^^} forms were added in bash 4.0
[1], which means they are not available in EAPIs before 6, which only
allow constructs from bash 3.2 [2].
[1]: https://tiswww.case.edu/php/chet/bash/NEWS
[2]: https://projects.gentoo.org/pms/6/pms.html#x1-640006
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs
As my time has become a more limited resource and I no longer use it, the following package is up for grabs: dev-util/schroot -- Jonathan Callen signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH] profiles: update pie use-flag masks for sys-devel/gcc
On 05/11/2017 10:45 PM, Duncan wrote:
> Matthias Maier posted on Thu, 11 May 2017 19:17:51 -0500 as excerpted:
>
>> In light of the recent discussion, I will restore the status quo for the
>> pie use-flag: masked on non-hardened profiles, unmasked and forced on
>> hardened profiles.
>>
>> The next step will be to switch the pie use-flag on default profiles
>> from masked to unmasked/forced with a profile update.
>
> For those of us who already have a default-pie system and now that we do,
> don't want to go back, what's the prescribed override? I've never felt
> the need to override a masked flag like that, before.
>
> (I'm sure I could find the general documentation and handle it myself,
> but I'm equally sure that there's likely to be others in my situation by
> now, and we shouldn't /all/ need to figure it out on our own.)
>
> (As some may remember, yes, I do have USE="-* ..." set, so didn't get pie
> with the initial gcc6 emerge and @world rebuild, but I was persuaded by
> the discussion here to try it, second global rebuild, and so far it
> works. So both because it's supposed to be safer and because I don't
> want to do now a /third/ global rebuild, I strongly prefer to keep it,
> now that I have it, and no issues so far.)
>
In general, to override a package.use{,.stable}.{mask,force} entry in
your profile, you add an entry to the same file in /etc/portage/profile/
that turns off the mask/force value in the profile. In this case, you
would add a line like:
>=sys-devel/gcc-6.3.0 -pie
to the /etc/portage/profile/package.use.mask file (creating the
file/parent directory as needed). If a flag is masked/forced for all
packages in use.{mask,force}, then you would add a line like "-foo" to
the use.{mask,force} file in /etc/portage/profile/.
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: meson.eclass second draft
On 05/04/2017 07:48 PM, William Hubbs wrote:
> All,
>
> here is meson.eclass after the changes from the first posting.
>
> Mgorny, I don't quite understand your question about the install command:
>
> DESTDIR="${ED}" eninja -v -c install
>
> I think it is ok, I don't think DESTDIR= has any bearing on EPREFIX.
>
> Here's the attachment.
>
> William
>
You need to set DESTDIR="${D}" when you pass --prefix="${EPREFIX}"/usr
(or equivalent), otherwise, you will install files to
${EPREFIX}/${EPREFIX}/usr. As Prefix expects files in ${EPREFIX}/usr,
etc., this will cause issues on all Prefix systems (specifically,
Portage will error out if it detects any file installed into $D that is
outside of $ED or the directory $ED/$EPREFIX existing at all (when
$EPREFIX != "")).
The only time that it is generally appropriate to set DESTDIR="${ED}" is
when dealing with broken build systems that force a prefix of exactly
"/usr" and don't allow the user to change it (or even force files into
"/bin", "/etc", etc.).
[Resent because it appears the first message didn't get through.]
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: meson.eclass second draft
On 05/04/2017 07:48 PM, William Hubbs wrote:
> All,
>
> here is meson.eclass after the changes from the first posting.
>
> Mgorny, I don't quite understand your question about the install command:
>
> DESTDIR="${ED}" eninja -v -c install
>
> I think it is ok, I don't think DESTDIR= has any bearing on EPREFIX.
>
> Here's the attachment.
>
> William
>
You need to set DESTDIR="${D}" when you pass --prefix="${EPREFIX}"/usr
(or equivalent), otherwise, you will install files to
${EPREFIX}/${EPREFIX}/usr. As Prefix expects files in ${EPREFIX}/usr,
etc., this will cause issues on all Prefix systems (specifically,
Portage will error out if it detects any file installed into $D that is
outside of $ED or the directory $ED/$EPREFIX existing at all (when
$EPREFIX != "")).
The only time that it is generally appropriate to set DESTDIR="${ED}" is
when dealing with broken build systems that force a prefix of exactly
"/usr" and don't allow the user to change it (or even force files into
"/bin", "/etc", etc.).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: new virtual -- virtual/go to fix go build time dependencies
On 03/01/2017 07:18 PM, William Hubbs wrote:
> All,
>
> the dependencies for dev-lang/go need to force a rebuild every time the
> compiler is downgraded or upgraded.
>
> To avoid abusing slot dependencies for dev-lang/go since it is not
> needed at runtime I need to do the following.
>
> I need to introduce virtual/go-1.7.5, virtual/go-1.8 and
> virtual/go-. The attachment shows 1.8 but it is the same for all
> versions.
>
> Also, the attached patch needs to be applied to golang-base.eclass.
>
> This is based on the following wiki page:
>
> Ahttps://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#Using_virtuals_to_expose_multiple_ABIs
>
> Any thoughts?
>
> William
>
Unfortunately, this would allow the user to remove all versions of
dev-lang/go before attempting to compile a package using go, as
virtual/go has no RDEPENDs, and only RDEPENDs of DEPENDs are required to
be present (not DEPENDs of DEPENDs).
That is, the following sequence of actions would be perfectly legal,
according to the dependencies:
Merge dev-lang/go
Merge virtual/go
Unmerge dev-lang/go
Merge {package using golang-base.eclass}
While my initial thought was to just add dev-lang/go to the DEPEND in
the eclass (in addition to virtual/go), that doesn't quite work as the
two packages are allowed to get out of sync because virtual/go doesn't
RDEPEND on dev-lang/go at all (so you could install virtual/go for your
current version of dev-lang/go, then upgrade dev-lang/go without
upgrading virtual/go).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: Global USE cuda
On 01/02/2017 04:37 PM, Justin wrote: > Hi all > > How about making USE=cuda a global USE? > > Description: Enable support for nVidia CUDA I would say: "Enable support for NVIDIA CUDA", as that reflects how NVIDIA now appears to refer to itself. > > Current Situation: > [snip] > > More or less consistent in enabling CUDA support. > > Best, > Justin > Jonathan signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: newsitem: OpenRC runscript transition (draft 2)
On 08/22/2016 05:45 PM, William Hubbs wrote: > On Mon, Aug 22, 2016 at 09:53:48PM +0200, Ulrich Mueller wrote: >>>>>>> On Mon, 22 Aug 2016, William Hubbs wrote: >> >>> Display-If-Installed: > >> Why the condition on the version number? > > I suppose I could change this to just sys-apps/openrc > >> >>> # emerge --oneshot -av $(grep -l "#!/sbin/runscript" /etc/init.d/*) >> >> Hm, I think you'll want single quotes there, otherwise the exclamation >> mark could trigger bash history expansion. Alternatively, grep for >> /sbin/runscript without the shebang (with the additional advantage >> that it would also catch cases with whitespace after the #!). > > Is '#! /sbin/runscript' a valid shebang line? I didn't think you could > have whitespace after the '#!'. > > William > Yes, it is. I just checked my /usr/bin, and found over 100 scripts that all begin with the string "#! /", including many scripts from autoconf, among others. -- Jonathan Callen signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News Item: OpenAFS no longer needs kernel option DEBUG_RODATA
On 07/21/2016 01:12 AM, Michał Górny wrote:
> On Thu, 21 Jul 2016 00:22:36 +0300
> Andrew Savchenko wrote:
>
>> On Wed, 20 Jul 2016 15:12:01 -0400 Michael Orlitzky wrote:
>>> On 07/20/2016 01:13 PM, NP-Hardass wrote:
>>>> Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2
>>>>
>>>> ...
>>>>
>>>> Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer
>>>> forced in the ebuild.
>>>
>>> Might not that version bound might backfire if someone upgrades before
>>> reading the news? People who pull from git often don't necessarily get
>>> the news in a timely fashion.
>>>
>>> Would it be simpler to ewarn in the ebuilds (for e.g. a year) if
>>> DEBUG_RODATA=n?
>>
>> We already do this in openafs-kernel-1.6.18.2.ebuild:
>>
>> if use kernel_linux && [[ ${REPLACING_VERSIONS} < "1.6.18.2" ]]; then
>
> Few important QA notes:
>
> 1. < is lexicographical comparison, so e.g. 1.6.2.2 < 1.6.18.2 gives
> false,
>
> 2. REPLACING_VERSIONS can have more than one value,
>
> 3. Finally, '' < 1.6.18.2 gives true, so it is also printed for initial
> install.
>
If you want to do a package version comparison, you probably want to use
the function version_is_at_least() in versionator.eclass. The primary
version comparison function in that eclass was written to be a complete
implementation of the version comparison algorithm in PMS. Maybe
eventually we'll get a version comparison function in PMS so we won't
have to resort to the wonderfully complex bash functions in that eclass :).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: Need design help/input for eclean-kernel
On 06/30/2016 08:38 AM, Michał Górny wrote:
> Hello, everyone.
>
> Back in 2011 I started a project called eclean-kernel. The idea was
> pretty simple -- to have a tool that would clean the old kernels for
> me since their install is not controlled by the package manager. This
> little project of mine seems to have gained a lot of popularity.
>
> Sadly, over time a lot of people had trouble with it. Aside to minor
> Python problems, eclean-kernel proved too simple to handle multitude of
> user systems with varying /boot layouts. In fact, even I don't use it
> on all of my systems since it doesn't handle them properly.
>
> After being buried in another set of bug reports, I'd like to
> officially ask Gentoo developers and users for help. I think it's
> impossible to solve most of the bugs reported so far in the current
> program design. Therefore, I'd like to rewrite it in a more flexible
> manner.
>
> For this reason, I would like to ask you to provide me with
> different /boot layouts you may have, had or seen. Basically, the idea
> is to collect as many different layouts as necessary, and use that to
> design eclean-kernel in a way making it possible to easily configure it
> to handle proper variant -- or even possibly make it capable of
> autoconfiguration.
>
> So if you have some time, please reply to this thread with
> a specific /boot layout that you think needs to be handled, with
> as much helpful information as possible -- including possible
> distinctive features and pitfalls.
>
> Thanks in advance.
>
https://wiki.freedesktop.org/www/Specifications/BootLoaderSpec/
${MACHINE_ID} is the contents of /etc/machine-id
Boot loader config:
/boot/loader/entries/${MACHINE_ID}-${KV}.conf
Kernel, initramfs, etc.:
/boot/${MACHINE_ID}/${KV}/linux
/boot/${MACHINE_ID}/${KV}/initrd
/boot/${MACHINE_ID}/${KV}/config
/boot/${MACHINE_ID}/${KV}/System.map
Can be generated by kernel-install(8) (part of systemd).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [tangent] Re: [gentoo-automated-testing] BROKEN: repository became broken!
On 06/17/2016 06:22 PM, Ian Stakenvicius wrote: > On 17/06/16 06:17 PM, Ian Stakenvicius wrote: >> On 17/06/16 05:22 PM, Michał Górny wrote: >>> On Sat, 18 Jun 2016 00:06:10 +0300 >>> Andrew Savchenko wrote: >>> >>>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote: >>>>> Hello, >>>>> >>>>> Since this is a major issue involving a lot of packages, and it needs >>>>> to be fixed *quickly*, I'm forwarding the new check results to >>>>> gentoo-dev. >>>>> >>>>> If the below list contains your package, please fix it ASAP. I will >>>>> file bugs for the remaining packages then. >>>>> >>>>> Long story short, using := operator inside || () conditional blocks is >>>>> completely forbidden and triggers random misbehavior inside package >>>>> managers (Portage doesn't do exactly what you think it does). >>>> >>>> Please explain in more details why this is forbidden. man 5 ebuild >>>> contains nothing about this, I can't find anything in PMS also. If >>>> package manager misbehaves this doesn't automatically imply that >>>> ebuilds are broken (and not PM). >>> >>> It was explained already. PMS doesn't permit it. It doesn't make *any* >>> sense, so the author didn't even bother explicitly saying it's >>> forbidden. Package manager can't not misbehave if something can't be >>> implemented. >>> >> >> Where does PMS not permit it?? >> >> 8.2: [...] >> An any-of group, which consists of the string ||, followed by >> whitespace, followed by an open parenthesis, followed by whitespace, >> followed by zero or more of (a dependency item of any kind followed by >> whitespace), followed by a close parenthesis. >> >> >> "dependency item of any kind" would certainly include atoms with slot >> operators. >> >> >> There is also no caveat at all in 8.2.3 that excludes slot operators, >> and 8.2.6.3 also contains no caveat or exclusion of slot operators >> from any-of groups. >> >> >> Using slot operators within OR deps was intended when EAPI5 was >> introduced. If Portage and other PMs don't handle it well or properly >> then they should be fixed, and perhaps the spec should be refined in >> EAPI7, but that doesn't mean banning it now. >> >> >> > > > Now, one thing that *is* banned is the use of :[SLOT]/[Sub-Slot] > values in ebuilds, as per PMS s.8.2.6.3 -- I know there's plenty of > ebuilds that are doing that, including in virtuals. > > > No, the specific syntax that is banned is ":0/0=" (that is, both a subslot and a slot operator). It is perfectly legal to depend on ":0/0" or on ":0=", but not on ":0/0=". -- Jonathan Callen signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: kernel-2.eclass Prefix support
On 06/12/2016 10:42 PM, Michael Orlitzky wrote:
> On 06/12/2016 09:12 PM, Benda Xu wrote:
>> Michael Orlitzky writes:
>>>
>>> Every rm, cp, mv, mkdir, dodir, cd, etc. needs "|| die".
>>
>> Thanks, updated.
>>
>> ...
>>
>> # Don't forget to make directory for sysfs
>> -[[ ! -d ${ROOT}sys ]] && kernel_is 2 6 && mkdir ${ROOT}sys
>> +[[ ! -d ${EROOT}sys ]] && kernel_is 2 6 && mkdir "${EROOT}"sys
>>
>
> One more =)
>
>
>
>
This one probably should also be guarded by a `if ! use prefix` or `if
[[ -z ${EPREFIX} ]]` (or whatever), as it doesn't make as much sense to
have a ${EPREFIX}/sys directory.
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs
As I no longer use this package, it is up for grabs: dev-libs/lockdev signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: News item: upgrading to Plasma 5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/06/2016 07:46 AM, M. J. Everitt wrote:
>
> In the event you're not explicitly using a desktop or KDE desktop
> profile, can you provide a summary of the changes that should be
> made manually when switching the the kde-plasma/* ebuilds please? I
> can probably handle a display manager change over a network of
> systems, but making a sensible transition to Plasma5 over many
> systems could be a trial if a small step is overlooked Thanks!
>
> Michael/veremit.
>
>
The list of things that the plasma profiles add to the system can be
found in ${PORTDIR}/profiles/targets/desktop/plasma/. The
make.defaults and package.use in there show which USE flags a default
plasma install would need (in addition to the standard desktop profile
and the flags enabled by default in the ebuilds). Note that most of
the changes are either a) disabling things in some old KDE 4 stuff
that hasn't been ported completely, to just have the bits still
required on a mostly-ported system, and b) choosing which
implementation (Qt4/Qt5) on packages that require you to choose (the
profile ends up enabling USE="qt4 qt5" for most packages, this turns
off one of them for some packages).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJXBa21AAoJEEIQbvYRB3mgmK8P/RnRjGjDjrrnrEiNW+0AQcpX
Wjsa47kEu7GenNQjJMg3RLDGYAXr2WlPVxXWJ6dSmd81Ja+36tWV5/pYj7XDGFOo
Pq7KSLBnS3aEHYjkMybikVhtOWbqV00sf/s3ApVopiivgvmiw2G40RsL7SA9DvZk
BkFkojt99XZ2K+v5sLUtAN7eGWbtCw7fgncCxpTxvcXgp9JK3Pp+VZOUidtTtfSy
7POdYdq/wgycoxRoZatSOYFsg8iQHoRRHxnq7wJsAsPCTkVVa0eghp/c6jAwa8Ja
23jrbk1u3hy84OJLD7Y3Z598Jj91HGEPWGdZ52yw1/1z6QvvaJ8DZP18T69cK6lC
Gjzu6xEGKSxaDILoQu/c98+qzvhdesgY5p6YGGa+UYQ/BCI4fia4fLEsx2nt7SDk
9USx42yRfN5rOo+B42Ii6LOhUQZ6+xQlBcQ3aFArHoZCfmxFuxHOnuOvAZ3rFRGo
A4tXcXI5nCf3VCns5+ONjocZI0fjDpvwY0fD2hgUi0AD1YYszcvW7UHpthRPZngm
9P/b1FACeE3j0fNbe6oZUS/LSPDW1GE1qh5yiJXgPyiqFxJkPi0cBoi4F9SRI1WC
fPtlOOkaFaZSTU/4OwGAwNDyFrtPTeA4JhZMPsVzykOd5mnAvEIRab1V3sG+MsUU
W83URmFaK3nQWlDfCzQ3
=aCfR
-END PGP SIGNATURE-
[gentoo-dev] Re: usr merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/05/2016 12:53 PM, Alexis Ballier wrote: > On Tuesday, April 5, 2016 2:26:53 PM CEST, Duncan wrote: >> >> As I said in the other thread, I'm running merged /usr and >> bin/sbin here, except that I merged them the other way, with /usr >> -> . so everything in /usr is now in /. >> >> Portage has long "just worked" in that regard, tho I've no idea >> whether the other PMs do. Portage has enough intelligence to >> avoid replacing a file with a symlink pointing to it (and thus to >> itself once the replacement is done), regardless of which way the >> directory symlinks point. >> >> As such, coreutils "just works". If the two would end up in the >> same canonical location, the file wins and the symlink isn't >> installed. > > What about the unlikely case with two files ? > Having actually run this way myself, I did find one case that I haven't filed a bug for yet: the plymouth ebuild tries to install symlinks in /sbin pointing at /usr/sbin, and portage chose to install the symlinks instead of the real files, for whatever reason (apparently because the $ED/sbin directory is created after the $ED/usr directory). Because of this, it might be best to ensure that packages that do install in both places are modified not to do so under such a configuration. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXBFMbAAoJEEIQbvYRB3mg2e4P/2lPBxpyjY311LP7gN2Nndn4 Dd4EtFbh8tQWoedPJQgr2CIeVgpPFA7l/stuvcoZAqLVDuFnn4ZmMWSIQOgHmgPp +mIiCDPuLMjhqw/yINlTGGVVhffHFG4PrHcd2MwP6Gm9ME0NH8+Z0cgAznHsHQ5c lgNdfXDsgBdrSrKu5/JTw7jDOv1A1TwIACJoLpEYZTlVCBClp6J01kqH1oyEzPf8 FO6fqAvFJXCq1um6/+ve8LOpS0OLBpg0dh5kcdkFgV1430FqNwUczMINhav5J0mp qTAIZTO4OSLxyswOUiKoxROl4xrQ1ByYi1ZF7g24oh7M1fmkreNClrhJ1kA3M6ff OJ3LJ6m350LEIVzAED66pnKOTNDOLJSaz6MsPk8CHzuJ2RCMatKjBA3Lb0tkkepp 5LOCBXbnVfSPRI+TQM91cHXVnh87T1zZSeGT8qOCfNoF7rFWNSlpIRnxMeeFlv2n 0kXfJo9YeiUAA9BYXBryMIsWr4StM4I9oq0ITc7h9WmB/WKW6zJhl7WHd7SgiePW Lb2fHJtz0R8dUIc53Yxuls1Cbt8AUAFYmN9Ve615cVLs3+jO8HWmwiuFfiYH71k1 JaS51cgBjPBnQuiET0iNxu/gjIekwIjoNptn/cCr9IZ4jnZ9L13ai6Wug49vUwwK bed4Tt3nl8GSbRtlV+rk =PHpB -END PGP SIGNATURE-
[gentoo-dev] Re: CVS headers in ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/04/2016 02:58 AM, Lars Wendler wrote: > On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote: > >> Does anyone still use the CVS $Id$ keywords that are in all >> ebuilds' headers, or are they being expanded anywhere? Or is >> there any other reason why they should be kept? >> >> In fact, the council had already voted to drop them in its >> 20141014 meeting: >> >> Can we drop CVS headers post-migration? Aye: blueness, creffett >> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh >> >> >> Ulrich > > Yes, I still use these lines to check for ebuild changes between > portage and my personal overlay. So please keep this line. > > Thanks. > > Lars > I do the same (after enabling expansion in .git/info/attributes on just "*.ebuild", I can even get a quick diff of what changed in gentoo.git to update my overlay). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXAz9VAAoJEEIQbvYRB3mg5wMP/1sjOs1yDT9qI96Cy/s3K+el +VfRKu1GmxCZgNzWJRMWkKRkYh6eY90aZ9naIijadlShsA4HtaP6psRIPuWxbxBZ UPDOqb+xxhm178Rj7BGeU/TtHGLyEE+09KqQSNOi6EwwVXWBSBcAJQln/IGMI831 4daghpp2UlUUhgkFlCyk9M2MsXbA5CtJo8tKp+mUt/0p6dxP458yxzK7gUC9eY3b TnjxP60T6oFWSnZQYJ0Qdj4DemBIe3B0uRWY87uST2KLA8dtCbsEKlRa9fE83JfS GT6G2RBetphsR5GJsEEgCOpu5MWXMwxjLFM7YMHo9mTDk4PhFuq82g88ZAaCQNta sG6wWPWnAiIh54nqT6axvM1FQ3OoPQI7hGG99zuUQAaZXp29lsxcFiRT2FWdecLk 0fyrAa3/0rBm6Bixr+YxsD27n0pjTQUzgOlfwfVT8mf+hKJ1X8DqXrkB5axpp/pc eArYrt/nYzmfMFM021xST8K5tDqTxd+MI6ZcMoeVAsJEdCyS/KvySYrinbe4PfRa v0ricr8hXDsAbVT91BwC/T+AWpSGn0K5T/VGqCeTDHdH3Dn+x2JGpVRE159/f/2e gD5ByNhIet+gSDMS+9Q/HO62mbs7Qu9Bwqi2cYKKeyIgHMi1s6JTh+tzOUxrC6Ny sJkCQLlAIKZ5LDlJ/DZu =Y/Tk -END PGP SIGNATURE-
[gentoo-dev] Re: New Eclasses: postgres and postgres-multi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/25/2016 07:29 AM, Aaron W. Swenson wrote:
> On 2016-01-24 18:44, Michael Orlitzky wrote:
>> On 01/24/2016 06:29 PM, Aaron W. Swenson wrote:
>>> Okay, provided that the new USE_EXPAND is okay for
>>> POSTGRES_TARGETS, attached are the eclasses that I'll commit to
>>> the tree.
>>>
>>
>>> case ${EAPI:-0} in 0|1|2|3|4) die "postgres-multi.eclass
>>> requires EAPI 5 or higher" ;; *) ;; esac
>>
>> Does this really work with EAPI=6? I didn't try, but it looks
>> like it would need an eapply_user somewhere in src_prepare. And,
>> pedantry warning, there's no such thing as "EAPI 5 or higher."
>> The lawyers will tell you to do something like this instead
>> (stolen from git-r3):
>>
>> case "${EAPI:-0}" in 5|6) ;; *) die "Unsupported EAPI=${EAPI}
>> (unknown) for ${ECLASS}" ;; esac
>>
>> That will require an edit for every new EAPI, but prevents weird
>> crashes from things like a missing eapply_user.
>>
>>
>
> Thank you.
>
> I've added the eapply_user to postgres-multi and modified the case
> condition to match the hot goods you're selling on the sly.
>
You missed the fix for EAPI in postgres-multi.eclass (it looks okay in
the other eclass, though).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJWpukoAAoJEEIQbvYRB3mgD/8P/iCbnkSZGcwnbQ7EsV55apJ+
+AqzVJVbgvNkrK23JysYfDcT9Qthld5W1CX66YBg38PBJbDHrQPZQiAYypybVxo8
Liv8P2O4smBdYhIdFfcMw6ARyOpfRec1kiYiZr0YI/sM1pQF/UV2RuG+zJJILMwJ
f3gNoRN0u58hMX5F1LZn0vRcrp9FqovNy1MMQ83u1qZp6SwK81IZFmHXoyyEWmaO
zh1plMRfs9iD7DK6CzHBvRyIyShzJGcNLOkNM7qKU5GhAXi7bWuwx5ZZpD1peWLI
Rn9xXfffyA62eU7EGvUQG/PuAU1PErT9+nFhH6qqSBnOpcR3kFO8a5zgfLHogzJT
cDQf4XU9MxDCjvSF2c/2tnt1tXqBO7CTjvsaIgaok8vzLsmh6wwJCiqGb80gRWX7
4HIAKqH1QbBLfPkb54NQp8ixw1b+LmtcbgJQrpXpxJTrUqtnJKDaaXKblFO8eOW2
LeLYYxdzEz3rh6RiqT7NZ3iKKP6cFy7S4qlfe4qsXD7mns1eIqcx9Hdt8LuwDMnC
zGLb7TBThrhBTt1gRdsXNDZUhkO5YohNqIgeUO1+bEnWS2UGZNf4Mv69HZTgipLO
vZ2vPFevEW5zAqj8kXgZQjuyrq59TlCY9l2q/etf4oxk6e2Sge1TZ8dcfLA9kJ/E
SIdeJ4XRl36+p1ANzG6c
=F4Y9
-END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH] readme.gentoo-r1.eclass: Do not inherit eutils.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/19/2015 05:56 PM, Michał Górny wrote:
> On Sat, 19 Dec 2015 23:51:47 +0100 Ulrich Mueller
> wrote:
>
>>> On Sat, 19 Dec 2015, Michał Górny wrote:
>>
(I guess it is encountering EOF on the temporary file created
by the string redirection, but how would one distinguish this
from other errors?)
>>
>>> read's return code indicates whether if found a full line (with
>>> a newline). read can't really fail.
>>
>> Certainly writing or reading the temp file can fail?
>>
Besides, it is hard to understand what this code does, as
compared to the "set -f" solution.
>>
>>> Many pieces of good code are harder to understand than cheap,
>>> ugly hacks. That's why those hacks are so common, and people
>>> meet them all the time and never learn good code.
>>
>> Well, compare:
>>
>> set -f echo -e ${DOC_CONTENTS} | ...
>>
>> versus:
>>
>> read -d '' -r -a DOC_CONTENTS <<<"${DOC_CONTENTS}" echo -e
>> "${DOC_CONTENTS[*]}" | ...
>>
>> The second one is (IMHO) harder to understand, less efficient,
>> and relies on undocumented behaviour.
>
> On WHAT?!
>
Apparently, bash(1) and bash.info don't document what it means to pass
an empty string as the argument to the -d option of the read builtin
(what actually happens is that in all cases, bash uses the first
character of the C string that the option gets translated to, which is
'\0' for the empty string; the documentation just refers to "the first
character of the string passed").
- --
Jonathan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJWdeydAAoJEEIQbvYRB3mgnQ4P+gP6WHxcyb6PZaBo8EG3nj/i
I5mbIs4XSsp4G13SVm54nTQelPzDlDLtMsRqdAj5Oh+oXrCyLLFcUKSpUf/1laNG
z7pzY6FStgFm1MZWAajtw16xr1+tAbkmGbGy/6pYvSVu7yNiI1n/P+2tBij6e6rN
cOeLtqRGfb1M0Ew3Py2qKVmWYf+/YxH6AkwFZGBZRcb+q3lCSZ9Ycbk3GRBStZwG
wi3PAf6nnuEaouuk7GA33Fi35cmHs8MISVIC70ULakOTu51xHm7aVJCzZQQIFl9N
WvH04+IMCcX+BleU6mP4LK0NB647WwKR8JWgcl8qj2415RvvImCtE35bhnpJbf92
PcVP1l4NJzbUUyfXMDZBpvxzXMHTz2DA4b9PS5Mq8jhiA1jKqAWFD5BBG05SHyrA
IpD0CKipLUFsXyJ5z/MS0gmUFFwymhB+dBVtKOqa4a4s40H2qahY3ffyn/MzIx52
imAYb7IK4MqCPQrzr9nM7qf7UApyLEaQDjN5n+bJ4ZEEd+p3kdf2sVrAFdTom0SU
hXmF1+7TCW4pVB6kL35YbtJkKQbHPfXTHVAJ/ctsLMMNNzXSiKUdnlCV+CwWfrgC
ptMy/Rk7WoHssyQZgl83JsQBdz396j0M6M3+kUNSGFThCz3OF9YBAccrKy7gqeHr
cyg+QQQN4yNyFaWl7S9a
=5O6Z
-END PGP SIGNATURE-
Re: [gentoo-dev] Multilib team lead election / future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/30/2015 04:01 PM, Ian Stakenvicius wrote: > On 30/09/15 03:57 PM, Michał Górny wrote: >> Dnia 2015-09-30, o godz. 21:36:51 Michał Górny >> napisał(a): > >>> Hello, multilibbers! >>> >>> It seems that one year past last election has passed. The >>> team's not doing much lately either now that the major part of >>> the work is done. This pretty much brings two possibilities: >>> >>> 1. electing a new lead, >>> >>> 2. or deciding that the project is no longer needed and >>> discontinuing it. >>> >>> Let's vote by mail, like the last time. Every team member is >>> allowed to vote. Every team member is nominated. Please reply >>> to this mail with a vote on one of the members, or discontuing >>> the team. >>> >>> The voting ends 2 weeks from now (2015-10-14) or when all team >>> members vote. >>> >>> Team listing (from wiki): aballier, axs, jcallen, mgorny, >>> pacho. > >> Oh, and I vote for axs. > > > I vote mgorny! all hail, fearless leader!! > > I vote mgorny. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJWDGZIAAoJEEIQbvYRB3mgcC8P/1twThG8iqvp/eUyzA4nKCug KT6fshvc3mFwNLpWkcZ5A7lTNm0ZT2/81SscK6IjtzOKRm9LlTdB8rXhKAjoliWk OcKPrd0x54inBM7jBceoCzK+ABnVNDFs9aixKwgjUzfwLpv3WvcfYjF6iAEyaAOV L8bZpr3AHiCwrd9noCB/+EHo4AV1zWuAMcXtVa3PESBwIuQzrfpMgE+CVnpmWUeo ndgeqseahcQtUgpqvwx75uI9bmW5w8jl4cH6XcZemFMNr2p4yxOW3Qub9Iy4bYbd jHnIX2xn8KjMH0aUSXFrqmbUYaIOMVuwxklxFCEw3JtCeHky4fqiFiOrDxqqrUmE 8M+zeHXPMuENZu/vR56IXeWMFWFayJHCmmzbGVw+FYKmCCJak7rjf9Sd0h451Y9w p21ZspbsoTpLiPc/h+HPEKOHDOU79WMyDgoHWn+e0nFMKIbQiavHYLGOPjr8QH3i bpsLiBUGW1bS6Lp/pLKgUu96l1fREnUNFvbEMKdlNxV2Ud+nLlLgELTyGlS4361P ByUhJpHRt4sP5v/W6MCUtkd7hC7X6SXx5o1XEiFY+MTwuOSU3AliMwB6XseYNYHe 1ovPe+tsC6qRYz+bqmrj3Of6gJlx5TH3VlZ5rlt3O++xFRX2Rzjgfh2dTb1ye/IF hP2hucOxWDE2y3yK2byt =8H8L -END PGP SIGNATURE-
[gentoo-dev] Re: qa last rites -- long list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/08/2015 02:23 AM, Daniel Campbell wrote:
> On 01/07/2015 04:19 PM, Jonathan Callen wrote:
>> On 01/07/2015 12:15 PM, Matt Turner wrote:
>>> On Wed, Jan 7, 2015 at 7:57 AM, William Hubbs
>>> wrote:
>>>> On Wed, Jan 07, 2015 at 06:49:56AM -0500, Philip Webb wrote:
>>>>> 150106 William Hubbs wrote: This one is perfectly safe on a
>>>>> single-user system : please leave it there.
>>>>
>>>> I'm not opposed to it staying in the tree under one of these
>>>> conditions:
>>>>
>>>> 1) fix it and remove the mask
>>>>
>>>> or
>>>>
>>>> 2) remove the mask and add ewarns to the ebuild
>
>>> Remove the mask that people have to see and actively disable in
>>> order to install the software and replace it with ewarn
>>> messages that they likely won't read?
>
>>> I don't see the problem with versions with security
>>> vulnerabilities masked in the tree. nethack in particular has
>>> been masked in the tree since 2006, so we have some
>>> precedence.
>
>
>
>> The only reason there is a security issue with nethack (and other
>> games like it) on Gentoo, and only on Gentoo, is that the games
>> team policy requires that all games have permissions 0750, with
>> group "games", and all users that should be allowed to run
>> games be in the "games" group. Nethack expects that it have
>> permissions 2755 (or 2711), with group "games" and that *no*
>> users are members of that group, so it can securely save files
>> that are accessible to all users during gameplay ("bones" files)
>> and ensure that the user cannot access/change their current save
>> file. These two expectations are incompatible with each other,
>> and end up creating a security issue that upstream would never
>> expect (as no users can be in the "games" group traditionally).
>
>
>
> Is Nethack's group expectation hard-coded? If not, then what's
> stopping nethack from using another, self-made group (like
> 'nethack') to arbitrate the bones files?
>
> If it *is* hard-coded, then can we produce a (hopefully simple)
> patch?
>
>
The problem was that you could not have the game setgid to "nethack"
*and* only executable by people in group "games" at the same time, as
they both require setting the group of the executable in order to
enforce the policy, and a file can only have one group (not counting
ACLs, which are not always supported).
As it is no longer required to follow the games team policy, the issue
can now be fixed by *not* using the "games" group for nethack.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJUrzrwAAoJELHSF2kinlg4IQsP/3gdF1OxDh0tOdqxd45tL4G+
1avsJ2x1+mVWM5hi2kYx3ZG3SIAOPqJdqVrFf+WozzAjDVC7Sd6WPs//E9i630HW
72O8zvO1s4CpqBrsu5Yb8BuhUHzcc4HO/3hE5rex7uhsOpPVqr96LdKtPJ74qFOH
T8aL/qk46HPCEc3Dg+lKVYDnhNKfThmjq3bx2NKFFgN3VaPOEc4IUs/NCkj/PzIt
UlgqwpD343qC+21xyboXVhIKeIyaaDZC2nwf/F92hhI2Xdcc9aw99O6S3mAuw1Xh
YDS3XN/4EvSMgSnCMC++S0LAT7nVkbghdhUh3R92UwJQoQcDzxOR6dEBrU7zjy++
L8c3A8gM8SfmtpwjqH2JwWF9AZ29SwVM1VtBus9EiREV0mthFC/Owz7Xfalj6VsS
u24hZn6NCRZ97FkOeX+GhAzAKLJHftLZW/ElgiFNwKFGA8qIjc4KIcc7Wg6opnDU
y4zV1f3YnUgS/4eMZxW4gcRoDTMSiPo1K5I2lSYC5Q9pId4Y3XvrjBkh5i6LA7Cc
2Pb3X4ZmWXvzm9p20kk6/SNp3qj6S/DnflWwWYmVnw4Le+Fa3+wlyS49yhL2/Aoa
nLtfHlgSZkKY6rLpa9swNKiVmYEu1PxdYDB2nlGfTn8nUiwyszRGpiai0ABwEWnR
NL9n1n5H6PTVOhElIKF2
=Mc9p
-END PGP SIGNATURE-
[gentoo-dev] Re: qa last rites -- long list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/07/2015 12:15 PM, Matt Turner wrote:
> On Wed, Jan 7, 2015 at 7:57 AM, William Hubbs
> wrote:
>> On Wed, Jan 07, 2015 at 06:49:56AM -0500, Philip Webb wrote:
>>> 150106 William Hubbs wrote: This one is perfectly safe on a
>>> single-user system : please leave it there.
>>
>> I'm not opposed to it staying in the tree under one of these
>> conditions:
>>
>> 1) fix it and remove the mask
>>
>> or
>>
>> 2) remove the mask and add ewarns to the ebuild
>
> Remove the mask that people have to see and actively disable in
> order to install the software and replace it with ewarn messages
> that they likely won't read?
>
> I don't see the problem with versions with security
> vulnerabilities masked in the tree. nethack in particular has been
> masked in the tree since 2006, so we have some precedence.
>
>
The only reason there is a security issue with nethack (and other
games like it) on Gentoo, and only on Gentoo, is that the games team
policy requires that all games have permissions 0750, with group
"games", and all users that should be allowed to run games be in the
"games" group. Nethack expects that it have permissions 2755 (or
2711), with group "games" and that *no* users are members of that
group, so it can securely save files that are accessible to all users
during gameplay ("bones" files) and ensure that the user cannot
access/change their current save file. These two expectations are
incompatible with each other, and end up creating a security issue
that upstream would never expect (as no users can be in the "games"
group traditionally).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJUrc0kAAoJELHSF2kinlg4U48P/0832YIuICSAqjvPd2HOevs0
PISYT08qafzPevhppfe4YC4G1Z2hpoUaiLTiEozHDGfEkwoxMjIQQWEB1idco5Wo
gbYtUtX3X7BgAlBQxNMlb6jnc+xExAKqwB35SJF4374s3gw3GEWmED2eNJzgCdnM
pERhAsKXpc9GNFCY31QmscWFAu+Wk7l8HjEWjKbZ9491dHESDpzBp3HSPoxGtUMH
wsL9vVhfS/JPEbLTcoCWwyx2s/et/wuEcnEO7c0N2byfxm6e0MXPS8vs4ZiMCRsl
+nVKTkCH4uH5LTF7KQJ/Djiju4+dtydmByOJ/FrC3T+6E47X4n8m4fXWUa09jHsZ
VO6YOxJLSbitw0FVE2RubGKbDVbQE7vHRefGxgtv0ZnpkeFC/8hoOAmntFCkbkmy
WKtTPNPxCCOIMU6AE4G53HkeLJ9aOBZFl/el4OKYGTTuRX6o80f0GzRdsiFAqbqz
CbP+pSDFMeqicP0P2R2rt5VFfa61DHLWYTO93hcSfgsBJ3tTFAPE4rh/hFQtbz0Z
W4Mife7QLN6SVh5KjWlUSAv3b9CFubDMcj9cUL63RNdp5yKUef6XRJN2CEv3mhn4
PckC1yanE52NybvQxnW+xKp4G2qk5V/j0MZpBjUFqO6s1Tn6hw3kLs2VBqtO7wDJ
LQWCPkTSyRjSIsJUa4Vg
=Zqwb
-END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo git workflows and the stabilization/keywording process
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/21/2014 01:21 PM, Michał Górny wrote: > Dnia 2014-09-18, o godz. 19:39:08 Tobias Klausmann > napisał(a): > >> Since we're causing at least mild upheaval process-wise, I >> thought I'd bring up a topic that will be exacerbated by the git >> migration if it's not really addressed. >> >> AIUI, we try to avoid merge conflicts, unless the merge is a >> meaningful integration of divergent processes. >> >> However, one aspect of how ebuilds are written these days will >> cause a non-trivial amount of merge commits that are not >> actually useful in that sense. >> >> This is due to the way keywording and stabilization work on an >> ebuild level. Since keywords are all in one line, any merge tool >> will barf on two keywords being changed in disparate clones. >> I.e. if I change ~alpha->alpha while someone else changes >> ~amd64->amd64, we will have a merge conflict. > > If someone stabilizes the package you have edited, then most likely > you actually want to edit your commits and move the changes to a > revbump. > > If at all, I'd be more worried by a case when queued version bumps > would lose keywords that were added in the meantime to older > versions. > The case under discussion here was where the only edit made locally to the ebuild was, in fact, stabilizing the ebuild on a different architecture. In this case, the correct response would be to ensure that the final commit pushed (whether it be a merge commit or rebased) contains the stabilization for both arches, as there would be no need to revbump to add a stable keyword (in fact, I'd call that an incorrect resolution). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJUHy8BAAoJELHSF2kinlg4wPIP/jrDAo0ye4f/5jRF3AwZYTN8 UkEJywDWFA4K9ffZbuAN2gGEWGclh6p5fMiiPwKjxAaMDzopuWdzWRrVYXsTEqqW SKT0jmAQroSiXj3DLczuvijw0xhY1sKLAUUnnsxhdieYb61SusIBV5xtDl4R/xuD pF8wtlEp/KL3Kbba4wlcBL4lZsSannuNZ8BA0QyGhPfiLb/UEYQsL+hhwWNR9IlM HnDuBzdHFvJP29QfP556+ItxoKFDFJpRMYqukN2Ws1g276DesryWe0iWF9hvzCyj VdTml7T+u1i7VXM9UCE0IAp7r94y/14Q1S/+XWLNxATFxI2xVP3HuecZVKwDYhcy zu8FTcRmYZddIzhcnUKVWe/e5ihIvYlesEoKVgsl6TCXbcbshzyKEpfZXcjTs5Po gQe32QPDwLetqO5qbko51SbO2E1gCMEFrzf+MsBLE2oO+nhfEbL6Gmsx5F7beM37 AafEdb8U3ZBi7jz2/zPGBKzoyDinbjB9o5I+mrwG7qL4t0OZDjS9Qg/eOg3lm3cF 5tQbMNvVOzxBocis3FSk+L9lMVxQKQAYCrYn52meZbbCdFc85bnqXuCZvh1Q+mp0 zgX8vroDDyzpzP6AJeq8haP10TExnVABbsZHV9YxhVEipQO0mPrtzDWodS157dEN yzgJrofBkxqf/r2hUcvX =gARN -END PGP SIGNATURE-
[gentoo-dev] Re: RFC: kde5 and kde5-functions eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/15/2014 12:19 PM, Davide Pesavento wrote:
> kde5-functions.eclass
>
>> local ver=${1:-${PV}} local major=$(get_major_version ${ver})
>> local minor=$(get_version_component_range 2 ${ver}) local
>> micro=$(get_version_component_range 3 ${ver}) if [[ ${ver} ==
>> ]]; then
>
> No wildcard match here? (*)
This is intentional, and comes from the kde4-functions equivalent.
The KDE version of the 5.0 branch is "5.0", not "live". Only the
master/trunk/etc. branch of the live repo gets the "live" designation.
(Under KDE SC 4, we used versions like 4.14.49. to reference the
4.14 branch, as upstream liked to use versions like 4.14.90 for a
beta/rc of 4.15; I haven't been involved enough with KDE5 to determine
what they're doing now.)
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCgAGBQJUF5MnAAoJELHSF2kinlg4mm0P/1DFUilFc8IfYNIsJqqK96Ec
hWrrDwK1Hy0yxCfJE4NccX7OGJjJDRi7r0O1XnEPc0vueXlCsTCzHFkOZDJOXz0M
+B6bbJm5WJCz9GYrU4rIY/BflSARPzCh+YZoEUu5Azvu2DuZkh3kHYw136mqnrvT
woqTAMPWaPZPQXMk3r8dmdSsjjtY+eplL68TSYh4x8p6qgSW/19UZcF0HjlfvHSd
JfrJ+TKupXa7i77PMOsR0GkHztVUyFbu2vVYnkPI52W7dLwlv9VuFDNGjprRl4ve
Xa5PzLGcz9Xr9JAtWSdPaTycRfkNpmYKJYwLRoOVIhJ3FvuZdT2ZD+P3x+uetem5
QumharQhkt5UNrwkWYC/KgVEJsLb0nVAYMDYUkaDTbYv1inEN6NkACjZrqvYTuSm
8zt4P9hhe73I7AliUD0AI70muvlOrGaseDXSrD0thsibqPHpK215IUgVyCNQjQ7U
NRu73bL2cEQ9fuoxzKmfTY3oPl5B9W9J3sXiKU4SEbWzplhJRQ2zBX1ZyqNgJMiP
ZZH1XWAiaotUzsrALcHcJ1iCCFE2rloIMA8unuxFhh7ch5MkMKsWfMLXio/pudTW
A0pHbnTAWonWIWdTy5HjBe7wUxu5Wxb09S5UbgCsnI6QhhorBNwvWfy/RGqdUThl
EUYzDpG+4ImziiPSm9Yu
=73JG
-END PGP SIGNATURE-
[gentoo-dev] Patches for multilib-build.eclass
The attached patches (attached so that Thunderbird won't mangle them)
fix some of the documentation for multilib-build.eclass, then add a
couple new functions to simplify some use cases where a flag would be
unconditionally enabled for native builds and disabled for non-native
builds.
--
Jonathan Callen
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -567,9 +567,6 @@
# @DESCRIPTION:
# Determine whether the currently built ABI is the profile native.
# Return true status (0) if that is true, otherwise false (1).
-#
-# This function is not intended to be used directly. Please use
-# multilib_build_binaries instead.
multilib_is_native_abi() {
debug-print-function ${FUNCNAME} "${@}"
@@ -580,14 +577,7 @@
# @FUNCTION: multilib_build_binaries
# @DESCRIPTION:
-# Determine whether to build binaries for the currently built ABI.
-# Returns true status (0) if the currently built ABI is the profile
-# native or COMPLETE_MULTILIB variable is set to 'yes', otherwise
-# false (1).
-#
-# This is often useful for configure calls when some of the options are
-# supposed to be disabled for multilib ABIs (like those used for
-# executables only).
+# Deprecated synonym for multilib_is_native_abi
multilib_build_binaries() {
debug-print-function ${FUNCNAME} "${@}"
@@ -615,7 +605,7 @@
# @FUNCTION: multilib_native_use_enable
# @USAGE: [ []]
# @DESCRIPTION:
-# Output --enable configure option alike use_with if USE
+# Output --enable configure option alike use_enable if USE
# is enabled and executables are being built (multilib_is_native_abi
# is true). Otherwise, outputs --disable configure option. Arguments are
# the same as for use_enable in the EAPI.
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -617,6 +617,34 @@
fi
}
+# @FUNCTION: multilib_native_enable
+# @USAGE: []
+# @DESCRIPTION:
+# Output --enable configure option if executables are being built
+# (multilib_is_native_abi is true). Otherwise, output --disable configure
+# option.
+multilib_native_enable() {
+ if multilib_is_native_abi; then
+ echo "--enable-${1}${2+=${2}}"
+ else
+ echo "--disable-${1}"
+ fi
+}
+
+# @FUNCTION: multilib_native_with
+# @USAGE: []
+# @DESCRIPTION:
+# Output --with configure option if executables are being built
+# (multilib_is_native_abi is true). Otherwise, output --without configure
+# option.
+multilib_native_with() {
+ if multilib_is_native_abi; then
+ echo "--with-${1}${2+=${2}}"
+ else
+ echo "--without-${1}"
+ fi
+}
+
# @FUNCTION: multilib_native_usex
# @USAGE: [ [ [ [
# @DESCRIPTION:
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: USE flags in virtuals, to allow a specific provider to be determined
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/25/2014 05:23 PM, William Hubbs wrote:
> On Fri, Jul 25, 2014 at 03:54:53PM -0400, Ian Stakenvicius wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> On 25/07/14 03:51 PM, Pacho Ramos wrote:
>>> El vie, 25-07-2014 a las 20:46 +0100, Ciaran McCreesh
>>> escribió:
>>>> On Fri, 25 Jul 2014 21:44:02 +0200 Luis Ressel
>>>> wrote:
>>>>> Okay, I didn't think of that. I'm not sure if the blocker
>>>>> deps or the REQUIRED_USE would be more helpful for Portage,
>>>>> but generally I think that the REQUIRED_USE error message
>>>>> is quite hard to understand for unexperienced users -- much
>>>>> more so than the error generated by a blocker dep.
>>>>
>>>> ...and the fix for that is to scrap REQUIRED_USE and use
>>>> pkg_pretend instead.
>>>>
>>>
>>> Could you give an example to let us see how pkg_pretend could
>>> be used to achieve the same as REQUIRED_USE?
>>>
>>> Thanks
>>>
>>>
>>
>> pkg_pretend() { if use heimdal && use mit-krb5; then eerror
>> "Please set only one of the use following flags:" eerror
>> "heimdal, mit-krb5" die "conflicting use flags set" fi }
>
> I think this could get complicated really quick though. For
> example, if I have an ebuild with three use flags,
> flag1/flag2/flag3 with the requirement that one and only one of
> them must be set, unless bash has an xor operator I don't know
> about, that is going to need a lot of nesting etc to get right.
>
> William
>
If you want to say "At most one of the flags 'foo', 'bar', and 'baz'
may be selected", then you say it like so (requires EAPI=5):
REQUIRED_USE="?? ( foo bar baz )"
If you want to say "Exactly one of the flags ...", then you use:
REQUIRED_USE="^^ ( foo bar baz )"
And, as always, you can say "At least one of the flags ..." with:
REQUIRED_USE="|| ( foo bar baz )"
While each of these can be written using the "foo? ( !bar )"-type
primitives, the messages portage outputs are generally better with
'??', '^^', and '||', as you might see something like:
"
The following REQUIRED_USE flag constraints are unsatisfied:
at-most-one-of ( foo bar baz )
"
Which is, in my opinion, more readable.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJT0+lKAAoJELHSF2kinlg4T8sQAKLq2d4x8UfDTxm8FP6yX5zv
g0GGjPe6TNSwJT83FIw2Bof85u2xGUHaozUaxr+3wwgYVmSaH8BcuEc41reaNZu0
aRhFonAySSTVW/OFEW/X+kpfxAgtFAVGsZ2MBXuFLshB+z/OPDL4lPS7pvUCSZVG
iXPlLNE05ZvF+mxSU4enKEChRPxYTBso3cXGqog0qAZrefv8I9w+QeesaGvXlr7v
65S9qPcgOhQRz1q5HfoQ55fdGHy53+/9ny86Gpxpg7xbEYUe0t2LCInFPT4ivL28
OAnSbwML7bMzphvT4EM+eHghfWIATRmnY5O7O9X66sOUB/JrtG3eQei/9EyAHwhA
JurcdfUu8zcsSjocuqxbQpMGeiEa1bcfzl3u39WUuFAoVsayzXEI3U9SziemmCpU
CCeRF+A5mV6PhFQBYczkdeu3xKc9zQoA3s/EaUYybmTli4oVwtMJUm224TWJEFg+
d7AxM49dyRPLHrHxbK69G7RVowXlaPlISCA/hahAmcgtZVD8y1phwP1qB9j8OBlL
DTrcuqiv9Ba4J+DmdhsjB/uvVZpoyfMVl9z1ytLKFjiEpo/PyJAPWRlRrAwq/Gz8
1rh4MrSqAEMGB4mEQaohDfMVVaCQmhGXZkpaBMtARiV3BDlI3W0bKPPh+r435ZZc
Z7PHHOimf/6acsprx/wI
=vExv
-END PGP SIGNATURE-
[gentoo-dev] Re: The request to abolish games team policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/08/2014 08:32 AM, Ulrich Mueller wrote: >>>>>> On Tue, 8 Jul 2014, Rich Freeman wrote: > >> On Tue, Jul 8, 2014 at 3:31 AM, Ulrich Mueller >> wrote: >>> The install locations (/usr/games, /usr/share/games, >>> /var/games, etc.) are specified by the FHS. So they're not >>> entirely games team policy. > >> I just checked some random packages on Debian and found that >> adherence to this path there is mixed. I'd say the majority of >> packages I checked installed in /usr/games, but quite a few did >> not. Many of the ones that tended to install there were games >> that probably predate the Linux kernel, but this was by no means >> exclusively the case. > >> Their official policy says that games should go in /usr/games >> though. They also state "Each game decides on its own security >> policy." They apparently only use a games group for things like >> high scores and save game dirs, and use sgid on the binary to >> accomplish this (minimizing its use in general). (Note, I don't >> run Debian much, so this is the result of a quick scan of their >> policies and the real world may vary.) > > It certainly differs between distros. Debian generally uses > /usr/games and has a games group for score files. Fedora has chosen > to ignore the FHS and installs everything in /usr/bin. IIUC, they > also use an own group for each game if it needs to write shared > score files. [1] > > Ulrich > > [1] http://thread.gmane.org/gmane.comp.freedesktop.games/365 > Just to clarify, the current Gentoo policy is that game executables go in /usr/games/bin and libraries go in /usr/games/$(get_libdir). Debian policy follows FHS in that games binaries go directly in /usr/games and games libraries go in the same directory as other libraries. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTvKBxAAoJELHSF2kinlg4y/kP/jj6wkESt7cXnj+MdgIcdYQd 2DSz1LQID4GyS4+Zkc8oIIfQCjWVBp4ZL3biEPDi2wWoF8gmsQPcnzru0/XlLwlb +0S4NfrsA4I53DUztDV1XW4Wsi1VxYF2RzCo/W+S7ZdzNceAkRcvFt9hEUhNlFnu 6DCw/yf8dHC3IkblU3Bs4ZYltkVQbCIuc02RYyT8UYKW72h5vbW0BJg032WYJkA5 gYW0RSWplv++z1ngeI+7LJ/bAJzD9wwriSY3ilBknrBNlR1AI2/S3EdQsQUyJt8I QrlweD7KIlhjj1Rb7zet04FMyLfoVtD0h2Gbyvht2l6ZQLvV8aIuO9VwWdaST2fF 45UkGKIMYt3zU4qH1l4qo5IuYYSkPcSmzXAdCG8GlKmWShI3heQcKEafH2kR35e7 os7D5z4DofzpwRgjd4KKebG3v0q3NLUyKhrlik2dTSO+jPOYGj45Ow1o83Up5U6V 9xB6PilLx9SoiVvU1prwG3WGd1s9J3YGq4JWWzxm9mGGQThdrvQUvLFNoIO7zOWF l0Dp4IMLnfrmGa9RWyzaBbYMZMK693novbkbr7yW+PFaBUjfKEsxasp9JHTwBDcF jW2iAf/a1JraP1APbDp9gYCXHfDO9wNXwzI3wyT5QvLkyzkLBUkPg+3gcdIDFgbM ugURcg6HIZ1bd4vQED6U =RdNt -END PGP SIGNATURE-
[gentoo-dev] Re: Making a common sub-profile for no-multilib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/03/2014 12:59 AM, Duncan wrote: > Jonathan Callen posted on Wed, 02 Jul 2014 19:06:59 -0400 as > excerpted: > >> On 07/02/2014 02:14 PM, Duncan wrote: >>> Rich Freeman posted on Wed, 02 Jul 2014 09:30:50 -0400 as >>> excerpted: >>> >>>> Some things to think about include multilib (just another >>>> arch?), systemd, and usr-merge. >>> >>> FWIW, systemd with merge to / (/usr being a symlink to . and >>> sbin to bin) here. In particular, the merge "just works" with >>> current portage. I'm no-multilib. >>> >> That merge only works because you happened to get lucky, and >> have portage merge coreutils in a particular manner >> (/usr/bin/uname installed before /bin/uname). If portage had >> installed /bin/uname first, you would have ended up with a >> /bin/uname symlink pointing to /bin/uname. The same is also true >> of basename, chroot, cut, dir, dirname, du, env, expr, head, >> mkfifo, mktemp, readlink, seq, sleep, sort, tail, touch, tr, tty, >> vdir, wc, and yes. > > No, it works because, as I specifically asked the portage folks > about before I tried it, portage has had symlink merge intelligence > for some time now. Apparently well before I asked (in May, 2013, > according to my portage-devel list archives), some portage dev > considered the possibility of directory symlinks triggering > overwrites of targets with the symlinks pointing to them, and > ensured that portage's qmerge code "just did the right thing." > > I did nothing with the answer for some time, but eventually decided > to try it. As I was a bit skeptical/careful at first, after doing > the initial manual moves and thus finding which files existed in > both target dirs, then deleting the individual file symlinks, > moving the remaining files to the new location and making the old > directory a symlink, I equery-belonged the symlinks and manually > remerged (from binpkg, which still stores the symlinks in their > usual location in the binpkg tarball) several of the packages one > at a time, first a non-critical one, then I think coreutils itself, > just to be sure, then 2-3 others together, and sure enough, it > "just worked" the way it was supposed to work. > > =:^) > >> I myself am currently running a system with the opposite merge >> (/bin, /lib, /lib64, and /sbin are symlinks to /usr/bin, >> /usr/lib, /usr/lib64, and /usr/sbin) although I do not yet have >> the sbin -> bin merge yet. > > FWIW I decided the single /usr -> . symlink was simpler, and > besides, I liked the shorter direct paths. =:^) And I did the /usr > merge first, thinking I wanted to keep the bin/sbin distinction at > first, until sometime later I decided to simplify my PATH var to > remove /usr, and realized I had sbin in my normal user's PATH too. > Completing the merge would/did allow me to simplify PATH even > further, and since I has sbin in my normal user's PATH, there > really wasn't a reason to keep them separate at that point, and I > was already comfortable with merged bins by then anyway, so it > wasn't much of a stretch at all. > >> I added a post_src_install and post_pkg_preinst hook in my >> /etc/portage/bashrc to ensure that there are no conflicts before >> the package is merged and a pre_pkg_setup hook to disarm >> gen_usr_ldscript (so as not to create a conflict). > > That's all unnecessary, because as I said, in general portage "just > works" with the merge now, since it's designed to work with pretty > much /any/ strange site-specific symlinking local gentoo admins > might throw at it, altho I expect the ldcache stuff is still doing > a bunch of extra work by going over all the dirs that are actually > the same thing, and I suspect revdep-rebuild (which I still run > religiously after every @world update) is doing a bunch of extra > scanning too. But as I'm on SSD the extra filesystem IO isn't a > big issue, meaning it's simply the CPU cycle cost, and so far > simply spending the extra CPU cycles has been cheaper for me than > actually researching what I might do about it, so... > That is good to know. I did, however test when a package installs two (different) regular files into paths that end up symlinked, and found that portage does break in that case (as the only sensible option at that point is to fail, as something will be lost in either case). - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTtQDKAAoJELHSF2kinlg4eIIP/0Jmia/151IPA
[gentoo-dev] Re: Making a common sub-profile for no-multilib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/02/2014 02:14 PM, Duncan wrote: > Rich Freeman posted on Wed, 02 Jul 2014 09:30:50 -0400 as > excerpted: > >> Some things to think about include multilib (just another >> arch?), systemd, and usr-merge. I'm not saying that we need to >> implement any of that stuff completely - but when planning the >> profile layout we should at least consider whether it will handle >> things like this in the future. Should some types of profiles be >> only additive? Etc... > > FWIW, systemd with merge to / (/usr being a symlink to . and sbin > to bin) here. In particular, the merge "just works" with current > portage. I'm no-multilib. > That merge only works because you happened to get lucky, and have portage merge coreutils in a particular manner (/usr/bin/uname installed before /bin/uname). If portage had installed /bin/uname first, you would have ended up with a /bin/uname symlink pointing to /bin/uname. The same is also true of basename, chroot, cut, dir, dirname, du, env, expr, head, mkfifo, mktemp, readlink, seq, sleep, sort, tail, touch, tr, tty, vdir, wc, and yes. I myself am currently running a system with the opposite merge (/bin, /lib, /lib64, and /sbin are symlinks to /usr/bin, /usr/lib, /usr/lib64, and /usr/sbin) although I do not yet have the sbin -> bin merge yet. I added a post_src_install and post_pkg_preinst hook in my /etc/portage/bashrc to ensure that there are no conflicts before the package is merged and a pre_pkg_setup hook to disarm gen_usr_ldscript (so as not to create a conflict). The only two packages I have installed that I had to modify to make this work were coreutils (as noted above) and plymouth. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTtJCTAAoJELHSF2kinlg41W0P/19TAJErj3y7eMFGJG2BMVIM TtAj2wM+whB0Md1+TGypFS0ESO+hJAxNyyuIT215afRIqZJgYjZG5NZCnmygI71t 9das1k2JHn+PRO5KSZcw3Z3VcpspzADTwR+avaxiqRuslzyTvAYrsPj+7oQd6iDp 4XzDKFSEh2hNJHUQUQ3eT5NxlJNQu9uxKLc4aM+1/GImlSAVbbiKHUHWy3njSVWN twFkQJ59IHod9aZgn0txydd9hhMr43Et6uDJywjGuIeVQncAO/eBvT9hRE5tB3aN x/pd1Dcf0V5FTN/459kcoRwTBQ2k3quhGJBeSSGLUwNlTjdOWDbqU5HcgOf0d7v4 NXMIOr95ung3LgeqCyZU5S4XTyoh9w/nZRXuSTYL0sQL3IxffLRkVPcvis02cY6a jZaSAwkVkPhyAGkV0QxMsfhEP9+2wdtB7JMc28kslO0kGpdV5Oa8ES+QqnwVXgi7 umB+5D4IjTDK6uPcM5K5p+8wKWcsFMvn5X/+3Fh49S6KDiWZRsjq45pHC7+5lC0p S8EJb8XybieRvQsVGo8NfgucvRQFbeUn+BaUfztoNRvKG3NxsnxRJ+JycK9bi1pj znu7YKmCZMmt8PurliQPKQ6vtPjFQK19gZZf72zTVBycc2hdaKnbowAV0rBgTETN +8xryIRBNfISkUIjEip/ =Muzz -END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH multilib-build.eclass] Add multilib_native_use* functions to make ebuild writing easier.
On 04/19/2014 06:53 AM, Michał Górny wrote:
> People are either inlining this or creating local functions for this
> purpose, so it'd be better to have them in the eclass.
>
> RFC: what about '!use'? Should we invert the multilib_build_binaries
> test as well?
> ---
> eclass/multilib-build.eclass | 48
>
> 1 file changed, 48 insertions(+)
>
> diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
> index 77e7573..6adfc76 100644
> --- a/eclass/multilib-build.eclass
> +++ b/eclass/multilib-build.eclass
> @@ -462,5 +462,53 @@ multilib_build_binaries() {
> [[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi
> }
>
> +# @FUNCTION: multilib_native_use_with
> +# @USAGE: [ []]
> +# @DESCRIPTION:
> +# Output --with configure option alike use_with if USE is enabled
> +# and executables are being built (multilib_build_binaries is true).
> +# Otherwise, outputs --without configure option. Arguments are the same
> +# as for use_with in the EAPI.
> +multilib_native_use_with() {
> + if multilib_build_binaries; then
> + use_with "${@}"
> + else
> + echo "--without-${2:-${1}}"
> + fi
> +}
> +
> +# @FUNCTION: multilib_native_use_enable
> +# @USAGE: [ []]
> +# @DESCRIPTION:
> +# Output --enable configure option alike use_with if USE
> +# is enabled and executables are being built (multilib_build_binaries
> +# is true). Otherwise, outputs --disable configure option. Arguments are
> +# the same as for use_enable in the EAPI.
> +multilib_native_use_enable() {
> + if multilib_build_binaries; then
> + use_enable "${@}"
> + else
> + echo "--disable-${2:-${1}}"
> + fi
> +}
> +
> +# @FUNCTION: multilib_native_usex
> +# @USAGE: [ [ [ [
> +# @DESCRIPTION:
> +# Output the concatenation of (or 'yes' if unspecified)
> +# and if USE is enabled and executables are being built
> +# (multilib_build_binaries is true). Otherwise, output the concatenation
> +# of (or 'no' if unspecified) and . Arguments
> +# are the same as for usex in the EAPI.
> +#
> +# Note: in EAPI 4 you need to inherit eutils to use this function.
> +multilib_native_usex() {
> + if multilib_build_binaries; then
> + usex "${@}"
> + else
> + echo "${3-no}${5}"
> + fi
> +}
> +
> _MULTILIB_BUILD=1
> fi
>
These all look good to me (being one of the offenders mentioned above).
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: sandbox access violations while running matlab binary installer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/01/2014 10:03 AM, Kfir Lavi wrote:
> On Mon, Mar 31, 2014 at 11:53 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
>> Alexandre Rostovtsev posted on Mon, 31 Mar 2014 14:54:09 -0400 as excerpted:
>>
>>> The best solution is to figure out why the directory is being created there
>>> and whether it
>>> is customizable. Maybe the code actually is creating $HOME/InstallShield?
>>> Then export
>>> HOME=${T} in your ebuild.
>>
>> Well, "best" would be not to run software where the author doesn't respect
>> your rights to
>> study, patch and share the software, with or without those modifications, in
>> the first
>> place.
>>
>> But understanding not everybody is prepared to go that route and it's their
>> machines and
>> life, not mine...
>>
>> On the ebuild execution side, as a last resort you can turn off
>> FEATURES=sandbox and perhaps
>> FEATURES=userpriv as well, allowing it free access to do whatever it's going
>> to do.
>>
>> Alternatively and for both the ebuild creation and execution sides, take a
>> look at
>> /etc/sandbox.conf and the files in /etc/sandbox.d/, and grep SANDBOX_ in
>> $PORTDIR/*/*/*.ebuild and $PORTDIR/eclass/*.eclass.
>>
>> (Tho it's not always proprietaryware; take a look at emacs... based on some
>> of the other
>> packages that disable sandbox, I'd guess it's the lisp.)
>>
>> Anyway, SANDBOX_PREDICT or SANDBOX_WRITE will probably do it in your case
>> (violations not
>> flat-out-segfaults as emacs apparently triggers), but SANDBOX_ON=0 is there
>> if you REALLY
>> need it.
>>
>> Tho obviously if you were doing that ebuild for the main tree, any messing
>> with sandbox isn't
>> going to get it there any faster. But if you're doing it for your own
>> (including possibly
>> company internal) use only...
>>
>> -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program
>> has a lord, a
>> master -- and if you use the program, he is your master." Richard Stallman
>>
>>
>>
> Thanks Duncan,
>
> addwrite /root/InstallShield addwrite /etc/mtab
>
> did the trick.
>
> Thanks all for replaying.
>
> Kfir
>
IIRC, you really should use `addpredict` instead of `addwrite`, as you don't
want the package
*really* writing to those locations.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJTO3zXAAoJELHSF2kinlg4emwQAJNwluWdrGXrBMj3f+j4Sx8+
Ch6M5FF5lRqQXnnqZUvXrEd2t6iBMrZ0Xm/AVnAkCNr4vlpRdcS7ahmbCSC4jT2f
Plct5CG6+3/W1PbNfmSLoBxIlEU8vMzx4gUJtaGUOuuekjuYK+xKHjlskVJks0Y8
im0k/1VDR13J6NyneBmISH0SglmYmVTAezT9yngqm089cfi4DkZo4MdR/r4TUtRd
lu62NlZ517t2pNINJe5anRq9Q0D+obGg8gmZ0+C2jNwj+9thXZWnSLuV03eXpIG3
ntVaVRI2H4p9hPWQJMCfVsyVfudYDiP/05hOkeTOd3NV+8crODoY06CQNhZ7e0hb
yB+TE+bqufAuqaEalhEB5oxn61u+ALYHCXSRNjuQItzZrWRSXqV6r7Hd9TKtHEL0
w+ayThJYXqWDSj69yXpyHMldWovydKMVv7Goz9gdzBjPIRVfLZoUmvpl1RGwsOII
ahubgQPp2n0cibm0K2Uaqr1xg7MuvUr810hl/LVhK8OlsT3gqDgMXyZrG6S1x/jo
DV7qCJCqy5GjDc4KdS/tPTXJt9krAjRNDIxfA/jzvOC8lghZuAFFZpUSHfBR9XL+
VUMUwhwdathtQic20+t4vnXP24AetYvqaO7K1dRFJhopGE8P0gnt7r8xQa5uZSkr
QtKhDStXVcLkOnuw3jy+
=3dEf
-END PGP SIGNATURE-
[gentoo-dev] Re: New eclass: xdg-basedir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/30/2014 03:11 AM, Gilles Dartiguelongue wrote:
> Le mercredi 29 janvier 2014 à 22:37 -0500, Mike Gilbert a écrit :
>> One difference: it creates 3 of the 4 directories under ${HOME} instead of
>> ${T}, just to
>> mimic the default behavior in the XDG basedir spec a bit more closely.
>
> The thing with ${HOME} is that it should not be a directory where XDG
> compliants tools should
> be able to store anything permanent while building since this would affect
> consecutive builds
> (say gobject-introspection, gstreamer registry, etc).
>
> This is why it is set to ${T} in gnome2-utils.eclass.
>
I don't know about other package managers, but portage at least sets $HOME to
${PORTAGE_TMPDIR}/portage/${CATEGORY}/${PF}/homedir, so this is a non-issue for
portage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJS6gxWAAoJELHSF2kinlg43+0QAIRQta3FrJCG0rwC8eVN0TrQ
heU/UG5xxBXlnYfSx1KZMH2lasGsZ6d31oycW404muSt7L7gOnpQGAa0upXGMMeq
aC6dKyxj5psb0WQRp4NeNkofPyGzOGlK7LYiEgGdl63yEadWkU+1cTK8HCwNpYEt
iOyDE5o/W05M3iPSkdjetrvADh2w3jK6paVekPWKoeawADalJQ9pjPcNUdiNZSzb
D2L7Td/IAiEOUYt6sQVTs4idExhDc3ndSFNcd8Z/C1/L60EZlJd+CWcP7mReOJkA
pToVXOAACxCRUBR4tUq23BZmBGN7d891SfybLbkAc/UjyS7f1gvCLPq4WLvmE+G/
wVmqbnhilRkfP/ecjaZKDg+l32sf+yNbqth+aD9CvYvIo4wvhbFqxlu3tyut37fn
OdlwWi6vrMIHicem5NBx/u7E7lh/mnUFKGtPBY/jSPlPCGf/D2T9ET4M7PH5UIRQ
fQePKx1GrNvlm5R80qENl/qL72NxX5sEd+fFZ4O6utEnceKQFcLwn6js6HsHetXM
DQsEsiCnex+f204MQ+fFInqNU5Sfk5u207zwLELDiinfms9jSSsa6ovemC7NtmNq
bJZagpdm51Y5oKjJLZhHad3gwc5u1uJnc9vZGOYeoO0tlD0ad3Zq5PRYkxouWTqQ
5YrXNfLdT0tQ/NXngdWe
=JJd7
-END PGP SIGNATURE-
[gentoo-dev] Re: some multilib-minimal enhancements [3/6]: a shitload of in-source doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/11/2013 07:54 PM, Greg Turner wrote: > On Wed, Dec 11, 2013 at 2:01 PM, hasufell wrote: >> I actually feel that some parts of this is not documentation, but rather >> "wiki". So maybe >> that's exactly where to put it? >> >> The doc in the eclass should only describe the behavior of the eclass and >> the main points you >> need to know in order to get it going. >> >> But it is not a strong feeling. > > I think you're probably right... I'll endeavor to re-factor this patch and > put the wiki stuff > into the wiki. > >>> +# it is often best to put multilib-minimal first on the inherits list. >> >> first? You mean last or what? > > I definitely meant first -- the existing in-source doc said "last" but I > thought that must > surely be a thinko... unless my understanding of how inherits works is > backwards -- the first, > not the last, inheritee gets the default phase-function implementations wired > up to it, > correct? I suppose another assumption I have, that, if not shared, might be > leading us to > opposite conclusions, is that a majority of inheritors would want the default > phase function > implementations to be wired up to multilib-minimal...? > > btw, based on the same criteria you mention above, some of what I've said > about the matter > probably better belongs in the wiki rather than the in-source doc. > > -gmt > > The *last* eclass inherited that exports a particular function (via EXPORT_FUNCTIONS) is the one that prevails, not the *first*. Therefore, if it is expected that multilib-minimal.eclass's versions will be used, it should be nearer the end of the inherit line, not the beginning. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSqSBrAAoJELHSF2kinlg4JcgP/2KKiXTcRkBUQmT0A5X0NLJV TqthtEKHlQhAuc9VjVtMj+h1UhAuDxsK4tasUBlXG6b3ab3o5drXVyD+rZWJHr8N FaqWuwSsbnIxp461DNVbQk5vhHAHY9oxFxT1rV/wjgFIK0d6yZxSBBDWWtWLbOba ev/FRw5LqnK8JkX/YaGCo6HYNSxaSGTRdeuSlndfF5dLYXRFO5JIR98S6YtsZWFY jXjKNcYQNVX/HAeU42LCMffgODSiCmLQPE9D5vhP9hOD9tLlBe6WZLt8iKKaBOug rBvRaQq9lL7obivYohMqR+7MCeCcvlDc6rMu1ZEdBMEfN39lzmTiAp9wXlYpbB7Q pM1YI97bqXGwS8lpBL6AIkS5Uep/0q1UD8bDw67PMtOrCh5Oi/SniCY8pdZCqpms bFYp+MgtYtvopI+vtn1P7/P4LBv9LspReQ7lVV4ukKSkuqx7L4B3Az3fiHcTV8ce XCzbSkR4ZOwvAypXtMRhmfcpIchVegqLwUIZHVRkUH9Qwd+o4dvpmBIxkUVdqFJD OINNplQ1/WqxJdonkFVzWUAO1jE67M91uf3zcimB63ioNKwSQGalVGQt3Rp1RfCd eJgsgkmtvI8fqhnkZTO+i70Xl89+JXhz+R4tfMewTId4wch+w3EiX3PKJUbF9rWK P6tuUW0eRNp6t7SU2ZdY =WMyy -END PGP SIGNATURE-
[gentoo-dev] Re: rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/20/2013 04:12 PM, Michael Orlitzky wrote: >> # Redmine =dev-ruby/builder-3.1.4 ~amd64 =dev-ruby/rails-3.2.13 ~amd64 >> =dev-ruby/railties-3.2.13 ~amd64 =dev-ruby/actionmailer-3.2.13 ~amd64 >> =dev-ruby/builder-3.0.4 >> ~amd64 =dev-ruby/arel-3.0.2-r1 ~amd64 =dev-ruby/rack-cache-1.2 ~amd64 >> =dev-ruby/rack-openid-1.3.1 ~amd64 =dev-ruby/thor-0.15.2 ~amd64 >> =dev-ruby/activemodel-3.2.13 >> ~amd64 =dev-ruby/sprockets-2.2.2 ~amd64 =dev-ruby/sass-rails-3.2.6 ~amd64 >> =dev-ruby/coffee-script-source-1.6.2 ~amd64 =dev-ruby/activerecord-3.2.13 >> ~amd64 >> =dev-ruby/rack-ssl-1.3.2 ~amd64 =dev-ruby/mail-2.5.3 ~amd64 >> =dev-ruby/activeresource-3.2.13 >> ~amd64 =net-libs/nodejs-0.10.15 ~amd64 =dev-ruby/journey-1.0.4 ~amd64 >> =dev-ruby/hike-1.2.3 >> ~amd64 =dev-ruby/i18n-0.6.4 ~amd64 =dev-ruby/coffee-rails-3.2.2 ~amd64 >> =dev-ruby/treetop-1.4.10-r1 ~amd64 =dev-ruby/activesupport-3.2.13 ~amd64 >> =dev-ruby/coffee-script-2.2.0 ~amd64 =dev-ruby/polyglot-0.3.3 ~amd64 >> =dev-ruby/jquery-rails-2.3.0 ~amd64 =dev-ruby/actionpack-3.2.13 ~amd64 >> =dev-ruby/execjs-1.4.0 >> ~amd64 =dev-ruby/uglifier-1.3.0 ~amd64 =dev-ruby/rack-test-0.6.2 ~amd64 >> =dev-ruby/bcrypt-ruby-3.0.1 ~amd64 =dev-ruby/mysql2-0.3.11 ~amd64 >> =dev-ruby/ruby-net-ldap-0.3.1 ~amd64 > > Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and 3.0 > was released almost > exactly three years ago. Every time rails-3.x gets bumped, I have to manually > update the entire > list above. I need to do it on an x86 server as well, so I get to do it > twice; I can't even > copy/paste the list. > > It sucks, but it's still better than running ~arch. Problems like this should > be fixed, but if > you decide it's easier to ACCEPT_KEYWORDS="~arch" than deal with the > exceptions, you're asking > for trouble. > If you want a list that you can copy and paste between x86/amd64 systems, just drop the keywords completely from the line, so only the atom remains. This will cause portage to use the ~arch keyword *for the current host*, so the same file works on all architectures. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSFEdaAAoJELHSF2kinlg4cTsQAJeeN3LV9O4zZUwCGF8ttb7F X8oi+y6rL7hCvnsVqincnTA81pmlphHDViZ+kkIROFEzvrvpWbXrXHK0t9HvmaT1 q1rvmlZzpfXV4nHQRsUxZzUFGiFv8iKhpS5NhRtQyf13PFxPwq3pybnSnpMJcJ5m O6Co/+NkxF5ynYOeyLLHlpAHzwnJILTcz1H0SK5wFNUt34aROJRPRtJJfAjWJlDv oP4lsv2VvnoBc4MWEylV/HjuWQ41yRGxulRZMEtNspTT60QB3VCP1BctDF8FZU3G u48zAM2bkVnppzggtsBycdVSVTsn7gB/zfpd3ESnL9MfJkg9pw8mpzkvZMw691Lq 7jK7I1mYAbRfAaCad3qA7fxRWe/8taTuHQvzku9nKe6qJY/OGZScDunjh4ezukEb YWFMr8E/i8EnruxeuEghpwL22nIEXqScWJuP457IvQ2oNz6Pj6qzoJ4l1RD81uHl vE99kt04KbsXBdt0o6DCCRpxbPgi2G+qh4K/4hDp4tHubOcZ/1AYqQay1Eqjkfhi ozZGSOAnQ4ujI1KXuaKhM6QR3BdgPOb3iYNr7Wb6wGBRDKOvgPgPeieY5gEh/mvj lOSC5c1dY29TdLco+N7Dyx/xBCErxTON+2av2Cdav+kvZw5c0u7zKJXCVBQATfD1 ZQ4V/ueUr9PdUqwcfgaU =VwWr -END PGP SIGNATURE-
[gentoo-dev] Re: PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-devel/clang- sys-devel/distcc-3.1-r7 sys-libs/libsmbios-2.2.28 virtual/pmw-1 virtual/pyfits-0 virtual/pyparsing-0 virtual/pyparsing-1 virtual/pyparsing-2 virtual/python-argparse-0 virtual/python-argparse-1 virtual/python-json-0 virtual/python-unittest2-1 virtual/pyvo-0 virtual/pywcs-0 x11-libs/libxcb-1.9-r1 x11-libs/vte-0.28.2-r206 x11-libs/xpyb-1.3.1-r1 x11-libs/xpyb-1.3.1-r2 x11-misc/alacarte-3.6.1-r1 x11-misc/alacarte-3.7.90 x11-misc/dex-0.6 x11-misc/redshift-1.7-r1 x11-misc/sunflower-0.1_alpha53 x11-misc/sunflower-0.1_alpha54 x11-misc/sunflower-0.1_alpha55 x11-proto/xcb-proto-1.8-r1 x11-proto/xcb-proto-1.8-r2 x11-proto/xcb-proto-1.8-r3 - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRo9JhAAoJELHSF2kinlg4iCQQALEy5Zp4D7tAx3eJn+Ijn+3u JSQ0NZhCSp9c598+xkOLsHwa6B1O2NpJpnQMNjB9x1SSUlF85J6Vuer9PaswDuAs vZLGrjUyK4PwzghIFaOfzGShfW9HhQUi7UkuSmasgzyRiVgQJEwZ31IhX+SY0yeX 87AUYPIBGqzYoShNtvBT17GHw/02Et9/Gsm+wexE+BjXtH5RQXsjrCbQiXKtAXBI Y7u2sgl/tLIo5sPeKgPZtS4mKB0h02sGGOr5nIp3Pt9x1hc3deRskWl+mi1pci8H wGVlzyoGM0ZcxYdFsVbwbTMlgzsbuiupE2t62BPnfV0qAX6Y2qzdWIRj3QM6eFhx KioaXgO6MiaLpA/J4Wby0eRxrNM/LSNiEJO2rhcnr1csAwLdVGlEXWqTpChY+DVn EFv0pDzePylvHFU6LyBx4r06afqoeawjslO3ZQcl6EYDD3+ywi+m75nlMp2QgNAq jvliqb52rE02pqiPbjyAsBpQPCPLSvXH/KRk6vtPpMBVq373mmHPJfa5D2vpQwaj VuN/3XfREF9eucefFQ3KPD8PDxmnqk5tZ9wjkBcsnrXmPhiq3hh6O35WBHYVhQKj JXhD/+VolhU04B9WlOvYM/gkiN7FVNqX6k9vczQZYzVYx3pCAOUEVSR9hTpSTYgL p9StTSBgRHOCsAjL9zHl =key7 -END PGP SIGNATURE-
[gentoo-dev] PSA: python-r1.eclass, python-single-r1.eclass, and REQUIRED_USE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
A quick reminder for anyone using python-r1.eclass or
python-single-r1.eclass:
These eclasses provide a ${PYTHON_REQUIRED_USE} variable that should
be included in REQUIRED_USE under the same USE conditionals (if any)
that ${PYTHON_DEPS} is included in DEPEND/RDEPEND.
For example, if your ebuild has:
RDEPEND="
python? ( ${PYTHON_DEPS}
"
then you should also have:
REQUIRED_USE="
python? ( ${PYTHON_REQUIRED_USE} )
"
And if your ebuild just has:
RDEPEND="${PYTHON_DEPS}"
then you should also have:
REQUIRED_USE="${PYTHON_REQUIRED_USE}"
Failure to include these in REQUIRED_USE may cause the eclass to die
very late in the build process.
Thank you,
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJRo309AAoJELHSF2kinlg4dVcP/2t3v1t8CId8jK/c4VG8HLWL
zTEvTI3d8wQILuHydI9VkOZllo3dPWhhUhg/1qJjwEXXnKQXiYNUiVzbtwdkGro/
OlkCrrpDstHgawHiovIZjgyEG9Y+Nz2Z5nKorZIAMFSFepaFsIkihVR3VkeHiG9Q
7XOOVaH8mqGuj7JWZNqikCmB11a6t08jVM68tzwtTZUuil1IRE2qjO5akMPczsvk
3ndoMsv5hQwUE4wmmTH4ffiz+wp/JUylK2Ypy6p/UWlMw+oq8IusyvQdKztF2rU4
SyjnEOHcPtbLXMA24NHSAUov5L3xVcSu4he5A+QnY0Ghn0dZ7Wbk72aRZQP+MOk+
e18tdPRaXE35ux8s0ogLeuD04lju6z5/esJbP8LF8H6loiKCURxVOfYEhUugIMIc
ihb6h4o4cflz2tYV6USOHxUQ6pA78X7ftXGJhOOR1sf1/2GZcg7ZQvD0WqjNLbAo
U52yQl3/bKMVpezYLhkLxgzmRAdwbBdBFdiav8dX+QNYabLPG/0y6mkqK0pc59sS
Lsse/dXCPrxfI6MVbsSQAaFt4s/YNrf9NLabdPHShRlWX8pRc16feQFb7FoTCmWe
BzwBwG63Mvw2OOS0GrXIfXdFs9klbezoZ8Ql8Zb3CIZPWaBPAOYfCqZDHkDDAyQL
UYQyPJdIntHmxKbtMQr9
=frSU
-END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH] Support wrapping headers for multilib ABIs.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/23/2013 03:56 PM, Michał Górny wrote:
> +# This variable has to be a bash array. Paths shall be relative
> to +# installation root (${D}), and name regular files. Recursive
> wrapping +# is not supported.
Based on the code, this comment should read "Paths shall be relative
to installation root (${ED}), and name regular files."
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJRTiYdAAoJELHSF2kinlg4uC4QAJbQzbpgwBvrADDurGm8LID0
X8VuffHQovpV6m5Z5YM02u1NjJvVb9qXquGzlGowEjJg37u+M3JdfA6/ewNi4h7o
0RQIwRCv2TJNSfKeoce1hzFvmLAZlk7F8YZn9xJEDBBq37srbhWkugQJLNmmBlI2
UjLJXN3COxj3Z+biuqRmGPN7NoH/BpxRbaHd3y0E71ANesqpOxcoBIMztjJwJXI8
3WCmzKkwvpz0Suo4ycB4IQWIBH6+i3yg+iHw7CPz3kd4aCmraVWv5O2wm/pow9dR
X84m8JdJ5ZHhOl+Ic7obFiLf2yXeyQlFcyhwZ04+sHwhgpSdlNpJtVtjj//ncQPq
ghVTyNgpSBYixEwQl1cHTYYp28H9lIRoTa9l1hvfYfRkAMW9Skr5yRpCnAOC+2T5
HLb5hOX9nokcGjA9VyN8hN/nEOKX3FDlFDdIbRJDtmUhngE2yAcaveobSCD80iSN
dL5xacYTANQuT2s4jydqPtHHe6Iu+jJkLxjRV0nFldccosE/A2HJ0HbAfLC3jqBV
g+ZyBRq1mZoXYldmR7Rely77lfQ8UcMTPt7WhUImQ7qaSkt3czCZdMsClb6RFfN4
FEOd58+9xocYPz1SAtt0N+wDnDueoIeKxo4zjr5fisoUnqGjt8eI/y5NjbQXFmEz
dvU74R0WDh9lqbCqLg0m
=4Uls
-END PGP SIGNATURE-
[gentoo-dev] Re: [PATCH 1/2] Introduce multibuild_merge_root() to merge interim installs.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/23/2013 01:44 PM, Alec Warner wrote:
> On Sat, Mar 23, 2013 at 9:26 AM, Michał Górny
> wrote:
>> + # Close the lock file when we are done
>> with it. + # Prevents deadlock if we aren't
>> in a subshell. + eval "exec ${lock_fd}>&-"
>
> Not following this bit.
>
> The bash manpage says N>&DIGIT- redirects fd DIGIT to fd N. N may
> be unspecified and defaults to 1.
>
> It doesn't say what happens if DIGIT is unspecified. Nor does it
> say it closes any file descriptors.
>
The relevant section of bash(1) is reproduced below:
Duplicating File Descriptors
The redirection operator
[n]<&word
is used to duplicate input file descriptors. If word expands to
one or more digits, the file descriptor denoted by n is made to
be a copy of that file descriptor. If the digits in word do not
specify a file descriptor open for input, a redirection error
occurs. If word evaluates to -, file descriptor n is closed.
If n is not specified, the standard input (file descriptor 0) is
used.
The operator
[n]>&word
is used similarly to duplicate output file descriptors. If n is
not specified, the standard output (file descriptor 1) is used.
If the digits in word do not specify a file descriptor open for
output, a redirection error occurs. As a special case, if n is
omitted, and word does not expand to one or more digits, the
standard output and standard error are redirected as described
previously.
While the outcome of n>&- is not specified directly in the man page,
it is treated exactly as n<&- is.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCgAGBQJRTfsWAAoJELHSF2kinlg4MO0P+wTQovWzYdfSgUP8H4WFmO1y
fpERqd1ZIoPle5Gl5+IUOWIHoMqkjS3mIAYUKF9cYwkufHRjbIs9l6NFGZg4wbRj
baCW6dRTbnbaM/YSiHLlstb4I5fcSwldwhtJrMuO9O6qLq2IFupJYkaSLnYJMs6C
HspU9W+bw4Vuvlk2wnhjGDGUj06ZIifQEOE6NYUVqF4GQaZlZpCsgA5BADPQL8zL
RAb90dJuRIuPPwgzuFka1+h0z4Sg5xxSlV7FS4c+r+HzrZCHHIHSyi9lOpOPB/8M
P+ZzJyDD3weW5AnAIuDjhJ3Rt0wI/2oYRRoVmC6hZ1CNSZuSjUCdWi6jvIvg99cR
TscJ0dKBl7bMcrrIILcXYgHtyKC/QRZWp6r0JxqOwX4L7FbPhF3qbtano+TxoCSr
X7hfCuRab1FEPE+jXeprH0c+N31SHrVBxfkJDG39MVx8hdJqXYzKCXah5/6lMJ63
Td2lc7Y3UBuXpxvQBoBCWTEV3vmKBrNX6v5Bu9TTLmrhfkcMsjCMX6TdU54tUoEU
YE37njpI4Thsl24/LPQtzkR8v9fVyYqVvvXylSq5HcM48VlqlhcI/EP0SRo9eUXu
CFRkwb7u5nX4YOdUMj+L0P59/N7Zobdfs/dCvGB4PDeJTqzFJowxVhm7Dh1Uxf6l
a1CBWFm9+S7kUPDTfwV6
=tFvf
-END PGP SIGNATURE-
[gentoo-dev] Re: New eclass: autotools-multilib-minimal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/24/2013 10:53 AM, Michał Górny wrote: > I think that base.eclass is silently intended for removal at some > point in the future. While we're here, we should probably mark it > deprecated. > The problem with deprecating base.eclass and telling people to use autotools-utils.eclass instead is that base.eclass also defines a src_prepare that is used for eclasses that support *non*-autotools build systems, such as cmake-utils.eclass. Requiring that support to be copied around to each of the eclasses that currently inherits base would allow the usual issues with copying code around. - -- Jonathan Callen (abcd) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRKlZ+AAoJELHSF2kinlg4L0UP/24ETiIoXIVS9it65p2s/YER D/KCcgsbTMowWTrs488mQ8Vs/3T0Ij2sDuYRcOqqKEiDb6+aAeILhU3pDP9c8k7V L8jV1RpF2nafO4dexXU9FBMd6KYvz3Vsf4JQfiHzybdBsVW9HE0vrU/lrST91tm8 irDxPfOWFMPGM3r8YD+AuQ6DlkgaMdnJnT+c9Bu5xtoGrjZ5inmSCeskQkX9zP54 wFFuwyg3+Db08r+qTHkUqnAPc1t3fSsz7X4tgQfX5btBjVgDKKYm2dsScjNmhvxg 4Wnv+A5R4QAcce3CWUOp/BXTAg6PuYBbGWZWm+5WzQstsZRRo+hiGh7buyIctdix IRQaoNh7SRMiiV2STHJtjqz8+e28NsK16Na4PSbDM3GOYbiq+gb8dyDpvIQpzN6m 48G2dhETJpAvox6YnA6Ix9YDdoAl0Y25ynJSUajLbyQ9+rSiynIGnMT5UHFr9zaM 2zs9oXRaqO7Gj1A98nN0NwjC0U+sP7J2JidvcXbUO7YNx4exsgzUHdbrdG7gBpVd iPHpECyrgh3uqIRS0j3bCR6WQAOBGb708hXrNj5a/ldGvYTYlLmt2Tbq+mJapZmp uFLYrK1kwBmXj/3CSErO0Bg0lMspk8E0MnEljChdFPGYekkbPGhZKGp9EufczG+G C5L3dv7V1Nv2AyyFiYB3 =cyEa -END PGP SIGNATURE-
[gentoo-dev] Re: RFC: fortran-2.eclass to depend on virtual/fortran
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/07/2012 01:20 PM, justin wrote: > Hi, > > I want to add following change to fortran-2.eclass to achieve more > simpler usage. > > The patch will make the eclass depend on virtual/fortran so that > no manual addition is needed. Two exception are present, a) the > ebuild has the USE flag fortran, then we check for that, or b) the > FORTRAN_OPTIONAL variable is set, which leaves the control to the > ebuild (e.g. for cases like "lapack? ( virtual/fortran )"). > > This is the best coverage of the use cases present, because > > * most ebuild using the eclass want to have a fortran compiler * > most other trigger optional fortran support through USE=fortran * > only minor have different USE for this purpose (e.g. numpy) > > Thanks for comments, > > Justin > You cannot check the value of IUSE in global scope in an eclass, as at least portage actually unsets it before sourcing an eclass (also, it is not defined in PMS what value IUSE would have at that point). You also got a conditional backwards -- if you don't set FORTRAN_OPTIONAL with that patch, then *nothing* gets appended to DEPEND -- if you do set it, then DEPEND="virtual/fortran" will always be set (with your current logic). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCgAGBQJQcb2UAAoJELHSF2kinlg4jQMP/Rt4UJBDCPE6lJyEoHzTp60l GapkNJRpBjiihYZ1n5pAtBpUvbKqgAo4zvvXX2AvLDfUazcpnPh3ZdW8Gc8JtycF cvCrUoUfV+0MY29DEcvL0tV5wX9ha5B5YEurR/zoPQ29V6eJqho21G+GZJ6L4Mdj rIcTRDf4izaDqiunRDRQp51udYEnAQLR8I9FAA4ybh1Dd536xmnm3jdDkGtpvgrW 15vWMdr8ETkmy5eK59K/iP6U4IzPldBXff+rKyIlss/D6CNrXI0WqeYY2PdFUHGk E+C4Sqx633AjevfS04c+6feAcsS3gIpZWVuzA0BZSXeFUFB7Cdph1RwHpLOYM50Q OoGi9/ha2llD3J/iS+76ddlP953ZfRrt3ZfjWzCaTsec73AA/srBuaxtoiOGjC/r 5DecDgL6OrOPJdad29VE1B/xEkccj+C7/YYXtwxsS2MzzL5oi8hpnnrLH/wmqOK9 Y/uf1H02swPu6m+ER8De/5KAgKc7LCaTmgvZVKetZHgZw2TqG0dwAwJ7FickiE/W 49yfc6wf8kQGtaH/BqHb+ja0T18y90jHhrexaGPK7mSU2LCzvQnMHDMAIEuSRzgz iM8JPsqJ6Jwc/dD3MMW7WKWf/aSP1fy+wJXGaK4eI25U5LmPzmNn7E68W1WUjKRc 5pfLsVRThwg2Md1UjlDO =P5yK -END PGP SIGNATURE-
[gentoo-dev] Re: python-distutils-ng.eclass: allow useflag dependencies for python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 09/06/2012 05:27 PM, Brian Harring wrote:
> On Thu, Sep 06, 2012 at 10:44:34PM +0200, hasufell wrote:
>> -dep_str="dev-lang/python:${dep_str: -3}" ;; +
>> dep_str="dev-lang/python:${dep_str: -3}${_PYTHON_USE}" ;;
> should I ask wth the space is for?
>
Without the space, ${dep_str:-3} means "${dep_str} unless empty or
unset, otherwise 3"; with the space, ${dep_str: -3} (can also be
written ${dep_str:(-3)}) means "the last 3 characters of ${dep_str}".
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJQSSzXAAoJELHSF2kinlg4UMUP/1xlAEhmy9JfDp//IPssBZ6g
SsO1eNbPjFtU8bFAWDAcbCMQ4c4bYB7xeAYCwn90qccpYiyOqftWCRiF5CPdou0T
ntUp2dpPkps1NkuuxSEwfk2jr91s38ri8GA3WOlT4AjADhjjjpIQjn7ib9SVYKVj
ZywHrwxjpHlkR7SaALAriwg6hkkrdtNKVtqnWyGKfx570e0rGJk+EK5SbnwtzHaD
ttmKkSFcHrkyPamTrmLa2udjqnnVMi0wuRi8IC5NP5AgF3osj91fqq1waBpViXxL
UVB397OpsHwXxP5uAWJ6O8eFPviCq8HcstRCg+XXnBIdyQYQcVB80aA+r+kfqfjI
d2WGBS5wNwYILGW1L5S5z5tcGibJKkraCvwI2vhNYItzL43X2oBuuiwVKo7u0cd2
P04g3vwBAfcMvGKo/GFWyUGvsLrdl9Fcnmiyv86XvJSo8guhx0NO628x/4uFY+uU
/IsbgXcWCC48HLmLqypE+kBVofkR7nWGNecEvHlgTe/4oLzpyJzOj/5bgTUbioW+
w9Rj/0S3K/GOYYfbBjvsQKH3vSuYqPP2/6KuG5N/r98lCtkaRujfxj7t7NlSqRT0
1XGr9Y+YZlE6YBQ/JjrfsOH9uotohvutY2aIxUlfe1MFjbixI3Q7p/9EWaZ89Cwq
8saYFqjaWfe9lHmwxxbJ
=x+TM
-END PGP SIGNATURE-
[gentoo-dev] Re: rfc: udev-rules.eclass
On 07/12/2012 05:09 PM, Samuli Suominen wrote:
> @@ -33,10 +35,14 @@
> # Get unprefixed udev rules directory.
> _udev_get_rulesdir() {
> local dir
> - if has_version ' - dir=/lib/udev/rules.d
> + if "$($(tc-getPKG_CONFIG) --exists udev)"; then
This should probably be:
if $(tc-getPKG_CONFIG) --exists udev 2>/dev/null; then
> + dir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d"
> else
> - dir=/usr/lib/udev/rules.d
> + if has_version ' + dir=/lib/udev/rules.d
> + else
> + dir=/usr/lib/udev/rules.d
> + fi
> fi
> echo -n $dir
> }
--
Jonathan Callen
[gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/01/2012 05:39 PM, Matt Turner wrote: > On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau > wrote: >> Matt Turner schrieb: >>> I suppose that's just for ease of implementation? Not having >>> to special-case packages that don't install binaries. >> >> I dont follow. Did you think about only having additional ABI >> flags for certain cases? > > Right. It seems to me that not having the ABI flags for packages > like x11-proto/* would make more sense, but may be more work to > implement. > For x11-proto/* you currently do need to build the package for each individual ABI because they install a file in /usr/$(get_libdir)/pkgconfig. This should probably be changed upstream to install to /usr/share/pkgconfig, as there is nothing ABI-specific in there. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJP8O8VAAoJELHSF2kinlg4uToP/1swJ2Dm0W1R5z15L41kCO8F jKtc1Q+3xN/gfDuHzAR1rJpzNLGhOzX0tE+9TKePp4TLcoDKSIeOi9wR+MwncULE aOqIDPQE5n06z06FEuKqkyWUSJZjJ3sObWiH0+hhWssIorks+LEVYZ8EeLNCw0rb 4zmobbckGeMcbZvcvtISw/N7K3QuUoEDM5rj+059ViqShLxzZegEnO8WU/+h1qi7 E6G5PwKK2MhMGHdWT/Gt+yMT6bSQbNpHu78YHElQFuYSagCcBe75JMfjTKup5iu+ 15hM7ZBbiU6yyx45CV6SSXzdqdpkTBkWY7lfrMzXqa3ZtIqgDhmtdxZiNyJ0sHDe dOtYhJC2FGIGkgv3ZarCEqlybOHrgFxYfBSo0dyFzbr9bWebJgb+mg8CWVbNb4j4 3pe3jVOy5r0CNQ6/ZKRN2ZhzMBhjB0sIsoVmnAOFyqKMNCXHTBHNngQ3jMdxkrJD fhBVMkEnRr2Gmzmsgi1DZZMvRI9W/6SJo03zwYrik0VBBqyRubRRvEp7mNJO1kV/ eW+8tfStDyOHXuQherGJfCdZiHdP6puj4ZmySURhFHAyeRTEQ1Gxq+vPDIGed1Jv 23odxq+l4MW9lktPgUIrTeku4zUG//FWva74JPBUld1VyicINSCU7plFkLwF5z0o XEzrHuDZRO+k9Vdi5y1P =RrNC -END PGP SIGNATURE-
[gentoo-dev] Re: enhancement for doicon/newicon in eutils.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/20/2012 07:49 PM, hasufell wrote:
> On 05/21/2012 01:36 AM, Alexis Ballier wrote:
>> On Mon, 21 May 2012 01:24:13 +0200 hasufell
>> wrote:
>>
>>> I want support for installing icons into the appropriate
>>> directories which are under /usr/share/icons/... and not just
>>> pixmaps.
>>>
>>> proposal attached + diff
>>>
>>> This should not break existing ebuilds. Tested a bit and open
>>> for review now.
>>
>> maybe i missed something but cant you just make doicon a newicon
>> wrapper and remove all that code duplication ?
>>
>
> I don't see how. "doicon" supports installing multiple icons with
> one command, as well as directories. That does not work for
> "newicon".
>
>
Normally, new* is a wrapper for do* that does something like:
newfoo() {
# argument checking omitted...
cp -P "${1}" "${T}/${2}"
dofoo "${T}/${2}"
}
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPuYXpAAoJELHSF2kinlg4C7kP/1tNBut+o5s0ScBt/SREjrQr
Oy1Q4iRk1hV5NqY0ve4Cx1LqT3LKFWGCUkUY9pY4YoacG5Pbt4FKebqHqBjNASbg
FIwA2BNGZ5VKW2uwfqpTcc2lp6VRAfA3IxqkO3mlKy/zwk96G3jeoU+2sLSRatRn
ZiXsuCQ6DxrBRp8Jtjc5X9lIvbfBNoDIC7uXtW8fOuFBILYT/oSDPwUdT9r3ppNR
nfEuB3AsjPEyxuSd0R7QNYXexwDwVyp4JlpqFAQGH/+xUR4Nsy4Cw5jVwOr6Ip+3
afDVC4NNkFBUf+8qQ/Rd6Fdch3RVLeGtdIfhHbYgSbmUGFjIOWQ/+kEy6yp8jNlp
2nkA29Y9eEmRYSwwfQR4xzTcWnuPyK9cNKuK2L5LTUN143rHJdQ85lzkhNPIAYJO
jQVPWZh966tQrjkLB9sfW14mkCcvkK5q9F4re5Z44R1RHfdnl+Npe7uts17dQSCg
61sdTQ4Q7r81SyqSgsf2g+QaaLQ+d7+HrZvEJ+N8xhDOwX06CZVjvNWnwewbHBUT
jWHkilE9wKJcliaAwK6wqCMNw0LZnvQJHWUKm+vNKcl1PSg51VeQrjEldPDix5cS
WVCjsFjzo4pLzID19pI1z3Yx7NIJJTbqfKw1Oju+Bv3JGAzz12RCX8XV4t9BCp7r
tPk3xzb4gsxPDqROppVh
=D2sX
-END PGP SIGNATURE-
[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/27/2012 11:26 AM, Zac Medico wrote:
> In order to be practical, I guess we'd have to add a constraint
> which says that if KEYWORDS contains the stable variant of a
> particular keyword, then it should also be considered to implicitly
> contain the unstable variant when the package manager is deciding
> whether or not to apply package.use.{mask,force}.
>
> So, here's a description of the whole algorithm that I'd use:
>
> 1) Let EFFECTIVE_KEYWORDS equal the set of values contained in
> KEYWORDS, plus ** and all the unstable variants of the stable
> values contained in KEYWORDS. For example:
>
> KEYWORDS="~amd64 x86" -> EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86"
>
> 2) Intersect EFFECTIVE_KEYWORDS with effective ACCEPT_KEYWORDS,
> where effective ACCEPT_KEYWORDS includes any relevant values from
> package.accept_keywords. For example, here is a table of
> intersections of EFFECTIVE_KEYWORDS="~amd64 x86 ** ~x86" with
> various effective ACCEPT_KEYWORDS values:
>
> ACCEPT_KEYWORDS | INTERSECTION | package.stable
> - x86
> | x86 | yes x86 ~x86 | x86 ~x86 | no **
> | **| no amd64 ~amd64 | ~amd64| no
>
> 3) Apply package.stable settings if INTERSECTION contains only
> stable keywords. For example, see the package.stable column in the
> table above.
This algorithm better matches what I meant in my earlier posting, so
+1 from me. (And if anyone has an ACCEPT_KEYWORDS value of "~amd64
- -amd64", they deserve any issues that may arise).
The only issue I have with it is that EFFECTIVE_KEYWORDS should be
expanded to contain "*" if any stable keyword is present and "~*" if
any unstable keyword is present (or "*" and "~*" in ACCEPT_KEYWORDS
should be pre-expanded).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJPmvKPAAoJELHSF2kinlg43ZgP/1F++FzGzmUZxy+2enHeCIRb
47y4hFxZG18ulWijr0qEJTizDGCxE8RCBfanM4I1G4qSdy0Eyg+6yIdT+B1FRZ1F
Wp5p/CPPX/AfxgJ+LTTmY5V3f8AWrk1MfX4sGoy+0DGzgMB+Z87M6f10wAWcLIV5
RHd3591kyL5AOifaaM53/tgFcjvXECz+DfbDaVFaD1XjnSkEsu6aV6k1xaVqGGfF
pK3Dqo672XUKR1laFODYEkknO0JlR8EcU8De4pkdgj8ffbf0g2uVXbpTCEgd+w4I
0eEd+LNVDAnTQntMuSETK5ysfYIVOPOmo1KoaR5XSFVsNL8UzjUKY1Yx7owXrm+N
2OR+2JtdCnjkTveZZbP/Y8M74wiZeptOsgK5PxN+C/3vLWJ0LMrxIsWMugc0Oihv
3ddk1/WQolBtA8+DDBY+mOrJuKa5R7eqLAJQVmFLyDVLGu2dTCO26TaT7IKWnN8J
Kw0RqscOFd93RcsfpgKwM2ij+8N+QlGgvK4qBwR9MAIEEQAPtx5Rxi6dxly/b/7h
6jC2Yt8UqVOCloQ4vjoopIqA7QYGk3JS+yp27HAVR+cXDX1OWntEU+LeVlmm27k9
vuEBRXosD9DpYCQ7OCQOzYa5TefgVs76TY/ygSgpkHlzcCbZ5iRwholKuOuKSvyd
mRi9g8/nctJXFkHn17GV
=LYAv
-END PGP SIGNATURE-
[gentoo-dev] Re: Feature request: package.use.stable.mask and package.use.stable.force
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/26/2012 06:03 PM, Andreas K. Huettel wrote: > I'd like to suggest we introduce the following very useful > feature, as soon as possible (which likely means in the next > EAPI?): > > * two new files in profile directories supported, > package.use.stable.mask and package.use.stable.force * syntax is > identical to package.use.mask and package.use.force * meaning is > identical to package.use.mask and package.use.force, except that > the resulting rules are ONLY applied iff a stable keyword is in > use As "a stable keyword is in use" is either ambiguous or outright wrong (depending on exactly what was meant by that), I would propose that one of the following cases replace that: * At least one keyword beginning with "~" or the value "**" is in the global ACCEPT_KEYWORDS. * At least one keyword beginning with "~" or the value "**" is in the ACCEPT_KEYWORDS used for the package in question. This is required because on a typical ~amd64 system, the effective value of ACCEPT_KEYWORDS is "amd64 ~amd64" -- which would be covered under "a stable keyword is in use" (the same applies for other arches as well). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPmiPhAAoJELHSF2kinlg4BRkP/2vxN8Wq9+tTdk54XifMm4T8 Q3p01uowvTYhTx2mIh2qLPMemtJ1ABCe7ZxpTkconE1Qw9VtgKsjuRX63glnsKDh wU6hzMH8RUFIA9BNDb4ZHstp35Okthtju67jPRiN2hp1DuYjTQ4kTKm9IIp14/8T hb9u7l2VEoyIuhYSAm1b1VjkIS5OO16tCkwiWF0HqaWCfw0z65/HncARf+D35cfZ giHV9qwTvHoXCh2PBq7XyJaCs3XYcNfmAV7o8tBpXxAvzqWRbh2hMLgSpmIxFjXM 3MvqdjVmNJowovAiLatHMby4ogO9Gq1A4svoYXsOuTC9lC4XQDp6md9zCcAPBD8w qBEnixWb2p4xfqpzk0zP6JxmvQkKmPPzWVoBuV8lYni8jN/GFRntnT35GEwiA/si 04/wg3+w/cG4q5vglExrFpT3cNG8nkMPmqQIN8XrtdhGnOCyLYrAd4lvymEVf4/8 ymD36BZwQ6xW3yjbWEl/CmvpdbRjrFBp5pzebFGzZxnWrrnGQtVBYYA4o7GoPvhu hsNtCM/C8afynflTvaiX+9/bzbwrKSN5+4VmTT+9m+sQBwbnFy6iby1X5HlmE/Ie L6k2iTxT0hrNxwZaf6eYR2zxjzV6FiDkO6eBEgYFNcOd+JgZ5/+dKJ/1CHy753d/ 2zXMNmzVLT6fXLHrAH6m =pmWk -END PGP SIGNATURE-
[gentoo-dev] Re: rfc: news item for app-backup/bacula
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/30/2011 06:09 AM, Thomas Beierlein wrote: > On Fri, 30 Dec 2011 11:44:23 +0100 Michał Górny > wrote: > >> On Fri, 30 Dec 2011 10:43:31 +0100 Thomas Beierlein >> wrote: >> >>> 4. Run the appropriate upgrade script from >>> /usr/libexec/bacula/updatedb/. 7. Start the new Bacula. >> >> You still miss steps 5 and 6 ;P. >> > > Oh, oh. Now I read your last line from former mail right. > Corrected, thanks again. > > Thomas > > Title: Bacula-5.2.3 Upgrade Author: Thomas Beierlein > Content-Type: text/plain Posted: 2011-12-30 > Revision: 3 This should remain as Revision: 1 until actually committed to svn. > News-Item-Format: 1.0 Display-If-Installed: > " > The 5.2.x release series of Bacula use a new database catalog > format. If you're upgrading from a 3.x.x or 5.0.x release, you must > upgrade your bacula catalog database. > > Please read the manual chapter for how to upgrade your database > (see > http://www.bacula.org/5.2.x-manuals/en/main/main/Installing_Bacula.html). > > You can find database upgrade scripts in /usr/libexec/bacula/(updatedb/). > > It is strongly recommended that you save a copy of your existing > database before upgrading. For details how to do it please look > into your database documentation. > > The simplest way to upgrade the database: > > 1. Stop Bacula from running (at least the director and storage > daemons). 2. Save a copy of your existing database. 3. Emerge the > new version of Bacula. 4. Run the appropriate upgrade script from > /usr/libexec/bacula/updatedb/. 5. Start the new Bacula. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJO/e6RAAoJELHSF2kinlg4b/IP/jrMPdNAz0eqQDi4jPtQoef5 prG0NwfpnSfKq0vTCf+CS+tSezGgrn2GsnfAp+GFngEPAed8zZlylGsViusQjR5w uOPkLlaYwGiKzlUjoronqm83GLbGRw2IZJuxr96t6wsk2PWMSIs4SLLDRRoA8Lis /yZ6YtuWpkaxqdtR7GIwpW2uTK7b0L7LSR1UyIe7YO5bTQ3wlLVneysxfcNadNAh JrT1Hi1oGR/SRtWP/J43M26mpTSibqaJjE9vU+4/UVUApquKUB/Cw8x6lPgh/hZz 1JemFwHWeozIr6zUu0OOoqI3oN4nkO7cFyqVcZYezx5WEuaEK+NFLiNIrqFQFyyQ uPYgKCXFmW32rhWXKVeIYNjTiX9RYrFsEUnyTOKltD5s2sGMYd0xiplYAPZDml3n ZUTU/swMp469N5qaYq1XNrpM0GE1QztG0/Le6lvngkSIo59j330d4VsvYT410jdl +AmFaVuTFVfvRl3A7f1B9iZ2v9HKQvguFcraC2Vp6o4QQ/TbHJqbzn9PpXjCXhjL 5msQM/UvlaxWlK87BqXFzwUMb9lC5kRu6qqPfmevDtrkT5jaCPNAubcdz8Gnlo89 w8grtnCNVWNbfMBVxIzOsSR1ESKAQqkm6jkgkPJnPrcrvtIi6QQhek6r59r3FIon uSmV/1RoedqyGGsdxVyD =urxy -END PGP SIGNATURE-
[gentoo-dev] Re: [RFC] office-ext.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Tomáš Chvátal wrote: > die "Unable not determine libreoffice/openoffice implementation!" "Unable to determine ..." - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJOXW2uAAoJELHSF2kinlg4WgkQAI+qmxqmKVcz0Ay3Ldj7XZgv pzsaWElCK+UBSTvdky9bXdyZmR1aGJ9EBnQ7QW2QWK7MpZRpZmyOoaxusgu0Jt72 +otMI/Jo6L9v15vEM8WpOGfTXjN3YW0FEKNIvtRSVQamvtB3Va6xKdbRJDC69Qiz 1x1KAVKoIV7owzCuo+yEjkyp8UXhkyrZfTVrOhKnvAmjK1n+8jw5g7fzRzVTaSfg RSGG3bFWAlkfBrzaLToFN9DRWVXUhlDC00mjbhnsMmr1y6oKmagKdxsWsa7NpJn5 2mElUeW5vm8wYJJGikQZC2n69KMz6DApt9bu2nqni7G64K1N9S3VnhfkIhkf1JaV GjdtlQxw9imJNzFfZhNIJkUmDJ8xmiqroVWi3bkTar6ySQC6wMjgutMYSc3KF7RF ep89WflYgH8woAmvsYKdfZF9B9v1v2cFHp4Ra2fdryE9tYYlLy0KHG+kUmAoRcDv CQ9vuxc63aD6ezc5qK8b2pvEH/C2OpYmQSby1im3/CIyoFfPTNf/S5iKq2W+jS8g cP8/XFRynoYzdSbFIddU3fqc1uCfpv/AawNzRDhKegIU/j8Kt8FDDzNHnouriS7b iPoZgMCz4OhQflWBTUxShLbYGAPUoX+v811AeWy+y6ViYMukdbmOsA8HMkfx6gmN 3j59tZmDp0b7pEKf63XV =9bkW -END PGP SIGNATURE-
[gentoo-dev] Re: POSIX capability in Gentoo
Ciaran McCreesh wrote: > On Tue, 2 Aug 2011 17:11:28 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> Ciaran McCreesh posted on Tue, 02 Aug 2011 16:05:54 +0100 as >> excerpted: >> > Because going behind the package mangler's back results in horribly >> > screwed up systems (as anyone who's ever used lafilefixer will tell >> > you...). >> >> Well, not "anyone". I never had any problems with it. > > You did, you just didn't notice it. You'll find out sooner or later > when you get bitten by one of the will-never-be-uninstalled-now .la > files that it modified on your system without updating VDB. > >> (Observation: Unqualified any/all statements are rather like >> greedy .* regex handling, sometimes they include more than one might >> intend!) > > Well, if you prefer, "anyone who's ever used lafilefixer and then either > looked carefully at what happened or got hit by random nastiness later > on". > That statement needs one more qualification: "and doesn't use portage". Portage will (by default) remove files on uninstall even if they *do not* match the checksum recorded in the vdb. This implies that most people will *not* see any issues due to something other than the package manager modifying the files behind the package manager's back. -- Jonathan Callen
[gentoo-dev] Re: Problem signing manifests for ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Bjarke Istrup Pedersen wrote: > I've tried that, it still does not work. > Even if I just login as myself and do something like this: > > gurligebis@raven ~ $ echo "blah" > test > gurligebis@raven ~ $ gpg -n --sign test > > > > I cannot figure out why gpg insists that I have cancelled anything, > when it by itself fails silently. > Any ideas? :) > Are you doing this from within an X11 session? If so, is DISPLAY set properly? If not, does the output of `eselect pinentry show` indicate that a non-X11 pinentry client is selected? - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJOGufnAAoJELHSF2kinlg4KCUP/Rz5Y4QuM1G6aBDgoy6HG/Y2 FFf7E4XT+BRp74KanLAsYSlMaHqyVULHCwosuDdlCEa2NvqYUUhVUUtPB4kN3B1a HpFVqZcOAF7Vt8+c2+P217h+6Bp7k+u8Ju8/JK7LOpY9E3oO5Rtld5KEoT1hy/fv oVLckbxPQbyHnMet0OTT1vL0JfbQ2Mua/zE9h6Gn7ZTEyD58oWr0vxeaUS/JdNrf Rd5N3M2hl6O1gIbeD8C/rQTCEAsdKB3UwZ9H7HU7XlL75/A8oancbhINGI8wmEvJ 49D3KoY2kZVIqhqtg53EmduGdGAP8cjnJ2BxefoKJVc6LBQ0f9UhylUyY6kTZXRk oLXVv3+jmIXXsv63AtKzAT+6xjMvo2x5s48IzjI45+516y7sCdeVWI5asXiA2zh1 gpK8x2EmTZO0BEwgzhHq7W1UfbXMoVLLXmy6jRyJMjgnwuuqivY8y1pOKeFbmTh+ N2vjBsJBoxg29QEm59NmfB54Szin0XtJSasgyb9Vgnyxa+utY7l0z18hTIWcStnW 2E3sK7/xeZuLdv08Ub9yyPkeLuRh0LwuHtaka8ilT6mD8XoKjEqZcfsXZmCbwYue W/BXVSOfESfWXijKHzglJCTnxO8DiU/5w2ybxisKAJU6HlBdVgLN6YJxcSWVmTZR DQbDZEuF4liEuxdCeFnJ =08xS -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/aria2: aria2-1.12.0.ebuild ChangeLog
Peter Volkov wrote:
>>
>> rm -rf "${D}/usr/share/doc/aria2"
>
> || die
`rm -f` never fails -- if the target does not exist, then rm simply returns
true. (The only reason it would fail that I can think of is /bin/rm not
existing, in which case you have a bigger problem.)
To test, try `rm -f /nonexistant/file; echo $?`
--
Jonathan Callen
[gentoo-dev] Re: Removal of kdeprefix news item
Here's the updated news item, which I will be committing very shortly. Please note that there is absolutely no version of portage that was not in package.mask that would have problems with an EAPI-2 atom in a news item because EAPI-2 support was added to portage at the same time as news item support (they both appeared in portage 2.1.6). -- Jonathan CallenTitle: Removal of kdeprefix support Author: Jonathan Callen Content-Type: text/plain Posted: 2011-05-22 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs[kdeprefix] On 2011-06-06, kdeprefix support will be removed from all KDE ebuilds in portage. After this is done, only one version of KDE SC will be able to be installed at a time on a system. If you are currently using USE=kdeprefix to install multiple versions of KDE SC simultaneously, you will need to migrate to a non-kdeprefix installation. To migrate, you will need to set USE=-kdeprefix (or remove the manual unmasking of that flag in /etc/portage/profile) and rebuild all of the installed packages in kde-base/. To reinstall these packages, you can run: emerge --update --deep --newuse @world
[gentoo-dev] Re: Removal of kdeprefix news item
Ulrich Mueller wrote: >>>>>> On Wed, 18 May 2011, Jonathan Callen wrote: > >> Display-If-Installed: kde-base/kdelibs[kdeprefix] > > I don't think that USE dependencies (or any other EAPI specific > features) are allowed here. The GLEP does not make any meantion as to whether it is legal to use USE dependencies here. I have, however, tested with portage and portage itself Does The Right Thing when faced with a USE dep in Display-If-Installed. >> run: emerge --oneshot $(qlist -IC kde-base/) > > Is it guaranteed that your users have portage-utils installed? > Otherwise the qlist command may not be available. > I had thought that we depended on this, but I was mistaken (the dependency was pulled in via pambase). I guess we could just use `emerge --update --deep --newuse @world` (and yes, @world is available in stable portage). -- Jonathan Callen
[gentoo-dev] Removal of kdeprefix news item
After a few years of masking, we will finally remove support for USE=kdeprefix from all KDE ebuilds/eclasses on or about 2011-06-06, moving everyone to the recommended FHS layout. The attached news item meant to serve as an early warning to affected users. I plan to commit this news item on 2011-05-22 to give about 2 weeks warning to users. Please comment and review. -- Jonathan CallenTitle: Removal of kdeprefix support Author: Jonathan Callen Content-Type: text/plain Posted: 2011-05-22 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: kde-base/kdelibs[kdeprefix] On 2011-06-06, kdeprefix support will be removed from all KDE ebuilds in portage. After this is done, only one version of KDE SC will be able to be installed at a time on a system. If you are currently using USE=kdeprefix to install multiple versions of KDE SC simultaneously, you will need to migrate to a non-kdeprefix installation. To migrate, you will need to set USE=-kdeprefix (or remove the manual unmasking of that flag in /etc/portage/profile) and rebuild all of the installed packages in kde-base/. To reinstall these packages, you can run: emerge --oneshot $(qlist -IC kde-base/) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: rfc: use of the /run directory
Samuli Suominen wrote: > On 05/18/2011 05:45 PM, Henry Gebhardt wrote: >> >> I thought I'd mention, the way systemd handles this is with an extra >> service and configuration files in /etc/tmpfiles.d [1]. I am sure >> OpenRC could use the same tool[2] for that. >> >> [1] http://0pointer.de/public/systemd-man/tmpfiles.d.html >> [2] http://0pointer.de/public/systemd-man/systemd-tmpfiles.html > > Not all packages using /var/run own a init script, nor need one. Take > sys-fs/udisks[1] for example. Then, we need something to create > these dirs in OpenRC (or fix the package, but that might take some > time...) > > [1] http://bugs.gentoo.org/333893 I belive the idea was to have a single service in openrc that would create all the needed files by reading the configuration in /etc/tmpfiles.d/. Then the various packages could just drop a single file in tmpfiles.d, and everything would be created automagically. -- Jonathan Callen
[gentoo-dev] Re: PYTHON_DEPEND in EAPI >=4, PYTHON_BDEPEND
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/28/2010 08:48 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-11-29 01:24:50 Alex Alexander napisał(a):
>> On 28 Nov 2010, at 22:20, Michał Górny wrote:
>>
>>> On Sun, 28 Nov 2010 20:32:16 +0100
>>> Arfrever Frehtes Taifersar Arahesis wrote:
>>>
>>>> PYTHON_DEPEND will be required. Otherwise each "${range_of_versions}"
>>>> should be included between "<<" and ">>" markers.
>>>
>>> Do we really need to introduce those ugly markers? AFAICS in all places
>>> they're used you could simply either use version numbers themselves or
>>> '*' (instead of '<<>>', and '*[...]' instead of '<<[...]>>').
>>>
>>
>> I agree, reading these markers hurts my eyes :p
>
> Some markers are necessary. Read the following examples in an ebuild NOT
> supporting installation
> for multiple Python ABIs:
>
> # Dependency on Python 2 or 3
> PYTHON_DEPEND="<<2 3>>"
>
> # Dependency on Python 2 and 3
> PYTHON_DEPEND="<<2>> <<3>>"
>
Just throwing this out as an option, instead of using "<< >>", maybe "{
}", which might be more readable (and isn't currently allowed at all in
*DEPEND.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJM8wfGAAoJELHSF2kinlg4+GcQAKd+AdhhXXiQmYpw0DGY+tz3
xiAxoFgNKob5lTNHT20Y82PoeDHrYeN8Wia8nHcKY/P3wJ7OjRW6RrA+OgS5sasu
fjA6sRhLqR6reUyQPJc/Varwd0Hr2sNUcNN25/6z12y9orsI0y7rtcqo7Nn23Sek
6YR5p4FCIN+94uXgdYUnt5ZhNwCaYl/5BZIvtMgGzA1fGTJlwlv8kQXKteD2ocQH
+AiRpGHOUusi4XA/9FVUiMHrX3N2pac87TR3FcUAtUEeOllYZqjUcQwu4cZjmRkb
nkqgXWU8/A10IpkHvwl0EctlHB5QWcLaV+Ffadd+itjIZ87d7+1mFZlOMr3wuypo
CMb/ogo8Zr7BqaeOyzxbQFR4LP3FbZjw/5hnMxQ7XqGyPsVduVeBWMl22SeBzUGK
fwNmxhIHNI4q3wCsI7e2AtS+bJL6CPhL1DzbMEEK6HQhxIVBrnnTBTJaX1lvs1l+
RK/0ygI7EBWGhebIfs28EMsxxZISH7ik2SVBGLTRpHEutrv+ikn96yMqMJC95Yef
R1rStPIkbwhGoVWw1QiYtjA3r7FRG0Zz09DeaPHXl66/qotNHfdQHuo6MsSPy1Yx
GdyFRiCSaD+AxnmJ8FJ5wg8TW47tPoX2M4xczQx08t34MHx9zlQ8fWIwgqKZrS0w
dp9HSzCYUXe7xlZ7Ja5g
=g1Y2
-END PGP SIGNATURE-
[gentoo-dev] Re: eclass/tests/tests-common.sh: debug-print family of functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/10/2010 03:36 AM, Michał Górny wrote: > On Sat, 9 Oct 2010 17:33:41 -0400 > Mike Frysinger wrote: >> this whole func is overkill. just use a single printf: > > I agree but I assumed Portage behavior has some reason for it. Maybe > it's some kind of pseudo-multiline output? > > debug-print 'line1' \ > 'line2' > > where each line would be prefixed with 'debug:'. > That printf expression does the exact same thing, printing each argument on a separate line, prefixed with 'debug: '. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMseHIAAoJELHSF2kinlg4ZjYQAIw1htkb1JuMK6jQru3JngHX S/k0zrCqpDgj0OOuJYta6E6yjJEi7iPkLK2oswp6Ip/T+baNFFw2G25CPyJJ9QQZ bcUn/ROiXKypuu5elz6QvkZvJauIMxiWQMfSfnL9Il9VNcGK19ZYVgm0IsMK4dEZ xAiaL9NdS+FDaUpQe7zT9qCyD3QfKkE08NIsCgQdqSctd2SWmLQZQs4C9DMfBb3x 24kBW1+NtHMb48alJ1JfKixzBefeUJZnQJwXMNZMHw05uP8y8aHE5Pd4Y9A+1fuo xEasllgYOdpcG32YK99UlDekvWl0GgwZ2E9kP1gv8Hjsu7LDyDPvQfW2zTs4CRKf a4I+FYdkw3fUMFWDiOuUUTM6a+i60jjDgaQm78lE5kfUudgyw7oeVhj2OAk14+GF pUn1zMLjnwuxlY1QIgrcJ+heU3GOlhJtnSI/4ozVImQvID3gLTjxgZZtSoarp+wu EUXLLuA3Ny0ksdhu2CQrBLpw3pgIOdUu6Re6iImWVvAZYk1C1RvmZXRfSshC3vkx RuWVEG194EY7WyZEOsh//7za8Kn5RfNFhEzU+hLIOny+9aGuaCDMABHDUFs//+J9 +iSNCdxdMFUenlUIrAscWTojnbap1sM24u5Q5XsO5OB5cXLSQMT9GOMpVfejBPfq 5gXeK46wvZ3J+ut2ke6s =Ju7m -END PGP SIGNATURE-
[gentoo-dev] Re: use_echo() as a universal '?:' operator-like function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/11/2010 02:03 PM, Jonathan Callen wrote:
> On 09/08/2010 03:03 PM, MichaB Górny wrote:
>> If called with a single arg, it would assume val1=use1.
>
> Just as a proof-of-concept, here's one implementation of such a
> function, allowing for an arbitrary number of arguments:
>
Actually, I forgot to include the single-argument version (which really
is the same as usev(), so it's not as useful as you might think):
> use_echo() {
if [[ $# -eq 1 ]]; then
usev "$1"
return
fi
> while [[ $# -gt 1 ]]; do
> if use "$1"; then
> echo "$2"
> return
> fi
> shift 2
> done
> [[ $# -eq 1 ]] && echo "$1"
> }
Consider this a vote in favor of `use_echo use1 val1 use2 val2 other`
instead of `use_echo use1,val1 use2,val2 other` (I think this is more
readable, myself).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJMjD12AAoJELHSF2kinlg40EQP/Rd9ks2JU9HjtDc7Vgt3fZWg
yN08UyhBhYxy4zS7Lijo+J33GyMBB/Qn5iEj5jkpgbol8BmETnC8aKTqc6LDOrnb
tahVVsuZNIoX+l8dF53op+qYXwGKDFNqobU02+Yj9lpju7MtpwWhQhHDjg7FtgTz
RCc2F712Lw4ncMCT54wlUnJFPX9Xy0WuCMaxUzVG6K9tB5+hyWR1l3oP0kfYkmY+
1kDD6uYt/MTH7c3koe9rIM0O1KGdOUJ+tszgmIKUhtlMNOHHIejTCPcZSdQassR7
Ff2Lh+WKe0OqNcAEKaFFlXjMBNz/g/uGZbqGWh39kX21oH+G+QOoYaStYuO9nnHV
NgpKRNL4eEr/UCvTt7DV52oJm9b6tK/6Z/J10ihhqf3vNBWeN5OMwguLW0iTu0/v
/ja16VpdkdFQ6d/kbeQCPWvx4WW+gWuo/QcbhL9drC2VsBV+gJcrQhzECSdxAHeG
CmJGrkAH8r6rBuNhzvkGMnNVsf+vwcB+1qGMiXltmboSkv56AcWhTOmeZ9tzfCv4
FUDIX4bm7v51xqBfqb/SNLrOgz+Deo3GOtOk2HWHbGfYHsohBPHva4WLAOHwIFcO
J4Fb5tNWf74DVKKJGmU5RctWGh5sDgM2mEZmDkTHEzv2R1/0Hp++jhZ5htYXpCRk
Ni95j32etVEKNK1a6FvH
=2cVl
-END PGP SIGNATURE-
[gentoo-dev] Re: use_echo() as a universal '?:' operator-like function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/08/2010 03:03 PM, Michał Górny wrote:
> Hello,
>
> We already have a variety of use_*() functions with their specific
> uses. But what I miss is a single, simple and universal use_echo()
> function, behaving similarly to ?: operator in C. In other words, a
> simple function replacing monsters like:
> $(use foo && echo bar || echo baz)
>
> Such a function could be implemented inside eutils eclass. The synopsis
> could be:
> use_echo use1 [val1 [use2 val2 [...]] [otherwise]]
>
> The idea is to echo 'valN' if 'useN' flag applies, or 'otherwise' if
> none of them do. If called with a single arg, it would assume
> val1=use1. If called with an even number of args (i.e. no 'otherwise'),
> it would not output anything if none of the flags match.
>
> For example, the code recalled above could be then rewritten as:
> $(use_echo foo bar baz)
>
> The multi-argument version could be used with one-of cases like:
> GUI=$(use_echo gtk GTK2 qt4 QT4 NONE)
> (for games-emulation/mupen64plus).
>
> The resulting function would certainly find use in packages using plain
> make. For an example, in net-misc/autoupnp (sunrise overlay) I use:
> WANT_LIBNOTIFY=$(use libnotify && echo true || echo false)
> That would be much shorter as:
> WANT_LIBNOTIFY=$(use_echo libnotify true false)
>
> The function could be used to reimplement some of use_*() functions
> within other eclasses too.
>
Just as a proof-of-concept, here's one implementation of such a
function, allowing for an arbitrary number of arguments:
use_echo() {
while [[ $# -gt 1 ]]; do
if use "$1"; then
echo "$2"
return
fi
shift 2
done
[[ $# -eq 1 ]] && echo "$1"
}
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJMi8RcAAoJELHSF2kinlg4z6gP/12fOfcJYJK1CUhe/DClXj99
sujt9ekdiiPKepa3g1JC2X4T/IObdLnKgtpGhsFpj4nuJkYYA4WBJUEjdeZO3evx
8tIlTXagN1AAlQcVSWtVbxb6iMDDX6Lc0HWpOk2vlXHqZDW3trBV8K0kqmnxoQxl
IRy9DjTXDXFo2eKGxrH/vE93lksHTbW8bBIva+LuXaoPnOEUCEG6QAO9537Gd5Gi
8xWd0fsj3wDq0bQ/nx/p3Ak1FjdZOhR+KdCsL4fZVrP7U6+lrEru8EgztQ6x6/2g
U4stSwtuARSH7X8wY9cdxLfbFJJ3PL1a/8uF7NSPCzKv2cNWbXxnMIHw4yD3WEjC
wKEg6U4SYwMmhu3b+PdI6iA+sVnxbN+qGfGG7g8TjHBiebYv8AttU+6STyKC5TWK
I8FK5pC6u90zRJsiFfHiA6LSfy6CxQ3AOD9xoO+dcTOVmW8k5lgik0w5D7LQs5+a
5YbkXEjlC8V7WnqXQpUr/eynI3iTcTCHfMrr2OebJs4qUy+qMwcsH5OLcI75F8hH
FWGjd65EqAmEEiVusfsdfYCv+TX272cSI7aAKq1N2nM0iPD82IuKACLBcuKfECI0
DqPD7PHCkUROrXXc1HsZAcyuJqguoZzT8heYfHnElmH1zRya/QZ6qyylg0lPUiaM
j6L8P2Wq1BOoJj6R7a64
=ANyl
-END PGP SIGNATURE-
[gentoo-dev] Re: Locale check in python_pkg_setup()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/2010 05:39 PM, James Cloos wrote: >>>>>> "PH" == Paweł Hajdan, writes: > > PH> Another thing we can consider is making UTF8 the default setup in > PH> Gentoo. I think most people (including me) don't care whether it's > PH> C or UTF8 as long as it works. > > Forcing utf-8 will only be reasonable when there is a C.UTF-8 and/or > a POSIX.UTF-8 locale. > > That should be done upstream in glibc, but were they to refuse then > Gentoo should add it to the glibc ebuild. > > The language_country locales are just wrong for root. They are often > broken (locales like en_US force case-insensitive colation, meaning that > a command such as 'rm [a-z]*' will unlink(2) 'Makefile' and similar files > which one would not expect to match) and cause bugs. > > In fact, glibc's insistance that C and POSIX are ascii rather than raw > unspecified eight bit is itself a bug. > > Utf8 is nice, but forcing the lang_country locales on root is not. > > -JimC You can create a POSIX.UTF-8 locale right now, using the same /etc/locale.gen mechanism that is used for generating other locales (localedef will output a few warnings, but the generated locale works just fine from what I can see). If you want a C.UTF-8 locale, then you just need to symlink /usr/share/i18n/locales/C to POSIX (or call localedef directly as "localedef --add-to-archive -i POSIX -f UTF-8 C.UTF-8"). If there are any issues with those locales besides the warnings that localedef outputs, I haven't seen them yet. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMVLH7AAoJELHSF2kinlg4+VYQAIB/Qc3Oq6lmK6tgiXADjk1Y ICMCTbxyuCRNkfllwVqqIKEMUE/UmkqIjkY2/1m2uHp3kIm8tErSa1AohdSoJncc 7LIH17daM7T9XylA7DoqX7et3E3mtl8SerGHFMQ7ae0qYMUkbnNeyeUq4mVhH35G IazjLFCIn0KlLmsim+8ILh8OQ4NWGK1JQlqXDluxHb3BVK37XDLWmvz5gG1+CTmS KrmL3ek+BujiHOfAuvc86jFi9rWMP/yPh8OMIOsG41e/4hdNnhhhwiF0MHRs6bpO Ql3FLsQjS5J7o6MC5690r/Ov/qHj/PAVITXft5cEQhq/gK17sg5TM5zs1JZxNMpH T5z8LuSJenB6hF/+Gk0aew0XKig52539KZRnYShyl9z0QlLUlmwj0L3t8cFnm1in 2ttaeVttc4P2gwaF5Uf4ljEPFJ5w3lVIsXtRJklcPOjDUlCwnpYU0y5GS7RtAXJG l/4Ax2/yW8P070dg7AoYh1WVTY1ChsyRNTECFYfge8ra5OnXT9HJPVBm7FFTof+L IYXJ8zOGnDm32xsiov0LsrYC5KiD+FixkqTiPUHnbZm9KmI/HCyvnODm3cD+k8ts Ht4JXxdVPEjv37bpDgdSbrI2vFb3sfpdH/wY1LMoAU00p9f/xwM2d9R1i+Q08CBV 74aYdVDpAQi5Kqevehw8 =7bB7 -END PGP SIGNATURE-
[gentoo-dev] Re: Locale check in python_pkg_setup()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/29/2010 07:16 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> + locale="$(python -c 'import os; print(os.environ.get("LC_ALL",
> os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"')"
> + if [[ "${locale}" != *.UTF-8 ]]; then
Shouldn't you be checking the output of `locale charmap` instead of the
actual contents of the LC_ALL/LC_CTYPE/LANG variables? You currently
are reporting an error if someone is using the "en_US.utf8" locale
(which *is* a legal UTF-8 locale, and should not be an error).
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJMUhkgAAoJELHSF2kinlg4dwYQAKkGNSIQJR+2If0c97MSTWZz
hj5UAUrj+hYsxdg4rjOt/J6rGdh/iG+v1OwzaGZy0GZpb3O/KKajrfbYDaarGXMp
RwHviKOh+jVZqnaCKF63Iz4F80BaEJpvuQBfU0zrwRVlvl5nVS9HaOuwXslFKFJr
ge4ygrsRkKWqenaVZbjvWnYWeFWxMHF3iGH77uWrAci04cDArJjNX6puCKiwCMEt
F/+aXro7DqkyZws084L1xjovfWs9HcbdkGPMsQ5TR48MqRIDRDuxKiNoRhRQoDjM
qSUKR8FpZtTcrXyIsPrZw85f2XAAsXXdW6aMwVcpj9rS7JxNeM8/383Z5A+i/za2
iyynZcBhZj1jYOWtghCvfOeKHdO+s6iBPRg/yN7WAashiS6cCa+hBwXeHT1YDw1V
iXSKfSKQnPcT1sqXqtZ7IkLKvXxG0PTNIrpIJya7SXCKTlZP97E6uVZcJeYYOT3Y
sN0FqCxJ7F7SIRndfC4Q9fxU6wxcNICoB6VF1jkpyYccO7XyjFqL9zNfd9+2Pe6u
hqAVZpae7GbE5NJJnkWvb7fQj0PVdhlk54dUdr9p5cinKnfV2hPW+23lSInpkgdw
Oa1ZMUy1G9+lEUsCN2ve/l3gfuUAWXeZx/Nuo6ieuJ/HJLFkAn9Cbbpy9C+VlkxN
K2S4CEu16mDy9zgrrbq+
=w5tr
-END PGP SIGNATURE-
[gentoo-dev] Re: News item announcing as-needed (glep 42 stuff)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/28/2010 01:26 AM, Ryan Hill wrote: > On Tue, 27 Jul 2010 22:36:17 -0500 > Jeremy Olexa wrote: > >> On 07/27/2010 11:51 AM, Jeroen Roovers wrote: >>> Since the QA trigger in portage is based on --hash-style=gnu, >>> you'd have to make that the default as well to find a package >>> ignoring LDFLAGS... >> >> Put that in the dev profile(s) then. :) > > We default to --hash-style=both everywhere which already covers it. No it does not, for two reasons: one, the portage QA check is run only if LDFLAGS actually contains the string "--hash-style=gnu" and two, the portage QA check actually checks to see if the section (.hash) that would be output by --hash-style=sysv or --hash-style=both is present. If it is present, then the check fails, as --hash-style=gnu does not output a .hash section. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMT9YLAAoJELHSF2kinlg4s0UP/j8D1DRdZVo3utQv4IslapBM LiFTVZzEYXhwVri50c5JEzfxUaQpgPVFcCCM373H7vi47Dat3bfu/AycPcL3IRty JsSAc5sTO2Y/u3SDoQ09gTgbnrd5T5OsKd2hR+Q9nnUG3pkdUBThnd32KXTGeoJ1 RAvHnoJ71tFwy7NrGFIXCiHtC6tFyZ4fszf7QrpY/cBsoGCWn608f2jNyfV9sSRw sLCpHPhF/wjILVgHG8uIWZNdBpxlx3pjheSbMJQX+jgNT2S4jiUidbVkw7VaoGTJ VuxxJfNE6H8ZRrr0GsirRfoGZWAiTLebONlsQ5kbOaf1ZhiP5Ojs4Qz2y0etn5vO 5lQLMhZU9nGQa8AaAdesVvqFMrCQalEavgZC8B6cRoVIlMhOhVLNhdlK3L7Q8EKE plE3D918wAcKy+lSQd4rXu43PJiwmuoz1BYuipaBbkIKGczkLha0gx1USYf0zlT9 tlUxd+sUDIfbhkRFXs/OL5onIf0fAJipR8E9HgdbPafuakoPjB/IBr/xSVcX2fRe zzoPVIqW2yXSK+w2UvJLTrvba68+pVgDHlvWlKUqs/C7v512WOUz1gpwxsVny+Ay PrcqFSPwGkLO+f2TAD9afNd/z1b0I4ubswU8n0z5Mu1vQXv3Em+lxNtfGqwvD8f/ QO4BsRekzin4Qzh7jUBV =k1L/ -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: xfconf.eclass
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 07/26/2010 03:03 PM, Samuli Suominen wrote:
> On 07/26/2010 09:57 PM, Samuli Suominen (ssuominen) wrote:
>
> Small change to xfconf.eclass, let me know if you see something wrong
> with it.
>
> - None of xfconf.eclass consumers install static archives (.a) because
> xfce libs are simply not useful static.
> - We don't have any plugins/libraries using libltdl.
>
> Therefore .la files have been annoying side product.
> So at the risk of breaking one or two users due to disappearing
> 'libxfce4util.la', this seems to be the cleanest way to be done with it.
> The fix is obvious to most: lafilefixer
>
>> --- xfconf.eclass13 Jun 2010 16:10:21 - 1.16
>> +++ xfconf.eclass26 Jul 2010 18:57:14 - 1.17
>> @@ -1,6 +1,6 @@
>> # Copyright 1999-2009 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> -# $Header: /var/cvsroot/gentoo-x86/eclass/xfconf.eclass,v 1.16 2010/06/13
>> 16:10:21 ssuominen Exp $
>> +# $Header: /var/cvsroot/gentoo-x86/eclass/xfconf.eclass,v 1.17 2010/07/26
>> 18:57:14 ssuominen Exp $
>>
>> # @ECLASS: xfconf.eclass
>> # @MAINTAINER:
>> @@ -138,6 +138,9 @@
>> if [[ -n ${DOCS} ]]; then
>> dodoc ${DOCS} || die "dodoc failed"
>> fi
>> +
>> +has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
>> +find "${ED}" -name '*.la' -exec rm -f {} +
>> }
>>
>> # @FUNCTION: xfconf_pkg_preinst
Personally, I would have just done `find "${D}" -name '*.la' -exec rm -f
{} +`, because there are no files in $D that are not in $ED (if there
are, portage will refuse to merge the package on Prefix).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJMTebjAAoJELHSF2kinlg4/3YQAILmGYFlLkzVnMdD4mUGifLx
kZjMs3klDcWguQXJmA2sYRSSZtV/g5Men5/yfvjOIGGtiW0LUBuJl7BawCnhiddp
uXjtlbVUGSOmQjWp/xy4gDyv21DYd/H/kcLmDcfjgfIObxyXC0X9q1VLG44ggGkj
M5PML/2me17ArOy3hXbj/T/HtpTI1cp+EOw+Kp7XLhLrnztgocAh2taNcpnHQM1a
rws+GEXbUkLguGQek+rcw9xhzVMhe/11ZdZWvsudNqwFsTZ2cOcSH4UxxxvbbFnb
b8Qujh7Wqfz3sWEoaSGaoLPVGwgxy35SIsdBRdvvvFjLFc2Vuga9iAW4adgV1IyM
oTXntGgKhzaRnJe+oousQioURqzYUA2eaq5rb67hyxGIUd2UwRR9nK86hSfgC5XT
z2Y6TC8CmrPQD+6jptvdrnCFaGn7Cz8glM99x4qOnkvr35k9hUHZpu3U4Ca3s7V7
xu6qA6U/pbXglHGHc4ug3YUqDZFx/yMROI9YL+Mf2Ogt/EnC/oORL1g1VteRWlUO
frvd1K1F2JqAq2SS1o15U7kQ9vapSU2sCBsbAtg6CfmEGMACngIug86jQlJKtJ7f
B0+2O/dImIhvpH0E9BkHB6zcCa4tRwur5KO8i+U/sMmo2ZBSOx/VcysUGkW9b0J/
eNusNJ6xg+eDP1uITD26
=fTXV
-END PGP SIGNATURE-
[gentoo-dev] Re: Gentoo Council 2010/2011 - Nominations are now open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/05/2010 09:19 AM, Samuli Suominen wrote: > On Saturday 05 of June 2010 02:00:02 Torsten Veller wrote: >> Hello fellow developers and users. >> >> Nominations for the Gentoo Council 2010/2011 are now open for the next >> two weeks (until 23:59 UTC, 18/06/2010). >> >> All nominations must be sent to the gentoo-dev mailing list. If you >> were nominated and want to run, you have to accept your nomination on >> the same mailing list. > > I'll nominate flameeyes and halcy0n. > I'd nominate vapier and scarabeus too, but they already got nominated so > no point. > > that is... if i'm still allowed to... ;-) > > According to the rules listed in the first post of this thread, *anyone* can make nominations - the only restriction in that regard is that the *nominee* be a dev. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMCoHNAAoJELHSF2kinlg4YUQQAJKxdu13+WTExzqPbCHwS0So up2us8ETsoRQjLIURvuN0VAu1pt9dTMKayHOXIYA8PBhas6wKAG96zgi3SDOiN2b Dfj2EKYuGYsBGx2/vLVdiiuam2FZAXij9wvrDV/2k8yetnq1zXj5AolHA/ANYipL gen9gdn+fxwxOOQX+7sfQzTb41cbtfN/t55Dh3xpt/lfbdjRqOZMR4eBjLT5MtrD Km53ENxvlVeYjji6qTzxEC6SzTxMZiQ99onDsAsm9lYdx/aZjES0HqC52sP1mNck GPkKkP3QDjZihZL0w3p809S0UiI4kC+Y/oPGkeNgW+a91XuNUg/tDpZGkHmtYVA3 RHOb7f4ILtUTDGgSI0IEy7f4b5vZf6LHNyalqLeTn4o0oPiF8cXcGjvsBPiy8LR0 zvRgxzhikkZ4bhx6CdgZHOvAOmZyw2nMqE+PHcfRR5rXvnV1vkwHv8SyL7B72HW2 b7Q8AcsuEo/QA9v/2PSQ7+iseQlOcc9kJgNsZlHCQ1yGOnYhjh8BuRL90VA7Rgs+ hGL6GYw8Mlqn3wiyEqUEsC8luSb6W505Ib0TkG84U2blaT8yO+LdzAPy5rh9cQyu gcUrLm0MKqXVwt8Q82pDxe1i5QIKTPsp8frsA9w7PTJr2+cFOeMb1wS86/KJUaSZ WaZQ2CkTr2pJfVuLrQdM =KcFp -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/enchant: ChangeLog enchant-1.5.0.ebuild
On 04/06/2010 12:26 PM, Gilles Dartiguelongue wrote:
> Le mardi 06 avril 2010 à 16:14 +0000, Jonathan Callen (abcd) a écrit :
>> -src_unpack() {
>> +src_prepare() {
>> unpack ${A}
>> cd "${S}"
>> # Fix for upstream bug #12305
>> @@ -41,13 +41,12 @@
>> eautoreconf
>> }
>
> Please remove stuff that has no place in prepare (unpack, cd ${S})
I had thought I had deleted those... fixed.
--
Jonathan Callen
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: perl eclass review - EAPI=3 + new helper eclass
On 04/01/2010 07:41 PM, James Cloos wrote: > And given that portage inappropriately ignores a fixed eclass in the > OVERlay, that means that every time one syncs one must re-patch the > offending eclasses. If you want all ebuilds to use eclasses from a given overlay (if available) instead of the eclasses from the same repository, then you should add the following 2 lines to /etc/portage/repos.conf: [DEFAULT] eclass-overrides = local Where "local" is the contents of /path/to/overlay/profiles/repo_name. -- Jonathan Callen signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Python 3.1: Stabilization and news item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/23/2010 03:13 PM, Arfrever Frehtes Taifersar Arahesis wrote: > I'm attaching updated news item, which will be committed soon. > A couple grammar issues: - -modules, which support both Python 2 and Python 3, are installed for both - -active version of Python 2 and active version of Python 3, when both Python 2 - -and Python 3 are installed. +modules that support both Python 2 and Python 3 are installed for both the +active version of Python 2 and the active version of Python 3 when both +Python 2 and Python 3 are installed. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkupHS0ACgkQOypDUo0oQOp+3ACdFdADMtd40bbzDO+/8wUgefZb 7gEAnj/SNtfF3/0FAXNw/ffRki4vjE7o =cCyr -END PGP SIGNATURE-
[gentoo-dev] Re: [rfc] making autotools.eclass depends flexible
On 03/06/2010 02:11 AM, Petteri Räty wrote: > What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the > DEPENDs should be under. This approach doesn't allow the ebuild > maintainer to forget adding the depends. That approach also disallows (or makes unduly difficult) making the dependency such that "I need autotools on USE=kernel_SunOS or USE=kernel_freemint, but nowhere else" or "I need autotools when USE=foo and USE=bar, but not otherwise". -- Jonathan Callen signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Changes to make_desktop_entry in eutils.eclass
On 02/24/2010 01:16 PM, Pacho Ramos wrote:
> El mar, 23-02-2010 a las 20:26 -0500, Jonathan Callen escribió:
>> Attached is a patch to properly comply with the part of the FDO Desktop
>> Menu Specification pertaining to Categories (namely, always ensuring
>> that the list ends in a ";") and the part of the FDO Desktop Entry
>> Specification and Icon Theme Specification pertaining to icons (namely,
>> that non-absolute paths MUST NOT have an extension).
>
> Would be nice if you would have time to look at the following old
> make_desktop_entry bug:
> http://bugs.gentoo.org/show_bug.cgi?id=191000
>
> Thanks a lot :-D
I edited the patch to include a fix for but 191000 as well. See attached.
--- eutils.eclass
+++ eutils.eclass.new
@@ -961,6 +961,7 @@ make_desktop_entry() {
news) type=News;;
nntp) type=News;;
p2p)type=FileTransfer;;
+ voip) type=Telephony;;
*) type=;;
esac
type="Network;${type}"
@@ -979,7 +980,7 @@ make_desktop_entry() {
visual*) type=DataVisualization;;
*) type=;;
esac
- type="Science;${type}"
+ type="Education;Science;${type}"
;;
sys)
@@ -991,7 +992,7 @@ make_desktop_entry() {
client) type=WebBrowser;;
*) type=;;
esac
- type="Network"
+ type="Network;${type}"
;;
*)
@@ -1007,6 +1008,17 @@ make_desktop_entry() {
local desktop="${T}/$(echo ${exec} | sed
's:[[:space:]/:]:_:g')-${desktop_name}.desktop"
#local desktop=${T}/${exec%% *:-${desktop_name}}.desktop
+ # Don't append another ";" when a valid category value is provided.
+ [[ -n ${type} && ${type} != *';' ]] && type+=";"
+
+ eshopts_push -s extglob
+ if [[ -n ${icon} && ${icon} != /* && ${icon} == *.@(xpm|png|svg) ]];
then
+ ewarn "As described in the Icon Theme Specification, icon file
extensions are not"
+ ewarn "allowed in .desktop files if the value is not an
absolute path."
+ icon=${icon%.@(xpm|png|svg)}
+ fi
+ eshopts_pop
+
cat <<-EOF > "${desktop}"
[Desktop Entry]
Name=${name}
@@ -1015,7 +1027,7 @@ make_desktop_entry() {
Exec=${exec}
TryExec=${exec%% *}
Icon=${icon}
- Categories=${type};
+ Categories=${type}
EOF
[[ ${path} ]] && echo "Path=${path}" >> "${desktop}"
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Changes to make_desktop_entry in eutils.eclass
Attached is a patch to properly comply with the part of the FDO Desktop
Menu Specification pertaining to Categories (namely, always ensuring
that the list ends in a ";") and the part of the FDO Desktop Entry
Specification and Icon Theme Specification pertaining to icons (namely,
that non-absolute paths MUST NOT have an extension).
--- eutils.eclass
+++ eutils.eclass.new
@@ -961,6 +961,7 @@ make_desktop_entry() {
news) type=News;;
nntp) type=News;;
p2p)type=FileTransfer;;
+ voip) type=Telephony;;
*) type=;;
esac
type="Network;${type}"
@@ -991,7 +992,7 @@ make_desktop_entry() {
client) type=WebBrowser;;
*) type=;;
esac
- type="Network"
+ type="Network;${type}"
;;
*)
@@ -1007,6 +1008,17 @@ make_desktop_entry() {
local desktop="${T}/$(echo ${exec} | sed
's:[[:space:]/:]:_:g')-${desktop_name}.desktop"
#local desktop=${T}/${exec%% *:-${desktop_name}}.desktop
+ # Don't append another ";" when a valid category value is provided.
+ [[ -n ${type} && ${type} != *';' ]] && type+=";"
+
+ eshopts_push -s extglob
+ if [[ -n ${icon} && ${icon} != /* && ${icon} == *.@(xpm|png|svg) ]];
then
+ ewarn "As described in the Icon Theme Specification, icon file
extensions are not"
+ ewarn "allowed in .desktop files if the value is not an
absolute path."
+ icon=${icon%.@(xpm|png|svg)}
+ fi
+ eshopts_pop
+
cat <<-EOF > "${desktop}"
[Desktop Entry]
Name=${name}
@@ -1015,7 +1027,7 @@ make_desktop_entry() {
Exec=${exec}
TryExec=${exec%% *}
Icon=${icon}
- Categories=${type};
+ Categories=${type}
EOF
[[ ${path} ]] && echo "Path=${path}" >> "${desktop}"
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: kde.eclass, kde-meta.eclass, kde-functions.eclass
As KDE 3 has been removed from the tree, the kde-* eclasses are no longer used by anything remaining in the tree. These eclasses are scheduled for removal on or about 2012/01/11. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: sys-apps/dchroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen (29 Dec 2009) # Project abandoned upstream (replaced by dev-util/schroot) # Collides with dev-util/schroot[dchroot] # Masked for removal in 30 days, bug 298874 sys-apps/dchroot -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6V70ACgkQOypDUo0oQOriGwCgymsLu2338AAqL1Fz9YUK/ONo COkAnimOrIEK52d8QZLpDOl1wdkhTx9I =t1zz -END PGP SIGNATURE-
[gentoo-dev] Re: gentoo-x86 commit in perl-core/Compress-Raw-Zlib
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torsten Veller wrote: > Why is prefix not in IUSE? > > IUSE lists "the USE flags used by the ebuild. > Historically, USE_EXPAND values and ARCH were not included..." > > prefix is not an ARCH. > While prefix is not an ARCH or a in USE_EXPANDed variable, it is included in the list of implicit USE flags, which do not need to be included in IUSE. > BTW: don't we bump EAPI to not add this `use prefix ||...` test? We could, if EAPI-3 were supported by portage (the support has not yet been enabled) and the council okayed it to be used in the tree (which has not yet occurred). - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkspbE8ACgkQOypDUo0oQOrkSwCfTCWlBmXCOiIeI2u8WInjnWVy YQIAnRNesROT2DNsUSApea6rv8lFpXyc =kfXK -END PGP SIGNATURE-
[gentoo-dev] Re: metdata.dtd should require
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: > В Пнд, 07/12/2009 в 21:20 +0100, Thilo Bangert пишет: >> Hans de Graaff said: >>> On Mon, 2009-12-07 at 12:56 +0100, Thilo Bangert wrote: >>>> dev-util/cucumbermissing >>> Fixed, but this is really a bug in metadata.dtd, which specifies >>> >> upstream)* )> > >> indeed: http://bugs.gentoo.org/show_bug.cgi?id=279206 > > So what we will do with this? It'll be great to fix dtd to follow our > requirements, but there is a problem: > > if we change dtd like this: > > > > we will force all metadata.xml files have strict order of tags: first > then other tags. Currently there are about 200 ebuilds with > different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 . > > Hans's suggestion http://bugs.gentoo.org/show_bug.cgi?id=279206#c7 works > but it is not nice and prohibits another order: herd, other tags, herd. > > Personally I'd kept dtd simple and forced ordering. > > So actually two questions here: > > 1. How should we fix dtd? > 2. Are there any problems if we fix dtd first and let maintainers fix > metadata.xml on bumps (iow, what will became broken if metadata.xml > became not valid)? > One way to allow for any ordering, would be: - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksnzAcACgkQOypDUo0oQOo3TQCgnvrr5r54RE5q2LVRYoT+Q2nR 6Q4AniRGhT0Tq1KnY1wAoZt7c+ZEfBvQ =Inet -END PGP SIGNATURE-
[gentoo-dev] Last rites: =app-crypt/qca-1*, app-crypt/qca-tls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen (14 Dec 2009) # Old Qt3-only version of qca, unused in tree # Removal on 2010-01-14 =app-crypt/qca-1* app-crypt/qca-tls -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksmatIACgkQOypDUo0oQOoslQCeKROyiPJbjAUf3apnc7hHtJUp fUsAoKsaZLzUUp4xFm3xoXSuZyMQxhpL =Fpwj -END PGP SIGNATURE-
[gentoo-dev] Heads up: cmake-utils.eclass changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Recently a change was made to cmake-utils.eclass, changing the
mycmakeargs parameter from a flat string to an array. This change was
also made to kde4-{base,meta}.eclass. The primary reason for this
change was to allow parameters passed to cmake to contain spaces (such
as "${S}" or "${EPREFIX}"). Currently, there is code in these eclasses
to properly convert a string to an array, keeping the previous behavior.
This code works in almost every case *except* if you want to change
mycmakeargs in src_test and call cmake-utils_src_configure again. The
few instances of this in the tree have been fixed to use arrays, as
should all new ebuilds.
The plan is to eventually remove this backwards-compatibility code, once
all usages in the tree have been converted.
- --
Jonathan Callen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.13 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksk+iEACgkQOypDUo0oQOqFhgCghP04XNdMb1U9xVDNzhQuwDSB
zMkAnRty6dY5V8GkTxkz4bHcRK9dDL1C
=kNek
-END PGP SIGNATURE-
[gentoo-dev] Deprecated eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following eclasses are not used anywhere in the tree, and as such have been marked as deprecated, with all functionality not related to uninstall removed (scheduled for removal on 2011/11/30, if not otherwise noted): aolserver.eclass check-kernel.eclass db4-fix.eclass ebook.eclass embassy-2.10.eclass embassy-2.9.eclass games-etmod.eclass games-ut2k4mod.eclass gnustep.eclass (remove on 2009/12/08) gnustep-funcs.eclass (remove on 2009/12/08) gnustep-old.eclass (remove on 2009/12/08) gst-plugins.eclass gtk-sharp-component.eclass iiimf.eclass java.eclass java-gnome.eclass java-utils.eclass kde-dist.eclass (remove on 2011/11/01) kde-source.eclass (remove on 2011/06/04) kernel.eclass mailer.eclass matrox.eclass mozconfig.eclass mozilla.eclass pcmcia.eclass php4_4-sapi.eclass php5_0-sapi.eclass (remove on 2009/12/24) php5_1-sapi.eclass tetex-2.eclass (remove on 2011/05/30) unipatch-001.eclass x11.eclass xfce4.eclass (remove on 2011/09/30) xfce42.eclass (remove on 2011/09/30) xfce44.eclass (remove on 2011/09/30) xmms-plugin.eclass The following eclasses have been marked as deprecated for more than 2 years, and as such have been removed from the tree: 64-bit.eclass (deprecated in 2005) commonbox.eclass (deprecated in 2006) debug.eclass (deprecated in 2007) gcc.eclass (deprecated in 2005) gtk-engines.eclass (deprecated in 2005) gtk-engines2.eclass (deprecated in 2005) inherit.eclass (deprecated in 2002) jakarta-commons.eclass (deprecated in 2005) java-pkg.eclass (deprecated in 2006) java-wsdp.eclass (deprecated in 2007) kde-base.eclass (deprecated in 2003) kde-i18n.eclass (deprecated in 2003) kernel-mod.eclass (deprecated in 2006) koffice-i18n.eclass (deprecated in 2004) kmod.eclass (deprecated in 2005) motif.eclass (deprecated in 2005) mozilla.eclass (deprecated in 2004) myth.eclass (deprecated in 2005) nxserver.eclass (deprecated in 2007) nxserver-1.3.2.eclass (deprecated in 2007) nxserver-1.4.eclass (deprecated in 2007) nxserver_1.5.eclass (deprecated in 2007) perl-post.eclass (deprecated in 2003) php.eclass (deprecated in 2006) php-2.eclass (deprecated in 2006) php5-sapi.eclass (deprecated in 2005) php5-sapi-r1.eclass (deprecated in 2005) php5-sapi-r2.eclass (deprecated in 2007) php5-sapi-r3.eclass (deprecated in 2007) php-ext.eclass (deprecated in 2007) php-ext-base.eclass (deprecated in 2007) php-ext-pecl.eclass (deprecated in 2007) php-ext-source.eclass (deprecated in 2007) php-lib.eclass (deprecated in 2007) php-pear.eclass (deprecated in 2007) php-sapi.eclass (deprecated in 2007) webapp-apache.eclass (deprecated in 2004) wxlib.eclass (deprecated in 2007) xfree.eclass (deprecated in 2004) No eclasses in either of these lists are being used in the tree; please remove any usage of them from overlays posthaste. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksTSZEACgkQOypDUo0oQOqu8QCgwVxTOBZTHZDSCOoH8j//OrES QOkAoNTGBP5qmo1MV6BuXrSzj85PBDzl =Nwia -END PGP SIGNATURE-
[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2009-10-25 23h59 UTC
Samuli Suominen wrote: > Nirbheek Chauhan wrote: >> On Mon, Oct 26, 2009 at 5:45 AM, Robin H. Johnson wrote: >>> The attached list notes all of the packages that were added or removed >>> from the tree, for the week ending 2009-10-25 23h59 UTC. >>> >>> Removals: >> [snip] >>> x11-themes/gtk-engines-kde4 2009-10-19 16:48:05 ssuominen >> [snip] >>> Additions: >>> x11-themes/gtk-engines-kde4 2009-10-19 16:26:02 ssuominen >> This is interesting. It's certainly not a category change; and the >> removal is after the addition; but the directories are still >> around[1]. >> >> Samuli, are you in the process of re-committing it or did you miss the >> empty directories? >> >> 1. >> http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-themes/gtk-engines-kde4/ >> > > It was a very bad decision to add this package so I've removed it like > few mins after adding. > > ssuomi...@unique ~/gentoo-x86/x11-themes $ cvs up > ssuomi...@unique ~/gentoo-x86/x11-themes $ ls -l *kde4* > ls: cannot access *kde4*: No such file or directory > ssuomi...@unique ~/gentoo-x86/x11-themes $ > > As shown above, there's no empty directory here. > > Actually, due to the way CVS works, there is an empty directory there, and will *always* be a directory there. I believe that in order to actually remove the directory, you have to have shell access to the cvs server itself. Most users end up setting up cvs to prune empty directories when checking out because of this exact problem. -- Jonathan
[gentoo-dev] Re: make install without die (gentoo-x86 commit in app-arch/hardlink, app-arch/duff )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Torsten Veller wrote: > An imprecise search (/make .*install$/) revealed another 200 packages: > http://dev.gentoo.org/~tove/files/makeinstallwithoutdie.txt > > Let it die before replacing a working package with a broken one. Removed from tree: kde-base/kdebase/kdebase-3.5.9.ebuild kde-base/kdebase/kdebase-3.5.9-r1.ebuild kde-base/kdebase/kdebase-3.5.9-r2.ebuild kde-base/kdebase/kdebase-3.5.9-r3.ebuild Fixed: kde-base/kdebase/kdebase-3.5.9-r4.ebuild kde-base/kdm/kdm-3.5.10.ebuild - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrh9VoACgkQOypDUo0oQOrTKgCdEPCduNbtJROucNWoc/2m6Nh2 3IgAnjTcTVmWl/4/iwL2umsf+QDiq3Sv =GNW7 -END PGP SIGNATURE-
[gentoo-dev] Re: RFC: multilib and the compatibility to singlelib
Mike Frysinger wrote:
> if you read FHS you'll see that both implementations are allowed. Gentoo
> isnt
> violating anything here. wrt LSB, who knows. there are a ton of things we
> dont follow with LSB.
Actually, at first, FHS says that any /lib would be allowed, but
it then goes into specifics in Chapter 6, Operating System Specific
Annex. Under the heading "/lib64 and /lib32 : 64/32-bit libraries
(architecture dependent)", it says, "The 64-bit architectures PPC64,
s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and
32-bit (or 31-bit on s390) libraries in /lib."
>> The problem was that Gentoo's early amd64 implementation predated this
>> standardization, and we had chosen the other way. While we've defaulted
>> to lib64 for 64-bit libs for years, it has never been considered anything
>> but experimental to break the lib --> lib64 link. AFAIK stable
>> baselayout still doesn't get its libdir usage consistent, putting files
>> in one but actually calling them using the other path, and boot breaks in
>> various frustrating ways if lib and lib64 are not the same directory.
>> Openrc gets it better now, but I'm not sure it's all fixed either -- it
>> certainly wasn't last time I tried breaking the link.
>
> your "AFAIK" isnt useful. there are no open bugs about either version and
> people assume that it's doing the right thing.
Personally, I do have a ~amd64 Gentoo chroot with LIBDIR_x86="lib".
There is only one place that I've found that it is still broken, namely
one line in toolchain.eclass (patch attached). I've been meaning to file
a bug for quite a while now, but never got around to it.
--
Jonathan
--- /usr/portage/eclass/toolchain.eclass
+++ toolchain.eclass
@@ -1956,8 +1956,7 @@ gcc_movelibs() {
${LIBPATH}/${OS_MULTIDIR} \
${LIBPATH}/../${MULTIDIR} \
${PREFIX}/lib/${OS_MULTIDIR} \
- ${PREFIX}/${CTARGET}/lib/${OS_MULTIDIR} \
- ${PREFIX}/lib/${MULTIDIR}
+ ${PREFIX}/${CTARGET}/lib/${OS_MULTIDIR}
do
removedirs="${removedirs} ${FROMDIR}"
FROMDIR=${D}${FROMDIR}
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] virtualx.eclass changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Recently, virtualx.eclass changed how it adds dependencies. Previously,
it always added IUSE=X, and added "X? ( x11-base/xorg-server
x11-apps/xhost )" to both DEPEND and RDEPEND (the RDEPEND part appears
to have been unintentional). This has been changed to instead be in the
control of the ebuild inheriting virtualx.
If you always need an X server to build, set VIRTUALX_REQUIRED=always
before inheriting virtualx, and the dependencies will be added to DEPEND
unconditionally.
If you only need an X server to run tests, just inherit virtualx. The
dependencies will be added with "test? ( )" around them, and "test" will
be added to IUSE.
If you need the X server under other conditions, set
VIRTUALX_REQUIRED=manual before inheriting virtualx, then use
${VIRTUALX_DEPEND} in DEPEND as needed.
This change has effectively removed the "X" USE flag from the following
packages where it should have been "test":
app-accessibility/gnome-mag
app-accessibility/gok
dev-libs/libunique
dev-python/gnome-python-desktop
dev-python/gnome-python-extras
dev-python/pygobject
dev-python/pygtk
gnome-base/eel
gnome-base/gnome-keyring
gnome-base/libbonoboui
gnome-base/libgnomecanvas
gnome-base/nautilus
gnome-extra/at-spi
gnome-extra/gnome-games
gnome-extra/gnome-power-manager
media-sound/rhythmbox
net-libs/webkit-gtk
sci-astronomy/wcslib
sci-mathematics/freemat
x11-libs/gtk+:2
x11-libs/guile-gtk
xfce-base/thunar
The following other packages also had changes for this:
app-crypt/heimdal:
the X server dep is now controlled by "test? ( X? ( ... ) )"
media-sound/rubyripper
the X server dep is now unconditional, and the package's X flag is
no longer in package.use.force.
- --
Jonathan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkrduS8ACgkQOypDUo0oQOrdGACeOajNxjLLoqw8A6aRC7G4vcTt
++wAn0qjITRs+V5tN0YZXjKkfLYs/lco
=edMH
-END PGP SIGNATURE-
[gentoo-dev] Last rites: Monolithic KDE 3.5.9 packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen (11 Oct 2009) # Old KDE 3.5.9 monolithic ebuilds. Replaced by kde*-meta. # Masked for removal in 30 days kde-base/kdeaccessibility kde-base/kdeaddons kde-base/kdeadmin kde-base/kdeartwork kde-base/kdebase kde-base/kdeedu kde-base/kdegames kde-base/kdegraphics kde-base/kde kde-base/kdemultimedia kde-base/kdenetwork kde-base/kdepim kde-base/kdesdk kde-base/kdetoys kde-base/kdeutils kde-base/kdewebdev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrSTOYACgkQOypDUo0oQOrQywCfXqypmrGr9S/XzezA1/kA1bwF 88oAn0TLo+Lm3f+re5ac785EtMkBGhun =O+Nj -END PGP SIGNATURE-
[gentoo-dev] Re: python-wrapper breaks init scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Haubenwallner wrote: > The problem here IMO is that this wrapper executes python2.6 with argv0 set > to python2.6, while it should be the argv0 from how the wrapper was executed. > At least this is what init.d scripts expect (seen with ntlmaps too). > > /haubi/ > Unfortunately, if argv[0] is *not* set to python2.6, it appears that some python programs crash, thereby making this a lose-lose proposition. I believe there is a way to make s-s-d stop a program by looking only at its pid, via a .pid file, which you may be able to use to work around the issue. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrKV8sACgkQOypDUo0oQOog6QCg18/A06tmecCa/5L6r7qoKAO1 urAAoKIHKiZyKveYoDwCQZ/woeRQdwY/ =C9ao -END PGP SIGNATURE-
[gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: > Title: Migration to X.org Server 1.6 and libxcb 1.4 > Author: Remi Cardona > Content-Type: text/plain > Posted: 2009-10-02 > Revision: 1 > News-Item-Format: 1.0 > Display-If-Installed: Display-If-Installed: > We're pleased to announce the stabilization of xorg-server-1.6. Users > are strongly encouraged to read the following two guides before upgrading: This should be wrapped to 72 characters/line. > > http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.6-upgrade-guide.xml > > http://www.gentoo.org/proj/en/desktop/x/x11/libxcb-1.4-upgrade-guide.xml > > Otherwise, it looks good to me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrFqv4ACgkQOypDUo0oQOpRkQCfXrZOesfAdH7K8wLIta4Y+jm7 oTYAnjbp1onG/51oMmNV/dRXd4lrYUUE =LDiJ -END PGP SIGNATURE-
[gentoo-dev] Re: why doesn't readline-6 install libreadline.so symlink?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Grozin wrote: > I'm using portage-2.2_pre*. After upgrading to sys-libs/readline-6.0, > portage (naturally) kept /lib/libreadline.so.5 -> > /lib/libreadline.so.5.2, because a lot of programs needed it. I did > emerge @preserved-rebuild, and only one binary using libreadline.so.5.2 > left: /usr/bin/gp, the interactive interpreter of sci-mathematics/pari. > Re-emerging it does not help: headers from readline-6 are used, but the > program links wirh libreadline.so.5.2. I thought something is wrong in > the pari's configure. This package does not use autoconf, but a > hand-written Configure script. It seems all right. Then I found that > /lib/libreadline.so symlink still points to libreadline.so.5. This > confuses the pari's Configure. I made it to point to libreadline.so.6 by > hand, and re-emerged pari. OK, gp now links with libreadline.so.6.0. Why > doesn't readline-6.0 ebuild install this symlink? > > After this re-emerging of pari, portage said > > !!! existing preserved libs: package: sys-libs/readline-6.0_p3 > * - /lib/libreadline.so > * used by /usr/bin/M2 (sci-mathematics/Macaulay2-1.2-r3) > * used by /usr/bin/Singular-3-0-4 (sci-mathematics/singular-3.0.4.4) > * used by /usr/bin/asy (media-gfx/asymptote-1.86) > * used by 111 other files > > I already re-emerged these packages (at least, 3 shown) as a part of > emerging @preserved-rebuild after upgrading readline, and they were not > in the @preserved-rebuild set before I changed the libreadline.so > symlink. Does this mean that all of these packages used libreadline.so > -> libreadline.so.5? This is not good. I'm going to emerge > @preserved-rebuild again, to be sure that my system is in a > self-consistent state. > > It seems that keeping libreadline.so -> libreadline.so.5 after merging > readline-6.0 and unmerging readline-5.2 is a bad idea. > > Andrey > > I'm not completely sure, but I think it doesn't install that symlink because it (correctly) installs a /usr/lib/libreadline.so ldscript, that tells the linker to link against /lib/libreadline.so.6, so long as the linker looks at /usr/lib before /lib, which is usually the case, unless "-L/lib" is passed to ld (by way of gcc). If you remove /lib/libreadine.so, then everything will Just Work, and portage will forget that that file ever existed as soon as you merge a package (any package). I'm not sure what the correct behavior of FEATURES="preserve-libs" should actually be in this case, but I think portage may need to look a little closer at the SONAME, and only preserve that file (like the old preserve_old_lib) or preserve only that symlink and what it links to, not everything that points at that. - -- Jonathan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq9rroACgkQOypDUo0oQOrUjgCdEoFum1tqM1f/g2BiGl7QKMc5 Ti0AoIeTDN6exLzTuR9hjRHe0UzKh41h =rwgK -END PGP SIGNATURE-
