[gentoo-dev] llvm-libunwind global USE flag

2021-04-01 Thread Arfrever Frehtes Taifersar Arahesis
llvm-libunwind - Use sys-libs/llvm-libunwind instead of sys-libs/libunwind

This would be similar to graphicsmagick and libressl USE flags.

sys-libs/libunwind and sys-libs/llvm-libunwind are ABI-incompatible,
at least due to different sonames of libraries. Switching between them
requires rebuilding of all reverse dependencies.

Example usage:

RDEPEND="libunwind? (
llvm-libunwind? ( sys-libs/llvm-libunwind:0= )
!llvm-libunwind? ( sys-libs/libunwind:0= )
  )"



Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: new function tc-ld-force-bfd()

2021-01-20 Thread Arfrever Frehtes Taifersar Arahesis
Maybe one generic function (called e.g. tc-set-linker) whose arguments
are a preference-ordered list of supported linkers?
If currently used linker is not in the specified list, then this
function would force using first found linker from that list.

Forcing bfd only:
  tc-set-linker bfd

Forcing gold only:
  tc-set-linker gold

Forcing lld only:
  tc-set-linker lld

Forcing bfd or gold (with bfd preferred if both are available):
  tc-set-linker bfd gold

Forcing bfd or lld (with bfd preferred if both are available):
  tc-set-linker bfd lld

Forcing lld or bfd (with lld preferred if both are available):
  tc-set-linker lld bfd



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/libuv: libuv-1.2.1.ebuild ChangeLog

2015-01-19 Thread Arfrever Frehtes Taifersar Arahesis
2015-01-19 10:40 Jeroen Roovers napisał(a):
 On Fri, 16 Jan 2015 15:26:55 +
 hasufell hasuf...@gentoo.org wrote:
 
  Patrick Lauer (patrick):
   patrick 15/01/16 04:16:55
   
 Modified: ChangeLog
 Added:libuv-1.2.1.ebuild
 Log:
 Bump
 
  
  I expect people to ask me for review if they bump any of my packages.
  That includes QA team members.
 
 The only (QA) problem I see is the pointless removal of the ebuild in
 question and the subsequent addition of a pointless revision bump with
 no clue as to why it was removed or why the revision bump was required

$ diff -u1 libuv-1.2.1.ebuild libuv-1.2.1-r1.ebuild
--- libuv-1.2.1.ebuild
+++ libuv-1.2.1-r1.ebuild
@@ -2,3 +2,3 @@
 # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-libs/libuv/Attic/libuv-1.2.1.ebuild,v 
1.1 2015/01/16 04:16:55 patrick Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-libs/libuv/libuv-1.2.1-r1.ebuild,v 1.1 
2015/01/16 15:47:31 hasufell Exp $
 
@@ -9,3 +9,3 @@
 DESCRIPTION=A new platform layer for Node
-HOMEPAGE=https://github.com/joyent/libuv;
+HOMEPAGE=https://github.com/libuv/libuv;
 SRC_URI=https://github.com/libuv/libuv/archive/v${PV}.tar.gz - ${P}.tar.gz
@@ -17,3 +17,6 @@
 
-DEPEND=virtual/pkgconfig
+DEPEND=
+   sys-devel/libtool
+   virtual/pkgconfig
+
 
@@ -24,4 +27,4 @@
sed -i \
-   -e '/libuv_la_CFLAGS/s#-g##' \
-   Makefile.am || die fixing CFLAGS failed!
+   -e '/CC_CHECK_CFLAGS_APPEND(\[-g\])/d' \
+   configure.ac || die fixing CFLAGS failed!
 


The broken libuv-1.2.1.ebuild was not disabling unwanted addition of -g to 
CFLAGS.
The fix for this problem affected installed files, so revision bump was 
required.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] emerge --verbose --quiet-repo-display: Delete deprecated code

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
[[[
emerge --verbose --quiet-repo-display: Delete deprecated code.

Use portage.repository.config.RepoConfigLoader.__iter__() instead of deprecated
PORTDIR and PORTDIR_OVERLAY.
1 call to deprecated 
portage.repository.config.RepoConfigLoader.mainRepoLocation()
has been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/_emerge/resolver/output_helpers.py
+++ pym/_emerge/resolver/output_helpers.py
@@ -39,24 +39,13 @@
 		self._unknown_repo = False
 		repo_paths = set()
 		for root_config in roots.values():
-			portdir = root_config.settings.get(PORTDIR)
-			if portdir:
-repo_paths.add(portdir)
-			overlays = root_config.settings.get(PORTDIR_OVERLAY)
-			if overlays:
-repo_paths.update(shlex_split(overlays))
+			for repo in root_config.settings.repositories:
+repo_paths.add(repo.location)
 		repo_paths = list(repo_paths)
 		self._repo_paths = repo_paths
 		self._repo_paths_real = [ os.path.realpath(repo_path) \
 			for repo_path in repo_paths ]
 
-		# pre-allocate index for PORTDIR so that it always has index 0.
-		for root_config in roots.values():
-			portdb = root_config.trees[porttree].dbapi
-			portdir = portdb.repositories.mainRepoLocation()
-			if portdir:
-self.repoStr(portdir)
-
 	def repoStr(self, repo_path_real):
 		real_index = -1
 		if repo_path_real:
@@ -80,7 +69,7 @@
 		shown_repos = self._shown_repos
 		unknown_repo = self._unknown_repo
 		if shown_repos or self._unknown_repo:
-			output.append(Portage tree and overlays:\n)
+			output.append(Repositories:\n)
 		show_repo_paths = list(shown_repos)
 		for repo_path, repo_index in shown_repos.items():
 			show_repo_paths[repo_index] = repo_path


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] portageq pquery: Search ebuilds in all repositories be default

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
[[[
portageq pquery: Search ebuilds in all repositories be default.

--all-repos option is no longer supported.
1 call to deprecated portage.repository.config.RepoConfigLoader.mainRepo() 
function
has been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- bin/portageq
+++ bin/portageq
@@ -1075,14 +1075,10 @@
 			herds.extend(x.split(,))
 		xml_matchers.append(HerdMatcher(herds))
 
-	repos = []
-	if opts.all_repos:
-		repos.extend(portdb.repositories.get_repo_for_location(location)
-			for location in portdb.porttrees)
-	elif opts.repo is not None:
-		repos.append(portdb.repositories[opts.repo])
+	if opts.repo is not None:
+		repos = [portdb.repositories[opts.repo]]
 	else:
-		repos.append(portdb.repositories.mainRepo())
+		repos = list(portdb.repositories)
 
 	if not atoms:
 		names = None
@@ -1220,12 +1216,8 @@
 },
 {
 	longopt: --repo,
-	help: repo to use (default is PORTDIR if omitted)
+	help: repository to use (all repositories are used by default)
 },
-{
-	longopt: --all-repos,
-	help: search all repos
-}
 			)
 		),
 		(


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] portage.dbapi.bintree.binarytree: Delete PORTDIR-reliant microoptimization in index of binary packages

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
[[[
portage.dbapi.bintree.binarytree: Delete PORTDIR-reliant microoptimization in 
index of binary packages.

This microoptimization cannot work when no main repository exists.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/portage/dbapi/bintree.py
+++ pym/portage/dbapi/bintree.py
@@ -360,16 +360,6 @@
 repository   : ,
 			}
 
-			# It is especially important to populate keys like
-			# repository that save space when entries can
-			# inherit them from the header. If an existing
-			# pkgindex header already defines these keys, then
-			# they will appropriately override our defaults.
-			main_repo = self.settings.repositories.mainRepo()
-			if main_repo is not None and not main_repo.missing_repo_name:
-self._pkgindex_default_header_data[repository] = \
-	main_repo.name
-
 			self._pkgindex_translated_keys = (
 (DESCRIPTION   ,   DESC),
 (repository,   REPO),


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] portage.tests.dbapi.test_portdb_cache: Delete deprecated code.

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
[[[
portage.tests.dbapi.test_portdb_cache: Delete deprecated code.

9 calls to deprecated 
portage.repository.config.RepoConfigLoader.mainRepoLocation()
function have been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/portage/tests/dbapi/test_portdb_cache.py
+++ pym/portage/tests/dbapi/test_portdb_cache.py
@@ -47,7 +47,7 @@
 			(lambda: not os.path.exists(md5_cache_dir),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
-if portage.portdb.repositories.mainRepoLocation() in portage.portdb._pregen_auxdb:
+if portage.portdb.repositories['test_repo'].location in portage.portdb._pregen_auxdb:
 	sys.exit(1)
 			),),
 
@@ -56,13 +56,13 @@
 			(lambda: os.path.exists(md5_cache_dir),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
-if portage.portdb.repositories.mainRepoLocation() not in portage.portdb._pregen_auxdb:
+if portage.portdb.repositories['test_repo'].location not in portage.portdb._pregen_auxdb:
 	sys.exit(1)
 			),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
 from portage.cache.flat_hash import md5_database
-if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories.mainRepoLocation()], md5_database):
+if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories['test_repo'].location], md5_database):
 	sys.exit(1)
 			),),
 
@@ -73,13 +73,13 @@
 			(lambda: os.path.exists(md5_cache_dir),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
-if portage.portdb.repositories.mainRepoLocation() not in portage.portdb._pregen_auxdb:
+if portage.portdb.repositories['test_repo'].location not in portage.portdb._pregen_auxdb:
 	sys.exit(1)
 			),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
 from portage.cache.flat_hash import md5_database
-if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories.mainRepoLocation()], md5_database):
+if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories['test_repo'].location], md5_database):
 	sys.exit(1)
 			),),
 
@@ -90,13 +90,13 @@
 (cache-formats = pms md5-dict, layout_conf_path,,
 			(portage_python, -b, -Wd, -Wi::DeprecationWarning, -c) + (textwrap.dedent(
 import os, sys, portage
-if portage.portdb.repositories.mainRepoLocation() not in portage.portdb._pregen_auxdb:
+if portage.portdb.repositories['test_repo'].location not in portage.portdb._pregen_auxdb:
 	sys.exit(1)
 			),),
 			(portage_python, -b, -Wd, -Wi::DeprecationWarning, -c) + (textwrap.dedent(
 import os, sys, portage
 from portage.cache.metadata import database as pms_database
-if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories.mainRepoLocation()], pms_database):
+if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories['test_repo'].location], pms_database):
 	sys.exit(1)
 			),),
 
@@ -105,13 +105,13 @@
 			(BASH_BINARY, -c, rm %s % portage._shell_quote(layout_conf_path)),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
