Re: Donate 1 minute of your time to test upgrades from F38 to F39
BTW, after removing python3-slip, python3-slip-dbus and python3-decorator, both dnf5 and dnf produce no errors On Thu, Aug 24, 2023 at 6:35 AM Tom London wrote: > > > On Thu, Aug 24, 2023 at 3:39 AM Nicola Sella wrote: > >> Thanks Mirek, >> >> dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ >>> --enablerepo=updates-testing \ >>> $(rpm -q fedora-repos-modular >/dev/null && echo >>> --enablerepo=updates-testing-modular) \ >>> --assumeno distro-sync >>> >> Allow me to steal some testing. :) >> I would like to point out that running the same command, replacing dnf >> with dnf5, should work and produce the same transaction. >> I suggest running both commands and report eventual errors. This would be >> of great help for the dnf team to implement/debug distro-upgrade commands. >> >> I am getting no errors in the transaction and have the same package list >> with both package managers. >> >> Thanks, >> >> >> >> I get this with dnf5: > > Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) > = 3.11, but none of the providers can be installed > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-3.11.4-1.fc38.x86_64 > Problem 2: package python3-3.11.4-1.fc38.x86_64 requires > python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be > installed > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-dbus-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-libs-3.11.4-1.fc38.x86_64 > Problem 3: package ibus-1.5.29~rc1-2.fc39.x86_64 requires python(abi) = > 3.12, but none of the providers can be installed > - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - problem with installed package > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install the best update candidate for package > ibus-1.5.28-6.fc38.x86_64 > Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires > libpython3.12.so.1.0()(64bit), but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = > 3.11.4-1.fc38, but none of the providers can be installed > - problem with installed package > - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, > but none of the providers can be installed > - cannot install the best update candidate for package > vtk-9.2.5-2.fc38.x86_64 > > and this with dnf: > > Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) > = 3.11, but none of the providers can be installed > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-3.11.4-1.fc38.x86_64 > Problem 2: package python3-3.11.4-1.fc38.x86_64 requires > python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be > installed > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and > python3-libs-3.12.0~rc1-1.fc39.x86_64 > - cannot install the best update candidate for package > python3-slip-dbus-0.6.4-29.fc38.noarch > - cannot install the best update candidate for package > python3-libs-3.11.4-1.fc38.x86_64 > Problem 3: package torbrowser-launcher-0.3.6-6.fc39.noarch requires > python(abi) = 3.12, but none of the providers can be installed > - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture > - cannot install both python3-3.11.4-1.fc38.x86_64 and > python3-3.12.0~rc1-1.fc39.x86_64 > - problem with installed package > - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = > 3.11, but none of the providers can be installed > - cannot install the best update candidate for
Re: Donate 1 minute of your time to test upgrades from F38 to F39
On Thu, Aug 24, 2023 at 3:39 AM Nicola Sella wrote: > Thanks Mirek, > > dnf --releasever=39 --setopt=module_platform_id=platform:f39 \ >> --enablerepo=updates-testing \ >> $(rpm -q fedora-repos-modular >/dev/null && echo >> --enablerepo=updates-testing-modular) \ >> --assumeno distro-sync >> > Allow me to steal some testing. :) > I would like to point out that running the same command, replacing dnf > with dnf5, should work and produce the same transaction. > I suggest running both commands and report eventual errors. This would be > of great help for the dnf team to implement/debug distro-upgrade commands. > > I am getting no errors in the transaction and have the same package list > with both package managers. > > Thanks, > > > > I get this with dnf5: Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-3.11.4-1.fc38.x86_64 Problem 2: package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-dbus-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-libs-3.11.4-1.fc38.x86_64 Problem 3: package ibus-1.5.29~rc1-2.fc39.x86_64 requires python(abi) = 3.12, but none of the providers can be installed - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - problem with installed package - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package ibus-1.5.28-6.fc38.x86_64 Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires libpython3.12.so.1.0()(64bit), but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - problem with installed package - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package vtk-9.2.5-2.fc38.x86_64 and this with dnf: Problem 1: package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-3.11.4-1.fc38.x86_64 Problem 2: package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - cannot install the best update candidate for package python3-slip-dbus-0.6.4-29.fc38.noarch - cannot install the best update candidate for package python3-libs-3.11.4-1.fc38.x86_64 Problem 3: package torbrowser-launcher-0.3.6-6.fc39.noarch requires python(abi) = 3.12, but none of the providers can be installed - python3-3.12.0~rc1-1.fc39.i686 has inferior architecture - cannot install both python3-3.11.4-1.fc38.x86_64 and python3-3.12.0~rc1-1.fc39.x86_64 - problem with installed package - package python3-slip-dbus-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for package torbrowser-launcher-0.3.6-3.fc38.noarch Problem 4: package vtk-9.2.6-6.fc39.x86_64 requires libpython3.12.so.1.0()(64bit), but none of the providers can be installed - cannot install both python3-libs-3.11.4-1.fc38.x86_64 and python3-libs-3.12.0~rc1-1.fc39.x86_64 - package python3-3.11.4-1.fc38.x86_64 requires python3-libs(x86-64) = 3.11.4-1.fc38, but none of the providers can be installed - problem with installed package - package python3-slip-0.6.4-29.fc38.noarch requires python(abi) = 3.11, but none of the providers can be installed - cannot install the best update candidate for
Re: Donate 1 minute of your time to test upgrades from F29 to F30
e) < 2.5.0, but none of the providers can be > installed > - problem with installed package python3-flake8-3.5.0-6.fc29.noarch > - python3-pycodestyle-2.4.0-3.fc29.noarch does not belong to a > distupgrade > repository > - python3-flake8-3.5.0-6.fc29.noarch does not belong to a distupgrade > repository > Problem 9: package dbus-common-1:1.12.12-2.fc30.noarch conflicts with > fedora-release < 30-0.2 provided by fedora-release-29-7.noarch > - package rpmfusion-free-release-29-1.noarch requires > system-release(29), > but none of the providers can be installed > - problem with installed package dbus-common-1:1.12.12-1.fc29.noarch > - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- > release, but none of the providers can be installed > - dbus-common-1:1.12.12-1.fc29.noarch does not belong to a distupgrade > repository > - problem with installed package fedy-plugins-4.0.5-1.fc22.noarch > Problem 10: package dnf-yum-4.1.0-1.fc30.noarch conflicts with yum > provided > by yum-3.4.3-521.fc30.noarch > - package yumex-3.0.17-2.fc23.noarch requires yum >= 3.2.23, but none of > the providers can be installed > - problem with installed package dnf-yum-4.1.0-1.fc29.noarch > - yum-3.4.3-518.fc29.noarch does not belong to a distupgrade repository > - dnf-yum-4.1.0-1.fc29.noarch does not belong to a distupgrade repository > - problem with installed package yumex-3.0.17-2.fc23.noarch > Problem 11: package rpmfusion-free-release-29-1.noarch requires system- > release(29), but none of the providers can be installed > - package dbus-daemon-1:1.12.12-2.fc30.x86_64 conflicts with fedora- > release < 30-0.2 provided by fedora-release-29-7.noarch > - package fedy-plugins-4.0.5-1.fc22.noarch requires rpmfusion-free- > release, but none of the providers can be installed > - problem with installed package dbus-daemon-1:1.12.12-1.fc29.x86_64 > - package fedy-4.0.5-1.fc22.noarch requires fedy-plugins, but none of > the > providers can be installed > - dbus-daemon-1:1.12.12-1.fc29.x86_64 does not belong to a distupgrade > repository > - problem with installed package fedy-4.0.5-1.fc22.noarch > (try to add '--allowerasing' to command line to replace conflicting > packages > or '--skip-broken' to skip uninstallable packages) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Tom London ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
fuse, /dev/fuse, systemd, ... ?
For the past week or two, I've noticed that cryptkeeper is not starting when Gnome starts up on my fully Rawhide system. Noticed that /dev/fuse is not set for user access, fuse module has not been loaded, etc. This by design (i.e., migrating udev to ..., etc.)? Here is what I am seeing: [root@tlondon ~]# ls -l /dev/fuse crw---. 1 root root 10, 229 Aug 3 09:48 /dev/fuse [root@tlondon ~]# lsmod | grep fuse [root@tlondon ~]# [root@tlondon ~]# systemctl status sys-fs-fuse-connections.mount sys-fs-fuse-connections.mount - FUSE Control File System Loaded: loaded (/usr/lib/systemd/system/sys-fs-fuse-connections.mount; static) Active: inactive (dead) start condition failed at Sat 2013-08-03 09:48:28 PDT; 2h 37min ago Where: /sys/fs/fuse/connections What: fusectl Docs: https://www.kernel.org/doc/Documentation/filesystems/fuse.txt http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems [root@tlondon ~]# [root@tlondon ~]# ls -l /sys/fs/fuse/connections ls: cannot access /sys/fs/fuse/connections: No such file or directory [root@tlondon ~]# [root@tlondon ~]# systmctl status systemd-modules-load.service bin-bash: systmctl: command not found [root@tlondon ~]# systemctl status systemd-modules-load.service systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: inactive (dead) start condition failed at Sat 2013-08-03 09:48:27 PDT; 2h 38min ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) [root@tlondon ~]# systemctl status systemd-readahead-collect.service systemd-readahead-collect.service - Collect Read-Ahead Data Loaded: loaded (/usr/lib/systemd/system/systemd-readahead-collect.service; enabled) Active: active (exited) since Sat 2013-08-03 09:48:27 PDT; 2h 39min ago Docs: man:systemd-readahead-replay.service(8) Main PID: 279 (code=exited, status=0/SUCCESS) Status: Collecting readahead data [root@tlondon ~]# systemctl status systemd-readahead-replay.service systemd-readahead-replay.service - Replay Read-Ahead Data Loaded: loaded (/usr/lib/systemd/system/systemd-readahead-replay.service; enabled) Active: active (exited) since Sat 2013-08-03 09:48:27 PDT; 2h 39min ago Docs: man:systemd-readahead-replay.service(8) Main PID: 278 (code=exited, status=0/SUCCESS) Status: Replaying readahead data [root@tlondon ~]# ls -l /lib/modules-load.d /usr/lib/modules-load.d /usr/local/lib/modules-load.d /etc/modules-load.d /run/modules-load.d ls: cannot access /usr/local/lib/modules-load.d: No such file or directory ls: cannot access /run/modules-load.d: No such file or directory /etc/modules-load.d: total 0 /lib/modules-load.d: total 0 /usr/lib/modules-load.d: total 0 [root@tlondon ~]# [root@tlondon ~]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.11.0-0.rc3.git2.2.fc20.x86_64 root=/dev/mapper/vg_tlondon-lv_root ro LANG=en_US.UTF-8 [root@tlondon ~]# Something to BZ or all part of the plan tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Mon, Dec 17, 2012 at 12:20 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, On Mon, Dec 17, 2012 at 12:27 AM, Tom London seli...@gmail.com wrote: I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. Sigh. Spoke too soon. Hang resurfaced. See: https://bugzilla.redhat.com/show_bug.cgi?id=877461 It still worth the update, IMHO. The 2.20.16 is just way better than the 2.20.10. As the gdm crash is still there, despite the 2.20.16 being the latest release, it might make sense to report the bug (with all the relevant information) directly on https://bugs.freedesktop.org/ -Ilyes I agree. System actually is running much better with the update to 2.20.16: The entire system feels snappier. I've updated my grab the error state script to also grab /var/log/Xorg.0.log and the gdm logs. When I capture these again, I'll report upstream tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sun, Dec 16, 2012 at 1:56 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: and performance (blt and blending, cairo-demos) is way better than the 2.20.10 and 2.20.14 releases. -Ilyes On Sun, Dec 16, 2012 at 10:47 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, Just testing the 2.20.16 release and everything looks good so far on GM45. -Ilyes On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto ser...@serjux.com wrote: On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and this platform using Intel HD 3000 i915 graphic. I install Base video mode. after that i dont achieve install intel driver. i need installation steps of xf86-video-intel 2.20.16 . libdrm version,X-server version, etc. also create problem when i make ./configure but i already updated Fedora 14 . When I want update packages I do custom rpms, and recently use mock (*) to build the packages. #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git #cd xorg-x11-drv-intel/ edit xorg-x11-drv-intel.spec change version to Version: 2.20.16 fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) and finally rpm -Uvh the build rpms if not have mock and fedpkg in F14 you could try rpmbuild -ba xorg-x11-drv-intel.spec ... (*) my notes to use mock http://www.serjux.com/alps/how_to_use_mock.txt On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Adam, On Dec 15, 2012 9:48 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. I'm confused. If this update breaks your system, why would you want us to move to it? No, the 2.20.14 which is in updates-testing isn't stable. From the changelog, the 2.20.16 looks like it has fixes for the issues reported for GM45. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Sérgio M. B. -- I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sun, Dec 16, 2012 at 12:39 PM, Tom London seli...@gmail.com wrote: On Sun, Dec 16, 2012 at 1:56 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: and performance (blt and blending, cairo-demos) is way better than the 2.20.10 and 2.20.14 releases. -Ilyes On Sun, Dec 16, 2012 at 10:47 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi, Just testing the 2.20.16 release and everything looks good so far on GM45. -Ilyes On Sun, Dec 16, 2012 at 2:28 AM, Sérgio Basto ser...@serjux.com wrote: On Dom, 2012-12-16 at 01:10 +0200, Ebru Arslan wrote: I am using 32 bit Fedora 14 . our platform is Adlink cPCI-3970D and this platform using Intel HD 3000 i915 graphic. I install Base video mode. after that i dont achieve install intel driver. i need installation steps of xf86-video-intel 2.20.16 . libdrm version,X-server version, etc. also create problem when i make ./configure but i already updated Fedora 14 . When I want update packages I do custom rpms, and recently use mock (*) to build the packages. #cd fedora-scm/ #git clone git://pkgs.fedoraproject.org/xorg-x11-drv-intel.git #cd xorg-x11-drv-intel/ edit xorg-x11-drv-intel.spec change version to Version: 2.20.16 fedpkg mockbuild --root fedora-18-x86_64 (or fedora-14-x86_64) fedpkg mockbuild --root fedora-18-i386 (or fedora-14-i386) and finally rpm -Uvh the build rpms if not have mock and fedpkg in F14 you could try rpmbuild -ba xorg-x11-drv-intel.spec ... (*) my notes to use mock http://www.serjux.com/alps/how_to_use_mock.txt On Sun, Dec 16, 2012 at 1:06 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Adam, On Dec 15, 2012 9:48 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 20:54 +0100, Ilyes Gouta wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. I'm confused. If this update breaks your system, why would you want us to move to it? No, the 2.20.14 which is in updates-testing isn't stable. From the changelog, the 2.20.16 looks like it has fixes for the issues reported for GM45. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Sérgio M. B. -- I concur: I locally build xorg-x11-drv-intel (including xf86-video-intel-2.20.16.tar.bz2), updated, and logged out/in. System does appear snappier, and I have not yet been able to recreate the hang/crash. Sigh. Spoke too soon. Hang resurfaced. See: https://bugzilla.redhat.com/show_bug.cgi?id=877461 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fwd: [ANNOUNCE] xf86-video-intel 2.20.16
On Sat, Dec 15, 2012 at 11:54 AM, Ilyes Gouta ilyes.go...@gmail.com wrote: Hi Adam, On Sat, Dec 15, 2012 at 8:35 PM, Adam Williamson awill...@redhat.com wrote: On Sat, 2012-12-15 at 12:23 +0100, Ilyes Gouta wrote: Hi, Would it be possible to pull in and package xorg-x11-drv-intel driver updates more frequently in Fedora? These are kinda critical for the stability of desktop/X. It sucks if you use an 830 or 845, sure, but that's not many people any more. Nah, I have a GM45, and this particular update breaks the desktop and video acceleration (overlay) on my machine. This update is an exception, but xorg-x11-drv package updates are usually fairly dull and not worth caring much about these days. I don't think you can use this update as a typical example of an xorg-x11-drv update. I'm sure ajax is considering whether this one is appropriate as an update. Let's just move to the latest xf86-video-intel 2.20.16 update. I'll be filing a bugzilla w/ the GPU lockup report. -Ilyes -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net Believe there are already a few BZs for GPU lockup: https://bugzilla.redhat.com/show_bug.cgi?id=877461 https://bugzilla.redhat.com/show_bug.cgi?id=869354 https://bugzilla.redhat.com/show_bug.cgi?id=879823 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dracut-20-51 - Heads up
On Mon, Jul 9, 2012 at 3:09 AM, Harald Hoyer har...@redhat.com wrote: Am 09.07.2012 09:44, schrieb Harald Hoyer: Do not install dracut-020-51! Sorry for those, who have been bitten by dracut-020-51. Instead of installing to the /var/tmp/initramfs.* directory, it installed in your real root. To remove most (if not all) of the files, it has installed, do the following: # rm /.bash_history # rm /dracut-state.sh # rm /lib/dracut-crypt-lib.sh /lib/dracut-lib.sh /lib/dracut/modules.txt # rm -r /lib/dracut/hooks # rm /sbin/btrfs_finished /sbin/btrfs_timeout /sbin/cryptroot-ask # rm /sbin/initqueue /sbin/insmodpost.sh /sbin/iscsiroot /sbin/loginit # rm /sbin/lvm_scan # rm /sbin/mdraid-cleanup /sbin/mdraid_start /sbin/nbdroot /sbin/netroot # rm /sbin/nfsroot /sbin/probe-keydev /bin/dracut-cmdline /bin/dracut-initqueue # rm /bin/dracut-pre-pivot /bin/dracut-pre-trigger /bin/dracut-pre-udev # rm /bin/mount-hook /bin/mount-lun.sh # rm /lib/fs-lib.sh /lib/net-lib.sh /lib/nfs-lib.sh # rm /etc/initrd-release # rm /lib/systemd/system/dracut* # rm /lib/systemd/system/*/dracut* # rm /lib/systemd/system/default.target # rm /lib/systemd/system/initrd-switch-root.service # rm -r /lib/systemd/system/initrd-switch-root.target # vi /etc/fstab .. remove all /sysroot lines # mkdir /tmp/dracut-fixup; ( cd /tmp/dracut-fixup; yumdownloader setup; \ rpm2cpio setup*.rpm | cpio -id ; cp etc/profile /etc ); \ rm -fr /tmp/dracut-fixup # mkdir /tmp/dracut-fixup; ( cd /tmp/dracut-fixup; \ yumdownloader --archlist=$(arch) systemd; \ rpm2cpio systemd*.$(arch).rpm | cpio -id ; \ cp usr/lib/systemd/system/emergency.service /usr/lib/systemd/system; \ cp usr/lib/systemd/system/rescue.service /usr/lib/systemd/system; ); \ rm -fr /tmp/dracut-fixup # for i in 10-console.rules 10-dm.rules 11-dm.rules 13-dm-disk.rules \ 40-multipath.rules 50-firmware.rules 50-udev-default.rules 50-udev.rules \ 59-persistent-storage.rules 60-cdrom_id.rules 60-pcmcia.rules \ 60-persistent-storage.rules 61-dmraid-imsm.rules \ 61-persistent-storage-edd.rules 61-persistent-storage.rules \ 64-device-mapper.rules 64-lvm.rules 64-md-raid.rules \ 65-md-incremental-imsm.rules 71-biosdevname.rules \ 80-btrfs.rules 80-drivers.rules 95-dm-notify.rules 95-late.rules \ 95-udev-late.rules ; do [[ -f $i ]] rm -vf /etc/udev/rules.d/$i; done # rm -f /etc/os-release; mkdir /tmp/dracut-fixup; \ ( cd /tmp/dracut-fixup; yumdownloader fedora-release; \ rpm2cpio fedora-release*.rpm | cpio -id ; cp etc/os-release /etc ); \ rm -fr /tmp/dracut-fixup -- Works for me, thanks! Booted up kernel-3.5.0-0.rc3.git0.2.fc18.x86_64. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta jspal...@gmail.com wrote: On Mon, Jun 25, 2012 at 5:36 AM, Tom London seli...@gmail.com wrote: Hmm... Still seeing spew: Here is what I did: 1. I 'rpm -Uvh --force' the new package. 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had saved them by moving them to revelation.old before updating/testing with the previous test build). 3. I rebooted and started revelation 4. Edit-Preferences I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and reboot/etc. it will work... I'd image the problem in your steps is the fact that you did 2 after 1. Get your system into the old state with the old 0.4.11 revelation update to new rpm logout/log back in. tracebacks should stop. I've tested this on a couple of systems now. -jef Oops Sorry for the fumble. Will redo and report tonight. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Mon, Jun 25, 2012 at 11:22 AM, Tom London seli...@gmail.com wrote: On Mon, Jun 25, 2012 at 9:46 AM, Jef Spaleta jspal...@gmail.com wrote: On Mon, Jun 25, 2012 at 5:36 AM, Tom London seli...@gmail.com wrote: Hmm... Still seeing spew: Here is what I did: 1. I 'rpm -Uvh --force' the new package. 2. I 'recovered' my old ~/.gconf/apps/revelation/ settings (I had saved them by moving them to revelation.old before updating/testing with the previous test build). 3. I rebooted and started revelation 4. Edit-Preferences I'm guessing if I nuke the ~/.gconf/apps/revelelation/ dir and reboot/etc. it will work... I'd image the problem in your steps is the fact that you did 2 after 1. Get your system into the old state with the old 0.4.11 revelation update to new rpm logout/log back in. tracebacks should stop. I've tested this on a couple of systems now. -jef Oops Sorry for the fumble. Will redo and report tonight. tom -- Tom London Must be something 'interesting' about my conf files This still fails for me: Traceback (most recent call last): File /usr/bin/revelation, line 206, in lambda action.connect(activate, lambda w: self.prefs()) File /usr/bin/revelation, line 1527, in prefs dialog.run_unique(Preferences, self, self.config) File /usr/lib64/python2.7/site-packages/revelation/dialog.py, line 1324, in run_unique d = create_unique(dialog, *args) File /usr/lib64/python2.7/site-packages/revelation/dialog.py, line 1282, in create_unique UNIQUE_DIALOGS[dialog] = dialog(*args) File /usr/bin/revelation, line 1623, in __init__ self.__init_section_password(self.page_general) File /usr/bin/revelation, line 1762, in __init_section_password ui.config_bind(self.config, passwordgen/punctuation, self.check_punctuation_chars) File /usr/lib64/python2.7/site-packages/revelation/ui.py, line 182, in config_bind id = cfg.monitor(key, cb_get, widget) File /usr/lib64/python2.7/site-packages/revelation/config.py, line 150, in monitor callback(key, self.get(key), userdata) File /usr/lib64/python2.7/site-packages/revelation/config.py, line 129, in get raise ConfigError ConfigError I copied my 'old' conf files from a backup, reinstalled via 'rpm -Uvh --force', rebooted, and started revelation. Something useful I can do? (or just blow the conf dir away?) tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Revelation password manager issue
On Sun, Jun 24, 2012 at 12:57 PM, Jef Spaleta jspal...@gmail.com wrote: Rawhide target scratch build of the upstream tree with the fix. http://koji.fedoraproject.org/koji/taskinfo?taskID=4191839 I have done a local build and test on an F16 system. Revelation informs me that the key file is an old encryption format and requests me to resave to update the encryption. Can someone please do an independent confirmation that this actually fixes the underlying issues with the encryption weakness? There appears to be one potential regression in 0.14.3+ with searching...but I think its due to a change in gconf key layout. If you experience the search crash...logout/login or shutdown/restart and the problem appears to go away. I saw the crash last week on F16 and F17 while I was doing initial testing for 0.14.3 test packages that I rolled ahead of this security fix landing...but I could not duplicate the search traceback again after a system restart... making it a bit difficult to track down and squash. AnywaysI'm inclined to wait for the official release tarball to land from upstream tomorrow to push update packages into rawhide-F17,F16 testing for release 0.14.4 that rolls in the encryption changes. In the meantime anyone who is seriously concerned about this, please beat on the on the scratch build and make sure its actually a fix. -jef -- Haven't checked the crypto changes, but I do notice this spew when I try 'Edit-Preferences': Traceback (most recent call last): File /usr/bin/revelation, line 206, in lambda action.connect(activate, lambda w: self.prefs()) File /usr/bin/revelation, line 1527, in prefs dialog.run_unique(Preferences, self, self.config) File /usr/lib64/python2.7/site-packages/revelation/dialog.py, line 1324, in run_unique d = create_unique(dialog, *args) File /usr/lib64/python2.7/site-packages/revelation/dialog.py, line 1282, in create_unique UNIQUE_DIALOGS[dialog] = dialog(*args) File /usr/bin/revelation, line 1623, in __init__ self.__init_section_password(self.page_general) File /usr/bin/revelation, line 1762, in __init_section_password ui.config_bind(self.config, passwordgen/punctuation, self.check_punctuation_chars) File /usr/lib64/python2.7/site-packages/revelation/ui.py, line 182, in config_bind id = cfg.monitor(key, cb_get, widget) File /usr/lib64/python2.7/site-packages/revelation/config.py, line 150, in monitor callback(key, self.get(key), userdata) File /usr/lib64/python2.7/site-packages/revelation/config.py, line 129, in get raise ConfigError ConfigError tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: One big old problem and one new with Rawhide
On Sat, Jul 16, 2011 at 1:49 PM, Lucas macach...@gmail.com wrote: One big problem is that my laptop can't go through systemd startup with selinux enabled. Boot hangs at random points - setup keyboard, stdio syslog bridge, kernel variables. Laptop just hangs, nothing happens and all I can do it turn it off. The only way is to add selinux=0. Its usually better to add enforcing=0 rather than selinux=0. enforcing=0 keeps files appropriately labeled. The second one that raises today - I can't log in at all - nor with root nor with user. I reported yesterday about: [ 37.654015] [ INFO: possible recursive locking detected ] [ 37.654015] 3.0-0.rc7.git0.1.fc16.i686 #1 [ 37.654015] - [ 37.654015] systemd-logind/651 is trying to acquire lock: And yesterday I was able to log into user and root account, today I can't - it looks like it checks the password, because it reports if it is wrong, when I type the right one it hangs again. May be system can't start console (I was trying to do it in level 3). What I can do with it? Need advice. Thanks. Not sure, but my Rawhide system is booting to gnome just fine with enforcing=0. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: One big old problem and one new with Rawhide
On Sat, Jul 16, 2011 at 2:15 PM, Lucas macach...@gmail.com wrote: On 07/17/2011 01:03 AM, Tom London wrote: On Sat, Jul 16, 2011 at 1:49 PM, Lucasmacach...@gmail.com wrote: One big problem is that my laptop can't go through systemd startup with selinux enabled. Boot hangs at random points - setup keyboard, stdio syslog bridge, kernel variables. Laptop just hangs, nothing happens and all I can do it turn it off. The only way is to add selinux=0. Its usually better to add enforcing=0 rather than selinux=0. enforcing=0 keeps files appropriately labeled. enforcing=0 doesn't help me, system hangs. I installed XFCE spin and then upgrade it to Rawhide, I do not have gnome because I hate it. I turned off enforcing when I start to test it, but selinux doesn't report anything, may be selinux can't do its job with new kernels, because system hangs in different points. -- Sorry, not enough info to help much more Do you have a stock system system? Did you try booting with the 'rhgb quiet' options removed and 'debug' added? Any unexpected messages? ... etc.? -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Sat, Jun 11, 2011 at 9:29 AM, Lucas macach...@gmail.com wrote: I can only boot if selinux is disabled - selinux=0 in grub. Otherwise boot always stops in different moments. I can't figured out which problem is this - selinux or systemd? -- Does this sound like it? https://bugzilla.redhat.com/show_bug.cgi?id=711015 If so, you need a newer systemd. systemd-28-3.fc16.x86_64 works for me. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:19 AM, Bruno Wolff III br...@wolff.to wrote: The 3.0 kernels are not working for me. (A cpu lockup is reporting during boot.) I am wondering if things are broken for everyone where I should probably just wait for updates and try again, or if I should get a picture of the traceback and file a bug? -- Boots for me on Thinkpad X200 with SELinux enforcing. gdm-greeter screen is scrambled, but if I blindly enter login/password, gnome comes up just fine. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Are 3.0 kernels working for anyone?
On Fri, Jun 10, 2011 at 11:54 AM, Jerry James loganje...@gmail.com wrote: On Fri, Jun 10, 2011 at 12:19 PM, Bruno Wolff III br...@wolff.to wrote: The 3.0 kernels are not working for me. (A cpu lockup is reporting during boot.) I am wondering if things are broken for everyone where I should probably just wait for updates and try again, or if I should get a picture of the traceback and file a bug? I've been using today's x86_64 Rawhide kernel with no problems. I had to attempt a boot 6 times before I finally got the i686 version off the ground, though. Twice udev segfaulted during boot, and I got some kind of lockup (perhaps what you are seeing) on the other 3 attempts. But the 6th time, it worked great. Unlike Tom's experience, the gdm login screen looked fine for me on both x86_64 and i686. -- Jerry James http://www.jamezone.org/ Didn't mention: exclusively using x86_64 version. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linux kernel 3.0 + SELinux problem
On Wed, Jun 8, 2011 at 3:52 PM, Jerry James loganje...@gmail.com wrote: I'm having some kind of problem with SELinux on the Rawhide 3.0 kernels. The boot process gets stuck loading the SELinux policy over and over again. I get a long series of messages like this for a few minutes: [ timestamp] type=1403 audit(various numbers): policy loaded auid=4294967295 ses=4294967295 Then something times out, I think. It always scrolls by too quickly for me to read it, but it looks like a typical stuck process kernel backtrace. Then I get some variety, and start seeing an endless parade of these: [ timestamp] type=1403 audit(various numbers): policy loaded auid=4294967295 ses=4294967295 [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. [ timestamp] SELinux: 2048 avtab hash slots, 223865 rules. [ timestamp] SELinux: 9 users, 13 roles, 3663 types, 193 bools, 1 sens, 1024 cats [ timestamp] SELinux: 81 classes, 223865 rules Well, at least I guess it's endless. I've let it go for as long as 10 minutes in the hope that something else would happen. I've tried both kernel 3.0-0.rc1.git0.2 and kernel 3.0-0.rc2.git0.1 and have the same problem with both. I touched /.autorelabel and rebooted with the last 2.6.39 kernel, but that didn't help. The only way I can boot these kernels is to use selinux=0 on the boot line. I'm seeing this on 2 virtual machines, one x86_64 and one i686, both with fully updated Rawhide as of today and (almost) the same set of packages installed. Both yum upgrade and package-cleanup --orphans show nothing to do. On both, after booting with selinux=0, systemctl --failed lists 0 units. Both started life as F-14 machines, became F-15 Alpha and then F-15 Beta boxes, and were upgraded to Rawhide after the release of F-15. It's possible some configuration got screwed up along the way. If anyone has a theory about what's going on, I'm all ears. Thanks, -- Jerry James http://www.jamezone.org/ See https://bugzilla.redhat.com/show_bug.cgi?id=711015 Believe updated systemd is building. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sun, Sep 26, 2010 at 9:45 AM, darrell pfeifer darrel...@gmail.com wrote: On Sun, Sep 26, 2010 at 09:30, Tom London seli...@gmail.com wrote: On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer darrel...@gmail.com wrote: On Sat, Sep 25, 2010 at 11:55, Owen Taylor otay...@redhat.com wrote: On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (core dumped) There also seem to be problems with nautilus from GTK+ ABI changes - I see various warnings along the lines of: (nautilus:27082): GLib-GObject-WARNING **: specified class size for type `EvPropertiesView' is smaller than the parent type's `GtkVBox' class size These indicate a definite need for rebuild, so I'll kick one off now, and maybe things will be better after that finishes. It's certainly not worth worrying about anything related to Nautilus until it's rebuild. The newer version still dies. It seemed to work for a while but segfaults again. Also, sftp doesn't work any more. Interestingly enough, it doesn't segfault under KDE. darrell -- Does this sound like your segfaults: https://bugzilla.redhat.com/show_bug.cgi?id=636543 I'm guessing that is some change in the gtk3 interface... I haven't run a stack trace on mine, so I can't be sure. Your guess might be accurate though. I also notice that chrome has been segfaulting with annoying frequency which is strange because it has been very stable for me. darrell -- Interesting. I just locally patched gtk3 (as described here: https://bugzilla.redhat.com/show_bug.cgi?id=636543), and now 'automounting' appears to be working as usual: the nice nautilus window with the device's root directory opens as expected. I'm running: nautilus-2.90.1-5.gitf3bbee7.fc15.x86_64 gtk3-2.90.7-2.local.fc15.x86_64 --- this is the 'patched' gtk3. I don't know if this is the 'right' patch, but this appears to indicate (at least part of) a problem. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer darrel...@gmail.com wrote: On Sat, Sep 25, 2010 at 11:55, Owen Taylor otay...@redhat.com wrote: On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (core dumped) There also seem to be problems with nautilus from GTK+ ABI changes - I see various warnings along the lines of: (nautilus:27082): GLib-GObject-WARNING **: specified class size for type `EvPropertiesView' is smaller than the parent type's `GtkVBox' class size These indicate a definite need for rebuild, so I'll kick one off now, and maybe things will be better after that finishes. It's certainly not worth worrying about anything related to Nautilus until it's rebuild. The newer version still dies. It seemed to work for a while but segfaults again. Also, sftp doesn't work any more. Interestingly enough, it doesn't segfault under KDE. darrell -- Does this sound like your segfaults: https://bugzilla.redhat.com/show_bug.cgi?id=636543 I'm guessing that is some change in the gtk3 interface... tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 9:16 AM, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Hi, What is going on with Nautilus? It's not been usable for quite a while now. Most recently, I've had it working by starting it from a terminal window but now even that has stopped working and is giving me the following Gtk-Message: Failed to load module pk-gtk-module: libpk-gtk-module.so: cannot open shared object file: No such file or directory Gtk-Message: Failed to load module gail-gnome: libgail-gnome.so: cannot open shared object file: No such file or directory (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to lookup signal select of unloaded type `GtkMenuItem' (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: assertion `signal_id 0' failed (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to lookup signal deselect of unloaded type `GtkMenuItem' (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: assertion `signal_id 0' failed Initializing nautilus-gdu extension (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (core dumped) (this is the same if I use nautilus -n [then double click on a drive icon] or nautilus with no arguments) Any ideas on what is going on? I last updated the machine last night and things seem to have gone wrong since about Tuesday (last update on koji). I did think it was related to the gir rebuilds, but that doesn't seem to be the case. HELP TTFN Paul P.S. I have both .so files installed... -- Vertraue mir, ich weiss, was ich mache... I've been running rawhide nautilus for a while (currently nautilus-2.90.1-4.gitf3bbee7.fc15.x86_64), and although there are some 'rough edges', it works well enough for me. Here are some things I've noticed: 1. Nautilus no longer displays the desktop; believe I got some indication that this was part of the move to a newer desktop 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb drives, hard drives, etc.). However, the device does appear in 'Places', and it mounts if you select it there. 3. Nautilus segfaults trying to open the device's root folder after selecting in 'Places': https://bugzilla.redhat.com/show_bug.cgi?id=636543 . But the device is mounted properly tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 11:19 AM, Owen Taylor otay...@redhat.com wrote: On Sat, 2010-09-25 at 09:31 -0700, Tom London wrote: 1. Nautilus no longer displays the desktop; believe I got some indication that this was part of the move to a newer desktop Since you aren't actually running the newer desktop (GNOME Shell is temporarily not working in Rawhide, we'll get it fixed this week, and the file management isn't fully there yet in any case), you can showing the desktop back on with: gconftool -s -t bool /apps/nautilus/preferences/show_desktop true Of course, that once you've set that key you'll no longer get the default experience. (See: http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00033.html for some discussion of the desktop situation) 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb drives, hard drives, etc.). However, the device does appear in 'Places', and it mounts if you select it there. This is a fairly long-standing bug related to turning off show_desktop - the automounting is part of the Nautilus process, and when not showing the desktop, Nautilus just exits when there are no windows. See: https://bugzilla.gnome.org/show_bug.cgi?id=585545 - Owen Thanks for the update Think I'll wait for the newer gnome-shell. I sort of got hooked on the compiz eye-candy. Any idea if that (e.g., wobbly windows, rotating cube, ...) will be part of the new gnome-shell experience? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus misbehaving
On Sun, Aug 29, 2010 at 9:49 AM, Paul F. Johnson p...@all-the-johnsons.co.uk wrote: Hi, After the recent rawhide to nautilus 2.90.1-1.fc15.i686, it's stopped working claiming that I don't have Settings schema 'org.gnome.desktop.lockdown' installed. What is this and how do I fix the problem? TTFN Paul Not sure about your problem, but here is where that schema comes from: [...@tlondon ~]$ rpm -qif /usr/share/glib-2.0/schemas/org.gnome.desktop.lockdown.gschema.xml Name: gsettings-desktop-schemasRelocations: (not relocatable) Version : 0.0.1 Vendor: Fedora Project Release : 2.fc15Build Date: Tue 24 Aug 2010 01:59:22 PM PDT Install Date: Wed 25 Aug 2010 06:20:01 AM PDT Build Host: x86-03.phx2.fedoraproject.org Group : System Environment/Libraries Source RPM: gsettings-desktop-schemas-0.0.1-2.fc15.src.rpm Size: 49344License: LGPLv2+ Signature : (none) Packager: Fedora Project URL : http://bugzilla.gnome.org/enter_bug.cgi?product=gsettings-desktop-schemas Summary : A collection of GSettings schemas Description : gsettings-desktop-schemas contains a collection of GSettings schemas for settings shared by various components of a desktop. [...@tlondon ~]$ Nautilus appears not to be starting on login for me; I need to start it manually via 'nautilus --no-default-window'. BZ'ed here: https://bugzilla.redhat.com/show_bug.cgi?id=627639 tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: is it still possible to use upstart as the init-system in F-14?
On Wed, Aug 25, 2010 at 4:45 PM, M A Young m.a.yo...@durham.ac.uk wrote: On Wed, 25 Aug 2010, Rahul Sundaram wrote: On 08/25/2010 05:35 PM, M A Young wrote: Yes, upstart still works. I tried systemd and couldn't get it to work, so I switched the machine back to upstart. You may need a rescue disk to make the switch if your computer doesn't boot with systemd. I might try systemd again when more of the bugs have been ironed out. Do you have any unreported bugs? I tried it again, and basically the boot doesn't ever finish, it just sits there without any useful indication as to what the problem is until I get fed up and use the sysrq keys to reboot it ctrl-alt-del doesn't work). Michael Young -- This sounds like a previously discussed issue with upgrading a system to systemd. Referring to Lennart's HEADS UP: Heya, just a little heads up for when you upgrade a rawhide system that is a few weeks old to current rawhide: since we changed the way how some of the default symlinks of systemd are created you will end up with an installation that lacks many of the necessary symlinks -- but only if you upgrade from a systemd version from older rawhide to current rawhide. It's really only a problem in this case. It is not a problem with fresh F14 installations, and it is not a problem with upgrades from F13. The fix is easy: after upgrading just run this command as root and the missing links should be created: # systemctl enable ge...@.service prefdm.service getty.target rc-local.service remote-fs.target And that should make things work again. Sorry for the late heads-up. Lennart Could this fix your boot hang? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update means only runlevel 1
On Fri, Jan 29, 2010 at 3:11 PM, darrell pfeifer darrel...@gmail.com wrote: i did an update this morning that took my machine from current rawhide to a few koji updates. included were dracut, udev and i memory serves me right, a minor initscript cleanup. now i can't get any farther than runlevell 1. going to even runlevel 3 hangs. any suggestions of what might be broken? (sorry for the brevity, typing on an inconvenient box) darrell Could this be it: https://bugzilla.redhat.com/show_bug.cgi?id=560031 ? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
