Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On 17/06/2013 06:55, Mike Frysinger wrote: >> > tar -xJf "./$i" > why doesn't the bzip2 detect as bzip2 ? > Capital J is XZ not bzip2.. still, it makes me think it needs a newer version of file to recognize it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: evar_push/pop helpers
On Monday 17 June 2013 01:42:15 Mike Frysinger wrote:
> On Sunday 02 June 2013 13:38:04 Steven J. Long wrote:
> > On Sat, Jun 01, 2013 at 11:03:20PM -0400, Mike Frysinger wrote:
> > > +# is not specified, the var will be unset.
> > > +evar_push_set() {
> > > + local var=$1
> > > + evar_push ${var}
> > > + case $# in
> > > + 1) unset ${var} ;;
> > > + 2) eval ${var}=\$2 ;;
> >
> > I wish you wouldn't use eval for this. I know it's technically okay here,
> > or would be if you verified the parameter, but bash has printf -v for
> > this purpose:
>
> interesting, i hadn't seen that before ... looks new to bash-3.1. /me
> tucks that into his tool belt.
>
> although it doesn't quite work in the edge case where the value is an empty
> string. consider:
> unset x
> printf -v x ''
> echo ${x+set}
>
> that should show "set", but it does not. i'll have to keep `eval ${var}=`
> when the value we're setting is empty. or just keep the eval code since i
> have to do eval anyways at that point.
>
> i'll report it upstream to the bash guys.
looks like it can be worked around by doing:
printf -v x '%s' ''
which is arguably what we want anyways
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On Monday 17 June 2013 03:15:53 Diego Elio Pettenò wrote: > On 17/06/2013 06:55, Mike Frysinger wrote: > >> > tar -xJf "./$i" > > > > why doesn't the bzip2 detect as bzip2 ? > > Capital J is XZ not bzip2.. still, it makes me think it needs a newer > version of file to recognize it. the stupid default font doesn't clearly render that. guess that's the older LZMA format rather than the newer XZ as the latter can be detected by file. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 12:08 PM, Mike Frysinger wrote: > On Monday 17 June 2013 03:15:53 Diego Elio Pettenò wrote: >> On 17/06/2013 06:55, Mike Frysinger wrote: > tar -xJf "./$i" >>> >>> why doesn't the bzip2 detect as bzip2 ? >> >> Capital J is XZ not bzip2.. still, it makes me think it needs a newer >> version of file to recognize it. > > the stupid default font doesn't clearly render that. guess that's the older > LZMA format rather than the newer XZ as the latter can be detected by file. I make all my files with "tar cJf" zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data worksforme - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRvz9dAAoJEKXdFCfdEflKLIsQAJ+AeXP5CIrlZSefzJCFgP4G 6Fd3XJPsTKr58KBl5KLmAVPOtRwac0vXty4F9lHMHECvnfNOh0UiajvNV/Jyz1yz zPZ/91Vv0vXc5ZlNNLqmq+rtIt3wuEXCg0TNwxTMbKX0MWW8S7ssOzibiYcLLoqT IHFKLXhtU3zIxQ4kLiMZ7e1QRBnrVvA4/VlcOKAs8R6cdsp/1e3fzhgZgMx9ft03 hmHLW9kMMC06/Bz8ZKsvnfuyWhvQrlvsOUH8JWC9pbyZO58fiCgwSFWRyma04d8k ulJ2y8K4B/WkIwRZzL47ROZQ91FcEnv9Ei9GzXLK6u4gIIrepX0NPcea441F1uVa 4i/9sjyk/zm6M3dAZyGlsCxZX96pAuFuE/H2OFcsaj9PRcdD2nR0Q4uvKwUqn+BM Mhcr2wQlBsLDHiQr/3g/WepZ7VGcKrfmWymjxcCZoj9VGMhMR6O/h3uGEAdLm3YK 1gLdvyQz+koUFdkmQIQHXFjd8q+165Lbky5CYqs6xekM1aSeLpskdZpVSI7GRp+j NvbB7gtEw2iz2pS8OSQ834K7KNnWI7OydVsv4cYnCySg3md+BAL1S5LLsc7FdmHz cRLjH8Yw5mH4EfeGFnIebWYsVMeRn8M0KJxVuz7GH1gjtIvOjfIOcjdWMBwOhryP LgmjPDvPM7NGJ3mneTLM =UOVj -END PGP SIGNATURE-
Re: [gentoo-dev] evar_push/pop helpers
On Mon, Jun 17, 2013 at 01:46:02AM -0400, Mike Frysinger wrote: > here's v2 These changes look good to me, and quite useful, thanks for doing this work. greg k-h
Re: [gentoo-dev] How to spread intltool fixes to all packages
El lun, 17-06-2013 a las 01:05 -0400, Mike Frysinger escribió: [...] > ELT-PATCHES is only used by elibtoolize which means it requires an explicit > call to patch things > > you're basically talking about the same type of problem that > https://bugs.gentoo.org/220040 tried to address. maybe we should update > autotools.eclass to have a general patching mechanism since any EAPI based > one > is doomed to failure. and then we rebase elibtoolize to that. > -mike It looks a bit ambitious to me, but, if you think it is not so hard to do, would be interesting :O
Re: [gentoo-dev] Calling die in a subshell
On 06/15/13 19:02, Mike Gilbert wrote: > On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh > wrote: >> On Sat, 15 Jun 2013 12:56:00 -0400 >> Mike Gilbert wrote: >>> If we find that all known implementations of PMS/EAPI 4 have >>> implemented a certain behavior, making a change to that version of PMS >>> to properly document the behavior seems reasonable. >> Part of the point of EAPI stability is that it doesn't just apply to >> current versions of package manglers. >> > So look back at the first versions which implemented EAPI 4 support, > and see what the behavior was implemented at the point in time. > it make sense but it stretch things a lot. Is it possible to: - keep an open bug (tracker) on named eclasses/ebuilds, so we (users and devs) know that there is a (teoric) fallacy - approve it for EAPI 6 - move all the eapi/ebuilds to EAPI 6 - close the bugs as WONT-FIX In any case it should be easy to port an ebuild from EAPI4 to 6, if gentoers want to keep things simple it could be more a version 5a than 6 regards
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On 17/06/2013 17:54, Rick "Zero_Chaos" Farina wrote: > I make all my files with "tar cJf" > > zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz > /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data cJ with _current_ tar will generate XZ cJ with _past_ tar could generate lzma xJ with _current_ tar will extract both XZ and lzma zJ with _past_ tar will only extract lzma -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2013 04:19 PM, Diego Elio Pettenò wrote: > On 17/06/2013 17:54, Rick "Zero_Chaos" Farina wrote: >> I make all my files with "tar cJf" >> >> zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz >> /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data > > cJ with _current_ tar will generate XZ > cJ with _past_ tar could generate lzma > xJ with _current_ tar will extract both XZ and lzma > zJ with _past_ tar will only extract lzma > > tar for the last several years properly and automatically detects the format of the input using just 'x'. This is true for gnu and bsd tar which should cover all of gentoo. We should be passing "tar xf" to extract things unless we want to hijack the decompression command like is possible in portage with BZIP2_COMMAND=lbzip2 in which case we want to pass "tar -I $BZIP2_COMMAND -xf" or (not yet in portage) "tar -I pixz - -xf". Some good examples of how this are handled are in catalyst but I'll let dolson talk about his own work as he is much more qualified than I am. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRv3NyAAoJEKXdFCfdEflKTYIP/ifbrOuhtEW2W3NRnUNImOmn YfRuRt+50OpEeHbniAp32zOhg0l6nYCgZ4CqzoUDTUm106EyAbyQSNheBC1d6DL6 eRFbuV41+B1cPDFB5FJMHrhapvKQmciGxyfgpPLrVnIHXQhNUvM+3h7qPq2SOnog tF8gQ3J3umfcJa3NMEqRRrWNkiytTniKZ537fLT0vxVvtOXSXswe3o3TJPNLpNVO BAyHNvZz3TKPy3gsHtvedo1iz37yUxUxAPnI0R0ccLRnPEGlnnNcseaQvCLGBvZP a7xqPMnM1gRv4xH9deWvh//mCSvIBjGoaeQLEP5ztjinrWalkFDikUk8xx8YZRev YYlQbj1n3NgKk7Io/fyXjaNmZGXHkdT0kYosT2w+uzwHMQVSbwIsdR24dUIxXrcp SG37KNB/wtPzOWpUYkV13wJgkLc1mVmEj92F47dSgGt4EKtSUng3sudDs2bPz4ds 7Z0lV4xLiG36ITZidBIIpjIWAKIQbQWIW+mIC25g40WGJ+qJtSz5bivwJa2a9PAx Zqhja3pQFbYz+YhIUidM/rkcy1XINicaL1lUbpaHZqzy8z/ivWAh6iXMLmulqdfa BjfPHVj0JcJs+ySbHMP/W3DN823BCzxOdc8cvHhLOG/Vhdysr+t5ga0yAQOawJsz fWqUGz1tNiKLU3uBs+20 =2YDM -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs
On 06/16/13 11:49, Pacho Ramos wrote: > Due ferringb retirement the following packages are up for grabs: > app-arch/tarsync * app-arch/tarsync Available versions: (~)0.2.1 (~)0.2.1-r1 Homepage:http://gentooexperimental.org/~ferringb/tarsync/ Description: Delta compression suite for using/generating binary patches ^^^ also this may need a new maintainer, it already need a new homepage (404) > dev-python/snakeoil > dev-util/bsdiff > dev-util/diffball > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained > and neither has eapi5 support) > > >
Re: [gentoo-dev] Calling die in a subshell
On 6/17/2013 4:10 PM, viv...@gmail.com wrote: > On 06/15/13 19:02, Mike Gilbert wrote: >> On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh >> wrote: >>> On Sat, 15 Jun 2013 12:56:00 -0400 >>> Mike Gilbert wrote: If we find that all known implementations of PMS/EAPI 4 have implemented a certain behavior, making a change to that version of PMS to properly document the behavior seems reasonable. >>> Part of the point of EAPI stability is that it doesn't just apply to >>> current versions of package manglers. >>> >> So look back at the first versions which implemented EAPI 4 support, >> and see what the behavior was implemented at the point in time. >> > it make sense but it stretch things a lot. > > Is it possible to: > - keep an open bug (tracker) on named eclasses/ebuilds, so we (users and > devs) know that there is a (teoric) fallacy > - approve it for EAPI 6 > - move all the eapi/ebuilds to EAPI 6 > - close the bugs as WONT-FIX > > In any case it should be easy to port an ebuild from EAPI4 to 6, if > gentoers want to keep things simple it could be more a version 5a than 6 > > regards What on earth is a "teoric fallacy"? I'm fine with waiting for EAPI 6 if necessary. I would not find a tracker bug very useful, and have no intention of starting one.
Re: [gentoo-dev] [RFC] unpacker.eclass extensions
On Mon, 2013-06-17 at 16:37 -0400, Rick "Zero_Chaos" Farina wrote:
> On 06/17/2013 04:19 PM, Diego Elio Pettenò wrote:
> > On 17/06/2013 17:54, Rick "Zero_Chaos" Farina wrote:
> >> I make all my files with "tar cJf"
> >>
> >> zero@ozzie ~ % file /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz
> >> /usr/portage/distfiles/gr-osmosdr-0.0.2.tar.xz: XZ compressed data
> >
> > cJ with _current_ tar will generate XZ
> > cJ with _past_ tar could generate lzma
> > xJ with _current_ tar will extract both XZ and lzma
> > zJ with _past_ tar will only extract lzma
> >
> >
> tar for the last several years properly and automatically detects the
> format of the input using just 'x'. This is true for gnu and bsd tar
> which should cover all of gentoo. We should be passing "tar xf" to
> extract things unless we want to hijack the decompression command like
> is possible in portage with BZIP2_COMMAND=lbzip2 in which case we want
> to pass "tar -I $BZIP2_COMMAND -xf" or (not yet in portage) "tar -I pixz
> -xf". Some good examples of how this are handled are in catalyst but
> I'll let dolson talk about his own work as he is much more qualified
> than I am.
>
> -Zero
Well, I don't code bash, but...
In catalyst, I had a request to add more types of
compression/decompression capabilities. Plus I am also trying to clean
up the messy, poorly structured code. What I have come up with is a
separate class that can be loaded with either compression or
decompression commands that can be configured, overridden, added to,...
It will provide a python interface to perform the actions requested,
keeping the detailed coding central and internal. It will provide
automatic detection of the command to use via it's extension as a
combination of a pre-determined configured preference (if it is
compatible) or a suitable command determined by that extension. There
can also be several predefined ways to do the same action, in which case
the pre-configured preference will take priority.
I hadn't gotten into reading this thread much, but did note the
similarity of what I was currently doing and what it was discussing.
What is directly relevant to the tar commands is listed in the
compression_definitions and decompression_definitions at the top of the
file attached.
This python lib can easily be made into a standalone pkg with a cli
interface to perform many common actions without the need of additional
coding in eclasses, package managers, etc.. It could provide gentoo
with a common, central, easily extended and updated method of performing
normal compression/decompression.
It is a work in progress, with only preliminary testing done inside my
catalyst rewrite. I have not yet added configuration options and
override preferences.
It is available in my catalyst git repo in my dev space. It is in the
compress branch. Note there is no master branch there, so a basic clone
will error when it tries to checkout a master working copy on completion
of the clone. Just "git checkout compress" after.
http://dev.gentoo.org/~dolsen/catalyst/
I've attached the current compress.py file so you can peruse and decide
if making this a standalone gentoo project is desired. If not, it will
get merged into catalyst code base.
--
Brian Dolbec
# Maintained in full by:
# Catalyst Team
# Release Engineering Team
'''
compress.py
Utility class to hold and handle all possible compression
and de-compression of files. Including rsync transfers.
'''
import os
from collections import namedtuple
from support import cmd
definition_fields = ["func", "cmd", "args", "id", "extension"]
defintition_types = [ str,str, list, str, str]
'''The definition entries are to follow the the definition_types
with the exception of the first entry "Type" which is a mode identifier
for use in the class as a type ID and printable string.'''
compress_definitions = {
"Type": ["Compression", "Compression definitions loaded"],
"rsync" :["rsync", "rsync", ["-a", "--delete", "%(source)s", "%(destination)s"], "RSYNC", None],
"lbzip2" :["_common", "tar", ["-I", "lbzip2", "-cf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "LBZIP2", "tbz2"],
"tbz2" :["_common", "tar", ["-I", "lbzip2", "-cf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "LBZIP2", "tbz2"],
"bz2" :["_common", "tar", ["-cpjf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "BZIP2", "tar.bz2"],
"tar" :["_common", "tar", ["-cpf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "TAR", "tar"],
"xz" :["_common", "tar", ["-cpJf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "XZ", "tar.xz"],
"pixz" :["_common", "tar", ["-I", "pixz", "-cpf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "PIXZ", "xz"],
"zip" :["_common", "tar", ["-cpzf", "%(filename)s", "-C", "%(basedir)s", "%(source)s"], "GZIP", "zip"],
}
decompress_definitions = {
"Type": ["Decompression", "Decompression definitions loaded"],
"rsync" :["rsync", "rsync", ["-a", "--delete", "%(source)s", "