-if portage.portdb.repositories.mainRepoLocation() not in portage.portdb._pregen_auxdb:
+if portage.portdb.repositories['test_repo'].location not in portage.portdb._pregen_auxdb:
 	sys.exit(1)
 			),),
 			python_cmd + (textwrap.dedent(
 import os, sys, portage
 from portage.cache.flat_hash import md5_database
-if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories.mainRepoLocation()], md5_database):
+if not isinstance(portage.portdb._pregen_auxdb[portage.portdb.repositories['test_repo'].location], md5_database):
 	sys.exit(1)
 			),),
 		)


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] portage.tests.glsa.test_security_set: Delete deprecated code

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
[[[
portage.tests.glsa.test_security_set: Delete deprecated code.

1 call to deprecated 
portage.repository.config.RepoConfigLoader.mainRepoLocation()
function has been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/portage/tests/glsa/test_security_set.py
+++ pym/portage/tests/glsa/test_security_set.py
@@ -1,4 +1,4 @@
-# Copyright 2013 Gentoo Foundation
+# Copyright 2013-2014 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import unicode_literals
@@ -129,8 +129,7 @@
 		try:
 
 			portdb = playground.trees[playground.eroot][porttree].dbapi
-			glsa_dir = os.path.join(
-portdb.repositories.mainRepoLocation(), 'metadata', 'glsa')
+			glsa_dir = os.path.join(portdb.repositories['test_repo'].location, 'metadata', 'glsa')
 			portage.util.ensure_dirs(glsa_dir)
 			for glsa in glsas:
 with io.open(os.path.join(glsa_dir,


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] emerge --info: Check metadata/timestamp.chk in all repositories

2014-12-13 Thread Arfrever Frehtes Taifersar Arahesis
New patch without os.path.isfile().

[[[
emerge --info: Check metadata/timestamp.chk in all repositories.

1 use of deprecated PORTDIR has been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/_emerge/actions.py
+++ pym/_emerge/actions.py
@@ -1452,6 +1452,7 @@
 	vardb = trees[eroot][vartree].dbapi
 	portdb = trees[eroot]['porttree'].dbapi
 	bindb = trees[eroot][bintree].dbapi
+	repos = portdb.settings.repositories
 	for x in myfiles:
 		any_match = False
 		cp_exists = bool(vardb.match(x.cp))
@@ -1554,13 +1555,10 @@
 			line += ,%10d free % (vm_info[swap.free] // 1024,)
 		append(line)
 
-	lastSync = portage.grabfile(os.path.join(
-		settings[PORTDIR], metadata, timestamp.chk))
-	if lastSync:
-		lastSync = lastSync[0]
-	else:
-		lastSync = Unknown
-	append(Timestamp of tree: %s % (lastSync,))
+	for repo in repos:
+		last_sync = portage.grabfile(os.path.join(repo.location, metadata, timestamp.chk))
+		if last_sync:
+			append(Timestamp of repository %s: %s % (repo.name, last_sync[0]))
 
 	# Searching contents for the /bin/sh provider is somewhat
 	# slow. Therefore, use the basename of the symlink target
@@ -1707,7 +1705,6 @@
 		append(%s %s % \
 			((cp + :).ljust(cp_max_len + 1), versions))
 
-	repos = portdb.settings.repositories
 	append(Repositories:\n)
 	for repo in repos:
 		append(repo.info_string())


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] emerge --info: Modernize output of configuration of repositories

2014-12-12 Thread Arfrever Frehtes Taifersar Arahesis
[[[
emerge --info: Modernize output of configuration of repositories.

- Always print detailed configuration of repositories.
- Always skip PORTAGE_REPOSITORIES variable.
- Always skip deprecated PORTDIR, PORTDIR_OVERLAY and SYNC variables.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/_emerge/actions.py
+++ pym/_emerge/actions.py
@@ -1713,13 +1713,9 @@ def action_info(settings, trees, myopts, myfiles):
 			((cp + :).ljust(cp_max_len + 1), versions))
 
 	repos = portdb.settings.repositories
-	if --verbose in myopts:
-		append(Repositories:\n)
-		for repo in repos:
-			append(repo.info_string())
-	else:
-		append(Repositories: %s % \
-			 .join(repo.name for repo in repos))
+	append(Repositories:\n)
+	for repo in repos:
+		append(repo.info_string())
 
 	installed_sets = sorted(s for s in
 		root_config.sets['selected'].getNonAtoms() if s.startswith(SETPREFIX))
@@ -1732,8 +1728,8 @@ def action_info(settings, trees, myopts, myfiles):
 		myvars = list(settings)
 	else:
 		myvars = ['GENTOO_MIRRORS', 'CONFIG_PROTECT', 'CONFIG_PROTECT_MASK',
-		  'PORTDIR', 'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR',
-		  'PORTDIR_OVERLAY', 'PORTAGE_BUNZIP2_COMMAND',
+		  'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR',
+		  'PORTAGE_BUNZIP2_COMMAND',
 		  'PORTAGE_BZIP2_COMMAND',
 		  'USE', 'CHOST', 'CFLAGS', 'CXXFLAGS',
 		  'ACCEPT_KEYWORDS', 'ACCEPT_LICENSE', 'FEATURES',
@@ -1745,11 +1741,18 @@ def action_info(settings, trees, myopts, myfiles):
 		'PORTAGE_BZIP2_COMMAND' : 'bzip2',
 	}
 
-	myvars = portage.util.unique_array(myvars)
+	skipped_vars = ['PORTAGE_REPOSITORIES']
+	# Deprecated variables
+	skipped_vars.extend(('PORTDIR', 'PORTDIR_OVERLAY', 'SYNC'))
+
+	myvars = set(myvars)
+	myvars.difference_update(skipped_vars)
+	myvars = sorted(myvars)
+
 	use_expand = settings.get('USE_EXPAND', '').split()
 	use_expand.sort()
 	unset_vars = []
-	myvars.sort()
+
 	for k in myvars:
 		v = settings.get(k)
 		if v is not None:


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] emerge --info: Always print ::repository

2014-12-12 Thread Arfrever Frehtes Taifersar Arahesis
[[[
emerge --info: Always print ::repository.

1 call to deprecated portage.repository.config.RepoConfigLoader.mainRepo() 
function
has been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/_emerge/actions.py
+++ pym/_emerge/actions.py
@@ -42,7 +42,7 @@ from portage.const import GLOBAL_CONFIG_PATH, VCS_DIRS, _DEPCLEAN_LIB_CHECK_DEFA
 from portage.const import SUPPORTED_BINPKG_FORMATS, TIMESTAMP_FORMAT
 from portage.dbapi.dep_expand import dep_expand
 from portage.dbapi._expand_new_virt import expand_new_virt
-from portage.dep import Atom
+from portage.dep import Atom, _repo_separator, _slot_separator
 from portage.eclass_cache import hashed_path
 from portage.exception import InvalidAtom, InvalidData, ParseError
 from portage.output import blue, colorize, create_color_func, darkgreen, \
@@ -1668,9 +1668,6 @@ def action_info(settings, trees, myopts, myfiles):
 
 	myvars = sorted(set(atoms))
 
-	main_repo = portdb.repositories.mainRepo()
-	if main_repo is not None:
-		main_repo = main_repo.name
 	cp_map = {}
 	cp_max_len = 0
 
@@ -1692,12 +1689,10 @@ def action_info(settings, trees, myopts, myfiles):
 if len(matched_cp)  cp_max_len:
 	cp_max_len = len(matched_cp)
 repo = vardb.aux_get(cpv, [repository])[0]
-if repo == main_repo:
-	repo_suffix = 
-elif not repo:
-	repo_suffix = ::unknown repository
+if repo:
+	repo_suffix = _repo_separator + repo
 else:
-	repo_suffix = :: + repo
+	repo_suffix = _repo_separator + unknown repository
 
 if matched_cp == orig_atom.cp:
 	provide_suffix = 
@@ -1826,13 +1821,13 @@ def action_info(settings, trees, myopts, myfiles):
 
 			if pkg_type == installed:
 append(\n%s was built with the following: % \
-	colorize(INFORM, str(pkg.cpv)))
+	colorize(INFORM, str(pkg.cpv + _repo_separator + pkg.repo)))
 			elif pkg_type == ebuild:
-append(\n%s would be build with the following: % \
-	colorize(INFORM, str(pkg.cpv)))
+append(\n%s would be built with the following: % \
+	colorize(INFORM, str(pkg.cpv + _repo_separator + pkg.repo)))
 			elif pkg_type == binary:
 append(\n%s (non-installed binary) was built with the following: % \
-	colorize(INFORM, str(pkg.cpv)))
+	colorize(INFORM, str(pkg.cpv + _repo_separator + pkg.repo)))
 
 			append('%s' % pkg_use_display(pkg, myopts))
 			if pkg_type == installed:
@@ -2015,10 +2010,10 @@ def action_uninstall(settings, trees, ldpath_mtimes,
 		atom = = + atom + - + \
 			portage.versions.cpv_getversion(cpv)
 	if ext_atom.slot:
-		atom += : + ext_atom.slot
+		atom += _slot_separator + ext_atom.slot
 		require_metadata = True
 	if ext_atom.repo:
-		atom += :: + ext_atom.repo
+		atom += _repo_separator + ext_atom.repo
 		require_metadata = True
 
 	atom = Atom(atom, allow_repo=True)


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] Almost always print ::repository

2014-12-10 Thread Arfrever Frehtes Taifersar Arahesis
[[[
Almost always print ::repository in list of packages for installation.

--verbose-main-repo-display option is no longer supported.
3 calls to deprecated portage.repository.config.RepoConfigLoader.mainRepo() 
function
have been deleted.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- man/emerge.1
+++ man/emerge.1
@@ -897,9 +897,6 @@
 Make slot conflicts more verbose. Note that this may in some cases output
 hundreds of packages for slot conflicts.
 .TP
-.BR \-\-verbose\-main\-repo\-display
-In the package merge list display, print ::repository even for main repository.
-.TP
 .BR \-\-verbose\-slot\-rebuilds [ y | n ]
 Turns on/off the extra emerge output to list which packages are causing rebuilds.
 The default is set to y (on).
--- pym/_emerge/depgraph.py
+++ pym/_emerge/depgraph.py
@@ -4293,14 +4293,9 @@
 		child = None
 		all_parents = self._dynamic_config._parent_atoms
 		graph = self._dynamic_config.digraph
-		verbose_main_repo_display = --verbose-main-repo-display in \
-			self._frozen_config.myopts
 
 		def format_pkg(pkg):
-			pkg_name = %s % (pkg.cpv,)
-			if verbose_main_repo_display or pkg.repo != \
-pkg.root_config.settings.repositories.mainRepo().name:
-pkg_name += _repo_separator + pkg.repo
+			pkg_name = %s%s%s % (pkg.cpv, _repo_separator, pkg.repo)
 			return pkg_name
 
 		if target_atom is not None and isinstance(node, Package):
--- pym/_emerge/main.py
+++ pym/_emerge/main.py
@@ -50,7 +50,6 @@
 --tree,
 --unordered-display,
 --update,
---verbose-main-repo-display,
 ]
 
 shortmapping={
--- pym/_emerge/resolver/output.py
+++ pym/_emerge/resolver/output.py
@@ -387,9 +387,7 @@
 		if old_pkg.slot != old_pkg.sub_slot or \
 			old_pkg.slot == pkg.slot and old_pkg.sub_slot != pkg.sub_slot:
 			key += / + old_pkg.sub_slot
-	if not self.quiet_repo_display and (self.verbose_main_repo_display or
-		self.portdb.repositories.mainRepo() is None or
-		any(x.repo != self.portdb.repositories.mainRepo().name for x in myoldbest + [pkg])):
+	if not self.quiet_repo_display:
 		key += _repo_separator + old_pkg.repo
 versions.append(key)
 			myoldbest_str = blue([+, .join(versions)+])
@@ -422,9 +420,7 @@
 		@param pkg_info: dictionary
 		@rtype string
 		
-		if not self.quiet_repo_display and (self.verbose_main_repo_display or
-			self.portdb.repositories.mainRepo() is None or
-			any(x.repo != self.portdb.repositories.mainRepo().name for x in pkg_info.oldbest_list + [pkg])):
+		if not self.quiet_repo_display:
 			pkg_str += _repo_separator + pkg.repo
 		return pkg_str
 
@@ -819,7 +815,6 @@
 			# and disable the entire repo display in this case.
 			repoadd_set = set()
 
-		self.verbose_main_repo_display = --verbose-main-repo-display in depgraph._frozen_config.myopts
 		self.restrict_fetch_list = {}
 
 		for mylist_index in range(len(mylist)):


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] emerge --info: Modernize output of configuration of repositories

2014-12-09 Thread Arfrever Frehtes Taifersar Arahesis
2014-12-09 09:50 Alexander Berntsen napisał(a):
 On 08/12/14 20:04, Arfrever Frehtes Taifersar Arahesis wrote:
  +   for skipped_var in skipped_vars: +  try: +
  myvars.remove(skipped_var) +except ValueError: +
  pass +
 wat

It is deleting elements from a list.

 mylist = [ab, cd, ef]
 mylist
['ab', 'cd', 'ef']
 mylist.remove(cd)
 mylist
['ab', 'ef']
 mylist.remove(cd)
Traceback (most recent call last):
  File stdin, line 1, in module
ValueError: list.remove(x): x not in list


--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] Almost always print ::repository

2014-12-09 Thread Arfrever Frehtes Taifersar Arahesis
2014-12-09 09:30 Alexander Berntsen napisał(a):
 As for the patch itself: I like the idea, but where is this requested?

It is part of work for deleting any remaining uses of deprecated PORTDIR, 
PORTDIR_OVERLAY and SYNC variables,
mainRepo() and mainRepoLocation() functions, main-repo attribute.

 Also, I would prefer to remove the old option entirely.

OK.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] emerge --info: Modernize output of configuration of repositories

2014-12-08 Thread Arfrever Frehtes Taifersar Arahesis
[[[
emerge --info: Modernize output of configuration of repositories.

- Always print detailed configuration of repositories.
- Always skip PORTAGE_REPOSITORIES variable.
- Always skip deprecated PORTDIR, PORTDIR_OVERLAY and SYNC variables.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/_emerge/actions.py
+++ pym/_emerge/actions.py
@@ -1707,13 +1707,9 @@
 			((cp + :).ljust(cp_max_len + 1), versions))
 
 	repos = portdb.settings.repositories
-	if --verbose in myopts:
-		append(Repositories:\n)
-		for repo in repos:
-			append(repo.info_string())
-	else:
-		append(Repositories: %s % \
-			 .join(repo.name for repo in repos))
+	append(Repositories:\n)
+	for repo in repos:
+		append(repo.info_string())
 
 	installed_sets = sorted(s for s in
 		root_config.sets['selected'].getNonAtoms() if s.startswith(SETPREFIX))
@@ -1726,8 +1722,8 @@
 		myvars = list(settings)
 	else:
 		myvars = ['GENTOO_MIRRORS', 'CONFIG_PROTECT', 'CONFIG_PROTECT_MASK',
-		  'PORTDIR', 'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR',
-		  'PORTDIR_OVERLAY', 'PORTAGE_BUNZIP2_COMMAND',
+		  'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR',
+		  'PORTAGE_BUNZIP2_COMMAND',
 		  'PORTAGE_BZIP2_COMMAND',
 		  'USE', 'CHOST', 'CFLAGS', 'CXXFLAGS',
 		  'ACCEPT_KEYWORDS', 'ACCEPT_LICENSE', 'FEATURES',
@@ -1735,6 +1731,16 @@
 
 		myvars.extend(portage.util.grabfile(settings[PORTDIR]+/profiles/info_vars))
 
+	skipped_vars = ['PORTAGE_REPOSITORIES', '_']
+	# Deprecated variables
+	skipped_vars.extend(('PORTDIR', 'PORTDIR_OVERLAY', 'SYNC'))
+
+	for skipped_var in skipped_vars:
+		try:
+			myvars.remove(skipped_var)
+		except ValueError:
+			pass
+
 	myvars_ignore_defaults = {
 		'PORTAGE_BZIP2_COMMAND' : 'bzip2',
 	}


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] [PATCH] Sort PORTAGE_ARCHLIST

2014-12-08 Thread Arfrever Frehtes Taifersar Arahesis
Currently PORTAGE_ARCHLIST has random value:
$ bin/portageq envvar PORTAGE_ARCHLIST
x64-macos x86-linux amd64-fbsd ppc x86 x86-macos x86-winnt hppa alpha 
sparc64-solaris x86-freebsd ppc-openbsd x86-solaris s390 m68k mips ppc64-linux 
ia64-linux x64-openbsd amd64-linux x86-cygwin amd64 sparc64-freebsd ppc64 
ia64-hpux sparc-solaris ia64 ppc-macos x86-interix x86-openbsd arm arm64 
hppa-hpux arm-linux sparc x64-solaris m68k-mint sh x86-netbsd sparc-fbsd 
ppc-aix x86-fbsd x64-freebsd
$ bin/portageq envvar PORTAGE_ARCHLIST
arm-linux sparc64-solaris x86-openbsd ppc64-linux ppc-macos x64-macos 
sparc-solaris ppc mips hppa-hpux ppc-aix x86-linux sparc x86-macos x86 
ia64-hpux x86-fbsd arm64 x64-freebsd ppc64 amd64 x86-winnt alpha x86-freebsd sh 
x86-solaris sparc64-freebsd m68k amd64-fbsd s390 x64-openbsd ia64 x86-netbsd 
amd64-linux ppc-openbsd arm x86-interix ia64-linux x64-solaris sparc-fbsd hppa 
m68k-mint x86-cygwin
$ bin/portageq envvar PORTAGE_ARCHLIST
x86-netbsd x86-solaris x86-winnt x64-solaris amd64 x86-fbsd x86-interix 
m68k-mint x64-macos arm64 hppa x86-freebsd amd64-fbsd m68k x86-openbsd ppc 
sparc x64-freebsd ppc-aix ia64 x86 sparc-solaris x86-macos arm ppc-openbsd 
alpha sh mips ppc64 sparc64-solaris sparc-fbsd ppc64-linux ia64-linux 
sparc64-freebsd arm-linux hppa-hpux amd64-linux s390 x64-openbsd ia64-hpux 
x86-linux x86-cygwin ppc-macos
$ bin/portageq envvar PORTAGE_ARCHLIST
sparc64-solaris arm-linux x86-openbsd x86-macos ia64-linux x86-fbsd ppc64-linux 
hppa amd64 x64-macos ia64-hpux hppa-hpux ia64 sparc-solaris sparc-fbsd 
amd64-fbsd alpha mips x86-cygwin x86-interix ppc64 amd64-linux x86-freebsd m68k 
s390 ppc-openbsd x64-freebsd ppc-macos sparc64-freebsd arm ppc-aix x86-netbsd 
x86-solaris x64-openbsd x86-winnt sparc x86-linux m68k-mint x64-solaris sh x86 
ppc arm64

I suggest to make it predictable.

[[[
Sort PORTAGE_ARCHLIST.
]]]

--
Arfrever Frehtes Taifersar Arahesis
--- pym/portage/package/ebuild/config.py
+++ pym/portage/package/ebuild/config.py
@@ -779,7 +779,7 @@
 
 			archlist = [grabfile(os.path.join(x, arch.list)) \
 for x in locations_manager.profile_and_user_locations]
-			archlist = stack_lists(archlist, incremental=1)
+			archlist = sorted(stack_lists(archlist, incremental=1))
 			self.configdict[conf][PORTAGE_ARCHLIST] =  .join(archlist)
 
 			pkgprovidedlines = [grabfile(


signature.asc
Description: This is a digitally signed message part.


[gentoo-portage-dev] Support for per-repository per-attribute environmental variables

2014-12-08 Thread Arfrever Frehtes Taifersar Arahesis
I suggest to add support for per-repository per-attribute environmental 
variables in Portage.
These variables would be used when PORTAGE_REPOSITORIES is not set.

Example of setting of them by user and detection of them by Portage:

$ env \
 PORTAGE_REPOSITORY:gentoo:location=/var/db/repositories/gentoo-cvs \
 PORTAGE_REPOSITORY:gentoo:sync-type=cvs \
 PORTAGE_REPOSITORY:gentoo:sync-uri=:pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot
  \
 python -c 'import os, pprint; pprint.pprint([x for x in os.environ.items() if 
 x[0].startswith(PORTAGE_REPOSITORY:)])'
[('PORTAGE_REPOSITORY:gentoo:sync-type', 'cvs'),
 ('PORTAGE_REPOSITORY:gentoo:location', '/var/db/repositories/gentoo-cvs'),
 ('PORTAGE_REPOSITORY:gentoo:sync-uri',
  ':pserver:anonym...@anoncvs.gentoo.org:/var/cvsroot')]

A separator between components of names of these variables cannot be any 
character valid in names of repositories.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] sync: allow overriding sync-user for the repository

2014-12-07 Thread Arfrever Frehtes Taifersar Arahesis
I would suggest to have a separate sync-group attribute and to support only 
user in sync-user attribute.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] Apply 'nonfatal' to helpers only

2014-08-18 Thread Arfrever Frehtes Taifersar Arahesis
2014-08-18 11:02 Michał Górny napisał(a):
 Make 'nonfatal' modifier affect helpers only rather than disabling 'die'
 completely. This improves the PMS conformance.

It is better to leave current code, until there is replacement functionality.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] don't rely on dynamic deps

2014-07-27 Thread Arfrever Frehtes Taifersar Arahesis
2014-07-27 23:33 Ciaran McCreesh napisał(a):
 On Sun, 27 Jul 2014 17:26:27 -0400
 Rich Freeman ri...@gentoo.org wrote:
  But, in that case you can put the necessary ebuilds into your overlay
  and then portage can make everything right.
 
 Oh? Please explain to us a) how the overlay interaction *actually* works
 with dynamic dependencies currently

Portage uses dynamic dependencies from ebuild in original repository of given 
installed ebuild.
Name of repository is stored in /var/db/pkg/${CATEGORY}/${PF}/repository file.

 and b) how it can work both in the case you describe

A user would have to do:
# echo ${new_repository}  /var/db/pkg/${CATEGORY}/${PF}/repository
# touch /var/db/pkg/${CATEGORY}/${PF}
# touch /var/db/pkg/${CATEGORY}
# touch /var/db/pkg

(It is possible that updating of timestamps is not yet strictly required...)

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] Helping out

2014-01-07 Thread Arfrever Frehtes Taifersar Arahesis
2014-01-06 21:46 Jesus Rivero (Neurogeek) napisał(a):
 Let me know what do you need from me.

You can help in porting various functions to not use deprecated objects.
Examples:
  PORTDIR   (when used as internal config variable)
  PORTDIR_OVERLAY   (when used as internal config variable)
  mainRepo  (outside pym/portage/repository/config.py)
  mainRepoLocation  (outside pym/portage/repository/config.py)
  porttree_root

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] make.conf.5: Document PYTHON_TARGETS, bug #493180

2013-12-03 Thread Arfrever Frehtes Taifersar Arahesis
Portage's documentation is inappropriate place for this.
Please do not commit this patch.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] Further document repos.conf

2013-12-02 Thread Arfrever Frehtes Taifersar Arahesis
2013-12-02 01:28 Alexander Berntsen napisał(a):
 Another trivial one. Fixes bug #491426.

Wrong section (/etc/portage/make.profile/ or /etc/make.profile/ instead of 
/etc/portage/). I will fix it.

When changing a manual, please remember to update date in first line in manual.

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] xattr: centralize the various shims in one place

2013-10-22 Thread Arfrever Frehtes Taifersar Arahesis
2013-10-21 05:00 Mike Frysinger napisał(a):
 On Wednesday 16 October 2013 23:42:26 Arfrever Frehtes Taifersar wrote:
  - cStringIO module should not be used. io module is a replacement available
  since Python 2.6.
 
 unfortunately, that doesn't work as well as it should.  python 2.7's 
 interface 
 is annoyingly different when using other python 2.7 modules.  i'll have the 
 code import the old module and then fallback to using the new io module.

(io.StringIO works only with unicode strings.
When bytes-compatible functions are really needed, then io.BytesIO can be used, 
which works only with bytes.
cStringIO.StringIO is designed to work with bytes, but 
cStringIO.StringIO().write(instance_of_unicode)
implicitly encodes its argument to bytes.)

In your another patch, 
portage.tests.bin.test_prepstrip.PrepStripFull._prepstrip() passes an instance 
of
cStringIO.StringIO class to portage.bin.prepstrip.main(), which passes it to 
portage.bin.prepstrip.Prepstrip(),
which passes it to print(), portage.elog.messages.eqawarn() and 
portage.elog.messages.ewarn().

pym/portage/bin/prepstrip.py should have:
from __future__ import unicode_literals

Then print('...', file=out) calls will work with an instance of io.StringIO 
class.

(portage.elog.messages.eqawarn() and portage.elog.messages.ewarn() internally 
decode message,
so they already work with out=io.StringIO, but not out=io.BytesIO.)

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH v2] xattr: centralize the various shims in one place

2013-10-22 Thread Arfrever Frehtes Taifersar Arahesis
:
 - if exclude is not None and isinstance(attrs[0], 
 bytes):
 - exclude = 
 exclude.encode(_encodings['fs'])
 - exclude = _get_xattr_excluder(exclude)
 + if attrs:
 + if exclude is not None and isinstance(attrs[0], bytes):
 + exclude = exclude.encode(_encodings['fs'])
 + exclude = _get_xattr_excluder(exclude)
  
 - for attr in attrs:
 - if exclude(attr):
 - continue
 - try:
 - xattr.set(dest, attr, xattr.get(src, 
 attr))
 - raise_exception = False
 - except IOError:
 - raise_exception = True
 - if raise_exception:
 - raise 
 OperationNotSupported(_(Filesystem containing file '%s' 
 - does not support extended 
 attribute '%s') %
 - (_unicode_decode(dest), 
 _unicode_decode(attr)))
 - else:
 + for attr in attrs:
 + if exclude(attr):
 + continue
   try:
 - with open(_os.devnull, 'wb') as f:
 - subprocess.call([getfattr, --version], 
 stdout=f)
 - subprocess.call([setfattr, --version], 
 stdout=f)
 - except OSError:
 - def _copyxattr(src, dest, exclude=None):
 - # TODO: implement exclude
 - getfattr_process = 
 subprocess.Popen([getfattr, -d, --absolute-names, src], 
 stdout=subprocess.PIPE)
 - getfattr_process.wait()
 - extended_attributes = 
 getfattr_process.stdout.readlines()
 - getfattr_process.stdout.close()
 - if extended_attributes:
 - extended_attributes[0] = b# file:  + 
 _unicode_encode(dest) + b\n
 - setfattr_process = 
 subprocess.Popen([setfattr, --restore=-], stdin=subprocess.PIPE, 
 stderr=subprocess.PIPE)
 - 
 setfattr_process.communicate(input=b.join(extended_attributes))
 - if setfattr_process.returncode != 0:
 - raise 
 OperationNotSupported(Filesystem containing file '%s' does not support 
 extended attributes % dest)
 - else:
 - def _copyxattr(src, dest, exclude=None):
 - pass
 + xattr.set(dest, attr, xattr.get(src, attr))
 + raise_exception = False
 + except (OSError, IOError):
 + raise_exception = True
 + if raise_exception:
 + raise OperationNotSupported(_(Filesystem containing 
 file '%s' 
 + does not support extended attribute '%s') %
 + (_unicode_decode(dest), _unicode_decode(attr)))
  
  def movefile(src, dest, newmtime=None, sstat=None, mysettings=None,
   hardlink_candidates=None, encoding=_encodings['fs']):
 

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] xattr: centralize the various shims in one place

