Summary: | >=kde-base/kdelibs-4.9.0 and related: Update UDisks2 patch and remove UDisks1 support as obsolete | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christian Loosli <spam> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 1i5t5.duncan, aklhfex, arne.flagge, asturm, b.brachaczek, cruzki123, cybertec.systems, franz.trischberger, freedesktop-bugs, gentoo, jens, kamil.kuduk, kuba.iluvatar, mrueg, nikoli, paolo.pedroni, simon, spam, tomas |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 439624 | ||
Attachments: |
udisks2 journal
kdelibs-4.9.4.ebuild kdelibs-udisks2-backend.patch |
Description
Christian Loosli
2012-06-29 19:44:30 UTC
We'll keep watching the situation and stay in touch with the Fedora guys who maintain the patch. I can confirm the delays. You'll see a lot of messages related to it in ~/.xsession-errors. If the situation does not improve, we'll remove the patch again before KDE 4.9.0 enters the main tree. (Which means the dependency on udisks:0 will be restored.) Just to confirm, I noticed exactly the same issues, mostly with krunner, compiling kdelibs against udisks-1.0.4 resolves the issue for me. I've hit 3 issues with this patch: 1. long delays in the open dialog 2. no CD detection on k3b 3. solid doesn't detect luks partitions I've moved the patch behind the udisks2 use flag. please, pretty please remove this patch. Waiting almost 10 seconds until gwenview displays anything sucks. Any errors in messages or auth.log? What if you run 'polkitd' without the --no-debug switch in terminal to get more verbose output? Someone needs to debug a bit futher before outright dismissing the patch that's working for so many. (In reply to comment #4) > please, pretty please remove this patch. Waiting almost 10 seconds until > gwenview displays anything sucks. You can simply disable USE="udisks2" and enable USE="udisks" in the overlay per latest commits No need to edit anything (In reply to comment #5) > Someone needs to debug a bit futher before outright dismissing the patch > that's working for so many. Is there actually someone here (note that maybe not "so many" use the kde overlay and a RC KDE) who could not reproduce these problems? If so, it would be great to have a look at what's different on these systems. The bug bit me too... Some info (ask if you need more): >>>KDE-Version: 4.8.95 >>> Hardware: Thinkpad T410s, Toshiba THNS128G SSD >>> emerge --info: Portage 2.2.0_alpha114 (default/linux/amd64/10.0/desktop/kde, gcc-4.6.3, glibc-2.14.1-r3, 3.4.4-gentoo x86_64) ================================================================= System uname: Linux-3.4.4-gentoo-x86_64-Intel-R-_Core-TM-_i5_CPU_M_520_@_2.40GHz-with-gentoo-2.1 Timestamp of tree: Mon, 02 Jul 2012 19:30:01 +0000 app-shells/bash: 4.2_p20 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/cmake: 2.8.7-r5 dev-util/pkgconfig: 0.26 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.9.9.3 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21.1-r1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.6 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 3.4 (virtual/os-headers) sys-libs/glibc: 2.14.1-r3 Repositories: gentoo kde java-netbeans java-binary aeoverlay Installed sets: @mykde, @networking, @portageutils, @toolbox ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0" 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/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=core2 -pipe" DISTDIR="/data/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuild-head preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de" MAKEOPTS="-j5" PKGDIR="/data/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="/var/lib/layman/kde /data/portage/java-netbeans /data/portage/java-binary /data/portage/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acpi alsa amd64 apng bzip2 cairo cdda cdr cli clucene consolekit cracklib crypt cups cxx dbus declarative device-mapper dri dts dvb dvd dvdr dvdread encode exif firefox flac foomaticdb gif gles gles1 gles2 glut glx gps hou iconv icu inotify irda java6 javadoc javasrc jpeg kde kipi kpathsea latex libnotify mmx modules mp3 mp4 mpeg mudflap multilib ncurses nepomuk netbeans-integration netbeans-library networkmanager nls nptl nptlonly ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds private-headers python3 qt3support quicktime rdp readline sasl scanner semantic-desktop session sou spell sse sse2 ssl startup-notification strigi svg system-sqlite systemjava tcpd theora threads tiff truetype udev udisks unicode upower usb userlocales v4l vorbis wayland x264 xcb xcomposite xetex xinerama xml xorg xscreensaver xv xvid zlib" 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" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="*" 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="pc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="de" PHP_TARGETS="php5-3" PYTHON_TARGETS="python3_2 python2_7" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="intel i965" 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, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON I got the same delay when starting dolphin, but didn't try out gwenview or k3b. Now with kdelibs-4.8.95 rebuilt without udisks2 patch, dolphin starts within its usual second. I've got quite a similar system hardware/software-wise as in Comment #8 but have a (mostly) regular HDD installed. Just for the record. + 26 Jul 2012; Johannes Huber <johu@gentoo.org> package.use.mask: + Mask experimental udisks2 support for kde-base/kdelibs, bug #424157. # Johannes Huber <johu@gentoo.org> (23 Mar 2012) # Broken dep upnp, see bug #389833. # Experimental udisks2 patch, see bug #424157 kde-base/kdelibs upnp udisks2 ?! After unmasking udisk2 in kdelibs, i'v got these error in dolphin: "/org/freedesktop/UDisks2/drives/WDC_WD5000BMVV_11GNWS0_WD_WX21A80F8816" has new interfaces: ("org.freedesktop.UDisks2.Drive", "org.freedesktop.UDisks2.Drive.Ata") "/org/freedesktop/UDisks2/block_devices/sdc" has new interfaces: ("org.freedesktop.UDisks2.Block", "org.freedesktop.UDisks2.PartitionTable") "/org/freedesktop/UDisks2/block_devices/sdc1" has new interfaces: ("org.freedesktop.UDisks2.Block", "org.freedesktop.UDisks2.Encrypted", "org.freedesktop.UDisks2.Partition") Failed to call the SolidUiServer, D-Bus said: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kded5 was not provided by any .service files") also see Bug 424157 sorry. These Bug: Bug 429618 A try of a analysis: https://bugs.gentoo.org/show_bug.cgi?id=400755#c4 I really can't imagine why 1451 udisks2::Device-instances need to be created... Replacing the two 4.8.95-udisks2 patches with: http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-udisks2-backend.patch?h=f17 on kdelibs-4.9.2 means k3b can find my optical drives with only udisks-2.0.0 installed. Removing sys-fs/udisks:0 as a dependency is not only eventually required, but in fact recommended action to do starting from this month, thus, adding blockers to bug 439624. @KDE: Please update to latest Fedora UDisks2 patchset and remove UDisks1 support in a revision targeted for ~arch. Stabilization of UDisks2 is happening as soon as we figure out the last blockers for >=sys-fs/udev-180 stabilization. We have all the required bugs open already. Unmasking and enabling udisks2 while removing udisks-1.* worked here without any problems. I don't see any delays when starting gwenview or dolphin (kde 4.9.3). Thanks a lot. Tried with the linked f17 udisks-backend.patch. Uninstalled udisks:0. Nothing really helped, dolphin takes ages to startup, even without optical disk inserted! Created attachment 331712 [details] udisks2 journal I'm with you guys. Acer 4810TG laptop. udev-196-r1, system booted with systemd-196, just moved to latest stable kde-4.9.3 and rebuilt kdelibs with udisks2. Dolphin takes something like 6 seconds to start, open dialogs take 10 seconds. I have attached udisks2 (without --no-debug) journal entries (in JSON) from current boot. There are no new log entries genereated when starting Dolphin. BTW, at https://bugzilla.redhat.com/show_bug.cgi?id=868530 they say delay in open/say dialogs was fixed in kdelibs-4.9.4-2.fc18. Has anyone tried this yet? Created attachment 331730 [details]
kdelibs-4.9.4.ebuild
Taken the ebuild from the tree, removed udisks:0-references, added a call to cmake-utils_use_with to enable udisks2-support.
Created attachment 331732 [details]
kdelibs-udisks2-backend.patch
The most recent udisks2-patch for fedora18.
The experience: Optical Disks still spin up for each dialog/dolphin window (once for each process, like with udisks:0) Tried to launch qdbusviewer, which caused X to use 100% CPU - Yeah. So overall no changes since udisks:0, let's look if the X-hang can be reprodeuced in some way. Looks like udisks2 support will be part of kde 4.10. https://bugs.kde.org/show_bug.cgi?id=310335. As 4.10 is scheduled for release on January 23 I guess most practical is to wait a bit. (In reply to comment #20) > Created attachment 331732 [details] > kdelibs-udisks2-backend.patch > > The most recent udisks2-patch for fedora18. This patch solves all problems for me: now dolphin and gwenview start up without delays and k3b can see my DVD writer, why isn't this in tree? KDE/4.10 indeed does have udisks2 support integrated, and is what we will be building. http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=590f914e42ae092e1a5ef628c0092a16a1a1393d The current kdelibs-4.9.98.ebuild might cause trouble: Upstream forces to either use udisks:2 or udisks:0. This needs a patch to turn off udisks completely, or add sth. like !udisks? ( sys-fs/udisks:0 ) to the deps. 1) would be the best to leave people the possibility to use a polkit(consolekit/systemd-free desktop, and 2) because may really confuse them. And: I finally can confirm that this is solved: but only for udisks:2, and only in kdelibs-4.9.98. (Now that I switched to gnome3 (because of this) and started to like it.... fine :() I saw your comment on the upstream bug and have forced udisks:2 only for now (since there is effort to remove :0 from the tree.) We can watch if upstream makes changes or patch it ourself later if it causes too much upset. Someone suggested in #-kde that since that since the backend doesn't actually appear to link to udisks, we could build udisks2 support unconditionally and just let it fail at runtime if udisks is missing. Is anyone able to test and see what happens? (having kdelibs-4.10.0 installed and udisks not should be all that's required) (In reply to comment #27) > Someone suggested in #-kde that since that since the backend doesn't > actually appear to link to udisks, we could build udisks2 support > unconditionally and just let it fail at runtime if udisks is missing. > > Is anyone able to test and see what happens? (having kdelibs-4.10.0 > installed and udisks not should be all that's required) CCing Duncan since I think he is running like this. (In reply to comment #27) > Someone suggested in #-kde that since that since the backend doesn't > actually appear to link to udisks, we could build udisks2 support > unconditionally and just let it fail at runtime if udisks is missing. > > Is anyone able to test and see what happens? (having kdelibs-4.10.0 > installed and udisks not should be all that's required) Unfortunately this approach will cause bugs like bug #456010. (In reply to comment #29) > (In reply to comment #27) > > Someone suggested in #-kde that since that since the backend doesn't > > actually appear to link to udisks, we could build udisks2 support > > unconditionally and just let it fail at runtime if udisks is missing. > > > > Is anyone able to test and see what happens? (having kdelibs-4.10.0 > > installed and udisks not should be all that's required) > > Unfortunately this approach will cause bugs like bug #456010. Thanks for CCing me. See bug 455792. Yes, I'm running without udisks of any sort (package.provided so portage doesn't protest, but USE=udev and udev is actually installed, USE=-upower and it's not installed) and kdelibs-4.9.98/4.10.0 (at least) have built just fine, and run just fine as far as I can see. Also note that udisks is an rdep, not a dep, so even as-is, it's not necessarily there for the build, only at runtime. So at least with udev, udisks support should be find to build unconditionally. I'm not sure about bug 456010, building without udev, however, but that's a different bug. Thus I'd suggest letting the udisk flag(s) pull in the rdep (providing runtime support), but at buildtime, either build the support unconditionally, or let the udev flag control udisks(2) support build as well, depending on how 456010 is resolved. (Looks like further bug dependencies are possible; there's certainly some interrelation.) Duncan Try if =sys-fs/udisks-2.0.92 works better, like with the delay problem So kdelibs-4.10.1 only deps on udisks:2 and the delay problem people have had with it should be fixed by using udisks-2.0.92 instead of .91 Nothing left to do here then, I'll close this (In reply to comment #32) > So kdelibs-4.10.1 only deps on udisks:2 and the delay problem people have > had with it should be fixed by using udisks-2.0.92 instead of .91 > Nothing left to do here then, I'll close this Huh? Two days in the middle of the week to leave people for testing? Quite short, isn't it? It definitely does NOT fix the delays. The only thing that may fix it is a daemon that caches the values. And this is done with soliddiskscan: https://github.com/sanya-m/solid-disk-prober The README.md there mentions my overlay from which you can get patched kdelibs (4.10.0 and 4.10.1) + kde-misc/soliddiskscan (comes as PDEPEND for kdelibs[udisks]). And that really finally fixes the delay issues. (In reply to comment #33) > (In reply to comment #32) > > So kdelibs-4.10.1 only deps on udisks:2 and the delay problem people have > > had with it should be fixed by using udisks-2.0.92 instead of .91 > > Nothing left to do here then, I'll close this > Huh? Two days in the middle of the week to leave people for testing? > Quite short, isn't it? > > It definitely does NOT fix the delays. The only thing that may fix it is a > daemon that caches the values. And this is done with soliddiskscan: > > https://github.com/sanya-m/solid-disk-prober > > The README.md there mentions my overlay from which you can get patched > kdelibs (4.10.0 and 4.10.1) + kde-misc/soliddiskscan (comes as PDEPEND for > kdelibs[udisks]). And that really finally fixes the delay issues. This bug was about converting udisks:0 dependency with udisks:2 in the ebuild which has been done This bug is not about the delays, but I've just wanted to mention it here that .92 solves part of the issues as per http://forums.gentoo.org/viewtopic-t-951786-highlight-.html If you wish to push soliddiskscan and patched kdelibs in tree, you propably want to open first an upstream bug and then new gentoo bug with a reference to the upstream bug Collecting multiple issues here isn't that good idea I use kde-base/kdelibs-4.10.5-r1 and udisks 2.1.0 and I have this issue, so what is wrong? (In reply to Florian Manschwetus from comment #35) > I use kde-base/kdelibs-4.10.5-r1 and udisks 2.1.0 and I have this issue, so > what is wrong? Please file a new bug, it's too difficult to track on an old bug like this. |