At this very moment: repoman full in kde-base/klatin reports: DEPEND.badmasked 2 kde-base/klatin/klatin-3.4.0_rc1.ebuild: ~x86 ['~kde-base/libkdeedu-3.4.0_rc1'] kde-base/klatin/klatin-3.4.0_rc1.ebuild: ~amd64 ['~kde-base/libkdeedu-3.4.0_rc1'] However, we can see: $ grep klatin ../../profiles/package.mask =kde-base/klatin-3.4.0_rc1* Since pretty much by definition, if something is mentioned in package.mask, it is already known to be broken and since reporting broken deps for these packages simply complicates the repoman report, I request that repoman not report repoman issues for ebuilds mentioned in package.mask. Portage 2.0.51.19 (default-linux/x86/2004.0, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.4.28 i686) ================================================================= System uname: 2.4.28 i686 AMD Athlon(tm) Processor Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 12 2005, 16:43:55)] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.7.9-r1, 1.5, 1.4_p6, 1.6.3, 1.9.4, 1.8.5-r3 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4, 1.3.5 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=i686 -O3 -pipe -Wall" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/X11/app-defaults /etc/X11/rstart /etc/X11/serverconfig /etc/X11/starthere /etc/X11/xdm /etc/bash_completion /etc/gconf /etc/init.d /etc/pango /etc/sound/events /etc/ssmtp /etc/terminfo /usr/X11R6/lib/X11/xkb /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache cvs distcc distlocks sandbox sfperms" GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="C" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/home/msterret/gentoo-x86" PORTDIR_OVERLAY="/home/msterret/src/portage-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X apm arts avi bash-completion berkdb bitmap-fonts cdr crypt cscope cups curl divx4linux dvd encode esd fam flac font-server foomaticdb gdbm gif gimpprint gnome gpm gstreamer gtk gtk2 guile imagemagick java jpeg libg++ libwww live mad mikmod mmx mmx2 mozilla moznocompose moznoirc moznomail mp3 mpeg nas ncurses nomotif noreiserfs nvidia oggvorbis opengl oss pam pcre pdflib perl png ppds python quicktime readline real sdl spell sqlite sse ssl tcpd tiff truetype truetype-fonts type1-fonts userlocales xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
B0rken again in 2.1 dev-libs/luabind is masked, yet repoman full in that directory reports the broken deps (that are the reason the package is masked in the first place).
(In reply to comment #3) > dev-libs/luabind is masked, yet repoman full in that directory reports the > broken deps (that are the reason the package is masked in the first place). There's some code in repoman that forces the --include-masked option when repoman is run in a package directory (level 3): if repolevel == 3 and "--include-masked" not in myoptions: myoptions.append("--include-masked") I'm not sure about the reason for this logic. The same code exists in 2.0.54 though, so apparently it's not a regression in 2.1.
The main reason for not reporting on masked package issues was due to the amount of noise at category and tree levels. I don't mind having the package-level logic removed but I'd suggest a short option for --include-masked or repoman'ing masked packages will become a huge PITA.
How useful is it to have something in the tree if it's dependencies can't be satisified? From my perspective, it should be punted immediately. I'd say that the safest route would be to invert the existing option and have a --ignore-masked feature instead. That will reduce the likelyhood that QA issues in a masked package will go accidentally unnoticed.
Meaning invert the logic _and_ pull the per-package check, right? Yeah, I'd be happy with that too. There are only a handful of people that do category or tree checks so there shouldn't be much of an issue.
The --include-masked option has been replaced with a --ignore-masked option (-i for short) in svn r3496.
Sounds good to me.
This has been released in 2.1.1_pre1.