2013-10-16 Thread Arfrever Frehtes Taifersar Arahesis
 - if raise_exception:
 - raise OperationNotSupported(_(Filesystem 
 containing file '%s' 
 - does not support extended attribute 
 '%s') %
 - (_unicode_decode(dest), 
 _unicode_decode(attr)))
 -else:
 +def _copyxattr(src, dest, exclude=None):
 + Copy the extended attributes from |src| to |dest|
   try:
 - import xattr
 - except ImportError:
 - xattr = None
 - if xattr is not None:
 - def _copyxattr(src, dest, exclude=None):
 -
 - try:
 - attrs = xattr.list(src)
 - except IOError as e:
 - if e.errno != OperationNotSupported.errno:
 - raise
 - attrs = ()
 + attrs = xattr.list(src)
 + except (OSError, IOError) as e:
 + if e.errno != OperationNotSupported.errno:
 + raise
 + attrs = ()
  
 - if attrs:
 - if exclude is not None and isinstance(attrs[0], 
 bytes):
 - exclude = 
 exclude.encode(_encodings['fs'])
 - exclude = _get_xattr_excluder(exclude)
 + if attrs:
 + if exclude is not None and isinstance(attrs[0], bytes):
 + exclude = exclude.encode(_encodings['fs'])
 + exclude = _get_xattr_excluder(exclude)
  
 - for attr in attrs:
 - if exclude(attr):
 - continue
 - try:
 - xattr.set(dest, attr, xattr.get(src, 
 attr))
 - raise_exception = False
 - except IOError:
 - raise_exception = True
 - if raise_exception:
 - raise 
 OperationNotSupported(_(Filesystem containing file '%s' 
 - does not support extended 
 attribute '%s') %
 - (_unicode_decode(dest), 
 _unicode_decode(attr)))
 - else:
 + for attr in attrs:
 + if exclude(attr):
 + continue
   try:
 - with open(os.devnull, 'wb') as f:
 - subprocess.call([getfattr, --version], 
 stdout=f)
 - subprocess.call([setfattr, --version], 
 stdout=f)
 - except OSError:
 - def _copyxattr(src, dest, exclude=None):
 - # TODO: implement exclude
 - getfattr_process = 
 subprocess.Popen([getfattr, -d, --absolute-names, src], 
 stdout=subprocess.PIPE)
 - getfattr_process.wait()
 - extended_attributes = 
 getfattr_process.stdout.readlines()
 - getfattr_process.stdout.close()
 - if extended_attributes:
 - extended_attributes[0] = b# file:  + 
 _unicode_encode(dest) + b\n
 - setfattr_process = 
 subprocess.Popen([setfattr, --restore=-], stdin=subprocess.PIPE, 
 stderr=subprocess.PIPE)
 - 
 setfattr_process.communicate(input=b.join(extended_attributes))
 - if setfattr_process.returncode != 0:
 - raise 
 OperationNotSupported(Filesystem containing file '%s' does not support 
 extended attributes % dest)
 - else:
 - def _copyxattr(src, dest, exclude=None):
 - pass
 + xattr.set(dest, attr, xattr.get(src, attr))
 + raise_exception = False
 + except (OSError, IOError) as e:

Unused variable e

 + raise_exception = True
 + if raise_exception:
 + raise OperationNotSupported(_(Filesystem containing 
 file '%s' 
 + does not support extended attribute '%s') %
 + (_unicode_decode(dest), _unicode_decode(attr)))
  
  def movefile(src, dest, newmtime=None, sstat=None, mysettings=None,
   hardlink_candidates=None, encoding=_encodings['fs']):
 

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-portage-dev] [PATCH] xattr: centralize the various shims in one place

2013-10-16 Thread Arfrever Frehtes Taifersar Arahesis
2013-10-17 04:53 Mike Frysinger napisał(a):
 On Wednesday 16 October 2013 22:51:17 Mike Frysinger wrote:
  On Wednesday 16 October 2013 20:02:50 Arfrever Frehtes Taifersar Arahesis
  
  wrote:
   2013-10-16 23:03 Mike Frysinger napisał(a):
Rather than each module implementing its own shim around the various
methods for accessing extended attributes, start a dedicated module
that exports a consistent API.
   
   Some things are incompatible with Python 3.
   See other comments below.
  
  i can run a linter on the code (probably should make this a git hook).  i'm
  interested more in review on the bigger picture.
 
 also, none of your comments were py3 issues that i saw

I said other comments, so I meant comments not related to incompatibility 
with Python 3.

About incompatibility with Python 3:
- subprocess.check_output(), subprocess.Popen().stdout.read(), 
subprocess.Popen().stderr.read() return
  bytes, which is incorrectly compared with str in your patches.
- dict.iteritems() was renamed to dict.items() (and its return type was changed 
from dictionary-itemiterator
  to dict_items, but it does not matter here).
- Queue module was renamed to queue.
- cStringIO module should not be used. io module is a replacement available 
since Python 2.6.
- Maybe other problems...

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots

2013-09-26 Thread Arfrever Frehtes Taifersar Arahesis
2013-09-26 17:04 Michael Palimaka napisał(a):
 What about when the subslot of boost was equal to ${PV}? Was it really a 
 good idea to make everyone rebuild half their system for a bugfix 
 release, without even checking if the ABI changed?

It is wrong example due to 2 reasons:
1. Subslot of dev-libs/boost::gentoo was never equal to ${PV}.
2. Sonames of Boost libraries actually include full ${PV}, so rebuilding of 
reverse dependencies
   would be necessary after upgrade from Boost 1.54.0 to hypothetical 1.54.1.

Although upstream rarely releases X.Y.Z with Z != 0 (last was 1.46.1).
http://www.boost.org/users/history/

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Marking of deprecated USE flags

