EAPI=2 support in kde4*.eclass was SUDDENLY removed few days ago breaking up numerous things in various overlays (including at least two ebuilds in sunrise: kde-misc/dikt and media-video/qnapi), without any deprecation warnings or any public notification (read: eselect news) prior this event [1]. I'm asking developers to revert this changes proceed with normal deprecation procedures. This is QA bug, is suppose. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-functions.eclass?logsort=cvs&r1=text&r2=text&tr1=1.45&tr2=1.44&view=patch Emerge info: Portage 2.2.0_alpha29 (default/linux/amd64/10.0/desktop, gcc-4.5.2, glibc-2.13-r2, 2.6.38-gentoo-r1-nord-oss-2.24 x86_64) ================================================================= System uname: Linux-2.6.38-gentoo-r1-nord-oss-2.24-x86_64-Intel-R-_Core-TM-2_Duo_CPU_T6600_@_2.20GHz-with-gentoo-2.0.2 Timestamp of tree: Wed, 06 Apr 2011 22:45:01 +0000 app-shells/bash: 4.2_p8 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r2, 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.4 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.0 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2, 4.6.0 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 virtual/os-headers: 2.6.38 (sys-kernel/linux-headers) Repositories: gentoo rion enlightenment-niifaq niifaq sunrise x11 gamerlay-stable java-overlay kde-sunset local Installed sets: @enlightenment-all ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native -mtune=native -msse4.1 -floop-interchange -floop-strip-mine -floop-block -floop-parallelize-all -fgraphite-identity" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=native -mtune=native -msse4.1 -floop-interchange -floop-strip-mine -floop-block -floop-parallelize-all -fgraphite-identity" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--keep-going --jobs=2" FEATURES="assume-digests binpkg-logs candy distlocks fixlafiles fixpackages metadata-transfer news noinfo parallel-fetch preserve-libs protect-owned sandbox sfperms split-log splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="ru_RU.UTF-8" LC_ALL="" LDFLAGS="-Wl,--as-needed -Wl,--sort-common -Wl,-O1 -Wl,--hash-style=gnu" LINGUAS="ru" MAKEOPTS="-j2" 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="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/rion /var/lib/layman/enlightenment-niifaq /var/lib/layman/niifaq /var/lib/layman/sunrise /var/lib/layman/x11 /var/lib/layman/gamerlay /var/lib/layman/java-overlay /var/lib/layman/kde-sunset /usr/local/portage" SYNC="rsync://rsync.niifaq.ru/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gdu gif gpm iconv idn ipv6 jpeg lcms ldap libnotify mad mikmod mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pango pcre pdf perl png policykit ppds pppd python qt3support qt4 readline sdl session spell sse sse2 ssl ssse3 startup-notification svg sysfs tcpd threads tiff truetype udev unicode usb vim vim-syntax vorbis wicd x264 xcb xcomposite xml xorg xulrunner xv xvid zlib zsh-completion" ALSA_CARDS="hda-intel" 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" CAMERAS="adc65 agfa_cl20 aox ax203 barbie canon casio_qv clicksmart310 digigr8 digita dimagev dimera3500 directory enigma13 fuji gsmart300 hp215 iclick jamcam jd11 jl2005a jl2005c kodak_dc120 kodak_dc210 kodak_dc240 kodak_dc3200 kodak_ez200 konica konica_qm150 largan lg_gsm mars mustek panasonic_coolshot panasonic_dc1000 panasonic_dc1580 panasonic_l859 pccam300 pccam600 polaroid_pdc320 polaroid_pdc640 polaroid_pdc700 ptp2 ricoh ricoh_g3 samsung sierra sipix_blink sipix_blink2 sipix_web2 smal sonix sony_dscf1 sony_dscf55 soundvision spca50x sq905 st2205 stv0674 stv0680 sx330z template topfield toshiba_pdrm11" 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 synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru" NETBEANS_MODULES="apisupport harness ide nb cnd enterprise java dlight ergonomics identity profiler websvccommon" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" SANE_BACKENDS="net" USERLAND="GNU" VIDEO_CARDS="radeon r600" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Only thing that we as gentoo devs care about is main tree, specialy eapi support.
(In reply to comment #1) > Only thing that we as gentoo devs care about is main tree, specialy eapi > support. Saying this you state that you don't care for user's comfort. I think that Sunrise is overlay that we *must* care about, or we would make users feel that their efforts can be made useless at any moment by any Gentoo Dev. Also, doing something harmful without notifying others, including your colleagues, is a bad idea and out of common etiquette.
Giving that you are the one who done this change, I don't believe in your judgement, sorry. This is normal procedure in such cases that you should not judge your own actions. So I'm reopening bug until anyone from QA team who is not in KDE-team at same time will confirm this decision. BTW, other teams do deprecation warnings and notifications in their eclasses. Why kde-team is so different?
Sunrise is NOT important part of the gentoo. The only important part of the gentoo is gentoo-x86 main tree. The eclasses were in testing for 4 months in the overlay where we tested various overlays and pinged maintainers, nobody obviously cared enough for sunrise, sad but it is up to users. EAPI is and always were dropped from eclasses with obvious 4 months ewarn or whatever period when no hits were found in main tree, just check the history. I am not saying altering or dropping functions should have same approach, but eapi drop usually just requires the altering of the eapi number unless the maintainers of the named eclass want to be huge PITA, so i am perfectly happy with current approach. Btw so your packages got marked as not supported by the eclass and you found during world update, but they were not removed or silently changed like would happen with functional remove. So just bug overlays maintainers to get it fixed. Leaving reopened so someone else close it.
s/with obvious 4 months/without any obvious 4 months/
Also for the record QA don't enforce or overview any overlays. Usuall approach is that what is in overlay does not exist/bother us. It is like saying that we didn't bother to announce that we did some package move and suddenly some packages in your overlay have invalid dependencies.
QA is generally not concerned with changes in Portage breaking or affecting an overlay. It cannot be expected for a dev to check all packages in all overlays for compliance with changes in an eclass. Unless it breaks the main tree, it's not considered a break. Having said that, a deprecation warning would have been handy, but honestly would not have likely changed anything. Unless someone is actively checking their package, even in sunrise, no one would have noticed until the first time someone tried to emerge it after the deprecation warning. And since weren't talking an overlay, not the main tree, that may have been a while if at all in a reasonable amount of time. News is also not the appropriate place for notification of changes in an eclass. News is meant for vital information to users pertaining generally to changes in a package that could break the use of their install (ex. potential breakage from a new version of say GCC), not for ebuild development changes. Finally, the changes were announced in the gentoo-dev ML. Sunrise: A heads up to Sunrise never hurts, but generally things get fixed quick when something like this happens. It's part of the process. It can get annoying, but there really isn't a much better way to deal with it. QA: Re-closing bug. [1] http://www.gentoo.org/proj/en/glep/glep-0042.html
My turn: s/weren't/we are/
(In reply to comment #7) > Having said that, a deprecation warning would have been handy, but honestly > would not have likely changed anything. Unless someone is actively checking > their package, even in sunrise, no one would have noticed until the first time > someone tried to emerge it after the deprecation warning. It fails egencache, for example, or any other ebuild sourc'ing, including dependency checks. So, warnings would be noticed by users who added this ebuilds into sunrise as they are, probably, using them. > Finally, the changes were announced in the gentoo-dev ML. Yeah. And there were warnings into overlay. Not so much of "public announce" as for me... > Sunrise: A heads up to Sunrise never hurts, but generally things get fixed > quick when something like this happens. It's part of the process. It can get > annoying, but there really isn't a much better way to deal with it. There is. And there is a plenty of examples. > QA: Re-closing bug. Well, that's your decision, but, from user's point of view, such behaviour is not very stable-insuring, as overlays are the part of almost every user's system and their breakage has not so big difference in users' experience from main tree's breakage. And this is even worse, taking into account how simple and obvious was the way to prevent such situation.
The maintainers of each overlay are responsible to keep their overlays working and compatible with the main tree. If they don't want that, then can always maintain their own eclasses. It makes absolutely no sense to ask us to take care of any single overlay that might exist in this universe or any other parallel universe. This bug has nothing to do with QA. If your overlays are broken then you should complain to their maintainers not to the gentoo developers.
(In reply to comment #9) > (In reply to comment #7) > > Having said that, a deprecation warning would have been handy, but honestly > > would not have likely changed anything. Unless someone is actively checking > > their package, even in sunrise, no one would have noticed until the first time > > someone tried to emerge it after the deprecation warning. > It fails egencache, for example, or any other ebuild sourc'ing, including > dependency checks. So, warnings would be noticed by users who added this > ebuilds into sunrise as they are, probably, using them. > Which is great, if it fails straight away it forces people to notice it. In comparsion to function drop, you would actualy have to emerge the ebuild. Fwiw the qa warning would polute the deps calculation/egencache in the same way. Now your maintainers are just forced to act faster, bummer.
(In reply to comment #10) > The maintainers of each overlay are responsible to keep their overlays working > and compatible with the main tree. It's very hard to achieve this goal if you don't know about any ongoing changes. Well, if you are a maintainer of some popular overlay than you, maybe, should be reading gentoo-dev maillist announcements. But if you are commiter to sunrise, which is "simple way for users to make their ebuild quality-assured and slightly more official (and trusted) than any other ebuild in overlay", you are probably not reading gentoo-dev maillist and you have no option of using your own eclasses. So, saying this, you mean that whole sunrise idea is a crap - if you are not a Full-Time Assured Gentoo Developer™ than your ebuilds are not quality assured, despite all complexity and QA high bar of sunrise commit procedure, and therefore could be broken at any moment without prior notification. So much of respect to those who commit into sunrise ;)
Sunrise maintainers should take care of their ebuilds. Stalling the main tree changes just because of sunrise broken ebuilds makes no sense. Why is it so difficult to understand that main tree has higher priority than sunrise?
I'm sorry, I'm removing the KDE Team, got tired of the bugmailspam.
(In reply to comment #13) > Sunrise maintainers should take care of their ebuilds. Stalling the main tree > changes just because of sunrise broken ebuilds makes no sense. Why is it so > difficult to understand that main tree has higher priority than sunrise? Just to be clear: it was known in prior that support would be dropped and announcements was made. But only in semi-public way: only in gentoo-dev maillist and only in kde overlay. So everyone who don't follow gentoo-dev@ and hadn't kde overlay installed wasn't aware of upcoming changes. And I see just no objections why it wasn't added into in-tree eclass'es (maybe after than all in-tree ebuilds were fixed)? Why it's so difficult to understand that users don't care about your priorities? Well, when I see that some overlay has missing digest or whatever I say "This damn overlay X failed, again!", but when I saw error in sunrise I thought "This d... wait... Sunrise?!". Of course, sunrise failure is not so epic failure like sbcl missing digest in main tree from some days ago, but generally sunrise believed to be even more stable and polished than main tree. So, when I looked upon error message with more attention, I thought "This damn kde-team had failed, again!". Just try to understand my opinion: sunrise is more than just overlay. It's promoted by gentoo devs, it's looked upon by gentoo devs, it's told as only-true-overlay-for-every-good-and-healthy-ebuild, by gentoo devs too, yes. And my opinion is, that in this current situation, you were able to avoid this situation without any "stalling", but you just didn't bothered. And now you are trying to cover your own failure with some words about. And your words now are more harmful than your actions. Breaking sunrise by accident is pity, but ok - you've just forgotten about it. But talking on public that sunrise is nothing more than simple overlay and you may break it at any moment _without_prior_warning_ (THIS is important: warnings, not breakage itself) is much worse. Just try to remember that except you there is some other non-official developers with enough experience and quality bar, that just have not so much free time or have some other options against being official developers - sunrise commiters. And they should be respected too. And your current behaviour is just disrespectful, IMO.
You are aware that both me and Markos work on sunrise. (well i used bit back but now i dont have time to help with reviews). The purpose of that overlay is to let users to contribute into one common place and help them understand how ebuild writting works, potentialy make them full developers. The stuff that is in that overlay is not getting any buildtime/runtime testing we just blindly trust what users contribute and give them proper informations how things should be done ebuild wise. It for sure does not have higher quality than project overlays where one of mandatory things is various buildtime testing and dependency scanning... Sunrise is just nice dumpground for users so you don't have to fetch multiple user overlays from untrusted sources, but still you should consider it overlay and not expect it to have that much higher quality over others.
Andrian, one option for the sunrise overlay is to add the old eclass into the overlay until the ebuilds are migrated. That's not a perfect solution, but that will allow the overlay maintainers to update their ebuilds with time and not have the ebuilds in the overlay broken. As a side note, as a former KDE lead, there was a time where we had particular care with eclasses updates so as not to break other ebuilds, but that was related to genkdesvn which was a "competing" KDE overlay and not just an overlay with some random ebuilds using the KDE eclasses.
