This has been broken since May. If I once had a utility installed, I expect it to be there when I go looking for it. If I'm expected to set new USE flags, I expect that whoever made this change would give sufficient heads up, preferably via einfo on sysvinit or a news item... and/or force the USE flag to on initially (until people decide to turn that flag on/off themselves). Missing mesg/wall on multiple machines really feels to me like a major QA failure, but hey, I might be wrong in my expectation that things on my systems won't just disappear without notice. Portage 2.2.1 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.16.0, 3.10.4-Deco x86_64) ================================================================= System uname: Linux-3.10.4-Deco-x86_64-Intel-R-_Core-TM-_i5-2400S_CPU_@_2.50GHz-with-gentoo-2.2 KiB Mem: 32980960 total, 18539880 free KiB Swap: 4589552 total, 4587684 free Timestamp of tree: Thu, 05 Sep 2013 02:45:01 +0000 ld GNU ld (GNU Binutils) 2.23.2 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5-r2, 3.2.5-r2, 3.3.2-r2 dev-util/cmake: 2.8.11.1 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.6, 1.13.4, 1.14 sys-devel/binutils: 2.23.2 sys-devel/gcc: 4.3.6-r1, 4.6.4, 4.7.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.11 (virtual/os-headers) sys-libs/glibc: 2.16.0 Repositories: gentoo hardened-dev matsuu isohunt-overlay local perl-gcpan ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native -g" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /var/spool/munin-async/.ssh" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=native -g" DISTDIR="/home/gentoo/distfiles/" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://gentoo.mirrors.easynews.com/linux/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j10" PKGDIR="/home/gentoo/packages/build-native" 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="/dev/shm" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/hardened-development /var/lib/layman/matsuu /usr/local/ih-portage /usr/local/portage /usr/local/g-cpan" SYNC="rsync://b01.yyz.as30085.net/gentoo-portage" USE="acl acpi adns aio amd64 apache2 apm ares aspell audit avahi bash-completion berkdb bzip2 ccache cgi cli cracklib crypt curl cvs cxx dbus device-mapper dri efiemu eix expat fam fftw fortran fpm fuse gd gdbm geoip git gpg hal hpn hwdb iconv idn imagemagick injection inotify iproute2 ipv6 jabber jpeg jpeg2k libevent libnl lua lzma lzo madwifi mercurial mhash mmap mmx mod_wsgi modules mount mudflap multilib mysql ncurses network-cron nls nptl ntfsprogs ntp objc objc++ objc-gc offensive openmp pam pcre perl php png profiling pygments python python2 readline rrdtool samba session smi soap sql sqlite sqlite3 sse sse2 ssh ssl subversion sudo suid syslog tcpd threads unicode urandom vim-pager vim-syntax xattr xext xinetd xmlrpc yaml zeroconf zlib" ABI_X86="64" 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" 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" APACHE2_MPMS="event" 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" GRUB_PLATFORMS="efi-32 efi-64 pc" 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="pypy2_0 python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" 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" USE_PYTHON="2.7 2.7-pypy-2.0 3.2" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
See ChangeLog entry for sysvinit-2.88-r5. I'd say INVALID.
So get the latest sys-apps/util-linux with the latest sys-apps/sysvinit? Mixing the stable and unstable branches is not supported.
Except I have the unstable versions of both. IF you'd read the summary, the issue is that USE flags changes were necessary to get 2 utilities re-installed after they'd been silently removed.
(In reply to Rafał Mużyło from comment #1) > See ChangeLog entry for sysvinit-2.88-r5. > > I'd say INVALID. *sysvinit-2.88-r5 (04 May 2013) 04 May 2013; Mike Frysinger <vapier@gentoo.org> +files/sysvinit-2.88-shutdown-h.patch, +sysvinit-2.88-r5.ebuild, sysvinit-2.88-r4.ebuild: Make shutdown -h work the same as other inits #449354 by David Weber. Stop installing mesg/wall as util-linux installs them now #468144 by Samuli Suominen. Where in that Changelog entry is there mention of "tty-helpers"?
Well, it's IUSE=+tty-helpers so they get installed by default. emerge prints USE flag changes so when it was newly introduced and disabled, you should have noticed that. What bug is here to fix?
(In reply to Jeroen Roovers from comment #5) > Well, it's IUSE=+tty-helpers so they get installed by default. Just a minor catch - that change is about two days old. Before that, it wasn't on by default.
(In reply to Jeroen Roovers from comment #5) > Well, it's IUSE=+tty-helpers so they get installed by default. emerge prints > USE flag changes so when it was newly introduced and disabled, you should > have noticed that. What bug is here to fix? ^ that change took place at my request roughly 7 minutes before I filed this bug. That change took place so that unsuspecting users in the community might actually get their mesg/wall/write back without knowing it was gone. I have checked deeply and have failed to find any mention of tty-helpers in util-linux or sysvinit's ChangeLog, no einfo/ewarn, no mention on gentoo-dev@l.g.o and no news items explaining the change. I find this curious, as I was under the impression it was bad form to silently break user's systems. Jer: I appreciate that in your line of work as a bug-wrangler you're faced with an ocean of idiots, and because of that, I don't take offense at you calling me one. In the future, if you'd like to come off slightly less combative sounding, perhaps you could try forming your allegations of idiocy into a question? For instance: "Are you mixing the stable and unstable branches? If you are, that's not supported." Of course, you can easily see from my emerge --info output that I'm not, that is, unless the meaning of ACCEPT_KEYWORDS="~amd64" has somehow changed recently. If it has, I'd be happy to remove the 'amd64 ' from my ACCEPT_KEYWORDS, though I'm pretty sure that behaviorally, portage is honoring my ~arch wishes. As of the filing of this bug, on the systems negatively impacted I was running sys-apps/sysvinit-2.88-r5 and sys-apps/util-linux-2.23.2. I covered the bit about lack of output/notice earlier, so I won't reiterate. Thankfully, I'm not an idiot, and I was able to figure out fairly quickly what had happened, but that doesn't magically make silently breaking systems an acceptable practice. Does the average user spend much time poking around in /usr/portage? Enough to know what they're looking at/for? The reasoning behind this bug is twofold: 1: That I, as a user, had to bitch in a very annoying manner at someone who didn't deserve it in order for the community's systems to be put back the way they were prior to the undocumented removal of 3 utilities by USE flag change. As an aside... bug #468144 didn't have any reference on the bug page itself to USE=tty-helpers either until just now. 2: This isn't the first time that systems I manage have been silently (no notice/announce/news/email/e(info|warn)/ChangeLog) changed by the same developer who is responsible for this bug. At this point, it'd be nice if someone from devrel or QA had a conversation with the developer and explained that their behavior isn't acceptable. Acting in this manner is damaging to user confidence and to Gentoo's reputation. So from now on every time this developer does something that silently breaks one of my machines I'll be filing a bug for the benefit of the community. I apologize in advance, Jer and bug-wranglers.
imo, making things +tty-helpers is wrong. these tools are esoteric cruft that the majority of people don't care about. and they're set*id. we can add elog to the sysvinit and util-linux ebuilds, but i plan on reverting the IUSE=+tty-helpers change.
Commit message: Note that sys-apps/util-linux now carry many tools http://sources.gentoo.org/sys-apps/sysvinit/sysvinit-2.88-r5.ebuild?r1=1.3&r2=1.4
should be all set now in the tree; thanks for the report! Commit message: Re-disable USE=tty-helpers by default and add an elog http://sources.gentoo.org/sys-apps/util-linux/util-linux-2.23.2-r2.ebuild?rev=1.1
(In reply to Allen Parker from comment #7) > (In reply to Jeroen Roovers from comment #5) > > emerge prints USE flag changes so when it was newly introduced and > > disabled, you should have noticed that. What bug is here to fix? This. > I have checked deeply and have failed to find any mention of tty-helpers in > util-linux or sysvinit's ChangeLog, no einfo/ewarn, no mention on > gentoo-dev@l.g.o and no news items explaining the change. I find this > curious, as I was under the impression it was bad form to silently break > user's systems. > 2: This isn't the first time that systems I manage have been silently (no > notice/announce/news/email/e(info|warn)/ChangeLog) changed by the same > developer who is responsible for this bug. At this point, it'd be nice if > someone from devrel or QA had a conversation with the developer and > explained that their behavior isn't acceptable. Acting in this manner is > damaging to user confidence and to Gentoo's reputation. So from now on every > time this developer does something that silently breaks one of my machines > I'll be filing a bug for the benefit of the community. I apologize in > advance, Jer and bug-wranglers. PMFJI, but... It definitely wasn't silently. Gentoo has always recommended doing an emerge --pretend (or --ask) before doing an upgrade, and investigating anything that looks like it might need configuration changes. As JR mentions, portage prints USE flag changes, even in *COLOR* by default so they're harder to miss, and any responsible gentooer should know to investigate them. As I did when I saw that change come by and the new tty-helpers flag. A quick equery uses util-linux told me exactly what I needed to know, that I didn't need the flag on since I don't use that functionality. If it was "silently", how could I have seen the USE flag changes, and from that, done what any /responsible/ gentoo sysadmin would do when he's unsure what a flag change does, and go from there. If it was silently I obviously couldn't have done that. So, it certainly wasn't silently. It was using the normal method of notification of USE flag changes built into gentoo, that any responsible gentooer who cares about his/her systems knows to pay attention to. The same normal tools that I, as any responsible gentoo sysadmin would, took advantage of to see and investigate the change BEFORE I actually installed. Given that, I believe you owe the devs an apology for raking them over the coals, threatening QA, etc, for nothing. It was *YOUR* mistake, not theirs. Certainly we all make mistakes and there's no shame in that, but when you're heatedly blaming someone else for your mistake, even threatening QA, etc, then you really do need to apologize. The notice was there in the form of changed USE flags all along, for those who cared enough about the wellbeing of their systems to look. Meanwhile, you're running ~arch. If you can't even deal with a changed USE flag in a reasonable way, what are you going to do when something REALLY breaks. It doesn't happen very often, but in the decade I've been running ~arch on gentoo, I've had both bash and glibc, among other things, die on me due to bad ~arch updates. Try running your system with a bad glibc! That sort of thing /happens/ occasionally on ~arch, and if you're running it, you really should be prepared for it. But you can't even notice a routine change of a USE flag nor apparently do you know how to deal with it, and start irrationally raking the devs over the coals for it, so how are you going to deal with REAL breakage? In light of that I'd suggest a reevaluation of your ~arch decision, and perhaps, even a reevaluation of whether gentoo's the right distro for you, if you can't even handle gentoo basics such as USE flag changes. Gentoo's not a hand-holding distro and it never was. There's other distros if that's what you want/need. There's no shame in deciding Gentoo's not the distro for you. Alternatively, stick with gentoo and learn to work /with/ the tools, not /fight/ them. There's plenty of documentation available for doing so, but you do have to actually spend a bit of time reading it.
That's a great idea, Duncan, blame the user. In your decade, have the QA rules changed any with regards to removing something from people's systems without giving them prior notice, because I'm pretty sure that even though they're not being applied in this case, they still exist.
the issue is fixed. debating intermediate points doesn't really accomplish anything.
