Hi! I have tried hard to make this message to the point. But that wasn't easy, as what I figured out about gzip --only after hours of work-- I still do need confirmation about, even though all appears correct.
gzip apparently inconsistent behavior occupies the most part of the report on inconsistencies here (esp. the script make_gzip_archives_consistent.sh). Another part is actually on Wireshark mailing list. Pls. see: Filtering on (negated) frame.time_relative filters out wrong frame.number https://www.wireshark.org/lists/wireshark-users/201704/msg00037.html as well as my study at: https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-4.php (and the previous ones there, but I gave the last as it is simplest/fastest to check) There is information that any advanced reader can easily provide by retracing some of my steps there, and which would clear some uncertainties here. The third part is about Bash apparent misbehavior. And the fourth part is about eix complaining it has a bug, it's near the bottom part of this email. That is my starting point, and at this stage, after having spent quite a few hours on this issue below (but I have other issues not-directly-related to my system that haven't allowed me to finish and send this yet)... This issue below I thought at first could be related to my Wireshark woes, and now I don't... and at this stage (the proofreading time) I'm actually asking for any confirmation/denial on my findings about it... miro@g0n ~ $ ls -lh wireshark-users_miroR_q_bug_q.txt -rw-r--r-- 1 miro miro 802 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt miro@g0n ~ $ ls -l --block-size=K wireshark-users_miroR_q_bug_q.txt -rw-r--r-- 1 miro miro 1K 2017-04-30 17:16 wireshark-users_miroR_q_bug_q.txt miro@g0n ~ $ mv -vi wireshark-users_miroR_q_bug_q.txt gzip_buggy.txt 'wireshark-users_miroR_q_bug_q.txt' -> 'gzip_buggy.txt' miro@g0n ~ $ tar czf gzip_buggy.txt.tar.gz gzip_buggy.txt miro@g0n ~ $ tar czf gzip_buggy.txt_1.tar.gz gzip_buggy.txt miro@g0n ~ $ tar czf gzip_buggy.txt_2.tar.gz gzip_buggy.txt miro@g0n ~ $ sha256sum gzip_buggy.txt*.tar.gz 26bcad15b4a81a3606859fdd4560af0e2c4cd875f1271808afb4569c50bfb5ec gzip_buggy.txt_1.tar.gz bd8f51bcd3274bbee4f73fa7ba9e1a2acd5db5d27f5643f72de10c52e224c22a gzip_buggy.txt_2.tar.gz 251a57e83ebaf4f07179f4a6500be80612a39ac6d2e97e482b30fb0a4de66f56 gzip_buggy.txt.tar.gz miro@g0n ~ $ You may check attachments: gzip_buggy.txt_1.tar.gz gzip_buggy.txt_2.tar.gz gzip_buggy.txt.tar.gz I think this is not like it should be. But the important question, really, is: is this the case in my machine only, or is it Gentoo-userdom wide? I fear it's the former, but like I asked in that Wireshark thread ( And it was amazing to see how little people care... there are always plenty of readers of Wireshark ML, and while not all can understand that thread --it took me years since I first used Wireshark to get to be able to minimally contribute there... lots of readers there such--, and of course those that can not really understand, need not reply... but lots of readers of Wireshark ML can easily repeat my steps that show in which exact fashion my Wireshark misbehaves... I'll be thankful is some Gentoo reader fills in this huge gap of carelessness.. ) [but like I asked in that Wireshark thread,] I ask here on Gentoo users ML (or readers from elsewhere). Pls. somebody confirm if this is, or is not, the case in their Gentoo machines. By simply decompressing the tar-gzip'd archive are do the tar-gzip compression as I did, and checking the sums of them. If you don't like my text file, you can use any file (like the ASCII file below, which I hope should be simple and fine enough), and reproduce what I tried with it. So let's try /usr/bin/eix-installed-after It's ASCII, it's Gentoo, everybody has it on this ML, but for visitors, it's in You may check attachments: eix-installed-after_1.tar.gz eix-installed-after_2.tar.gz eix-installed-after.tar.gz In my Gentoo, I copied it in my homedir and... miro@g0n ~ $ tar czf eix-installed-after.tar.gz eix-installed-after miro@g0n ~ $ tar czf eix-installed-after_1.tar.gz eix-installed-after miro@g0n ~ $ tar czf eix-installed-after_2.tar.gz eix-installed-after miro@g0n ~ $ sha256sum eix-installed-after*.tar.gz 80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz miro@g0n ~ $ And let me go further. Inspecting those...: miro@g0n ~ $ ls -l eix-installed-after*.tar.gz -rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_1.tar.gz -rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after_2.tar.gz -rw-r--r-- 1 miro miro 3771 2017-04-30 17:39 eix-installed-after.tar.gz miro@g0n ~ $ ls -l --block-size=K eix-installed-after*.tar.gz -rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_1.tar.gz -rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after_2.tar.gz -rw-r--r-- 1 miro miro 4K 2017-04-30 17:39 eix-installed-after.tar.gz miro@g0n ~ $ ...those tiny files, I find that...: miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c38 00000000 1f 8b 08 00 25 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c38 00000000 1f 8b 08 00 27 05 06 59 00 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c38 00000000 1f 8b 08 00 29 05 06 59 00 miro@g0n ~ $ miro@g0n ~ $ ...it's always the... ah well, for clarity, let's head just the first 25 bytes of the hex representation, whihc will later be 5 bytes for dd commands...: miro@g0n ~ $ hexdump -C eix-installed-after.tar.gz | head -c25 00000000 1f 8b 08 00 25 miro@g0n ~ $ hexdump -C eix-installed-after_1.tar.gz | head -c25 00000000 1f 8b 08 00 27 miro@g0n ~ $ hexdump -C eix-installed-after_2.tar.gz | head -c25 00000000 1f 8b 08 00 29 miro@g0n ~ $ ...that it's always (or almost always, see below about PART3 sometimes being different) just the 5th byte that is different, in the way that doing the procedure below will get those files which differed at creation time...: 80d004b1ecc6e6c2aec7cd453d05c7b4e4cc4092b9cef6b7c3fb31d148eb2310 eix-installed-after_1.tar.gz f4c30c6d4ccc90d1ec2cc6df2ac10cae2545d04a85c7ff39207d93129cd0ec78 eix-installed-after_2.tar.gz a8161c5771b661476966250af31d2b8bd80581a3e0c52d535b401524ee541ae7 eix-installed-after.tar.gz ( Notice: the hash is always new. You won't get any of those hashes above if you tar-gzip it. This is about the non-identical results. ) ...to become identical. This procedure, that I'll put in the script: Pls see attachment: make_gzip_archives_consistent.sh The fact is, I have, hours ago (this is slow work for me...) made a backup (and spent all this time, and more to write that script), and noticed how my gzip behaves, or should I say the gzip program *in my machine*... And... And I can tell that I get different instances of archives consistently fixed with that script. I only can't get identical archives when PART3 is different in some (usually only one of the three) of the archives. NOTE (at proofreading time): But I'm not investigating that anymore, find how I confirmed that the archives upon decompression are all of verifiably same content, and that suffices. I really have tried only on my backup, on multiple series of three different tar-gzip'ed instances each of which in the series was done on the same directory with the script above. The script is just a proof of concept, and a demonstration of the apparent issue. Because this previously does not seem to me to have been the case, but maybe I misremember? I checked a few of the tar-gzip'd archives of my backup, and so far they have always, upon decompression, shown identical in all the different instances. The finding =========== I've typically compared series of three instances of same directories that I backed up, such as /home/miro, /root and /var/log, and they always were identical upon decompression. ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | That means *probably* all is fine with gzip, and there is no issue. (But this result was not trivial to get by... and since I'm unsure in my conclusion, I'm still posting this, asking for confirmation or denial.) So maybe I've been chasing shadows here... And for long hours... And I'm sorry if that is so, but look at that issue that I have with Wireshark! Look at that! That's not a shadow. That's a serious bug or a serious malfunction in my Gentoo, the latter being most likely... And if it is the latter, it can only be one or the other way. One: the cause is in some Gentoo packge. Two: it is an attack by some unknown means. ( If Air-Gapped is some info, I did try and editcap (and the whole Wireshark) behave in the same wrong way in my Air-Gapped too. Same holds for the gzip inconsistency --or "inconsistency". ) And looking for solution to that Wireshark issue, I found the above issue which appeared to me to be some kind of inconsistency... And I have other inconsistencies, bogus or true that they might be, such as with bash. One is very quick to report. Here it goes... Thanks for any report on how this issue, and the one with Wireshark, shows, completely in order or just like in my machine, in any other Gentoo users' systems. This is one of a series of commands that I used to check one of the backups, in three different instances of tar-gzip'd archive I checked (such as the /root directory tar-gzip'd today), and which showed faultless upon decompression in all the three instances, despite the three instances of tar-gzip'd archives not being identical (as their SHA256 sums show): # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done ; Now if I just place the cursor, by moving with Alt-F (skipping "words") and Ctrl-F (skipping 1 char) to just after: "for i in $(ls -1d root_170430_g0n*.d/" in that command, and if I then hit Tab for completion on the experssion there, I get (and I'm sorry for the mess, but that's what I get): g0n ~ # for i in $(ls -1d root_170430_g0n*.dbash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done ; NOTE (at proofreading time): rechecked, I do get that same behavior the day after (wrote most of this yesterday, still to send this morning). [[ NOTE (before delayed sending): In fact, it is only this clone that exibits the above Bash malfunctioning. I just checked the same for loop command (some six paragraphs above) in my Air-Gapped master [1] (never any internet it sees, longer workaround/detailed checking before updating it with stuff from internet, sneakernet or optical media), and it is just fine. That line, simply gave what it should: # for i in $(ls -1d root_170430_g0n*.d/); do sum=$(echo $i|sed 's/\.d\//\.sum/'); echo $sum ; read FAKE ; j=$(echo $i | sed 's/\.d\//\.tar.gz/'); ls -l $j $i ; cd $i; pwd ; read FAKE ; for file in $(find ./ -name '*'); do if [ -f "$file" ]; then sha256sum $file >> ../$sum ; fi; done ; cd - ; done root_170430_g0n_1.d// root_170430_g0n_2.d// root_170430_g0n.d// # [[and the same command line was back here]] under exact same conditions/circumstances as the clone of my Air-Gapped. And it's similar with some other completion issues: they seem non-existent in my Air-Gapped. ]] IOW, first, Bash sullied the entire line, which is not very considerate of Her, and second that's not some usual error. Just for clarity, it wrote this: bash: unexpected EOF while looking for matching `)'bash: syntax error: unexpected end of file (and it wrote it by overwriting, which I never used to see in Bash) What's going on there?... Ah... Importantly: do any of you other users get some erratic unusual behavior like this with Bash? Of course, I can move to the start of the line with Ctrl-A and then issue Ctrl-K to clear and capture to the entire line and then issue Ctrl-Y to paste it back, and no disorderly message remains, but Bash isn't behaving... I'll try and send this soon, but I first need to finish my backup... Backup is done. Just, I guess if the reader has this bash version installed: $ bash --version GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. $ they might be able to reproduce such kind of misbehavior. And finally, and this is what eix throws on any package that I would check: g0n ~ # eix memtest86+ * sys-apps/memtest86 Available versions: 4.3.7 (~)4.3.7-r1 {serial} Homepage: http://www.memtest86.com/ Description: A stand alone memory test for x86 computers * sys-apps/memtest86+ Available versions: 2.01^t 4.00^t 4.20-r1 (~)4.20-r3 5.01-r2 (~)5.01-r3 {floppy iso serial} Homepage: http://www.memtest.org/ Description: Memory tester based on memtest86 Found 2 matches Received SIGSEGV - you probably found a bug in eix. Please proceed with the following few instructions and help us find the bug: * install gdb (sys-devel/gdb) * reemerge eix with FEATURES="nostrip" CXXFLAGS="-g -ggdb3" LDFLAGS="" * enter gdb with "gdb --args eix your_arguments_for_eix" * type "run" and wait for the segfault to happen * type "bt" to get a backtrace (this helps us a lot) * post a bugreport and be sure to include the output from gdb. Sorry for the inconvenience and thanks in advance! g0n ~ # Too many inconsistencies. Where do I start searching for the causes? (As far as the fourth "inconsistency", I was thinking about trying memtest as per: Message-ID: <lo1p123mb067395fd4e9010b549743c9280...@lo1p123mb0673.gbrp123.prod.outlook.com> How to get memtest onto a USB drive https://lists.gt.net/gentoo/user/325837#325837 , but that's just for lack of other ideas, these issues don't look like bad memory. I might still try it, but when I go to sleep, not sooner. ) Regards! --- [1] My methods are still these: Air-Gapped Gentoo Install, Tentative https://forums.gentoo.org/viewtopic-t-987268.html and Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion https://forums.gentoo.org/viewtopic-t-999436.html#7613044 -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
gzip_buggy.txt.tar.gz
Description: Binary data
gzip_buggy.txt_1.tar.gz
Description: Binary data
gzip_buggy.txt_2.tar.gz
Description: Binary data
make_gzip_archives_consistent.sh
Description: Bourne shell script
On 170317-11:29+0000, Graham Bloice wrote:
> On 17 March 2017 at 11:23, Peter Wu <pe...@lekensteyn.nl> wrote:
...
> Or use editcap to drop the packets;
>
> editcap infile outfile packet#1 packet#2
>
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | | | | | |
I have tried just that above, and have the same issue.
While my message is awaiting moderation for over two hours (and I'm
*not* saying that anything is wrong, but want to let know of this issue
with a short notice, and move on, while I wait),
I posted about it on:
Same Issue with Editcap
https://www.croatiafidelis.hr/foss/cap/cap-170313-git-devuan-mail/git-devuan-mail-4.php
Not re-sending the much longer message, as I'm advised in the notice.
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
#!/bin/sh
# This script is part of the eix project and distributed under the
# terms of the GNU General Public License v2.
#
# Authors and Copyright (c):
# Martin V\"ath <mar...@mvath.de>
#
# This script lists all packages installed after/before a certain package
# See the eix manpage for details. (eix 0.32.7).
set -u
# We make use of the functions provided by eix-functions.sh:
if eix_funcs=`'/usr/bin/eix-functions.sh' 2>/dev/null`
then eval "$eix_funcs"
else echo "${0##*/}: cannot find eix-functions.sh" >&2
exit 1
fi
ReadFunctions
# Prepend content of eix variable EIX_INSTALLED_AFTER to the arguments
ReadVar EIX_INSTALLED_AFTER
eval "set -- a $EIX_INSTALLED_AFTER \${1+\"\$@\"}"
shift
# The following function outputs the usage of the script and then dies.
Usage() {
n=${0##*/}
p='eix 0.32.7'
eval_gettext 'Usage: ${n} [options] category/package[:slot]
This is a well-commented demo script for eix (${p}).
It lists packages installed after (or before) the last (or first) install
of the given package/version in an output format which is convenient
as an argument for "emerge -1".
Be aware that only packages in the eix database are considered.
The argument can use shell pattern matching (* and ?; do not forget to quote
them if you call this script from a shell); the first match is chosen.
The :slot part can be omitted if the corresponding package has only one slot.
(Options -l and -L have different rules.)
The argument is not needed if option -f, -e or -F is used.
The eix (or environment) variable EIX_INSTALLED_AFTER is prepended to the
arguments; note that this variable is evaluated, so quote properly and be
aware about security risks!
The following options are available:
-i Ignore all previous options (useful if EIX_INSTALLED_AFTER is set.)
-f Output full list of all packages.
-e TIME Use TIME as "install" date.
TIME is in seconds since epoch (see e.g. "date +%s")
-F FILE Use the mtime of FILE as the "install" date.
-l Use /var/log/emerge.log to use the _first_ (instead of the last) install
time of the given package. In this case, the argument must be a
regular expression matching category/package-version.
Note that the time in the log file and the time recorded in the database
usually differ slightly so that usage/non-usage of option -I need not
have the expected effect: The package may or may not be included.
You can use -a/-A to fix the time. Note also that -t or -T have no
effect on the data in the log file.
-L LOG As -l but use LOG instead of /var/log/emerge.log
-a SEC With -F, -l -L, or -e, increase the actual match time by SEC seconds.
-A SEC With -F, -l -L, or -e, decrease the actual match time by SEC seconds.
-b Output packages installed before (instead of after) the given package
-I Include the given package (on the command line) in the output
-S When finding the starting package, choose the first matching slot
-V When finding the starting package, look for category/package-version
instead of category/package:slot
-d Output the installation date after the package
-s Output slot of the package, even if there appears no ambiguity
-v Output category/package-version instead of category/package[:slot]
-= Output =category/package-version instead of category/package[:slot]
-t Use build time (if available) instead of installation time,
independent of the value of USE_BUILD_TIME
-T Never use build time'
echo
exitcode=${1:-1}
Exit $exitcode
}
# Parse the command line options:
DefaultOpts() {
full=false
timefile=
epoch=
logfile=
before=false
date_output=
output='NAMESLOT'
input='NAMESLOT'
including=false
addtime=
subtime=
}
DefaultOpts
OPTIND=1
while getopts 'fF:lL:e:a:A:bdsv=SViItTh' opt
do case $opt in
f) full=:;;
F) timefile=$OPTARG;;
l) logfile='/var/log/emerge.log';;
L) logfile=$OPTARG;;
e) epoch=$OPTARG;;
a) addtime=$OPTARG;;
A) subtime=$OPTARG;;
b) before=:;;
d) date_output='\t<date:DATE_OUTPUT>';;
s) output='NAMEASLOT';;
v) output='NAMEVERSION';;
'=') output='EQNAMEVERSION';;
S) input='NAME';;
V) input='NAMEVERSION';;
i) DefaultOpts;;
I) including=:;;
t) USE_BUILD_TIME=true; export USE_BUILD_TIME;;
T) USE_BUILD_TIME=false; export USE_BUILD_TIME;;
'?') exitcode=1; Exit 1;;
*) Usage 0;;
esac
done
[ $OPTIND -le 1 ] || shift `Expr $OPTIND - 1`
# After the options there should be exactly one argument: $match
if [ -n "${timefile:++}" ]
then epoch=`stat -c '%Y' -- "$timefile" 2>/dev/null` || epoch=
fi
# "found" is our flag in the loop whether we already found our package.
found=false
if $full
then logfile=
before=false
epoch=
found=:
elif [ -z "${epoch:++}" ]
then [ $# -eq 1 ] || Usage
match=$1
fi
# With options -l or -L, we also have to parse the logfile:
if [ -n "${logfile:++}" ]
then test -r "$logfile" || die "`eval_gettext 'cannot read ${logfile}'`"
epoch=`unset LC_ALL
LC_COLLATE=C
sed -ne "\\: Merging ($match\\:\\:.*):{s/^\([0-9]*\).*/\\1/p
q}" "$logfile"` && [ -n "${epoch:++}" ] || die "`eval_gettext \
'cannot find merge of ${match} in ${logfile}'`"
fi
# We will let eix output for each installed package (and then sort by time):
# date (in the format %s) TAB
# package (in the input format) TAB
# package (in the output format) [TAB date (in the format "%x %X")]
# newline
# (the [...] part occurs only with option -d).
# The functions Check resp. Output are called with each $line as argument
# (which thus undergoes the usual splitting at spaces or tabs).
# Check returns 0 if the package matches $match (or is known to be younger).
# Output outputs the package (and date).
# Both functions ignore empty lines.
if [ -z "${epoch:++}" ]
then
Check() {
[ $# -ge 2 ] && case "$2:" in
$match:*)
return 0;;
esac
return 1
}
else [ -z "${addtime:++}" ] || epoch=`Expr "$epoch" + "$addtime"`
[ -z "${subtime:++}" ] || epoch=`Expr "$epoch" - "$subtime"`
# With options -f, -e, -l, -L, we need a different Check function:
Check() {
[ $# -ne 0 ] && [ "$1" -ge "$epoch" ]
}
fi
Output() {
if [ $# -eq 3 ]
then Echo "$3"
elif [ $# -gt 3 ]
then printf '%-43s %-11s %s\n' "$3" "$4" "$5"
fi
}
# Now the main loop. The interesting point is of course the call to eix.
#
# We could define NAMESLOT, NAMEASLOT, NAMEVERSION, and EQNAMEVERSION
# instead of using their default definitions (which are built into eix).
# However, we want to allow that the user overrides these definitions if he
# wants to and thus is able to change the input/output format of this script
# implicitly.
#
# Since there is no corresponding default variable which outputs _only_
# the package category/name (and never the slot), we define such a variable
# for option -S (we have chosen the name NAME for that).
#
# As you can see with "eix --dump", the default definitions of
# NAMESLOT, NAMEASLOT, NAMEVERSION, and EQNAMEVERSION make use of the variable
# VERSION_NEWLINE to output an optional newline.
# We do not want such a newline: In fact, the only newline we want is the one
# which should be output at the end of the LINE variable.
# So we set VERSION_NEWLINE=
#
# We set NOCOLORS to avoid the "reset color string" at the very end.
#
# We set EIX_LIMIT to 0 to force output of really all packages.
#
# To define the output format, we use the --format argument.
# If we would have used the FORMAT variable instead (or in <eix-0.29.6)
# we would have to set additionally DEFAULT_FORMAT=normal to make sure
# the a user's setting of DEFAULT_FORMAT is overridden.
#
# The --format refers implicitly to the LINE variable which in turn refers
# implicitly to DATE_FORMAT, DATE_OUTPUT, and NAME:
#
# The name of the variables DATE_FORMAT, DATE_OUTPUT, NAME, and LINE
# could also be any other unused names; it is only important that in LINE
# resp. in the --FORMAT argument we use the corresponding variable names.
#
# We have to quote \ for the shell when we use "..." to set variables.
#
# Note that all the following variables are automatically exported, since
# they immediately preceed the command (the \ at the line-ends is crucial):
NOCOLORS=: \
EIX_LIMIT=0 \
VERSION_NEWLINE= \
DATE_FORMAT='%s' \
DATE_OUTPUT='%x %X' \
NAME='<category>/<package>' \
LINE='<date:DATE_FORMAT>\t%{'$input'}\t%{'$output'}'$date_output'\n' \
eix --format '<installedversions:LINE>' '-I*' \
| sort -n \
| {
while read -r line
do if $found
then $before || Output $line
elif Check $line
then found=:
$including && Output $line
else $before && Output $line
fi
done
$found
}
Exit
eix-installed-after.tar.gz
Description: Binary data
eix-installed-after_1.tar.gz
Description: Binary data
eix-installed-after_2.tar.gz
Description: Binary data
signature.asc
Description: Digital signature
