Bug#834402: aptitude: search loses column format when redirected or piped
Package: aptitude Version: 0.8.3-1+b2 Followup-For: Bug #834402 I also consider this a regression. For instance, see this example: aptitude -s search -F '%c%M %p' '~i' > status.txt The width doesn't matter, I'm logging the output for archival. I actually *want* infinite width. But %M is now expanded to the empty string when missing, causing the output to be mis-aligned. Fine, but consider the following tweak: aptitude -s search -F '%c%1M %p' '~i' > status.txt it *still* expands to empty, even though I'm requesting 1 column of output with %1M in any condition. This is broken. -- Package-specific info: Terminal: rxvt-unicode-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.3 Compiler: g++ 6.2.0 20161103 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160917 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7ffcd5b67000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fb2ddf5f000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fb2ddd2f000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fb2ddb05000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fb2dd8fe000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fb2dd601000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fb2dd2f7000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fb2dd0df000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fb2dcec6000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fb2dccc2000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fb2dc8b4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb2dc697000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fb2dc314000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb2dc01) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fb2dbdf9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb2dba5b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb2db857000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fb2db64) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb2db424000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fb2db214000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb2dafee000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb2daddc000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb2dabd4000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb2da9cd000) /lib64/ld-linux-x86-64.so.2 (0x55d973091000) -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.3-1 ii libapt-pkg5.0 1.3.1 ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-iostreams1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-5 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.2.0-13 ii libncursesw5 6.0+20160917-1 ii libsigc++-2.0-0v5 2.10.0-1 ii libsqlite3-0 3.15.1-1 ii libstdc++6 6.2.0-13 ii libtinfo5 6.0+20160917-1 ii libxapian301.4.1-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-11 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index0.49 pn aptitude-doc-en | aptitude-doc ii debtags 2.1.2 pn tasksel
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
On Wed, Aug 17, 2016 at 10:46:59PM +0100, Manuel A. Fernandez Montecelo wrote: > - somehow try to use the same width of the current terminal, with > possible truncation (would work fine in pipes for which the ultimate > output is the same terminal, but not if redirected and processed/seen > from another terminal/computer, unless the width is the same) A way to get the width of the current terminal even when stdout was redirected/piped is read it from stdin (fd 0) instead. With the advantage that, unlike stdout, most of the times the standard input is going to be connected directly to the terminal (I don't see actual cases where somebody would want to redirect the standard input of aptitude to a file/pipe, but maybe I'm wrong). A simple proof of concept: #include #include #include void check_term_size( int fd ) { struct winsize ws; if ( isatty(fd) ) { printf( "tty at FD %d\n", fd ); if ( ioctl(fd, TIOCGWINSZ, &ws) != -1 ) { printf( "ROWS=%d\n", ws.ws_row ); printf( "COLUMNS=%d\n", ws.ws_col ); } } } int main( int argc, char* argv[] ) { check_term_size( 1 ); /* stdout */ check_term_size( 0 ); /* stdin */ return 0; } The downside is that the problem persists with redirections: they are again dependent on the size of the terminal --meaning "aptitude search > kk" would be different depending on the current width of the terminal where the command is executed. But that is the case the -w option was created for, right? -- Saludos de Javier signature.asc Description: PGP signature
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
Hi, 2016-08-16 19:18 Javier Cantero: On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote: The reasoning for the change was that with pipes/redirections the concept of "terminal" and consequently "width" is lost. If it's redirected it's possibly/likely that it's because it's moved and processed elsewhere (where the new terminal size will likely be different), or that the further processing doesn't bother with terminal columns or uses smarter methods like using '|' as field separators. Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any filter can interact with the terminal in a later stage of the pipeline. In some cases like pagers there is *always* a terminal at the end. That is the fundamental difference: the tool interacting with the terminal is at the end, so the output is the terminal, so it can know its dimensions. If the tool is at the beginning, or at any point in the middle, the output is a file or pipe (== a file for all purposes, from the tool's POV), so it cannot know the dimensions. For example, with a file with long lines such as apt's history.log: # less /var/log/apt/history.log > /tmp/test # md5sum /var/log/apt/history.log /tmp/test 420a7acb08a4e58c9c6b97654aa1bb6a /var/log/apt/history.log 420a7acb08a4e58c9c6b97654aa1bb6a /tmp/test # less --chop-long-lines /var/log/apt/history.log > /tmp/test # md5sum /var/log/apt/history.log /tmp/test 420a7acb08a4e58c9c6b97654aa1bb6a /var/log/apt/history.log 420a7acb08a4e58c9c6b97654aa1bb6a /tmp/test # less --chop-long-lines /var/log/apt/history.log | cat | md5sum 420a7acb08a4e58c9c6b97654aa1bb6a - So they are exactly the same file. "less" (at the start of the command chain) doesn't insert newlines in the file or does any processing on the input file with the "--chop-long-lines" option. It treats the width of the terminal as infinite. This is what aptitude does now as well. (Disclaimer: the tools or other tools that you mention perhaps still do some trick to adapt to the terminal size even if the output is a file/pipe, but well, my point is that the position and access to the terminal is the fundamental difference between "cat | less" and "aptitude | less"; and that "less" when not the last in the chain behaves the same as the new behaviour of aptitude). In other words, trying to columnize the output when the width is unknown (pipes or redirections) is a bit hacky and doesn't make much sense to me, and forcing it to be 80 for a lack of better default is not always a good solution as it might have been back in ~2000 (I think). I agree that forcing to be 80 is hacky. But there is a better solution: if the output isn't to a terminal (and -w is not passed), write the entire output without truncating to any width size and let the next process in the pipeline deal with it. If it's the last process before going to terminal, I'm sure that program will have code to properly adapt its output to the actual terminal size. In one sentence: delegate the job to the process dealing with the terminal. Actually, aptitude /now/ works as you say and for the same reasons that you say, so we could be in violent agreement. Only that I suspect that we are not, because that's why you submitted the original bug report after all... :) So as you say, what aptitude does is that "if the output isn't to a terminal (and -w is not passed), write the entire output without truncating to any width size and let the next process in the pipeline deal with it". It does not truncate the output now when it's at the start of a chain of commands. Only that to columnize the output, it has to have some reference to the width that it's going to "render" the output to, because most fields can shrink and expand -- they are not of a fixed size. And knowing the width is exactly what it's lacking to columnize the output when piping/redirecting. If aptitude considers width as infinite, same as "less", all rows are of infinite width (infinite being 65536 in the implementation). So the new behaviour is that, instead of columnizing to 80 and truncating, it doesn't truncate (but doesn't columnize). If it doesn't truncate and also doesn't have a width and doesn't want to use the infinite, the only solution for columnizing would be to do two passes: one collecting the maximum size of the columns for all packages that match the search ("search" and other commands that use the same columnizer code), and another pass to actually write the text and fill with blanks until the max width of the column is filled in. In this case, if using "aptitude search ${pattern} | less", searches would have different widths -- the output would depend on the max length of the fields for the packages that match. Like this: |-| i A aptitude an awesome package manager that everyone loves |-| |--
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
On Mon, Aug 15, 2016 at 11:25:40PM +0100, Manuel A. Fernandez Montecelo wrote: > The reasoning for the change was that with pipes/redirections the > concept of "terminal" and consequently "width" is lost. If it's > redirected it's possibly/likely that it's because it's moved and > processed elsewhere (where the new terminal size will likely be > different), or that the further processing doesn't bother with terminal > columns or uses smarter methods like using '|' as field separators. Counterexamples: any PAGER (more, less, ...), grep, sed, and virtually any filter can interact with the terminal in a later stage of the pipeline. In some cases like pagers there is *always* a terminal at the end. > In other words, trying to columnize the output when the width is unknown > (pipes or redirections) is a bit hacky and doesn't make much sense to > me, and forcing it to be 80 for a lack of better default is not always a > good solution as it might have been back in ~2000 (I think). I agree that forcing to be 80 is hacky. But there is a better solution: if the output isn't to a terminal (and -w is not passed), write the entire output without truncating to any width size and let the next process in the pipeline deal with it. If it's the last process before going to terminal, I'm sure that program will have code to properly adapt its output to the actual terminal size. In one sentence: delegate the job to the process dealing with the terminal. -- Saludos de Javier signature.asc Description: PGP signature
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
Hi, 2016-08-15 20:54 Axel Beckert: Hi Manuel, Manuel A. Fernandez Montecelo wrote: In the past it was just hardcoded to "80 columns", so your example when doing it with and without pipe/redirection will have looked different as well -- unless the terminal that you are using is 80-column wide, of course. (See attachment, the description is truncated). Either your examples show something different or not the problem: $ aptitude search '~i~n^aptitude' i aptitude - terminal-based package manager i aptitude-common - architecture independent files for the aptitude package manager $ aptitude search '~i~n^aptitude' | cat i aptitude- terminal-based package manager i aptitude-common - architecture independent files for the apt This definitely looks different here and IIRC also for the original submitter: [...] Manuel: I really wonder why your examples looked different than mine wrt. to aligned columns. Maybe some different options being set via configuration files? Sorry that I was not very explicit... with "In the past" I meant the version in stable/Jessie (or for that matter, any older than that), and I was only saying that the output would have looked different in one way or another. (There were complaints in previous bug reports about different aspects of this issue). For example, if the default fields are used, the description will almost always be truncated, sometimes in a slightly confusing ways as for example in the case of aptitude-common above -- where it's not visually obvious by the context that it was truncated, and one might thing that aptitude just fails to process the short description incorrectly. That is, the output when piping and redirecting was always different to the "direct-to-terminal" one unless the terminal width happened to be 80. To get always columns with these commands, no matter what, one can define it explicitly, either with "-w" or with Aptitude::CmdLine::Package-Display-Width (in the latter case, -w overrides the config variable). Of course, if one hardcodes Aptitude::CmdLine::Package-Display-Width to e.g. 80 to have the same behaviour as before, then it'll will always use 80 when outputting directly to the terminal, unless overridden. Aptitude::CmdLine::Package-Display-Format can also be used to define another format, perhaps removing uninteresting fields (description?) and setting explicit widths for the fields. Another work around for the new behaviour is e.g.: $ alias aptitude-search="aptitude -w $COLUMNS search" The reasoning for the change was that with pipes/redirections the concept of "terminal" and consequently "width" is lost. If it's redirected it's possibly/likely that it's because it's moved and processed elsewhere (where the new terminal size will likely be different), or that the further processing doesn't bother with terminal columns or uses smarter methods like using '|' as field separators. In other words, trying to columnize the output when the width is unknown (pipes or redirections) is a bit hacky and doesn't make much sense to me, and forcing it to be 80 for a lack of better default is not always a good solution as it might have been back in ~2000 (I think). Cheers. -- Manuel A. Fernandez Montecelo
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
Hi Manuel, Manuel A. Fernandez Montecelo wrote: > In the past it was just hardcoded to "80 columns", so your example when > doing it with and without pipe/redirection will have looked different as > well -- unless the terminal that you are using is 80-column wide, of > course. (See attachment, the description is truncated). Either your examples show something different or not the problem: > $ aptitude search '~i~n^aptitude' > i aptitude > - terminal-based package manager > i aptitude-common > - architecture independent files for the aptitude package manager > > $ aptitude search '~i~n^aptitude' | cat > i aptitude- terminal-based package manager > i aptitude-common - architecture independent files for the > apt This definitely looks different here and IIRC also for the original submitter: ~ → aptitude search '~i~n^aptitude' | cat i A aptitude - terminal-based package manager i A aptitude-common - architecture independent files for the aptitude package manager i A aptitude-doc-en - English manual for aptitude, a terminal-based package manager In the above example the descriptions are no more aligned while they are in your examples with the very same command (and for me with 0.6.11-1 on Jessie, too). It gets even worse if automatically and manually installed packages are mixed in the output: ~ → aptitude search \~i | head i A 0ad - Real-time strategy game of ancient warfare i A 0ad-data - Real-time strategy game of ancient warfare (data files) i A 0ad-data-common - Real-time strategy game of ancient warfare (common data files) i 0x - Open Free Fiasco Firmware Flasher i A 2048-qt - mathematics based puzzle game i A 2ping - Ping utility to determine directional packet loss i A 9menu - Creates X menus from the shell i abduco - terminal session manager i A abe-archive-tools - Packages needed to read exotic archive formats i A abe-commandline - Metapackage of commandline tools Axel usually installs Now even the package names are no more aligned. IMHO this misalignment is what this bug report is about. And yes, if you add an arbitrary value to -w, the column-based, aligned layout comes back: ~ → aptitude search -w 80 '~i~n^aptitude' | cat i A aptitude- terminal-based package manager i A aptitude-common - architecture independent files for the apt i A aptitude-doc-en - English manual for aptitude, a terminal-ba ~ → aptitude -w 80 search \~i | head i A 0ad - Real-time strategy game of ancient warfare i A 0ad-data- Real-time strategy game of ancient warfare i A 0ad-data-common - Real-time strategy game of ancient warfare i 0x - Open Free Fiasco Firmware Flasher i A 2048-qt - mathematics based puzzle game i A 2ping - Ping utility to determine directional pack i A 9menu - Creates X menus from the shell i abduco - terminal session manager i A abe-archive-tools - Packages needed to read exotic archive for i A abe-commandline - Metapackage of commandline tools Axel usua Manuel: I really wonder why your examples looked different than mine wrt. to aligned columns. Maybe some different options being set via configuration files? Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#834402: aptitude: search loses column format when redirected or piped
Hi, 2016-08-15 11:59 Axel Beckert: Control: tag -1 + confirmed Hi Javier, Javier Cantero wrote: Compare this: $ aptitude search "~i aptitude" i aptitude0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager with the same output piped through `less`: $ aptitude search "~i aptitude" | less i aptitude 0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager The same happens if the output is redirected to a file: $ aptitude search "~i aptitude" > kk.txt $ cat kk.txt i aptitude 0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager Indeed. This looks like a regression from the version in Debian Jessie. I've already read the discussion in #815690. but the thing is: piping to more/less is a very common usage of aptitude search (since the lists of packages tend to be very long), not just a special case for automatic processing of the output. It's really annoying to have to remember to add an arbitrary[*] width using `-w` in every `aptitude search ... | less`, especially when it's a significant deviation from previous behaviour. I agree here, but I'm still not sure what's the best way to handle this case. It's not a regression, or at least not an unintended one. It was directed to fix the problems described in #445206 and #496728. The width given with -w is not arbitrary, it's the one that one wants the lines to have (at least for me, it works differently if one sets 80, 100 or 160). -w $COLUMNS should work fine if looking it directly in a terminal, or if you want the pipe/redirection to have exactly the same width as your current terminal. In the past it was just hardcoded to "80 columns", so your example when doing it with and without pipe/redirection will have looked different as well -- unless the terminal that you are using is 80-column wide, of course. (See attachment, the description is truncated). Cheers. -- Manuel A. Fernandez Montecelo $ aptitude search '~i~n^aptitude' i aptitude - terminal-based package manager i aptitude-common - architecture independent files for the aptitude package manager $ aptitude search '~i~n^aptitude' | cat i aptitude- terminal-based package manager i aptitude-common - architecture independent files for the apt
Bug#834402: [Aptitude-devel] Bug#834402: aptitude: search loses column format when redirected or piped
Control: tag -1 + confirmed Hi Javier, Javier Cantero wrote: > Compare this: > > $ aptitude search "~i aptitude" > i aptitude0.8.3-1 >- gestor de paquetes basado en terminal > i A aptitude-common 0.8.3-1 >- architecture independent files for the aptitude package manager > > with the same output piped through `less`: > > $ aptitude search "~i aptitude" | less > i aptitude 0.8.3-1 - gestor de paquetes basado en terminal > i A aptitude-common 0.8.3-1 - architecture independent files for the > aptitude package manager > > The same happens if the output is redirected to a file: > > $ aptitude search "~i aptitude" > kk.txt > $ cat kk.txt > i aptitude 0.8.3-1 - gestor de paquetes basado en terminal > i A aptitude-common 0.8.3-1 - architecture independent files for the > aptitude package manager Indeed. This looks like a regression from the version in Debian Jessie. > I've already read the discussion in #815690. but the thing is: piping to > more/less is a very common usage of aptitude search (since the lists of > packages tend to be very long), not just a special case for automatic > processing of the output. It's really annoying to have to remember to add > an arbitrary[*] width using `-w` in every `aptitude search ... | less`, > especially when it's a significant deviation from previous behaviour. I agree here, but I'm still not sure what's the best way to handle this case. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#834402: aptitude: search loses column format when redirected or piped
Package: aptitude Version: 0.8.3-1 Severity: normal Dear Maintainer, Compare this: $ aptitude search "~i aptitude" i aptitude0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager with the same output piped through `less`: $ aptitude search "~i aptitude" | less i aptitude 0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager The same happens if the output is redirected to a file: $ aptitude search "~i aptitude" > kk.txt $ cat kk.txt i aptitude 0.8.3-1 - gestor de paquetes basado en terminal i A aptitude-common 0.8.3-1 - architecture independent files for the aptitude package manager I've already read the discussion in #815690. but the thing is: piping to more/less is a very common usage of aptitude search (since the lists of packages tend to be very long), not just a special case for automatic processing of the output. It's really annoying to have to remember to add an arbitrary[*] width using `-w` in every `aptitude search ... | less`, especially when it's a significant deviation from previous behaviour. [*] arbitrary because usually it doesn't matter the actual width -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.3 Compiler: g++ 6.1.1 20160802 Compiled against: apt version 5.0.0 NCurses version 6.0 libsigc++ version: 2.8.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20160625 cwidget version: 0.5.17 Apt version: 5.0.0 aptitude linkage: linux-vdso.so.1 (0x7fffd27cc000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7faf90684000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7faf90454000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7faf90229000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7faf90022000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7faf8fd25000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7faf8fa2) libboost_iostreams.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.61.0 (0x7faf8f808000) libboost_filesystem.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.61.0 (0x7faf8f5ef000) libboost_system.so.1.61.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.61.0 (0x7faf8f3ea000) libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 (0x7faf8efe6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7faf8edc9000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7faf8ea47000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7faf8e742000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7faf8e52c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7faf8e18a000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7faf8df87000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7faf8dd83000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7faf8db6b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7faf8d95) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7faf8d74) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7faf8d51c000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7faf8d30a000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7faf8d101000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7faf8cefc000) /lib64/ld-linux-x86-64.so.2 (0x5571f0e7b000) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (600, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.6-amd64 (SMP w/4 CPU cores) Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.3-1 ii libapt-pkg5.0 1.3~pre3 ii libboost-filesystem1.61.0 1.61.0+dfsg-2.1 ii libboost-iostreams1.61.0 1.61.0+dfsg-2.1 ii libboost-system1.61.0 1.61.0+dfsg-2.1 ii libc6 2.23-4 ii libcwidget3v5 0.5.17-4+b1 ii libgcc11:6.1.1-11 ii libncursesw5 6.0+20160625-1 ii libsigc++-2.0-0v5 2.8.0-2 ii libsqlite3-0 3.13.0-1 ii libstdc++6