USE=multislot, xDEPEND-syntax in SLOT and Slot dependencies [Was: Re: [RFC] some global useflags]

I'm deliberately starting a new thread here, because this is meandering
well off the original topic of the global useflag proposals.

On Thu, Oct 16, 2008 at 02:18:16AM +0200, Marius Mauch wrote:
> There are also other issues, e.g. it breaks the generation of the
> @installed package set as the installed slots can't be found in the
> tree. As portage-2.2 makes increased use of slot atoms internally for
> vdb handling we got a few bugreports simply due to the cache constraint
> violation by USE=multislot.
Ok, I found bug #174184 on this matter.

kugelfang proposed to include this in EAPI=1, but I don't find it in
there, what happened?

The short-term fix of use.mask just stops current breakage, but we need
a real solution so that we can keep using it where we actually need it.

Ignoring Vapier's tirade against ciaranm there, we need the
xDEPEND-syntax for SLOTS as the real solution, however that still
wouldn't resolve the portion that has CTARGET as part of the SLOT, since
metadata generated on the rsyncmaster with a different CTARGET wouldn't
match on the clients.

I'm also wondering about a bad interaction with slot dependencies even
without having CTARGET:
Say gcc has two variants, SLOT=3.4 and SLOT=3.4.5. 
The language in the approved version of PMS (section 9.2.5) states: "A
specification with a named slot dependency matches only if the slot of
the matched package is squal to ths lot specified."

[RFC] some global useflags

server                        16
logrotate                     10
gsm                           9
custom-cflags                 9
kontact                       8
openmp                        8
plasma                        7
html                          7
demo                          7
smp                           6
icu                           6
editor                        6
multislot                     6
nautilus                      6
audacious                     6
tools                         6
qt3support                    6
dxr3                          6
music                         5
smtp                          5
fax                           5
bsf                           5
irc                           5
mp4                           5
clisp                         5
nfs                           5
pcsc-lite                     5
zvbi                          5
http                          5
web                           5

Stabilize ebuilds which use EAPIs only supported by ~arch PMs

Hi all:

Reading a random discussion in our dev mailling list, I came with a
doubt about our new EAPI policy and its procedures. I couldn't find it
documented nor discussed anywhere so I bringing it here.

Supposing that anyone can currently add an ebuild using EAPI-2 under the
testing branch: what are we going to do if an EAPI-2 ebuild (which are
only managed by ~arch package managers) needs to go stable due to some
kind of major reason like security? 

Hypothetical case: foo-1 (eapi-0) marked as stable and foo-2 (eapi-2)
with new features marked as testing. A security problem appears
affecting both. UPSTREAM release foo-3 to solve the security issue.

There are some others sceneries but are not so common as the one presented
could be. Any decent solution for this case?

--

-- 
Jose Luis Rivero <yoswink <at> gentoo.org>
Gentoo/Doc Gentoo/Alpha

Automated Package Removal and Addition Tracker, for the week ending 2008-10-12 23h59 UTC

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2008-10-12 23h59 UTC.

Removals:
dev-tex/vntex                      	2008-10-06 19:53:29	aballier
media-sound/gogo                   	2008-10-08 16:08:15	mr_bones_
www-apps/xrms                      	2008-10-11 19:12:23	wrobel
www-apps/bugport                   	2008-10-12 05:49:06	wrobel

Additions:
dev-db/maatkit                     	2008-10-06 11:34:32	wschlich
sys-apps/fakeroot-ng               	2008-10-06 21:55:10	spock
media-libs/realcodecs              	2008-10-07 15:02:53	beandog
media-libs/babl                    	2008-10-07 21:34:20	hanno
media-libs/gegl                    	2008-10-07 22:12:50	hanno
dev-lang/c-intercal                	2008-10-08 00:58:26	ulm
x11-misc/ktsuss                    	2008-10-09 05:06:39	darkside
app-dicts/stardict-freedict-tur-eng	2008-10-09 19:17:24	serkan
app-dicts/stardict-freedict-tur-deu	2008-10-09 19:21:08	serkan
app-dicts/stardict-freedict-eng-tur	2008-10-09 19:24:19	serkan
games-arcade/tecnoballz            	2008-10-09 20:42:44	tupone
dev-java/jpf                       	2008-10-11 19:50:07	caster
media-libs/exempi                  	2008-10-11 22:30:41	eva
gnome-extra/gnome-user-share       	2008-10-12 20:14:39	eva

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail     : robbat2 <at> gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

System packages in (R)DEPEND?

I see packages like bison, flex, perl or sed in the system set. And i also see ebuilds depending on
them. I also heard from Peter Volkov (pva) that there where discussions about removing different
packages from the system set. So now my question is:

Should we depend on all system packages? Should we depend on some packages, because they could be
removed? If yes, which ones? Or should we leave the system packages out completly?

--

-- 
Thomas Sachau

Gentoo Linux Developer

RFC: fox.eclass update

Hi folks,

While fixing bug #240060 I touched fox.eclass.
In the process, I updated the eclass to 
    * use versionator
    * cut support for fox-1.0 (loong outdated)
    * cut support for fox-1.5
    * use eautomake instead of =automake-1.4*
    * use emake instead of make
    * use elog instead of einfo
    * apply more variable quoting

I'm sure, I missed one or the other issue. That's why I'm posting it
here for public review. If you have requests or comments to make, please
reply to this thread.
--

-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/fox.eclass,v 1.7 2007/01/15 20:27:06 mabi Exp $

# fox eclass
#
# This eclass allows building SLOT-able FOX Toolkit installations
# (x11-libs/fox: headers, libs, and docs), which are by design
# parallel-installable, while installing only one version of the utils
# (dev-util/reswrap) and apps (app-editors/adie, sci-calculators/calculator,

Last rites: net-mail/qmail-vmailmgr

# Thilo Bangert <bangert <at> gentoo.org> (12 Oct 2008)
# Masked for removal in 30 days (see bug #240371)
# useless meta ebuild - never fully developed
net-mail/qmail-vmailmgr

svn.overlays migration/downtime

Hi Folks,

At some point over this weekend (we haven't pinned an exact time yet,
details to follow), there's going to be a ~5-minute outage of overlays
SVN service to move SVN onto the new server.

Bug reports for items not listed here should go to bugzilla (Product:
Infra, Component: Other)

The SVN side is pretty much worked out. 
Known issues:
- Subersion failed to include a required Content-Length header with the
  serf library (if you have USE='webdav-serf -webdav-neon').
  https://bugs.gentoo.org/241234
  This will break all SVN actions until fixed.

Source Viewing:
- Trac and ViewVC.

Wiki side:
- We were originally going to ditch Trac entirely, but for the moment
  we're just sticking with it. If we do switch wikis, it will be either
  dokuwiki or MediaWiki.

You can play with the new box at by using the new DNS:
overlaystest.gentoo.org
ALL changes will be wiped when we do the final migration.

Old box specs:
egret - 1.5GHz Sempron 2200+, 512MiB RAM, 80GB IDE.

net-nds/nis-utils needs a maintainer or it will get removed.

If you don't use NIS or NIS+ you can stop reading now; if you do use
NIS or NIS+...I'm so so sorry.

The basic gist is "this package is old and everyone should move to LDAP."

Consider it masked in two weeks for removal in 30 days unless a
maintainer is found.

-Alec

Last rites: dev-java/gnu-jaxp

# Serkan Kaba <serkan <at> gentoo.org> (09 Oct 2008)
# Masked for removal in 30 days (see bug #240734)
# Included in gnu-classpath. No reverse dependencies.
dev-java/gnu-jaxp

--
Sincerely,
Serkan KABA
Gentoo/Java

EAPI change: Call ebuild functions from trusted working directory

Hello,

currently, PMS section 10.1 states:

  Some functions may assume that their initial working directory is
  set to a particular location; these are noted below.
  If no initial working directory is mandated, it may be set to
  anything and the ebuild must not rely upon a particular location
  for it.

Please consider the following addition to this paragraph:

  The ebuild can rely that the chosen initial working direcotry is
  a trusted location that is not world-writable and owned by
  a privileged user and group.

This change affects all pkg_ functions.

Rationale:
This feature presents a security hardening to work around 
vulnerabilities in ebuilds and applications called by ebuilds, and the 
Gentoo Security Team considers this the official solution to
bug 239560 / GLSA 200810-02.

I would like:
 * everyone to comment on the change and propose changes to the wording
 * council to vote on this change to EAPI-0, -1 and -2.

Portage implements this in 2.1.4.5 and 2.2_rc12, Paludis in 0.30.2.
I have not heard back from Brian on pkgcore (because this issue has been