Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
On Mon, 10 Nov 2014 22:18:01 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, developers. I'm planning to commit this news item before =2.1-r90 goes stable. It's pretty strange, but after the last emerge -1uDN world system update I lost bash-complition. It was removed (app-admin/eselect-bashcomp-1.3.6, app-shells/bash-completion-1.3-r2, app-shells/gentoo-bashcomp-20121024) during emerge --depclean process. I have bash-completion USE-flag in /etc/portage/make.conf and installed bashcomp long time ago. Now it was semi-automatically deleted. May it be relatated to this changes (migration to 2.1-r90)?
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-20, o godz. 11:58:59 Diamond diam...@hi-net.ru napisał(a): On Mon, 10 Nov 2014 22:18:01 +0100 Michał Górny mgo...@gentoo.org wrote: Hello, developers. I'm planning to commit this news item before =2.1-r90 goes stable. It's pretty strange, but after the last emerge -1uDN world system update I lost bash-complition. It was removed (app-admin/eselect-bashcomp-1.3.6, app-shells/bash-completion-1.3-r2, app-shells/gentoo-bashcomp-20121024) during emerge --depclean process. I have bash-completion USE-flag in /etc/portage/make.conf and installed bashcomp long time ago. Now it was semi-automatically deleted. May it be relatated to this changes (migration to 2.1-r90)? Partially. USE=bash-completion will be completely removed, and completions will be installed unconditionally. You have to install app-shells/bash-completion yourself if you want to use it. Maybe I should mention the USE flag changes too in the news item :). -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Dnia 2014-11-19, o godz. 17:41:53 Diego Elio Pettenò flamee...@flameeyes.eu napisał(a): On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Comrel, please either do something about vapier or reassign all his packages (and team positions) to a volunteering proxy developer who will handle human relations for him. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-10, o godz. 22:18:01
Michał Górny mgo...@gentoo.org napisał(a):
Hello, developers.
I'm planning to commit this news item before =2.1-r90 goes stable.
I have rewritten the message to be more user-oriented like Rich
suggested (big thanks to you!) and added a paragraph about loading
bashcomp in bashrc.
Please review.
Next version, added the paragraph about USE=bash-completion.
--
Best regards,
Michał Górny
Title: bash-completion-2.1-r90
Author: MichaŠGórny mgo...@gentoo.org
Content-Type: text/plain
Posted: 2014-MM-DD
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: app-shells/bash-completion-2.1-r90
Starting with app-shells/bash-completion-2.1-r90, the framework used to
enable and manage completions in Gentoo is finally changing in order to
properly follow upstream design. This has some important implications
for our users.
Firstly, the install location for completions changes to follow upstream
default. The completions enabled before the upgrade will continue to
work but you may no longer be able to enable or disable completions
installed prior to the upgrade. To solve this issue, the packages
installing completions need to rebuilt. The following command can be
used to automatically rebuild all the relevant packages:
$ find /usr/share/bash-completion -maxdepth 1 -type f \
'!' -name 'bash_completion' -exec emerge -1v {} +
Secondly, the autoloading support introduced upstream removes the
penalties involved with enabling a great number of completions. This
allowed us to switch to an opt-out model where all completions installed
after the upgrade are enabled by default. Specific completions can be
disabled using 'eselect bashcomp disable ...'
The model change implies that all current selections done using 'eselect
bashcomp' can not be properly migrated and will be disregarded when
the relevant completion files are built against the new bash-completion
version. After rebuilding all the packages providing completion files,
you may want to remove the symlinks that were used to configure
the previous framework using the following command:
$ find /etc/bash_completion.d -type l -delete
Thirdly, we have solved the issue causing bash-completion support to be
enabled by default on login shells only. If you needed to explicitly
source 'bash_completion' script in bashrc, you can safely remove that
code now since system-wide bashrc takes care of loading it.
Lastly, we would like to explain that USE=bash-completion is being
removed from packages for the completions will be installed
unconditionally now. However, this will result in some implicit
dependencies being removed. Most specifically, users wishing to use
bash-completion will have to request app-shells/bash-completion
explicitly, e.g.:
$ emerge -n app-shells/bash-completion
signature.asc
Description: PGP signature
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/20/2014 05:39 AM, hasufell wrote: I see a lot of things to figure out (especially PM-side, tools-side, maybe even PMS, maybe even repository layout, but also documentation and if it makes sense culture-wise), but I don't see a fundamental unsolvable problem here. It would be interesting to see a draft of those proposals. Could you start writing it somewhere on the wiki? Then we can discuss more concrete technical things. Even if it will not result in more distributed model for Gentoo, it could improve our current model of overlays. -- Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 11/20/14 04:37, Michał Górny wrote: Dnia 2014-11-19, o godz. 17:41:53 Diego Elio Pettenò flamee...@flameeyes.eu napisał(a): On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Comrel, please either do something about vapier or reassign all his packages (and team positions) to a volunteering proxy developer who will handle human relations for him. Chill dude. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 19/11/14 09:51 PM, Rich Freeman wrote: On Wed, Nov 19, 2014 at 8:41 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Guys, can we please give the volunteers who are going around uploading logs time to do their jobs before we go closing bugs as invalid? The logs are going to get attached. If somebody is in a mad rush to actually resolve the bug (heaven forbid), then just click on the link. My script is running every 10 minutes; I can do it more often than that but I don't want to hammer b.g.o if I don't have to. Also, as of now, it *does not* upload to bugs that are marked RESOLVED. I think I'll adjust that so it will upload to bugs marked RESO/NEEDINFO (and re-open them), but please, ^^^ And finally, if anyone sees an issue, including if bugs are not getting their attachments in a timely manner, please attach the bug to tracker bug 527870 and I'll do my best to fix things. Thanks, Ian -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRt/xkACgkQ2ugaI38ACPD1EwD9EdRh3peIX333vGwEcHtLribX nPcTun79Vk0yTULN2yUA/i3mkjmCrEhb2e785IuBVu+6aqnH3KU1pXCN9ahS4og2 =NWa6 -END PGP SIGNATURE-
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/11/14 09:47 AM, Ian Stakenvicius wrote: On 19/11/14 09:51 PM, Rich Freeman wrote: On Wed, Nov 19, 2014 at 8:41 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 31 October 2014 09:28, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So who wants to pick up the pieces now? Because I'm almost pissed off enough to turn down the tinderbox and give a big FU to Gentoo already. https://bugs.gentoo.org/show_bug.cgi?id=527608 More! https://bugs.gentoo.org/show_bug.cgi?id=529788 Again, is somebody going to stand up and do something or can I shut down my tinderbox and spend my free time playing Baldur's Gate? Guys, can we please give the volunteers who are going around uploading logs time to do their jobs before we go closing bugs as invalid? The logs are going to get attached. If somebody is in a mad rush to actually resolve the bug (heaven forbid), then just click on the link. My script is running every 10 minutes; I can do it more often than that but I don't want to hammer b.g.o if I don't have to. Also, as of now, it *does not* upload to bugs that are marked RESOLVED. I think I'll adjust that so it will upload to bugs marked RESO/NEEDINFO (and re-open them), but please, ^^^ And finally, if anyone sees an issue, including if bugs are not getting their attachments in a timely manner, please attach the bug to tracker bug 527870 and I'll do my best to fix things. Thanks, Ian Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlRuESgACgkQ2ugaI38ACPDR8AEAgdIvuivmg++PiDlUPfLOy7SR XUL5q4H+PFWRz077musA+gIbaPVFRBivJg11IXHHZtJVxj924iz/uyvNV+NlQyVF =YNpA -END PGP SIGNATURE-
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On Thu, 20 Nov 2014 01:36:32 +0100 hasufell hasuf...@gentoo.org wrote: Exherbo is already running a more modular approach, I'd be interested what they have to say about this or which problems they were facing. Well the big thing is that unlike Gentoo, Exherbo was able to switch to using Git for its repositories. On top of that, Exherbo also has proper automated tinderbox runs (with automated conflict resolution) for changes, including across repositories, and a much stronger culture of accepting that breaking changes to APIs and APIs that give an error on misuse are necessary for a quality product, and a tolerance of developers making those changes and then applying the fixes to other people's packages. Distributed is much easier to do if you're starting from something which is correct and verified... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
From: Julian Ospald hasuf...@gentoo.org
Date: Thu Nov 20 17:04:20 UTC 2014
Subject: Allow to disable games permissions wrt #467386
This also removes unnecessary exports of games
variables.
--- eclass/games.eclass
+++ eclass/games.eclass
@@ -19,25 +19,46 @@
*) die no support for EAPI=${EAPI} yet ;;
esac
+# Set to 0 to disable file permission modifications.
+GAMES_PERMISSIONS=${GAMES_PERMISSIONS:-1}
+
+# Set to 0 to set the games variables like GAMES_PREFIX to
+# match regular ebuilds if you don't want to micromanage them.
+GAMES_VARIABLES=${GAMES_VARIABLES:-1}
+
if [[ ${CATEGORY}/${PN} != games-misc/games-envd ]] ; then
# environment file
RDEPEND=games-misc/games-envd
fi
-export GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
-export GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}
-export GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}
-export GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share} # some packages
auto append 'games'
-export GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}
-export GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}
-export GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}
-export GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}
-export GAMES_ENVD=90games
+if [[ ${GAMES_VARIABLES} != 1 ]] ; then
+ GAMES_PREFIX=/usr
+ GAMES_PREFIX_OPT=/opt
+ GAMES_DATADIR=/usr/share
+ GAMES_DATADIR_BASE=/usr/share
+ GAMES_SYSCONFDIR=/etc
+ GAMES_STATEDIR=/var/lib
+ GAMES_LOGDIR=/var/log
+ GAMES_BINDIR=${GAMES_PREFIX}/bin
+ GAMES_USER=root
+ GAMES_USER_DED=root
+ GAMES_GROUP=root
+fi
+
+GAMES_PREFIX=${GAMES_PREFIX:-/usr/games}
+GAMES_PREFIX_OPT=${GAMES_PREFIX_OPT:-/opt}
+GAMES_DATADIR=${GAMES_DATADIR:-/usr/share/games}
+GAMES_DATADIR_BASE=${GAMES_DATADIR_BASE:-/usr/share} # some packages auto
append 'games'
+GAMES_SYSCONFDIR=${GAMES_SYSCONFDIR:-/etc/games}
+GAMES_STATEDIR=${GAMES_STATEDIR:-/var/games}
+GAMES_LOGDIR=${GAMES_LOGDIR:-/var/log/games}
+GAMES_BINDIR=${GAMES_BINDIR:-${GAMES_PREFIX}/bin}
+GAMES_ENVD=90games
# if you want to use a different user/group than games.games,
# just add these two variables to your environment (aka /etc/profile)
-export GAMES_USER=${GAMES_USER:-root}
-export GAMES_USER_DED=${GAMES_USER_DED:-games}
-export GAMES_GROUP=${GAMES_GROUP:-games}
+GAMES_USER=${GAMES_USER:-root}
+GAMES_USER_DED=${GAMES_USER_DED:-games}
+GAMES_GROUP=${GAMES_GROUP:-games}
games_get_libdir() {
echo ${GAMES_PREFIX}/$(get_libdir)
@@ -87,46 +108,56 @@
games_make_wrapper() { gameswrapper ${FUNCNAME/games_} $@; }
-gamesowners() { chown ${GAMES_USER}:${GAMES_GROUP} $@; }
-gamesperms() { chmod u+rw,g+r-w,o-rwx $@; }
+gamesowners() {
+ if [[ ${GAMES_PERMISSIONS} == 1 ]] ; then
+ chown ${GAMES_USER}:${GAMES_GROUP} $@
+ fi
+}
+gamesperms() {
+ if [[ ${GAMES_PERMISSIONS} == 1 ]] ; then
+ chmod u+rw,g+r-w,o-rwx $@;
+ fi
+}
prepgamesdirs() {
- local dir f mode
- for dir in \
- ${GAMES_PREFIX} ${GAMES_PREFIX_OPT} ${GAMES_DATADIR} \
- ${GAMES_SYSCONFDIR} ${GAMES_STATEDIR} $(games_get_libdir)
\
- ${GAMES_BINDIR} $@
- do
- [[ ! -d ${D}/${dir} ]] continue
- (
- gamesowners -R ${D}/${dir}
- find ${D}/${dir} -type d -print0 | xargs -0 chmod 750
- mode=o-rwx,g+r,g-w
- [[ ${dir} = ${GAMES_STATEDIR} ]] mode=o-rwx,g+r
- find ${D}/${dir} -type f -print0 | xargs -0 chmod
$mode
-
- # common trees should not be games owned #264872
- if [[ ${dir} == ${GAMES_PREFIX_OPT} ]] ; then
- fowners root:root ${dir}
- fperms 755 ${dir}
- for d in $(get_libdir) bin ; do
- # check if dirs exist to avoid
nonfatal option
- if [[ -e ${D}/${dir}/${d} ]] ; then
- fowners root:root ${dir}/${d}
- fperms 755 ${dir}/${d}
- fi
- done
+ if [[ ${GAMES_PERMISSIONS} == 1 ]] ; then
+ local dir f mode
+ for dir in \
+ ${GAMES_PREFIX} ${GAMES_PREFIX_OPT}
${GAMES_DATADIR} \
+ ${GAMES_SYSCONFDIR} ${GAMES_STATEDIR}
$(games_get_libdir) \
+ ${GAMES_BINDIR} $@
+ do
+ [[ ! -d ${D}/${dir} ]] continue
+ (
+ gamesowners -R ${D}/${dir}
+ find ${D}/${dir} -type d -print0 | xargs -0
chmod 750
+ mode=o-rwx,g+r,g-w
+ [[ ${dir} = ${GAMES_STATEDIR} ]]
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
I am running this since ~4 months straight without any problems.
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On Thu, 20 Nov 2014, hasufell wrote: From: Julian Ospald hasuf...@gentoo.org Date: Thu Nov 20 17:04:20 UTC 2014 Subject: Allow to disable games permissions wrt #467386 This also removes unnecessary exports of games variables. Wouldn't it be saner to have a new games-r1.eclass with fixed permissions, instead of adding such additional bloat to the existing eclass? Ulrich pgp7gXweSKJP5.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 11/20/2014 06:49 PM, Ulrich Mueller wrote: On Thu, 20 Nov 2014, hasufell wrote: From: Julian Ospald hasuf...@gentoo.org Date: Thu Nov 20 17:04:20 UTC 2014 Subject: Allow to disable games permissions wrt #467386 This also removes unnecessary exports of games variables. Wouldn't it be saner to have a new games-r1.eclass with fixed permissions, instead of adding such additional bloat to the existing eclass? Ulrich I don't intend to write another games eclass, I'd rather be interested in removing it altogether. This is just an intermediate solution IMO, for people who don't care about those permissions. If you look at the eclass, then it doesn't do much actual stuff, except for: * applying games permissions * installing files in non-standard locations So, games-r1.eclass would basically be empty.
Re: [gentoo-dev] [gentoo-project] Re: towards a more distributed model
On 11/20/2014 12:41 PM, Jauhien Piatlicki wrote: On 11/20/2014 05:39 AM, hasufell wrote: I see a lot of things to figure out (especially PM-side, tools-side, maybe even PMS, maybe even repository layout, but also documentation and if it makes sense culture-wise), but I don't see a fundamental unsolvable problem here. It would be interesting to see a draft of those proposals. Could you start writing it somewhere on the wiki? Then we can discuss more concrete technical things. Even if it will not result in more distributed model for Gentoo, it could improve our current model of overlays. https://wiki.gentoo.org/wiki/Distributed_Gentoo
Re: [gentoo-dev] Portage dependency solving algorithm
On 11/19/2014 11:59 AM, Andrew Savchenko wrote: Hello, On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote: On 11/17/2014 09:47 PM, Andrew Savchenko wrote: I use 2.2.14 on both hosts (and usually latest ~x86 portage is there). I thought that running fixpackages should be enough to run emerge with --dynamic-deps=n. It depends on how badly the installed deps have diverged from the corresponding ebuilds in the tree. I tried fixpackages. It fixed some problems and looks like dependencies resolution became faster. But not all problems are fixed and I can't use --dynamic-deps n on both systems for now; and emerge @changed-deps fails due to numerous conflicts, blocks, unsatisfied deps (this is not surprising, since it doesn't try to update all packages in tree). By the way, is there any way to unroll conflict lists in portage output? I mean if I have following: (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by =dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed) ^ (and 68 more with the same problem) How can I see all list of these 68 packages? Sometimes this feature is really desired, e.g. if I don't want to update all @world but need to apply GLSA fix which leads to similar conflicts. I can't find any switch in emerge manual. There's currently no switch for this. However, you can use a a command like this to see all installed packages that pull in your installed ghc: emerge -pv --depclean dev-lang/ghc I've filed a feature request bug for the switch that you have requested: https://bugs.gentoo.org/show_bug.cgi?id=529988 As for hitomi box, it is both slower and have much older packages, so I'm still struggling to fix conflicts and other issues. Results will be available later. From your results, it seems that _select_pkg_highest_available would be an obvious thing to optimize. This method already uses memoization, but the cache is entirely discarded each time that a package is added to the graph. I will see about making it salvage as much cache as possible when a package is added. P.S. Note for those who would like to use gpro2dot: it should be run with the same python interpreter active as was used during pstats data collection, otherwise it will fail to process data. I spent some time while figuring this out. I wasn't aware of that, so thanks for the tip. -- Thanks, Zac
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
Dnia 2014-11-20, o godz. 18:49:25 Ulrich Mueller u...@gentoo.org napisał(a): On Thu, 20 Nov 2014, hasufell wrote: From: Julian Ospald hasuf...@gentoo.org Date: Thu Nov 20 17:04:20 UTC 2014 Subject: Allow to disable games permissions wrt #467386 This also removes unnecessary exports of games variables. Wouldn't it be saner to have a new games-r1.eclass with fixed permissions, instead of adding such additional bloat to the existing eclass? Here's how games-r1 would look like. However, now that I think about it, it may be actually useful to commit such an eclass. Otherwise people will keep thinking games.eclass is the way to go. -- Best regards, Michał Górny # Copyright 1999-2014 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/eclass/games.eclass,v 1.158 2014/07/11 08:21:58 ulm Exp $ # @ECLASS: games-r1.eclass # @MAINTAINER: # mgo...@gentoo.org # @BLURB: eclass to help standarizing game install in Gentoo # @DESCRIPTION: # This is the modern eclass used to standarize games install in Gentoo. # It is intended to replace games.eclass, and should be used in game # ebuilds nowadays. # # However, since games do not need any special rules you are free not to # inherit this eclass if you don't want to. Or inherit it before other # eclasses that export phase functions. : signature.asc Description: PGP signature
Re: [gentoo-dev] Portage dependency solving algorithm
On 11/20/2014 12:19 PM, Zac Medico wrote: On 11/19/2014 11:59 AM, Andrew Savchenko wrote: Hello, On Mon, 17 Nov 2014 21:55:48 -0800 Zac Medico wrote: On 11/17/2014 09:47 PM, Andrew Savchenko wrote: I use 2.2.14 on both hosts (and usually latest ~x86 portage is there). I thought that running fixpackages should be enough to run emerge with --dynamic-deps=n. It depends on how badly the installed deps have diverged from the corresponding ebuilds in the tree. I tried fixpackages. It fixed some problems and looks like dependencies resolution became faster. But not all problems are fixed and I can't use --dynamic-deps n on both systems for now; and emerge @changed-deps fails due to numerous conflicts, blocks, unsatisfied deps (this is not surprising, since it doesn't try to update all packages in tree). By the way, is there any way to unroll conflict lists in portage output? I mean if I have following: (dev-lang/ghc-7.6.3-r1:0/7.6.3::gentoo, installed) pulled in by =dev-lang/ghc-6.8.2:0/7.6.3= required by (dev-haskell/random-1.0.1.1-r1:0/1.0.1.1::gentoo, installed) ^ (and 68 more with the same problem) How can I see all list of these 68 packages? Sometimes this feature is really desired, e.g. if I don't want to update all @world but need to apply GLSA fix which leads to similar conflicts. I can't find any switch in emerge manual. There's currently no switch for this. However, you can use a a command like this to see all installed packages that pull in your installed ghc: emerge -pv --depclean dev-lang/ghc I've filed a feature request bug for the switch that you have requested: https://bugs.gentoo.org/show_bug.cgi?id=529988 I forgot, we have a --verbose-conflicts option already. As for hitomi box, it is both slower and have much older packages, so I'm still struggling to fix conflicts and other issues. Results will be available later. From your results, it seems that _select_pkg_highest_available would be an obvious thing to optimize. This method already uses memoization, but the cache is entirely discarded each time that a package is added to the graph. I will see about making it salvage as much cache as possible when a package is added. I've written a patch, and it gives good results. On one of my computers with this patch, 'emerge -puvDN @world' takes 15% less time, and results in 58% fewer _select_pkg_highest_available_imp calls: https://bugs.gentoo.org/show_bug.cgi?id=530010 -- Thanks, Zac
[gentoo-dev] Re: [news item review] bash-completion-2.1-r90, version 2
Michał Górny posted on Thu, 20 Nov 2014 12:22:53 +0100 as excerpted: Thirdly, we have solved the issue causing bash-completion support to be enabled by default on login shells only. If you needed to explicitly source 'bash_completion' script in bashrc, you can safely remove that code now since system-wide bashrc takes care of loading it. FWIW, I lost bash-completion yesterday when I updated and both bash and bash-completion were updated. Fortunately I remembered that bash- completion's undergoing changes and the various discussion here (the heads-up on such changes that I get here being a big reason I'm subscribed), and was able to compare the binpkgs for the old and new versions to figure out what happened. It could be useful to say that if a user's custom config breaks, they need to change it to source the file in the new location, /etc/bash/ bashrc.d/bash_completion.sh, and that while they are at it they might want to simply source all (non-dot-file non-backup) files in that dir, as it's a new directory location designed to have files dropped into it to be sourced by bashrc, with such an approach being exactly what the default solution does. Or don't worry about it since users who have such custom configs should be able to handle it themselves, but risk a wave of bugs when they can't/ don't, at least before filing the bug. Without the heads-up from here I'd have certainly eventually figured it out, but it's an open question whether I'd have figured out the problem before I filed a bug, myself. (FWIW this is why a lot of news items end up pointing to a writeup on the wiki or dev-space with more details, because at some point people realize there's more detail there than appropriate for an ideally concise news item, but providing that link with further detail ends up being easier than dealing with the bug fallout if it's not provided. As the dev doing it, your choice of course, either way.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 11/20/14 5:04 PM, Ian Stakenvicius wrote: Ok, added the RESO/NEEDINFO case, and bumped my polling time to 5 minute intervals. Diego, please keep going, your efforts are still very much appreciated. +1, and thanks Ian for your script! Paweł signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] [PATCH v2] Add emerge --with-test-deps option for bug #520652
For packages matched by arguments, this option will pull in dependencies
that are conditional on the test USE flag, even if FEATURES=test is not
enabled for the matched packages. The state of the test USE flag is not
affected by this option. It only changes the effective dependencies
which are processed by the depgraph._add_pkg_deps method.
X-Gentoo-Bug: 520652
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=520652
---
PATCH v2 fixes the code in _add_pkg_deps to use _pkg_use_enabled instead
of accessing pkg.use.unabled directly (we should not bypass
_pkg_use_enabled unless there is a very good reason for it).
man/emerge.1 | 8 -
pym/_emerge/create_depgraph_params.py | 5 +++
pym/_emerge/depgraph.py | 24 +++--
pym/_emerge/main.py | 11 ++
pym/portage/tests/resolver/test_with_test_deps.py | 44 +++
5 files changed, 89 insertions(+), 3 deletions(-)
create mode 100644 pym/portage/tests/resolver/test_with_test_deps.py
diff --git a/man/emerge.1 b/man/emerge.1
index bbe71ac..a206e8e 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -1,4 +1,4 @@
-.TH EMERGE 1 Oct 2014 Portage VERSION Portage
+.TH EMERGE 1 Nov 2014 Portage VERSION Portage
.SH NAME
emerge \- Command\-line interface to the Portage system
.SH SYNOPSIS
@@ -894,6 +894,12 @@ installation actions, meaning they will not be installed,
and
This setting can be added to
\fBEMERGE_DEFAULT_OPTS\fR (see make.conf(5)) and later overridden via the
command line.
+.TP
+.BR \-\-with\-test\-deps [ y | n ]
+For packages matched by arguments, this option will pull in dependencies
+that are conditional on the test USE flag, even if test is not
+enabled in \fBFEATURES\fR for the matched packages. (see \fBmake.conf\fR(5)
+for more information about \fBFEATURES\fR settings).
.SH ENVIRONMENT OPTIONS
.TP
\fBEPREFIX\fR = \fI[path]\fR
diff --git a/pym/_emerge/create_depgraph_params.py
b/pym/_emerge/create_depgraph_params.py
index 225b792..6f74de7 100644
--- a/pym/_emerge/create_depgraph_params.py
+++ b/pym/_emerge/create_depgraph_params.py
@@ -21,6 +21,7 @@ def create_depgraph_params(myopts, myaction):
# removal by the --depclean action as soon as possible
# ignore_built_slot_operator_deps: ignore the slot/sub-slot := operator
parts
# of dependencies that have been recorded when packages where
built
+ # with_test_deps: pull in test deps for packages matched by arguments
myparams = {recurse : True}
bdeps = myopts.get(--with-bdeps)
@@ -104,6 +105,10 @@ def create_depgraph_params(myopts, myaction):
# other option like --update.
myparams.pop(selective, None)
+ with_test_deps = myopts.get(--with-test-deps)
+ if with_test_deps is not None:
+ myparams[with_test_deps] = with_test_deps
+
if '--debug' in myopts:
writemsg_level('\n\nmyparams %s\n\n' % myparams,
noiselevel=-1, level=logging.DEBUG)
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 6f1910d..505d8a8 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -2699,6 +2699,20 @@ class depgraph(object):
for k in Package._dep_keys:
edepend[k] = metadata[k]
+ use_enabled = self._pkg_use_enabled(pkg)
+
+ with_test_deps = not removal_action and \
+ with_test_deps in \
+ self._dynamic_config.myparams and \
+ pkg.depth == 0 and \
+ test not in use_enabled and \
+ pkg.iuse.is_valid_flag(test) and \
+ self._is_argument(pkg)
+
+ if with_test_deps:
+ use_enabled = set(use_enabled)
+ use_enabled.add(test)
+
if not pkg.built and \
--buildpkgonly in self._frozen_config.myopts and \
deep not in self._dynamic_config.myparams:
@@ -2782,7 +2796,7 @@ class depgraph(object):
try:
dep_string =
portage.dep.use_reduce(dep_string,
-
uselist=self._pkg_use_enabled(pkg),
+ uselist=use_enabled,
is_valid_flag=pkg.iuse.is_valid_flag,
opconvert=True,
token_class=Atom,
eapi=pkg.eapi)
@@ -2797,7 +2811,7 @@ class depgraph(object):
# practical to ignore this issue for
installed packages.
try:
dep_string =
portage.dep.use_reduce(dep_string,
-
[gentoo-portage-dev] [PATCH] emerge: check for writable PKGDIR (490732)
If there are packages to be merged and buildpkg or buildsyspkg is
enabled, then bail out early if PKGDIR is not writable (in order to
avoid a fatal EROFS error which would otherwise occur later on).
Behavior remains unchanged for --pretend, --fetchonly and
--fetch-all-uri. For --ask, it will bail out just after the last
relevant --ask prompt.
X-Gentoo-Bug: 490732
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=490732
---
pym/_emerge/actions.py | 28 ++--
pym/portage/dbapi/bintree.py | 12
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index 6f7dfe0..dec5b04 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -428,7 +428,18 @@ def action_build(settings, trees, mtimedb,
# least show warnings about missed updates and such.
mydepgraph.display_problems()
- if not Scheduler._opts_no_self_update.intersection(myopts):
+
+ need_write_vardb = not Scheduler. \
+ _opts_no_self_update.intersection(myopts)
+
+ need_write_bindb = not any(x in myopts for x in
+ (--fetchonly, --fetch-all-uri, --pretend)) and \
+ (any(buildpkg in trees[eroot][root_config].
+ settings.features for eroot in trees) or
+ any(buildsyspkg in trees[eroot][root_config].
+ settings.features for eroot in trees))
+
+ if need_write_bindb or need_write_vardb:
eroots = set()
for x in mydepgraph.altlist():
@@ -436,13 +447,26 @@ def action_build(settings, trees, mtimedb,
eroots.add(x.root)
for eroot in eroots:
- if not trees[eroot][vartree].dbapi.writable:
+ if need_write_vardb and \
+ not
trees[eroot][vartree].dbapi.writable:
writemsg_level(!!! %s\n %
_(Read-only file system: %s) %
trees[eroot][vartree].dbapi._dbroot,
level=logging.ERROR,
noiselevel=-1)
return 1
+ if need_write_bindb and \
+ (buildpkg in
trees[eroot][root_config].
+ settings.features or
+ buildsyspkg in
trees[eroot][root_config].
+ settings.features) and \
+ not
trees[eroot][bintree].dbapi.writable:
+ writemsg_level(!!! %s\n %
+ _(Read-only file system: %s) %
+ trees[eroot][bintree].pkgdir,
+ level=logging.ERROR,
noiselevel=-1)
+ return 1
+
if (--resume in myopts):
favorites=mtimedb[resume][favorites]
diff --git a/pym/portage/dbapi/bintree.py b/pym/portage/dbapi/bintree.py
index a5d7ac9..b56c8c1 100644
--- a/pym/portage/dbapi/bintree.py
+++ b/pym/portage/dbapi/bintree.py
@@ -18,6 +18,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util:atomic_ofstream,ensure_dirs,normalize_path,' + \
'writemsg,writemsg_stdout',
'portage.util.listdir:listdir',
+ 'portage.util.path:first_existing',
'portage.util._urlopen:urlopen@_urlopen',
'portage.versions:best,catpkgsplit,catsplit,_pkg_str',
)
@@ -85,6 +86,17 @@ class bindbapi(fakedbapi):
self._aux_cache_slot_dict =
slot_dict_class(self._aux_cache_keys)
self._aux_cache = {}
+ @property
+ def writable(self):
+
+ Check if PKGDIR is writable, or permissions are sufficient
+ to create it if it does not exist yet.
+ @rtype: bool
+ @return: True if PKGDIR is writable or can be created,
+ False otherwise
+
+ return os.access(first_existing(self.bintree.pkgdir), os.W_OK)
+
def match(self, *pargs, **kwargs):
if self.bintree and not self.bintree.populated:
self.bintree.populate()
--
2.0.4
[gentoo-portage-dev] [PATCH] _select_pkg_highest_available: selective cache invalidation (530010)
Implement selective invalidation of cache for the
depgraph._select_pkg_highest_available method, so that the entire cache
is not discarded whenever a package is added to the graph. On one of my
computers with this patch, 'emerge -puvDN @world' takes 15% less time,
and results in 58% fewer _select_pkg_highest_available_imp calls.
X-Gentoo-Bug: 530010
X-Gentoo-Url: https://bugs.gentoo.org/show_bug.cgi?id=530010
---
pym/_emerge/Package.py | 18 --
pym/_emerge/depgraph.py | 14 +-
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/pym/_emerge/Package.py b/pym/_emerge/Package.py
index a09f73c..8612e8b 100644
--- a/pym/_emerge/Package.py
+++ b/pym/_emerge/Package.py
@@ -35,8 +35,8 @@ class Package(Task):
category, counter, cp, cpv_split,
inherited, iuse, mtime,
pf, root, slot, sub_slot, slot_atom, version) + \
- (_invalid, _masks, _metadata, _raw_metadata, _use,
- _validated_atoms, _visible)
+ (_invalid, _masks, _metadata, _provided_cps,
+ _raw_metadata, _use, _validated_atoms, _visible)
metadata_keys = [
BUILD_TIME, CHOST, COUNTER, DEPEND, EAPI,
@@ -128,6 +128,20 @@ class Package(Task):
return self._metadata.properties
@property
+ def provided_cps(self):
+
+ if self._provided_cps is None:
+ provided_cps = [self.cp]
+ for atom in self._metadata[PROVIDE].split():
+ try:
+ provided_cps.append(Atom(atom).cp)
+ except InvalidAtom:
+ pass
+ self._provided_cps = tuple(provided_cps)
+
+ return self._provided_cps
+
+ @property
def restrict(self):
return self._metadata.restrict
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 3f4a097..ab79aef 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -399,6 +399,7 @@ class _dynamic_depgraph_config(object):
self._initially_unsatisfied_deps = []
self._ignored_deps = []
self._highest_pkg_cache = {}
+ self._highest_pkg_cache_cp_map = {}
self._flatten_atoms_cache = {}
# Binary packages that have been rejected because their USE
@@ -2539,8 +2540,8 @@ class depgraph(object):
if not previously_added:
self._dynamic_config._package_tracker.add_pkg(pkg)
self._dynamic_config._filtered_trees[pkg.root][porttree].dbapi._clear_cache()
- self._dynamic_config._highest_pkg_cache.clear()
self._check_masks(pkg)
+ self._prune_highest_pkg_cache(pkg)
if not pkg.installed:
# Allow this package to satisfy old-style
virtuals in case it
@@ -2685,6 +2686,7 @@ class depgraph(object):
# Clear caches.
self._dynamic_config._filtered_trees[pkg.root][porttree].dbapi._clear_cache()
self._dynamic_config._highest_pkg_cache.clear()
+ self._dynamic_config._highest_pkg_cache_cp_map.clear()
def _check_masks(self, pkg):
@@ -3967,6 +3969,7 @@ class depgraph(object):
# Invalidate the package selection cache, since
# arguments influence package selections.
self._dynamic_config._highest_pkg_cache.clear()
+ self._dynamic_config._highest_pkg_cache_cp_map.clear()
for trees in self._dynamic_config._filtered_trees.values():
trees[porttree].dbapi._clear_cache()
@@ -4987,6 +4990,8 @@ class depgraph(object):
return ret
ret = self._select_pkg_highest_available_imp(root, atom,
onlydeps=onlydeps, parent=parent)
self._dynamic_config._highest_pkg_cache[cache_key] = ret
+ self._dynamic_config._highest_pkg_cache_cp_map. \
+ setdefault(atom.cp, []).append(cache_key)
pkg, existing = ret
if pkg is not None:
if self._pkg_visibility_check(pkg) and \
@@ -4994,6 +4999,13 @@ class depgraph(object):
self._dynamic_config._visible_pkgs[pkg.root].cpv_inject(pkg)
return ret
+ def _prune_highest_pkg_cache(self, pkg):
+ for cp in pkg.provided_cps:
+ for cache_key in self._dynamic_config. \
+ _highest_pkg_cache_cp_map.pop(cp, []):
+ self._dynamic_config._highest_pkg_cache.pop(
+ cache_key, None)
+
def
