[gentoo-dev] Re: Re: Looking for alternative to RESTRICT=userpriv
On Sun, Oct 05, 2014, Zac Medico wrote: On 10/02/2014 07:32 PM, Steven J. Long wrote: On Tue, Sep 30, 2014, Zac Medico wrote: On Mon, Sep 29, 2014, Zac Medico wrote: We control the shell code that launches the requested command, so we can save the environment after the requested command completes (using a modified version of our existing environment persistence code). snip You're thinking in terms of a SUID helper like sudo. The implementation that I've been suggesting does not involve a SUID helper. No, I'm thinking in terms of a process with elevated privileges running a specific command; whether that first process is started by us or not, is irrelevant to whether it can get the environment from a child process we have no control over, after it completes. You're assuming that we have no control over the child process, which would be true with a SUID helper like sudo (in the absence of a wrapper script, see below) that is only designed to run a specific command and then exit without saving the enviroment. I've already agreed you can run a shell command that you control: that's equivalent to running a process whose code you control. However, imagine a helper that is designed to run a requested shell command and then save the environment before it exits. It could be done with sudo if you simply required that the first argument to sudo be a wrapper script that executes the requested command and then saves the environment. For example, consider the following usage: sudo /foo/bar/wrapper.sh requested shell command with arguments If the sudo command is constructed shown above, then wrapper.sh can load an arbitrary environment, execute the requested shell command with arguments, and then save the resulting environment afterwards. What command exactly? Since after any external it runs, which I thought was the whole point of this, it can't get the resultant env. You're in the same situation, only you're discussing a shell command as opposed to a privileged process. I'm just trying to get at which env exactly you think you're getting. Sure it can save its own, but since it's a generic run any command helper, it can't do much more than give us back what we gave it, unless you're talking about echoing back settings, in the manner of gpg et al, which by definition is not about the saved env. That's why we have to use that format in the first place; because the env setting must be done by the process which wants to use it (have it inherited for child processes), for the same reason: a child process can never affect the parent env. We could implement esudo so that it will insert wrapper.sh into the sudo arguments, so that the caller doesn't have to know anything about the wrapper.sh implementation details. For example: esudo requested shell command with arguments So that's going to call the listener with a string to eval(gack) and the listener will then launch a bash process to evaluate the line, correct? Given that this is ebuild context, that's likely going to be a process that loads the env saved before the call, in order to have access to the functions and metadata declared in the ebuild. And then evaluates the line given (which sets off all sorts of alarm-bells). In the typical case that's just going to be an external we could have called anyway. In the case pertinent to this discussion, there is some sort of env-setting going on. But not from externals, unless of the gpg-ilk such that we can load any variable settings they give us, or they write out to a file we can source; iow not from 99% of externals. Presumably the shell line (I'd guess a call to a saved function in env) is going to export settings back to the env, which will be saved by the usual mechanism. Is that about right? So, the privilege escalation mechanism is indeed irrelevant, as long as there's some opportunity to insert a wrapper script that runs with escalated privileges, allowing it to load/save the environment at the appropriate time during shell execution. Yeah we just run a shell script (as a privileged user). Which can save its own env off for sure; just not the env from some external it happens to run, which is usually the functional aspect of a shell script. It could run something like gpg et al which give an env return, as I described before. Instead, IPC would be used to request that the privileged parent process launch a new privileged process on behalf of esudo. In this context, unless the esudo implementation provides explicit support for environment inheritance, the new privileged process will not inherit any environment from the environment where esudo was called. Well, assuming that were the implementation, that explains why you'd want to save the env off, so that the privileged helper can access it. It still sounds like more work in the long run in terms of what's happening, but regardless: it doesn't get you the
Re: [gentoo-dev] Re: Re: Looking for alternative to RESTRICT=userpriv
On 10/11/2014 12:06 AM, Steven J. Long wrote: On Sun, Oct 05, 2014, Zac Medico wrote: On 10/02/2014 07:32 PM, Steven J. Long wrote: On Tue, Sep 30, 2014, Zac Medico wrote: On Mon, Sep 29, 2014, Zac Medico wrote: We control the shell code that launches the requested command, so we can save the environment after the requested command completes (using a modified version of our existing environment persistence code). snip You're thinking in terms of a SUID helper like sudo. The implementation that I've been suggesting does not involve a SUID helper. No, I'm thinking in terms of a process with elevated privileges running a specific command; whether that first process is started by us or not, is irrelevant to whether it can get the environment from a child process we have no control over, after it completes. You're assuming that we have no control over the child process, which would be true with a SUID helper like sudo (in the absence of a wrapper script, see below) that is only designed to run a specific command and then exit without saving the enviroment. I've already agreed you can run a shell command that you control: that's equivalent to running a process whose code you control. However, imagine a helper that is designed to run a requested shell command and then save the environment before it exits. It could be done with sudo if you simply required that the first argument to sudo be a wrapper script that executes the requested command and then saves the environment. For example, consider the following usage: sudo /foo/bar/wrapper.sh requested shell command with arguments If the sudo command is constructed shown above, then wrapper.sh can load an arbitrary environment, execute the requested shell command with arguments, and then save the resulting environment afterwards. What command exactly? Since after any external it runs, which I thought was the whole point of this, it can't get the resultant env. You're in the same situation, only you're discussing a shell command as opposed to a privileged process. I'm just trying to get at which env exactly you think you're getting. The shell env consists of shell variables and functions. Maybe it helps if I explain it in terms of existing ebuild phases that are already supported. For example, pkg_setup runs as root, and the ebuild's shell enviroment is saved. This environment contains the ebuild functions and variables as well as the functions and variables of the eclasses it inherits. When the src_unpack phase is called, it runs as the portage user, and it's able to load the environment from pkg_setup. So, we have two phases sharing/mutating the same shell environment, yet they run as different users with different privileges. The pkg_setup/src_unpack environment sharing is very similar to the environment sharing that I have suggested for esudo. You can consider them to be practically identical, except that esudo will allow an unprivileged phase to launch a privileged shell with a shared environment, using basically the same mechanics that allow pkg_setup and src_unpack to share the same environment. Sure it can save its own, but since it's a generic run any command helper, it can't do much more than give us back what we gave it, unless you're talking about echoing back settings, in the manner of gpg et al, which by definition is not about the saved env. That's why we have to use that format in the first place; because the env setting must be done by the process which wants to use it (have it inherited for child processes), for the same reason: a child process can never affect the parent env. We could implement esudo so that it will insert wrapper.sh into the sudo arguments, so that the caller doesn't have to know anything about the wrapper.sh implementation details. For example: esudo requested shell command with arguments So that's going to call the listener with a string to eval(gack) and the listener will then launch a bash process to evaluate the line, correct? Given that this is ebuild context, that's likely going to be a process that loads the env saved before the call, in order to have access to the functions and metadata declared in the ebuild. And then evaluates the line given (which sets off all sorts of alarm-bells). Right. In the typical case that's just going to be an external we could have called anyway. In the case pertinent to this discussion, there is some sort of env-setting going on. But not from externals, unless of the gpg-ilk such that we can load any variable settings they give us, or they write out to a file we can source; iow not from 99% of externals. Presumably the shell line (I'd guess a call to a saved function in env) is going to export settings back to the env, which will be saved by the usual mechanism. Is that about right? Right. Maybe I should have read your this part of your email before I wrote the pkg_setup/src_unpack example above,
Re: [gentoo-dev] Re: virtual/{posix,stage1,2,3} Was: Add bc back to the stage3
On Sat, Oct 11, 2014 at 1:25 AM, Steven J. Long sl...@rathaus.eclipse.co.uk wrote: Not arguing with your use-case. Just wondering why ed and bc are considered such major burdens, but polkit+systemd+udev+dbug+glib+glibc+godknows are a minimal base. Nobody is talking about adding most of that stuff to the @system set. The issue is that in general we're trying to reduce @system and list explicit dependencies. Honestly, my personal preference would be to ditch it altogether as an implicit set of dependencies. I'm all for having virtuals or profiles that make it easy for users to install commonly-used sets of packages, including convenience ones that reflect particular configurations. The whole idea of dependencies, however, is that we don't have to have endless debates about whether dbus is or isn't a great package to install by default. Instead, people just install the packages they want, and they get the baggage that necessarily comes along with it. So, this isn't about keeping ed/bc out while we have openssh of all things in. The concern is more about not adding more to something that feels more like a hack at this point, and finding a better way of letting users easily have sane defaults. In the end, it is actually about choice. If done right it should actually make it easier for you to have a system free of udev+glibc (I don't think the rest of what you put there is part of the system set today). -- Rich
[gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
In my earlier thread http://thread.gmane.org/gmane.linux.gentoo.devel/92113 I explored the possibility to stabilize gcc-4.8, and we have that going now in https://bugs.gentoo.org/show_bug.cgi?id=516152. Meanwhile I just applied a small patch for chromium-38 that allows it to compile with gcc-4.7. It's in stable now. We'll really need gcc-4.8 in stable within 6-12 weeks from now. Chromium starts making heavy use of C++11 language features, see http://chromium-cpp.appspot.com/ . I don't realistically see us being able to just patch chromium to work around that. I'd like to ask for every possible help with https://bugs.gentoo.org/show_bug.cgi?id=461954 blockers on amd64 and x86. There are harder problems on arches like MIPS, but newer gcc is not as urgent there I think. One highlight is https://bugs.gentoo.org/show_bug.cgi?id=513386. It occurs only when the user has gcc-4.7 and 4.8 installed simultaneously and using 4.7 as the active compiler. It's not obvious to me whether we have to support this (while it's obviously better to support rather than not, it's webkit-gtk in a specific and rare configuration versus chromium with security updates in all configurations). There is also https://bugs.gentoo.org/show_bug.cgi?id=500966 which may be more tricky. I could reproduce that bug. It's also about webkit-gtk. There are couple more blockers of https://bugs.gentoo.org/show_bug.cgi?id=461954. If you can, please take a look and help. I think several other distros are using gcc-4.8 or later now, they may have hit the same problems and either have patches or something that could also help us. There may be some upstream patches to be backported etc. Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Unify keyring related USE flags
Hello I am wondering about current status of keyring related USE flags: - gnome-keyring USE is listed as global USE - libsecret is a local USE - wallet is local (only used by one package now) I think we should simply have a keyring USE flag to enable what most people will want - keyring support. What do you think? I am not sure what kind of USE flags are other desktops but Gnome/MATE using :S Thanks a lot
[gentoo-dev] last rites: dev-perl/Template-Latex
# Andreas K. Huettel dilfri...@gentoo.org (11 Oct 2014) # Outdated and unused; masked for removal in 30 days dev-perl/Template-Latex -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev]
There's a bunch of hype about ubuntu for the power 8 (new power 8 Tyan boards which apparently exist but i cant find them anywhere.) I thought gentoo always had a power fork anyway, not sure what the big deal is. I really wish i could find a board and cpu though. They need to release some for sale soon as in like now. -- Sent from my Android device with K-9 Mail.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
I took a look a the list of the current blocker of gcc-4.8 and many / most of them seem to be hardend or x86 related. Right now I'm using an amd64 linux with some freaky lto + heavily optimized make.conf flags and didn't find a gcc-4.8 related bug. Except the usual list of package just not ready for lto. But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. signature.asc Description: PGP signature
Re: [gentoo-dev] Unify keyring related USE flags
В Sat, 11 Oct 2014 17:02:20 +0200
Pacho Ramos pa...@gentoo.org пишет:
Hello
I am wondering about current status of keyring related USE flags:
- gnome-keyring USE is listed as global USE
- libsecret is a local USE
- wallet is local (only used by one package now)
Err.. wallet USE flag is completely unrelated. This wallet is for
bitcoins, it's not a keyring for passwords. :)
There are also gnome and kde USE flags. Note that the following
command doesn't catch multiline USE-conditional dependencies.
$ find . -type f -name *.ebuild -exec egrep -e 'kde\?.*kwallet' -e
'gnome\?.*gnome-keyring' '{}' \+
./dev-vcs/subversion/subversion-1.8.9.ebuild: kde? ( kde-base/kwalletd )
./dev-vcs/subversion/subversion-1.8.10.ebuild: kde? ( kde-base/kwalletd )
./dev-vcs/subversion/subversion-1.7.18.ebuild: kde? ( kde-base/kwalletd )
./media-gfx/darktable/darktable-1.2.3.ebuild: kde? ( kde-base/kwalletd )
./media-gfx/darktable/darktable-1.4.1-r1.ebuild:kde? (
kde-base/kwalletd )
./media-gfx/darktable/darktable-1.4.2.ebuild: kde? ( kde-base/kwalletd )
./media-gfx/darktable/darktable-1.4.ebuild: kde? ( kde-base/kwalletd )
./media-gfx/darktable/darktable-.ebuild:kde? ( kde-base/kwalletd )
./media-sound/cantata/cantata-1.3.3.ebuild: kde? ( $(add_kdebase_dep
kwalletd) )
./media-sound/cantata/cantata-1.3.4.ebuild: kde? ( $(add_kdebase_dep
kwalletd) )
./net-fs/smbnetfs/smbnetfs-0.5.3a.ebuild: gnome? (
gnome-base/gnome-keyring:= )
./net-fs/smbnetfs/smbnetfs-0.5.3b.ebuild: gnome? (
gnome-base/gnome-keyring:= )
./net-im/gajim/gajim-0.15.4.ebuild: gnome? ( gnome-keyring )
./net-im/gajim/gajim-0.15.4.ebuild: kde? ( kde-base/kwalletmanager )
./net-im/gajim/gajim-0.16.ebuild: gnome? ( gnome-keyring )
./net-im/gajim/gajim-0.16.ebuild: kde? ( kde-base/kwalletmanager )
./www-client/qupzilla/qupzilla-1.6.5.ebuild:kde? ( kde-base/kwalletd:4 )
./www-client/qupzilla/qupzilla-1.6.6.ebuild:kde? ( kde-base/kwalletd:4 )
./www-client/qupzilla/qupzilla-1.8.0.ebuild:kde? ( kde-base/kwalletd:4 )
I think we should simply have a keyring USE flag to enable what most
people will want - keyring support.
Some apps have optional support for both kwallet and gnome-keyring
(e.g. darktable, subversion). So I'm not sure you can leave a single
USE flag.
What do you think? I am not sure what kind of USE flags are other
desktops but Gnome/MATE using :S
Thanks a lot
--
Alexander Tsoy
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de wrote: But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. If there is general consensus that this is going to be a stable target it might make sense to start running mixed stable+gcc-4.8 systems as widely as possible for feedback. -- Rich
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
Am Samstag, 11. Oktober 2014, 22:28:08 schrieb Rich Freeman: On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de wrote: But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. If there is general consensus that this is going to be a stable target it might make sense to start running mixed stable+gcc-4.8 systems as widely as possible for feedback. If it's of any help, I've been running 4.8 on my mostly stable systems for ages. Sounds feasible. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On 10/11/14 16:28, Rich Freeman wrote: On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell ziebell_ma...@posteo.de wrote: But if anyone would ask me to stabilize gcc-4.8 I would say amd64 ok. If there is general consensus that this is going to be a stable target it might make sense to start running mixed stable+gcc-4.8 systems as widely as possible for feedback. -- Rich Looking at the following two trackers: #461954 - GCC 4.8 porting #516152 - sys-devel/gcc-4.8.? stabilization I would say the following still should be fixed: #523788 - sys-firmware/ipxe-1.0.0_p20130925 stable request - fixes build for gcc-4.8 #477118 - media-gfx/photivo-0_pre20121212 fails to build with gcc 4.8 - error: ‘shared_ptr’ in namespace ‘std’ does not name a type #499166 - x11-misc/imake-1.0.7 stabilize (just ia64 and sparc to go)- fixes build for gcc-4.8 #46 - media-video/vlc-2.1.2 - deinterlace/yadif_template.h: In function 'yadif_filter_line_ssse3': deinterlace/yadif_template.h:134:9: error: 'asm' operand has impossible constraints #500064 - app-emulation/virtualbox-4.3.6 fails to build with gcc 4.8.x in bundled iPXE (fixed in vbox 4.3.16) #500944 - =media-libs/x264-0.0.20111220 segmentation faults during initialization of x264 encoder in x264_cqm_init () from /usr/lib/libx264.so.120 #500966 - =net-libs/webkit-gtk-2.2.4 USE=-webgl - ./.libs/libwebkitgtk-1.0.so: undefined reference to `_ZN3JSC21GenericTypedArrayViewINS_14Float32AdaptorEE6createEj' #513386 - net-libs/webkit-gtk-2.4.3 - ./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' These look like some namespace issues, and different use of registers (on x86). #46 is hardened specific. I think the following can be put on the backburner. #516548 - [4.8/4.9] gcc-4.8+ __atomic_* builtins broken on R1-based MIPS systems. #458706 - PaX: Max. per-task virtual memory too small for llvm asan and gcc-4.8 asan #465268 - dev-embedded/msp430-gcc-4.6.3_p20120406 with gcc-4.8.0 #503838 - sys-libs/glibc: building w/gcc-4.8 crashes early on ia64 For mips there is nothing to do, but ia64 will have to fall behind. And hardened will have to live with the asan-PaX issue. -- 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] Unifying the PostgreSQL Ebuilds
On 2014-09-19 10:11, Aaron W. Swenson wrote: I've been working on unifying the PostgreSQL ebuilds for a while now. Besides just being cleaner and taking a bit less time to compile, it will inherently resolve a couple issues that are difficult to workaround, such as cross compilation [1] and CFLAGS changes [2]. I'm including a list of affected packages, but I think I have everything prepared in my overlay [3] for commit to gentoo-x86. I'm aiming to do a package move instead of the virtual/postgresql mess we had last time. Before I do that, I'd like some feedback as there may be some issue I've overlooked or haven't run into. I don't really think there should be as the installation model is the same as the split ebuilds; it's still slotted, and installation paths are the same. I'm hoping to press forward with this change in the next week or so. Thank you in advance! [1] https://bugs.gentoo.org/show_bug.cgi?id=505540 [2] https://bugs.gentoo.org/show_bug.cgi?id=456876 [3] https://github.com/titanofold/titanofold-gentoo-x86 Affected Packages app-admin/collectd app-admin/rsyslog app-admin/sagan app-admin/ulogd app-backup/bacula app-backup/bareos app-crypt/onak app-editors/xemacs app-forensics/aide app-misc/sphinx app-mobilephone/gammu app-mobilephone/gnokii app-mobilephone/kannel app-office/akonadi-server app-office/calligra app-office/libreoffice app-office/openerp app-office/openerp-server dev-cpp/pficommon dev-db/barman dev-db/cppdb dev-db/libdbi-drivers dev-db/libzdb dev-db/mysql-super-smack dev-db/opendbx dev-db/pgadmin3 dev-db/pgagent dev-db/pgmemcache dev-db/pgpool2 dev-db/pgtap dev-db/pg_top dev-db/pgxnclient dev-db/postgis dev-db/psqlodbc dev-db/pygresql dev-db/slony1 dev-db/soci dev-db/textsearch_ja dev-db/tora dev-haskell/hdbc-postgresql dev-haskell/hsql-postgresql dev-java/jdbc-postgresql dev-lang/io dev-lang/php dev-libs/apr-util dev-libs/cyrus-sasl dev-libs/libhome dev-libs/libpqxx dev-libs/radlib dev-libs/redland dev-lisp/clisp dev-lua/luadbi dev-ml/postgresql-ocaml dev-perl/DBD-Pg dev-perl/pgperl dev-python/psycopg dev-python/pypgsql dev-qt/qtsql dev-ruby/pg games-server/cyphesis games-server/pvpgn games-strategy/freeciv gnome-extra/libgda gnustep-libs/sqlclient mail-filter/anubis mail-filter/dspam mail-filter/gld mail-mta/courier mail-mta/exim mail-mta/postfix media-video/motion net-analyzer/barnyard net-analyzer/barnyard2 net-analyzer/echoping net-analyzer/flow-tools net-analyzer/hydra net-analyzer/icinga2 net-analyzer/metasploit net-analyzer/munin net-analyzer/nagios-plugins net-analyzer/pmacct net-analyzer/zabbix net-dialup/accel-ppp net-dialup/freeradius net-dialup/gnuradius net-dns/bind net-dns/mydns net-dns/pdns net-firewall/nufw net-ftp/proftpd net-ftp/pure-ftpd net-im/jabberd2 net-irc/eggdrop net-irc/inspircd net-libs/courier-authlib net-libs/cvm net-libs/wt net-mail/cyrus-imapd net-mail/dovecot net-mail/ezmlm-idx net-mail/mailutils net-mail/perdition net-mail/tpop3d net-mail/vpopmail net-misc/asterisk net-misc/cfengine net-misc/mico net-misc/ser net-misc/stargazer net-print/pykota net-voip/gnugk net-voip/yate sci-biology/emboss sci-geosciences/grass sci-geosciences/mapnik sci-geosciences/osm2pgsql sci-geosciences/qgis sci-libs/gdal sci-libs/vtk sci-mathematics/pspp sci-physics/root sys-auth/libnss-pgsql sys-auth/pam-pgsql sys-cluster/gearmand sys-cluster/slurm www-apache/mod_auth_nufw www-apache/mod_auth_pgsql www-apps/liquid_feedback_core www-apps/webmcp www-servers/uwsgi Well, since I've heavily modified the PostgreSQL ebuilds I've decided to use virtual packages to do the transition. Anyone opposed to my fixing the dependencies of the above packages? -- Mr. Aaron W. Swenson Gentoo Linux Developer PostgreSQL Herd Bull Email : titanof...@gentoo.org GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0 GnuPG ID : D1BBFDA0 signature.asc Description: Digital signature
Re: [gentoo-dev] more help needed with gcc-4.8 stabilization, chromium starts heavily using C++11
On Sat, Oct 11, 2014 at 5:27 PM, Anthony G. Basile bluen...@gentoo.org wrote: I would say the following still should be fixed: ... These look like some namespace issues, and different use of registers (on x86). #46 is hardened specific. Do any of these actually apply to non-hardened amd64? I picked a few at random using default USE flags and didn't get any build failures on amd64 except for photivo (note that I didn't test the rest exhaustively). What is blocking stabilization on amd64? This makes me wonder how much love the 32-bit toolchain is getting these days (not just on Gentoo). A bit of a reversal from the early days of amd64... -- Rich
Re: [gentoo-portage-dev] [PATCH] bin/ebuild-helpers/portageq: fix bug #524964
Dnia 2014-10-10, o godz. 21:50:53
Zac Medico zmed...@gentoo.org napisał(a):
Since commit 0cc4c1ac21a2ea94cfb1f6ff4b461a9e349d47df,
$PORTAGE_BIN_PATH/portageq no longer exists, which breaks
bin/ebuild-helpers/portageq. Note that has_version and best_version
rely on bin/ebuild-helpers/portageq if IPC is disabled, so breakage
extends beyond ebuilds that call portageq illegally. Since
$PORTAGE_BIN_PATH no longer works, use PATH to locate the real
portageq python script.
Fixes: 0cc4c1ac21a2 (Install Portage using setup.py)
X-Gento-Bug: 524964
X-Gentoo-URL: https://bugs.gentoo.org/show_bug.cgi?id=524964
---
bin/ebuild-helpers/portageq | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/bin/ebuild-helpers/portageq b/bin/ebuild-helpers/portageq
index b67b03f..9eb17fc 100755
--- a/bin/ebuild-helpers/portageq
+++ b/bin/ebuild-helpers/portageq
@@ -2,9 +2,24 @@
# Copyright 2009-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
+scriptpath=${BASH_SOURCE[0]}
+scriptname=${scriptpath##*/}
+
PORTAGE_BIN_PATH=${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}
PORTAGE_PYM_PATH=${PORTAGE_PYM_PATH:-/usr/lib/portage/pym}
# Use safe cwd, avoiding unsafe import for bug #469338.
cd ${PORTAGE_PYM_PATH}
-PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
- exec ${PORTAGE_PYTHON:-/usr/bin/python} $PORTAGE_BIN_PATH/portageq
$@
+
+IFS=':'
+
+for path in ${PATH}; do
This will trigger unwanted filename expansion. For example,
PATH='/*/bin'
will trigger '/usr/bin' rather than '/*/bin' :P.
+ [[ -x ${path}/${scriptname} ]] || continue
+ [[ ${path}/${scriptname} -ef ${scriptpath} ]] continue
+ PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
+ exec ${PORTAGE_PYTHON:-/usr/bin/python} \
+ ${path}/${scriptname} $@
+done
+
+unset IFS
+echo ${scriptname}: command not found 12
+exit 127
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] bin/ebuild-helpers/portageq: fix bug #524964
On 10/11/2014 12:17 AM, Michał Górny wrote:
Dnia 2014-10-10, o godz. 21:50:53
Zac Medico zmed...@gentoo.org napisał(a):
+
+IFS=':'
+
+for path in ${PATH}; do
This will trigger unwanted filename expansion. For example,
PATH='/*/bin'
will trigger '/usr/bin' rather than '/*/bin' :P.
Good catch, thanks. This version uses 'set -f' to fix that:
From d16a4eb704fd91a60341daef7b31dcede7f17bf5 Mon Sep 17 00:00:00 2001
From: Zac Medico zmed...@gentoo.org
Date: Fri, 10 Oct 2014 21:32:54 -0700
Subject: [PATCH] bin/ebuild-helpers/portageq: fix bug #524964
Since commit 0cc4c1ac21a2ea94cfb1f6ff4b461a9e349d47df,
$PORTAGE_BIN_PATH/portageq no longer exists, which breaks
bin/ebuild-helpers/portageq. Note that has_version and best_version
rely on bin/ebuild-helpers/portageq if IPC is disabled, so breakage
extends beyond ebuilds that call portageq illegally. Since
$PORTAGE_BIN_PATH no longer works, use PATH to locate the real
portageq python script.
Fixes: 0cc4c1ac21a2 (Install Portage using setup.py)
X-Gento-Bug: 524964
X-Gentoo-URL: https://bugs.gentoo.org/show_bug.cgi?id=524964
---
bin/ebuild-helpers/portageq | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/bin/ebuild-helpers/portageq b/bin/ebuild-helpers/portageq
index b67b03f..4151bac 100755
--- a/bin/ebuild-helpers/portageq
+++ b/bin/ebuild-helpers/portageq
@@ -2,9 +2,25 @@
# Copyright 2009-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
+scriptpath=${BASH_SOURCE[0]}
+scriptname=${scriptpath##*/}
+
PORTAGE_BIN_PATH=${PORTAGE_BIN_PATH:-/usr/lib/portage/bin}
PORTAGE_PYM_PATH=${PORTAGE_PYM_PATH:-/usr/lib/portage/pym}
# Use safe cwd, avoiding unsafe import for bug #469338.
cd ${PORTAGE_PYM_PATH}
-PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
- exec ${PORTAGE_PYTHON:-/usr/bin/python} $PORTAGE_BIN_PATH/portageq
$@
+
+IFS=':'
+set -f # in case ${PATH} contains any shell glob characters
+
+for path in ${PATH}; do
+ [[ -x ${path}/${scriptname} ]] || continue
+ [[ ${path}/${scriptname} -ef ${scriptpath} ]] continue
+ PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
+ exec ${PORTAGE_PYTHON:-/usr/bin/python} \
+ ${path}/${scriptname} $@
+done
+
+unset IFS
+echo ${scriptname}: command not found 12
+exit 127
--
1.8.5.5
Re: [gentoo-portage-dev] Re: portage meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 9 Oct 2014 12:18:34 -0700 Brian Dolbec dol...@gentoo.org wrote: On Thu, 09 Oct 2014 11:17:17 +0200 Alexander Berntsen berna...@gentoo.org wrote: On 08/10/14 22:10, Brian Dolbec wrote: Can you edit whenisgood for a meeting this weekend/next week. If this weekend is not good for you yet, then maybe next weekend instead. Have fun at the conference... :) Yes. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander Can everyone please fill out their available times for the portage team meeting . http://whenisgood.net/portage and you can see the results: http://whenisgood.net/portage/results/y8rwaw9 Main topics on the agenda: Decide what patches go in to 2.2.14 final Patches to merge after the release. Open for anything else that needs to be taken care of... Thanks - -- Brian Dolbec dolsen Sorry for the late reply, I've set the meeting for Sunday at 17:00 UTC http://whenisgood.net/ResultsPopup?event=portagecode=y8rwaw9slot=141373800 - -- Brian Dolbec dolsen -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUOYUvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2OUZEQTI0MjY5QzhCNUE3RTlFMjMxRTkw MTg2ODIyMzFCOTI2RTRGAAoJEAGGgiMbkm5PtKgP/1UnRum/TBrNvthdFehH66tl wZYIaJfo5MQELmaPQaepviZHcAzAVhlGTKheKmJhrZsSHkBrf3mDqD2tm16nvBUV q6KwTlvsSMkdmAN3VqcCFDB0ZOdIvMoDSLtgYjJDMspnSvyhXNLeQfZhj4zJ2MrV r0liVkIiBC9u32TSNGLMwrDgamDqsxFlmzMpB58nlSVf27MbdcAmC6UDuPJwdHgC dEJsTvAewwi2L0gNC+qirIUC3uavlOQynyAKNCI45AlpdE9u63xlEe0sH8KTycTz 52lt/+k6pEUddtXmbNvIiyJEXhYZSIfJMoewH1abUp8ZviuCmGXoDJ1bccmQ3puv w7+MwiHIiOGTqugnebw+zfkz9ABn4ys9/Ha9Ld4dqq7PSQHqWUivZfK+Aci5PNds 18LUuV6hE+2489LibS4jHC+5ugOOkwhSa4mvurgA+wK4COeSLOnNB3KpJQApER4v ikwo38sSuTOBDFIEVnETGPf5QiOw4eSNn28L+edbyuJ4E4ldoww26td4uHceUEmx E4xLbbeaB656NpF2C6NfqZYLGvDJfg+ThcG386edSfBZNez24achcgFc9VebcFIw 3B13sJgLhxGCm6DIwOlWQuV+OXkUcfWkwRn2n2gvZ6OJqy8yK84/YgDVl7hdAzaw 4Hz7QYvoWmssl6OvK383 =+g3T -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [PATCH] Add --autounmask-write-retry feature.
On 05/19/2014 09:43 AM, Wade Cline wrote: This patch allows users to re-attempt an emerge after USE flag changes have been automatically written via --autounmask-write, allowing easier installation of ebuilds when users are not concerned about USE flag details. Previously, users would have needed to invoke emerge multiple times. Implementation was choosen based off of what was possible for me to get working at the time. Based on Portage 2.2.10_p25_p484922. --- If I understand correctly, this works under the assumption that the user has CONFIG_PROTECT_MASK=/etc/portage or something like that? Otherwise, it won't work, because the user needs to run etc-update or dispatch-conf. Right? -- Thanks, Zac
