I'm trying to emerge webkit-gtk and I get this error: .o -c /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-56.cpp In file included from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/JSGPUExternalTextureDescriptor.h:23, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/JSGPUDevice.cpp:59, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/unified-sources/UnifiedSource-3a52ce78-56.cpp:1: /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUExternalTextureDescriptor.h: In static member function ‘static WebCore::WebGPU::VideoSourceIdentifier WebCore::GPUExternalTextureDescriptor::mediaIdentifierForSource(const WebCore::GPUVideoSource&, __CVBuffer*&)’: /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUExternalTextureDescriptor.h:71:44: error: invalid use of incomplete type ‘class WebCore::HTMLVideoElement’ 71 | auto playerIdentifier = videoSource->playerIdentifier(); | ^~ In file included from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/html/HTMLCanvasElement.h:33, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUImageCopyExternalImage.h:29, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUQueue.h:31, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUDevice.h:35, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/JSGPUDevice.h:23, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WebCore/DerivedSources/JSGPUDevice.cpp:22: /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/dom/Document.h:151:7: note: forward declaration of ‘class WebCore::HTMLVideoElement’ 151 | class HTMLVideoElement; | ^~~~~~~~~~~~~~~~ In file included from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/CompactRefPtrTuple.h:30, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/WeakPtr.h:29, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/CancellableTask.h:30, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/dom/ActiveDOMObject.h:32, from /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUDevice.h:28: /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/RefPtr.h: In instantiation of ‘static void WTF::DefaultRefDerefTraits< <template-parameter-1-1> >::derefIfNotNull(T*) [with T = WebCore::HTMLVideoElement]’: /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/RefPtr.h:75:61: required from ‘WTF::RefPtr<T, <template-parameter-1-2>, <template-parameter-1-3> >::~RefPtr() [with T = WebCore::HTMLVideoElement; _PtrTraits = WTF::RawPtrTraits<WebCore::HTMLVideoElement>; _RefDerefTraits = WTF::DefaultRefDerefTraits<WebCore::HTMLVideoElement>]’ /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/Modules/WebGPU/GPUExternalTextureDescriptor.h:46:8: required from here /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0_build/WTF/Headers/wtf/RefPtr.h:43:18: error: invalid use of incomplete type ‘class WebCore::HTMLVideoElement’ 43 | ptr->deref(); | ~~~~~^~~~~ /var/tmp/portage/net-libs/webkit-gtk-2.42.0-r410/work/webkitgtk-2.42.0/Source/WebCore/dom/Document.h:151:7: note: forward declaration of ‘class WebCore::HTMLVideoElement’ 151 | class HTMLVideoElement; | ^~~~~~~~~~~~~~~~ [3185/6824] /usr/bin/x86_64-pc-linu Reproducible: Always Portage 3.0.51 (python 3.11.5-final-0, default/linux/amd64/17.1/desktop/plasma/systemd/merged-usr, gcc-13, glibc-2.38-r2, 6.5.3-cova x86_64) ================================================================= System uname: Linux-6.5.3-cova-x86_64-Intel-R-_Core-TM-_i7-6820HQ_CPU_@_2.70GHz-with-glibc2.38 KiB Mem: 65677484 total, 48894200 free KiB Swap: 8388604 total, 8388604 free Timestamp of repository gentoo: Sun, 17 Sep 2023 16:01:44 +0000 Head commit of repository gentoo: 40f9e822039e5ea7efa86853383052c9e9ed4a99 Head commit of repository cova: ae91f9e570efedfe6db80f2bd0f212d60086c7be sh bash 5.2_p15-r6 ld GNU ld (Gentoo 2.41 p2) 2.41.0 app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.2_p15-r6::gentoo dev-java/java-config: 2.3.1-r1::gentoo dev-lang/perl: 5.38.0-r1::gentoo dev-lang/python: 3.8.18::gentoo, 3.10.13::gentoo, 3.11.5::gentoo, 3.12.0_rc2_p1-r1::gentoo dev-lang/rust: 1.72.0::gentoo dev-util/cmake: 3.27.5::gentoo dev-util/meson: 1.2.1-r1::gentoo sys-apps/baselayout: 2.14::gentoo sys-apps/sandbox: 2.38::gentoo sys-apps/systemd: 254.3::gentoo sys-devel/autoconf: 2.13-r8::gentoo, 2.71-r7::gentoo sys-devel/automake: 1.16.5-r1::gentoo sys-devel/binutils: 2.41-r1::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/clang: 16.0.6::gentoo sys-devel/gcc: 12.3.1_p20230825::gentoo, 13.2.1_p20230826::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/lld: 16.0.6::gentoo sys-devel/llvm: 15.0.7-r3::gentoo, 16.0.6::gentoo sys-devel/make: 4.4.1-r1::gentoo sys-kernel/linux-headers: 6.5::gentoo (virtual/os-headers) sys-libs/glibc: 2.38-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://anongit.gentoo.org/git/repo/sync/gentoo.git priority: -1000 volatile: True sync-git-verify-commit-signature: yes cova location: /var/lib/layman/cova sync-type: git sync-uri: https://github.com/cova-fe/cova-overlay.git masters: gentoo priority: 50 volatile: True local location: /usr/overlay masters: gentoo priority: 51 volatile: True ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O3 -fgraphite-identity -floop-nest-optimize -ftree-loop-distribution -flto=4 -fuse-linker-plugin -pipe -fpie -fpic -fstack-protector-strong -fstack-clash-protection" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /usr/share/sddm/scripts/Xsetup" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O3 -fgraphite-identity -floop-nest-optimize -ftree-loop-distribution -flto=4 -fuse-linker-plugin -pipe -fpie -fpic -fstack-protector-strong -fstack-clash-protection" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live clean-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.eu.oneandone.net/linux/distributions/gentoo/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/" LANG="en_IE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -march=native -O3 -fgraphite-identity -floop-nest-optimize -ftree-loop-distribution -flto=4 -fuse-linker-plugin -pipe -fpie -fpic -fstack-protector-strong -fstack-clash-protection -Wl,--as-needed -Wl,--hash-style=gnu" LEX="flex" LINGUAS="en it de" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" RUSTFLAGS="-C target-cpu=native" SHELL="/bin/bash" USE="3dnow 3dnowext 3dnowprefetch X \ a52 aac aalib acl acpi activities aim alsa amd64 apng appstream ares asf ati audio audiofile avahi bash-completion bidi bl bluetooth branding bri bzip2 cairo caps cdda cdr cjk cli crypt cups curl dba dbus declarative device-mapper dga divx divx4linux dri dts dv dvb dvd dvdr dvdread eap-sim edl egl encode ethereal evdev exif expat faad fam fame fbcon ffmpeg fftw fish-completion flac force-cgi-redirect fortran ftp gallium garmin gd gdbm gif gimp gmedia gmp gnutls gphoto2 gpm gps gsm gtk gui h264 h323 iconv icq icu idn ifp ilbc imagemagick imap innodb ipod iproute2 ipv6 ithreads jabber java javascript joystick jpeg kde kontact kvm kwallet lastfm lcms libnotify libtirpc libvirtd live lm_sensors lua lvm lxc lzma lzo mad maildir matroska mbox mdnsresponder-compat mhash mime mjpeg mmap mmx mmxext mng mozdevelop mozilla mp3 mp4 mpeg msn mtp multilib mysql ncurses network networkmanager new-hpcups nfsv4 njb nls nptl nptlonly offensive ofx ogg oggvorbis ogm openal openexr opengl openmp oscar pam pango parted pcap pcre pdf phonon php pipewire plasma plotutils png policykit ppds pulseaudio qemu qml qt5 readline real rtc ruby samba sasl screencast sdl seccomp semantic-desktop semantic-destkop sha512 sip slang slp smartcard sndfile snmp sound sox speex spell srt sse sse2 ssh ssl ssse3 startup-notification svg systemd tcltk telepathy test-rust theora threads tiff tk touchpad tremor truetype udev udisks unicode upower usb utempter v4l v4l2 vcd vde vhosts video videos vim-syntax virt-network virtualbox vorbis vulkan wav wayland widgets wifi wmf wmp wps wxwidgets wxwindows x264 xanim xattr xcb xface xft xine xinerama xml xosd xpm xscreensaver xsl xv xvid zeroconf zlib zpm" ABI_X86="64 32" ADA_TARGET="gnat_2021" 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="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="libinput wacom" KERNEL="linux" L10N="en it de en_IE" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="luajit" LUA_TARGETS="lua5-1 lua5-4 luajit" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby31 ruby32" VIDEO_CARDS="i965 intel nvidia v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, SIZE, STRINGS, STRIP, YACC, YFLAGS
Created attachment 870819 [details] emerge.log
Same here
Same here, this appears to be an issue with USE="-gstreamer".
Y'all, what are we doing here? We have USE=+gstreamer, so you're explicitly disabling it. webkit-gtk takes 45-55 minutes to compile on my system and takes ~120 MiB of disk space. The 4 deps added by USE=gstreamer take less than 3 minutes to compile and take ~30 MiB of disk space. Why are you disabling this?
> Why are you disabling this? Wrong answer from a developer. People are disabling it because they don't need it. The only reason why I disabled it is I have to compile this webkit because it's a dependency for evolution. Gstreamer is kind of a bit useless too for me because I'm using phonon-vlc. Not all people are on Gnome where gstreamer is widely used. In fact, you can built a fully functional KDE desktop w/o gstreamer.
(In reply to Francois Chenier from comment #5) > > Why are you disabling this? > > Wrong answer from a developer. I asked a question. I didn't provide an answer. But thank you for your disrespect. It makes it much easier for me to disregard you and what you say.
> But thank you for your disrespect. It makes it much easier for me to disregard you and what you say. That was imprecise. What I mean is, it makes it much easier to know who is not worth having a discussion with.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=abc960d0681ed29ce7a4f1a066d0bc08ae6b811d commit abc960d0681ed29ce7a4f1a066d0bc08ae6b811d Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-09-19 03:48:11 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-09-19 03:52:41 +0000 profiles: Force USE=gstreamer on webkit-gtk >= 2.42 Closes: https://bugs.gentoo.org/914362 Signed-off-by: Matt Turner <mattst88@gentoo.org> profiles/base/package.use.force | 7 +++++++ 1 file changed, 7 insertions(+)
May I also ask what's going on here? The reason because someone is not using a feature is because they don't need it. It is such an obvious question that I hardly see the need to ask it in the first place. That is the main reason of having USE flags in the first place, and possibly one of the defining features of the whole Gentoo concept. So, having a developer asking why a use flag is, well.., used sounds a bit weird, to say the least. And the removal of the use flag sounds like "I remove this use flag because I say so". Hardly a good reason. Maybe I can be wrong, but the average Gentoo user is not exactly naive, likely the cumulative knowledge of those users is pretty significant. Treating them as kids does not make sense in any context, go figure here. Moreover, In my opinion the answers here, like "But thank you for your disrespect. It makes it much easier for me to disregard you and what you say." is highly disrespectful, way more than the previous comment. If I'm not mistaken, the developer that answered this way is also part of gentoo council, that makes the issue even more interesting. That said, back to the technical part of this bug: Is gstreamer required part of webkit-gtk, by design, or this issue happens because of some bug in webkit-gtk that is masked by use flag removal? After all, previous versions and releases of this package does not suffer from the same issue.
(In reply to Fabio Coatti from comment #9) > May I also ask what's going on here? The reason because someone is not using > a feature is because they don't need it. It is such an obvious question that > I hardly see the need to ask it in the first place. That is the main reason > of having USE flags in the first place, and possibly one of the defining > features of the whole Gentoo concept. > So, having a developer asking why a use flag is, well.., used sounds a bit > weird, to say the least. > And the removal of the use flag sounds like "I remove this use flag because > I say so". Hardly a good reason. > Maybe I can be wrong, but the average Gentoo user is not exactly naive, > likely the cumulative knowledge of those users is pretty significant. > Treating them as kids does not make sense in any context, go figure here. > > Moreover, In my opinion the answers here, like "But thank you for your > disrespect. It makes it much easier for me to disregard you and what you > say." is highly disrespectful, way more than the previous comment. > comment 5 is where the non-technical, disrespectful tone started. People shouldn't be surprised if it then degrades. > If I'm not mistaken, the developer that answered this way is also part of > gentoo council, that makes the issue even more interesting. Not a helpful comment. > > That said, back to the technical part of this bug: I really think you could've cut out everything before this bit, except maybe the first sentence or two, and avoided the risk of further derailment. > Is gstreamer required > part of webkit-gtk, by design, or this issue happens because of some bug in > webkit-gtk that is masked by use flag removal? After all, previous versions > and releases of this package does not suffer from the same issue. The issue is that *in effect* it's required by upstream because they don't test non-gstreamer builds, it's a regular source of bugs like this, and it's unclear how useful webkit-gtk's media capabilities are without gstreamer. We sometimes have USE flags for things which have been there "since forever" but don't provide a configuration that either/or upstream or Gentoo actually care to support (possibly too bothersome to test, practically useless, outsized source of issues wrt the gain from it, ...), or where someone simply added the flag because a build system option existed for it without evaluating if it really should be optional for users. At no point has anyone here offered to actually look at the issue itself and create a patch. I'd recommend doing that if the flag is valuable to you.
(also fwiw "appeals to gentoo nature" are generally not super well received given it tends to be a suggestion of bad faith / incompetence and is a cliche.w We're all here for a reason & we all have interests in certain things, it's way better to just stay focused on the actual technical reason for something and the benefits/cons of making something optional.)
(In reply to Sam James from comment #11) > (also fwiw "appeals to gentoo nature" are generally not super well received > given it tends to be a suggestion of bad faith / incompetence and is a > cliche.w I can see that, and this is half true. By the same token, gentoo developers should consider that if someone uses a feature, it's because they think it is something that can be used, otherwise it would be not there in the first place. Considering them badly because of that is not well received either. Tends to be a suggestion of incompetence and it is also a cliche. > > We're all here for a reason & we all have interests in certain things, it's > way better to just stay focused on the actual technical reason for something > and the benefits/cons of making something optional.) I can not argue with that. May I point out that this good suggestion should be considered by all the parties involved in a bug report? Asking why someone uses a feature seems not the best strategy either. (In reply to Sam James from comment #10) them as kids does not make sense in any context, go figure here. > > > > Moreover, In my opinion the answers here, like "But thank you for your > > disrespect. It makes it much easier for me to disregard you and what you > > say." is highly disrespectful, way more than the previous comment. > > > > comment 5 is where the non-technical, disrespectful tone started. People > shouldn't be surprised if it then degrades. Everyone should try to avoid disrespectful tone, indeed. However, to me and apparently to others this started at comment #4, not 5. > > > If I'm not mistaken, the developer that answered this way is also part of > > gentoo council, that makes the issue even more interesting. > > Not a helpful comment. I disagree, it is important. But you may be right in pointing out that it is not helpful, so I rephrase: Is there any committee or similar structure to get a comment on this behavior? I'm a gentoo user since quite a bit and this is the first time that I saw such a behavior. Usually gentoo devs are extremely friendly and supportive, IIRC I got some good suggestions also from you. things like comment #4 could make people not exactly willing to report bugs or issues. > > > > > That said, back to the technical part of this bug: > > I really think you could've cut out everything before this bit, except maybe > the > first sentence or two, and avoided the risk of further derailment. I guess we can say that we agree to disagree on this one. > > > Is gstreamer required > > part of webkit-gtk, by design, or this issue happens because of some bug in > > webkit-gtk that is masked by use flag removal? After all, previous versions > > and releases of this package does not suffer from the same issue. > > The issue is that *in effect* it's required by upstream because they don't > test non-gstreamer builds, it's a regular source of bugs like this, and > it's unclear how useful webkit-gtk's media capabilities are without > gstreamer. > > We sometimes have USE flags for things which have been there "since forever" > but don't provide a configuration that either/or upstream or Gentoo actually > care to support (possibly too bothersome to test, practically useless, > outsized > source of issues wrt the gain from it, ...), or where someone simply added > the flag because a build system option existed for it without evaluating if > it really should be optional for users. This is a good answer, thanks for that. > > At no point has anyone here offered to actually look at the issue itself and > create > a patch. I'd recommend doing that if the flag is valuable to you. This is again less useful. Of course if someone is interested can create patches, everyone knows that. But the whole thing started with the (arguably) pretty harsh answer from the developer, that would make everyone willing to help a bit less willing, so to speak. Instead of asking why people are using a feature, what about "It seems that this package can not be compiled without gstreamer [...] so it's better to remove the use flag. Simple as that. Comment #4 is a fire starter, as you may see. Not the users involved in this discussion. I hoe this clarifies my position and explains why I moved away from the pure technical aspects.
comrel is the relevant body. sticking to the technical bits: I'd be interested in the reasons people here have webkit-gtk installed on their systems (output of emerge -pvc webkit-gtk). That might help make it clearer as to if a webkit-gtk w/o gstreamer is (sufficiently) useful to bother supporting, or if webkit-gtk should just be avoidable entirely for those users instead. webkit-gtk has a bunch of runtime automagic logic to just not load videos/audio if a codec is missing as well. As for the patch bit: point was that upstream don't bother testing this configuration => someone here need to provide a patch to keep it working, as I suspect one won't be forthcoming from upstream (i.e. reporting upstream is likely not a useful venture). My comment wasn't as simple as a glib "patches welcome" (although this is generally true if people are super keen on a seemingly niche configuration).
My case: Calculating dependencies... done! net-libs/webkit-gtk-2.40.5-r410 pulled in by: app-office/gnucash-5.1 requires net-libs/webkit-gtk:4.1/0=, net-libs/webkit-gtk:4.1= gnome-extra/yelp-42.2-r1 requires net-libs/webkit-gtk:4.1 yelp can be avoided in my setup (if you don't like docs, I mean), as it looks like this: ⌙➤ equery d yelp * These packages depend on yelp: app-office/gnucash-5.1 (doc ? gnome-extra/yelp) media-sound/easyeffects-7.0.7 (doc ? gnome-extra/yelp) gnucash is another issue, though. It gets more complicated if I run equery d: ⌙➤ equery d webkit-gtk * These packages depend on webkit-gtk: app-office/gnucash-5.1 (gui ? net-libs/webkit-gtk:4.1) gnome-extra/yelp-42.2-r1 (net-libs/webkit-gtk:4.1) x11-libs/wxGTK-3.0.5.1-r1 (webkit ? net-libs/webkit-gtk:4) x11-libs/wxGTK-3.2.2.1-r3 (webkit ? net-libs/webkit-gtk:4) And then, down the rabbit hole :) ⌙➤ equery d x11-libs/wxGTK * These packages depend on x11-libs/wxGTK: app-misc/golly-4.2 (x11-libs/wxGTK:3.2-gtk3[X,curl,opengl,sdl,tiff]) media-video/mediainfo-23.04 (wxwidgets ? x11-libs/wxGTK:3.0-gtk3[X]) sci-visualization/gnuplot-5.4.8 (wxwidgets ? x11-libs/wxGTK:3.2-gtk3[X])
(In reply to Fabio Coatti from comment #12) > > This is again less useful. Of course if someone is interested can create > patches, everyone knows that. But the whole thing started with the > (arguably) pretty harsh answer from the developer, that would make everyone > willing to help a bit less willing, so to speak. > Instead of asking why people are using a feature, what about "It seems that > this package can not be compiled without gstreamer [...] so it's better to > remove the use flag. Simple as that. Comment #4 is a fire starter, as you > may see. Not the users involved in this discussion. > > I hoe this clarifies my position and explains why I moved away from the pure > technical aspects. Thanks for understanding. I'm sure mattst88 meant the words to come out that way, "why/how are you running webkit-gtk without gstreamer" as gstreamer seems like an internal part of webkit-gtk. You provided a concrete use-case example: webkit-gtk is a necessary evil so you try to keep it as minimal as possible. I feel like what happened after, is mattst88 got your message as an "instruction". You know we've had users telling us what to do a lot lately, and it's especially visible with Gnome/gstreamer stack since as sam also hinted the upstream is pretty stubborn on their ways to only support one configuration. The technical solution for now also seems correct, as only the affected version is use.forced until it gets patched. If it gets patched. Again, upstream may not be willing to include this patch, but I don't want to discourage anyone from trying!
bleh, it looks like gnucash really does always depend on it (cmake check is 'REQUIRED') and it's used for viewing reports. Someone raised this a while ago at https://lists.gnucash.org/pipermail/gnucash-user/2015-December/063242.html (see also https://lists.gnucash.org/pipermail/gnucash-user/2015-December/063252.html).
interestingly, I _do_ see fixes upstream recently fixing non-gst build, although they've refactored a lot wrt gst in master so I can't tell if it's the same problem. so they may well be open to reports actually
(In reply to Sam James from comment #17) > interestingly, I _do_ see fixes upstream recently fixing non-gst build, > although they've refactored a lot wrt gst in master so I can't tell if it's > the same problem. so they may well be open to reports actually It is worth a try, once I have 5 minutes free I'll check with gnucash upstream if they have something on this topic. Thanks for the suggestion.
sorry to be clear: meant webkit-gtk has fixes recently for non-gst; not looked at any upstream progress on gnucash w/o webkit-gtk (although from the mails I linked, it sounds like they would be interested if someone wanted to implement it)
(In reply to Sam James from comment #19) > sorry to be clear: meant webkit-gtk has fixes recently for non-gst; not > looked at any upstream progress on gnucash w/o webkit-gtk (although from the > mails I linked, it sounds like they would be interested if someone wanted to > implement it) Yep, got it, my answer was even more confusing :) I meant that also pinging gnucash upstream could be wort a shot. (even though proposing patches to that project could be quite above my skills, but this is another issue....)
(In reply to Sam James from comment #19) > sorry to be clear: meant webkit-gtk has fixes recently for non-gst; not > looked at any upstream progress on gnucash w/o webkit-gtk (although from the > mails I linked, it sounds like they would be interested if someone wanted to > implement it) IIRC, gnucash requires webkit-gtk in order to provide the gui functionality without which gnucash is probably not very useful to most people. However, as gnucash is the only thing that absolutely requires webkit-gtk on my system, and comes in at: >>> net-libs/webkit-gtk-2.42.0-r410 merge time: 6 hours, 7 minutes and 58 seconds. (old hardware, sob) it would absolutely be nice to be able to dispense with it altogether. But, echoing Sam's comments, I don't get that this at all a priority upstream with gnucash developers.
(In reply to Fabio Coatti from comment #9) > May I also ask what's going on here? The reason because someone is not using > a feature is because they don't need it. It is such an obvious question that > I hardly see the need to ask it in the first place. That is the main reason > of having USE flags in the first place, and possibly one of the defining > features of the whole Gentoo concept. > So, having a developer asking why a use flag is, well.., used sounds a bit > weird, to say the least. I'm asking a legitimate question because - the savings by disabling gstreamer are trivial - it has broken a lot recently So I'm trying to figure out whether there's significant value in it being optional when balanced by the maintanence cost. For context, it was only last month that bug 911663 was filed, which lead to me investigating, debugging, and fixing the build failure. I submitted the fix upstream which is not an easy task with webkit. And then I added the patch to gentoo to fix the original bug report. For all that time and effort, I am justified in questioning the usefulness of disabling gstreamer when it breaks a month later. Very often, users disable something because they can and it makes them *feel* like they're saving something. I'm noting what is actually being saved and questioning whether it's useful trade-off when considering the maintanence costs. Now, of course it's worth it for you since *my* time is not at all a consideration for you.
(In reply to Matt Turner from comment #22) > (In reply to Fabio Coatti from comment #9) > > May I also ask what's going on here? The reason because someone is not using > > a feature is because they don't need it. It is such an obvious question that > > I hardly see the need to ask it in the first place. That is the main reason > > of having USE flags in the first place, and possibly one of the defining > > features of the whole Gentoo concept. > > So, having a developer asking why a use flag is, well.., used sounds a bit > > weird, to say the least. > > I'm asking a legitimate question because > > - the savings by disabling gstreamer are trivial > - it has broken a lot recently > > So I'm trying to figure out whether there's significant value in it being > optional when balanced by the maintanence cost. > > For context, it was only last month that bug 911663 was filed, which lead to > me investigating, debugging, and fixing the build failure. I submitted the > fix upstream which is not an easy task with webkit. And then I added the > patch to gentoo to fix the original bug report. > > For all that time and effort, I am justified in questioning the usefulness > of disabling gstreamer when it breaks a month later. That is absolutely fine and understandable. I think there is a misunderstanding of the whole situation. From my point of view, it is not the best approach to start questioning the usage of a feature that is available. To support my point of view, look at the discussion. It quickly become heated and not really helpful. And everyone involved had some part on it. To give my two cents, the whole situation would have remained perfectly fine if the first (4) comment was formulated in a different way, even slightly. > > Very often, users disable something because they can and it makes them > *feel* like they're saving something. I'm noting what is actually being > saved and questioning whether it's useful trade-off when considering the > maintanence costs. Again, this is completely reasonable, no one objected on the technical part of your point. > > Now, of course it's worth it for you since *my* time is not at all a > consideration for you. ...and here comes back the problematic approach. No one said or mentioned or even implied that your time is not a consideration. this could easily trigger heated discussions. Not to mention that everyone spent time on this issue, either by reporting, testing and discussing it. Not only gentoo developers are dedicating some time here, being it a small or a big amount. If you look retrospectively at the exchange, from a small bait the flame started pretty fast, and the final stroke was when respect was mentioned. This triggered also me, to be honest. (see 4,5,6). To not make this thread a complete waste, I would suggest to take it an example of how things can get sidetracked if not properly managed. Like "don't offend, don't get offended too much". A clearer and measured comment #4 and #5, for example, could have saved a lot of time to everyone.
Believe me, if I could do something differently I would. I wouldn't have responded at all. Anyway, I've maintained gnome@ by myself long enough. I've asked for help repeatedly and I've gotten only one consistent contributor. I hate to leave it all on him, especially when he's not even a developer, but I'm just sick of dealing with things like this. So I'm not going to anymore. So I hope you'll excuse me when I confidently say that no, as a rule, Gentoo users do not value my time. If they did they would not be so quick to demand so much of it without doing anything to help alleviate the load (or even a "thank you" 98% of the time).
(In reply to Matt Turner from comment #24) > Believe me, if I could do something differently I would. I wouldn't have > responded at all. > > > Anyway, I've maintained gnome@ by myself long enough. I've asked for help > repeatedly and I've gotten only one consistent contributor. I hate to leave > it all on him, especially when he's not even a developer, but I'm just sick > of dealing with things like this. So I'm not going to anymore. > > So I hope you'll excuse me when I confidently say that no, as a rule, Gentoo > users do not value my time. If they did they would not be so quick to demand > so much of it without doing anything to help alleviate the load (or even a > "thank you" 98% of the time). You are the only one that can judge your situation, so I'm not going to argue with your opinion here. And I completely believe that many (even though not all) users behaves like that. Personally I consider this to be expected. However, I still believe that a slightly different approach would have ended in a way more satisfactory way. Not technically, but at personal level. As example, instead of asking "why you are doing that", a "hi, I dug thru the problem and it turns out that removing this dependency would be not worth" (for all the reasons that emerged in this interesting thread). And I'm ready to bet that everyone would have been grateful for the explanation. However, I think that everyone clarified their position; I'm satisfied with the outcome that allowed me to understand the technical background of the issue. Regarding the emotional part of it, I can only say that I completely understand the feeling, no issue with that. I guess that it is something that can be influenced positively with a slightly different approach. Btw: I'm pretty grateful to everyone involved in gentoo activities, I try to help when I can but I can see how taxing it could be at times.
It looks like this is fixed in 2.42.1-r600. FWIW the reason I disable it is that under no circumstances do I ever want my web browser to play sound or video. Disabling it in webkit is a straightforward way to make that happen (epiphany certainly doesn't give you any options) and has security benefits if you don't care about the content. As far as the maintenance burden: no one wants the maintainers to burn themselves out over this. If it breaks, report it upstream and wait for them to deal with it. That requires (almost) no work, and for those of us who want the flag off, is still preferable to having it non-optional. At the very least we can find the bug report and set USE=gstreamer for one release if we need to.
Please do file downstream reports and I'll fix them on a best effort basis. It's just that all combinations don't get tested before pushing an update out and when there are issues with rarely used combinations, they tend to be lower priority to fully fix and sometimes it's better to just force it on meanwhile as a better alternative for a webkit build failing after 6 hours on slower computers. The typical failure cases are USE=-jumbo-build and USE=-gstreamer
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8627ce09b2fcacc28e5bac20c3e2ff8a5bfe5714 commit 8627ce09b2fcacc28e5bac20c3e2ff8a5bfe5714 Author: Michael Orlitzky <mjo@gentoo.org> AuthorDate: 2023-12-04 12:30:47 +0000 Commit: Michael Orlitzky <mjo@gentoo.org> CommitDate: 2023-12-04 16:48:30 +0000 profiles/base: un-force USE=gstreamer for newer webkit-gtk It works now. As someone who disables it, I'd rather have it fail to build and have to make a decision every once in a while than have it force-enabled forever. Bug: https://bugs.gentoo.org/914362 Bug: https://github.com/gentoo/gentoo/pull/33762 Signed-off-by: Michael Orlitzky <mjo@gentoo.org> profiles/base/package.use.force | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