2013-08-09 Thread Arfrever Frehtes Taifersar Arahesis
Some people want that repoman print warnings for ebuilds, whose effective IUSE 
contains deprecated
USE flags (e.g. USE flags corresponding to old versions of Python/Ruby). I 
suggest that deprecation
of USE flags be specified by  (DEPRECATED) suffix in descriptions of given 
flags in profiles/use.desc
and profiles/desc/*.desc files.

Any opinions about syntax?

Example:

Index: profiles/desc/python_single_target.desc
===
RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_single_target.desc,v
retrieving revision 1.5
diff -u -r1.5 python_single_target.desc
--- profiles/desc/python_single_target.desc 5 Aug 2013 14:20:47 -   
1.5
+++ profiles/desc/python_single_target.desc 9 Aug 2013 16:27:37 -
@@ -4,14 +4,14 @@
 
 # This file contains descriptions of PYTHON_SINGLE_TARGET USE_EXPAND flags.
 
-python2_5 - Build for Python 2.5 only
+python2_5 - Build for Python 2.5 only (DEPRECATED)
 python2_6 - Build for Python 2.6 only
 python2_7 - Build for Python 2.7 only
-python3_1 - Build for Python 3.1 only
+python3_1 - Build for Python 3.1 only (DEPRECATED)
 python3_2 - Build for Python 3.2 only
 python3_3 - Build for Python 3.3 only
-jython2_5 - Build for Jython 2.5 only
+jython2_5 - Build for Jython 2.5 only (DEPRECATED)
 jython2_7 - Build for Jython 2.7 only
-pypy1_9 - Build for PyPy 1.9 only
+pypy1_9 - Build for PyPy 1.9 only (DEPRECATED)
 pypy2_0 - Build for PyPy 2.0 only
 pypy2_1 - Build for PyPy 2.1 only
Index: profiles/desc/python_targets.desc
===
RCS file: /var/cvsroot/gentoo-x86/profiles/desc/python_targets.desc,v
retrieving revision 1.9
diff -u -r1.9 python_targets.desc
--- profiles/desc/python_targets.desc   5 Aug 2013 14:20:47 -   1.9
+++ profiles/desc/python_targets.desc   9 Aug 2013 16:27:37 -
@@ -4,15 +4,15 @@
 
 # This file contains descriptions of PYTHON_TARGETS USE_EXPAND flags.
 
-python2_5 - Build with Python 2.5
+python2_5 - Build with Python 2.5 (DEPRECATED)
 python2_6 - Build with Python 2.6
 python2_7 - Build with Python 2.7
-python3_1 - Build with Python 3.1
+python3_1 - Build with Python 3.1 (DEPRECATED)
 python3_2 - Build with Python 3.2
 python3_3 - Build with Python 3.3
 python3_4 - Build with Python 3.4
-jython2_5 - Build with Jython 2.5
+jython2_5 - Build with Jython 2.5 (DEPRECATED)
 jython2_7 - Build with Jython 2.7
-pypy1_9 - Build with PyPy 1.9
+pypy1_9 - Build with PyPy 1.9 (DEPRECATED)
 pypy2_0 - Build with PyPy 2.0
 pypy2_1 - Build with PyPy 2.1
Index: profiles/desc/ruby_targets.desc
===
RCS file: /var/cvsroot/gentoo-x86/profiles/desc/ruby_targets.desc,v
retrieving revision 1.3
diff -u -r1.3 ruby_targets.desc
--- profiles/desc/ruby_targets.desc 23 Jun 2013 12:31:14 -  1.3
+++ profiles/desc/ruby_targets.desc 9 Aug 2013 16:27:37 -
@@ -6,7 +6,7 @@
 
 rbx - Build with Rubinius
 jruby - Build with JRuby
-ree18 - Build with Ruby Enterprise Edition 1.8.x
+ree18 - Build with Ruby Enterprise Edition 1.8.x (DEPRECATED)
 ruby18 - Build with MRI Ruby 1.8.x
 ruby19 - Build with MRI Ruby 1.9.x
 ruby20 - Build with MRI Ruby 2.0.x

--
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] SRC_URI behaviour

2013-06-16 Thread Arfrever Frehtes Taifersar Arahesis
2013-06-15 17:51 Rich Freeman napisał(a):
 Plus, right now with Gentoo there is no way to set an overlay as being LOWER
 priority than the main tree - so that you can grab packages not supported in
 main from an overlay but still use the main packages when available.

Portage has been supporting setting of priority in /etc/portage/repos.conf for 
about 2.7 years.

$ cat /etc/portage/repos.conf
[name_of_overlay]
priority = -1001

(`emerge --info -v` shows repositories with their priorities.)

--
Arfrever Frehtes Taifersar Arahesis



Re: [gentoo-portage-dev] A way to prevent useless rebuild?

2013-01-20 Thread Arfrever Frehtes Taifersar Arahesis
2013-01-20 13:22:42 Pacho Ramos napisał(a):
 I noticed go USE flag was masked on gcc:4.6, the problem is that I
 just compiled it a week ago with USE=-go... then, I would like to know
 if there is a way to prevent it from being rebuild again :| (It will
 take some time in my currently running system but on other machines I
 maintain it will take hours)

sed -e s/\(^\| \)go\($\| \)/\1\2/;s/^ //;s/  / /g;s/ $// -i 
/var/db/pkg/sys-devel/gcc-4.6.3/IUSE
touch /var/db/pkg/sys-devel/gcc-4.6.3
touch /var/db/pkg/sys-devel
touch /var/db/pkg

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Dropping slotted boost

2012-10-30 Thread Arfrever Frehtes Taifersar Arahesis
2012-10-30 19:30:16 Diego Elio Pettenò napisał(a):
 Given the amount of headaches that Boost seems to give us all, now
 thanks to the recent changes even more because Gentoo's boost is
 different from all others and no upstream default check seem to work
 correctly with it, I'm questioning the usefulness of having it slotted.
 
 Among other things, with each GCC/GLIBC update all but a handful of
 slots are kept working; in this case I think most if not all 1.50 are
 broken.
 
 So given that it's a PITA for the maintainers, a PITA for the users,
 eselect boost has been shown to be a bad idea and so on ... can we just
 go back to just install it and that's about it?

I think that slotting is needed, but pkg_postinst() could create (without using 
`eselect boost`) symlinks like /usr/include/boost etc.
It is possible that a package works with e.g. Boost 1.50, but not 1.51, so it 
could use boost-utils.eclass with BOOST_MAX_SLOT set to 1.50.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Maintainer needed: dev-libs/icu

2012-10-30 Thread Arfrever Frehtes Taifersar Arahesis
2012-10-29 23:07:15 Diego Elio Pettenò napisał(a):
 c) try to get betas and rcs in asap _but masked_;

=sys-devel/gcc-4.7.0, whose usage is required to trigger some problems, is 
already package.masked.

 d) call for a tinderbox run (I can do that with a quick email);

One of major problems with this tinderbox is that it cannot be used to test 
packages against newer versions of packages
present in overlays [1], but it can be very useful. E.g. before release of 
Python 3.3.0 I had tested about 200 packages
against snapshots of Python 3.3 found in an overlay. Besides founding problems 
in about 10% of packages, I also found
some regressions in Python 3.3 [2], which were later fixed before final release 
of Python 3.3.0.

 In this case all should have stopped at a) since libreoffice-bin has a
 =49* dep, for obvious reasons.
 
 Since there was no hurry of security issues to get icu-50 in, I don't
 see why this was all forced through -50_rc without giving time to the
 _one_ package that was using an older version to update.

Maintainers of app-office/libreoffice-bin always build it against stable 
versions of its dependencies,
so maintainers of app-office/libreoffice-bin can be asked to build it against 
ICU 50 after stabilization of ICU 50.

[1] http://blog.flameeyes.eu/2010/08/fixed-in-overlay-read-not-fixed
[2] http://bugs.python.org/issue15925
http://bugs.python.org/issue15926

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Maintainer needed: dev-libs/icu

2012-10-30 Thread Arfrever Frehtes Taifersar Arahesis
2012-10-31 04:18:14 Arfrever Frehtes Taifersar Arahesis napisał(a):
 Besides founding problems in about 10% of packages

s/founding/finding/

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Maintainer needed: dev-libs/icu

2012-10-28 Thread Arfrever Frehtes Taifersar Arahesis
2012-10-28 22:14:15 Mike Gilbert napisał(a):
 This library is used for processing Unicode text in several high-profile
 packages, including Chromium and other Webkit browsers, PHP, boost, and
 many more.
 
 Fair warning: ICU tends to break several packages with every major
 release, so thorough testing is needed when bumping it.
 
 This package is currently being maintained by proxy by a former Gentoo
 developer, Arfrever. Given this package's potential to cause problems,
 this situation is not ideal.
 
 It would be really great if an active Gentoo developer would step
 forward and take care of this one.

I am actively maintaining ICU and test many reverse dependencies with new 
versions of ICU
(using a not package.masked version of GCC).

Members of proxy-maintainers team or others actively commit fixes/updates, so 
there
is no need to change current situation.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] About disabling DISABLE_DEPRECATED

2012-10-07 Thread Arfrever Frehtes Taifersar Arahesis
2012-10-03 04:57:10 Mike Frysinger napisał(a):
 On Sunday 30 September 2012 17:44:05 Gilles Dartiguelongue wrote:
  +   if ! grep -qE (DISABLE_DEPRECATED|GSEAL_ENABLE) 
  ${makefile}; then
 
 `grep -E` - `egrep`

'man grep' says:
egrep is the same as grep -E. fgrep is the same as grep -F. Direct invocation 
as either egrep or fgrep is deprecated,
but is provided to allow historical applications that rely on them to run 
unmodified.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

2012-09-17 Thread Arfrever Frehtes Taifersar Arahesis
A potential dev-libs/dep package might have valid use case for USE flags 
related to USE_EXPAND=DEP.
Your suggested syntax for types of dependencies in DEPENDENCIES would conflict 
with these USE flags
after implementing : delimiter for USE_EXPAND-related USE flags.

I vote for a separate syntax for types of dependencies.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

2012-09-09 Thread Arfrever Frehtes Taifersar Arahesis
2012-09-09 10:06:43 Michał Górny napisał(a):
 No, we don't support older versions.

Older versions must be supported to easily handle the situation when Boost 1.49 
is stable and
Boost 1.50 and 1.51 are unstable and not package.masked and package X has only 
stable ebuilds
and all of them currently fail to build/work with Boost =1.51, so 
BOOST_MAX_VERSION=1.50 would
have to be used in all ebuilds of package X.
(Boost 1.49 would be used for stable users and Boost 1.50 would be used for 
unstable users.)

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

2012-09-08 Thread Arfrever Frehtes Taifersar Arahesis
2012-09-04 22:50:16 Michał Górny napisał(a):
 + local slot=${1:-${BOOST_MAX_VERSION:-$(boost-utils_get_best_slot)}}

When BOOST_MAX_VERSION is non-empty, then it should be used in the following 
way:

  [[ ${BOOST_MAX_VERSION} =~ ^[[:digit:]]+\.[[:digit:]]+$ ]] || die Invalid 
BOOST_MAX_VERSION
  atom=$(best_version 
dev-libs/boost-${BOOST_MAX_VERSION%.*}.$((${BOOST_MAX_VERSION#*.}+1))_alpha)
  slot=$(get_version_component_range 1-2 ${atom#dev-libs/boost-})

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

2012-08-27 Thread Arfrever Frehtes Taifersar Arahesis
2012-08-28 00:19:28 Michał Górny napisał(a):
 --- /dev/null
 +++ b/gx86/eclass/boost-utils.eclass
 @@ -0,0 +1,43 @@
 +# Copyright 1999-2012 Gentoo Foundation
 +# Distributed under the terms of the GNU General Public License v2
 +# $Header: $
 +
 +if [[ ! ${_BOOST_ECLASS} ]]; then
 +
 +# @ECLASS: boost-utils.eclass
 +# @MAINTAINER:
 +# mgo...@gentoo.org

It is better to copy list of maintainers from 
gentoo-x86/dev-libs/boost/metadata.xml.

 +# @BLURB: helper functions for packages using Boost C++ library
 +# @DESCRIPTION:
 +# Helper functions to be used when building packages using the Boost C++
 +# library collection.
 +
 +case ${EAPI:-0} in
 + 0|1|2|3|4) ;;
 + *) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
 +esac

Please accept all EAPIs.

 +inherit versionator
 +
 +# @FUNCTION: boost-utils_get_best_slot
 +# @DESCRIPTION:
 +# Get newest SLOT (major version) of Boost.
 +boost-utils_get_best_slot() {
 + local pkg=dev-libs/boost
 + local atom=$(best_version ${pkg})
 + get_version_component_range 1-2 ${atom#${pkg}}
 +}
 +
 +# @FUNCTION: boost-utils_get_includedir
 +# @DESCRIPTION:
 +# Get correct includedir for best Boost version. Outputs the sole path
 +# (without -I).
 +boost-utils_get_includedir() {
 + local slot=$(boost-utils_get_best_slot)
 + has ${EAPI:-0} 0 1 2  ! use prefix  EPREFIX=
 +
 + echo -n ${EPREFIX}/usr/include/boost-${slot/./_}
 +}

There needs to be a way to specify maximal accepted slot of Boost. Examples of 
some possibilities:
* BOOST_MAX_SLOT=1.49 global variable
* '--max 1.49' arguments for boost-utils_get_* functions

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] autotools.eclass no longer inherits eutils; check your ebuilds!

2012-05-21 Thread Arfrever Frehtes Taifersar Arahesis
2012-05-22 01:01:04 Francesco Riosa napisał(a):
 2012/5/22 Mike Frysinger vap...@gentoo.org:
  On Monday 21 May 2012 18:16:25 Markos Chandras wrote:
  Excuse me but the way this change was handled is a bit depressing.
  First, the ebuilds should have been fixed to inherit eutils and then
  remove eutils from autotools. Now, a bunch of ebuilds are broken out
  of nowhere. I don't believe this issue was that urgent in order to
  justify the significant breakage of portage tree.
 
  you're assuming the breakage was intentional.  i also wouldn't really 
  describe
  it as significant, but that's just quibbling over an insignificant aspect.
 
 It's intentional not to revert the change, it's significant because it
 involve a number of significant packages like icu, vim and boost

These packages are not involved:

dev-libs/icu ebuilds do not inherit autotools.eclass.
An older ebuild (icu-4.8.1.1-r1.ebuild) inherits eutils.eclass only through 
versionator.eclass.

app-editors/vim ebuilds do not inherit autotools.eclass, and inherit vim.eclass,
which inherits eutils.eclass.

dev-libs/boost ebuilds do not inherit autotools.eclass, and inherit 
check-reqs.eclass,
flag-o-matic.eclass and versionator.eclass, which inherit eutils.eclass.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

2012-05-14 Thread Arfrever Frehtes Taifersar Arahesis
2012-05-14 06:58:30 Duncan napisał(a):
 Ulrich Mueller posted on Sat, 12 May 2012 20:39:05 +0200 as excerpted:
 
  On Sat, 12 May 2012, Michał Górny wrote:
  
  EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
  variable for users who need to pass something specific to make.
  
  You are right, of course.
 
  I guess the following ebuilds should be fixed then:
  
 eclass/bsdmk.eclass
 eclass/python.eclass
 eclass/scons-utils.eclass
 dev-db/redis/redis-2.2.12.ebuild
 dev-db/redis/redis-2.4.4-r1.ebuild
 dev-db/redis/redis-2.4.7.ebuild
 dev-db/redis/redis-2.4.8.ebuild
 dev-db/redis/redis-2.4.10.ebuild
 dev-db/redis/redis-2.4.13.ebuild
 gnome-base/gconf/gconf-2.32.4.ebuild
 net-misc/mico/mico-2.3.13-r5.ebuild
 sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild
 sys-fs/udev/udev-171-r5.ebuild
 
 Ouch, in eclasses too!

All matches in eclasses and some matches in ebuilds are false positives.

-- 
Arfrever Frehtes Taifersar Arahesis



Re: [gentoo-dev] add global useflag: webkit

2012-05-06 Thread Arfrever Frehtes Taifersar Arahesis
2012-05-06 02:34:26 hasufell napisał(a):
 # grep :webkit use.local.desc | wc -l
 33
 
 I would vote to make this a global useflag:
 
 webkit - Adds support for the webkit library/module

I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk USE flags.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] add global useflag: webkit

2012-05-06 Thread Arfrever Frehtes Taifersar Arahesis
2012-05-07 03:00:31 hasufell napisał(a):
 On 05/07/2012 02:47 AM, Arfrever Frehtes Taifersar Arahesis wrote:
  2012-05-06 02:34:26 hasufell napisał(a):
  # grep :webkit use.local.desc | wc -l 33
  
  I would vote to make this a global useflag:
  
  webkit - Adds support for the webkit library/module
  
  I suggest to use separate qt-webkit (or webkit-qt) and webkit-gtk
  USE flags.
  
 
 You mean that for example KDE users who set +webkit in make.conf would
 possibly get some weird gtk-deps too?

16 packages have webkit USE flag, which enables dependency on 
net-libs/webkit-gtk:
app-misc/gramps
app-office/gnucash
app-pda/gtkpod
app-text/xiphos
dev-java/swt
dev-util/geany-plugins
dev-util/mono-tools
gnome-extra/avant-window-navigator-extras
gnome-extra/zenity
mail-client/balsa
media-gfx/gimp
media-sound/gmusicbrowser
media-sound/gpodder
media-sound/rhythmbox
net-im/empathy
x11-misc/google-gadgets

15 packages have webkit USE flag, which enables dependency on 
x11-libs/qt-webkit:
dev-python/PyQt4
dev-python/pyside
kde-base/kget
kde-base/perlqt
kde-base/qtruby
kde-base/qyoto
kde-base/smokeqt
net-im/psi
net-im/qutim
net-irc/quassel
sci-chemistry/ball
sci-geosciences/merkaartor
x11-libs/qt-assistant
x11-libs/qt-declarative
x11-libs/qt-demo

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Fix spurious dep to eselect-python

2012-03-20 Thread Arfrever Frehtes Taifersar Arahesis
2012-03-20 05:29:20 Luca Barbato napisał(a):
 Hi, I tried to avoid depending on eselect-python if the useflag is disabled.
 
 Please test and review.

The proper fix is to make python.eclass add dependency on 
app-admin/eselect-python only when
${CATEGORY}/${PN} is dev-lang/python, dev-java/jython or dev-python/pypy. See 
bug #341037.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Fix spurious dep to eselect-python

2012-03-20 Thread Arfrever Frehtes Taifersar Arahesis
2012-03-20 17:53:56 Michał Górny napisał(a):
 On Tue, 20 Mar 2012 17:41:39 +0100
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
 
  2012-03-20 05:29:20 Luca Barbato napisał(a):
   Hi, I tried to avoid depending on eselect-python if the useflag is
   disabled.
   
   Please test and review.
  
  The proper fix is to make python.eclass add dependency on
  app-admin/eselect-python only when ${CATEGORY}/${PN} is
  dev-lang/python, dev-java/jython or dev-python/pypy. See bug #341037.
 
 Couldn't we just push that dependency to the specific ebuilds?

We want to control required version (=20091230 in case of 
app-admin/eselect-python) in 1 place.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: [gentoo-python] New eclass for Python

2012-03-03 Thread Arfrever Frehtes Taifersar Arahesis
2012-02-28 22:13:36 Krzysztof Pawlik napisał(a):
  - uses PYTHON_TARGETS use-expand

You cannot painlessly use USE flags for this purpose in gentoo-x86 without 
support for use.unsatisfiable.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: New global USE flag neon for ARM NEON optimization(s)

2012-01-18 Thread Arfrever Frehtes Taifersar Arahesis
2012-01-18 12:37:12 Mike Frysinger napisał(a):
 On Friday 23 December 2011 11:44:32 Duncan wrote:
  Matt Turner posted on Fri, 23 Dec 2011 08:09:30 -0500 as excerpted:
   to avoid confusion I'd suggest arch-neon or arm-neon (or armneon/
   archneon) if it's to be a global flag.
   
   NEON (the SIMD extensions) are turned on by the neon flag much more
   often than support for net-libs/neon is. Let's not rename USE flags like
   this.
  
  I'd argue that the library is far more frequently used, given that it's
  used across archs and arm is (for the time being, that seems to be
  gradually changing) still a rather obscure arch (for end-user installed
  distros, anyway), so the neon library is likely the most frequently used.
  
  However you are probably correct about the USE flag, as the library usage
  seems to be required in many cases and thus not USE-flaggable.
  
  So I'd still argue that to prevent confusion... but it's not something I
  feel strongly about, so given no one else objecting, use=neon for the simd
  extensions works as a global USE flag, and if it's ever used for the net-
  lib, that one can change I guess.
 
 if we're going to arch namespace flags, we should do it for all of them.  i 
 probably wouldn't complain about that (although i'd prefer more of an ISA 
 prefix than Gentoo $ARCH), but doing it for one flag is not nice.
 
 i agree that for some users, they've never heard of the the ARM NEON 
 extensions, but they have heard of the neon library.  i'd counter that with a 
 few points: (1) i don't think there are any packages in the tree that have 
 optional neon (the library) support

http://qa-reports.gentoo.org/output/genrdeps/rindex/net-libs/neon lists 6 
packages, which optionally
depend on net-libs/neon.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/

2011-11-27 Thread Arfrever Frehtes Taifersar Arahesis
2011-11-26 11:58:22 Fabian Groffen napisał(a):
 On 26-11-2011 01:54:35 +, Arfrever Frehtes Taifersar Arahesis wrote:
  commit: 1d4ac47c28706094230cb2c4e6ee1c1c71629aa0
  T Org
  AuthorDate: Sat Nov 26 01:52:49 2011 +
  Commit: Arfrever Frehtes Taifersar Arahesis arfrever AT gentoo DOT 
  org
  CommitDate: Sat Nov 26 01:52:49 2011 +
  URL:
  http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1d4ac47c
  
  dblink.mergeme(): Merge files in alphabetic order.
 
 What's the advantage of this?

The advantage is that this allows to easier review output of `emerge` to verify 
if correct files
have been installed.

 I don't really like to pay for sorting a potentially huge list just for some 
 eye-candy. 

Time of sorting in case of Linux sources is less than 0.05 s.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

2011-09-15 Thread Arfrever Frehtes Taifersar Arahesis
2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
 On Thu, 15 Sep 2011 09:35:21 +0200
 Michał Górny mgo...@gentoo.org wrote:
  Could you point me to at least a single program not supporting dots
  in useflags? My quick check shows that all PMs handle them well, quse
  and euse as well.
 
 Hrm, it's rather disappointing that they're accepted everywhere. That
 really shouldn't happen... My excuse for Paludis is that I never quite
 got around to passing in additional flags to validation of names, and
 dots are legal in exheres-0

There is no reason for Gentoo to be worse than Exherbo and not allow dots in 
USE flags.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

2011-09-15 Thread Arfrever Frehtes Taifersar Arahesis
2011-09-16 01:54:44 Brian Harring napisał(a):
 On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
   On Thu, 15 Sep 2011 09:35:21 +0200
   Michał Górny mgo...@gentoo.org wrote:
Could you point me to at least a single program not supporting dots
in useflags? My quick check shows that all PMs handle them well, quse
and euse as well.
   
   Hrm, it's rather disappointing that they're accepted everywhere. That
   really shouldn't happen... My excuse for Paludis is that I never quite
   got around to passing in additional flags to validation of names, and
   dots are legal in exheres-0
  
  There is no reason for Gentoo to be worse than Exherbo and not allow dots 
  in USE flags.
 
 Seriously Arfrever, drop the rhetoric here, and go fix the profile 
 compatibility issue.

I suggest to support files with -${EAPI} suffix.
Examples:
  profiles/package.mask-5
  profiles/use.desc-5
  profiles/base/package.mask-5
  profiles/base/package.use-5
  profiles/base/package.use.force-5
  profiles/base/package.use.mask-5
  profiles/base/use.force-5
  profiles/base/use.mask-5
  profiles/desc/python_abis.desc-5

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

2011-09-08 Thread Arfrever Frehtes Taifersar Arahesis
2011-09-08 19:03:56 Thomas Sachau napisał(a):
 Tomáš Chvátal schrieb:
  Start collecting ideas for EAPI5.
 
 2) USE-flag based support to install for different slots (e.g. python, ruby 
 or php)
 
 The second one is already done in some eclasses, afaik php and ruby, but it 
 might be a good idea to
 have a general framework for all slotted languages, so there is no need to 
 re-implement the same for
 every language.

It's better to have it implemented in eclasses. E.g. Python scripts need to be 
specially handled
(python_merge_intermediate_installation_images() renames them (so that their 
names include
Python ABI), calls python_convert_shebangs() if they don't have appropriate 
shebangs, and calls
python_generate_wrapper_scripts() to create appropriate wrapper scripts).

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] net-zope maintenance

2011-08-13 Thread Arfrever Frehtes Taifersar Arahesis
2011-08-13 12:37:00 Dirkjan Ochtman napisał(a):
 we should just cut it from the portage tree.

I suggest to wait until Zope team decides which overlay will be used to host 
updated, improved
and actively maintained ebuilds. The comment in package.mask should describe 
transition from
gentoo-x86 to overlay.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: POSIX capability in Gentoo

2011-08-02 Thread Arfrever Frehtes Taifersar Arahesis
2011-08-02 19:39:18 Ciaran McCreesh napisał(a):
 On Tue, 02 Aug 2011 13:36:12 -0400
 Jonathan Callen a...@gentoo.org wrote:
  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.
 
 Ugh, seriously? When did that happen?

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a133cb89d5279df7febcd0c8ab3890e2ccfb897a
 
 Maybe we need to spec VDB after all to avoid that kind of nonsense.

I think that unmerge-orphans is a useful feature.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

2011-07-27 Thread Arfrever Frehtes Taifersar Arahesis
2011-07-27 15:07:54 Rafael Goncalves Martins napisał(a):
 On Wed, Jul 27, 2011 at 6:02 AM, Pacho Ramos pa...@gentoo.org wrote:
  El mié, 27-07-2011 a las 09:39 +0200, Michał Górny escribió:
  Hello,
 
  As many of us already raged, the Python eclasses are delaying half
  a year with support of EAPI=4. The reason for that is not actually
  the lack of time or complexity of needed changes but willingness to use
  the new EAPI as an excuse to turn the eclass API upside down.
 
  The question I'm raising here: should eclasses be actually allowed to
  do *heavy* changes in their APIs in such cases? Or should the eclass
  maintainers create a new eclass instead (python-r1.eclass or so)?
 
  The main advantage I see in that is that devs are somehow forced
  to migrate their ebuilds as soon as they bump EAPI in them. Taking
  a look at a number of ebuilds still using git.eclass (instead of git-2)
  this is a serious advantage.
 
  On the other hand, I find this idea very unclear. Why should two
  ebuilds use completely different eclass variables just because they're
  using two different EAPIs? More importantly, why is a dev forced to do
  the migration in a random point when he/she wants to bump the ebuild
  EAPI? I'd like to remind you that python eclass is still hard to read
  for many of us.
 
  And why do we have to wait so long to use a new EAPI? We already had to
  fix a lot of ebuilds when old EAPIs were banned in Python eclasses. We
  wanted to bump the ebuilds to EAPI 4 then but the eclasses didn't
  support it. And now it still doesn't come with EAPI 4 support.
 
  And keeping two different EAPIs in a single eclass file means probably
  that older EAPIs are going to be banned at a random point once again.
  Devs will have to pro-actively migrate their ebuilds, overlays will
  break and so on. The usual procedure related to eclass removal wouldn't
  apply.
 
  So, don't you think it would be better to simply add EAPI=4 support to
  python eclass with no changes and start developing the new API in
  python-r1? Devs could migrate then at any point they want (and have
  time to!), and when Python team wants to get rid of the old eclass,
  the usual removal procedure will apply.
 
 
  About the concrete case of python eclass, per Arfrever's comment in bug
  report related with its eapi4 support, that support is already available
  in overlay, but not yet merged to the tree (probably because of the
  possible upcoming retirement of Arfrever :-/). What is preventing python
  team to merge eclass from overlay?
 
 
 AFAIK, the EAPI4 support in the overlay is EAPI 4-python, that almost
 certainly will never come to gx86, and some guys are trying to port
 the functionality to raw EAPI4, IIRC.

python.eclass from python overlay supports EAPI=4.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Turning eclasses upside down with new EAPIs (the python eclasses)

2011-07-27 Thread Arfrever Frehtes Taifersar Arahesis
There are small changes between behavior in EAPI=3 and EAPI=4 in 
python.eclass in python
overlay. The main change is improved syntax of PYTHON_DEPEND, which provides 
support for more
situations and replaces PYTHON_USE_WITH* variables. 95 % of whole code in 
python.eclass is
EAPI-independent, so there is no need for a new eclass.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] The Python problem

2011-06-29 Thread Arfrever Frehtes Taifersar Arahesis
2011-06-29 02:33:34 Jesus Rivero (Neurogeek) napisał(a):
 With python-updater, well, some time ago Ali Polatel implemented some
 approaches to get rid of python-updater, by exporting some variable in
 ebuilds that needed to be rebuilt when new python versions were
 installed. I dont recall what happened with that, but we could think
 of some ways to finally get rid of python-updater.

He added python_need_rebuild() function, which sets PYTHON_NEED_REBUILD 
variable, which is
checked by python-updater, so that python-updater can avoid checking CONTENTS 
files in VDB
and calling scanelf on all installed files.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Thoughts about broken package handling

2011-06-29 Thread Arfrever Frehtes Taifersar Arahesis
2011-06-26 13:48:02 Thomas Sachau napisał(a):
 In case of slotted dependencies (like python, ruby or php), this would also 
 allow the user to define
 per package, if he wants support for one or more slots of e.g. python.

You can set USE_PYTHON in /etc/portage/env/${CATEGORY}/${PN} or 
/etc/portage/env/${CATEGORY}/${PN}:${SLOT}.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] The Python problem

2011-06-29 Thread Arfrever Frehtes Taifersar Arahesis
2011-06-27 22:57:05 Thomas Sachau napisał(a):
 Dirkjan Ochtman wrote:
  On Mon, Jun 27, 2011 at 15:08, Fabian Groffen grob...@gentoo.org wrote:
  On 27-06-2011 14:28:34 +0200, Dirkjan Ochtman wrote:
  It would be nice when a similar technique could be implemented only
  once, in a consistent way.  In a way, multilib-portage can be considered
  equal to one of the objectives of the python (and ruby) eclass:
  multiple times compiling and installing for different ABIs.
  
  Yeah, but it'd be nice not to have to compile subversion three times
  just because we want the python bindings installed in three different
  Python environments.
 
 You wont be able to prevent this with a general solution, only with some 
 specialized solution inside
 the build, if you really want and need that.
 Currently, if you want python bindings for three different python 
 environments, you will have to
 build everything for all three python environments, even if you only need a 
 subset.

Building everything for all Python ABIs is not required in case of majority of 
packages, which
optionally install Python bindings. Makefiles of many packages (including 
dev-vcs/subversion)
provide separate targets for building/installation of core libraries and 
various bindings.

Example:

src_compile() {
emake || die

if use python; then
python_copy_sources bindings/python
build_python_bindings() {
emake \
PYTHON_INCLUDES=$(python_get_includedir) \
PYTHON_SITE_PACKAGES=$(python_get_sitedir) \
python_bindings
}
python_execute_function -s --source-dir bindings/python 
build_python_bindings
fi
}


-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] PSF-2 license

2011-06-29 Thread Arfrever Frehtes Taifersar Arahesis
gentoo-x86/licenses contains the following licenses:
  PSF-2.2
  PSF-2.3
  PSF-2.4
  PYTHON

PSF-2.2, PSF-2.3 and PSF-2.4 contain some versions of Python Software 
Foundation License Version 2,
which differ only in versions of Python, copyright years etc. They also contain 
some history of
Python and licenses for Python 2.0 and older versions.

PYTHON contains only some history of Python and licenses for Python 2.0 and 
older versions.

I suggest that PSF-2 file is introduced, which will contain only Python 
Software Foundation
License Version 2 with YEARS instead of some specific years and will 
(slowly) replace
PSF-2.2, PSF-2.3, PSF-2.4 and PYTHON in values of LICENSE in ebuilds.

I'm attaching suggested PSF-2 file based on LICENSE file from default branch of 
Python upstream
repository.

-- 
Arfrever Frehtes Taifersar Arahesis
PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2


1. This LICENSE AGREEMENT is between the Python Software Foundation
(PSF), and the Individual or Organization (Licensee) accessing and
otherwise using this software (Python) in source or binary form and
its associated documentation.

2. Subject to the terms and conditions of this License Agreement, PSF hereby
grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce,
analyze, test, perform and/or display publicly, prepare derivative works,
distribute, and otherwise use Python alone or in any derivative version,
provided, however, that PSF's License Agreement and PSF's notice of copyright,
i.e., Copyright (c) YEARS Python Software Foundation; All Rights Reserved
are retained in Python alone or in any derivative version prepared by Licensee.

3. In the event Licensee prepares a derivative work that is based on
or incorporates Python or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python.

4. PSF is making Python available to Licensee on an AS IS
basis.  PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED.  BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.

5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.

7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee.  This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.

8. By copying, installing or otherwise using Python, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-17 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-17 19:32:23 Markos Chandras napisał(a):
 On Tue, May 17, 2011 at 01:11:57PM -0400, Mark Loeser wrote:
  Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
   PyXML is dead:
 http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
 http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
   
   PyXML provides _xmlplus module, which replaces xml module (from standard 
   library) at run time,
   which might result in various problems.
   
   I'm planning to implement the following solution:
   - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
   this function will be
 necessary to use replace xml module with _xmlplus module. Python 
   =2.7.1-r2:2.7 will be added
 to the tree in next week and will be temporarily package.masked. Later 
   this change will be
 backported to new versions in older slots.
   - All packages, which use PyXML, will have to be patched to call 
   xml.use_pyxml(). The following
 code should be added before first import of anything from xml module:
   
   import xml
   if hasattr(xml, use_pyxml):
   xml.use_pyxml()
  
  Is this use_pyxml upstream?  From what you are saying, it is not. In
  that case, we have just made patches for every package that will never
  be allowed upstream.  Why not do something more worthwhile than waste the
  time of having to support something that might just become a problem to
  maintain in the future?
  
 
 I second that. Why do we need to make all the work fixing packages
 instead of letting upstream do their job? I am not so excited to 
 fix every package I maintain as it is quite possible to introduce
 regressions in the process. Furthermore, I don't understand your first
 message. You say that you will provide xml.use_pyxml() function on
 python-2.7. Is this code official or you are just patching the official
 python releases?
 Anyway, as I said, I'd rather wait for upstream to fix their packages
 instead of me.

Some upstreams are dead and some packages using PyXML will never be ported by 
upstreams to use
something else than PyXML (e.g. lxml).

$ python2.7
Python 2.7.1+ (2.7:572fbd9ca28f+, May 16 2011, 21:40:05) 
[GCC 4.5.2] on linux2
Type help, copyright, credits or license for more information.
 import xml, _xmlplus
 xml_modules = set(xml.__all__)
 _xmlplus_modules = set(_xmlplus.__all__)
 xml_modules - _xmlplus_modules
set(['etree'])
 _xmlplus_modules - xml_modules
set(['xpath', 'utils', 'schema', 'marshal', 'xslt'])


-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-17 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-17 19:11:57 Mark Loeser napisał(a):
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
  PyXML is dead:
http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
  
  PyXML provides _xmlplus module, which replaces xml module (from standard 
  library) at run time,
  which might result in various problems.
  
  I'm planning to implement the following solution:
  - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
  this function will be
necessary to use replace xml module with _xmlplus module. Python 
  =2.7.1-r2:2.7 will be added
to the tree in next week and will be temporarily package.masked. Later 
  this change will be
backported to new versions in older slots.
  - All packages, which use PyXML, will have to be patched to call 
  xml.use_pyxml(). The following
code should be added before first import of anything from xml module:
  
  import xml
  if hasattr(xml, use_pyxml):
  xml.use_pyxml()
 
 Is this use_pyxml upstream?

Python 2 is dead, so new features will never be added to Python 2 by Python 
upstream.

Before addition of xml.use_pyxml(), if user had many packages installed, which 
use xml module,
and 1 package installed, which needs PyXML, then the other packages were 
suffering from using
old code with more bugs.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-17 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-17 20:24:16 Mark Loeser napisał(a):
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said:
   I second that. Why do we need to make all the work fixing packages
   instead of letting upstream do their job? I am not so excited to 
   fix every package I maintain as it is quite possible to introduce
   regressions in the process. Furthermore, I don't understand your first
   message. You say that you will provide xml.use_pyxml() function on
   python-2.7. Is this code official or you are just patching the official
   python releases?
   Anyway, as I said, I'd rather wait for upstream to fix their packages
   instead of me.
  
  Some upstreams are dead and some packages using PyXML will never be ported 
  by upstreams to use
  something else than PyXML (e.g. lxml).
 
 Then those packages should get removed from the tree.  Do not start
 introducing Gentoo specific hacks to work around the problem.

Majority of packages from 
http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/pyxml seem to
have active upstreams, which doesn't mean they are actively working on porting 
these packages
to use something else than PyXML.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-17 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-17 20:43:29 Tomáš Chvátal napisał(a):
 Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a):
  PyXML is dead:
http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
 
  PyXML provides _xmlplus module, which replaces xml module (from standard 
  library) at run time,
  which might result in various problems.
 
  I'm planning to implement the following solution:
  - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
  this function will be
necessary to use replace xml module with _xmlplus module. Python 
  =2.7.1-r2:2.7 will be added
to the tree in next week and will be temporarily package.masked. Later 
  this change will be
backported to new versions in older slots.
  - All packages, which use PyXML, will have to be patched to call 
  xml.use_pyxml(). The following
code should be added before first import of anything from xml module:
 
  import xml
  if hasattr(xml, use_pyxml):
  xml.use_pyxml()
 
This code works with previous versions of Python, so no changes in 
  dependencies are needed.
 
 As I already asked,
 what problem do we have to keep PyXML in main tree to be used with python2.
 
 Your specific hack introduce different behaviour for python2.7.1-r2
 where you do not explain the need for it at all.

I had already explained it in many places.

 It is just python2 thing and we can happily use PyXML as it works even
 with latest python-2.7.
 
 So where is the problem?

Fixes for at least the following bugs are absent when PyXML is installed:
http://bugs.python.org/issue4877
http://bugs.python.org/issue6098
http://bugs.python.org/issue5762
http://bugs.python.org/issue5027
http://bugs.python.org/issue9054
http://bugs.python.org/issue777884
http://bugs.python.org/issue1433694
http://bugs.python.org/issue847665
http://bugs.python.org/issue1472827
http://bugs.python.org/issue1094164
http://bugs.python.org/issue1309009
http://bugs.python.org/issue1262320
http://bugs.python.org/issue925152

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-17 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-17 21:21:48 Tomáš Chvátal napisał(a):
 Dne 17.5.2011 21:12, Arfrever Frehtes Taifersar Arahesis napsal(a):
  2011-05-17 20:43:29 Tomáš Chvátal napisał(a):
  Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a):
  PyXML is dead:
http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
 
  PyXML provides _xmlplus module, which replaces xml module (from standard 
  library) at run time,
  which might result in various problems.
 
  I'm planning to implement the following solution:
  - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
  this function will be
necessary to use replace xml module with _xmlplus module. Python 
  =2.7.1-r2:2.7 will be added
to the tree in next week and will be temporarily package.masked. Later 
  this change will be
backported to new versions in older slots.
  - All packages, which use PyXML, will have to be patched to call 
  xml.use_pyxml(). The following
code should be added before first import of anything from xml module:
 
  import xml
  if hasattr(xml, use_pyxml):
  xml.use_pyxml()
 
This code works with previous versions of Python, so no changes in 
  dependencies are needed.
 
  As I already asked,
  what problem do we have to keep PyXML in main tree to be used with python2.
 
  Your specific hack introduce different behaviour for python2.7.1-r2
  where you do not explain the need for it at all.
 
  I had already explained it in many places.
 
  It is just python2 thing and we can happily use PyXML as it works even
  with latest python-2.7.
 
  So where is the problem?
 
  Fixes for at least the following bugs are absent when PyXML is installed:
  http://bugs.python.org/issue4877
  http://bugs.python.org/issue6098
  http://bugs.python.org/issue5762
  http://bugs.python.org/issue5027
  http://bugs.python.org/issue9054
  http://bugs.python.org/issue777884
  http://bugs.python.org/issue1433694
  http://bugs.python.org/issue847665
  http://bugs.python.org/issue1472827
  http://bugs.python.org/issue1094164
  http://bugs.python.org/issue1309009
  http://bugs.python.org/issue1262320
  http://bugs.python.org/issue925152
 
 2 options
 1) fix PyXML
 2) drop all packages including PyXML
 
 Altering system package is not the option.

Changing of any package is always an option, when given change fixes or works 
around a problem
and its benefits outweigh costs. The patches for about 20 packages will be easy 
to maintain,
since there is easy algorithm of generation of these patches (addition of 
constant 3-line code
before first import of xml module).

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PyXML

2011-05-11 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-11 12:30:18 Tomáš Chvátal napisał(a):
 Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a):
  PyXML is dead:
http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
http://mail.python.org/pipermail/xml-sig/2006-June/011545.html
 
  PyXML provides _xmlplus module, which replaces xml module (from standard 
  library) at run time,
  which might result in various problems.
 
  I'm planning to implement the following solution:
  - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of 
  this function will be
necessary to use replace xml module with _xmlplus module. Python 
  =2.7.1-r2:2.7 will be added
to the tree in next week and will be temporarily package.masked. Later 
  this change will be
backported to new versions in older slots.
  - All packages, which use PyXML, will have to be patched to call 
  xml.use_pyxml(). The following
code should be added before first import of anything from xml module:
 
  import xml
  if hasattr(xml, use_pyxml):
  xml.use_pyxml()
 
This code works with previous versions of Python, so no changes in 
  dependencies are needed.
 
 Apart from not being developed is PyXML actualy broken so we can't wait
 for upstream [1] to migrate their packages?

PyXML provides code from 2004. Since then, there were many fixes in stdlib xml 
module.

The following commands test code from xml module (which might be _xmlplus) and 
show problems when
PyXML is installed:
python2.7 -m test.test_minidom
python2.7 -m test.test_pyexpat
python2.7 -m test.test_sax

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] PyXML

2011-05-10 Thread Arfrever Frehtes Taifersar Arahesis
PyXML is dead:
  http://mail.python.org/pipermail/xml-sig/2004-November/010735.html
  http://mail.python.org/pipermail/xml-sig/2006-June/011545.html

PyXML provides _xmlplus module, which replaces xml module (from standard 
library) at run time,
which might result in various problems.

I'm planning to implement the following solution:
- Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this 
function will be
  necessary to use replace xml module with _xmlplus module. Python 
=2.7.1-r2:2.7 will be added
  to the tree in next week and will be temporarily package.masked. Later this 
change will be
  backported to new versions in older slots.
- All packages, which use PyXML, will have to be patched to call 
xml.use_pyxml(). The following
  code should be added before first import of anything from xml module:

import xml
if hasattr(xml, use_pyxml):
xml.use_pyxml()

  This code works with previous versions of Python, so no changes in 
dependencies are needed.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: Devmanual text on ChangeLogs

2011-05-02 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-02 02:16:49 Markos Chandras napisał(a):
 On Sun, May 01, 2011 at 04:31:08PM -0700, Brian Harring wrote:
  On Sun, May 01, 2011 at 11:23:40PM +, Duncan wrote:
   What about having a dedicated server-based changlog-signing key?  That's 
   still a lot of signing with a single key, but as you observed, the 
   hazards 
   of a loss of integrity there aren't as high as with most of the tree 
   content.  It'd require changes, but I don't believe they're out of line 
   with that required for the rest of the proposal.
  
  It means the only real trust that clients can level is on that key- 
  since it will be the last signer (thus /the/ signer) across all pkgs.
  
  Get at that key, and you've got the tree, versus the current form, 
  crack all signing keys and you've got the tree.
  
  Mind you this is ignoring eclasses, but getting eclasses sorted will 
  be mildly pointless if the rest of the solution has been 
  weakened/gutted since.
  
  Point is, it's not *just* about having a signature on it- it's about 
  mapping the trust of that signature back, and sectioning/containing 
  compromises.  What y'all are suggesting guts that layered defense.
  ~brian
 
 Then the only choice here is to ignore Changelogs from Manifests and
 live with that. You have your changelogs unprotected but you keep your
 ebuilds safe(?). As I said, it is a balanced choice that has to be made.

Generated ChangeLogs could contain server-side-generated signatures for 
themselves
(gpg --sign --clearsign ChangeLog  mv ChangeLog.asc ChangeLog). 
(Manifests wouldn't contain entries for ChangeLogs.)

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] python-namespaces.eclass

2011-04-30 Thread Arfrever Frehtes Taifersar Arahesis
2011-04-04 13:48:43 Brian Harring napisał(a):
  # @ECLASS: python-namespaces.eclass
  # @MAINTAINER:
  # Gentoo Python Project pyt...@gentoo.org
  # @BLURB: Eclass for packages installing Python namespaces
  # @DESCRIPTION:
  # The python-namespaces eclass defines phase functions for packages 
  installing Python namespaces.
 
 ^^^ This isn't a useful description.

IMHO it's sufficient, but could you suggest some sentences of description?

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] python-namespaces.eclass

2011-04-30 Thread Arfrever Frehtes Taifersar Arahesis
2011-05-01 00:32:13 Brian Harring napisał(a):
 On Sat, Apr 30, 2011 at 11:27:47PM +0200, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  2011-04-04 13:48:43 Brian Harring napisał(a):
# @ECLASS: python-namespaces.eclass
# @MAINTAINER:
# Gentoo Python Project pyt...@gentoo.org
# @BLURB: Eclass for packages installing Python namespaces
# @DESCRIPTION:
# The python-namespaces eclass defines phase functions for packages 
installing Python namespaces.
   
   ^^^ This isn't a useful description.
  
  IMHO it's sufficient, but could you suggest some sentences of description?
 
 It probably is sufficient for *you*- you're knee deep in the guts of 
 python, and know it's purpose.  Plus you wrote the eclass ;)
 
 The purpose of the description, and general code comments is for 
 *other* folk who may be looking at that code/problem for the first 
 time.  It needs to be written aimed at them.
 
 I'd suggest doing a grep of DESCRIPTION w/in eclasses and working from 
 the clearer examples- just looking at the first few examples returned, 
 alternatives for example has enough in the opening description to 
 understand exactly what it's for, same for apache-2.
 
 One thing to keep in mind is that even for folk who know python, this 
 is actually an area that doesn't match the normal verbage, and is a 
 bit niche in it's usage- try googling 'python namespaces' sometime, 
 note that it's scope discussions rather than pkgutil/distribute 
 importation across multiple directories. 
 
 To be clear, 'python namespaces' is a whole other thing from what this 
 is doing- this is manipulation of importation pathways (the 
 module/import hierarchy/namespace, rather than the common scope 
 terminology).
 
 Either way, rough suggestion:
 
 This eclass handles installation/creation of python 2.7 and higher

__init__.py files generated by this eclass work with Python 2.4.
(I haven't tested them with older versions.)

 pkgutil namespaces, and the equivalent distibute functionality.  See 
 zope's (example ebuild) for examples of usage.
 

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] python-namespaces.eclass

2011-04-04 Thread Arfrever Frehtes Taifersar Arahesis
2011-04-04 12:04:44 Tomáš Chvátal napisał(a):
 Dne 4.4.2011 01:13, Arfrever Frehtes Taifersar Arahesis napsal(a):
  2011-04-03 21:28:02 Tomáš Chvátal napisał(a):
  Dne 3.4.2011 19:38, Arfrever Frehtes Taifersar Arahesis napsal(a):
  I would like to add python-namespaces.eclass. This eclass will be used by 
  a small number of
  special packages, which will provide Python namespaces. These packages 
  will be used as
  dependencies of other packages already present in the tree.
 
  Ebuilds using this eclass must set PYTHON_NAMESPACES variable before 
  inheriting this eclass.
  Example (from net-zope/namespaces-zope):
PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app
 
  This eclass provides 3 public functions:
python-namespaces_src_install()
python-namespaces_pkg_postinst()
python-namespaces_pkg_postrm()
 
  Why you do so much overquoting in the conditions?
 
  I like consistency with python.eclass and improved syntax highlighting :) .
 Improved syntax highlighting? Apart from making it a bit larger that
 indeed is not a point if bash has to process and strip all the quotes
 your code is to be slower than the one without them.

Please don't try to force other developers to use your coding style.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] python-namespaces.eclass

2011-04-04 Thread Arfrever Frehtes Taifersar Arahesis
2011-04-04 13:48:43 Brian Harring napisał(a):
 What other consumers are expected for this beyond namespaces-zope?

dev-python/namespaces-enthought
dev-python/namespaces-peak
dev-python/namespaces-repoze
net-zope/namespaces-archetypes
net-zope/namespaces-grok
net-zope/namespaces-plone
net-zope/namespaces-silva
net-zope/namespaces-zc
net-zope/namespaces-z3c

The following packages will use both distutils.eclass and 
python-namespaces.eclass:
dev-python/dap
dev-python/flask
dev-python/logilab-common
dev-python/paste
net-zope/kss-core

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] python-namespaces.eclass

2011-04-03 Thread Arfrever Frehtes Taifersar Arahesis
I would like to add python-namespaces.eclass. This eclass will be used by a 
small number of
special packages, which will provide Python namespaces. These packages will be 
used as
dependencies of other packages already present in the tree.

Ebuilds using this eclass must set PYTHON_NAMESPACES variable before inheriting 
this eclass.
Example (from net-zope/namespaces-zope):
  PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app

This eclass provides 3 public functions:
  python-namespaces_src_install()
  python-namespaces_pkg_postinst()
  python-namespaces_pkg_postrm()

-- 
Arfrever Frehtes Taifersar Arahesis
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: python-namespaces.eclass
# @MAINTAINER:
# Gentoo Python Project pyt...@gentoo.org
# @BLURB: Eclass for packages installing Python namespaces
# @DESCRIPTION:
# The python-namespaces eclass defines phase functions for packages installing 
Python namespaces.

if ! has ${EAPI:-0} 4; then
die EAPI=\${EAPI}\ not supported by python-namespaces.eclass
fi

if [[ -z ${SUPPORT_PYTHON_ABIS} ]]; then
die python-namespaces.eclass cannot be used in ebuilds of packages not 
supporting installation for multiple Python ABIs
fi

if [[ -z ${PYTHON_NAMESPACES} ]]; then
die PYTHON_NAMESPACES variable not set
fi

inherit python

# 

# = HANDLING OF METADATA 
=
# 


# @ECLASS-VARIABLE: PYTHON_NAMESPACES
# @REQUIRED
# @DESCRIPTION:
# Python namespaces.
# If given namespace is prepended with + or -, then + or - is prepended 
to corresponding
# USE flag in generated IUSE.

_python-namespaces_set_metadata() {
local namespace parent_namespace

_PYTHON_NAMESPACES=
_PYTHON_NAMESPACES_COUNT=0
for namespace in ${PYTHON_NAMESPACES}; do
_PYTHON_NAMESPACES+=${_PYTHON_NAMESPACES:+ }${namespace#[+-]}
((_PYTHON_NAMESPACES_COUNT++))
done

DESCRIPTION=Python namespaces: ${_PYTHON_NAMESPACES// /, }
HOMEPAGE=http://www.gentoo.org/;
SRC_URI=

LICENSE=public-domain
SLOT=0

if [[ ${_PYTHON_NAMESPACES_COUNT} -ge 2 ]]; then
IUSE=${PYTHON_NAMESPACES//./-}
REQUIRED_USE=|| ( ${_PYTHON_NAMESPACES//./-} )

for namespace in ${_PYTHON_NAMESPACES}; do
if [[ ${namespace} == *.* ]]; then
parent_namespace=${namespace%.*}
REQUIRED_USE+= ${namespace//./-}? ( 
${parent_namespace//./-} )
fi
done
else
IUSE=
REQUIRED_USE=
fi

S=${WORKDIR}
}
_python-namespaces_set_metadata
unset -f _python-namespaces_set_metadata

# 

# === PHASE FUNCTIONS 

# 


EXPORT_FUNCTIONS src_install pkg_postinst pkg_postrm

_python-namespaces_get_enabled_namespaces() {
local namespace

if [[ ${_PYTHON_NAMESPACES_COUNT} -ge 2 ]]; then
for namespace in ${_PYTHON_NAMESPACES}; do
if use ${namespace//./-}; then
echo ${namespace}
fi
done
else
echo ${_PYTHON_NAMESPACES}
fi
}

# @FUNCTION: python-namespaces_src_install
# @DESCRIPTION:
# Implementation of src_install() phase. This function is exported.
# This function installs __init__.py modules corresponding to Python namespaces.
python-namespaces_src_install() {
if [[ ${EBUILD_PHASE} != install ]]; then
die ${FUNCNAME}() can be used only in src_install() phase
fi

_python_check_python_pkg_setup_execution

if [[ $# -ne 0 ]]; then
die ${FUNCNAME}() does not accept arguments
fi

python-namespaces_installation() {
local namespace
for namespace in $(_python-namespaces_get_enabled_namespaces); 
do
dodir $(python_get_sitedir)/${namespace//.//} || return 
1
echo \
try:
import pkg_resources
pkg_resources.declare_namespace(__name__)
try:
del pkg_resources
except NameError:
pass
except ImportError:
import pkgutil
__path__ = pkgutil.extend_path(__path__, __name__)
del pkgutil  
${ED}$(python_get_sitedir)/${namespace

[gentoo-dev] Patch for distutils.eclass [2011-04-03]

2011-04-03 Thread Arfrever Frehtes Taifersar Arahesis
This patch for distutils.eclass is divided into 13 subpatches.

Subpatch #1 bans DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS variable (too 
late).
Subpatch #2 removes 2 functions banned long time ago.
Subpatch #3 adds handling of *-nspkg.pth files in distutils_src_install().
Subpatch #4 adds missing sanity checks for execution of python_pkg_setup() in 
EAPI =4.
Subpatch #5 adds support for EAPI=4 in handling of DOCS variable.
Subpatch #6 disables installation of useless files.
Subpatch #7 adds sanity checks for appropriateness of execution of 
distutils_pkg_postinst()
and distutils_pkg_postrm().
Subpatch #8 adds support for EAPI=4 in handling of DISTUTILS_GLOBAL_OPTIONS 
array.
Subpatch #9 adds distutils_get_intermediate_installation_image() function, 
which will be
used in a small number of ebuilds, which currently rely on knowledge of 
implementation
details of distutils.eclass.
Subpatch #10 adds support for automatic changing of current working directory 
in handling
of DISTUTILS_SETUP_FILES (in all EAPIs).
Example:
  # Change current working directory to bindings/python and execute setup.py
  DISTUTILS_SETUP_FILES=(bindings/python|setup.py)
Subpatch #11 adds sanity checks for arguments in some functions.
Subpatch #12 adds unsetting of some internal functions after using of them.
Subpatch #13 moves declaration of local variables to other places for 
consistency with
python.eclass.

I'm planning to commit this patch in 1 week.

-- 
Arfrever Frehtes Taifersar Arahesis
--- distutils.eclass
+++ distutils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2010 Gentoo Foundation
+# Copyright 1999-2011 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/eclass/distutils.eclass,v 1.79 2010/12/24 15:05:24 arfrever Exp $
 
@@ -58,11 +58,17 @@
 
 # @ECLASS-VARIABLE: DISTUTILS_SETUP_FILES
 # @DESCRIPTION:
-# Paths to setup files.
+# Array of paths to setup files.
+# Syntax:
+#   [current_working_directory|]path_to_setup_file
 
 # @ECLASS-VARIABLE: DISTUTILS_GLOBAL_OPTIONS
 # @DESCRIPTION:
-# Global options passed to setup files.
+# Array of global options passed to setup files.
+# Syntax in EAPI 4:
+#   global_option
+# Syntax in EAPI =4:
+#   Python_ABI_pattern global_option
 
 # @ECLASS-VARIABLE: DISTUTILS_SRC_TEST
 # @DESCRIPTION:
@@ -100,19 +106,10 @@
 	EXPORT_FUNCTIONS src_test
 fi
 
-# @ECLASS-VARIABLE: DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS
-# @DESCRIPTION:
-# Set this to disable renaming of Python scripts containing versioned shebangs
-# and generation of wrapper scripts.
+# Scheduled for deletion on 2011-06-01.
 if [[ -n ${DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS} ]]; then
-	ewarn
-	ewarn \${EBUILD}\:
-	ewarn Deprecation Warning: DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS is deprecated
-	ewarn and will be banned on 2011-02-01. Use PYTHON_NONVERSIONED_EXECUTABLES=(\.*\).
-	ewarn The ebuild needs to be fixed. Please report a bug, if it has not been already reported.
-	ewarn
-
-	PYTHON_NONVERSIONED_EXECUTABLES=(.*)
+	eerror Use PYTHON_NONVERSIONED_EXECUTABLES=(\.*\) instead of DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS variable.
+	die DISTUTILS_DISABLE_VERSIONING_OF_PYTHON_SCRIPTS variable is banned
 fi
 
 # @ECLASS-VARIABLE: DOCS
@@ -144,6 +141,48 @@
 	fi
 }
 
+_distutils_prepare_global_options() {
+	local element option pattern
+
+	if [[ -n $(declare -p DISTUTILS_GLOBAL_OPTIONS 2 /dev/null)  $(declare -p DISTUTILS_GLOBAL_OPTIONS) != declare -a DISTUTILS_GLOBAL_OPTIONS=* ]]; then
+		die DISTUTILS_GLOBAL_OPTIONS should be indexed array
+	fi
+
+	if has ${EAPI:-0} 0 1 2 3; then
+		_DISTUTILS_GLOBAL_OPTIONS=(${DISTUTILS_GLOBAL_OPTIONS[@]})
+	else
+		_DISTUTILS_GLOBAL_OPTIONS=()
+
+		for element in ${DISTUTILS_GLOBAL_OPTIONS[@]}; do
+			if [[ ! ${element} =~ ^[^[:space:]]+\ . ]]; then
+die Element '${element}' of DISTUTILS_GLOBAL_OPTIONS array has invalid syntax
+			fi
+			pattern=${element%% *}
+			option=${element#* }
+			if _python_check_python_abi_matching ${PYTHON_ABI} ${pattern}; then
+_DISTUTILS_GLOBAL_OPTIONS+=(${option})
+			fi
+		done
+	fi
+}
+
+_distutils_prepare_current_working_directory() {
+	if [[ $1 == *|*|* ]]; then
+		die Element '$1' of DISTUTILS_SETUP_FILES array has invalid syntax
+	fi
+
+	if [[ $1 == *|* ]]; then
+		echo ${_BOLD}[${1%|*}]${_NORMAL}
+		pushd ${1%|*}  /dev/null || die Entering directory '${1%|*}' failed
+	fi
+}
+
+_distutils_restore_current_working_directory() {
+	if [[ $1 == *|* ]]; then
+		popd  /dev/null || die Leaving directory '${1%|*}' failed
+	fi
+}
+
 # @FUNCTION: distutils_src_unpack
 # @DESCRIPTION:
 # The distutils src_unpack function. This function is exported.
@@ -170,8 +209,15 @@
 		die ${FUNCNAME}() can be used only in src_prepare() phase
 	fi
 
+	_python_check_python_pkg_setup_execution
+
+	local distribute_setup_existence=0 ez_setup_existence=0
+
+	if [[ $# -ne 0 ]]; then
+		die ${FUNCNAME}() does not accept arguments
+	fi
+
 	# Delete ez_setup files to prevent

[gentoo-dev] Re: python-namespaces.eclass

2011-04-03 Thread Arfrever Frehtes Taifersar Arahesis
2011-04-03 21:28:02 Tomáš Chvátal napisał(a):
 Dne 3.4.2011 19:38, Arfrever Frehtes Taifersar Arahesis napsal(a):
  I would like to add python-namespaces.eclass. This eclass will be used by a 
  small number of
  special packages, which will provide Python namespaces. These packages will 
  be used as
  dependencies of other packages already present in the tree.
 
  Ebuilds using this eclass must set PYTHON_NAMESPACES variable before 
  inheriting this eclass.
  Example (from net-zope/namespaces-zope):
PYTHON_NAMESPACES=Products Shared Shared.DC five +zope zope.app
 
  This eclass provides 3 public functions:
python-namespaces_src_install()
python-namespaces_pkg_postinst()
python-namespaces_pkg_postrm()
 
 Why you do so much overquoting in the conditions?

I like consistency with python.eclass and improved syntax highlighting :) .

 Why do you die on those arguments, just ignore them...

The policy for Python-related eclasses is to not ignore misusage of functions.

 You could use some eclass-debug calls (see other eclasses) :)

IMHO they are helpless in debugging. 'set -x' enabled by -d option of emerge is 
more helpful.

 Why do you call those set_metadata right after its creation and delete
 it right away, does it save so much time it is better than doing it in
 global scope?

It is used to have appropriate scope for local variables, so that they don't 
have to be unset
manually immediately after the code, in which they should exist.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] python.eclass EAPI 4 support

2011-03-22 Thread Arfrever Frehtes Taifersar Arahesis
2011-03-22 12:51:48 Paweł Hajdan, Jr. napisał(a):
 I remember there was an effort to make python.eclass support EAPI 4 even
 before it has been officially approved.
 
 Now that we have EAPI 4 support even in stable portage, it would be
 awesome to make python.eclass support that EAPI.
 
 What do you think?

python.eclass maintainers are (slowly) working on support for EAPI=4. Please 
wait patiently.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Python 3.2 in the tree

2011-02-21 Thread Arfrever Frehtes Taifersar Arahesis
Python 3.2 is now in the main tree. It is currently package.masked.
Currently I'm planning unmasking on friday 2011-05-13 :) .

Bug #python-3.2 [1] is used to track incompatible packages. This bug can be
blocked ONLY by bugs in packages, which work correctly with Python 3.1.

[1] https://bugs.gentoo.org/show_bug.cgi?id=python-3.2

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: gentoo-x86/profiles/prefix/darwin/macos/10.4/x86: make.defaults

2011-02-13 Thread Arfrever Frehtes Taifersar Arahesis
2011-02-13 20:43:12 Fabian Groffen napisał(a):
 On 13-02-2011 16:53:40 +, Arfrever Frehtes Taifersar Arahesis wrote:
  arfrever11/02/13 16:53:40
  
  Modified: make.defaults
  Log:
Don't include ${USE} in the first assignment to USE in make.defaults 
  files to avoid incorrect interactions between enabled and disabled flags in 
  different files.
 
 Is there any resource you can point me to where it explains more
 carefully why and when this has changed?

PMS
5.2.4 make.defaults
Variables to the right of the equals sign in the form ${foo} or $foo are 
recognised and expanded
from variables previously set in this or earlier make.defaults files.
5.3.1 Incremental Variables
Incremental variables must stack between parent and child profiles in the 
following manner:
Beginning with the highest parent profile, tokenise the variable’s value based 
on whitespace and
concatenate the lists. Then, for any token T beginning with a hyphen, remove it 
and any previous
tokens whose value is equal to T with the hyphen removed, or, if T is equal to 
-*, remove all
previous values. Note that because of this treatment, the order of tokens in 
the final result is
arbitrary, not necessarily related to the order of tokens in any given profile. 
The following
variables must be treated in this fashion: 
  • USE 
  • USE_EXPAND 
  • USE_EXPAND_HIDDEN 
  • CONFIG_PROTECT 
  • CONFIG_PROTECT_MASK

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI usage in main tree

2011-01-25 Thread Arfrever Frehtes Taifersar Arahesis
2011-01-25 15:34:58 Thomas Sachau napisał(a):
 This means, that you either have to convince the python eclass maintainers to 
 reduce the complexity
 of their eclass

There are plans to remove some EAPI-specific behavior by removing support for 
old EAPIs.
E.g. when there are no remaining ebuilds using distutils.eclass, 
python_mod_optimize() or
python_mod_cleanup() in old EAPIs, then it will be possible to remove large 
parts of
python_mod_optimize() and python_mod_cleanup().

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI usage in main tree

2011-01-25 Thread Arfrever Frehtes Taifersar Arahesis
2011-01-25 22:33:16 Lars Wendler napisał(a):
 Hi,
 
 I don'f feel very well with this idea especially because no matter how hard I 
 try I don't get comfortable with EAPI-3. No offense to our prefix guys, you 
 surely did a hell of a good job and EAPI-3 seems to really get you out of 
 quite some trouble you had with earlier EAPIs, but... 
 I for myself never tried a prefix installation and I don't have any 
 intentions 
 to do this in the foreseeable future so I still prefer EAPI-2 wherever I can 
 simply because EAPI-3 imposes overhead on my side which I have no real 
 benefit 
 from and I have no real clue about how to write proper EAPI-3 ebuilds.

You can use EAPI=3 without supporting prefix installations.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-geosciences/mapserver: mapserver-5.4.2-r1.ebuild ChangeLog

2010-12-23 Thread Arfrever Frehtes Taifersar Arahesis
2010-12-23 20:07:45 Justin (jlec) Lecher napisał(a):
 On 23/12/10 19:47, Mike Gilbert wrote:
  On 12/23/2010 12:18 PM, Jeremy Olexa wrote:
  FYI: This adds no value to the ebuild. The default src_unpack is ran
  when src_unpack() is not defined.
  
  Unless src_unpack() is exported in one of the many eclasses that ebuild
  inherits. In which case this would un-export it and bring the behavior
  back to default.
  
 
 That's right. The magic comes from the loved python.eclass. If it is not
 added the webapp.eclass does some things.

What do you mean about python.eclass?
python.eclass doesn't define python_src_unpack().

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Summary of suggested new features in EAPI=4

2010-12-17 Thread Arfrever Frehtes Taifersar Arahesis
This is the summary of some problems and suggested new features in EAPI=4, 
which would solve
these problems.



Problem #1: USE flags cannot contain . characters.

The following solutions have been suggested:
- Add support for . characters in USE flags in EAPI=4.



Problem #2: Files in profiles cannot use features from newer EAPIs.

The following solutions have been suggested:
- Add support for files with -${EAPI} extension in EAPI=4. These files 
would use EAPI
  specified in their filenames instead of EAPI of profile.
  Example files:
package.mask-${EAPI}
package.use-${EAPI}
package.provided-${EAPI}
use.force-${EAPI}
use.mask-${EAPI}
package.use.force-${EAPI}
package.use.mask-${EAPI}
packages-${EAPI}
virtuals-${EAPI}
- Create new profiles using EAPI=4, remove all older profiles from 
profiles.desc so that
  repoman doesn't check older profiles, and deprecate older profiles.

Council should choose one of these solutions.



Problem #3: repoman doesn't allow stable packages to have optional dependencies 
on unstable
packages (usually until these packages are stabilized).

Example of the problem:
If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are 
masked using
use.mask on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on 
these
architectures, then majority of reverse dependencies of Python won't be tested 
with new
versions of Python.

The following solutions have been suggested:
- Add support for use.unsatisfiable and package.use.unsatisfiable files in 
profiles in
  EAPI=4. These files would cause that repoman would allow optional 
dependencies on
  packages potentially unsatisfiable in some configurations (e.g. on 
stable-only systems).
- Create separate profiles for stable and unstable keywords. USE flags would be 
masked in
  stable profiles and unmasked in unstable profiles.

Council should choose one of these solutions.



There are already existing patches for Portage, which implement these 
solutions, which are
suggested new features in EAPI=4.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Summary of suggested new features in EAPI=4

2010-12-17 Thread Arfrever Frehtes Taifersar Arahesis
2010-12-18 03:48:26 Donnie Berkholz napisał(a):
 On 02:45 Sat 18 Dec , Arfrever Frehtes Taifersar Arahesis wrote:
  Problem #1: USE flags cannot contain . characters.
 
 This isn't a problem, it's an arbitrary statement of an antifeature. My 
 understanding of the actual problem here is that you want to have some 
 sort of USE flags for various Python versions with names containing 
 periods, for usability. Perhaps you could expand on exactly what you 
 want to do, so we can work together to figure out whether this is the 
 best route to solve your problem.
 
 If the problem is handling which Python versions to build modules for, 
 I'm wondering whether enhancing the eselect module to select multiple 
 preferred versions might not be a better solution than EAPI changes. 

USE flags would allow to use USE dependencies to ensure that dependencies of 
given package
have been installed for required Python versions.

  
  
  Problem #2: Files in profiles cannot use features from newer EAPIs.
 
 Could you explain how the eapi file in profiles does not address this? 
 The 10.0 profiles are using it already with EAPI=2.

I would like to use EAPI=4-specific syntax in a file in base profile (or 
somewhere else) to
affect all profiles. If I have to rely on eapi files, then all non-deprecated 
profiles
checked by repoman would have to use EAPI =4.

  
  
  Problem #3: repoman doesn't allow stable packages to have optional 
  dependencies on unstable
  packages (usually until these packages are stabilized).
 
 This seems useful at first glance, but I'm wondering how big of a 
 problem it really is and whether this solution is a bit overarchitected.
 
  Example of the problem:
  If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE 
  flags are masked using use.mask on given architectures until Python 
  2.7, 3.1 and 3.2 are stabilized on these architectures, then majority 
  of reverse dependencies of Python won't be tested with new versions of 
  Python.
 
 Why does that have to be the case? Why not unmask them earlier but only 
 make them available to ~arch ebuilds?

There are already hundreds of stable ebuilds, which support unstable Python 2.7 
(without
explicit optional dependency on Python 2.7). The solution to problem #3 
shouldn't require
any changes in ebuilds.

 I don't know of anyone who's actually done this, but setting IUSE based 
 on ACCEPT_KEYWORDS being ~arch should be possible.

It would break invariance of metadata.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: [rfc] Sane defaults for USE_PYTHON, patch to python eclass

2010-12-07 Thread Arfrever Frehtes Taifersar Arahesis
2010-12-04 01:23:41 Sebastian Pipping napisał(a):
 Current situation
 =
 Without specifying USE_PYTHON in /etc/make.conf ebuilds based on the
 python eclass will install packages for no more ABIs than the two active
 versions on the 2.x and 3.x lines.  To give an example: with Python 2.6,
 2.7 and 3.1 installed and 2.7 set as the active 2.x Python version I
 would get files installed for python 2.7 and 3.1, but not 2.6.
 
 Is that a sane default?  Especially when a new slot of Python arrives at
 the Gentoo tree, you run into situations with two slots of Python 2.x
 installed.  To have packages functioning with both, you would need a
 custom USE_PYTHON line like USE_PYTHON=2.6 2.7 - otherwise one of
 these slots' Python will be very limited.
 
 This problem is made worse by the fact that USE_PYTHON has almost no
 documentation.  This bug shows well, that the current behavior is a
 surprising troublemaker:
 
 https://bugs.gentoo.org/show_bug.cgi?id=347153
 
 
 Proposed new situation
 ==
 If I have a version of Python installed, it should be usable well.
 So USE_PYTHON is derived from the list of all available Python slots.

Please don't change current algorithm.
- Average users need packages built with support for at most 1 version of 
Python 2 and at most
  1 version of Python 3.
- Only people, who want to explicitly test given modules/scripts with multiple 
Python versions,
  would need dependencies built with support for more Python versions.
- You might break something outside of python.eclass.

There is a plan (and patches) to introduce usage of USE flags for selection of 
requested 
Python versions. It will be available when a future EAPI supports dots in names 
of USE flags.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] eclass review for Gnome 2.32 and waf ebuilds

2010-12-07 Thread Arfrever Frehtes Taifersar Arahesis
Why does waf-utils_pkg_setup() call 'python_set_active_version 2'?
What do you plan to do when there are packages using waf and supporting Python 
3?

http://code.google.com/p/waf/ says:
compatibility from Python 2.3 to 3.1 is maintained (and Jython 2.5)

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Python 2.7 status check?

2010-11-29 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-29 12:43 Sebastian Pipping sp...@gentoo.org napisał(a):
 On 11/29/10 02:35, Arfrever Frehtes Taifersar Arahesis wrote:
 Sebastian Pipping recently removed automatic upgrade of active version of 
 Python, so
 python-2.7.1.ebuild does not upgrade active version of Python.

 The ebuilds you just added for 2.7.1 and 3.1.3 do contain
 eselect_python_update() and calls to it.

 I suppose that happened by mistake and removed eselect_python_update()
 on these ebuilds, too.  They are in CVS now, mirrors take extra time.

It wasn't any mistake. Please actually read that code:

eselect_python_update() {
if [[ -z $(eselect python show --python${PV%%.*}) ]]; then
eselect python update --python${PV%%.*}
fi
}

${PV%%.*} == 2
'eselect python update --python2' would be called only if output of
'eselect python show --python2' was empty, which would occur when
there was no active version of Python 2 set (no /usr/bin/python2
symlink).

--
Arfrever Frehtes Taifersar Arahesis



Re: [gentoo-dev] Disabling auto-bumping of active Python version

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-27 14:00:28 Sebastian Pipping napisał(a):
 On 11/14/10 17:28, Sebastian Pipping wrote:
  So I plan to remove the call to eselect_python_update from all Python
  ebuilds in two weeks from now.
 
 Now fixed in both the main tree as well as the Python overlay.
 Please let me know in case I broke anything.

You probably broke generation of stages :) .
(I have restored a minimal version of eselect_python_update() in python 
overlay.)

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-16 00:41:35 Alex Alexander napisał(a):
 On Mon, Nov 15, 2010 at 07:40:44PM +0100, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  Some updates to my suggestion:
  - Files would optionally end with -${EAPI} suffix.
  - The following files would be affected:
  package.mask
  package.unmask
  package.keywords
  package.accept_keywords
  package.use
  package.provided
  use.force
  use.mask
  use.unsatisfiable
  package.use.force
  package.use.mask
  package.use.unsatisfiable
  packages
  virtuals
  
  (Some of these files aren't documented in PMS.)
  
  I would like to suggest that this feature be included in EAPI=4.
  I have a patch, which implements this feature in Portage.
 
 The council has already decided that a filename suffix is not a
 desirable way to fix issues like this.

GLEP 55 changes established filename extension, while my proposition affects 
files,
which don't have any common extension.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Extending EAPI=4

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-19 16:51:03 Zac Medico napisał(a):
 On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
  use.unsatisfiable and package.use.unsatisfiable files would cause that 
  `repoman` would treat
  given USE flags in the same way as masked USE flags. These files wouldn't 
  affect behavior of
  `emerge`:
   - If user has enabled given USE flag specified in use.unsatisfiable or 
  package.use.unsatisfiable
 and if optional dependencies controlled by this USE flag are already 
  installed or satisfiable,
 then `emerge` will allow to install given package.
   - If user has enabled given USE flag specified in use.unsatisfiable or 
  package.use.unsatisfiable
 and if optional dependencies controlled by this USE flag cannot be 
  satisfied (with current
 settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then 
  `emerge` will print
 informative error message telling e.g. about a dependency masked by 
  ~${ARCH} keyword.
 
 Can't we print a masked by ~${ARCH} keyword message as you suggest,
 even without the use.unsatisfiable data? If so, then isn't
 use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
 use.mask, so I don't see any value added.

repoman sometimes needs to allow stable packages to have optional dependencies 
on unstable
packages (usually until these packages are stabilized). My patch implements 
this functionality
for repoman.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Extending EAPI=4

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-28 20:59:05 Zac Medico napisał(a):
 On 11/28/2010 10:15 AM, Arfrever Frehtes Taifersar Arahesis wrote:
  2010-11-19 16:51:03 Zac Medico napisał(a):
  On 10/25/2010 06:24 AM, Arfrever Frehtes Taifersar Arahesis wrote:
  use.unsatisfiable and package.use.unsatisfiable files would cause that 
  `repoman` would treat
  given USE flags in the same way as masked USE flags. These files wouldn't 
  affect behavior of
  `emerge`:
   - If user has enabled given USE flag specified in use.unsatisfiable or 
  package.use.unsatisfiable
 and if optional dependencies controlled by this USE flag are already 
  installed or satisfiable,
 then `emerge` will allow to install given package.
   - If user has enabled given USE flag specified in use.unsatisfiable or 
  package.use.unsatisfiable
 and if optional dependencies controlled by this USE flag cannot be 
  satisfied (with current
 settings of ACCEPT_KEYWORDS, /etc/portage/package.keywords etc.), then 
  `emerge` will print
 informative error message telling e.g. about a dependency masked by 
  ~${ARCH} keyword.
 
  Can't we print a masked by ~${ARCH} keyword message as you suggest,
  even without the use.unsatisfiable data? If so, then isn't
  use.unsatisfiable redundant? Your patch [1] seems to behave exactly like
  use.mask, so I don't see any value added.
  
  repoman sometimes needs to allow stable packages to have optional 
  dependencies on unstable
  packages (usually until these packages are stabilized). My patch implements 
  this functionality
  for repoman.
 
 It seems like you're trying to bypass an important function of repoman
 though. The idea is that repoman is supposed to protect users from
 experiencing unsatisfiable dependencies of this sort, and use.mask
 accomplishes that.

If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are 
masked using use.mask
on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on these 
architectures, then
majority of reverse dependencies of Python wouldn't be tested with new versions 
of Python.

Example {,R}DEPEND:
  python_abis_2.4? ( dev-lang/python:2.4 )
  python_abis_2.5? ( dev-lang/python:2.5 )
  python_abis_2.6? ( dev-lang/python:2.6 )
  python_abis_2.7? ( dev-lang/python:2.7 )
  python_abis_3.0? ( dev-lang/python:3.0 )
  python_abis_3.1? ( dev-lang/python:3.1 )
  python_abis_3.2? ( dev-lang/python:3.2 )
  python_abis_2.5-jython? ( dev-java/jython:2.5 )

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-28 21:15:15 Markos Chandras napisał(a):
 On Sun, Nov 28, 2010 at 08:32:16PM +0100, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  I would like to introduce incompatible improvements in syntax of 
  PYTHON_DEPEND variable in
  EAPI =4. The new syntax will depend on whether given package supports 
  installation for
  multiple Python ABIs. The extended functionality will replace 
  PYTHON_USE_WITH* variables.
  
  [...]
 
 Your changes are far too complicated to me. Python eclass and
 consequently writing python ebuilds is a difficult task already.
 If you keep adding more and more magic in this eclass,
 you will end up supporting and fixing all the python ebuilds by
 yourself. Maybe you should consider splitting python eclass 
 into two separate modules. One for core functionality and 
 another one which will inherit this core eclass and export 
 a simple API so the rest of us can use python eclass without 
 having to study all the documentation for a month.

The changes aren't complicated. You only need to understand special  
marker.
The syntax of ranges of versions in packages not supporting installation for 
multiple Python ABIs
won't be changed. Majority of ebuilds won't need to explicitly use any extended 
functionality
of PYTHON_DEPEND. In ebuilds, which support installation for multiple Python 
ABIs, unconditionally
depend on Python and don't need additional USE dependencies on Python, I will 
unset PYTHON_DEPEND,
because it will work like PYTHON_DEPEND=.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-28 21:20:31 Michał Górny napisał(a):
 On Sun, 28 Nov 2010 20:32:16 +0100
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org 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 prefer to use a character sequence, which isn't valid in 
DEPEND/RDEPEND/PDEPEND.

I don't know what you mean by version numbers. Remember that each  in 
an ebuild with empty
RESTRICT_PYTHON_ABIS is replaced in DEPEND/RDEPEND by:
  python_abis_2.4? ( dev-lang/python:2.4 )
  python_abis_2.5? ( dev-lang/python:2.5 )
  python_abis_2.6? ( dev-lang/python:2.6 )
  python_abis_2.7? ( dev-lang/python:2.7 )
  python_abis_3.0? ( dev-lang/python:3.0 )
  python_abis_3.1? ( dev-lang/python:3.1 )
  python_abis_3.2? ( dev-lang/python:3.2 )
  python_abis_2.5-jython? ( dev-java/jython:2.5 )

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Extending EAPI=4

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-28 21:30:47 Zac Medico napisał(a):
 On 11/28/2010 12:07 PM, Arfrever Frehtes Taifersar Arahesis wrote:
  2010-11-28 20:59:05 Zac Medico napisał(a):
  It seems like you're trying to bypass an important function of repoman
  though. The idea is that repoman is supposed to protect users from
  experiencing unsatisfiable dependencies of this sort, and use.mask
  accomplishes that.
  
  If python_abis_2.7, python_abis_3.1 and python_abis_3.2 USE flags are 
  masked using use.mask
  on given architectures until Python 2.7, 3.1 and 3.2 are stabilized on 
  these architectures, then
  majority of reverse dependencies of Python wouldn't be tested with new 
  versions of Python.
  
  Example {,R}DEPEND:
python_abis_2.4? ( dev-lang/python:2.4 )
python_abis_2.5? ( dev-lang/python:2.5 )
python_abis_2.6? ( dev-lang/python:2.6 )
python_abis_2.7? ( dev-lang/python:2.7 )
python_abis_3.0? ( dev-lang/python:3.0 )
python_abis_3.1? ( dev-lang/python:3.1 )
python_abis_3.2? ( dev-lang/python:3.2 )
python_abis_2.5-jython? ( dev-java/jython:2.5 )
 
 It seems like the problem here is that we don't have separate profiles
 for stable and unstable keywords. The obvious solution would be to have
 separate profiles, mask the flags in the stable profiles, and unmask the
 flags in the unstable profiles. That way, repoman would continue to
 protect stable profile users from unsatisfiable dependencies, without
 unnecessarily masking those choices from unstable profile users.

I would prefer small number of additional files instead of huge proliferation 
of profiles.
You also suggested using EAPI=4-specific profiles instead of EAPI-versioned 
files, so eventually
we might have about 4 times more profiles :) .

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Python 2.7 status check?

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-29 01:26:19 Robin H. Johnson napisał(a):
 Presently in package.mask, we have this entry:
 
 # Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org (04 Jul 2010)
 # Python 2.7 masked until sufficient number of reverse dependencies is fixed.
 ~dev-lang/python-2.7
 
 Well Python 2.7.1 was committed today, and does NOT match this mask, so are 
 all
 of the reverse deps fixed?

Sufficient number of reverse dependencies is fixed. Almost all remaining open 
bugs are about
problems specific to test suites.

Sebastian Pipping recently removed automatic upgrade of active version of 
Python, so
python-2.7.1.ebuild does not upgrade active version of Python.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-29 01:24:50 Alex Alexander napisał(a):
 On 28 Nov 2010, at 22:20, Michał Górny mgo...@gentoo.org wrote:
 
  On Sun, 28 Nov 2010 20:32:16 +0100
  Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org 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

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: PYTHON_DEPEND in EAPI =4, PYTHON_BDEPEND

2010-11-28 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-29 02:54:14 Jonathan Callen napisał(a):
 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.

I'm not sure if Thomas Sachau or somebody else wasn't planning to use {...} 
in the future.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-15 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-03 06:18:01 Zac Medico napisał(a):
 When you need to use a new EAPI, why not just create a sub-profile that
 uses the existing 'eapi' file support? For example, you could create
 10.1 profiles that inherit from the 10.0 profiles, and put anything
 requiring the new EAPI in the 10.1 sub-profiles.

Your suggestion would require that hundreds of packages are manually masked in 
base profile
and unmasked in this new subprofile.
E.g. it is planned that dev-python/setuptools will have 
python_abis_2.5-jython USE flag.
This flag should be masked on architectures, which don't support Java/Jython. 
use.mask and
package.use.mask files in base profile don't support such a USE flag, so 
dev-python/setuptools
and all its (at least indirect) reverse dependencies would have to be masked in 
base profile.

If a future EAPI allows a new character in package names, then my suggestion 
would allow to
handle such packages.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] EAPI versioning of files in profiles

2010-11-15 Thread Arfrever Frehtes Taifersar Arahesis
2010-11-15 19:32:28 Zac Medico napisał(a):
 On 11/15/2010 10:23 AM, Arfrever Frehtes Taifersar Arahesis wrote:
  2010-11-03 06:18:01 Zac Medico napisał(a):
  When you need to use a new EAPI, why not just create a sub-profile that
  uses the existing 'eapi' file support? For example, you could create
  10.1 profiles that inherit from the 10.0 profiles, and put anything
  requiring the new EAPI in the 10.1 sub-profiles.
  
  Your suggestion would require that hundreds of packages are manually masked 
  in base profile
  and unmasked in this new subprofile.
  E.g. it is planned that dev-python/setuptools will have 
  python_abis_2.5-jython USE flag.
  This flag should be masked on architectures, which don't support 
  Java/Jython. use.mask and
  package.use.mask files in base profile don't support such a USE flag, so 
  dev-python/setuptools
  and all its (at least indirect) reverse dependencies would have to be 
  masked in base profile.
 
 Why would they have to be masked, just to make repoman happy?

Yes.

 Alternatively, we could simply deprecate the older profile and remove it
 from profiles.desc so that repoman doesn't check it anymore. It's
 desirable to remove old profiles from profiles.desc anyway, since we
 don't want them to slow down repoman.

The advantage of my suggestion is that it's fully backward compatible and 
doesn't require such
changes in profiles.desc.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Extending EAPI=4

2010-11-15 Thread Arfrever Frehtes Taifersar Arahesis
2010-10-25 16:03:01 Ciaran McCreesh napisał(a):
 On Mon, 25 Oct 2010 15:56:18 +0200
 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
  2010-10-25 15:42:00 Ciaran McCreesh napisał(a):
   On Mon, 25 Oct 2010 15:24:23 +0200
   Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org wrote:
1. Support for . characters in names of USE flags
   
   If you do this, you'll have to either convert everything using
   Python ABIs to EAPI 4 immediately, or have two sets of flag names.
   Won't users get confused if they have to set both python_abis_3_2
   (for EAPI  4 packages) and python_abis_3.2 (for EAPI 4 packages)?
  
  There won't be any such USE flags for EAPI 4.
 
 Ok, that answers that objection. In that case I'd not be opposed to .
 being allowed *provided*:
 
 - Portage explicitly enforces it not being allowed anywhere else,
   including in profiles that aren't marked as eapi 4

I have implemented validation of syntax of USE flags in files in profiles:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=9e9c822aae0c3daab208175025b161d6d34877fe

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] EAPI versioning of files in profiles

2010-11-01 Thread Arfrever Frehtes Taifersar Arahesis
I would like to suggest improvement in handling of EAPI in profiles:
Some files could optionally end with :${EAPI}, which would be used to 
specify, which EAPI
should be used for parsing of given file. It would concern at least the 
following files:
  package.mask
  package.use
  use.force
  use.mask
  package.use.force
  package.use.mask
And maybe also use.unsatisfiable and package.use.unsatisfiable.

Examples:
  profiles/package.mask:5 could be used to mask dependency atoms with -scm or 
-live suffix
  (if EAPI=5 supports this suffix).

  profiles/base/use.mask:4 could be used to mask USE flags (which use 
EAPI=4-specific syntax)
  on all profiles inheriting from base profile.

Without support for EAPI-versioned files, such actions from above examples 
might require copying
of whole tree of profiles, adding eapi file to new profiles etc.

eapi files would still be used to specify EAPI for EAPI-unversioned files in 
given profiles.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.


  1   2   3   >