Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
* Michał Górny schrieb am 10.11.14 um 22:18 Uhr: 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. Looks good to me, but to remove stale symlinks you need to add the -L option to find. Or write just symlinks, because like this it will remove *all* symlinks. $ find /etc/bash_completion.d -type l -delete -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer msch...@gentoo.org napisał(a): * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: 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. Looks good to me, but to remove stale symlinks you need to add the -L option to find. Or write just symlinks, because like this it will remove *all* symlinks. Well, the meaning was 'all symlinks since they are stale now'. I will try to reword it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)
On 11/11/14 01:41, Mike Frysinger wrote: On 01 Sep 2014 06:30, Samuli Suominen wrote: On 01/09/14 03:37, Patrick Lauer wrote: Consider this message a prenotice, now you know it's gone ... one more win for eudev. Sigh. They are planning in dropping the userspace loader as well, it's redudant afterall. Most firmware are kernel loadable by = 3.7 Everything is kernel loadable (3.7 and few later versions had some exceptions for more rare drivers) in latest echo /bin/busybox mdev /proc/sys/kernel/hotplug -mike I will continue to maintain eudev 1.10.x which has userland firmware loading support. Versions 2.0 and above removed it. -- 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] [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 09:53:58
Marc Schiffbauer msch...@gentoo.org napisał(a):
* Michał Górny schrieb am 10.11.14 um 22:18 Uhr:
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.
Looks good to me, but to remove stale symlinks you need to add the
-L option to find. Or write just symlinks, because like this it
will remove *all* symlinks.
Is the attached version more clear?
--
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
Lastly, 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.
signature.asc
Description: PGP signature
[gentoo-dev] Re: [news item review] bash-completion-2.1-r90, version 2
Michał Górny posted on Tue, 11 Nov 2014 11:03:03 +0100 as excerpted: Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer msch...@gentoo.org napisał(a): * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: 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. Looks good to me, but to remove stale symlinks you need to add the -L option to find. Or write just symlinks, because like this it will remove *all* symlinks. Well, the meaning was 'all symlinks since they are stale now'. I will try to reword it. Note that some users (including me) have symlinks in /etc/bash_completion.d/ that point to their own completions in /usr/local/share/bash_completion/ or the like. Now I don't claim to know much about creating completions, but for instance, many of my completions were for emerge stubs (ea for emerge --ask, etc), so I was able to simply source the gentoo completion in my own, then use emerge's completion function for my stubs. With this update I had to figure out enough about completions to figure out how to update mine, and I've already done so. But, the symlinks pointing to my completions in /usr/local are most assuredly *NOT* stale, neither will remerging anything make them so. So I don't want to remove those symlinks, or I'd lose the connection to my own completions (presuming the normal bash completion doesn't look in /usr/local/share/bash_completion for them... I never claimed I to be a bash-completion wizard, only to have hacked up something that seems to work, and I want it to STAY working). So if indeed all installed symlinks should be stale at that point, then the suggested -L -type l -delete would be a good change, as it wouldn't remove any non-stale symlinks users had put there themselves. -- 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] Re: [news item review] bash-completion-2.1-r90, version 2
Dnia 2014-11-11, o godz. 11:21:00 Duncan 1i5t5.dun...@cox.net napisał(a): Michał Górny posted on Tue, 11 Nov 2014 11:03:03 +0100 as excerpted: Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer msch...@gentoo.org napisał(a): * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: 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. Looks good to me, but to remove stale symlinks you need to add the -L option to find. Or write just symlinks, because like this it will remove *all* symlinks. Well, the meaning was 'all symlinks since they are stale now'. I will try to reword it. Note that some users (including me) have symlinks in /etc/bash_completion.d/ that point to their own completions in /usr/local/share/bash_completion/ or the like. If you do custom stuff like this, you already know enough to understand the consequences of removing the symlinks. You were on your own already, so don't expect that we're going to start holding your hand now. But, the symlinks pointing to my completions in /usr/local are most assuredly *NOT* stale, neither will remerging anything make them so. So I don't want to remove those symlinks, or I'd lose the connection to my own completions (presuming the normal bash completion doesn't look in /usr/local/share/bash_completion for them... I never claimed I to be a bash-completion wizard, only to have hacked up something that seems to work, and I want it to STAY working). Of course, you could have asked for proper /usr/local support... but why? It's easier to hack things around then complain. So if indeed all installed symlinks should be stale at that point, then the suggested -L -type l -delete would be a good change, as it wouldn't remove any non-stale symlinks users had put there themselves. People who installed bash-completion after 27.08 have all completions in completionsdir already. For them, the symlinks will still be valid yet unnecessary. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [news item review] bash-completion-2.1-r90, version 2
* Michał Górny schrieb am 11.11.14 um 12:06 Uhr: Dnia 2014-11-11, o godz. 09:53:58 Marc Schiffbauer msch...@gentoo.org napisał(a): * Michał Górny schrieb am 10.11.14 um 22:18 Uhr: 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. Looks good to me, but to remove stale symlinks you need to add the -L option to find. Or write just symlinks, because like this it will remove *all* symlinks. Is the attached version more clear? Yes, I think so. -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
[gentoo-dev] Packages up for grabs
Hello all, Due to lack of time I'm giving up some packages. Feel free to take them. I'll remove myself from metadata in the following packages within 10 days: * app-admin/cronolog * app-misc/recoll * app-shells/sash * dev-vcs/mr * dev-vcs/vcsh * net-analyzer/portbunny * net-libs/udns Comaintained packages(herds,devs): * app-admin/denyhosts * dev-python/tweepy * kde-misc/kimtoy * kde-misc/plasma-network-status * net-im/turses I will also drop myself from the net-proxy herd. Thanks, Pavlos Ratis
Re: [gentoo-dev] Packages up for grabs
Am 11. Nov 2014, 15:59 schrieb Pavlos Ratis daster...@gentoo.org: * dev-vcs/mr I can take care of this one - I use dev-vcs/mr quite heavily. Best, Matthias
Re: [gentoo-dev] Packages up for grabs
* dev-vcs/mr * dev-vcs/vcsh On second thought, I think, I'll adapt both of them. :-) Best, Matthias
[gentoo-dev] [news item review] sys-devel/kgcc64 removal on sparc
Hi, Please have a look at the following news item. Thanks! Title: sys-devel/kgcc64 removal on sparc Author: Raúl Porcel armi...@gentoo.org Content-Type: text/plain Posted: 2014-11-11 Revision: 1 News-Item-Format: 1.0 Display-If-Profile: default/linux/sparc sys-devel/kgcc64 is going to be removed from the sparc system package set since the normal sys-devel/gcc can, since version 4.4, build 64bit kernels. Until now, you had to use CONFIG_CROSS_COMPILE=sparc64-unknown-linux-gnu- in your kernel configuration, but with sys-devel/kgcc64 going away, you need to remove that option.
Re: [gentoo-portage-dev] [PATCH] unprivileged mode: generate PORTAGE_DEPCACHEDIR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/11/14 01:17, Zac Medico wrote: We could certainly express it in a way that doesn't involve any mutating loop control variables, but ultimately that's going to lead to more lines of code, and it will leave imperative programmers wondering why we didn't choose a simpler and more succinct approach. For example, we could create an class for iterating over the paths from a given path down to the root directory. Then we could create a function which selects the first element from that iterator that exists. Once the class and function are implemented, their usage would be very succinct: first_parent = first_existing(iter_parents(path)) I would greatly prefer this. But I suppose I'm in a minority. v2 of the patch is fine by me. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlRh04kACgkQRtClrXBQc7Wg7AD/WmncYIvR/f6OZ9W2mVfpgMmL pZRD+68xWgWTdvatodYBAIX9VfX/0kINsmV9RhzumhLnHYE7LMz43nLy+yrekbxp =H68V -END PGP SIGNATURE-
[gentoo-portage-dev] [PATCH] _selinux.setexec: improve failure message (525726)
From: Sven Vermeulen sw...@gentoo.org This converts OSError: [Errno 22] Invalid argument into a more meaningful error message that is to designed to guide users in the right direction. Also, add an import that was missing for the sys module, since is referenced in the error paths of many functions in this module. X-Gentoo-Bug: 525726 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=525726 --- pym/portage/_selinux.py | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/pym/portage/_selinux.py b/pym/portage/_selinux.py index 2a7194c..c5e8b2c 100644 --- a/pym/portage/_selinux.py +++ b/pym/portage/_selinux.py @@ -5,6 +5,7 @@ # the whole _selinux module itself will be wrapped. import os import shutil +import sys import portage from portage import _encodings @@ -77,7 +78,18 @@ def settype(newtype): def setexec(ctx=\n): ctx = _native_string(ctx, encoding=_encodings['content'], errors='strict') - if selinux.setexeccon(ctx) 0: + rc = 0 + try: + rc = selinux.setexeccon(ctx) + except OSError: + msg = _(Failed to set new SELinux execution context. + \ + Is your current SELinux context allowed to run Portage?) + if selinux.security_getenforce() == 1: + raise OSError(msg) + else: + portage.writemsg(!!! %s\n % msg, noiselevel=-1) + + if rc 0: if sys.hexversion 0x300: ctx = _unicode_decode(ctx, encoding=_encodings['content'], errors='replace') if selinux.security_getenforce() == 1: -- 2.0.4
Re: [gentoo-portage-dev] [PATCH] _selinux.setexec: improve failure message (525726)
On Tue, 11 Nov 2014 13:52:04 -0800 Zac Medico zmed...@gentoo.org wrote: From: Sven Vermeulen sw...@gentoo.org This converts OSError: [Errno 22] Invalid argument into a more meaningful error message that is to designed to guide users in the right direction. Also, add an import that was missing for the sys module, since is referenced in the error paths of many functions in this module. X-Gentoo-Bug: 525726 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=525726 --- pym/portage/_selinux.py | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) LGTM, merge your fixed patch. Thank you Swen and Zac -- Brian Dolbec dolsen
[gentoo-portage-dev] [PATCH] dep_zapdeps: avoid use.mask/force changes (515584)
This patch causes dep_zapdeps to check which USE flags cause a match
to fail, and uses that information to prioritize choices that do not
require changes to use.mask or use.force.
X-Gentoo-Bug: 515584
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=515584
---
pym/portage/dep/dep_check.py | 36 -
pym/portage/tests/resolver/test_or_choices.py | 58 ++-
2 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/pym/portage/dep/dep_check.py b/pym/portage/dep/dep_check.py
index 62f42ac..ccdda59 100644
--- a/pym/portage/dep/dep_check.py
+++ b/pym/portage/dep/dep_check.py
@@ -317,6 +317,7 @@ def dep_zapdeps(unreduced, reduced, myroot, use_binaries=0,
trees=None):
priority = trees[myroot].get(priority)
graph_db = trees[myroot].get(graph_db)
graph= trees[myroot].get(graph)
+ pkg_use_enabled = trees[myroot].get(pkg_use_enabled)
want_update_pkg = trees[myroot].get(want_update_pkg)
vardb = None
if vartree in trees[myroot]:
@@ -349,6 +350,7 @@ def dep_zapdeps(unreduced, reduced, myroot, use_binaries=0,
trees=None):
all_available = True
all_use_satisfied = True
+ all_use_unmasked = True
slot_map = {}
cp_map = {}
for atom in atoms:
@@ -369,6 +371,32 @@ def dep_zapdeps(unreduced, reduced, myroot,
use_binaries=0, trees=None):
avail_pkg_use = mydbapi_match_pkgs(atom)
if not avail_pkg_use:
all_use_satisfied = False
+
+ if pkg_use_enabled is not None:
+ # Check which USE flags cause
the match to fail,
+ # so we can prioritize choices
that do not
+ # require changes to use.mask
or use.force
+ # (see bug #515584).
+ violated_atom =
atom.violated_conditionals(
+
pkg_use_enabled(avail_pkg),
+
avail_pkg.iuse.is_valid_flag)
+
+ # Note that violated_atom.use
can be None here,
+ # since evaluation can collapse
conditional USE
+ # deps that cause the match to
fail due to
+ # missing IUSE (match uses
atom.unevaluated_atom
+ # to detect such missing IUSE).
+ if violated_atom.use is not
None:
+ for flag in
violated_atom.use.enabled:
+ if flag in
avail_pkg.use.mask:
+
all_use_unmasked = False
+ break
+ else:
+ for flag in
violated_atom.use.disabled:
+ if flag
in avail_pkg.use.force and \
+
flag not in avail_pkg.use.mask:
+
all_use_unmasked = False
+
break
else:
# highest (ascending order)
avail_pkg_use = avail_pkg_use[-1]
@@ -416,7 +444,9 @@ def dep_zapdeps(unreduced, reduced, myroot, use_binaries=0,
trees=None):
else:
preferred_non_installed.append(this_choice)
else:
- if all_installed_slots:
+ if not all_use_unmasked:
+ other.append(this_choice)
+ elif all_installed_slots:
unsat_use_installed.append(this_choice)
else:
unsat_use_non_installed.append(this_choice)
@@ -490,7 +520,9 @@ def dep_zapdeps(unreduced, reduced, myroot, use_binaries=0,
trees=None):
else:
