virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote: May I suggest an alternative? We could implement sys-virtual/posix and make it depend on all packages that are not necessary for @system, but are necessary for proper POSIX compliance. Then we can tell users who need/want an environment containing all tools specified by POSIX, such as those not using sys-kernel/*-sources, to `emerge virtual/posix`. I like this idea, for a virtual/posix; would let us trim a lot of other things from some environments. In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Cheers, Trevor [1]: http://git.tremily.us/?p=catalyst.git;a=blob;f=doc/HOWTO.txt;h=cec22c35484d480fa127beb7be6bbdd9e942dc39;hb=HEAD#l139 Linking to my public repo, because the gitweb service on git.overlays.gentoo.org is still broken. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wk...@tremily.us wrote: On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: In a similar vein, would releng be open to moving stage1/2/3 package sets to virtual packages or package sets? Presently they are inside catalyst, and I think this would clean things up a lot. They're already in the Portage tree (the profile's packages.build for stage1, scripts/bootstrap.sh for stage2, and the profile's packages for stage3) [1]. Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. The build system would just iteratively start at the bottom and output a tarball or whatever as each level is completed, then use that as the basis for bootstrapping the next. Such a design would also eliminate the need to have the same list of packages define the contents of @system and a stage3. It could also support any number of stages, with any names we wish. My intent here isn't to get three cheers for making the releng team do more work. I'm actually more interested in feedback as to whether there are any obvious flaws in an approach like this that I'm missing, or whether something entirely different would be better. I would also still have stage builds use a profile of some kind - that could be useful from a standpoint of setting USE flags and so on. However, if it made sense to build earlier stages with different flags they could still be specified as USE dependencies (maybe due to circular deps you have to build a package with different set of USE flags before you can build the desired USE flags in a later stage). -- Rich
[gentoo-dev] last rites: kde-misc/kcm_touchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Manuel Rüger mr...@gentoo.org (11 Oct 2014) # Dead upstream use kde-misc/kcm-touchpad instead kde-misc/kcm_touchpad -BEGIN PGP SIGNATURE- Version: GnuPG v2.0 iQJ8BAEBCgBmBQJUOI5KXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNc1FIP/3sMQuC8Q/p0R2l6jHq4RDyL 2VNJ6gKBuN3fPhVMef5V8eFRoa56v8mPS7AhoGZWjmjnJqxzH5RqgovpyLadwoNi 84gHtu3RR99xewwAdV/6vhxPnzUmXvkHByN6Q37m06A/Tw9m+iQVL/opZeICYomZ 8+i1WfsJM8TMKF9yrnTR0wsj+z9XYEw76nSSqqmczY8SZHygjoqSdpRaYDqh17Hs /HiCmVVrbxHTGtPpml3iw88SUdNJWi8rBwqdYf1+pxwfEcpXpDFsXUPYdVO2wSKs wRfaUYM4EmaTIDbvr0KIiEdO3dktJ3TlRzbqc/a9FlLeBF10kZKHyDX7SgBFcRGQ S+v1Vl5ymimWmz/cCDTY6AP2D2qTPI2sj4rxUBcehpcQdYZB/SsGETd4e1GvGC/3 wz4FPBpBAQm8hyL72cZEYbClLJpmf/mY1SPpx4ALefAkcuVfKvXBac+/bnHtZX1X hfHlB7G8AQnVskCLrxiKidxgJxUrdsFgtm7xr6lnpgHHYiD1xkpoCNjv8mL8FgOh Iy8yBcgLof7ezRk1kwzAuZ+q9vVUiIEY+CFjBduIpi6LuuWf37iLp7MTY5SHP9+H QM2za9Vo3LIoPZmkjzspMsoqaRp5IDPo55eaVc6uut5CGgHkoxUkVRDAVfI9Dltp wDlfuY7QKps1DUWa2B8b =maJX -END PGP SIGNATURE-
Re: virtual/{posix,stage1,2,3} Was: [gentoo-dev] Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:45:37PM -0400, Rich Freeman wrote: Obviously this entails work on somebody's part, but would it still make sense to make the stage build process more generic along the lines Robin suggested? That is, instead of having 3 specific places we use to generate a stage1/2/3, we instead just define a stage as a virtual of some kind that optionally depends on another stage (not necessarily using the standard DEPEND mechanism) and then pulls in a list of packages. The root stage would not depend on another stage, and therefore would be built from the host system. Why bother with multiple layers and per-profile package lists if a straight emerge is all you need? My ideal long-term situation would be to explicitly list all a package's dependencies (no implicit @system dependencies). Then have the stage1 just emerge a self-hosting virtual/toolchain (which can have per-arch dependencies if it needs them) from an arbitrary seed, and stage2 rebuild -e using itself. Everything after that could be user-generated @world stuff, and you might want virtual/release with nano and whatever else you want to put up under releases/$ARCH/autobuilds/gentoo-$ARCH-$DATE.tar.bz. That's less magical, and Catalyst could be a bit simpler, but I don't have the energy to move things there ;). It's also pretty much what we have now, except @system is floating around between virtual/toolchain (our current stage1 packages) and virtual/release (our current stage3 packages). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: last rites: kde-misc/kcm_touchpad
Manuel Rüger posted on Sat, 11 Oct 2014 03:56:26 +0200 as excerpted: # Manuel Rüger mr...@gentoo.org (11 Oct 2014) # Dead upstream use kde-misc/kcm-touchpad instead kde-misc/kcm_touchpad Please consider adding another line to that mask message: # (_ vs. -) Would have saved /me/ quite some confusion, anyway, thinking you were pointing people at the same package you were removing. =8^0 And saving people confusion can mean saving yourself and your project bugs. =:^) -- 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
[gentoo-dev] Re: virtual/{posix,stage1,2,3} Was: Add bc back to the stage3
On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote: On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote: May I suggest an alternative? We could implement sys-virtual/posix and make it depend on all packages that are not necessary for @system, but are necessary for proper POSIX compliance. Then we can tell users who need/want an environment containing all tools specified by POSIX, such as those not using sys-kernel/*-sources, to `emerge virtual/posix`. kernel-sources doesn't get you that afaict: it just gets you bc. Certainly doesn't get you ed, which is tiny and designed to be used in rootfs. I just don't see the point in not providing a POSIX.2 system by default. It feels like crippling the distro before it's out the door. I like this idea, for a virtual/posix; would let us trim a lot of other things from some environments. Such as? 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. I feel like I've gone through the looking-glass. (pam pulling in polkit?) Anyhow, it seems to that in the minimal embedded env you're talking about, the user can quite easily remove or package.provide things, and that can be done in the profile as well as myriad other options for the expert use-case; none of which speak to the default. We used to have LDAP enabled by default, for the best part of a decade to my recollection, just so that people could plug a disk into a Windows environment, on the grounds that this made us look more professional. With respect, nothing looks more amateurish than a *nix that doesn't even comply with POSIX.2. It's not exactly hard, yet we don't manage it, but meantime let's add in massively complex layers. It seems very masochistic sometimes, from an external perspective. Loads of extra work, discussion and what often reads like heartache, for want of a better word, in order to achieve what you could have done really simply. Still, moar code must be better, right? -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-portage-dev] [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 | 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
+ [[ -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
