Ufed fails to see and display the iwmmxt USE flag (recently added as global), possibly other flags as well. Confirmed on a few amd64/x86 boxes. If I rename (in use.desc) iwmmxt to wmmxt or iiwmmxt, the flag is displayed properly. Changing the description of the flag doesn't change anything. If I add (to use.desc) the flag "iwa" with a random description, it is displayed properly. # grep iwmmxt /usr/portage/profiles/use.desc iwmmxt - Adds support for optimizations for ARM iwMMXt instructions Reproducible: Always Steps to Reproduce: 1. Launch ufed 2. Try looking for the flag iwmmxt Actual Results: The iwmmxt flag is not found. Expected Results: The iwmmxt flag should be displayed. Portage 2.1.10.11 (hardened/linux/amd64, gcc-4.5.3, glibc-2.12.2-r0, 3.0.4 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.0.4-x86_64-Intel-R-_Core-TM-_i5-2520M_CPU_@_2.50GHz-with-gentoo-2.0.3 Timestamp of tree: Mon, 24 Oct 2011 18:15:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.68 sys-devel/automake: 1.9.6-r3, 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.5.3-r1 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.39 (virtual/os-headers) sys-libs/glibc: 2.12.2 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -maes -mpclmul -mpopcnt" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -maes -mpclmul -mpopcnt" DISTDIR="/tmp/distfiles" FEATURES="assume-digests binpkg-logs candy collision-protect distlocks ebuild-locks fixlafiles fixpackages news noinfo parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync" FFLAGS="" GENTOO_MIRRORS="http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.wheel.sk/ http://gentoo.supp.name/ http://gentoo.mirror.web4u.cz/ http://de-mirror.org/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed" LINGUAS="en cs ja" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/boot/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.cz.gentoo.org/gentoo-portage" USE="X a52 aac acpi aes-ni alsa amd64 avx bash-completion berkdb bluetooth bzip2 cddb cjk cli cracklib crypt css dri encode ffmpeg flac fontconfig ftp gdbm geoip gif gnutls gzip hardened hddtemp iconv icq icu idn imap javascript jpeg jpeg2k justify latex lm_sensors lzma lzo matroska mbox mime mms mmx mmxext modules mp3 mp4 mpeg mplayer mudflap multilib musicbrainz ncurses nls nocd nptl nptlonly ogg opengl oscar pam pax_kernel pcre pda pdf png pppd quicktime raw readline recode rss session smp sockets sound spell sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 svg sysfs syslog threads truetype udev unicode urandom usb v4l v4l2 videos vim-syntax vorbis wifi x264 xcomposite xorg xosd xscreensaver xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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 stage tables krita karbon braindump" 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="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en cs ja" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="intel vesa" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= app-portage/ufed-0.40.1 was built with the following: USE="(multilib)" dev-lang/perl-5.12.4-r1 was built with the following: USE="berkdb gdbm (multilib) -build -debug -doc -ithreads"
How strange.
I just tried it out and it is displayed in current ufed. Please re-open if you find other flags that are not displayed when they should.
Cannot confirm here (an amd64 and an x86 box). I still cannot see "iwmmxt" and "neon" (and maybe others I'm not aware of). ****************************************************************************** ****************************************************************************** # emerge --info ufed perl Portage 2.1.11.31 (default/linux/x86/10.0, gcc-4.5.4, glibc-2.15-r3, 3.6.11-gentoo i686) ================================================================= System Settings ================================================================= System uname: Linux-3.6.11-gentoo-i686-Intel-R-_Pentium-R-_4_CPU_3.06GHz-with-gentoo-2.1 Timestamp of tree: Sun, 06 Jan 2013 19:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.69 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64 x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=prescott -mmmx -msse -msse2 -msse3" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=prescott -mmmx -msse -msse2 -msse3" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-logs candy collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news noinfo parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://gentoo.mirror.web4u.cz/ ftp://gentoo.mirror.web4u.cz/ ftp://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.supp.name/" LANG="cs_CZ.UTF-8" LC_ALL="cs_CZ.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --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="" SYNC="rsync://rsync.cz.gentoo.org/gentoo-portage" USE="acpi apache2 bash-completion berkdb bindist branding bzip2 cdinstall cgi cli cracklib crypt cxx dedicated ftp gd gdbm geoip gif gzip iconv icu idn javascript jit jpeg jpeg2k lzma lzo mmap mmx modules mudflap mysql mysqli ncurses nls nocd nptl odbc pam pcre php png pppd readline recode session smp sockets spell sse sse2 sse3 ssl subversion syslog szip threads tiff tokenizer udev unicode usb videos vim-syntax x86 zlib" 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" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions auth_basic authn_default authn_file authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi deflate dir disk_cache dumpio env expires ext_filter file_cache filter headers include log_config log_forensic logio mem_cache mime mime_magic negotiation setenvif unique_id userdir usertrack" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" 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" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="cs en" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= app-portage/ufed-0.40.2-r1 was built with the following: USE="" dev-lang/perl-5.12.4-r1 was built with the following: USE="berkdb gdbm -build -debug -doc -ithreads" ****************************************************************************** ****************************************************************************** # emerge --info ufed perl Portage 2.1.11.31 (hardened/linux/amd64, gcc-4.5.4, glibc-2.15-r3, 3.7.0 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.7.0-x86_64-Intel-R-_Core-TM-_i5-2520M_CPU_@_2.50GHz-with-gentoo-2.1 Timestamp of tree: Sun, 06 Jan 2013 19:15:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.9 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -maes -mpclmul -mpopcnt" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -maes -mpclmul -mpopcnt" DISTDIR="/tmp/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs candy collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news noinfo parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.mirror.dkm.cz/pub/gentoo/ http://gentoo.supp.name/ http://ftp.fi.muni.cz/pub/linux/gentoo/ ftp://gentoo.mirror.dkm.cz/pub/gentoo/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--as-needed" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/boot/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.cz.gentoo.org/gentoo-portage" USE="X a52 aac acpi aes-ni alsa amd64 avx bash-completion berkdb bluetooth bzip2 cddb cjk cli cracklib crypt dri encode ffmpeg flac fontconfig ftp gdbm geoip gif gnutls gps gzip hardened hddtemp iconv icu idn imap javascript jpeg jpeg2k justify libass lm_sensors lzma lzo matroska mbox mime mms mmx mmxext modules mp3 mp4 mpeg mplayer mudflap multilib musicbrainz ncurses nls nocd nptl ogg opengl pam pax_kernel pcre pda pdf png postscript pppd quicktime raw readline recode session smp sockets sound spell sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 svg syslog threads truetype udev unicode urandom usb v4l vdpau videos vim-syntax vorbis wifi x264 xcomposite xosd xscreensaver xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" 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" 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="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en cs ja" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="intel vesa" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON ================================================================= Package Settings ================================================================= app-portage/ufed-0.40.2-r1 was built with the following: USE="(multilib)" dev-lang/perl-5.12.4-r1 was built with the following: USE="berkdb gdbm (multilib) -build -debug -doc -ithreads"
Strange, I can see both. The only difference that jumps at me is, that I have neither default/x86 nor hardened/amd64 but default/amd64. I'll look into the parsing code whether there is any possibility that entries get filtered or skipped. Otherwise I need to find out a way to reproduce this.
Sven I found that "neon" and "iwmmxt" flags are mentioned in /usr/portage/profiles/base/use.mask. Maybe there is problem with inherting masks and unmasks on arch's profiles?
Marcin might have hit it. When I comment out lines 39 through 49 of ufed (ufed-0.40.2-r1) I see both "iwmmxt" and "neon".
Then this is certainly a bug of another quality than I thought. I can see _all_ USE flags from /usr/portage/profiles/base/use.mask. But where is the use-case for this? ufed should not display USE flags that aren't even valid for the system. The full list is long enough without ufed displaying masked flags. The following strikes me. === 1 === The use flag "ayatana" is masked: $ grep "ayatana" /usr/portage/profiles/base/use.mask ayatana $ === 2 === eix gtimelog shows the masked flag: $ eix gtimelog * app-office/gtimelog Available versions: 0.7.1 ~0.8.0 {{ayatana test}} Homepage: http://mg.pov.lt/gtimelog/ Description: A small Gtk+ application for keeping track of your time $ === 3 === equery u gtimelog-0.7.1 does _not_ show the flag, although the ebuild has it in its IUSE: $ equery u app-office/gtimelog-0.7.1 [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-office/gtimelog-0.7.1: U I - - test : Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore $ === 4 === ufed displays this flag on my system although it is useless. ----- There are already enhancements on filtering USE flags (global versus local in bug 104852 and per package only flags in bug 106815) on my todo list. Maybe it is a good idea to filter out masked use flags completely and reliably to ensure a useful list of displayed flags. Those flags must be parsed anyway so I could imagine a key code or option to re-show them, but in parantheses like portage does it. What do you think?
I second that opinion - masked flags should not be shown (by default, anyway). I didn't even know there was such a thing as masked use flags, actually. Still, it's strange how our systems behave differently. I have no problem running any patched versions you might want me to run on my systems in order to solve the issue.
It's on my todo list.
Kernel sources has USE flag "build" and it looks ufed-0.40.2-r1 doesn't display it on my 2 boxes.
It looks like there was no bug at all. ufed does not display masked USE flags. You can not enable them in your make.conf without unmasking first. Additionally the two flags "boostrap" and "build" are filtered, too, because those are dangerous. There is no need to discuss "boostrap". But for the "build" flag there is a very important reason why this flag must not be available in ufed. "build" is an internal USE flag for gcc. It would be a serious bug if ufed allowed to set that flag in make.conf. ----- sys-devel/gcc: - - bootstrap : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during original system bootstrapping [make stage2] - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] ----- However, it seems that my comments about ufed showing certain flags on my system was an indication that something broke on my machine. An indication I did not understand back then. I have analyzed the work flow of ufed line by line and it filters masked flags correctly. After the last sync I can no longer see masked flags in ufed, too. I am currently working on transporting the information about masked flags into the interfaces, so users can at least display (but not change, obviously) masked flags if they want.
I have just pushed commits to git which add/change the following: 1. Masked flags are no longer thrown away, but sent to the curses interface if they are known. 2. Masked flags are not shown by default but can be unhidden using the "Tab"-Key. 3. Masked flags can not be changed. (Obviously.) To test please emerge app-portage/ufed-9999 - This will grab the current sources from the git repository. I'd like to hear about whether this works nicely everywhere and - of course - as expected.
The only issue that I have seen so far with the change is a minor one. I have to press the tab key twice to toggle the masked flags back off.
Well, my idea was, that you can either view not masked flags, masked flags only, or both. But perhaps showing both is a bit of an overkill? Should I restrict the filter to show either masked or not masked flags only? Another issue is the key assigned. Tab. Bug 104852 discusses the filtering of global versus local flags. Those need a key to toggle as well. As nothing is fixed for the next release, yet, I'd like to hear some ideas about key bindings. Maybe something like ctrl+m for masked flag filter and ctrl+l for local/global flag filter? Maybe I am fussing around too much for too little, but now the tab key seems too common for such a special filter...
[in ref. to ufed-9999-006dcae3e2abadc1773b2d762b0f661ad69da851] I agree Tab is better suited for some other function. No need for a key combo, though. The description "Toggle Masked (Tab)" at the bottom should be changed to something like "Toggle Masked/Normal/All (Tab)" - that's what fooled Paul, I believe. I think the masked flags shouldn't be listed in brackets. The [m] tag is sufficient and I can't search for them just by typing out their name (I have to include the bracket at the beginning which is counter-intuitive). Furthermore, since local flags have the "Local flag: " prefix in their description, masked flags could have something like "Masked flag: " prefix. Alternatively - and perhaps better yet - both these prefixes could be reduced to something shorther (like [l] and [m]), because space for the description is of short supply for people with a 80x25 terminal. I think the masked flags should be sorted alphabetically along with the rest of the flags. This is important: ufed should be able to distinguish between a masked flag not being set and being set in make.conf (by "being set" I mean both the positive and the negative setting). This difference should be displayed in the ncurses interface and ufed should allow the user to remove the flag from their make.conf. Maybe ufed shouldn't treat masked flags the way it does now - they are fixed, static, cannot be toggled (with the spacebar) +/-/nothing. Maybe they should be toggle-able normally like any other flag and only marked [m] in their description (as discussed previously). And then when the user is leaving&saving a new make.conf ufed should display a warning saying that some masked flags are explicitly +/-, list those masked flags (or some of them if the list is too long for a single line) and offer a cancellation of the leave&save decision. In fact, the warning should be displayed even upon the leave&no-save operation - some people might have unknowingly had a masked flag in their make.conf for a long time and now the time might have come for somebody to inform them about it. If you don't like the idea of masked flags being newly(!) toggle-able at all, I'm fine with that - I'm sure you get my point in what I wish changed.
First of all thank you very much for your feedback! (In reply to comment #15) > I agree Tab is better suited for some other function. No need for a key > combo, though. > > The description "Toggle Masked (Tab)" at the bottom should be changed to > something like "Toggle Masked/Normal/All (Tab)" - that's what fooled Paul, I > believe. Normal keys are caught for the incremental search. But maybe F-Keys would do? I had a longer description, too, but with the planned local/global flag filter, the space on that line starts getting short. How about: "Filter (F5: Normal/Mask, F6: Local/Global)" ? > > I think the masked flags shouldn't be listed in brackets. The [m] tag is > sufficient and I can't search for them just by typing out their name (I have > to include the bracket at the beginning which is counter-intuitive). The list is rather short and the current design of ufed forces me to put them at the beginning. Further I thought it would be more intuitive if the flags where displayed like portage does. > > Furthermore, since local flags have the "Local flag: " prefix in their > description, masked flags could have something like "Masked flag: " prefix. > Alternatively - and perhaps better yet - both these prefixes could be > reduced to something shorther (like [l] and [m]), because space for the > description is of short supply for people with a 80x25 terminal. Yes, that idea came to my mind, too, this very morning. I need an additional mechanism to distinguish between global and local flags, and adding a short prefix like [l] / [g] / [m] in front of the description (where I actually need this to be) would help me. Aaaaand I could eventually move the packages to the front. I find it annying for ages now to have to scroll to the right just to find out which exact package is affected. > > I think the masked flags should be sorted alphabetically along with the rest > of the flags. As I stated above ufed design does not allow that. To be more specfic, the ufed display management would not be able to handle this. I would have to rewrite a lot of stuff. And personally I do not think that it is a good idea to "hide" the masked flags between regular flags. > > This is important: ufed should be able to distinguish between a masked flag > not being set and being set in make.conf (by "being set" I mean both the > positive and the negative setting). This difference should be displayed in > the ncurses interface and ufed should allow the user to remove the flag from > their make.conf. Actually ufed does display it. When I add two masked flags to my make.conf, like "3dfx -altivec", I get: [m] (3dfx) ( +) [m] (altivec) ( -) Maybe I should at least add the possibility to remove those flags from make.conf, but not set it. (snip) > If you don't like the idea of masked flags being newly(!) toggle-able at > all, I'm fine with that - I'm sure you get my point in what I wish changed. No, it is not a matter of liking. I do like the idea, but masked flags are something highly special and dangerous. If you have to unmask and set a masked flag, then you are most probably doing some very "I-know-what-I-am_doing"-stuff. ufed must not make such dangerous tweaks easy. You really *must* know what you'll break. ;) And I do not think that some kind of warning about masked flags is something greeted by people who do have unmasked flags. ufed would bug them about it, but just think about someoen needing (prefix) or wanting to test (uclibc). And then there are flags that might have been masked after someone enabled or disabled them. They wouldn't do anything in your make.conf, so nagging about them with an extra dialogue does not sound appealing to me. (Of course I might be on a completely wrong track and am missing important use cases here!) However, before I can tweak the masked flags handling anyway, I have to teach ufed to know about manually unmasked flags first. This is something missing, because those flags would become regular flags and should be handled like that. (But still get the [m] prefix for the description.)
(In reply to comment #16) > How about: "Filter (F5: Normal/Mask, F6: Local/Global)" ? +1 > > I think the masked flags shouldn't be listed in brackets. The [m] tag is > > sufficient and I can't search for them just by typing out their name (I have > > to include the bracket at the beginning which is counter-intuitive). > > The list is rather short and the current design of ufed forces me to put > them at the beginning. Further I thought it would be more intuitive if the > flags where displayed like portage does. OK, let them stay non-searchable then. (I mean, searchable with the bracket only.) > Aaaaand I could eventually move the packages to the front. I find it annying > for ages now to have to scroll to the right just to find out which exact > package is affected. Nice, +1. > > This is important: ufed should be able to distinguish between a masked flag > > not being set and being set in make.conf (by "being set" I mean both the > > positive and the negative setting). This difference should be displayed in > > the ncurses interface and ufed should allow the user to remove the flag from > > their make.conf. > > Actually ufed does display it. When I add two masked flags to my make.conf, > like "3dfx -altivec", I get: > > [m] (3dfx) ( +) > [m] (altivec) ( -) Personally, I'd like to see the state of the flag in the left-most brackets. We already have masked flag names in brackets and we have the [m] as a prefix in the description. As a user, I'm used to looking at the left-most brackets. I'll very easily overlook a masked flag being set when this is only indicated in the () brackets following the flag name. I believe this holds for more people. > Maybe I should at least add the possibility to remove those flags from > make.conf, but not set it. Definitely, +1. > However, before I can tweak the masked flags handling anyway, I have to > teach ufed to know about manually unmasked flags first. This is something > missing, because those flags would become regular flags and should be > handled like that. (But still get the [m] prefix for the description.) Good point. Maybe these could get something [un-m] and be handled as normal apart from that. As for the rest of your comments> understood, OK. By the way, I just filed this today: https://bugs.gentoo.org/show_bug.cgi?id=452650 but maybe I should've just put a note in here for you. It's about UI cosmetics. Please, close the bug if you find the matter too trivial for a separate bug.
Sorry for the long delay, I had to change (and partly rewrite) a lot of the inner details to allow the design to become more knowlegdable and more flexible. The following changes have been made: - The left brackets now show the selections status for masked flags, too. - Masked flags are now searchable without hitting '(' first. - global flag descriptions are now blue. (*1) - the poackage list of local flag descriptions is now printed first not last. (*2) - All flags have one of the following prefixes in front of their descriptions: (*3) [g] Global flag description [l] Local flag description, no affected packages are installed. [L] Local flag description, at least one affected package is installed. [m] Masked flag description, global or no affected packages are installed. [M] Masked flag description, at least one affected package is installed. *1: This is now final design descision. I guess I'll turn them black again but drop the [g] prefix. *2: Although *I* like it much better this way, I'll make this changeable. (F7 ? ;)) *3: I am not very happy with this (brackets _again_) design. Maybe two characters, once the prefix for global descriptions is dropped, are better. Something like 'L'/'M' for "local"/"masked" and ' '/'*' (or 'I') for "not installed"/"installed". I haven't made up my mind, yet. Still missing to resolv this bug: - Reassign toggle key (still Tab) - Make masked flags at least be removable from make.conf - Show manually unmasked flags like normal flags (editable and everything)
Sorry. It is late and I have made some idiotic (and _VERY_ misleading spelling errors: (In reply to comment #18) > - the poackage list of local flag descriptions is now printed first not > last. (*2) the list of affected packages by a local flag description is now printed in front of the description and not after it. > *1: This is now final design descision. I guess I'll turn them black again > but drop the [g] prefix. This is _NO_ final descision. Really, one additional 'w' and the meaning is reversed. Shame on me! > > *2: Although *I* like it much better this way, I'll make this changeable. > (F7 ? ;)) Which means users can put the list back to the end of each line. > > *3: I am not very happy with this (brackets _again_) design. Maybe two > characters, once the prefix for global descriptions is dropped, are better. > Something like 'L'/'M' for "local"/"masked" and ' '/'*' (or 'I') for "not > installed"/"installed". I haven't made up my mind, yet. Example: ----- ( ) ccache ( ) L (dev-util/catalyst) Enables ccache support ( ) L* (dev-lang/swig) build ccache-swig(a fast c -----
(In reply to comment #18) > - Masked flags are now searchable without hitting '(' first. Since these flags are not sorted along with the other flags, I think they actually should be only searchable with the initial bracket. Add the following flag in your use.desc: ib - Blahblah Now start ufed, switch to displaying 'all' flags, and type 'ibm'. You're still stuck on the masked "ibm" flag, while the program should've first moved you to the "ib" flag, then skip back to the "(ibm)" flag. The "ib" flag is invisible for searching. That's bad. Or, clear the searching, move to the "i18n" flag and type 'ibm': you're first moved to the "ib" flag, then to the "ibmvio" flag. Now the "(ibm)" flag is omitted from the search results which doesn't correspond to your current design. > - the poackage list of local flag descriptions is now printed first not > last. (*2) > *2: Although *I* like it much better this way, I'll make this changeable. > (F7 ? ;)) +1. F7 is OK, I think. > - All flags have one of the following prefixes in front of their > descriptions: (*3) > > [g] Global flag description > [l] Local flag description, no affected packages are installed. > [L] Local flag description, at least one affected package is installed. > [m] Masked flag description, global or no affected packages are installed. > [M] Masked flag description, at least one affected package is installed. Wow, very nice! Also, this strongly calls for an F8 :) to toggle displaying everything / [M] and [L] only. > *3: I am not very happy with this (brackets _again_) design. Maybe two > characters, once the prefix for global descriptions is dropped, are better. > Something like 'L'/'M' for "local"/"masked" and ' '/'*' (or 'I') for "not > installed"/"installed". I haven't made up my mind, yet. Replacing more brackets with something else sounds sensible. Although... > Example: > ----- > ( ) ccache ( ) L (dev-util/catalyst) Enables ccache support > ( ) L* (dev-lang/swig) build ccache-swig(a fast c > ----- ... the "L*" should probably be delimited from the description - global flags have no leading bracket in it. It would be just "... ( ) * Enables foobar". Vertical delimiter might help: (+) localflagX |+ |L | (dev-lang/swig) Enables foo ( ) globalflagY | | *| Enables bar As for the rest> nice / understood.
I don't mean the vertical delimiter you get when you press the '|' key. I mean the ncurses vertical delimiter for the box that already surrounds the main window.
Another searching issue: start ufed, type 'shaper', you are moved to the flag "shaper". Now press the down-arrow; searching is cleared and you are moved one flag downwards. Finally, type 'server'. You are not moved to the flag "server". Tested with ufed-9999-4c71fca78a4ff4afc8d8380c6221acecf58f123a
Hi Roman, I have been busy, and here is the current status: - The searching issue (there was a problem with searching backwards in the list) is fixed. So this issue will be gone with the next push. - Currently I am (partly) rewriting the core display routines to make them flexible enough to skip flags without punching holes in the list. This needs a lot of testing. Right now the list shows up and scrolls like it was. The next step for me is to reinsert the masked flags into the list, which will fix the other searching issue. And the masked flags will be where they alphabetically belong. - Once this is done I'll re-enable the local/global filter that is already added and push the result. As for the flag scope, I like the idea with the ncurses vertical delimiter and will definetly test it.
Just pushed the latest commits for ufed-9999. - Masked flags can be toggled on and off with F5. - They show up alphabetically sorted. - I have added the ncurses vertical separator (ACS_VLINE) for package related flags. Global descriptions are again prefix-less. (And black, btw. Didn't like the blue in the end.) Of course the global flag descriptions break the vertical separations for local prefixes. But I had no better idea, yet.
All looks fine with functionality. I thought, however, that even globals would have the | | before their description. They would have no 'G' in it, but they might or might not have the asterisk - that piece of information is missing now. Plus, things are not aligned, as you said. And what about this layout (set in make.conf, global, affects an installed package)? [+] lzma | +| *| Support for LZMA This should save 2 characters worth of space horizontally.
(In reply to comment #25) > All looks fine with functionality. I thought, however, that even globals > would have the | | before their description. They would have no 'G' in it, > but they might or might not have the asterisk - that piece of information is > missing now. Plus, things are not aligned, as you said. > > And what about this layout (set in make.conf, global, affects an installed > package)? > [+] lzma | +| *| Support for LZMA > > This should save 2 characters worth of space horizontally. Done and pushed, please test it if you like the new layout. The piece missing is the asterisk for global flag description. But whether or not to indicate that there are packages installed that are affected by a global use flag is beyond this bug. ;)
(In reply to comment #26) > Done and pushed, please test it if you like the new layout. It's neatly aligned, only the last line in the main window is empty. > The piece missing is the asterisk for global flag description. But whether > or not to indicate that there are packages installed that are affected by a > global use flag is beyond this bug. ;) Ah, OK, didn't notice that. But why? It looks like an easy thing to add and it might be a feature of a certain usability for some people - those who want to keep their make.conf clean from useless flags and who want to save (a lot of) time setting up (global) flags by limiting themselves to those that actually affect their system.
(In reply to comment #27) > (In reply to comment #26) > > Done and pushed, please test it if you like the new layout. > > It's neatly aligned, only the last line in the main window is empty. Type something. ;) > > > The piece missing is the asterisk for global flag description. But whether > > or not to indicate that there are packages installed that are affected by a > > global use flag is beyond this bug. ;) > > Ah, OK, didn't notice that. But why? It looks like an easy thing to add and > it might be a feature of a certain usability for some people - those who > want to keep their make.conf clean from useless flags and who want to save > (a lot of) time setting up (global) flags by limiting themselves to those > that actually affect their system. Actually this is not this easy. Currently I can only tell that a specific local flag description affects an installed package, because it comes from use.local.desc so I can compare it with the installed packages. To effectively add a reliable information whether a global flag is (currently) used or not, I have to add proper parsing of IUSE (means: /var/db/pkg/category/installed-package/IUSE) and its companion PKGUSE (which where explicitedly set when emerged) first. But this is already on my todo list at position 4 of 9.
(In reply to comment #28) > > It's neatly aligned, only the last line in the main window is empty. > Type something. ;) Oh. :)
I caused a crash with 9999-7d480726bfedba69db50d761f669829414fba53c I hit F5 twice to display masked flags and then hit ? to display help. ufed printed the following error message: ERROR in ufed-curses.c:139 (drawitems): -> drawitems() must not be called with a filtered currentitem! (topline 0 listline 0) Other than that the changes so far look good to me.
(In reply to comment #30) > I caused a crash with 9999-7d480726bfedba69db50d761f669829414fba53c > > I hit F5 twice to display masked flags and then hit ? to display help. ufed > printed the following error message: > > ERROR in ufed-curses.c:139 (drawitems): -> drawitems() must not be called > with a filtered currentitem! (topline 0 listline 0) > > Other than that the changes so far look good to me. This issue should be fixed now.
Please check current app-portage/ufed-9999 whether you like the result. ufed is not yet complete, the display of masked local flags (meaning a normal flag where it is masked or forced only for specific packages) needs to be improved. (Example: "upnp" A regular flag but masked for kdelibs.) And of course the documentation has to be updated. Once everybody is fine with the design and the above two issues are sorted out, I guess ufed is ready for a new release. Thank you very much for your patience!
Just checkout'd. What does DPC stand for precisely? Shouldn't the ones that have '+' in the middle be listed with '(+)' in the left-most column? I can see that ufed now automatically removes the ssse3 sse4* sse5 flags from make.conf. What is the rationale for that? I see it doesn't touch the global ones - sse, sse2 and sse3... Also, although ufed won't save these local sse* flags into make.conf, it lets me select them. If they have a similar status to masked flags, it might be better to hide them under F5 and make them un-selectable (only). # ufed Use of uninitialized value $Portage::eprefix in concatenation (.) or string at /usr/sbin/ufed line 170. Use of uninitialized value $Portage::eprefix in concatenation (.) or string at /usr/sbin/ufed line 171.
(In reply to comment #33) > What does DPC stand for precisely? Shouldn't the ones that have '+' in the > middle be listed with '(+)' in the left-most column? That is to be updated in the help text. The man page already show (partly) updated information: D = make.defaults P = package.use (or more precisely: The package is installed having this flag enabled) C = make.conf : Your settings. > > I can see that ufed now automatically removes the ssse3 sse4* sse5 flags > from make.conf. What is the rationale for that? I see it doesn't touch the > global ones - sse, sse2 and sse3... It does _WHAT_ ??? I have those flags enabled with ufed, make.conf has: ~ # egrep "^[^#].*sse" /etc/portage/make.conf sndfile sox sqlite sqlite3 sse4 sse41 sse4_1 sse4a sse5 ssse3 subversion And when I restart ufed they are gone? *CRAP* (I hope you had a backup of your make.conf...) However, I found the bug and it is fixed now. > Also, although ufed won't save these local sse* flags into make.conf, it > lets me select them. If they have a similar status to masked flags, it might > be better to hide them under F5 and make them un-selectable (only). No, no it was a bug. > # ufed > Use of uninitialized value $Portage::eprefix in concatenation (.) or string > at /usr/sbin/ufed line 170. > Use of uninitialized value $Portage::eprefix in concatenation (.) or string > at /usr/sbin/ufed line 171. Ah, I must have overlooked those... -> fixed.
> > What does DPC stand for precisely? Shouldn't the ones that have '+' in the > > middle be listed with '(+)' in the left-most column? > > D = make.defaults > P = package.use (or more precisely: The package is installed having this > flag enabled) > C = make.conf : Your settings. Could you please give an example of packages with and without a '+' under "P" and show why the '+' is/isn't there? I probably lack knowledge of something important here, but I only see a very few flags in package.use (be it /usr/portage/profiles/... or in /etc/portage/package.use) and I have relatively many pluses under "P" in ufed.
(In reply to comment #35) > > > What does DPC stand for precisely? Shouldn't the ones that have '+' in the > > > middle be listed with '(+)' in the left-most column? > > > > D = make.defaults > > P = package.use (or more precisely: The package is installed having this > > flag enabled) > > C = make.conf : Your settings. > > Could you please give an example of packages with and without a '+' under > "P" and show why the '+' is/isn't there? I probably lack knowledge of > something important here, but I only see a very few flags in package.use (be > it /usr/portage/profiles/... or in /etc/portage/package.use) and I have > relatively many pluses under "P" in ufed. That is another problem I have to solve in the "documentation" section. "package.use" files tend to enable/disable USE flags for specific versions. But ufed shows generalized information. I therefore had to change this column a bit. A '+' here means that the package is installed with the USE Flag enabled. A '-' means that, at the time the package was emerged, the flag was enabled, but explicitly disabled for the package. The difficult (and to-be-solved) detail is, that the package will also get a '+' if the flag is enabled by default by the ebuild. Example from my notebook: The flag "eigen" is not enabled anywhere on my system. It is nowhere set in any file. But the ebuild enables it: ~ # grep "IUSE" /usr/portage/kde-base/kdeartwork-kscreensaver/kdeartwork-kscreensaver-4.9.5.ebuild IUSE="debug +eigen +kexiv2 opengl xscreensaver" and therefore it has a '+' in ufed. --- An idea would be that I parse all possible package.use files and filter for versionless packages. I could combine this with the information from the installed packages and simply declare the (P) to simply mean "Package".
Hmm, I think I'll wait for the final functionality of this.
(In reply to comment #37) > Hmm, I think I'll wait for the final functionality of this. Done, have fun! ;) Explanation: The column 'P' is now showing not only the status of installed packages, but adds information from both profiles package.use files and the user specific /etc/portage/package.use. Therefore it can contain both '+' and '-'. There is one limitation, though: Some entries are bound to specific versions. These are skipped, because ufed can in no acceptable way determine whether a version-bound entry is relevant for the displayed list, or not. I will update the documentation next, it is horribly outdated.
(In reply to comment #38) > Explanation: The column 'P' is now showing not only the status of installed > packages, but adds information from both profiles package.use files and the > user specific /etc/portage/package.use. Therefore it can contain both '+' > and '-'. Change: The column 'P' only shows what is found in the various package.use files. I admit I was a bit of an idiot there. It is completely irrelevant for a use flag editor which flag was enabled when a package was installed. Only what is enabled/disabled *now* counts. Sorry that I did not see this earlier.
It seems to ignore my /etc/portage/package.use. In it I have sys-fs/udev gudev virtual/udev gudev media-video/mplayer -dvdnav But "gudev" has no '+' under P and 'dvdnav' has a '+' under P.
(In reply to comment #40) > It seems to ignore my /etc/portage/package.use. In it I have > sys-fs/udev gudev > virtual/udev gudev > media-video/mplayer -dvdnav > > But "gudev" has no '+' under P and 'dvdnav' has a '+' under P. Good find! Parsing installed packages could indeed "overwrite" the findings from package.use. I have fixed the order now, so package.use will no longer be overwritten by the settings in installed packages IUSE files. To make sure it works I have tried with exactly those three lines from yours in my /etc/portage/package.use file.
The compile phase fails, complaining about a missing 'ufed.8'. I see dead people. Still. # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l osdmenu {} \; # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l acoustid {} \; # And yet, ufed says: ( ) osdmenu | + |Li|(media-video/mplayer) Blah ( ) acoustid | + |Li|(media-sound/picard) Bleh ----- Another thing: take the global flag "oss". I have it '-oss' in make.conf. When I add 'app-emulation/wine oss' into /etc/portage/package.use, nothing changes about the way the flag is presented in ufed - no sign of the fact that I have the flag enabled for wine. I think that as long as the package.use are taken into consideration, this situation should be projected in ufed.
(In reply to comment #42) > The compile phase fails, complaining about a missing 'ufed.8'. I just fixed the ufed-9999 ebuild in the tree to fix that issue.
(In reply to comment #43) > (In reply to comment #42) > > The compile phase fails, complaining about a missing 'ufed.8'. > > I just fixed the ufed-9999 ebuild in the tree to fix that issue. Thank you very much, I didn't realize this was necessary. (In reply to comment #42) > I see dead people. Still. > > # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l > osdmenu {} \; > # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l > acoustid {} \; > # > > And yet, ufed says: > ( ) osdmenu | + |Li|(media-video/mplayer) Blah > ( ) acoustid | + |Li|(media-sound/picard) Bleh Ah, a detail to add to the documentation. The middle column is what package.use and the ebuilds think is necessary: # grep -m 1 "osdmenu" /usr/portage/media-video/mplayer/mplayer-1.1-r1.ebuild +network nut openal +opengl +osdmenu oss png pnm pulseaudio pvr +quicktime # grep -m 1 "acoustid" /usr/portage/media-sound/picard/picard-1.1.ebuild IUSE="+acoustid +cdda +ffmpeg nls" You see? Both ebuilds set the flag by default, so the '+' in the P column is correct, because you have these packages installed. > Another thing: take the global flag "oss". I have it '-oss' in make.conf. > When I add 'app-emulation/wine oss' into /etc/portage/package.use, nothing > changes about the way the flag is presented in ufed - no sign of the fact > that I have the flag enabled for wine. I think that as long as the > package.use are taken into consideration, this situation should be projected > in ufed. Well, wine does not have an individual meaning of this use flag, which means it has no individual line in use.local.desc. Therefore wine does not have a line displayed in ufed where the '+' could be displayed. I still have no idea how to display these "affected" packages without exploding the list of displayed lines in ufed. I think it is an important information, but just use "doc" as an example: # grep -c " doc" /etc/portage/package.use 86 So I'd need 86 (or 18 if one line lists up to five packages) extra lines just to represent the packages that do not listen to "doc" which I do not enable in make.conf, (*) However, I am planning to test various theories about how to add a limited list of affected packages for individual settings from package.use. But when? There have been so many changes, that IMHO an "rc" should be released, soon. (*) This is not entirely true, as some of these packages already have a local description and are thus already listed. It is just an example.
(In reply to comment #44) > > # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l > > osdmenu {} \; > > # find /etc/portage /usr/portage/profiles -name package.use -exec grep -l > > acoustid {} \; > > # > > > > And yet, ufed says: > > ( ) osdmenu | + |Li|(media-video/mplayer) Blah > > ( ) acoustid | + |Li|(media-sound/picard) Bleh > > Ah, a detail to add to the documentation. The middle column is what > package.use and the ebuilds think is necessary: > > # grep -m 1 "osdmenu" > /usr/portage/media-video/mplayer/mplayer-1.1-r1.ebuild > +network nut openal +opengl +osdmenu oss png pnm pulseaudio pvr +quicktime > > # grep -m 1 "acoustid" /usr/portage/media-sound/picard/picard-1.1.ebuild > IUSE="+acoustid +cdda +ffmpeg nls" > > You see? Both ebuilds set the flag by default, so the '+' in the P column is > correct, because you have these packages installed. This is the first time I noticed there are not just "flags" and "-flags" in IUSE, but also "+flags". What is the point of the "+" there? I can't seem to find and answer. And this answer might be important for this context - I don't understand why we need to see in ufed what IUSE thinks. Ufed tells me that I have a package relevant to this flag installed and tells me what the flag does. That's all I need to know. When I have the description and decide I want to enable/disable it, I ignore IUSE anyway. When I don't know if I explicitly want/don't want the flag, I'll just leave it up to some defaults and in that case I don't care what those defaults are. By the way, shouldn't the "P" column be dedicated to IUSE only? Since package.use override make.conf for special cases, their settings should probably also override make.conf's column in ufed (i.e., the "C" column). > > Another thing: take the global flag "oss". I have it '-oss' in make.conf. > > When I add 'app-emulation/wine oss' into /etc/portage/package.use, nothing > > changes about the way the flag is presented in ufed - no sign of the fact > > that I have the flag enabled for wine. I think that as long as the > > package.use are taken into consideration, this situation should be projected > > in ufed. > > Well, wine does not have an individual meaning of this use flag, which means > it has no individual line in use.local.desc. Therefore wine does not have a > line displayed in ufed where the '+' could be displayed. > > I still have no idea how to display these "affected" packages without > exploding the list of displayed lines in ufed. I think it is an important > information, but just use "doc" as an example: > > # grep -c " doc" /etc/portage/package.use > 86 > > So I'd need 86 (or 18 if one line lists up to five packages) extra lines > just to represent the packages that do not listen to "doc" which I do not > enable in make.conf, (*) Listing 86 of them would be terrible, but that's not what I'm asking for. I think the "oss" flag from the example above justifies wine's presence in the list because wine has this flag (un)set explicitly. The flag may be used by another 50 packages, but none of them has this flag set any different from make.conf or the default. So by not listing them the user loses no information about her settings. But when wine is omitted, something relevant about my USE flag settings is concealed. Else, the "P" column would have to be introduced as functioning for local flags only. If you decided to keep the "P" column to show all +/- IUSE flags, there might be additional overhead here. In case "doc" were explicitly + or - in make.conf, then you really only need to list those of the 86 packages that either have "doc" as local or have it set differently in package.use. No information is lost. But if "doc" were not set in make.conf, then it might be in order to mention those packages whose IUSE sets "doc" differently from what "doc" has in the "D" column. If this list of packages were missing, the user would have to be told that the "P" column only tells about those packages that have "doc" as local and, of course, the "D" column only says what the single global default is. In fact, personally, I never had any use for the "D" column - for the same reason I have no need for IUSE, as explained above. ---- By the way, the "gdbm", "berkdb" and some other flags have a grey (+). Just mentioning it FYI; don't know what it means. ---- A minor buggie: when I'm in the [ normal / global / installed ] mode, the scrollbar to the right of the descriptions sometimes scrolls as a "#" sign and sometimes as a "##" double-sign. There are a few hundred items on the list at that time. I suppose that's not an issue (and is caused by ncurses on top of that, probably); I'll just put this note down for you. ---- So since ufed now reads IUSE from /var/db/pkg, can I rely on the [ normal / global / installed ] mode to show me all global flags that are used by at least one installed package? Where "used" means that the flags are mentioned in IUSE as "flags", "+flags" or "-flags". If ufed does work this way, it's super-cool. ---- I agree it is about time for an -rc. As for my personal user-ish needs, I don't use the "P"-IUSE thing, so I'm fine with it functioning any way it might function at any moment. In any case, the documentation should probably be in good shape before ufed leaves -9999, because there's a lot of new stuff. It could be helpful to ask somebody who hasn't been following this and other bugs to try out the finished -rc, read the manpage and share their opinion about the it (and the shiny new -rc too :) ).
In fact, please ignore the last paragraph. I once received a task at work to update our IS documentation. Ever since I have nightmares about documentation from time to time. It's probably OK to just let the users of the -rc comment on the manpage, should they feel like it. I admit I haven't read the manpage yet.:) Maybe I'll get to it too.
(In reply to comment #45) > This is the first time I noticed there are not just "flags" and "-flags" in > IUSE, but also "+flags". What is the point of the "+" there? I can't seem to It can be either "flag" (present) or "+flag" (present and enabled by default). So if you do not set flag "foo" anywhere, and it is listed in IUSE as "foo" in the ebuild, the package will be emerged with disabled "foo". But if it is listed in IUSE as "+foo", then it will be enabled by default. > don't understand why we need to see in ufed what IUSE thinks. Ufed tells me Because it is the package default. You do not need to set a use flag for a package that already enables it all by itself. The down side is, that ufed can not possibly parse all ebuilds and therefore has to be restricted to the information of installed packages. But I guess that is okay, as it (at least) helps you clean up your make.conf once in a while. > By the way, shouldn't the "P" column be dedicated to IUSE only? Since > package.use override make.conf for special cases, their settings should > probably also override make.conf's column in ufed (i.e., the "C" column). I have to think about this one. The IUSE information is only available for installed packages. And only /etc/portage/package.use overrides make.conf. The profile versions don't IIRC. Maybe it would be better and even clearer, if the [P]ackage column is made up from /etc/portage/make.profile/(and all parents)/package.use and IUSE from installed packages. And the [C]onfiguration column is made up from make.conf - overridden by the users package.use. The first will be system specific content in 'P', and user specific content in 'C'. > Listing 86 of them would be terrible, but that's not what I'm asking for. I > think the "oss" flag from the example above justifies wine's presence in the > list because wine has this flag (un)set explicitly. The flag may be used by > another 50 packages, but none of them has this flag set any different from > make.conf or the default. So by not listing them the user loses no > information about her settings. But when wine is omitted, something relevant > about my USE flag settings is concealed. Else, the "P" column would have to > be introduced as functioning for local flags only. Yes, you a right. This is the best idea about how to handle "affected" packages right now. I have thought of numerous ways and get back to this limiting one every time. But I never thought up such a good explanation. Thank you! > By the way, the "gdbm", "berkdb" and some other flags have a grey (+). Just > mentioning it FYI; don't know what it means. This is the default behavior of ufed. It got lost during the data restructuring. If you do not set a flag in make.conf, the flag is preceded with round brackets showing its current default. I just thought the gray would make it better recognizable than just having different types of brackets. (Square if you set a flag in make.conf) > A minor buggie: when I'm in the [ normal / global / installed ] mode, the > scrollbar to the right of the descriptions sometimes scrolls as a "#" sign > and sometimes as a "##" double-sign. There are a few hundred items on the > list at that time. I suppose that's not an issue (and is caused by ncurses > on top of that, probably); I'll just put this note down for you. Well, the limitation of integers... ;) > So since ufed now reads IUSE from /var/db/pkg, can I rely on the [ normal / > global / installed ] mode to show me all global flags that are used by at > least one installed package? Where "used" means that the flags are mentioned > in IUSE as "flags", "+flags" or "-flags". If ufed does work this way, it's > super-cool. Yes, you can. When parsing IUSE, the global descriptions (if present) of the listed flags get marked as "installed". (In reply to comment #46) > Ever since I have nightmares about documentation from time to time. I know *exactly* what you are talking about. *sigh*
(In reply to comment #47) > (In reply to comment #45) > > This is the first time I noticed there are not just "flags" and "-flags" in > > IUSE, but also "+flags". What is the point of the "+" there? I can't seem to > > It can be either "flag" (present) or "+flag" (present and enabled by > default). > > So if you do not set flag "foo" anywhere, and it is listed in IUSE as "foo" > in the ebuild, the package will be emerged with disabled "foo". But if it is > listed in IUSE as "+foo", then it will be enabled by default. OK. This is not a matter of ufed, but I still don't see the need for three types (flag, +flag, -flag). If there were just the good old regular "flag" and "-flag", the effect would be the same - if I understand your explanation correctly, there is no difference between how "flag" and "-flag" affect everything around. > Maybe it would be better and even clearer, if the [P]ackage column is made > up from /etc/portage/make.profile/(and all parents)/package.use and IUSE > from installed packages. And the [C]onfiguration column is made up from > make.conf - overridden by the users package.use. > The first will be system specific content in 'P', and user specific content > in 'C'. That's good reasoning, OK. OK to eveything else too.
On a second look, I dislike the grey color in the (+) and (-). A grey (+) is OK, but a grey (-) is invisible. The ()/[] brackets are a vivid enough difference, I think. Have you considered switching to GPL3? I don't know what the difference is between v2 and v3, but lots of folks seem to like v3... Idea: in the bottom help-line, s/Return\/Enter/Enter/ && s/Mask/Mask\/Forced/. Also, I can toggle "(+multilib)" +/-/ arbitrarily. I think forced flags should have the same toggle-ability as masked flags: allow removing the toggle, deny applying a toggle. This may be coming late, but I just realized that the syntax of "(maskedflag)" and "(+forcedflag)" doesn't comply with official tools which use "(-maskedflag)" and "(forcedflag)". This also corresponds to the way positivity/negativity of setting exists in make.conf. man ufed, line 49, 50: s/affected/something_more_explanative/ I suggest moving the section "What are USE flags?" before "Navigation and control". Also, please consider adding into the manpage: that use flags are stored in make.conf; what are global/local flags and where they are defined; possibility of customization through /etc/portage/package.use (but that that doesn't make flags local).
Sorry for the delay. I have been sick the last few days and needed to catch up at work yesterday, first. However, I had the opportunity to talk to a friend of mine about ufed. He is a software developer, too, but does not use Gentoo (Debian fan), so I had to explain what use flags are, first. Nice thing to sort the own mind... We came up with the following solution to get the display a lot more detailed and a lot less confusing. Column 'D': This is the "Default" column. Everything listed here is enabled/disabled by default (profiles make.defaults and/or default enabling via IUSE - further masked and forced flags, see below.) Column 'P': This is the [P]rofiles [P]ackage settings, meaning the found package.use files in the users profiles path. Column 'C': This is the [C]onfiguration column. The settings in here come from the users make.conf and are overridden by the users package.use file. Column 'M': This was overkill and is gone. Flag [m]asking and en[f]orcing is now represented in the 'D' column, as both express a (strong) default. (In reply to comment #49) > On a second look, I dislike the grey color in the (+) and (-). A grey (+) is > OK, but a grey (-) is invisible. The ()/[] brackets are a vivid enough > difference, I think. Yes, you are right. Actually it is black. But ncurses draws it gray because I set it to be bold (A_BOLD). Now it's black again. > > Have you considered switching to GPL3? I don't know what the difference is > between v2 and v3, but lots of folks seem to like v3... Well it is a Gentoo product. I do not know whether I can change the license model... > > Idea: in the bottom help-line, s/Return\/Enter/Enter/ && > s/Mask/Mask\/Forced/. Good idea, I have postponed deciding about the help line design until the real functionality is done. Further I'd like to reorder the function keys. Local/Global and Installed/Not installed are probably of a lot more interest to most users than seeing what masked/forced flags exist. > > Also, I can toggle "(+multilib)" +/-/ arbitrarily. I think forced flags > should have the same toggle-ability as masked flags: allow removing the > toggle, deny applying a toggle. Damn. I thought I fixed that... hang on... Ok, fixed and pushed. > > This may be coming late, but I just realized that the syntax of > "(maskedflag)" and "(+forcedflag)" doesn't comply with official tools which > use "(-maskedflag)" and "(forcedflag)". This also corresponds to the way > positivity/negativity of setting exists in make.conf. You are absolutely right, I should have seen this myself. Fixed and pushed. > > man ufed, line 49, 50: s/affected/something_more_explanative/ > > I suggest moving the section "What are USE flags?" before "Navigation and > control". Yes, good idea. > > Also, please consider adding into the manpage: that use flags are stored in > make.conf; what are global/local flags and where they are defined; > possibility of customization through /etc/portage/package.use (but that that > doesn't make flags local). I'll do that. I have to update the documentation thoroughly anyway. Thank you very much for your feedback!
That's nice logic for the columns, too. Please, let us know when the docs and everything is finished (I'm still on -9999 which overrides everything else).
I mean, I tried the latest -9999 and it looks OK. I'm reverting to ~arch ufed. Am I hearing v1.0 in the distance? :)
I just hit this: USE setting in make.defaults overrides ebuild-specific IUSE defaults (man make.conf, description of USE_ORDER). That's interesting. I don't have -9999 anymore to check this - does ufed reflect this precedence in the "D" column?
(In reply to comment #53) > I just hit this: USE setting in make.defaults overrides ebuild-specific IUSE > defaults (man make.conf, description of USE_ORDER). That's interesting. I > don't have -9999 anymore to check this - does ufed reflect this precedence > in the "D" column? Actually it is the other way round right now. USE_ORDER is (and always was) read, but only it is only checked to see whether the configuration is valid. I'll add usage of this list to correct the overriding of the settings.
(In reply to comment #54) > (In reply to comment #53) > > I just hit this: USE setting in make.defaults overrides ebuild-specific IUSE > > defaults (man make.conf, description of USE_ORDER). That's interesting. I > > don't have -9999 anymore to check this - does ufed reflect this precedence > > in the "D" column? > > Actually it is the other way round right now. USE_ORDER is (and always was) > read, but only it is only checked to see whether the configuration is valid. > I'll add usage of this list to correct the overriding of the settings. $BEGIN$ I don't understand, but I suppose you understand the business. As regards the manpage, if it says something wrong - such as that make.defaults overrides IUSE - a bug should be filed. I'm not filing it, because GOTO($BEGIN$).
(In reply to comment #55) > (In reply to comment #54) > > (In reply to comment #53) > > > I just hit this: USE setting in make.defaults overrides ebuild-specific IUSE > > > defaults (man make.conf, description of USE_ORDER). That's interesting. I > > > don't have -9999 anymore to check this - does ufed reflect this precedence > > > in the "D" column? > > > > Actually it is the other way round right now. USE_ORDER is (and always was) > > read, but only it is only checked to see whether the configuration is valid. > > I'll add usage of this list to correct the overriding of the settings. > > $BEGIN$ I don't understand, but I suppose you understand the business. As > regards the manpage, if it says something wrong - such as that make.defaults > overrides IUSE - a bug should be filed. I'm not filing it, because > GOTO($BEGIN$). *hrhr* Sorry about that. What I meant is, that ufed-9999 currently overwrites the make.defaults settings with IUSE settings in the interface. But you are right, according to the man page it should be the other way round.
I wanted to check out GIT once more, but ufed doesn't even run: # ufed Type of arg 1 to keys must be hash or array (not hash element) at /usr/share/ufed/Portage.pm line 950, near "}) " Type of arg 1 to keys must be hash or array (not hash element) at /usr/share/ufed/Portage.pm line 960, near "}) " Compilation failed in require at /usr/sbin/ufed line 10. BEGIN failed--compilation aborted at /usr/sbin/ufed line 10. I'll take a look at the manpage.
(In reply to comment #57) > I wanted to check out GIT once more, but ufed doesn't even run: > > # ufed > Type of arg 1 to keys must be hash or array (not hash element) at > /usr/share/ufed/Portage.pm line 950, near "}) " > Type of arg 1 to keys must be hash or array (not hash element) at > /usr/share/ufed/Portage.pm line 960, near "}) " > Compilation failed in require at /usr/sbin/ufed line 10. > BEGIN failed--compilation aborted at /usr/sbin/ufed line 10. That's odd. I test everything before I push my commits, and this version of ufed just starts fine on my system. I guess it has something to do with my perl version (5.16.2) and it doing an automatic conversion that previous versions didn't do. The specific parts have been changed to use a more conservative approach. It is just pushed and should work now. > > I'll take a look at the manpage. Thank you very much!
Ufed starts OK now. I use perl 5.12-4-r1. When I enter help with '?', then exit with a double-Esc and then press PgUp, ufed asks "Cancel?". F8 (description order toggle) doesn't work. On a 80x25 terminal, the bottom help-line has F7 and F8 missing completely. The line probably cannot be shortened enough, but consider s/Toggle : /Toggles (F5-F8): /, so that the 80x25 people know to look for something more than just F5 and F6.
(In reply to comment #59) > Ufed starts OK now. I use perl 5.12-4-r1. > > When I enter help with '?', then exit with a double-Esc and then press PgUp, > ufed asks "Cancel?". That is a curses issue. ESC is a key that starts a character sequence (see ncurses(3) man page, ESCDELAY) that is broke by the second escape hit. If you waited a second instead of hitting PgUp (or any other key), the "Cancel?" question would appear, too. > > F8 (description order toggle) doesn't work. It is F9 now, because F8 will be used for another filter later (Expanded values) > > On a 80x25 terminal, the bottom help-line has F7 and F8 missing completely. Yes, it has 119 characters right now (-->) > The line probably cannot be shortened enough, but consider s/Toggle : > /Toggles (F5-F8): /, so that the 80x25 people know to look for something > more than just F5 and F6. (<--) and I thought about splitting it into two lines, and for that remove the (additional) horizontal line under the title. The main display is encased in a box anyway.
OK. As for the manpage, I think the section "What are global and local USE flags" needs a complete rephrase. Here's a proposal: --- Global USE flags are called such because they represent functionality that is found in a wider variety of packages. For example, the global flag "cjk" is about adding / not adding support for Eastern-Asian languages, which obviously affects a multitude of various packages. Global flags are defined in /usr/portage/profiles/use.desc. Local USE flags are unique package-wise, because the functionality they stand for is only found in that particular package and no other. See /usr/portage/profiles/use.local.desc for a full, per-package listing of all local USE flags. It still happens that a flag which is defined as global is also defined as local for one or more packages. That is because the general definition of the global flag takes on specialized semantics in some particular package. It also occurs that multiple packages define a local flag of the same name - the meaning of the flag differs, however, for each package. --- If you don't like the length of it all, drop the last paragraph.
ufed.8, line 73-74: s/it can be masked, making it impossible to select/it is "masked", and it is impossible to select it/. And an analogous flip for forced flags below. line 6: s/DESCRIPTION/INTRODUCTION/ and a new .SH section for the "Navigation and control" and "Display layout" subsections. l 95: s/.*/F5: Toggle display of local / global / all flag descriptions./ l 97-98: s/.*/F6: Toggle display of flags supported by at least one installed package / supported by no installed package / all flags./ l 100: s/.*/F7: Toggle display of masked and forced flags / flags that are neither masked nor forced / all flags./ l 108: s/make this permanent/save your USE flag setup to make.conf/. l 118-120: this paragraph -> to the beginning of the "Navigation and control" section (prepend to the existing first paragraph there). l 125: s/.*/Each line takes the following form:/. l 131: append to the end of the paragraph: "Flags marked as [+] or [-] are those that will be saved in your make.conf when you leave the program with an Enter." l 133: surround this paragraph with another set of ".br"s (I suppose .br is like <br />). l 136: s/make.defaults/\/usr/\portage\/profiles/\...\/make.defaults/. l 137: s/packages./packages (the IUSE variable)./. Also specify, which takes precedence (IUSE/make.defaults). l 139: s/package.use//usr/\portage\/profiles/\...\/package.use/. l 143: Also specify precedence. l 144: add another .br just below this line. l 145-146: s/package specific descriptions have an 'L' for "local"./local flag descriptions have an 'L' here./. l 151: add another .br just below this line. l 158: s/in that file(s)/on that level/; also two other appearances in that paragraph. --- The manpage doesn't mention the '?' key and its role. I don't consider it a problem, but maybe you didn't omit it on purpose. --- BTW, I'm not checking grammar+spelling; I see you're already looking for a native speaker to do the task.
Bah, I failed to \-escape some of the slashes there. But you'll know what I mean.:)
(In reply to comment #63) > Bah, I failed to \-escape some of the slashes there. But you'll know what I > mean.:) Done, with only slight changes. I hope you like it. ;) I haven't found any issues in the last week, so I will update the help text in the program to contain the same information as the man page. The resulting commit should then be fine for a release candidate.
Great, I'm going back to ~arch ufed.
It might be a good idea to try to push ufed into pkg_postinst() of gentoolkit. It currently prints a list of some app-portage/ stuff as further suggestions, but something like ufed is missing desperately. Ufed might also look nice even in the Handbook. The docs people would have to agree, but...
(In reply to comment #66) > It might be a good idea to try to push ufed into pkg_postinst() of > gentoolkit. It currently prints a list of some app-portage/ stuff as further > suggestions, but something like ufed is missing desperately. > > Ufed might also look nice even in the Handbook. The docs people would have > to agree, but... Yes, I'd like more advertisment for ufed. ;) I have just pushed the last commit for the first release candidate. The keys are now on two lines, and everything fits now into a 80x25 console.
OK, I'm leaving this one be. I'll meet you at the ~arch version.
As the 0.90_rc1 version, that has everything discussed here included, is in the tree now, I am closing this overly long bug discussion.
