[gentoo-dev] Lastrite: FlowScan, CUFlow, and JKFlow
# Sammuli Suominen ssuomi...@gentoo.org (01 Feb 2012) # Masked for removal in 30 days for having unallowed depend for # unslotted net-analyzer/rrdtool-1.2 in the same stabilization # level net-analyzer/FlowScan dev-perl/CUFlow dev-perl/JKFlow
Re: [gentoo-dev] [rfc] Which ebuild category should these ebulds go into?
On Wed, 2012-02-01 at 07:01 +0100, Sebastian Pipping wrote: spacenavd driver daemon (with optional X support) -- sys-apps/spacenavd ? -- app-misc/spacenavd ? -- .. ? I would suggest either sys-apps or x11-drivers. libspnav library accessing before-mentioned daemon -- dev-libs/libspnav ? -- media-libs/libspnav ? -- sys-libs/libspnav ? -- .. ? dev-libs seems reasonable. sys-libs definitely feels wrong, libspnav would look out of place in that exclusive company of core system libraries. -Alexandre
Re: [gentoo-dev] [rfc] Which ebuild category should these ebulds go into?
Take a look at g15daemon (useful for some logitech keyboards). There you have: app-misc/g15daemon dev-libs/libg15
Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
On Tue, 31 Jan 2012 19:58:32 -0500
Anthony G. Basile bluen...@gentoo.org wrote:
On 01/29/2012 02:14 PM, Mike Frysinger wrote:
On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
I've run nbench on two amd64 systems both running the same kernel
vanilla-3.2.2.
i don't think nbench is a good benchmark for this as it isn't
really testing what you think it's testing. it's very good at
validating math support in the ISA/ABI, optimized compiler output,
and supplementary math implementations in libgcc. PIE vs non-PIE
will still be able to multiply/divide in pretty much the same
amount of time.
I know, but the problem is, what benchmark best approximates common
every day use? So I wrote the following which really hits the
problem hard on x86:
int modfac(int n)
{
if(n==0) return 1;
return n * modfac(n-1);
}
int main()
{
int i;
for( i = 0 ; i 4096*4096 ; i++ ) modfac(4096);
return 0;
}
Using vanilla kernel 3.2.2, userland built with vanilla toolchain,
gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code
simply as gcc -o test modfac.c, CFLAGS=-O2 -march=i686 -pipe I get:
time -p ./test
real 327.89
user 327.72
sys 0.00
Keep everything else the same, even the same hardware, but switch to
userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus
error), I get:
time -p ./test
real 629.68
user 629.37
sys 0.00
The hardware is 8 x Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz with 12
GB ram. That's nearly a factor of 2x but how often does one set up
4k stack frames in everyday use?
So at least on amd64, I don't think that performance is ever an
issue.
yes, most likely on systems where the PIC has hardware support in
the ISA, the performance hit on PIE is typically low.
I have yet to look at x86.
pretty sure this is going to be much more palpable.
-mike
Vanilla userland is simply a stage3 chroot amd64.
hardened kernel/userland
real5m43.402s
user5m42.510s
sys 0m0.002s
hardened kernel/vanilla gcc
real5m29.271s
user5m28.417s
sys 0m0.003s
hardened kernel/vanilla userland
real5m29.495s
user5m28.599s
sys 0m0.030s
vanilla all (disabled pax and grsec on hardened kernel, compiled kernel
with hardened gcc)
real5m34.861s
user5m33.981s
sys 0m0.001s
i686 cflag test, vanilla all
CFLAGS=-O2 -march=i686 -pipe
gcc modfac.c -o vv-moddfac
real5m42.171s
user5m41.176s
sys 0m0.092s
CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
RAM: 16G
--
Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
Re: [gentoo-dev] [rfc] Which ebuild category should these ebulds go into?
On 02/01/2012 09:42 AM, ScytheMan wrote: Take a look at g15daemon (useful for some logitech keyboards). There you have: app-misc/g15daemon dev-libs/libg15 Great, thanks! Best, Sebastian
[gentoo-dev] RFC: New eclass: mozlinguas.eclass
Hello folks,
We in the mozilla team got tired of duplicating the same 50 lines of
code across 6 ebuilds, and decided to consolidate them inside one
eclass.
The eclass is specific to Mozilla products (no one else can or should use it).
It generates SRC_URI using a list of supported language packs
${LANGS[@]}, and exports src_unpack and src_install to install
language packs.
I'd love to have the attached eclass reviewed before I commit it. For
those using gmail, here's a web copy: http://i.cx/ahp
(git.o.g.o/mozilla)
Thanks!
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
mozlinguas.eclass
Description: Binary data
[gentoo-dev] unpacker.eclass
any feedback before merging this initial version ?
https://bugs.gentoo.org/399019
-mike
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v 1.377 2012/01/03
08:45:36 jlec Exp $
# @ECLASS: unpacker.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
# @BLURB: helpers for extraneous file formats and consistent behavior across
EAPI's
# @DESCRIPTION:
# Some extraneous file formats are not part of PMS, or are only in certain
# EAPI's. Rather than worrying about that, support the crazy cruft here
# and for all EAPI versions.
# Possible todos:
# - merge rpm unpacking
# - support partial unpacks?
if [[ ${___ECLASS_ONCE_UNPACKER} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_UNPACKER=recur -_+^+_- spank
# @ECLASS-VARIABLE: UNPACKER_BZ2
# @DEFAULT_UNSET
# @DESCRIPTION:
# Utility to use to decompress bzip2 files. Will dynamically pick between
# `pbzip2` and `bzip2`. Make sure your choice accepts the -c option.
# Note: this is meant for users to set, not ebuilds.
# for internal use only (unpack_pdv and unpack_makeself)
find_unpackable_file() {
local src=$1
if [[ -z ${src} ]] ; then
src=${DISTDIR}/${A}
else
if [[ ${src} == ./* ]] ; then
: # already what we want
elif [[ -e ${DISTDIR}/${src} ]] ; then
src=${DISTDIR}/${src}
elif [[ -e ${PWD}/${src} ]] ; then
src=${PWD}/${src}
elif [[ -e ${src} ]] ; then
src=${src}
fi
fi
[[ ! -e ${src} ]] return 1
echo ${src}
}
unpack_banner() {
echo Unpacking ${1##*/} to ${PWD}
}
# @FUNCTION: unpack_pdv
# @USAGE: file to unpack size of off_t
# @DESCRIPTION:
# Unpack those pesky pdv generated files ...
# They're self-unpacking programs with the binary package stuffed in
# the middle of the archive. Valve seems to use it a lot ... too bad
# it seems to like to segfault a lot :(. So lets take it apart ourselves.
#
# You have to specify the off_t size ... I have no idea how to extract that
# information out of the binary executable myself. Basically you pass in
# the size of the off_t type (in bytes) on the machine that built the pdv
# archive.
#
# One way to determine this is by running the following commands:
#
# @CODE
# strings pdv archive | grep lseek
# strace -elseek pdv archive
# @CODE
#
# Basically look for the first lseek command (we do the strings/grep because
# sometimes the function call is _llseek or something) and steal the 2nd
# parameter. Here is an example:
#
# @CODE
# vapier@vapier 0 pdv_unpack # strings hldsupdatetool.bin | grep lseek
# lseek
# vapier@vapier 0 pdv_unpack # strace -elseek ./hldsupdatetool.bin
# lseek(3, -4, SEEK_END) = 2981250
# @CODE
#
# Thus we would pass in the value of '4' as the second parameter.
unpack_pdv() {
local src=$(find_unpackable_file $1)
local sizeoff_t=$2
[[ -z ${src} ]] die Could not locate source for '$1'
[[ -z ${sizeoff_t} ]] die No idea what off_t size was used for this
pdv :(
unpack_banner ${src}
local metaskip=$(tail -c ${sizeoff_t} ${src} | hexdump -e \%i\)
local tailskip=$(tail -c $((${sizeoff_t}*2)) ${src} | head -c
${sizeoff_t} | hexdump -e \%i\)
# grab metadata for debug reasons
local metafile=$(emktemp)
tail -c +$((${metaskip}+1)) ${src} ${metafile}
# rip out the final file name from the metadata
local datafile=$(tail -c +$((${metaskip}+1)) ${src} | strings | head
-n 1)
datafile=$(basename ${datafile})
# now lets uncompress/untar the file if need be
local tmpfile=$(emktemp)
tail -c +$((${tailskip}+1)) ${src} 2/dev/null | head -c 512
${tmpfile}
local iscompressed=$(file -b ${tmpfile})
if [[ ${iscompressed:0:8} == compress ]] ; then
iscompressed=1
mv ${tmpfile}{,.Z}
gunzip ${tmpfile}
else
iscompressed=0
fi
local istar=$(file -b ${tmpfile})
if [[ ${istar:0:9} == POSIX tar ]] ; then
istar=1
else
istar=0
fi
#for some reason gzip dies with this ... dd cant provide buffer fast
enough ?
#dd if=${src} ibs=${metaskip} count=1 \
# | dd ibs=${tailskip} skip=1 \
# | gzip -dc \
#${datafile}
if [ ${iscompressed} -eq 1 ] ; then
if [ ${istar} -eq 1 ] ; then
tail -c +$((${tailskip}+1)) ${src} 2/dev/null \
| head -c $((${metaskip}-${tailskip})) \
| tar -xzf -
else
tail -c +$((${tailskip}+1))
Re: [gentoo-dev] Can we get PIE on all SUID binaries by default, por favor?
On Tuesday 31 January 2012 19:58:32 Anthony G. Basile wrote:
On 01/29/2012 02:14 PM, Mike Frysinger wrote:
On Saturday 28 January 2012 07:26:59 Anthony G. Basile wrote:
I've run nbench on two amd64 systems both running the same kernel
vanilla-3.2.2.
i don't think nbench is a good benchmark for this as it isn't really
testing what you think it's testing. it's very good at validating math
support in the ISA/ABI, optimized compiler output, and supplementary
math implementations in libgcc. PIE vs non-PIE will still be able to
multiply/divide in pretty much the same amount of time.
I know, but the problem is, what benchmark best approximates common
every day use? So I wrote the following which really hits the problem
hard on x86:
int modfac(int n)
{
if(n==0) return 1;
return n * modfac(n-1);
}
int main()
{
int i;
for( i = 0 ; i 4096*4096 ; i++ ) modfac(4096);
return 0;
}
Using vanilla kernel 3.2.2, userland built with vanilla toolchain,
gcc-4.5.3-r1, glibc-2.13-r4, binutils-2.21.1-r1, compiling my code
simply as gcc -o test modfac.c, CFLAGS=-O2 -march=i686 -pipe I get:
time -p ./test
real 327.89
user 327.72
sys 0.00
Keep everything else the same, even the same hardware, but switch to
userland built with hardened gcc-4.5.3-r2 (not -r1 because of the bus
error), I get:
time -p ./test
real 629.68
user 629.37
sys 0.00
The hardware is 8 x Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz with 12 GB
ram. That's nearly a factor of 2x but how often does one set up 4k
stack frames in everyday use?
you mean how often do people do recursion on data sets ? is that 2x slow down
really because of the *depth* of the stack ?
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: New eclass: mozlinguas.eclass
On Thu, Feb 2, 2012 at 12:55 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote:
I'd love to have the attached eclass reviewed before I commit it. For
those using gmail, here's a web copy: http://i.cx/ahp
(git.o.g.o/mozilla)
After comments from mgorny on #gentoo-dev, I've made the following changes:
(a) Use mozlinguas() instead of linguas() (namespace)
(b) Use lowercase for local iterator variables
An updated eclass is attached (this time with a fake extension to get
gmail to see it as ascii text!).
Web version:
http://git.overlays.gentoo.org/gitweb/?p=proj/mozilla.git;a=blob;f=eclass/mozlinguas.eclass;hb=HEAD
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: mozlinguas.eclass
# @MAINTAINER: mozi...@gentoo.org
# @AUTHOR: Nirbheek Chauhan nirbh...@gentoo.org
# @BLURB: Handle language packs for mozilla products
# @DESCRIPTION:
# Sets IUSE according to LANGS (language packs available). Also exports
# src_unpack and src_install for use in ebuilds.
inherit mozextension
case ${EAPI:-0} in
0|1)
die EAPI ${EAPI:-0} does not support the '-' SRC_URI
operator;;
2|3|4)
EXPORT_FUNCTIONS src_unpack src_install;;
*)
die EAPI ${EAPI} is not supported, contact eclass
maintainers;;
esac
# @ECLASS-VARIABLE: LANGS
# @DEFAULT-UNSET
# @DESCRIPTION: Array containing the list of language pack xpis available for
# this release. The list can be updated with scripts/get_langs.sh from the
# mozilla overlay.
: ${LANGS:=}
# @ECLASS-VARIABLE: MOZ_PV
# @DESCRIPTION: Ebuild package version converted to equivalent upstream version.
# Defaults to ${PV}, and should be overridden for alphas, betas, and RCs
: ${MOZ_PV:=${PV}}
# @ECLASS-VARIABLE: MOZ_PN
# @DESCRIPTION: Ebuild package name converted to equivalent upstream name.
# Defaults to ${PN}, and should be overridden for binary ebuilds.
: ${MOZ_PN:=${PN}}
# @ECLASS-VARIABLE: MOZ_P
# @DESCRIPTION: Ebuild package name + version converted to upstream equivalent.
# Defaults to ${MOZ_PN}-${MOZ_PV}
: ${MOZ_P:=${MOZ_PN}-${MOZ_PV}}
# @ECLASS-VARIABLE: FTP_URI
# @DEFAULT-UNSET
# @DESCRIPTION: The ftp URI prefix for the release tarballs and language packs.
: ${FTP_URI:=}
# @ECLASS-VARIABLE: LANGPACK_PREFIX
# @DESCRIPTION: The relative path till the lang code in the langpack file URI.
# Defaults to ${MOZ_PV}/linux-i686/xpi/
: ${LANGPACK_PREFIX:=${MOZ_PV}/linux-i686/xpi/}
# @ECLASS-VARIABLE: LANGPACK_SUFFIX
# @DESCRIPTION: The suffix after the lang code in the langpack file URI.
# Defaults to '.xpi'
: ${LANGPACK_SUFFIX:=.xpi}
# Add linguas_* to IUSE according to available language packs
# No language packs for alphas and betas
if ! [[ ${PV} =~ alpha|beta ]]; then
for x in ${LANGS[@]} ; do
# en and en_US are handled internally
if [[ ${x} = en ]] || [[ ${x} = en-US ]]; then
continue
fi
SRC_URI=${SRC_URI}
linguas_${x/-/_}?
(
${FTP_URI}/${LANGPACK_PREFIX}${x}${LANGPACK_SUFFIX} - ${MOZ_P}-${x}.xpi )
IUSE=${IUSE} linguas_${x/-/_}
# We used to do some magic if specific/generic locales were
missing, but
# we stopped doing that due to bug 325195.
done
fi
mozlinguas() {
[[ ${PV} =~ alpha|beta ]] return
# Generate the list of language packs called linguas
# This list is used to unpack and install the xpi language packs
local lingua
for lingua in ${LINGUAS}; do
if has ${lingua} en en_US; then
# For mozilla products, en and en_US are handled
internally
continue
# If this language is supported by ${P},
elif has ${lingua} ${LANGS[@]//-/_}; then
# Add the language to linguas, if it isn't already there
has ${lingua//_/-} ${linguas[@]} ||
linguas+=(${lingua//_/-})
continue
# For each short lingua that isn't in LANGS,
# We used to add *all* long LANGS to the linguas list,
# but we stopped doing that due to bug 325195.
fi
ewarn Sorry, but ${P} does not support the ${lingua} locale
done
}
# @FUNCTION: mozlinguas_src_unpack
# @DESCRIPTION:
# Unpack xpi language packs according to the user's LINGUAS settings
mozlinguas_src_unpack() {
local x
mozlinguas
for x in ${linguas[@]}; do
# FIXME: Add support for unpacking xpis to portage
xpi_unpack ${MOZ_P}-${x}.xpi
done
if [[ ${linguas[*]} != ${linguas[*]} != en ]]; then
einfo Selected language packs (first will be default):
${linguas[*]}
fi
}
# @FUNCTION:
Re: [gentoo-dev] unpacker.eclass
On Wed, 1 Feb 2012 15:05:40 -0500
Mike Frysinger vap...@gentoo.org wrote:
# You have to specify the off_t size ... I have no idea how to
extract that # information out of the binary executable myself.
Basically you pass in # the size of the off_t type (in bytes) on the
machine that built the pdv # archive.
Can't you use 'file' to determine the host type and just assume off_t
for it?
# @FUNCTION: unpack_makeself
# @USAGE: [file to unpack] [offset] [tail|dd]
# @DESCRIPTION:
# Unpack those pesky makeself generated files ...
# They're shell scripts with the binary package tagged onto
# the end of the archive. Loki utilized the format as does
# many other game companies.
#
# If the file is not specified, then ${A} is used. If the
# offset is not specified then we will attempt to extract
# the proper offset from the script itself.
The third argument is not explained.
unpack_makeself() {
local src_input=${1:-${A}}
What if ${A} contains more than a single file? Well, what is this for
anyway?
case ${exe} in
tail) exe=tail -n +${skip} '${src}';;
dd) exe=dd ibs=${skip} skip=1
if='${src}';; *) die makeself cant handle exe
'${exe}' esac
What is the use of that?
# @FUNCTION: unpacker
Wrong name.
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and figure out
the # dependencies that are needed to unpack things.
#
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to fallback to
'unpack' anywhere too.
And I think you should consider using 'file --mime' rather than
relying on format descriptions not ever changing/differing due to
subtle differences.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] unpacker.eclass
On Wednesday 01 February 2012 15:30:16 Michał Górny wrote:
On Wed, 1 Feb 2012 15:05:40 -0500 Mike Frysinger wrote:
# You have to specify the off_t size ... I have no idea how to
extract that # information out of the binary executable myself.
Basically you pass in # the size of the off_t type (in bytes) on the
machine that built the pdv # archive.
Can't you use 'file' to determine the host type and just assume off_t
for it?
i'm not looking for feedback on the unpack_{makeself,pdv} at this point in
time. i'll look after the eutils-unpacker migration is done.
# @FUNCTION: unpacker
Wrong name.
fixed
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and figure out
the # dependencies that are needed to unpack things.
#
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to fallback to
'unpack' anywhere too.
eh ? this func doesn't do unpacking, just ${SRC_URI}-${DEPEND} matching.
And I think you should consider using 'file --mime' rather than
relying on format descriptions not ever changing/differing due to
subtle differences.
probably worth looking at
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] unpacker.eclass
On Wed, 1 Feb 2012 15:44:14 -0500
Mike Frysinger vap...@gentoo.org wrote:
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and figure
out the # dependencies that are needed to unpack things.
#
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to fallback to
'unpack' anywhere too.
eh ? this func doesn't do unpacking, just ${SRC_URI}-${DEPEND}
matching.
Sooo.. it's intended to generate an useless DEPEND or you have to
reset src_unpack() to default to make the archives actually extractable.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] unpacker.eclass
On Wednesday 01 February 2012 15:51:52 Michał Górny wrote:
On Wed, 1 Feb 2012 15:44:14 -0500 Mike Frysinger wrote:
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and figure
out the # dependencies that are needed to unpack things.
#
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to fallback to
'unpack' anywhere too.
eh ? this func doesn't do unpacking, just ${SRC_URI}-${DEPEND}
matching.
Sooo.. it's intended to generate an useless DEPEND
the ebuild does:
DEPEND+= $(unpacker_src_uri_depends)
or you have to reset src_unpack() to default to make the archives actually
extractable.
this func has nothing to do with extraction. look at the rest of the code to
see how the default src_unpack is handled via standard EXPORT_FUNC means.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] unpacker.eclass
On Wed, 2012-02-01 at 15:05 -0500, Mike Frysinger wrote: # @BLURB: helpers for extraneous file formats and consistent behavior across EAPI's # @DESCRIPTION: # Some extraneous file formats are not part of PMS, or are only in certain # EAPI's. Rather than worrying about that, support the crazy cruft here s/EAPI's/EAPIs/g Plurals of acronyms are formed without using the apostrophe. E.g. see http://grammar.about.com/od/punctuationandmechanics/tp/GuideApostrophe.htm or http://owl.english.purdue.edu/owl/resource/621/01/ -Alexandre.
Re: [gentoo-dev] unpacker.eclass
On Wed, 1 Feb 2012 15:55:46 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Wednesday 01 February 2012 15:51:52 Michał Górny wrote:
On Wed, 1 Feb 2012 15:44:14 -0500 Mike Frysinger wrote:
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and
figure out the # dependencies that are needed to unpack
things. #
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to
fallback to 'unpack' anywhere too.
eh ? this func doesn't do unpacking, just ${SRC_URI}-${DEPEND}
matching.
Sooo.. it's intended to generate an useless DEPEND
the ebuild does:
DEPEND+= $(unpacker_src_uri_depends)
or you have to reset src_unpack() to default to make the archives
actually extractable.
this func has nothing to do with extraction. look at the rest of the
code to see how the default src_unpack is handled via standard
EXPORT_FUNC means. -mike
Yes, and can that exported default src_unpack() extract either .rar
or .7z?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] unpacker.eclass
On Wednesday 01 February 2012 18:12:02 Michał Górny wrote:
On Wed, 1 Feb 2012 15:55:46 -0500 Mike Frysinger wrote:
On Wednesday 01 February 2012 15:51:52 Michał Górny wrote:
On Wed, 1 Feb 2012 15:44:14 -0500 Mike Frysinger wrote:
# @USAGE: [archives that we will unpack]
# @RETURN: Dependencies needed to unpack all the archives
# @DESCRIPTION:
# Walk all the specified files (defaults to $SRC_URI) and
figure out the # dependencies that are needed to unpack
things. #
# Note: USE flags are not yet handled.
unpacker_src_uri_depends() {
local uri deps d
[[ $# -eq 0 ]] set -- ${SRC_URI}
for uri in $@ ; do
case ${uri} in
*.rar|*.RAR)
d=app-arch/unrar ;;
*.7z)
d=app-arch/p7zip ;;
Where are those file formats handled? You don't seem to
fallback to 'unpack' anywhere too.
eh ? this func doesn't do unpacking, just ${SRC_URI}-${DEPEND}
matching.
Sooo.. it's intended to generate an useless DEPEND
the ebuild does:
DEPEND+= $(unpacker_src_uri_depends)
or you have to reset src_unpack() to default to make the archives
actually extractable.
this func has nothing to do with extraction. look at the rest of the
code to see how the default src_unpack is handled via standard
EXPORT_FUNC means.
Yes, and can that exported default src_unpack() extract either .rar
or .7z?
there are no plans for that since portage handles it from EAPI=0 onwards. i
can have _unpacker() automatically tail off into `unpack` if it finds a file it
doesn't recognize.
-mike
signature.asc
Description: This is a digitally signed message part.
