Hi all, I have noticed for a while that emerge --info displays multiple settings and their values on one line, which makes it difficult to read them. I will attach the specific output I'm referring to along with a reformatted version that would be easier to read. I would appreciate your consideration on this. Thanks, William $ emerge --info Portage 2.2.1 (default/linux/x86/13.0, gcc-4.6.3, glibc-2.15-r3, 3.10.0-05696-g98f486f1 i686) ================================================================= System uname: Linux-3.10.0-05696-g98f486f1-i686-Intel-R-_Celeron-R-_D_CPU_3.20GHz-with-gentoo-2.2 KiB Mem: 503276 total, 265928 free KiB Swap: 506040 total, 506040 free Timestamp of tree: Thu, 22 Aug 2013 08:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5, 3.2.5-r1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 9999::local sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.69 sys-devel/automake: 1.12.6 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo local ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--nospinner" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" USE="acl alsa berkdb bzip2 cli cracklib crypt curl cxx dbus dri fortran gdbm gpg iconv imap ipv6 javascript modules mudflap ncurses nls nptl openmp openrc pam pcre portaudio readline session ssl tcpd unicode usb x86 zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON
Created attachment 356776 [details] emerge-info1.txt This is the original output from emerge --info I am concerned about. Notice that all of this is one line.
Created attachment 356778 [details] emerge-info2.txt This is that same portion of the output, reformatted in a way that makes it easier to read imo. Is it possible to do this easily?
(In reply to William Hubbs from comment #2) > Created attachment 356778 [details] > emerge-info2.txt > > This is that same portion of the output, reformatted in a way that makes > it easier to read imo. Is it possible to do this easily? If those USE_EXPAND vars are mixed in with all the other vars, it makes it less obvious which USE flags are enabled because to have to go hunting around for all the USE_EXPAND vars.
@zmedico: I don't understand your response. I'm just asking that newlines be incorporated into the output, so that instead of: foo="some value" bar="another value" bas="and another value" it looks like: foo="some value" bar="another value" bas="and another value" That allows things like: emerge --info | grep -i 'video_cards=' or: grep -i 'video_cards=' emerge-info.txt to return a specific setting instead of giving you the settings of all of those variables.
As it is, you can look at the USE=... line and see all of the USE flags that are enabled. If we change the display as you propose, then that will no longer be possible because the USE_EXPAND flags will be split onto separate lines that are mixed among the other variables.
That seems a little confusing since use_expand flags are separate settings in make.conf. For all other settings in emerge --info, everything is listed one setting/value per output line. Why should the USE= line contain all of those other variables?
(In reply to William Hubbs from comment #6) > Why should the USE= line contain all of those other variables? The reasoning is that they are all mapped to USE flags, like video_cards_foo and stuff. I guess omitting those special expand flags from the USE= line probably isn't so bad, as long as we show include all of the corresponding USE_EXPAND variables in the default set of variables that's displayed.
(In reply to Zac Medico from comment #7) > The reasoning is that they are all mapped to USE flags, like video_cards_foo > and stuff. I guess omitting those special expand flags from the USE= line > probably isn't so bad, as long as we show include all of the corresponding > USE_EXPAND variables in the default set of variables that's displayed. I don't understand this. Could you rewrite it with fewer spelling errors and maybe give an example?
Just reread this. I agree with Zac. If you move VIDEO_CARDS, PYTHON_TARGETS, and so on, from the USE line, it gets very confusing and annoying to parse. In my opinion, this output is primarily for grep-ing and debugging, and not meant to be read as prose. I'm going to close this as WONTFIX for now. Please reopen if someone comes up with some solution that both a) make it obvious and easily parse-able (by computers) what USE flags are activated, and b) make it more "readable", where "readable" of course is quite subjective. Note that I'm not "putting my foot down". I would be perfectly happy to see some suggestions and have the bug reopened.
(In reply to Alexander Berntsen from comment #9) > Just reread this. I agree with Zac. If you move VIDEO_CARDS, PYTHON_TARGETS, > and so on, from the USE line, it gets very confusing and annoying to parse. > In my opinion, this output is primarily for grep-ing and debugging, and not > meant to be read as prose. That is exactly why I made the request. If I grep the output of emerge --info for VIDEO_CARDS, for example, all I want to see is VIDEO_CARDS="foo bar bas" Right now it is far from that and is very difficult to pull out the specific setting I want to check.
This is also a consistency issue, because using grep works as expected for other parts of emerge --info output, such as: emerge --info | grep LDFLAGS It is better to put the '^' in front of the setting you are grepping for, but that gives no output for anything on the use line other than emerge --info | grep '^USE'
(In reply to William Hubbs from comment #10) > If I grep the output of emerge > --info for VIDEO_CARDS, for example, all I want to see is > > VIDEO_CARDS="foo bar bas" > > Right now it is far from that and is very difficult to pull out the specific > setting I want to check. emerge --info | grep -o 'VIDEO_CARDS="[^"]*"' portageq envvar -v VIDEO_CARDS
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > (In reply to William Hubbs from comment #10) > > If I grep the output of emerge > > --info for VIDEO_CARDS, for example, all I want to see is > > > > VIDEO_CARDS="foo bar bas" > > > > Right now it is far from that and is very difficult to pull out the specific > > setting I want to check. > > emerge --info | grep -o 'VIDEO_CARDS="[^"]*"' > portageq envvar -v VIDEO_CARDS Ok, I didn't know about these, but that doesn't work if I am looking at a text file of someone elses emerge --info output for debugging purposes.
(In reply to William Hubbs from comment #13) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #12) > > (In reply to William Hubbs from comment #10) > > > If I grep the output of emerge > > > --info for VIDEO_CARDS, for example, all I want to see is > > > > > > VIDEO_CARDS="foo bar bas" > > > > > > Right now it is far from that and is very difficult to pull out the specific > > > setting I want to check. > > > > emerge --info | grep -o 'VIDEO_CARDS="[^"]*"' > > portageq envvar -v VIDEO_CARDS > > Ok, I didn't know about these, but that doesn't work if I am looking at a > text file of someone elses emerge --info output for debugging purposes. I was wrong in my last statement, the grep example you give does work, but it is definitely not intuitive. I still would rather see newlines in the output, so @bermalex, would you please reconsider?
As Arfrever points out, it's perfectly simple to grep the log for e.g. VIDEO_CARDS. However, if we go ahead with your proposed change, we will break grep-ing for *all* USE flags.
(In reply to Alexander Berntsen from comment #15) > As Arfrever points out, it's perfectly simple to grep the log for e.g. > VIDEO_CARDS. However, if we go ahead with your proposed change, we will > break grep-ing for *all* USE flags. That depends on how you define use flags. In the handbook, we define use flags as being set in USE= in make.conf, so given that definition, with or without my proposed change, emerge --info | grep '^USE=' is sufficient to show all use flags.
Currently there are many more pressing issues to work on in portage. We are currently not interested in wasting a ton more time over a trivial change. Something which I am sure will cause the same kind of uproar from a few individuals as the recent "." in DESCRIPTIONS mess. So, although I think the end result would be better, the whole setup would need to be re-vamped to be both consistent and individually searchable. In this case the overly loud vocal minority has created a "Can't touch this" attitude among the team. Leaving as RESOLVED, WONTFIX
(In reply to Alexander Berntsen from comment #15) > As Arfrever points out, it's perfectly simple to grep the log for e.g. > VIDEO_CARDS. However, if we go ahead with your proposed change, we will > break grep-ing for *all* USE flags. I wouldn't call that grep perfectly simple at all. A simple grep wouldn't require a regex like that, but just be "grep VIDEO_CARDS". As an alternative, why not put the USE flags in a separate section, each on their own line: USE_EXPAND: ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp.." APACHE2_MODULES="authn_core authz_core socache_shmcb..." CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore..." INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" USE="acl alsa berkdb bzip2 cli cracklib ..." USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64..." XTABLES_ADDONS="quota2 psd pknock lscan..." then, you can look for all USE_EXPAND via a simple: $ emerge --info | grep 'USE_EXPAND' -A 1000 or $ emerge --info | sed -n '/USE_EXPAND:/,$p' and anyone looking for VIDEO_CARDS or one of the other nearly two dozen (!) variables that are currently concatenated into one impossible to read line can simply do: $ emerge --info | grep VIDEO_CARDS and actually get a readable line. (In reply to Brian Dolbec from comment #17) > Currently there are many more pressing issues to work on in portage. We are > currently not interested in wasting a ton more time over a trivial change. Just because there are 'more pressing' issues to work on doesn't make this one invalid. That's what the 'importance field' is for. More pressing issues should get higher priority, while leaving this open as 'normal' or 'enhancement'. > Something which I am sure will cause the same kind of uproar from a few > individuals as the recent "." in DESCRIPTIONS mess. Appeasing an extremely vocal minority should not be reason to not fix bugs that affect others.
