[gentoo-portage-dev] [patch] dont run ldconfig unless libraries are actually installed
simple patch which gets rid of all the pointless calls to `ldconfig` when
emerging packages that dont install libraries
thoughts ?
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2559)
+++ pym/portage.py (working copy)
@@ -521,7 +521,7 @@
#parse /etc/env.d and generate /etc/profile.env
-def env_update(makelinks=1):
+def env_update(makelinks=1,srcroot=""):
global root
if not os.path.exists(root+"etc/env.d"):
prevmask=os.umask(0)
@@ -637,7 +637,10 @@
if not mtimedb.has_key("ldpath"):
mtimedb["ldpath"]={}
- for x in specials["LDPATH"]+['/usr/lib','/lib']:
+ skip_makelinks=1
+ for x in specials["LDPATH"]+['/usr/lib','/usr/lib64','/usr/lib32','/lib','/lib64','/lib32']:
+ if makelinks and skip_makelinks and os.access(srcroot+x,os.R_OK):
+ skip_makelinks=0
try:
newldpathtime=os.stat(x)[stat.ST_MTIME]
except SystemExit, e:
@@ -654,9 +657,13 @@
mtimedb["ldpath"][x]=newldpathtime
ld_cache_update=True
+ # Don't run ldconfig if the package didn't install any libs
+ if (makelinks and skip_makelinks):
+ makelinks=0
+
# ldconfig has very different behaviour between FreeBSD and Linux
- if ostype=="Linux" or ostype.lower().endswith("gnu"):
- if (ld_cache_update or makelinks):
+ if (ld_cache_update or makelinks):
+ if ostype=="Linux" or ostype.lower().endswith("gnu"):
# We can't update links if we haven't cleaned other versions first, as
# an older package installed ON TOP of a newer version will cause ldconfig
# to overwrite the symlinks we just made. -X means no links. After 'clean'
@@ -666,8 +673,7 @@
commands.getstatusoutput("cd / ; /sbin/ldconfig -r "+root)
else:
commands.getstatusoutput("cd / ; /sbin/ldconfig -X -r "+root)
- elif ostype in ("FreeBSD","DragonFly"):
- if (ld_cache_update):
+ elif ostype in ("FreeBSD","DragonFly"):
writemsg(">>> Regenerating "+str(root)+"var/run/ld-elf.so.hints...\n")
commands.getstatusoutput("cd / ; /sbin/ldconfig -elf -i -f "+str(root)+"var/run/ld-elf.so.hints "+str(root)+"etc/ld.so.conf")
[gentoo-portage-dev] [patch] flexible env-update
along the same lines of the previous patch, this allows people to call
`env-update` without regenerating the ld.so.cache if they want ... i can
easily use this in gcc-config/binutils-config to make those suckers a hell of
a lot faster (the delay from switching versions is because the ld.so.cache is
rebuilt)
thoughts ?
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2559)
+++ pym/portage.py (working copy)
@@ -591,9 +591,6 @@
oldld=None
ld_cache_update=False
- if os.environ.has_key("PORTAGE_CALLER") and \
- os.environ["PORTAGE_CALLER"] == "env-update":
- ld_cache_update = True
newld=specials["LDPATH"]
if (oldld!=newld):
Index: bin/env-update
===
--- bin/env-update (revision 2559)
+++ bin/env-update (working copy)
@@ -7,5 +7,23 @@
os.environ["PORTAGE_CALLER"] = "env-update"
sys.path = ["/usr/lib/portage/pym"]+sys.path
+def usage(status):
+ print "Usage: env-update [--no-ldconfig]"
+ print ""
+ print "See the env-update(1) man page for more info"
+ sys.exit(status)
+
+if "-h" in sys.argv or "--help" in sys.argv:
+ usage(0)
+
+makelinks=1
+if "--no-ldconfig" in sys.argv:
+ makelinks=0
+ sys.argv.pop(sys.argv.index("--no-ldconfig"))
+
+if len(sys.argv) > 1:
+ print "!!! Invalid command line options!\n"
+ usage(1)
+
import portage
-portage.env_update()
+portage.env_update(makelinks)
Re: [gentoo-portage-dev] [patch] dont run ldconfig unless libraries are actually installed
On Sunday 15 January 2006 00:43, Mike Frysinger wrote:
> simple patch which gets rid of all the pointless calls to `ldconfig` when
> emerging packages that dont install libraries
and revised
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2559)
+++ pym/portage.py (working copy)
@@ -521,7 +521,7 @@
#parse /etc/env.d and generate /etc/profile.env
-def env_update(makelinks=1):
+def env_update(makelinks=1,srcroot=""):
global root
if not os.path.exists(root+"etc/env.d"):
prevmask=os.umask(0)
@@ -637,7 +634,10 @@
if not mtimedb.has_key("ldpath"):
mtimedb["ldpath"]={}
- for x in specials["LDPATH"]+['/usr/lib','/lib']:
+ skip_makelinks=1
+ for x in portage_util.unique_array(specials["LDPATH"]+['/usr/lib','/usr/lib64','/usr/lib32','/lib','/lib64','/lib32']):
+ if makelinks and skip_makelinks and os.access(srcroot+x,os.R_OK):
+ skip_makelinks=0
try:
newldpathtime=os.stat(x)[stat.ST_MTIME]
except SystemExit, e:
@@ -654,9 +654,10 @@
mtimedb["ldpath"][x]=newldpathtime
ld_cache_update=True
- # ldconfig has very different behaviour between FreeBSD and Linux
- if ostype=="Linux" or ostype.lower().endswith("gnu"):
- if (ld_cache_update or makelinks):
+ # Don't run ldconfig if the package didn't install any libs
+ if (ld_cache_update or (makelinks and not skip_makelinks)):
+ # ldconfig has very different behaviour between FreeBSD and Linux
+ if ostype=="Linux" or ostype.lower().endswith("gnu"):
# We can't update links if we haven't cleaned other versions first, as
# an older package installed ON TOP of a newer version will cause ldconfig
# to overwrite the symlinks we just made. -X means no links. After 'clean'
@@ -666,8 +667,7 @@
commands.getstatusoutput("cd / ; /sbin/ldconfig -r "+root)
else:
commands.getstatusoutput("cd / ; /sbin/ldconfig -X -r "+root)
- elif ostype in ("FreeBSD","DragonFly"):
- if (ld_cache_update):
+ elif ostype in ("FreeBSD","DragonFly"):
writemsg(">>> Regenerating "+str(root)+"var/run/ld-elf.so.hints...\n")
commands.getstatusoutput("cd / ; /sbin/ldconfig -elf -i -f "+str(root)+"var/run/ld-elf.so.hints "+str(root)+"etc/ld.so.conf")
Re: [gentoo-portage-dev] [patch] flexible env-update
On Sunday 15 January 2006 05:10, Kevin F. Quinn (Gentoo) wrote: > On Sun, 15 Jan 2006 00:52:16 -0500 > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > along the same lines of the previous patch, this allows people to > > call `env-update` without regenerating the ld.so.cache if they > > want ... i can easily use this in gcc-config/binutils-config to make > > those suckers a hell of a lot faster (the delay from switching > > versions is because the ld.so.cache is rebuilt) > > Since switching gcc and binutils configs swaps out library directories > in ld.so.conf, isn't it necessary to rebuild ld.so.cache anyway? yes, but they swap out very specific known paths which means we can tweak them to only run ldconfig on those dirs rather than all paths (but mostly not /lib and /usr/lib) -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [patch] dont run ldconfig unless libraries are actually installed
On Monday 16 January 2006 19:52, Zac Medico wrote:
> Mike Frysinger wrote:
> > - for x in specials["LDPATH"]+['/usr/lib','/lib']:
> > + skip_makelinks=1
> > + for x in
> > portage_util.unique_array(specials["LDPATH"]+['/usr/lib','/usr/lib64','/u
> >sr/lib32','/lib','/lib64','/lib32']): + if makelinks and
> >skip_makelinks
> > and os.access(srcroot+x,os.R_OK): + skip_makelinks=0
>
> The logic here isn't obvious to me, could you clarify?
makelinks is set to 1 by default when upgrading a package so that running
ldconfig will update any shared lib links ... however, if the package doesnt
install any libraries, then there's no point in running ldconfig
> I've tried the
> patch (against trunk revision 2564) and it seems that the skip_makelinks=0
> executes even when a package with no shared libraries is installed, making
> the patch ineffective (I still get "Regenerating /etc/ld.so.cache" no
> matter what). If I comment out the skip_makelinks=0 part then ldconfig
> doesn't run unecessarily (as expected).
that's because there's one small hunk missing from what i posted
updated patch attached
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 2563)
+++ pym/portage.py (working copy)
@@ -521,7 +521,7 @@
#parse /etc/env.d and generate /etc/profile.env
-def env_update(makelinks=1):
+def env_update(makelinks=1,srcroot=""):
global root
if not os.path.exists(root+"etc/env.d"):
prevmask=os.umask(0)
@@ -637,7 +634,10 @@
if not mtimedb.has_key("ldpath"):
mtimedb["ldpath"]={}
- for x in specials["LDPATH"]+['/usr/lib','/lib']:
+ skip_makelinks=1
+ for x in portage_util.unique_array(specials["LDPATH"]+['/usr/lib','/usr/lib64','/usr/lib32','/lib','/lib64','/lib32']):
+ if makelinks and skip_makelinks and os.access(srcroot+x,os.R_OK):
+ skip_makelinks=0
try:
newldpathtime=os.stat(x)[stat.ST_MTIME]
except SystemExit, e:
@@ -654,9 +654,10 @@
mtimedb["ldpath"][x]=newldpathtime
ld_cache_update=True
- # ldconfig has very different behaviour between FreeBSD and Linux
- if ostype=="Linux" or ostype.lower().endswith("gnu"):
- if (ld_cache_update or makelinks):
+ # Don't run ldconfig if the package didn't install any libs
+ if (ld_cache_update or (makelinks and not skip_makelinks)):
+ # ldconfig has very different behaviour between FreeBSD and Linux
+ if ostype=="Linux" or ostype.lower().endswith("gnu"):
# We can't update links if we haven't cleaned other versions first, as
# an older package installed ON TOP of a newer version will cause ldconfig
# to overwrite the symlinks we just made. -X means no links. After 'clean'
@@ -666,8 +667,7 @@
commands.getstatusoutput("cd / ; /sbin/ldconfig -r "+root)
else:
commands.getstatusoutput("cd / ; /sbin/ldconfig -X -r "+root)
- elif ostype in ("FreeBSD","DragonFly"):
- if (ld_cache_update):
+ elif ostype in ("FreeBSD","DragonFly"):
writemsg(">>> Regenerating "+str(root)+"var/run/ld-elf.so.hints...\n")
commands.getstatusoutput("cd / ; /sbin/ldconfig -elf -i -f "+str(root)+"var/run/ld-elf.so.hints "+str(root)+"etc/ld.so.conf")
@@ -6113,7 +6113,7 @@
downgrade = True
#update environment settings, library paths. DO NOT change symlinks.
- env_update(makelinks=(not downgrade))
+ env_update(makelinks=(not downgrade),srcroot=srcroot)
#dircache may break autoclean because it remembers the -MERGING-pkg file
global dircache
if dircache.has_key(self.dbcatdir):
[gentoo-portage-dev] first pass at --debug-build
here's what i was talking about when i mentioned the mutate() idea
tested and it works for me ... binary is built properly and environment.bz2
contains the correct values
-mike
--- pym/portage.py (revision 2565)
+++ pym/portage.py (working copy)
@@ -1266,10 +1266,6 @@
if "usersandbox" in self.features:
self.features.remove("usersandbox")
- self.features.sort()
- self["FEATURES"] = " ".join(["-*"]+self.features)
- self.backup_changes("FEATURES")
-
if not len(self["CBUILD"]) and len(self["CHOST"]):
self["CBUILD"] = self["CHOST"]
self.backup_changes("CBUILD")
@@ -1277,6 +1273,32 @@
if mycpv:
self.setcpv(mycpv)
+ self.mutate_env
+
+ def mutate_env(self):
+ "emerge may have mutated the env slightly, so we may have to rebuild some things"
+
+ if "debug-build" in self.features:
+ # the profile should be setting these, but just in case ...
+ if not len(self["DEBUG_CFLAGS"]):
+self["DEBUG_CFLAGS"] = "-g -O"
+self.backup_changes("DEBUG_CFLAGS")
+ if not len(self["DEBUG_CXXFLAGS"]):
+self["DEBUG_CXXFLAGS"] = self["DEBUG_CFLAGS"]
+self.backup_changes("DEBUG_CXXFLAGS")
+ # replace user vars with debug version
+ for var in ["CFLAGS","CXXFLAGS","LDFLAGS"]:
+self[var]=self["DEBUG_"+var]
+self.backup_changes(var)
+ # if user has splitdebug, the debug info will be auto saved for
+ # gdb, otherwise we want to keep the binaries from being stripped
+ if not "splitdebug" in self.features:
+self.features.append("nostrip")
+
+ self.features.sort()
+ self["FEATURES"] = " ".join(["-*"]+self.features)
+ self.backup_changes("FEATURES")
+
def loadVirtuals(self,root):
self.virtuals = self.getvirtuals(root)
--- pym/portage_const.py (revision 2565)
+++ pym/portage_const.py (working copy)
@@ -40,7 +40,7 @@
CONFIG_MEMORY_FILE = PRIVATE_PATH + "/config"
INCREMENTALS=["USE","USE_EXPAND","USE_EXPAND_HIDDEN","FEATURES","ACCEPT_KEYWORDS","ACCEPT_LICENSE","CONFIG_PROTECT_MASK","CONFIG_PROTECT","PRELINK_PATH","PRELINK_PATH_MASK"]
-STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
+STICKIES=["KEYWORDS_ACCEPT","USE","CFLAGS","CXXFLAGS","LDFLAGS","DEBUG_CFLAGS","DEBUG_CXXFLAGS","DEBUG_LDFLAGS","MAKEOPTS","EXTRA_ECONF","EXTRA_EINSTALL","EXTRA_EMAKE"]
EBUILD_PHASES = ["setup","unpack","compile","test","install","preinst","postinst","prerm","postrm"]
EAPI = 0
--- bin/emerge (revision 2565)
+++ bin/emerge (working copy)
@@ -173,6 +173,7 @@
"--ask",
"--buildpkg", "--buildpkgonly",
"--changelog","--columns", "--cols",
+"--debug-build", "--debugbuild"
"--debug","--deep",
"--digest",
"--emptytree",
@@ -429,6 +430,13 @@
if ("--nocolor" in myopts) and (sys.stdout.isatty()):
nocolor()
+# Now mutate portage env based upon options user gave us
+if ("--debug-build" in myopts):
+ portage.settings.unlock()
+ portage.settings.features.append("debug-build")
+ portage.settings.mutate_env()
+ portage.settings.lock()
+
CLEAN_DELAY = 5
EMERGE_WARNING_DELAY = 10
if portage.settings["CLEAN_DELAY"]:
Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?
On Sunday 22 January 2006 19:33, Mikey wrote: > actions=[ > +"glsa-only", whats wrong with just "glsa" ? -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Monday 23 January 2006 15:55, Simon Stelling wrote: > Lares Moreau wrote: > > Many ebuilds fail due to failed QA. How difficult would it be to have > > the package create the tarball before the QA tests. If this were > > possible, QA could be slightly quicker, as there would be no need to > > rebuild the entire package, with features disabled, upon failure. > > I think you rather want to use FEATURES=keepwork than doing such ugly > stuff. keepwork wouldnt accomplish anything wrt to what he wants this would prob do it though: ebuild install package qmerge -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] first pass at --debug-build
On Thursday 19 January 2006 19:39, Mike Frysinger wrote: > here's what i was talking about when i mentioned the mutate() idea > > tested and it works for me ... binary is built properly and environment.bz2 > contains the correct values to speed this along ... how do people care about the FEATURES=debug-build idea in general ? i could commit the first part which implements FEATURES=debug-build in general and then we can fight over how to implement `emerge --debug-build` -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] first pass at --debug-build
On Monday 23 January 2006 19:31, Alec Warner wrote: > I'm stuck on this. Part of me wants to see more new features in portage > and part of me screams horrible hack :P the idea or the implementation ? there is no getting around the idea and forcing the users to do this stuff for every package is bad design -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Tuesday 24 January 2006 03:43, Francesco Riosa wrote: > Indeed, could someone shade a light on what happen to /var/db/pkg and > world file when using "ebuild" this manner ? > Could be rephrased as "Does it act exactly the same way emerge does ?" the 'qmerge' step would take care of updating /var/db/pkg -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Switching LOCALE during build?
On Tuesday 28 February 2006 10:55, Patrick Lauer wrote: > During build portage should change the locale to en_us no, C would be a saner setting > so that any error > messages are easy to read even if the user has set it differently. This > shouldn't affect users much and could get rid of the bugreports where it > is hard to understand what went wrong because everything is in french. i'm not sure how this would affect the build process ... it would for sure mask mistakes in ebuild/packages that assume certain things about the active local when using character classes in regular expressions -mike -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
so we've found some cases where a package installs objects that either need to be ignored by some of the scanelf checks ... first off, we have kernel binary objects that a package installs (the h*modem packages do this), so they should not be subjected to the exec stack scans next up is the slmodem package ... this puppy is partly binary only and we have no access to the source code and upstream is dead ... one of the pre-built binary objects has an exec stack enabled via gcc (meaning it's a legit use of exec stack) ... so we need to skip that what this e-mail is about is naming convention ... i'm thinking that an ebuild sets up a variable with a list of relative paths to $D of files that should be skipped for various checks ... so with slmodem, we'd have like: QA_EXEC_STACK="usr/sbin/slmodemd usr/sbin/slmodem_test" if, in the future, we need to add an ignore list for TEXTRELs, we'd use QA_TEXTRELS="" -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Sunday 05 March 2006 19:48, Kevin F. Quinn (Gentoo) wrote: > Ned Ludd <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-03-03 at 23:32 -0500, Mike Frysinger wrote: > > > so we've found some cases where a package installs objects that > > > either need to be ignored by some of the scanelf checks ... > > > > > > ... > > > > > > what this e-mail is about is naming convention ... i'm thinking > > > that an ebuild sets up a variable with a list of relative paths to > > > $D of files that should be skipped for various checks ... so with > > > slmodem, we'd have like: QA_EXEC_STACK="usr/sbin/slmodemd > > > usr/sbin/slmodem_test" > > > > > > if, in the future, we need to add an ignore list for TEXTRELs, we'd > > > use QA_TEXTRELS="" > > > > This becomes tricky when looking at tests across all CHOSTs. > > What holds true for one arch defiantly is not the case for others. > > This could be done via the profiles, perhaps - package.qa, something > like package.mask/use/keywords: i hate such things ... imo this information should stay in the ebuild and nowhere else ... be trivial to expand the support like: QA_TEXTRELS="..." # for all arches QA_TEXTRELS_arch="..." # for just one arch so in the case of slmodem: QA_EXEC_STACK="usr/sbin/slmodemd" in the case of some other package that only has issues on x86: QA_EXEC_STACK_x86="some/foo" this thread was about the naming convention :P does QA_EXEC_STACK and QA_TEXTRELS work for people ? -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
how does the attached patch look ? it allows for regexes in the ignore list
which is why i used gawk ;)
QA_TEXTRELS="usr/lib/libGL.so.*"
QA_EXECSTACK="usr/bin/slmodem usr/bin/modem_test"
-mike
Index: ebuild.sh
===
--- ebuild.sh (revision 2825)
+++ ebuild.sh (working copy)
@@ -1095,7 +1095,7 @@
done
if type -p scanelf > /dev/null ; then
- local insecure_rpath=0
+ local qa_var insecure_rpath=0
# Make sure we disallow insecure RUNPATH/RPATH's
# Don't want paths that point to the tree where the package was built
@@ -1132,9 +1132,22 @@
fi
# TEXTREL's are bd
- f=$(scanelf -qyRF '%t %p' "${D}")
+ # Allow devs to mark things as ignorable ... e.g. things that are
+ # binary-only and upstream isn't cooperating (nvidia-glx) ... we
+ # allow ebuild authors to set QA_TEXTRELS_arch and QA_TEXTRELS ...
+ # the former overrides the latter ... regexes allowed ! :)
+ qa_var="QA_TEXTRELS_${ARCH}"
+ [[ -n ${!qa_var} ]] && QA_TEXTRELS=${!qa_var}
+ f=$(scanelf -qyRF '%t %p' "${D}" | grep -v ' usr/lib/debug/' | \
+ gawk '
+ BEGIN { split("'"${QA_TEXTRELS}"'", ignore); }
+ { for (idx in ignore)
+ if ($NF ~ "^"ignore[idx]"$")
+ next;
+print;
+ }')
if [[ -n ${f} ]] ; then
- scanelf -qyRF '%T %p' "${WORKDIR}"/ &> "${T}"/scanelf-textrel.log
+ scanelf -qyRF '%T %p' "${PORTAGE_BUILDDIR}"/ &> "${T}"/scanelf-textrel.log
echo -ne '\a\n'
echo "QA Notice: the following files contain runtime text relocations"
echo " Text relocations force the dynamic linker to perform extra"
@@ -1158,15 +1171,30 @@
# http://hardened.gentoo.org/gnu-stack.xml (Arch Status)
case ${CTARGET:-${CHOST}} in
i?86*|ia64*|m68k*|powerpc64*|s390*|x86_64*)
- f=$(scanelf -qyRF '%e %p' "${D}") ;;
-*)
- f="" ;;
+ # Allow devs to mark things as ignorable ... e.g. things
+ # that are binary-only and upstream isn't cooperating ...
+ # we allow ebuild authors to set QA_EXECSTACK_arch and
+ # QA_EXECSTACK ... the former overrides the latter ...
+ # regexes allowed ! :)
+
+ qa_var="QA_EXECSTACK_${ARCH}"
+ [[ -n ${!qa_var} ]] && QA_EXECSTACK=${!qa_var}
+ f=$(scanelf -qyRF '%e %p' "${D}" | grep -v ' usr/lib/debug/' | \
+ gawk '
+ BEGIN { split("'"${QA_EXECSTACK}"'", ignore); }
+ { for (idx in ignore)
+if ($NF ~ "^"ignore[idx]"$")
+ next;
+ print;
+ }')
+ ;;
+*) f="" ;;
esac
;;
esac
if [[ -n ${f} ]] ; then
# One more pass to help devs track down the source
- scanelf -qyRF '%e %p' "${WORKDIR}"/ &> "${T}"/scanelf-exec.log
+ scanelf -qyRF '%e %p' "${PORTAGE_BUILDDIR}"/ &> "${T}"/scanelf-execstack.log
echo -ne '\a\n'
echo "QA Notice: the following files contain executable stacks"
echo " Files with executable stacks will not work properly (or at all!)"
@@ -1174,7 +1202,7 @@
echo " at http://bugs.gentoo.org/ to make sure the file is fixed."
echo " For more information, see http://hardened.gentoo.org/gnu-stack.xml";
echo " Please include this file in your report:"
- echo " ${T}/scanelf-exec.log"
+ echo " ${T}/scanelf-execstack.log"
echo "${f}"
echo -ne '\a\n'
die_msg="${die_msg} execstacks"
Re: [gentoo-portage-dev] [rfc] variable naming for marking binaries as QA ignorable
On Wednesday 08 March 2006 02:54, Kevin F. Quinn (Gentoo) wrote: > On Wed, 8 Mar 2006 00:17:52 -0500 > > how does the attached patch look ? it allows for regexes in the > > ignore list which is why i used gawk ;) > > Could we add something so that we can disable these ignore lists in the > hardened profile? done and committed -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Locales
On Friday 17 March 2006 11:55, tvali wrote: > Most of installation scripts of et locale are broken. Because of that, i > would like some way to configure portage in such way that it starts with > changing locale into english, then installs and then starts locale back > into estonian no, fix the scripts -mike -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: r3046 - main/trunk/pym
On Saturday 01 April 2006 02:34, Zach Medico wrote: > Modified: >main/trunk/pym/portage.py > Log: > Fix ROOT handling for timestamps of lib directories. Only run ldconfig when > timestamps have changed (the makelinks flag does not force ldconfig unless > timestamps have changed). no, this is still wrong makelinks is kept sep from the ld mtime logic on purpose -mike -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] rewriting the ldconfig logic
i thought about this some more ... why do we even care about the mtimes during package merge ? if a package doesnt install any files into a libdir, why should we bother running ldconfig ? if a user updated the dirs, then they can either run ldconfig or env-update ... so imo, the logic should be: if srcroot is None: else: -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] rewriting the ldconfig logic
On Saturday 01 April 2006 17:17, Zac Medico wrote: > Mike Frysinger wrote: > > i thought about this some more ... why do we even care about the mtimes > > during package merge ? if a package doesnt install any files into a > > libdir, why should we bother running ldconfig ? if a user updated the > > dirs, then they can either run ldconfig or env-update ... > > > > so imo, the logic should be: > > if srcroot is None: > > > > else: > > > > Yeah, I think that's correct. Also, even though we don't need to check the > mtimes when srcroot is defined, we can still update the mtimes in the > mtimedb to the current values in order to avoid an unnecessary ldconfig run > on the next env_update call. feel like implementing this ? that way we dont stop on each others feet again and i dont have to waste time when you rewrite my work ;) -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] should we add userpriv and usersandox to make.globals FEATURES?
On Monday 10 April 2006 08:08, Ned Ludd wrote: > On Mon, 2006-04-10 at 02:24 -0700, Zac Medico wrote: > > What do people think about adding userpriv and usersandox to make.globals > > FEATURES? I've been using these for a long time and haven't had any > > trouble with them. Are there any arguments against making them default? > > This is would qualify as core change. Please post this on the -dev ml. agreed, this is the inappropriate forum for such a change -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Outstanding decisions
On Saturday 15 April 2006 10:51, Simon Stelling wrote: > Bug: SRC_URI: spaces not supported > http://bugs.gentoo.org/show_bug.cgi?id=102607 > Is this a 'NOTABUG' case? personally i'd say "not worth the hassle, fix the brain dead URL" > Bug: gpg: "strict" incorrectly takes priority over "severe" > http://bugs.gentoo.org/show_bug.cgi?id=68906 > What's the expected behaviour? Is it NOTABUG? by the description, sounds like it should be changed as suggested > Bug: Method to monitor a package without installing/upgrading it > http://bugs.gentoo.org/show_bug.cgi?id=47456 > Same thing. Do we want this? i'd say kill it > Bug: Support for a pre-compile pkg_config > http://bugs.gentoo.org/show_bug.cgi?id=99529 > As Jason mentioned: Is this worth the effort? with some packages, USE flags are the wrong solution (think php times 10) ,,, but i dont think integration into portage really works ... > Bug: Wording "These are the packages that I would merge, in order:" > http://bugs.gentoo.org/show_bug.cgi?id=112439 > This needs a decision too. What wording do we prefer? Either way, the bug > should be closed, the fix is trivial in case we want to change it. WONTFIX imo -mike -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Re: r3200 - main/trunk/bin
On Sunday 23 April 2006 12:36, Alec Warner wrote: > Modified: >main/trunk/bin/sed > Log: > Make sed wrapper not executable. why ? it isnt hurting anything to be set executable -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: r3200 - main/trunk/bin
On Monday 24 April 2006 01:09, Alec Warner wrote: > Mike Frysinger wrote: > > On Sunday 23 April 2006 12:36, Alec Warner wrote: > >>Modified: > >> main/trunk/bin/sed > >>Log: > >>Make sed wrapper not executable. > > > > why ? it isnt hurting anything to be set executable > > At present it is not in the pre9 tarball. However it is in SVN, so it > will make it into the tarball eventually. > > Since it's in /bin it will get installed with all the other binaries. > However it's a !GNU only sed wrapper, so in this case once it is added > to the tarball it will be installed on all systems, but set +x only on > non GNU systems. imo, relying on the existence is a better idea than relying on it being +x so i'd leave it +x everywhere but delete it on GNU systems think like cygwin where files are always +x ... -mike -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] backend support for FEATURES=debug-build (again)
no one responded last time about this patch so lets try one more time :P
backend support for FEATURES=debug-build ... no hooks/hacks/etc... included
here to handle a user interface `emerge --debug-build`
-mike
Index: pym/portage.py
===
--- pym/portage.py (revision 3337)
+++ pym/portage.py (working copy)
@@ -1310,6 +1310,23 @@ class config:
if "usersandbox" in self.features:
self.features.remove("usersandbox")
+ if "debug-build" in self.features:
+ # the profile should be setting these, but just in case ...
+ if not len(self["DEBUG_CFLAGS"]):
+self["DEBUG_CFLAGS"] = "-g -O"
+self.backup_changes("DEBUG_CFLAGS")
+ if not len(self["DEBUG_CXXFLAGS"]):
+self["DEBUG_CXXFLAGS"] = self["DEBUG_CFLAGS"]
+self.backup_changes("DEBUG_CXXFLAGS")
+ # replace user vars with debug version
+ for var in ["CFLAGS","CXXFLAGS","LDFLAGS"]:
+self[var]=self["DEBUG_"+var]
+self.backup_changes(var)
+ # if user has splitdebug, the debug info will be auto saved for
+ # gdb, otherwise we want to keep the binaries from being stripped
+ if not "splitdebug" in self.features:
+self.features.append("nostrip")
+
self.features.sort()
self["FEATURES"] = " ".join(self.features)
self.backup_changes("FEATURES")
Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)
On Wednesday 10 May 2006 12:21, Zac Medico wrote: > Mike Frysinger wrote: > > no one responded last time about this patch so lets try one more time :P > > > > backend support for FEATURES=debug-build ... no hooks/hacks/etc... > > included here to handle a user interface `emerge --debug-build` > > This type of thing can already be done quite easily via > /etc/portage/bashrc. so ? you cant expect every user who wants to do debug building to add hacks to their own bashrc > Is it really necessary to add support for small > environment tweaks like this on the python side? yes, it's a user-friendly interface issue: we have *no* *sane* way of doing a debug emerge -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)
On Thursday 11 May 2006 02:41, Donnie Berkholz wrote: > Mike Frysinger wrote: > > yes, it's a user-friendly interface issue: > > we have *no* *sane* way of doing a debug emerge > > I don't find this particular implementation very user-friendly either, if you read my original e-mail in this thread (or even the subject), i said this is the back-end changes *only* the next step is to add `emerge --debug-build foo` > since AFAIK the FEATURES settings still aren't remembered nor should they > or settable on a per-package level. unrelated topic, see per-package.env bug > That's why x-modular.eclass has USE=debug to accomplish the same thing. which is totally wrong read the thread i started on gentoo-dev where i went over how USE=debug in the portage tree is complete trash atm -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)
On Thursday 11 May 2006 14:23, Donnie Berkholz wrote: > Mike Frysinger wrote: > > On Thursday 11 May 2006 02:41, Donnie Berkholz wrote: > >> That's why x-modular.eclass has USE=debug to accomplish the same thing. > > > > which is totally wrong > > > > read the thread i started on gentoo-dev where i went over how USE=debug > > in the portage tree is complete trash atm > > It may be wrong, but it's the only way that works usefully. so you'd rather stick with a known crappy/inconsistent methodology then move in the proper direction ? this debug-build FEATURES is the proper direction > This is totally useless IMHO until you can set it on a per-package level, bashrc hacks can add insert FEATURES on a per package basis until proper portage support is in place, but unlike the previous bashrc suggestion, this is a stop gap, not the correct, solution i'm willing to forgo this (imo) minor aspect in favor of cutting the unreliable USE=debug from the tree -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)
On Tuesday 09 May 2006 22:43, Mike Frysinger wrote: > no one responded last time about this patch so lets try one more time :P > > backend support for FEATURES=debug-build ... no hooks/hacks/etc... included > here to handle a user interface `emerge --debug-build` so do we have anyone against this ? if not i'll merge it later this weekend -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] backend support for FEATURES=debug-build (again)
On Tuesday 09 May 2006 22:43, Mike Frysinger wrote: > no one responded last time about this patch so lets try one more time :P > > backend support for FEATURES=debug-build ... no hooks/hacks/etc... included > here to handle a user interface `emerge --debug-build` so i guess no one has any problems with the current proposed patch ? -mike pgpopIuQ2Jfof.pgp Description: PGP signature
Re: [gentoo-portage-dev] tiny manpage fix
On Friday 26 May 2006 02:27, Kevin F. Quinn wrote: > On Thu, 25 May 2006 21:57:30 -0400 > > Alec Warner <[EMAIL PROTECTED]> wrote: > > Attached is a tiny diff for make.conf, can someone with l337 skills in > > manpages look it over before it gets commited. > > Easiest way to check how a man page looks is to do: > > nroff -man | less huh ? how is that easier than `man ./make.conf.5` -mike pgpwTnTXfWBYm.pgp Description: PGP signature
[gentoo-portage-dev] making permission/ownership retention consistent
when merging things from ${D} to ${ROOT}, portage currently will make sure
that the permissions in ${D} for files are retained after merging into
${ROOT}, but not for directories
for example, consider an ebuild that:
- creates dir /usr/share/foo with foo:foo ownership and 777 permissions
- creates file /usr/share/foo/bar with foo:foo ownership and 777 permissions
now the user goes in and runs:
chmod -R 700 /usr/share/foo
chown -R 0:0 /usr/share/foo
then the user goes and re-emerges the aforementioned ebuild ... then end
result ? the directory /usr/share/foo will still be 0:0 ownership with 700
permissions yet the file /usr/share/foo/bar will be reset to foo:foo
ownership and 777 permissions
personally i think that we should be retaining the permissions of the file as
is instead of resetting it, but i wont fight too hard in either direction ...
we just need the behavior to be consistent
-mike
pgpsEvCqcKnY4.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Monday 31 July 2006 13:42, Marius Mauch wrote: > Was just brought to my attention that the =* operator doesn't work as I > thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3. > This wouldn't be a bug problem if it could be used as a general glob > operator like with =foo-1.2.*, but it's use is strictly limited to the > above version (can only be used when a version component separator may > appear), so atm there is no facility to reliably lock an atom at a > specific version component when you have to account for multi-digit > components. i pointed this out quite a while ago and was told it was "by design" so i've just lived with it ... but i would be happy to see it changed as you proposed :) -mike pgpxbc6wJgy91.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Monday 31 July 2006 18:48, Brian Harring wrote: > Should be discussed on -dev, not here imo; why ? short term we're gaining functionality: simply add .* if we want to go long term and cut #*, then we can chat on gentoo-dev -mike pgpBV72zPlgkc.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Monday 31 July 2006 21:37, Drake Wyrm wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Monday 31 July 2006 18:48, Brian Harring wrote: > > > Should be discussed on -dev, not here imo; > > > > why ? short term we're gaining functionality: > > simply add .* > > Just making sure that I understand you... Given the original example > atom of =foo-1.2*, which currently matches "foo-1.2", and his objection > that =foo-1.2.* does _not_ match "foo-1.2", you're suggesting that the > matching engine be modified such that =foo-1.2.* _will_ match "foo-1.2". > Does that sound about right? you're assuming =foo-1.* even works ... it doesnt so no one is using =foo-1.* now > > if we want to go long term and cut #*, then we can chat on gentoo-dev > > Is that from a development version, or have I missed something? I can't > seem to find atoms with the hash prefix anywhere. replace the # with a number -mike pgpBqwKxzHuXO.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Monday 31 July 2006 21:30, Brian Harring wrote: > On Mon, Jul 31, 2006 at 09:11:35PM -0400, Mike Frysinger wrote: > > On Monday 31 July 2006 18:48, Brian Harring wrote: > > > Should be discussed on -dev, not here imo; > > > > why ? short term we're gaining functionality: > > simply add .* > > 1) portage isn't the only package manager invalid reason until a spec exists. portage's behavior is the spec > 2) it's not a backwards compatible change so ? same way any new feature gets merged: support it now, dont use it till later -mike pgpigeSW2jEdf.pgp Description: PGP signature
Re: [gentoo-portage-dev] Re: Atom matching behavior
On Monday 31 July 2006 23:57, Drake Wyrm wrote: > The question I'm trying to ask is this: =foo-1.2.* should obviously > match "foo-1.2.3", but should it also match on "foo-1.2"? It seems more > _useful_ that the 1.2 version would also match, despite not having the > .3 subversion, but perhaps that is not perfectly intuitive from the > syntax. portage versions have implicit .0 extension ad infinitum so matching 1.2 would make logical sense as it is really just 1.2.0 ... -mike pgpkjVUIb27Qg.pgp Description: PGP signature
Re: [gentoo-portage-dev] Re: Atom matching behavior
On Tuesday 01 August 2006 13:19, Brian Harring wrote: > On Tue, Aug 01, 2006 at 12:48:05AM -0400, Mike Frysinger wrote: > > On Monday 31 July 2006 23:57, Drake Wyrm wrote: > > > The question I'm trying to ask is this: =foo-1.2.* should obviously > > > match "foo-1.2.3", but should it also match on "foo-1.2"? It seems more > > > _useful_ that the 1.2 version would also match, despite not having the > > > .3 subversion, but perhaps that is not perfectly intuitive from the > > > syntax. > > > > portage versions have implicit .0 extension ad infinitum so matching 1.2 > > would make logical sense as it is really just 1.2.0 ... > > Err... wrong actually (try emerge -pv =dev-util/diffball-0.6.5 and > emerge -pv =dev-util/diffball-0.6.5.0). cpv's don't have implicit .0 > extensions, and that should _not_ be changed. when it comes to version comparing, there is implicit .0 extension ... which is what we're talking about here, comparing versions -mike pgpQJGnVPTQDE.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Tuesday 01 August 2006 02:58, Thomas de Grenier de Latour wrote: > - "=sys-devel/autoconf-2.1*" matches autoconf-2.13 (found in > net-proxy/privoxy and dev-tcltk/expect) this is because stupid portage lacks SLOT deps > - "=sys-devel/autoconf-2.5*" matches autoconf-2.59 (found in > x11-libs/gtk-server and media-plugins/xmms-jack) this too is because SLOT deps are missing, but this is broken anyways as it'll work with autoconf-2.6x ... -mike pgp44n4PDPuyl.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Tuesday 01 August 2006 15:49, Thomas de Grenier de Latour wrote: > - =sys-libs/db-1.8* matches 1.85 (found in > net-nds/directoryadministrator) > > - =app-text/docbook-xsl-stylesheets-1.6* matches 1.68.1 and 1.69.1 > (found in media-sound/solfege) these should actually be SLOT deps, but portage sucks -mike pgp5ECbXPG1Dw.pgp Description: PGP signature
[gentoo-portage-dev] Re: emaint
On Sunday 11 June 2006 18:38, you wrote: > The man page says you're the author (of the man page anyway) of > emaint. I don't quite understand this utility. i just usually write all the man pages > I've noticed that emerge now has something called a "set" of which > "world" is such a thing. This is a relatively recent change > (not in documentation for emerge 2.0.51.22-r3). not really, portage has always had "sets" ... the "world" and "system" sets > But even in the latest `man emerge`, this is still mentioned: > /var/lib/portage/world >Contains a list of all user-specified packages. You can safely >edit this file, adding packages that you want to be considered >in world set updates and removing those that you do not want >to be considered. > > So my question is, if I can edit it like it says I can, why should it > complain when I do something like this?: dunno, i wasnt part of decision making for said change > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > cdimage portage # echo 'sys-process/vixie-cron' > > /var/lib/portage/world cdimage portage # emerge world -pv > > These are the packages that would be merged, in order: > > Calculating world dependencies | > !!! Problems have been detected with your world file > !!! Please run emaint --check world > > >... done! > > Total size of downloads: 0 kB > cdimage portage # emaint --check world > Checking world for problems > > 'sys-process/vixie-cron' is not installed > > > Finished > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > So now what? Is world sort of useless for editing? > > Has something changed? Why can't I make edits to my world file? What I > have typically done is to copy world files from other systems during > install so that all the good stuff that I like is present (more or > less with minimal tweaking) on each new system I deploy. This worked > great until today. Any hints would be appreciated. I didn't feel that > this was necessarily a bug since it's just likely that I'm not > understanding some subtle thing that has changed. Thanks. i'll let the guys who made said change comment on it -mike pgpyc8gGJFMLa.pgp Description: PGP signature
Re: [gentoo-portage-dev] has_version and built_with_use ignore package.provided
and yet you still dont get it the point isnt that your code is wrong, the point is that if the package isnt installed, the return value of built_with_use is meaningless ive changed built_with_use to call 'die' if it is unable to locate the USE file (aka the package is not installed) -mike pgpepIoYYEe8I.pgp Description: PGP signature
Re: [gentoo-portage-dev] package.test
On Thursday 31 August 2006 20:06, Christopher Chan wrote: > I have a need to selectively run src_test() for some packages, but do > not want to run it for all like FEATURES=test. Has anyone discussed or > thought about this? what you actually want is per-package environment variables search bugzilla -mike pgpmsFLA48BVa.pgp Description: PGP signature
[gentoo-portage-dev] Re: r4676 - main/trunk/bin
On Friday 13 October 2006 22:17, Zach Medico wrote:
> - tar cpvf - ./ | bzip2 -f > "${pkg_tmp}" || die "Failed to create
> tarball"
> + tar -cf - . | bzip2 -f > "${pkg_tmp}" || die "Failed to create tarball"
dropping the v is ok but dropping the p is not
-mike
pgp4dbQp2cZOG.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Re: r4676 - main/trunk/bin
On Friday 13 October 2006 23:59, Mike Frysinger wrote:
> On Friday 13 October 2006 22:17, Zach Medico wrote:
> > - tar cpvf - ./ | bzip2 -f > "${pkg_tmp}" || die "Failed to create
> > tarball" + tar -cf - . | bzip2 -f > "${pkg_tmp}" || die "Failed to create
> > tarball"
>
> dropping the v is ok but dropping the p is not
as Zac points out, -p only affects extraction, not creation
-mike
pgp3S5nvZ2Wjw.pgp
Description: PGP signature
Re: [gentoo-portage-dev] Making doins die with FEATURES=stricter if the destination file exists
On Saturday 13 January 2007 16:58, Petteri Räty wrote: > Now doins silently overwrites files. Would probably be useful to make it > at least echo a message about this and maybe die with FEATURES=stricter. > What do you think? i'm not sure i'd like either of these ... after all, we dont have `cp` complain when it overwrites a file ... -mike pgpg57CvhKLSP.pgp Description: PGP signature
[gentoo-portage-dev] allow people to disambiguate built_with_use in upgrade situations
Diego is proposing a new flag to built_with_use to handle the corner case where you query a package that does not have the requested flag in IUSE built_with_use [--missing ] ... so in the case of version transitions, you can specify the as either true, false, or die (only current option) seems like a cleaner solution than forcing what can be a rats nest of has_version checks -mike pgpmOZ9RnTvss.pgp Description: PGP signature
Re: [gentoo-portage-dev] allow people to disambiguate built_with_use in upgrade situations
On Tuesday 16 January 2007 19:06, Mike Frysinger wrote: > built_with_use [--missing ] ... this is implemented in cvs now ... give it a spin Diego -mike pgpPP1F01YYad.pgp Description: PGP signature
Re: [gentoo-portage-dev] Sugestion
On Friday 16 February 2007, oxi wrote: > Surely it has been sugested before, or there are currently plans to > implement it. both ... search bugzilla, it's an old bug that's open -mike pgpP1BRI2Z2mL.pgp Description: PGP signature
Re: [gentoo-portage-dev] Sugestion
On Friday 16 February 2007, [EMAIL PROTECTED] wrote: > http://forums.gentoo.org/viewtopic-t-282474.html?sid=3097208b666cf527ce0221 >b0b873e2f8 that thread is lame just run: emerge world --deep -u while ! emerge world --deep -u --resume --skipfirst ; do :; done -mike pgp7GHK5NzBto.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Simon Stelling wrote: > Using preserve-libs it would leave the old lib around, > making it possible for programs to link against the wrong version and > ending up being vulnerable. generally, this is incorrect the only way you could link against it is if you were to actually specify the full path to the library: ... /usr/lib/libfoo.so.3 ... and since that's invalid usage, there is no real security impact -mike pgpBnvQvPKu3N.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Brian Harring wrote: > Security impact is from a pkg potentially dragging along old libs; if > you've got a stable pkg that gets an update once every blue moon, it > can hold onto the lib for a *long* time while still using the lib; > thus if a vuln. in the lib, said pkg still is screwed. umm, no ... the package itself is updated against the new copy while the old copy exists for other packages that have already been built > Other angle is someone intentionally forcing usage of a known bad > library that is still dangling. Corner case, but doable. as i said, this is the "invalid" syntax: ... /usr/lib/libfoo.so.3 ... besides, this is not a real concern ... if a user is purposefully relinking against files because it has a security issue, they have the ability to do a lot more than any bug exposed in the library > Bit curious how this is going to behave if via linked in libs, new loc > and old get loaded alongside... this would require multiple libraries to be involved in the equation and the answer is undefined behavior which most certainly result in runtime failures ... besides, just like the gcc-3.3 -> gcc-3.4 transition, if you dont run revdep-rebuild and things are breaking, it's your own fault -mike pgpO00K3jGoxh.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Brian Harring wrote: > On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote: > > On Saturday 17 February 2007, Brian Harring wrote: > > > Security impact is from a pkg potentially dragging along old libs; if > > > you've got a stable pkg that gets an update once every blue moon, it > > > can hold onto the lib for a *long* time while still using the lib; > > > thus if a vuln. in the lib, said pkg still is screwed. > > > > umm, no ... the package itself is updated against the new copy while the > > old copy exists for other packages that have already been built > > Suspect you're ignoring soname changes, which is about all this patch > would address- for example, ssl's old form of breakage. In that case, > *yes* the package gets updated, anything recompiled should get the > correct lib i'm not ignoring soname changes, those are exactly what i'm talking about > (assuming the code knows the appropriate linker args) there is no such thing ... it's always "-lfoo" > the old vuln. lib still will hang around as long as anything refs it. of course and this is the desired behavior ... people need to run revdep-rebuild, there's no two ways about it > > > Other angle is someone intentionally forcing usage of a known bad > > > library that is still dangling. Corner case, but doable. > > > > as i said, this is the "invalid" syntax: > > ... /usr/lib/libfoo.so.3 ... > > Not to LD_PRELOAD :) > > Haven't tried anything crazy, but suspect it can be abused to override > to the old. again, not in any scenario that actually matters ... so this too is a pointless line of thought to pursue as it has no real security impact > > > Bit curious how this is going to behave if via linked in libs, new loc > > > and old get loaded alongside... > > > > this would require multiple libraries to be involved in the equation and > > the answer is undefined behavior which most certainly result in runtime > > failures ... > > Point there was that instead of just bailing with "lib is missing", > suspect it'll manage to run, then segfault at potentially crappy > times. this is really an outside case and not worth worrying over -mike pgpaUyoVR2L1f.pgp Description: PGP signature
Re: [gentoo-portage-dev] New preserve-libs feature
On Saturday 17 February 2007, Brian Harring wrote: > On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote: > > On Saturday 17 February 2007, Brian Harring wrote: > > > (assuming the code knows the appropriate linker args) > > > > there is no such thing ... it's always "-lfoo" > > The point is that it is *not* always -lfoo. Commenting about packages > that collapse, split libs apart, where -lorig becomes -lnew1 -lnew2. so why is this an issue ... the build system for a package either takes it into account or it doesnt, it'll behave exactly the same whether we preserve the ABI lib we're preserving runtime libs here, not ones detectable by a linker process and thus a build system > Also, so help me, if you respond to valid critism with "it doesn't > actually matter" as a retort, you're getting wedgied considering > this is one of the scenarios this patch is supposed to address :p i guess come up with a valid criticism first and then i wont use that > Eh? setuid comes to mind why ? pretty much all LD_* variables are filtered by ldso in a set*id environment > or any other attempt to finagle privs via forcing the bad lib. considering the only privs you can finagle are your own, this is not an issue > Combined with the scenario above (where a > crappy pkg can hold the lib around for a *long* time), tend to think > it matters. it doesnt > It's a change in behaviour; previously, would just flat out stop; now > it'll run, but probably take a poo in your shoes. > > Going from the potential of "it won't run" to "it eats itself in > special way" is *not* something I'd blistfully write off as "not > worth worring over", considering what this change intends to address. let's review the original by copy & paste: - I'm not claiming that it's a silver bullet to all possible runtime linker problems, it's supposed to cover some of the common cases (like the expat problem) what you're talking about can never be fully solved by the methodology utilized here ... if you want the full solution, go implement your own behavior > Additional comment, introducing the change makes it so that glsa's > aren't really as accurate- version based, rather then lib. considering current glsa integration (== 0), i'd say proper general infrastructure needs to be put into place first -mike pgp0OkDNaKm9o.pgp Description: PGP signature
Re: [gentoo-portage-dev] LC_ALL and friends in make.conf
On Thursday 08 March 2007, Kevin F. Quinn wrote: > As we all know, setting LC_ALL and friends can cause all sorts of > trouble in package builds. However, many users really appreciate > being able to set it so that errors from the compiler etc are in their > own language. we've fixed our documents so users should be setting LANG, not LC_ALL > It occurs to me that during emerge, only LC_MESSAGES is actually useful > for the user, to help interpret build errors. LC_COLLATE and the > others don't give the user any benefit in the emerge process. > > So how about if LANG or LC_* are set, portage would set LC_MESSAGES and > clear the rest? > > Is there any real advantage to the user having LC_* set apart from > LC_MESSAGES? to answer the question directly, i think you're correct in that only LC_MESSAGES is a benefit to the user and screwing with the localization variables as suggested seems pretty sane hwever, ;) while i see the direction you're looking to go and the burdens you're looking to relieve, i think this just puts us back to the state that i disagree with ... namely that we shouldnt be ignoring these sort of problems, we should be fixing them -mike pgp1wst0a4EAY.pgp Description: PGP signature
Re: [gentoo-portage-dev] Add a couple new warnings to QA check
On Monday 19 March 2007, Alec Warner wrote: > If you expect these warnings to be *fixed* by developers please provide > documentation to enable developers to do so. SpanKY has some docs in > trunk/doc/ for this express purpose. As much as I love QA checks I > really don't like forcing them on people (doubly so for a failure mode > check like this) without giving people advice on how to fix them. yeah, just post a little blurb about each one and i'll see about merging it into the right places -mike pgpDJeO0zKCef.pgp Description: PGP signature
Re: [gentoo-portage-dev] Add a couple new warnings to QA check
On Monday 19 March 2007, Kevin F. Quinn wrote: > To this end it would also be useful if the QA notices were _all_ sent to > the elog report; the "Files were installed with user/group portage" one > is, but I don't think any of the others are. add "qa" to your elog classes and any messages that still arent sent arent properly using the eqawarn func and should be trivial to fix -mike pgpPyHYoVVATT.pgp Description: PGP signature
Re: [gentoo-portage-dev] Add a couple new warnings to QA check
On Monday 19 March 2007, Petteri Räty wrote: > Is eqawarn something we can use in eclasses? We have quite a few QA > checks in the java eclasses that could potentially make use of this > function. If it's not part of the public API we can of course just if it > exists and fall back to echo. it isnt part of the PMS ... so it'd need to be added -mike pgpZ3gY5Z6hMF.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Sunday 25 March 2007, Thomas de Grenier de Latour wrote: > While reading tosay's PMS draft, i've seen the following (§9.2.1), which > > reminded me this old discussion: > > = Exactly equal to the specified version. Special exception: if the > >version specified has an asterisk immediately following it, a string > >prefix comparison is used instead. When an asterisk is used, the > >specification must remain valid if the asterisk were removed. (An > >asterisk used with any other operator is illegal.) > > This ratifies the current substring matching semantics, and excludes the > "=foo/bar-1.2.*" syntax addition that has been suggested in this thread. =foo/bar-1.2.* has never been valid and still isnt valid in current portage ... i dont see a reason to force it in for EAPI=0 considering we've gotten by so far without it being a big deal -mike pgpFJ3q0KomGI.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Sunday 25 March 2007, Thomas de Grenier de Latour wrote: > My suggestion is only about dropping the substring-match semantics, to > replace it with something more restrictive, and that, it's doable for > EAPI=0 if decided now. i'd be on the fence about that ... i feel like some of your examples here of where the behavior changes is a bad thing: > =app-dicts/aspell-en-0.5* > --- > app-dicts/aspell-en-0.51.0 > app-dicts/aspell-en-0.51.1 you'd have to add more atoms to match 0.51.0, 0.52.1, 0.53.3, etc... > =app-text/docbook-xsl-stylesheets-1.6* > --- > app-text/docbook-xsl-stylesheets-1.68.1-r1 > --- > media-sound/solfege-2.0.5: =app-text/docbook-xsl-stylesheets-1.6*" > media-sound/solfege-2.0.6: =app-text/docbook-xsl-stylesheets-1.6*" same here ... you want 1.6* to match 1.67.0 and 1.68.1 and 1.69.3 ... considering the pretty subtle problems and headaches this would throw onto the heads of developers, i think it'd be saner to leave this logic change for EAPI=1 ... -mike pgp3WMldoSUYG.pgp Description: PGP signature
Re: [gentoo-portage-dev] Atom matching behavior
On Sunday 25 March 2007, Thomas de Grenier de Latour wrote:
> On 2007/03/25, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > =app-dicts/aspell-en-0.5*
> > > ---
> > > app-dicts/aspell-en-0.51.0
> > > app-dicts/aspell-en-0.51.1
> >
> > you'd have to add more atoms to match 0.51.0, 0.52.1, 0.53.3, etc...
>
> Yes and no...
>
> On one hand, only 0.51.{0,1} exist atm, so a dep on =0.51* would be
> enough.
>
> Now, i understand you want to anticipate some hypothetical future
> versions.
it isnt hypothetical, look at the history of aspell ... it had versions that
matched my example
app-text/docbook-xsl-stylesheets have examples right now that match what i'm
talking about
> But if you go that road, then i don't buy the argument:
> - there are numerous ~foo/bar-1.1 deps around, which doesn't take
> hypothetical future 1.1.1 compatible version into account. How is
> this "0.5x" particular case different, why would it be more a problem
> than the usual case?
> - there are numerous =0.1* deps around written with only 0.1.x in
> mind... If hypothetical future versions really matter, then what about
> an incompatible 0.10? Imho, taking them into account pleads for
> dropping the substring match semantics, rather than keeping it.
it works now because package maintainers tend to follow one course or the
other ... in other words, people who do x.y.z releases do not generally do
x.yz.w releases and vice versa
but each has obvious pros and cons that arent debatable, they're fact ... so
if we're gonna get screwed one way or the other, best to keep old behavior
for EAPI=0 and leave the logical (from the point of view of the pm parsing
the version) switch for EAPI=1 ...
-mike
pgpI6vwLpXqTM.pgp
Description: PGP signature
Re: [gentoo-portage-dev] use* cleanup
On Tuesday 30 October 2007, Marius Mauch wrote: > On Tue, 30 Oct 2007 19:32:52 +0100 > > "Marijn Schouten (hkBst)" <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > The purpose of this patch is to expose a generic function, namely > > _use, which can be used to build your own use* variant if you need > > that. I reimplemented all other current use function using _use (and > > _if) to cut out duplicate and verbose code. Comments expected. I > > didn't test this code. > > Please don't post patches inline, there are these things called > attachments that work so much better for such things. posting inline only works if done right ... but this wasnt done right ;) ignoring the word wrappings, whitespacing looks broken/inconsistent -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] use* cleanup
On Tuesday 30 October 2007, Marijn Schouten (hkBst) wrote: > The purpose of this patch is to expose a generic function, namely _use, > which can be used to build your own use* variant if you need that. I > reimplemented all other current use function using _use (and _if) to cut > out duplicate and verbose code. Comments expected. I didn't test this code. i guess i dont really see it ... there isnt that much duplicate code to begin with, and the end result is kind of hard to understand at first glance which is a bad thing ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] use* cleanup
On Wednesday 31 October 2007, Marijn Schouten (hkBst) wrote:
> I hope this is just an artifact of the patch being a bit opaque. The
> inconsistent indentation in the patch is a consequence of emacs bash mode
> using a different indentation style than (I guess) vi(m). I'm sure even in
> vi you can re-indent my code with one simple key-chord.
no idea, i dont use vi ... but you're writing the patch which means you get to
fix it ;)
> The immediate motivation of my examining this code was a request on
> #gentoo-dev-help by lack for something which I could with my new code
> easily write like this:
>
> use_mime() {
> local WORD="$(_if $2 $2 $1)"
>
> _use $1 "${WORD};"
> }
write where ? in eclasses/ebuilds ?
> local SUFFIX="$(_if $3 "=$3")"
> local WORD="$(_if $2 $2 $1)"
local FOO=$(...)
extraneous quoting makes eyes bleed
> _if() {
> if $1; then echo $2; else echo $3; fi
> }
$1 && echo $2 || echo $3
> if hasq ${flag} ${USE} ; then
> echo ${string_success}; return ${found}
> else
> echo ${string_failure}; return $((!found))
> fi
no point in cuddling those lines
> What's not to like?
when you've written it out, it does look much nicer ... but i'd like to
understand the motivation behind it first ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] use* cleanup
On Thursday 01 November 2007, Marijn Schouten (hkBst) wrote: > Zlin found yet another bug. Since echo "" will output a newline my current > proposed implementation of useq won't be quiet. sounds like we should have a testsuite in portage to make sure the misc variants are operating as expected -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] use* cleanup
On Thursday 01 November 2007, Marijn Schouten (hkBst) wrote:
> Mike Frysinger wrote:
> > On Wednesday 31 October 2007, Marijn Schouten (hkBst) wrote:
> >> The immediate motivation of my examining this code was a request on
> >> #gentoo-dev-help by lack for something which I could with my new code
> >> easily write like this:
> >>
> >> use_mime() {
> >> local WORD="$(_if $2 $2 $1)"
> >>
> >> _use $1 "${WORD};"
> >> }
> >
> > write where ? in eclasses/ebuilds ?
>
> yes
then there are problems:
- exported interfaces that people are expected to utilize should never ever
start with an underscore
- this is an API change which means you need to propose it and get it
accepted on the gentoo-dev mailing list
> >> if hasq ${flag} ${USE} ; then
> >>echo ${string_success}; return ${found}
> >> else
> >>echo ${string_failure}; return $((!found))
> >> fi
> >
> > no point in cuddling those lines
>
> Hmm, cuddling? I don't know what that means in this context.
it means there's no good reason for doing the echo/return on the same line
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Re: use* cleanup
On Friday 02 November 2007, Duncan wrote: > Mike Frysinger <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Thu, 01 Nov > > 2007 14:06:13 -0400: > > On Thursday 01 November 2007, Marijn Schouten (hkBst) wrote: > >> Zlin found yet another bug. Since echo "" will output a newline my > >> current proposed implementation of useq won't be quiet. > > > > sounds like we should have a testsuite in portage to make sure the misc > > variants are operating as expected > > While such a test suit would be good for portage, the other package > managers could probably use it as well. It'd therefore be useful to make > it an independent package, probably in cooperation with the EAPI > definition project. that's been discussed before, but it isnt a priority right now nor is anyone really stepping up to do it -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
On Sunday 04 November 2007, Zac Medico wrote: > Fabian Groffen wrote: > > Just to have it clear and to be sure: > > > > On 04-11-2007 03:33:41 +, [EMAIL PROTECTED] wrote: > >> Modified: diffutils-2.8.7-r2.ebuild > >> Log: > >> do *not* include userland_GNU in IUSE > >> (Portage version: 2.1.3.16) > >> > >> > >> Index: diffutils-2.8.7-r2.ebuild > >> > >> -IUSE="nls static userland_GNU" > >> +IUSE="nls static" > > > > On 04-11-2007 08:10:29 +, Zac Medico wrote: > >> Author: zmedico > >> Date: 2007-11-04 08:10:29 + (Sun, 04 Nov 2007) > >> New Revision: 8420 > >> > >> Modified: > >>main/trunk/pym/portage/dbapi/bintree.py > >> Log: > >> When evaluating *DEPEND conditionals for the Packages metadata > >> index, do not use IUSE to filter USE since there is currently > >> no guarantee that IUSE properly defines all of the necessary > >> flags. > > > > These two changes now mean that without having "userland_GNU" in IUSE > > > > DEPEND="!userland_GNU? ( some/package )" > > > > will correctly end up in the Packages file, such that Portage will > > properly calculate dependencies when reading from a binhost, right? > > Well, I consider my change to be a workaround for people behaving > like Mike and refusing to declare certain conditionals in IUSE. The > way that I see it, userland_GNU is a USE conditional, so it belongs > in IUSE just like any other USE conditional. Maybe we would be > better off if things like userland_GNU weren't in the USE > conditional space, but they are. userland_* and all other profile-expanded USE flags are "magical" and arent available for user consumption. that is how i view IUSE. it was my understanding that portage was going to get fixed to automatically include the profile-expanded ones and so adding anything to IUSE now for ebuilds is dumb when they're just going to get turned around and removed. the same goes for all implicit/automatic USE expanding things. portage can do this for us, so having developers track it themselves seems like a waste of time. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
On Sunday 04 November 2007, Andrew Gaffney wrote:
> Zac Medico wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Mike Frysinger wrote:
> >> userland_* and all other profile-expanded USE flags are "magical" and
> >> arent available for user consumption. that is how i view IUSE. it was
> >> my understanding that portage was going to get fixed to automatically
> >> include the profile-expanded ones and so adding anything to IUSE now for
> >> ebuilds is dumb when they're just going to get turned around and
> >> removed. the same goes for all implicit/automatic USE expanding things.
> >> portage can do this for us, so having developers track it themselves
> >> seems like a waste of time. -mike
> >
> > Fair enough, but we need to define a way to "automatically include
> > the profile-expanded ones" since none currently exists. One thing
> > that I don't like about using USE_EXPAND_HIDDEN is that ARCH isn't a
> > USE_EXPAND. It would have been more consistent if it had been,
> > along with KERNEL, ELIBC, and USERLAND.
>
> Why not turn it into one? The whole USE="${ARCH}" thing is inconsistent
> with the USE_EXPANDed KERNEL, ELIBC, AND USERLAND. Yes, I know that it's
> been around a lot longer than the others, but that's not a good reason for
> keeping it the way it is.
>
> I don't think it would be a difficult transition. Is there any reason that
> portage can't set both USE=${ARCH} *and* USE=arch_${ARCH} for a while
> (until all ebuilds have been changed to use the new USE_EXPANDed form)? We
> could even just have portage set both forms indefinitely (the old form does
> no harm if nothing is using it).
an interesting line of thinking and quite logical ... i dont see any arguments
against it other than "it's always been this way" and considering the
advantages for everyone, i dont think that offsets the pros
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] IUSE and userland_, elibc_, kernel_, etc.
On Sunday 04 November 2007, Zac Medico wrote:
> Mike Frysinger wrote:
> > On Sunday 04 November 2007, Andrew Gaffney wrote:
> >> Zac Medico wrote:
> >>> Mike Frysinger wrote:
> >>>> userland_* and all other profile-expanded USE flags are "magical" and
> >>>> arent available for user consumption. that is how i view IUSE. it
> >>>> was my understanding that portage was going to get fixed to
> >>>> automatically include the profile-expanded ones and so adding anything
> >>>> to IUSE now for ebuilds is dumb when they're just going to get turned
> >>>> around and removed. the same goes for all implicit/automatic USE
> >>>> expanding things. portage can do this for us, so having developers
> >>>> track it themselves seems like a waste of time. -mike
> >>>
> >>> Fair enough, but we need to define a way to "automatically include
> >>> the profile-expanded ones" since none currently exists. One thing
> >>> that I don't like about using USE_EXPAND_HIDDEN is that ARCH isn't a
> >>> USE_EXPAND. It would have been more consistent if it had been,
> >>> along with KERNEL, ELIBC, and USERLAND.
> >>
> >> Why not turn it into one? The whole USE="${ARCH}" thing is inconsistent
> >> with the USE_EXPANDed KERNEL, ELIBC, AND USERLAND. Yes, I know that it's
> >> been around a lot longer than the others, but that's not a good reason
> >> for keeping it the way it is.
> >>
> >> I don't think it would be a difficult transition. Is there any reason
> >> that portage can't set both USE=${ARCH} *and* USE=arch_${ARCH} for a
> >> while (until all ebuilds have been changed to use the new USE_EXPANDed
> >> form)? We could even just have portage set both forms indefinitely (the
> >> old form does no harm if nothing is using it).
> >
> > an interesting line of thinking and quite logical ... i dont see any
> > arguments against it other than "it's always been this way" and
> > considering the advantages for everyone, i dont think that offsets the
> > pros
>
> For the USE=arch_${ARCH} part, we only have to add ARCH to
> USE_EXPAND in the base profile. For generating the implicit IUSE, we
> can introduce a new profile variable (rather than hardcode them).
> For example, we can define IUSE_EXPAND_IMPLICIT="ARCH ELIBC KERNEL
> USERLAND" and that will cause every package to inherit the
> corresponding USE_EXPAND flags in it's IUSE.
i consider profile ones half the solution ... what about the other USE
expanded ones ? video cards / alsa drivers / etc...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] manual uninstall
On Thursday 14 February 2008, Lanza Fabrizio wrote: > I need to manually uninstall a package (without emerge --unmerge). not supported > How > do I tell emerge that a package is not installed (even if it is)? (I > basically need to force a reinstall, for a catalyst issue.) you unmerge it ... if you insist on modifying the backend information, then see: > Another good question is: how does portage know that a package is > actually installed? portage maintains installed package information in /var/db/pkg/ -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On Saturday 15 March 2008, Alec Warner wrote: > On 3/14/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Friday 14 March 2008, Alec Warner wrote: > > > On 3/14/08, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > On Thursday 13 March 2008, Steve Dibb wrote: > > > > > Because package.mask in CVS for profiles is so huge, I think it > > > > > might help it to get organized if we split it up a bit. > > > > > > > > > > halcyon had a good idea for the scheme: testing, broken, removal. > > > > > That seems to sum up the main 3 reason that a package would be > > > > > masked. > > > > > > > > > > Right now there are 679 entries in package.mask. The reason I > > > > > came up with the idea was to find a way to make it easier for > > > > > treecleaners to quickly see which ones they were working on. > > > > > > > > > > I'd like to take the discussion to -dev but wanted to get QA's > > > > > thoughts first. I haven't looked into whether or not this is > > > > > technically feasible at all. > > > > > > > > i think the real solution here is allowing masking in a package > > > > > > You want to add a metadata key and cache it you mean? > > > > i dont care terribly much about the logistics, just the results. as long > > as an ebuild can declare itself masked, it sounds good to me. > > > > this doesnt preclude the other ideas as there are often times where you > > want to have 1 global package mask piece (like large package set bumps > > ... so X or KDE or GNOME or ...). > > [-gentoo-qa, +gentoo-portage-dev] > > Original thread was splitting up package.mask entries. > > Genone notes the code to do this already is basically in already (we > just don't invoke it for $PORTDIR/profiles afaik). > > Genone, do we use existing code for package.mask (ie if we switch from > a file to a dir will it break existing versions? I am unsure if we > used the directory code for $PORTDIR/profiles/* > > If we do then I say that is the easiest method. > > MIke also mentioned a means for a single ebuild to mark itself masked. > > I think this is useless without the use of a metadata key and I'm > still not sold on its usefullnessI could easily buy some sort of > bash var that is read by a tool to generate package.mask entries > though. Seems fragile though. i dont see it being any different from an ebuild declaring its own KEYWORDS. if you want to be lazy, then have a magic KEYWORD: +pmask. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] Re: [gentoo-qa] splitting up package.mask
On Saturday 15 March 2008, Marius Mauch wrote: > On Sat, 15 Mar 2008 07:45:19 -0400 Mike Frysinger wrote: > > i dont see it being any different from an ebuild declaring its own > > KEYWORDS. if you want to be lazy, then have a magic KEYWORD: +pmask. > > What's wrong with KEYWORDS="" ? (I'm not saying it's the perfect > solution, just looking for specific requirements) no reason for masking. if you updated portage to parse the comment block above a KEYWORDS="" line, then i think that would work fine. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] EAPI, Berlin Packaging API.
On Tuesday 24 June 2008, Казанков Александр Владимирович wrote: > Recently has seen news about renewal of project Berlin Packaging API and > it became interesting to me, that developers think about EAPI and LSB > Package API (http://www.linuxfoundation.org/en/LSB_Package_API)? Whether > such realization in portage awakes? Such integration will make the > distribution kit more flexible!? considering Gentoo is not (and probably never will be) LSB compliant, i'm not sure how much the packaging stuff matters. search the dev mailing lists on the topic. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] A seemingly bug found when emerging @preserved-rebuild
On Tuesday 01 July 2008, Marius Mauch wrote: > On Wed, 2 Jul 2008 02:41:14 +0800 > > Is this a bug? or did I miss something here? > > Thanks for your time! > > The 'bug' here is that USE=multislot shouldn't exist. not really. the SLOT syntax should be sufficiently flexible, but seeing as it isnt, the result is hacks to work around a limited system. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [RFC] Change to kernel-2.eclass for bug #233266
On Saturday 23 August 2008, Mike Pagano wrote: > After querying some folks in #gentoo-portage concerning bug #233266[1], it > was suggested to me to add the entire /usr/src to PRELINK_PATH_MASK. > > To sum up the bug, when emerging tuxonice-sources with prelink installed, > every file was checked which isn't necessary since nothing in there gets > compiled during the install. > > After speaking to dsd, we were thinking of adding an env.d file from within > the postinst_sources function in the kernel-2.eclass if the file does not > already exist. This env.d file will add /usr/src to PRELINK_PATH_MASK. > > The thinking here is that the file would not be owned by any package so we > would not need one per kernel source package and it would not be removed > when unmerging a kernel package. > > Thoughts? why dont we merge it into the prelink package -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] %n in writable segment detected ??
On Saturday 14 March 2009 12:53:52 Duncan wrote: > What's the below "%n in writable segment detected" bit all about? it has nothing to do with portage and it can be ignored. if you want more info, just search bugzilla and/or google. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
> On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
> > Hi all.
> >
> > While working on my overlay, I stumbled on an issue where qfile refused
> > to acknowledge an installed file as being part of my package.
> >
> > Looking into q's implementation (portage-utils-0.1.29), I see:
> >
> > amit0 portage-utils-0.1.29 # grep -A 2 next_entry
> > ./libq/vdb_get_next_dir.c next_entry:
> > ret = readdir(dir);
> > if (ret == NULL) {
> > --
> > goto next_entry;
> > if (strchr(ret->d_name, '-') == NULL)
> > if ((strcmp(ret->d_name, "virtual")) != 0)
> > goto next_entry;
> >
> > I encountered this since I used a new category, which only contained a
> > single word. Adding a hyphen and a 2nd token solved my issue, and now
> > qfile knows the file's association.
> >
> > Is this assumption, that category should be "stringA-stringB" documented
> > somewhere?
>
> We made that assumption for portage-utils as they can be used on a
> device which has no $PORTDIR at all. So when there is no categories file
> that exists we fell back to the rules that have been working well for
> the past %d years.
>
> We changed that behavior however a while ago. I thought this was in the
> tree. But I guess not if you are hitting it.
>
> http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb
>_get_next_dir.c?r1=1.2&r2=1.3
we should do a new release already
-mike
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Monday 16 March 2009 18:49:04 Ned Ludd wrote:
> On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
> > On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
> > > On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
> > > > Hi all.
> > > >
> > > > While working on my overlay, I stumbled on an issue where qfile
> > > > refused to acknowledge an installed file as being part of my package.
> > > >
> > > > Looking into q's implementation (portage-utils-0.1.29), I see:
> > > >
> > > > amit0 portage-utils-0.1.29 # grep -A 2 next_entry
> > > > ./libq/vdb_get_next_dir.c next_entry:
> > > > ret = readdir(dir);
> > > > if (ret == NULL) {
> > > > --
> > > > goto next_entry;
> > > > if (strchr(ret->d_name, '-') == NULL)
> > > > if ((strcmp(ret->d_name, "virtual")) != 0)
> > > > goto next_entry;
> > > >
> > > > I encountered this since I used a new category, which only contained
> > > > a single word. Adding a hyphen and a 2nd token solved my issue, and
> > > > now qfile knows the file's association.
> > > >
> > > > Is this assumption, that category should be "stringA-stringB"
> > > > documented somewhere?
> > >
> > > We made that assumption for portage-utils as they can be used on a
> > > device which has no $PORTDIR at all. So when there is no categories
> > > file that exists we fell back to the rules that have been working well
> > > for the past %d years.
> > >
> > > We changed that behavior however a while ago. I thought this was in the
> > > tree. But I guess not if you are hitting it.
> > >
> > > http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq
> > >/vdb _get_next_dir.c?r1=1.2&r2=1.3
> >
> > we should do a new release already
>
> Why yes.. Yes you should :)
if you dont do it before me, i'll probably try and do it this weekend. btw, i
went through the bug reports and saw qcache crashes ... are those still
relevant ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: > There is also a bug with atom parsing iirc on 32bit platforms. gradm was > the test case. Think we need to change from int to long. the code is documented as having 64bit limitations for any specific component. the last release doesnt have the updated work i did in qatom to handle the latest atom spec though, and that includes moving from 32bit to 64bit for components ... > Maybe another with -rX parsing. if you're thinking of the open bug, that's an eprefix specific extension. they turned the X in -rX into a floating point #. which isnt supported currently. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Thursday 16 April 2009 19:05:46 Ned Ludd wrote: > On Tue, 2009-03-17 at 10:50 -0700, Ned Ludd wrote: > > On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: > > > On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: > > > > There is also a bug with atom parsing iirc on 32bit platforms. gradm > > > > was the test case. Think we need to change from int to long. > > > > > > the code is documented as having 64bit limitations for any specific > > > component. the last release doesnt have the updated work i did in qatom > > > to handle the latest atom spec though, and that includes moving from > > > 32bit to 64bit for components ... > > > > Sounds good. > > > > > > Maybe another with -rX parsing. > > > > > > if you're thinking of the open bug, that's an eprefix specific > > > extension. they turned the X in -rX into a floating point #. which > > > isnt supported currently. > > > > I don't think that was it. But I can't recall well enough off the top of > > my head the problem that somebody pointed out to me one day on irc while > > I was probably too busy. > > The error was pointed out to me again today on irc by jmbsvicetto and > hoffie, which reminded me of what I had forgot before in this thread. > > The problem was/is that qpkg is not handling -rX extensions properly. you'll have to be more specific. like i said, -rX extensions are a prefix extension and not part of the standard tree and/or spec. i'm not going to implement every random thing that someone feels like adding. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Saturday 18 April 2009 13:08:24 Ned Ludd wrote: > On Sat, 2009-04-18 at 12:55 -0400, Mike Frysinger wrote: > > On Thursday 16 April 2009 19:05:46 Ned Ludd wrote: > > > On Tue, 2009-03-17 at 10:50 -0700, Ned Ludd wrote: > > > > On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: > > > > > On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: > > > > > > Maybe another with -rX parsing. > > > > > > > > > > if you're thinking of the open bug, that's an eprefix specific > > > > > extension. they turned the X in -rX into a floating point #. which > > > > > isnt supported currently. > > > > > > > > I don't think that was it. But I can't recall well enough off the top > > > > of my head the problem that somebody pointed out to me one day on irc > > > > while I was probably too busy. > > > > > > The error was pointed out to me again today on irc by jmbsvicetto and > > > hoffie, which reminded me of what I had forgot before in this thread. > > > > > > The problem was/is that qpkg is not handling -rX extensions properly. > > > > you'll have to be more specific. like i said, -rX extensions are a > > prefix extension and not part of the standard tree and/or spec. i'm not > > going to implement every random thing that someone feels like adding. > > Heh. I don't think you understand the problem yet. Not a feature > request.. It's a real bug/regression. See the bug# that jmbsvicetto > filed this morn about it. > > https://bugs.gentoo.org/266646 yes, that is the "more information" that i required. that certainly looks bad. i'm guessing 0.1.29 works but 0.2 fails ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] files in ${FILESDIR}
On Tuesday 05 May 2009 02:26:21 Toha wrote:
> What about this idea: list all files in ${FILESDIR} (patches, init
> scripts), related to ebuild in this ebuild like:
>
> FLS=( "some-init-script" "${PN}-patch1.patch" "${PN}-${PV}-patch2.patch"
> ... "${PN}-patchN.patch" )
>
> then using this files by addressing his index in ${FLS} array
>
> applying patches with command: epatch 1 ( or in batch mode: epatch 1 2 3 )
> and init scripts like: doinitd 0
> etc.
>
> reason: easy automated way to moving ebuilds with all required files betwen
> repositories/overlays
downsides: updating of array causes ugly cascading of changes throughout the
entire ebuild instead of one or two lines. maintaining the info indirectly
with numbers makes reading ebuilds harder to understand and harder to maintain
(adding/dropping files).
such changes should be proposed on the gentoo-dev mailing list anyways ...
you'll get a lot more feedback as to why this is more "con" than "pro".
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] install_qa_check() for hppa64 and ia64-hpux
On Tuesday 14 July 2009 04:40:14 Michael Haubenwallner wrote:
> have noticed that the "Evaluating misc gcc warnings" QA check does not
> know about "hppa64" cpu in bin/misc-functions.sh:
> alpha*|hppa64*|ia64*|powerpc64*|mips64*|sparc64*|sparcv9*|x86_64*)
> gentoo_bug=yes ;; esac
looks fine to me -- feel free to add it. or if you cant, i can throw it in if
people dont beat me to it.
> This was while I was looking why this check blocked merging of gcc-4.3.3
> on the 32bit platform CHOST=ia64-hp-hpux* due to:
> warning: implicit declaration of function 'strtok_r'
>
> Yes, ia64-hp-hpux* is a multilib platform with 32bit default - the 64bit
> default would have CHOST=ia64w-hp-hpux*.
the hpux guys created their own 32bit ia64 ELF ABI !? or they're using x86
emulation ? both are wicked stupid ...
> As we do not do multilib in Prefix, "ia64-hp-hpux*" is 32bit, and I want
> to hear your thoughts about this additional line there:
> case ${CHOST} in
> + ia64-hp-hpux*) ;; # multilib with 32bit default, 64bit is
> ia64w-hp-hpux*
> alpha*|hppa64*|ia64*|powerpc64*|mips64*|sparc64*|sparcv9*|x86_64*)
> gentoo_bug=yes ;; esac
>
> Note that each of these are multilib with 32bit default too, although
> there is no "64" in the 32bit CHOST:
> sparc-*-solaris* (sparc64-*-solaris*)
> i386-*-solaris* (x86_64-*-solaris*)
> powerpc-ibm-aix* (powerpc64-ibm-aix*)
the check is to catch the majority of users, and it does. i dont want to go
down this rabbit hole. about we just fix the source code in question and call
it a day.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] install_qa_check() for hppa64 and ia64-hpux
On Thursday 16 July 2009 04:15:50 Michael Haubenwallner wrote:
> On Wed, 2009-07-15 at 10:26 -0400, Mike Frysinger wrote:
> > On Tuesday 14 July 2009 04:40:14 Michael Haubenwallner wrote:
> > > have noticed that the "Evaluating misc gcc warnings" QA check does not
> > > know about "hppa64" cpu in bin/misc-functions.sh:
> > > alpha*|hppa64*|ia64*|powerpc64*|mips64*|sparc64*|sparcv9*|x86_64*)
> > > gentoo_bug=yes ;; esac
> >
> > looks fine to me -- feel free to add it. or if you cant, i can throw it
> > in if people dont beat me to it.
>
> Should be possible for me, thank you!
ive added to svn, thanks
> > > As we do not do multilib in Prefix, "ia64-hp-hpux*" is 32bit, and I
> > > want to hear your thoughts about this additional line there:
> > > case ${CHOST} in
> > > + ia64-hp-hpux*) ;; # multilib with 32bit default, 64bit
> > > is ia64w-hp-hpux*
> > > alpha*|hppa64*|ia64*|powerpc64*|mips64*|sparc64*|sparcv9*|x86_64*)
> > > gentoo_bug=yes ;; esac
> >
> > the check is to catch the majority of users, and it does. i dont want to
> > go down this rabbit hole. about we just fix the source code in question
> > and call it a day.
>
> AFAICS, it is the only exception to "*64*" being 64bit.
> But ok, seems I'll have to mask gcc-4.3 even for hppa-hpux anyway.
the fix here though seems like it should be relatively straight forward ?
just add a missing #include or #define ? or are there more gcc-4.3 problems
than this for that target ?
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] ia64 rpaths and python building...
On Thursday 17 December 2009 04:38:36 Markus Duft wrote: > I recently did some ia64-hpux hacking in prefix, and i stumbled over > alittle problem: > > the native linker collects -L options on the command line, and python > uses -L. while building. this results in . beeing in rpath. > > now when $PWD == $S, there is libpython-*.so, and executing the already > installed python finds (through rpath ".") this local libpython. this > (although binary exactly the same) refuses to load installed extensions > (Fatal Python Error: ). > > The problem was caused by the filter-bash-environment.py call in > ebuild.sh, _only_ during the "test" phase seemingly. > > the attached patch fixes the problem for me - what do you think? I guess > there are better ways to tackle the problem, but i needed to get this to > work ;) this ignores the real problem. there should never be an installed binary whose rpath includes $PWD. this is a terrible security issues waiting to bite you in the ass, or cause random failures depending on what the user's cwd is at any point in time. the second change (adding the || exit) is a good idea in theory, but the proposed change is incorrect. use the assert helper so that the exit values of all commands in the pipeline are checked. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] portage docbook documentation -> why not asciidoc ?
On Saturday, November 27, 2010 16:39:04 Alec Warner wrote: > On Sat, Nov 27, 2010 at 6:53 AM, Zac Medico wrote: > > As it is, I'm fairly comfortable with docbook. Now you want me to learn > > a new format, with possible drawbacks, in order to try and draw in some > > contributions that may never happen? > > Here is where I would look for data. Are there pending contributions? > I have not seen anyone on this list specifically say "I'd write some > documentation if it was not in docbook." I have had issues (years > ago) getting vapier to write documentation; but I assumed that was > because he hated writing docs and he contributed documentation after a > while. not sure where you're going with this, but i'm the one who started the doc/ dir and introduced the docbook system. obviously i have no problem with it and would rather see real examples of people who are being impeded by it rather than yet another "omg we need to switch to this awesome new format because it is so awesome". -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] portage docbook documentation -> why not asciidoc ?
On Monday, November 29, 2010 18:59:04 Daniel Barkalow wrote: > On Sat, 27 Nov 2010, Zac Medico wrote: > > On 11/27/2010 01:25 AM, Sebastian Pipping wrote: > > > In case DocBook is keeping contributions down than cutting away certain > > > flexibility to increase contributions could be a good trade-off, too. > > > > I'm not sure that docbook represents a significant barrier in this > > respect. It's hard to speculate. Maybe if we had a survey sampling the > > opinions of a broad spectrum of open-source developers, then we'd have > > more to go on. > > My impression from git development is that, with asciidoc, we got a lot of > documentation patches from users who read the documentation, found that it > was inaccurate or unclear, and were able to propose corrections based on > their observation of the actual behavior. I believe we also got > documentation of previously undocumented functionality, written by people > who had found out how to use it from some other source after failing to > find it mentioned in the documentation. I suspect that docbook is too high > a barrier for some people when asciidoc wouldn't be; the question is > really whether any of these people are the audience for portage > documentation. all of the user-facing documentation is in the man pages. all of the docbook pages are generally more internal stuff. so any of the corrections you discuss i think would be files under man/ and not doc/. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH 1/4] Manifest2 hash: Whirlpool
On Thursday, September 29, 2011 21:27:39 Robin H. Johnson wrote: > Provide public-domain implementation of the Whirlpool hash algorithm to > be used as new Manifest2 hash. > > Signed-off-by: Robin H. Johnson > --- > pym/portage/checksum.py |4 + > pym/portage/util/whirlpool.py | 788 > + 2 files changed, 792 > insertions(+), 0 deletions(-) > create mode 100644 pym/portage/util/whirlpool.py shouldn't we add pycryptoplus to the tree and depend on that rather than copying & pasting their code into portage ? -mike
[gentoo-portage-dev] [PATCH 3/4] tests: add a --help option to make runtest more friendly
At the moment, trying to do `./runtests.h -h` just produces an ugly and indecipherable traceback. Make it a bit more friendly. Signed-off-by: Mike Frysinger --- pym/portage/tests/__init__.py |9 +++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/pym/portage/tests/__init__.py b/pym/portage/tests/__init__.py index 7f1ed3f..07be2f6 100644 --- a/pym/portage/tests/__init__.py +++ b/pym/portage/tests/__init__.py @@ -5,6 +5,7 @@ import sys import time import unittest +from optparse import OptionParser, OptionValueError try: from unittest.runner import _TextTestResult # new in python-2.7 @@ -23,8 +24,12 @@ def main(): basedir = os.path.dirname(os.path.realpath(__file__)) testDirs = [] - if len(sys.argv) > 1: - suite.addTests(getTestFromCommandLine(sys.argv[1:], basedir)) + usage = "usage: %s [options] [tests to run]" % sys.argv[0] + parser = OptionParser(usage=usage) + (options, args) = parser.parse_args(args=sys.argv) + + if len(args) > 1: + suite.addTests(getTestFromCommandLine(args[1:], basedir)) return TextTestRunner(verbosity=2).run(suite) # the os.walk help mentions relative paths as being quirky -- 1.7.6.1
[gentoo-portage-dev] [PATCH 0/4] make testing more user friendly
I'm not an expert at python, so trying to make sure I'm doing anything too stupid. I tried to keep existing portage style, but feel free to point out whatever. I can also push these myself, so if people are OK with them, just let me know ... you don't have to merge+push yourself. Mike Frysinger (4): runtests: make sure we are in the right dir tests: split up getTests into helper funcs to avoid duplication tests: add a --help option to make runtest more friendly tests: add --list flag to show available tests pym/portage/tests/__init__.py | 93 - runtests.sh |3 + 2 files changed, 57 insertions(+), 39 deletions(-) -- 1.7.6.1
[gentoo-portage-dev] [PATCH 2/4] tests: split up getTests into helper funcs to avoid duplication
This avoids a little duplication between the getTestFromCommandLine and
getTests funcs, and they'll get utilized even more in follow up patches.
Signed-off-by: Mike Frysinger
---
pym/portage/tests/__init__.py | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/pym/portage/tests/__init__.py b/pym/portage/tests/__init__.py
index 3897aba..7f1ed3f 100644
--- a/pym/portage/tests/__init__.py
+++ b/pym/portage/tests/__init__.py
@@ -55,7 +55,7 @@ def my_import(name):
return mod
def getTestFromCommandLine(args, base_path):
- ret = []
+ result = []
for arg in args:
realpath = os.path.realpath(arg)
path = os.path.dirname(realpath)
@@ -65,29 +65,16 @@ def getTestFromCommandLine(args, base_path):
raise Exception("Invalid argument: '%s'" % arg)
mymodule = f[:-3]
+ result.extend(getTestsFromFiles(path, base_path, [mymodule]))
+ return result
- parent_path = path[len(base_path)+1:]
- parent_module = ".".join(("portage", "tests", parent_path))
- parent_module = parent_module.replace('/', '.')
- result = []
-
- # Make the trailing / a . for module importing
- modname = ".".join((parent_module, mymodule))
- mod = my_import(modname)
- ret.append(unittest.TestLoader().loadTestsFromModule(mod))
- return ret
-
-def getTests(path, base_path):
- """
-
- path is the path to a given subdir ( 'portage/' for example)
- This does a simple filter on files in that dir to give us modules
- to import
-
- """
+def getTestNames(path):
files = os.listdir(path)
files = [ f[:-3] for f in files if f.startswith("test") and
f.endswith(".py") ]
files.sort()
+ return files
+
+def getTestsFromFiles(path, base_path, files):
parent_path = path[len(base_path)+1:]
parent_module = ".".join(("portage", "tests", parent_path))
parent_module = parent_module.replace('/', '.')
@@ -99,6 +86,16 @@ def getTests(path, base_path):
result.append(unittest.TestLoader().loadTestsFromModule(mod))
return result
+def getTests(path, base_path):
+ """
+
+ path is the path to a given subdir ( 'portage/' for example)
+ This does a simple filter on files in that dir to give us modules
+ to import
+
+ """
+ return getTestsFromFiles(path, base_path, getTestNames(path))
+
class TextTestResult(_TextTestResult):
"""
We need a subclass of unittest._TextTestResult to handle tests with TODO
--
1.7.6.1
[gentoo-portage-dev] [PATCH 1/4] runtests: make sure we are in the right dir
The code assumes we're in the top of the tree (when it tries to run with
the full path "pym/portage/tests/runTests"), so try to make sure we are
in the right place to allow things like `../runtests.sh` to "just work".
Signed-off-by: Mike Frysinger
---
runtests.sh |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/runtests.sh b/runtests.sh
index 981fa1e..d55860a 100755
--- a/runtests.sh
+++ b/runtests.sh
@@ -4,6 +4,9 @@
PYTHON_VERSIONS="2.6 2.7 3.1 3.2 3.3"
+# has to be run from portage root dir
+cd "${0%/*}" || exit 1
+
case "${NOCOLOR:-false}" in
yes|true)
GOOD=
--
1.7.6.1
[gentoo-portage-dev] [PATCH 4/4] tests: add --list flag to show available tests
Trying to guess at what runtests actually wants in terms of command line
tests is pretty hard. Any invalid value just gives you an ugly traceback.
So add a helper --list option so the user can easily figure out what the
code wants *exactly*.
Signed-off-by: Mike Frysinger
---
pym/portage/tests/__init__.py | 55 +---
1 files changed, 34 insertions(+), 21 deletions(-)
diff --git a/pym/portage/tests/__init__.py b/pym/portage/tests/__init__.py
index 07be2f6..6cce487 100644
--- a/pym/portage/tests/__init__.py
+++ b/pym/portage/tests/__init__.py
@@ -17,38 +17,28 @@ from portage import _encodings
from portage import _unicode_decode
def main():
-
- TEST_FILE = b'__test__'
- svn_dirname = b'.svn'
suite = unittest.TestSuite()
basedir = os.path.dirname(os.path.realpath(__file__))
- testDirs = []
usage = "usage: %s [options] [tests to run]" % sys.argv[0]
parser = OptionParser(usage=usage)
+ parser.add_option("-l", "--list", help="list all tests",
+ action="store_true", dest="list_tests")
(options, args) = parser.parse_args(args=sys.argv)
+ if options.list_tests:
+ testdir = os.path.dirname(sys.argv[0])
+ for mydir in getTestDirs(basedir):
+ testsubdir = os.path.basename(mydir)
+ for name in getTestNames(mydir):
+ print("%s/%s/%s.py" % (testdir, testsubdir,
name))
+ sys.exit(0)
+
if len(args) > 1:
suite.addTests(getTestFromCommandLine(args[1:], basedir))
return TextTestRunner(verbosity=2).run(suite)
- # the os.walk help mentions relative paths as being quirky
- # I was tired of adding dirs to the list, so now we add __test__
- # to each dir we want tested.
- for root, dirs, files in os.walk(basedir):
- if svn_dirname in dirs:
- dirs.remove(svn_dirname)
- try:
- root = _unicode_decode(root,
- encoding=_encodings['fs'], errors='strict')
- except UnicodeDecodeError:
- continue
-
- if TEST_FILE in files:
- testDirs.append(root)
-
- testDirs.sort()
- for mydir in testDirs:
+ for mydir in getTestDirs(basedir):
suite.addTests(getTests(os.path.join(basedir, mydir), basedir) )
return TextTestRunner(verbosity=2).run(suite)
@@ -73,6 +63,29 @@ def getTestFromCommandLine(args, base_path):
result.extend(getTestsFromFiles(path, base_path, [mymodule]))
return result
+def getTestDirs(base_path):
+ TEST_FILE = b'__test__'
+ svn_dirname = b'.svn'
+ testDirs = []
+
+ # the os.walk help mentions relative paths as being quirky
+ # I was tired of adding dirs to the list, so now we add __test__
+ # to each dir we want tested.
+ for root, dirs, files in os.walk(base_path):
+ if svn_dirname in dirs:
+ dirs.remove(svn_dirname)
+ try:
+ root = _unicode_decode(root,
+ encoding=_encodings['fs'], errors='strict')
+ except UnicodeDecodeError:
+ continue
+
+ if TEST_FILE in files:
+ testDirs.append(root)
+
+ testDirs.sort()
+ return testDirs
+
def getTestNames(path):
files = os.listdir(path)
files = [ f[:-3] for f in files if f.startswith("test") and
f.endswith(".py") ]
--
1.7.6.1
[gentoo-portage-dev] [PATCH 2/2] prepstrip: add support for elfutils strip
If people use strip from the elfutils package, take advantage of some of
its neat features (like splitting + stripping in one step).
Signed-off-by: Mike Frysinger
---
bin/ebuild-helpers/prepstrip | 63 ++
1 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/bin/ebuild-helpers/prepstrip b/bin/ebuild-helpers/prepstrip
index 7a08aba..6c8c312 100755
--- a/bin/ebuild-helpers/prepstrip
+++ b/bin/ebuild-helpers/prepstrip
@@ -34,10 +34,25 @@ for t in STRIP:strip OBJCOPY:objcopy READELF:readelf ; do
type -P -- ${!v} >/dev/null || eval ${v}=${t}
done
-# We'll leave out -R .note for now until we can check out the relevance
-# of the section when it has the ALLOC flag set on it ...
-export SAFE_STRIP_FLAGS="--strip-unneeded"
-export PORTAGE_STRIP_FLAGS=${PORTAGE_STRIP_FLAGS-${SAFE_STRIP_FLAGS} -R
.comment}
+# See if we're using GNU binutils or elfutils for stripping
+case $(${STRIP} --version) in
+*elfutils*) # dev-libs/elfutils
+ # elfutils default behavior is always safe, so don't need to specify
+ # any flags at all
+ SAFE_STRIP_FLAGS=""
+ DEF_STRIP_FLAGS="--remove-comment"
+ SPLIT_STRIP_FLAGS="-f"
+ ;;
+*) # assume binutils
+ # We'll leave out -R .note for now until we can check out the relevance
+ # of the section when it has the ALLOC flag set on it ...
+ SAFE_STRIP_FLAGS="--strip-unneeded"
+ DEF_STRIP_FLAGS="-R .comment"
+ SPLIT_STRIP_FLAGS=
+ ;;
+esac
+: ${PORTAGE_STRIP_FLAGS=${SAFE_STRIP_FLAGS} ${DEF_STRIP_FLAGS}}
+
prepstrip_sources_dir=/usr/src/debug/${CATEGORY}/${PF}
type -P debugedit >/dev/null && debugedit_found=true || debugedit_found=false
@@ -95,8 +110,12 @@ save_elf_debug() {
ln "${D}usr/lib/debug/${!inode:${#D}}.debug" "$y"
else
eval $inode=\$x
- ${OBJCOPY} --only-keep-debug "${x}" "${y}"
- ${OBJCOPY} --add-gnu-debuglink="${y}" "${x}"
+ if [[ -e ${T}/prepstrip.split.debug ]] ; then
+ mv "${T}"/prepstrip.split.debug "${y}"
+ else
+ ${OBJCOPY} --only-keep-debug "${x}" "${y}"
+ ${OBJCOPY} --add-gnu-debuglink="${y}" "${x}"
+ fi
local args="a-x,o-w"
[[ -g ${x} || -u ${x} ]] && args+=",go-r"
chmod ${args} "${y}"
@@ -117,6 +136,24 @@ save_elf_debug() {
fi
}
+process_elf() {
+ local x=$1 strip_flags=${*:2}
+
+ vecho " ${x:${#D}}"
+ save_elf_sources "${x}"
+
+ if ${strip_this} ; then
+ # see if we can split & strip at the same time
+ if [[ -n ${SPLIT_STRIP_FLAGS} ]] ; then
+ ${STRIP} ${strip_flags} -f "${T}"/prepstrip.split.debug
"${x}"
+ save_elf_debug "${x}"
+ else
+ save_elf_debug "${x}"
+ ${STRIP} ${strip_flags} "${x}"
+ fi
+ fi
+}
+
# The existance of the section .symtab tells us that a binary is stripped.
# We want to log already stripped binaries, as this may be a QA violation.
# They prevent us from getting the splitdebug data.
@@ -186,19 +223,9 @@ do
${STRIP} -g "${x}"
fi
elif [[ ${f} == *"SB executable"* || ${f} == *"SB shared object"* ]] ;
then
- vecho " ${x:${#D}}"
- save_elf_sources "${x}"
- if ${strip_this} ; then
- save_elf_debug "${x}"
- ${STRIP} ${PORTAGE_STRIP_FLAGS} "${x}"
- fi
+ process_elf "${x}" ${PORTAGE_STRIP_FLAGS}
elif [[ ${f} == *"SB relocatable"* ]] ; then
- vecho " ${x:${#D}}"
- save_elf_sources "${x}"
- if ${strip_this} ; then
- [[ ${x} == *.ko ]] && save_elf_debug "${x}"
- ${STRIP} ${SAFE_STRIP_FLAGS} "${x}"
- fi
+ process_elf "${x}" ${SAFE_STRIP_FLAGS}
fi
done
--
1.7.6.1
[gentoo-portage-dev] [PATCH 1/2] prepstrip: extract buildid with readelf to avoid debugedit when possible
The readelf utility is much more common than debugedit.
Signed-off-by: Mike Frysinger
---
bin/ebuild-helpers/prepstrip | 32 +++-
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/bin/ebuild-helpers/prepstrip b/bin/ebuild-helpers/prepstrip
index 67ceead..7a08aba 100755
--- a/bin/ebuild-helpers/prepstrip
+++ b/bin/ebuild-helpers/prepstrip
@@ -26,10 +26,13 @@ if ${RESTRICT_strip} || ${FEATURES_nostrip} ; then
${FEATURES_installsources} || exit 0
fi
-STRIP=${STRIP:-${CHOST}-strip}
-type -P -- ${STRIP} > /dev/null || STRIP=strip
-OBJCOPY=${OBJCOPY:-${CHOST}-objcopy}
-type -P -- ${OBJCOPY} > /dev/null || OBJCOPY=objcopy
+# look up the tools we might be using
+for t in STRIP:strip OBJCOPY:objcopy READELF:readelf ; do
+ v=${t%:*} # STRIP
+ t=${t#*:} # strip
+ eval ${v}=\"${!v:-${CHOST}-${t}}\"
+ type -P -- ${!v} >/dev/null || eval ${v}=${t}
+done
# We'll leave out -R .note for now until we can check out the relevance
# of the section when it has the ALLOC flag set on it ...
@@ -65,8 +68,15 @@ save_elf_sources() {
local x=$1
local inode=$(inode_var_name "$x")
[[ -n ${!inode} ]] && return 0
- debugedit -b "${WORKDIR}" -d "${prepstrip_sources_dir}" \
- -l "${T}"/debug.sources "${x}"
+
+ # since we're editing the ELF here, we should recompute the build-id
+ # (the -i flag below). save that output so we don't need to recompute
+ # it later on in the save_elf_debug step.
+ buildid=$(debugedit -i \
+ -b "${WORKDIR}" \
+ -d "${prepstrip_sources_dir}" \
+ -l "${T}"/debug.sources \
+ "${x}")
}
save_elf_debug() {
@@ -78,9 +88,6 @@ save_elf_debug() {
# dont save debug info twice
[[ ${x} == *".debug" ]] && return 0
- # this will recompute the build-id, but for now that's ok
- local buildid="$( ${debugedit_found} && debugedit -i "${x}" )"
-
mkdir -p "${y%/*}"
local inode=$(inode_var_name "$x")
@@ -95,6 +102,12 @@ save_elf_debug() {
chmod ${args} "${y}"
fi
+ # if we don't already have build-id from debugedit, look it up
+ if [[ -z ${buildid} ]] ; then
+ # convert the readelf output to something useful
+ buildid=$(${READELF} -x .note.gnu.build-id "${x}" 2>/dev/null \
+ | awk '$NF ~ /GNU/ { getline; printf $2$3$4$5; getline;
print $2 }')
+ fi
if [[ -n ${buildid} ]] ; then
local buildid_dir="${D}usr/lib/debug/.build-id/${buildid:0:2}"
local buildid_file="${buildid_dir}/${buildid:2}"
@@ -165,6 +178,7 @@ do
# actually causes problems. install sources for all
# elf types though cause that stuff is good.
+ buildid=
if [[ ${f} == *"current ar archive"* ]] ; then
vecho " ${x:${#D}}"
if ${strip_this} ; then
--
1.7.6.1
Re: [gentoo-portage-dev] [PATCH 2/2] prepstrip: add support for elfutils strip
On Tuesday 11 October 2011 03:11:03 Fabian Groffen wrote:
> On 11-10-2011 00:50:54 -0400, Mike Frysinger wrote:
> > If people use strip from the elfutils package, take advantage of some of
> > its neat features (like splitting + stripping in one step).
> >
> > +# See if we're using GNU binutils or elfutils for stripping
> > +case $(${STRIP} --version) in
> > +*elfutils*) # dev-libs/elfutils
> > + # elfutils default behavior is always safe, so don't need to specify
> > + # any flags at all
> > + SAFE_STRIP_FLAGS=""
> > + DEF_STRIP_FLAGS="--remove-comment"
> > + SPLIT_STRIP_FLAGS="-f"
> > + ;;
> > +*) # assume binutils
>
> For the sake of it, can we try to detect GNU binutils here? Our
> profiles restrict strip, so no immediate problem here if not.
>
> % strip --version
> strip: unrecognized option: --version
> Usage: strip [-AnuSXx] [-] [-d filename] [-s filename] [-R filename] [-o
> output] file [...]
adding detection here will fix most, but i don't think all, of your troubles
the code still unconditionally runs `strip -g` which i'm guessing won't work
for you ...
also, we only run strip on ELF files. so if you aren't an ELF system, even
fixing the -g won't help.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH 2/2] prepstrip: add support for elfutils strip
On Tuesday 11 October 2011 10:55:32 Fabian Groffen wrote: > On 11-10-2011 10:18:16 -0400, Mike Frysinger wrote: > > > For the sake of it, can we try to detect GNU binutils here? Our > > > profiles restrict strip, so no immediate problem here if not. > > > > adding detection here will fix most, but i don't think all, of your > > troubles > > > > the code still unconditionally runs `strip -g` which i'm guessing won't > > work for you ... > > > > also, we only run strip on ELF files. so if you aren't an ELF system, > > even fixing the -g won't help. > > Actually, on Solaris (ELF) the way Portage uses strip will damage the > files in such a way that they become unusable. And we're using GNU > binutils there. So I guess it's ok to assume here. In the profiles > stripping is just disabled everywhere it breaks. so GNU binutils is broken on Solaris ? the flags that portage uses should be safe (by design) when stripping ELF files. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] sleep 1 in misc-functions.sh
On Thursday 20 October 2011 07:20:14 Fabian Groffen wrote: > The full context of this message is from a thread on gentoo-alt ml: > http://archives.gentoo.org/gentoo-alt/msg_db73b1a140fd958efb88f2437170646d. > xml > > Long story short, this person has to deal with a fileserver that sets > the rw world bits on for all files that are created. > While I don't think the suggested patch is fair (this is obviously a > very badly configured fileserver), I do wonder if the "sleep 1" that is > in the code is actually desired. In case we want it, I would suggest we > move down the "sleep 1" so it's only done once for the entire list with > files. > > Can we use eqawarn in bin/misc-functions.sh:177 instead and avoid the > sleep? or have it sleep once overall instead of per file -mike signature.asc Description: This is a digitally signed message part.
[gentoo-portage-dev] Re: [gentoo-dev] Re: proj/portage:master commit in: pym/portage/dbapi/
On Saturday 26 November 2011 07:50:27 Nirbheek Chauhan wrote: > On Sat, Nov 26, 2011 at 5:08 PM, Fabian Groffen wrote: > > On 26-11-2011 16:56:41 +0530, Nirbheek Chauhan wrote: > >> [...] Besides, sorting even 30,000 > >> entries (if you're merging every ebuild in portage) should not take > >> more than a few secs. > > > > A linux kernel has around that much of files, and I really wonder if > > it's worth waiting a couple of seconds (probably more on sparc and arm > > systems) just because then the files are in sorted order. > > I'm not sure the two are really comparable. However, looking at a > simple string sort on 30,000 strings, I don't see it taking a > significant amount of time at all: sure, it's probably not significantly higher, but i also can't see any point in sorting the entries. we've been doing fine so far in the 10+ years of it being unsorted. so unless Arfrever has a compelling reason, time to revert. -mike signature.asc Description: This is a digitally signed message part.
