Re: A question about "Software rendering for gnome-shell"
On Thu, 2012-02-23 at 19:40 -0700, Michal Jaegermann wrote: > On Thu, Feb 23, 2012 at 11:43:22AM -0800, Adam Williamson wrote: > > On Thu, 2012-02-23 at 09:54 -0500, Adam Jackson wrote: > > > > > > For comparison: > > > > > > > > 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 > > > > > > > > Fine. System Monitor CPU at 19%. > > > > > > That's still way higher than I'd like, but it's at least an r300g bug > > > not an llvmpipe bug. > > > > Remember that CPU usage is inherently going to be higher than usual when > > running a debug kernel. > > As I wrote before I tried that also with 3.3.0-0.rc4.git1.4.fc17.x86_64 > (the latest for FC17 at that time) with no real difference. If this one > is "debug" then how recognize one which is not? Remember that it has to > support llvmpipe. Almost all FC17 kernels are debug kernels. A quick way to tell if you're using one is: grep -i CONFIG_ACPI_DEBUG /boot/config-`uname -r` 'not set' = release kernel. 'Y' = debug kernel. The kernel team is building one kernel per upstream kernel release (I think that's it) as 'release' not 'debug', but you can quite easily rebuild a kernel as 'release' instead of 'debug' yourself - just check out the kernel package from git, do 'make release', then build it however you like - e.g. 'fedpkg srpm' then 'fedpkg scratch-build'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: VirtualBox and test releases
On Thu, 2012-02-23 at 16:00 -0500, Claude Jones wrote: > I'm trying to test Fedora 17 RC4 in a Virtual Box environment. I had > problems doing this with F16 as well. It is up and running, but > tortuously slow. I noticed that it complained when I was installing the > guest additions about the 'experimental x' version. Every aspect of what > I do is slow; bootup takes many minutes, logging in takes over a couple > of minutes, opening windows or programs, everything. I'm running the > latest version of VirtualBox from Oracle on a Win7 machine with an i5 > CPU and 4 GB of ram. I've allocated 2 GB to the Fedora VM. Does anyone > else have this problem? As ajax says, check if you're getting software rendering of GNOME Shell, which is likely to be slow: if so you can force fallback mode from a VT, much faster than trying to get through the control center, with this command: gsettings set org.gnome.desktop.session session-name 'gnome-fallback' run it as user - not root - then log out and back in again. Aside from that, though, there is a known bug with the kernel in Alpha which causes slowness on some systems, it's possible it affects VirtualBox 'machines' too. See https://bugzilla.redhat.com/show_bug.cgi?id=795050 . The latest kernel build fixes that issue: https://admin.fedoraproject.org/updates/FEDORA-2012-2304/kernel-3.3.0-0.rc4.git1.4.fc17 so grab that and see if it helps. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: RC4 and NFS
On Thu, Feb 23, 2012 at 4:55 AM, Chuck Forsberg WA7KGX N2469R wrote: > > Here is the relevant /etc/exports entry in my server: > / 192.168.1.1/255.255.255.0(rw,async) > > Here is the screen capture from RC4 64 bit Xfce session: > [root@omen3 /]# mount 192.168.1.13:/ /o > mount.nfs: No such device > [root@omen3 /]# > > FWIW the /etc/exports has not been changed since November, > and the "mount 192.168.1.13:/ /o" where .o exists has worked > on client Fedoras for years until now. "nfs" must not be loaded; run "modprobe nfs". -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On 02/23/2012 09:54 AM, Adam Jackson wrote: On Thu, 2012-02-23 at 08:44 -0500, mwesten wrote: Fedora-17-Alpha-i686-Live-Desktop.iso (RC2) on USB 2.13GHz AthlonXP 2600+ / RV200 (Radeon 7500) / 1280x1024 Fallback mode is fine, but once the shell starts, it's a battle just to get System Monitor open and to the Resources tab. Once there, the CPU sits at 100% until I get off that tab. Very high latency, screen flickering, artifacts, incomplete rendering... "Incomplete" is worrisome, I've not seen that. OK, let me (try to) clarify all that with an example. Say I have a terminal window open. I click and drag it somewhere. A few seconds later, it "jumps" to the new location. Then it quickly jumps back to where it started. Sometimes it just leaves a piece behind, and other times the whole window reappears at the new location, so there are two. (!) Switching modes or bouncing out to a VC and back will make it redraw correctly. This is only on the *really* slow one now (RV200). The others don't do any of whatever that is... There's a bit of a quantum effect here where the act of drawing the CPU monitor necessarily raises CPU load. If you ssh into the machine and run top from there, gnome-shell and Xorg shouldn't be taking any undue load at idle. If they are, that means there's rendering happening at idle, which is a legitimate bug that would affect even accelerated drivers by keeping the GPU from going to sleep to save power. I'm just using the monitor as an easy way of loading and comparing the systems. I did check and the idle load is very low, so no issue there. In the non-steady-state, though, the current implementation is known to be incredibly memcpy-heavy. Fixes coming soon, beta should be much better I hope. If you want to collect some data about where CPU time is being spent, 'perf record' against the X server or gnome-shell (with debuginfo installed) and then 'perf report' should be enlightening. I suspect you'll find the vast majority of the time spent in memcpy in one form or another (pixman or fb blit, copying data into and out of the kernel across the unix socket, etc). I'll see what I can do. -Mike -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On 02/23/2012 02:43 PM, Adam Williamson wrote: On Thu, 2012-02-23 at 09:54 -0500, Adam Jackson wrote: For comparison: 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 Fine. System Monitor CPU at 19%. That's still way higher than I'd like, but it's at least an r300g bug not an llvmpipe bug. Remember that CPU usage is inherently going to be higher than usual when running a debug kernel. I usually find any kind of mouse movement in X on a debug kernel runs my CPU to 10-20%, and that's an overclocked core i7-2600k (!). On a release kernel, no such effect. Understood. I wasn't complaining about it. It's there as something of baseline for the the others. Same code, same test, comparable hardware (to an extent), but no soft3D. -Mike -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On Thu, Feb 23, 2012 at 11:43:22AM -0800, Adam Williamson wrote: > On Thu, 2012-02-23 at 09:54 -0500, Adam Jackson wrote: > > > > For comparison: > > > > > > 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 > > > > > > Fine. System Monitor CPU at 19%. > > > > That's still way higher than I'd like, but it's at least an r300g bug > > not an llvmpipe bug. > > Remember that CPU usage is inherently going to be higher than usual when > running a debug kernel. As I wrote before I tried that also with 3.3.0-0.rc4.git1.4.fc17.x86_64 (the latest for FC17 at that time) with no real difference. If this one is "debug" then how recognize one which is not? Remember that it has to support llvmpipe. > I usually find any kind of mouse movement in X > on a debug kernel runs my CPU to 10-20%, In any case dropping CPU usage by 10-20% would not be really significant in the context. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: VirtualBox and test releases
On 2/23/2012 5:21 PM, Andre Robatino wrote: Claude Jones tehogeeservices.com> writes: Thanks for your reply. I'm not sure I understand it. Are you saying that I should open a terminal and issue that 'export' command, then run the installation of guest additions again? Yes. If you're building Guest Additions in F17 or Rawhide and don't issue that command first, you'll probably get an OpenGL-associated error - see http://freeoracletrainings.com/index.php/blogs/item/15-install-guest-additions-building-the-opengl-support-module-failed If you issue the command beforehand, it should prevent it. I don't know where the fault for this is (Fedora or Oracle). OK - I'll give that a shot tomorrow - machine is at work and I'm going home -- Claude Jones Brunswick, MD, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
VirtualBox and test releases
Claude Jones tehogeeservices.com> writes: > Thanks for your reply. I'm not sure I understand it. Are you saying that > I should open a terminal and issue that 'export' command, then run the > installation of guest additions again? Yes. If you're building Guest Additions in F17 or Rawhide and don't issue that command first, you'll probably get an OpenGL-associated error - see http://freeoracletrainings.com/index.php/blogs/item/15-install-guest-additions-building-the-opengl-support-module-failed If you issue the command beforehand, it should prevent it. I don't know where the fault for this is (Fedora or Oracle). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: VirtualBox and test releases
On Thu, 2012-02-23 at 16:00 -0500, Claude Jones wrote: > I'm trying to test Fedora 17 RC4 in a Virtual Box environment. I had > problems doing this with F16 as well. It is up and running, but > tortuously slow. I noticed that it complained when I was installing the > guest additions about the 'experimental x' version. VirtualBox insists that they can't possibly have stable upstreamable X drivers, because they don't want to have internal ABI compatibility between their virtual GPU and their drivers, because waa that's so hard. Therefore you're probably falling onto the (still very unoptimized) llvmpipe path for software gnome-shell. Feel free to ask VirtualBox when they're going to learn how ABI compatibility works. Until then I can't possibly recommend using VirtualBox to run experimental guests OSes. (Even then I still wouldn't recommend running VirtualBox, but that's just me preferring to run code that doesn't make me vomit to read.) - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: VirtualBox and test releases
On 2/23/2012 4:12 PM, Andre Robatino wrote: Claude Jones tehogeeservices.com> writes: I'm trying to test Fedora 17 RC4 in a Virtual Box environment. I had problems doing this with F16 as well. It is up and running, but tortuously slow. I noticed that it complained when I was installing the guest additions about the 'experimental x' version. Every aspect of what I do is slow; bootup takes many minutes, logging in takes over a couple of minutes, opening windows or programs, everything. I'm running the latest version of VirtualBox from Oracle on a Win7 machine with an i5 CPU and 4 GB of ram. I've allocated 2 GB to the Fedora VM. Does anyone else have this problem? Yes, for me with VirtualBox 4.1.8, the F15 and F16 guests are reasonably fast, but the F17 and Rawhide guests are very slow. I get gnome shell using hardware passthrough on the F15 and F16 guests, but am unsure whether that's the case on the F17 and Rawhide guests, or if it's using software rendering. Presumably hardware passthrough would be faster. I also found that building the Guest Additions automatically using dkms as described in http://www.virtualbox.org/manual/ch04.html#idp11277648 works in F15 and F16 but not in F17 or Rawhide, so I have to do it manually there. If you get an error building the OpenGL extensions, you can work around that by issuing the command export MAKE='/usr/bin/gmake -i' before installing the Guest Additions. Thanks for your reply. I'm not sure I understand it. Are you saying that I should open a terminal and issue that 'export' command, then run the installation of guest additions again? -- Claude Jones Brunswick, MD, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Experiences with F17-Alpha-RC4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2012 04:03 PM, Joachim Backes wrote: > On 02/23/2012 08:13 PM, Daniel J Walsh wrote: >> On 02/23/2012 05:31 AM, Joachim Backes wrote: >>> On 02/23/2012 08:32 AM, Joachim Backes wrote: Hi, I made a fresh F17 desktop (gnome3) installation on my box to a real partition with F17/Alpha/RC4: No problems during install, the system runs immediately. Applying all available updates. But there are some flaws: 3. One ugly problem after quitting a gnome3 session: logging in again (via gdm login window) shows in most cases the well know "Oh nO! something has gone wrong, logout!" dialog. Searching a little bit in /var/log/messages, I saw that there are some (unspecified) problems with /run/user/ and/or dot files in /tmp. I could get rid from these login problems by removing some files as /tmp/.ICE-unix /tmp/.X11-unix /tmp/.X0-lock /run/user/ and then login again > >>> I could get rid from the problems in 3. by setting >>> "SELINUX=permissive" in /etc/selinux/config > > > > >> Are you seeing avc messages? > > I'm sorry, nothing. > > >> ausearch -m avc -ts recent > > > > > > Turn off dontaudit rules with # semodule -DB And try to login again. Collect AVC's and send them to me. # semodule -B To turn back on dontaudit rules. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Gs0MACgkQrlYvE4MpobPLSQCgjlqVRxVenlRAX5itBKoTm199 QL8AoN41FlgKvuLo5tMqpx0Be5cAFNcx =/+up -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
VirtualBox and test releases
Claude Jones tehogeeservices.com> writes: > I'm trying to test Fedora 17 RC4 in a Virtual Box environment. I had > problems doing this with F16 as well. It is up and running, but > tortuously slow. I noticed that it complained when I was installing the > guest additions about the 'experimental x' version. Every aspect of what > I do is slow; bootup takes many minutes, logging in takes over a couple > of minutes, opening windows or programs, everything. I'm running the > latest version of VirtualBox from Oracle on a Win7 machine with an i5 > CPU and 4 GB of ram. I've allocated 2 GB to the Fedora VM. Does anyone > else have this problem? Yes, for me with VirtualBox 4.1.8, the F15 and F16 guests are reasonably fast, but the F17 and Rawhide guests are very slow. I get gnome shell using hardware passthrough on the F15 and F16 guests, but am unsure whether that's the case on the F17 and Rawhide guests, or if it's using software rendering. Presumably hardware passthrough would be faster. I also found that building the Guest Additions automatically using dkms as described in http://www.virtualbox.org/manual/ch04.html#idp11277648 works in F15 and F16 but not in F17 or Rawhide, so I have to do it manually there. If you get an error building the OpenGL extensions, you can work around that by issuing the command export MAKE='/usr/bin/gmake -i' before installing the Guest Additions. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Experiences with F17-Alpha-RC4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2012 08:13 PM, Daniel J Walsh wrote: > On 02/23/2012 05:31 AM, Joachim Backes wrote: >> On 02/23/2012 08:32 AM, Joachim Backes wrote: >>> Hi, >>> >>> I made a fresh F17 desktop (gnome3) installation on my box to >>> a real partition with F17/Alpha/RC4: No problems during >>> install, the system runs immediately. Applying all available >>> updates. >>> >>> But there are some flaws: >>> >>> >>> 3. One ugly problem after quitting a gnome3 session: logging >>> in again (via gdm login window) shows in most cases the well >>> know "Oh nO! something has gone wrong, logout!" dialog. >>> Searching a little bit in /var/log/messages, I saw that there >>> are some (unspecified) problems with /run/user/ and/or >>> dot files in /tmp. I could get rid from these login problems by >>> removing some files as >>> >>> /tmp/.ICE-unix /tmp/.X11-unix /tmp/.X0-lock /run/user/ >>> >>> and then login again > >> I could get rid from the problems in 3. by setting >> "SELINUX=permissive" in /etc/selinux/config > > > > > Are you seeing avc messages? I'm sorry, nothing. > > ausearch -m avc -ts recent > > - -- Joachim Backes http://www.rhrk.uni-kl.de/~backes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPRqmJAAoJEOC2Jvxd+P1oPloP/0G64uDfRxE8t8Tw0YiIvvy3 t19Y7rOMZKdpCgeC60nVPtrB6I4s7H7eXD1zdpzx7Iv/EEYcDt8IHf5T6CP3GkbK xp0ewy4244VjVUIwmq6VyXaWtg3omxQ3sG5yEyc865BSRUiasQeyXqoRi+ibXlKQ q2fidMlXn7U7j4cXOCgp5hsQ22GapQ2W3bfJus/dysFpiHlZDvjTVUEKr61BMFM/ q5ofhIGg6qHqEXLamDQeRAyipZEhfRddmxYXPTQWwTX1eHkCY0mbIR2LsMwg2u7J eEbQWl/d494yhGtQtzkUr5SvcWSe3uN+7bvOt0OPuPnyYwIYT6dTGhKOyoyVm8px 6oLfJmguqB+D6HZsAhp1AbQVqbr7QZ9fDCUYYG3Ik/sg2BP2Dvp7vqniWsznlMmT oD0/KZ6QkDPs8OGfAdK3E2Jr1yIo5mVSnKHBHaLWWUG/Gac7o4n/nAJOz//gzg+e MLtnOZzH+lGxQqTIDuOrjoZelw717ls6EsHV/QXgG0zuu1NEx6ccSMScpCXpOT9b WS/KCnXsE269eUJueAHVGa4WKpmlmPv/F9P7qz8RQcfEIQ/0Ujz+OfC3E/GWEPi6 xKHOe8GojSGxX1259tEfTHlQO4sZt//W4TGnojdHCTuUqRsyUYqPhzVGFiaGmuUn mQSrsr2piPycO8WBDQrw =bRc3 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
VirtualBox and test releases
I'm trying to test Fedora 17 RC4 in a Virtual Box environment. I had problems doing this with F16 as well. It is up and running, but tortuously slow. I noticed that it complained when I was installing the guest additions about the 'experimental x' version. Every aspect of what I do is slow; bootup takes many minutes, logging in takes over a couple of minutes, opening windows or programs, everything. I'm running the latest version of VirtualBox from Oracle on a Win7 machine with an i5 CPU and 4 GB of ram. I've allocated 2 GB to the Fedora VM. Does anyone else have this problem? -- Claude Jones Brunswick, MD, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Thu, 2012-02-23 at 14:14 -0600, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > On Thu, 2012-02-23 at 09:40 -0600, Chris Adams wrote: > > > That's what I used to do, but it didn't work for me with F16 and GRUB2. > > > I get a warning that I shouldn't install GRUB2 to a partition and then > > > an error about there not being enough space. > > > > You can use --force to make grub2 install to a partition. > > If I run "grub2-install /dev/sda6", I get: > > /sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk > or to a partition. This is a BAD idea.. > /sbin/grub2-setup: error: embedding is not possible, but this is required for > cross-disk install. > > --force makes no difference. > > /dev/sda6 is actually part of a software RAID1; "grub2-install /dev/md3" > segfaults. Somebody else has already put this in BZ as 788830. Yep, sounds like the RAID thing is your issue, not the install-to-partition thing. I'm not sure if grub2 is actually capable of being written to the first sector of a RAID device at all. pjones may know. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: unable to run tests requiring "updates=http://jlaska.fedorapeople.org/updates/traceback.img" option
Kamil Paral redhat.com> writes: > Thanks, Andre. Please report it as a bug. > (and try scp manually whether it works) I was wrong - it DOES send the file to the remote system. The problem is that if you don't specify the name of the file on the remote system (which people wouldn't normally bother doing) instead of using the original name (like abrt-upload-2012-02-23-19:56:43-583.tar.gz), it just uses "tmp", which is easy to overlook (especially when you're sending it to the directory /tmp on the remote system). Reported as https://bugzilla.redhat.com/show_bug.cgi?id=796899 . -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
Once upon a time, Adam Williamson said: > On Thu, 2012-02-23 at 09:40 -0600, Chris Adams wrote: > > That's what I used to do, but it didn't work for me with F16 and GRUB2. > > I get a warning that I shouldn't install GRUB2 to a partition and then > > an error about there not being enough space. > > You can use --force to make grub2 install to a partition. If I run "grub2-install /dev/sda6", I get: /sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.. /sbin/grub2-setup: error: embedding is not possible, but this is required for cross-disk install. --force makes no difference. /dev/sda6 is actually part of a software RAID1; "grub2-install /dev/md3" segfaults. Somebody else has already put this in BZ as 788830. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Thu, 2012-02-23 at 09:40 -0600, Chris Adams wrote: > Once upon a time, Michael Schwendt said: > > Is it a single /boot partition shared by multiple dists? > > If so, that has always been just an ugly work-around to escape from having > > to repartition. I prefer individual partitions for each dist plus > > installing each dist's boot loader in the partition's boot sector and > > chainloading them from GRUB (which still works with GRUB2). > > That's what I used to do, but it didn't work for me with F16 and GRUB2. > I get a warning that I shouldn't install GRUB2 to a partition and then > an error about there not being enough space. You can use --force to make grub2 install to a partition. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On Thu, 2012-02-23 at 09:54 -0500, Adam Jackson wrote: > > For comparison: > > > > 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 > > > > Fine. System Monitor CPU at 19%. > > That's still way higher than I'd like, but it's at least an r300g bug > not an llvmpipe bug. Remember that CPU usage is inherently going to be higher than usual when running a debug kernel. I usually find any kind of mouse movement in X on a debug kernel runs my CPU to 10-20%, and that's an overclocked core i7-2600k (!). On a release kernel, no such effect. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: RC4 and NFS
On Thu, 2012-02-23 at 01:55 -0800, Chuck Forsberg WA7KGX N2469R wrote: > Here is the relevant /etc/exports entry in my server: > / 192.168.1.1/255.255.255.0(rw,async) > > Here is the screen capture from RC4 64 bit Xfce session: > [root@omen3 /]# mount 192.168.1.13:/ /o > mount.nfs: No such device > [root@omen3 /]# > > FWIW the /etc/exports has not been changed since November, > and the "mount 192.168.1.13:/ /o" where .o exists has worked > on client Fedoras for years until now. What does 'lsmod | grep nfs' say? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Experiences with F17-Alpha-RC4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2012 05:31 AM, Joachim Backes wrote: > On 02/23/2012 08:32 AM, Joachim Backes wrote: >> Hi, >> >> I made a fresh F17 desktop (gnome3) installation on my box to a >> real partition with F17/Alpha/RC4: No problems during install, >> the system runs immediately. Applying all available updates. >> >> But there are some flaws: >> >> >> 3. One ugly problem after quitting a gnome3 session: logging in >> again (via gdm login window) shows in most cases the well know >> "Oh nO! something has gone wrong, logout!" dialog. Searching a >> little bit in /var/log/messages, I saw that there are some >> (unspecified) problems with /run/user/ and/or dot files in >> /tmp. I could get rid from these login problems by removing some >> files as >> >> /tmp/.ICE-unix /tmp/.X11-unix /tmp/.X0-lock /run/user/ >> >> and then login again > > I could get rid from the problems in 3. by setting > "SELINUX=permissive" in /etc/selinux/config > > > > Are you seeing avc messages? ausearch -m avc -ts recent -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9Gj+UACgkQrlYvE4MpobNjSgCg6o+fL/AnnlMD88AxgKKmrdvM IEgAn3XKW3tbYsNi9N8Y5U5Jv/MAmgQP =HY4o -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] Announcing 389 Directory Server version 1.2.10.2 Testing
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.2. No new features were added after alpha 8, just many bug fixes. There are also 389-adminutil, 389-admin, and 389-dsgw packages in Testing. NEW: EL6 support Beginning with RHEL 6.2, the 389-ds-base package is included in the base OS. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions. However, the 389 Project will still make the full 389-ds-base package available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information. NEW: Issue Tracking System We have moved our ticket tracking system from the Red Hat Bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora Hosted Trac https://fedorahosted.org/389. All of the old 389 bugs have been copied to Trac. All new bugs, feature requests, and tasks should be entered in Trac This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 NEW: Plugin Authors WARNING: Plugins should be made transaction aware so that they can be called from within a backend pre/post transaction plugin. Otherwise, attempting to perform an internal operation will cause a deadlock. See http://directory.fedoraproject.org/wiki/Plugins Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil # or for EPEL yum upgrade --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. * Go to https://admin.fedoraproject.org/updates * In the Search box in the upper right hand corner, type in the name of the package * In the list, find the version and release you are using (if you're not sure, use rpm -qi on your system) and click on the release * On the page for the update, scroll down to "Add a comment" and provide your input Or just send us an email to 389-us...@lists.fedoraproject.org Reporting Issues https://fedorahosted.org/389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: NumLock won't turn off in rawhide
On 02/21/2012 04:13 AM, Olav Vitters wrote: On Mon, Feb 20, 2012 at 12:28:02PM -0500, Clyde E. Kunkel wrote: How do I get the numlock the turn off? (please don't tell me to press the NumLock key!! It doesn't work in rawhide right now. :-) ) Already fixed upstream: http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=ebca1ce1287679c5cb470804abfcc8de3c2d740c Hoorayfixed in rawhide 20120223. Thanks! -- Regards, OldFart -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: New testcase proposal: Dualboot with Windows
Hello gang, as there were no opposing voices, I'll add the test to the test matrix template. Once again, kudos to adamw for providing the base test. Joza - Original Message - > From: "Josef Skladanka" > To: "For testing and quality assurance of Fedora releases" > > Sent: Friday, February 10, 2012 2:06:24 PM > Subject: New testcase proposal: Dualboot with Windows > > Hello, > > I'd like to propose new Testcase, to cover the Final criterion: "The > installer must be able to install into free space alongside an > existing clean single-partition Windows installation and either > install a bootloader which can boot into the Windows installation, > or leave the Windows bootloader untouched and working". The testcase > Draft is available here (kudos to AdamW for providing most of it) > > https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_dualboot_alongside_windows > > C&C most welocomed > > Thanks > > Joza -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
tools_livecd-iso-to-disk.sh write to 2GB USB with Fedora-17-Nightly-20120221.07-i686-Live-soas
USB-stick is persistent Transcript of a successful install: http://wiki.sugarlabs.org/go/Sugar_Creation_Kit/sck/tools_livecd-iso-to-disk Tom Gilliard satellit_ on #sugar IRC freenode -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
Once upon a time, Michael Schwendt said: > Is it a single /boot partition shared by multiple dists? > If so, that has always been just an ugly work-around to escape from having > to repartition. I prefer individual partitions for each dist plus > installing each dist's boot loader in the partition's boot sector and > chainloading them from GRUB (which still works with GRUB2). That's what I used to do, but it didn't work for me with F16 and GRUB2. I get a warning that I shouldn't install GRUB2 to a partition and then an error about there not being enough space. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On Thu, 2012-02-23 at 08:44 -0500, mwesten wrote: > Fedora-17-Alpha-i686-Live-Desktop.iso (RC2) on USB > > 2.13GHz AthlonXP 2600+ / RV200 (Radeon 7500) / 1280x1024 > > Fallback mode is fine, but once the shell starts, it's a battle just to > get System Monitor open and to the Resources tab. Once there, the CPU > sits at 100% until I get off that tab. Very high latency, screen > flickering, artifacts, incomplete rendering... "Incomplete" is worrisome, I've not seen that. There's a bit of a quantum effect here where the act of drawing the CPU monitor necessarily raises CPU load. If you ssh into the machine and run top from there, gnome-shell and Xorg shouldn't be taking any undue load at idle. If they are, that means there's rendering happening at idle, which is a legitimate bug that would affect even accelerated drivers by keeping the GPU from going to sleep to save power. In the non-steady-state, though, the current implementation is known to be incredibly memcpy-heavy. Fixes coming soon, beta should be much better I hope. If you want to collect some data about where CPU time is being spent, 'perf record' against the X server or gnome-shell (with debuginfo installed) and then 'perf report' should be enlightening. I suspect you'll find the vast majority of the time spent in memcpy in one form or another (pixman or fb blit, copying data into and out of the kernel across the unix socket, etc). > For comparison: > > 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 > > Fine. System Monitor CPU at 19%. That's still way higher than I'd like, but it's at least an r300g bug not an llvmpipe bug. - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Can't start acroread in F17/Alpha
On Thu, 2012-02-23 at 09:21 +0100, Joachim Backes wrote: > Did somebody try to run acroread in F17? I did it and got as result: > > acroread > > /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading > shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as > shared object requires: Permission denied Fedora's OpenSSL build does: # Add -Wa,--noexecstack here so that libcrypto's assembler modules will be # marked as not requiring an executable stack. RPM_OPT_FLAGS="$RPM_OPT_FLAGS -Wa,--noexecstack" Which implies that the executable stack marking is not in fact needed, and normally only exists because the assembler has to assume the stack _might_ be executable. You should be able to clear the executable stack flag for individual binaries (the bundled libcrypto, in this case) by running 'execstack -c' on them. After which you should be able to turn the selinux boolean back on. - ajax signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: A question about "Software rendering for gnome-shell"
On 02/22/2012 02:42 PM, Michal Jaegermann wrote: I am afraid that I am not qualified to sensibly discuss underlying mechanisms. I can only report what I see. In this thread mwes...@verizon.net wrote "the processor gets pegged at 100% continuously and it's not usable". I am not sure what was the hardware. I wonder if turning off acceleration changes anything to him. Michal Fedora-17-Alpha-i686-Live-Desktop.iso (RC2) on USB 2.13GHz AthlonXP 2600+ / RV200 (Radeon 7500) / 1280x1024 Fallback mode is fine, but once the shell starts, it's a battle just to get System Monitor open and to the Resources tab. Once there, the CPU sits at 100% until I get off that tab. Very high latency, screen flickering, artifacts, incomplete rendering... Turned it down to 1024x768, no help. I also tried a couple of other oldies... 2.2GHz Pentium 4 / i845G / 1024x768 The shell does come up and work, but requires a lot of patience to do anything. Scrolling and dragging are jerky and painful. System Monitor CPU at 97%+ continuously. 1.6GHz Pentium M / RV250 (FireGL 9000) / 1024x768 Slightly better than i845G. "NoAccel" had no noticeable effect. For comparison: 3,2GHz Pentium 4 (HT Disabled) / Gallium 0.4 on ATI RV370 / 1680x1050 Fine. System Monitor CPU at 19%. -Mike -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Experiences with F17-Alpha-RC4
On 02/23/2012 12:42 PM, Brendan Jones wrote: > On 02/23/2012 08:32 AM, Joachim Backes wrote: >> Hi, >> >> I made a fresh F17 desktop (gnome3) installation on my box to a real >> partition with F17/Alpha/RC4: No problems during install, the system >> runs immediately. Applying all available updates. >> >> But there are some flaws: >> >> 1. No sound with "00:1b.0 Audio device: Intel Corporation N10/ICH 7 >> Family High Definition Audio Controller (rev 01)." The output >> device is not shown by the "system settings" menu. > Fix for this here [1] > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=794690 Hi Brendan, thanks for the hint. Editing /etc/pulse/default.pa as described in BZ 794690 solved my sound problems. Thank you! -- Joachim Backes http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Experiences with F17-Alpha-RC4
On 02/23/2012 08:32 AM, Joachim Backes wrote: Hi, I made a fresh F17 desktop (gnome3) installation on my box to a real partition with F17/Alpha/RC4: No problems during install, the system runs immediately. Applying all available updates. But there are some flaws: 1. No sound with "00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01)." The output device is not shown by the "system settings" menu. Fix for this here [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=794690 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-17 Branched report: 20120223 changes
Compose started at Thu Feb 23 08:15:09 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [Pound] Pound-2.6-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [asterisk] asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaEvt.so.3(OPENAIS_EVT_B.01.01)(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaEvt.so.3()(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaClm.so.3(OPENAIS_CLM_B.01.01)(64bit) asterisk-ais-10.0.0-1.fc17.1.x86_64 requires libSaClm.so.3()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [banshee] banshee-meego-2.2.1-3.fc17.x86_64 requires mutter-meego [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [coccinella] coccinella-0.96.20-3.fc17.noarch requires memchan [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [curry] curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dlm] dlm-3.99.0-5.fc17.x86_64 requires libcfg.so.4(COROSYNC_CFG_0.82)(64bit) dlm-3.99.0-5.fc17.x86_64 requires libcfg.so.4()(64bit) [elice] elice-0.323-6.fc17.x86_64 requires ruby(abi) = 0:1.8 [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [fantasdic] fantasdic-1.0-0.9.beta7.fc17.noarch requires ruby(gettext-package) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gdal] gdal-ruby-1.7.3-12.fc17.x86_64 requires libruby.so.1.8()(64bit) [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [geos] geos-ruby-3.3.2-1.fc17.x86_64 requires libruby.so.1.8()(64bit) [gnatcoll] gnatcoll-2011-6.fc17.i686 requires libgnat-4.6.so gnatcoll-2011-6.fc17.i686 requires libgnarl-4.6.so gnatcoll-2011-6.fc17.x86_64 requires libgnat-4.6.so()(64bit) gnatcoll-2011-6.fc17.x86_64 requires libgnarl-4.6.so()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnucash] gnucash-2.4.8-1.fc17.x86_64 requires libgoffice-0.8.so.8()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gphpedit] gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requires libgtkhtml-2.so.0()(64bit) [gpsdrive] gpsdrive-2.11-10.fc17.x86_64 requires libmapnik.so.0.7()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) gpsdrive-2.11-10.fc17.x86_64 requires libboost_
Re: Experiences with F17-Alpha-RC4
On 02/23/2012 08:32 AM, Joachim Backes wrote: > Hi, > > I made a fresh F17 desktop (gnome3) installation on my box to a real > partition with F17/Alpha/RC4: No problems during install, the system > runs immediately. Applying all available updates. > > But there are some flaws: > > > 3. One ugly problem after quitting a gnome3 session: logging in again >(via gdm login window) shows in most cases the well know "Oh nO! >something has gone wrong, logout!" dialog. Searching a little bit in >/var/log/messages, I saw that there are some (unspecified) problems >with /run/user/ and/or dot files in /tmp. I could get rid from >these login problems by removing some files as > > /tmp/.ICE-unix /tmp/.X11-unix /tmp/.X0-lock /run/user/ > > and then login again I could get rid from the problems in 3. by setting "SELINUX=permissive" in /etc/selinux/config -- Joachim Backes http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Wed, 22 Feb 2012 10:38:16 -0500, TD (Timothy) wrote: > It's not the recovery mode entry that bothers me, but the fact that for > all of the kernels in my boot parttion gets assigned to F17 or what > every the last distro installed. Maybe the mkconfig program isn't samrt > enought or maybe I should go ahead and write my own. Is it a single /boot partition shared by multiple dists? If so, that has always been just an ugly work-around to escape from having to repartition. I prefer individual partitions for each dist plus installing each dist's boot loader in the partition's boot sector and chainloading them from GRUB (which still works with GRUB2). -- Fedora release 16 (Verne) - Linux 3.2.7-1.fc16.x86_64 loadavg: 0.41 0.69 0.35 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: RC4 and NFS
Here is the relevant /etc/exports entry in my server: / 192.168.1.1/255.255.255.0(rw,async) Here is the screen capture from RC4 64 bit Xfce session: [root@omen3 /]# mount 192.168.1.13:/ /o mount.nfs: No such device [root@omen3 /]# FWIW the /etc/exports has not been changed since November, and the "mount 192.168.1.13:/ /o" where .o exists has worked on client Fedoras for years until now. On 02/22/2012 09:54 PM, Chuck Forsberg WA7KGX N2469R wrote: I was able to fool RC4 into installing on my office machine by telling it to use advances sotrage and selecting a drive that had no version of Linux on it. Unfortunately, attempting to mount a nfs share fails with a message about no such device. Broken NFS is a real impediment to testing Linux. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: unable to run tests requiring "updates=http://jlaska.fedorapeople.org/updates/traceback.img" option
> Kamil Paral redhat.com> writes: > > > > QA:Testcase_Anaconda_save_traceback_to_remote_system > > > QA:Testcase_Anaconda_save_traceback_to_bugzilla (Alpha) > > > QA:Testcase_Anaconda_save_traceback_to_disk (Alpha) > > > QA:Testcase_Anaconda_traceback_debug_mode > > > > I have tried Alpha RC4 (anaconda 17.11), it's there. I'll update > > the test > cases now. > > I hadn't checked past the first anaconda screen (where the traceback > appeared > previously). Going through the first few screens as indicated in the > new test > cases, I see it now. It might have been in RC3 as well. Anyway, I > verified that > the last 3 tests work as advertised. > QA:Testcase_Anaconda_save_traceback_to_remote_system did not work, > using an URL > of the form "scp://andre:mypassword@192.168.1.2:/tmp" (which worked > previously). > The installer claims it wrote the file successfully, and tells you > the exact > name of the file, but it never actually appears on the remote system. Thanks, Andre. Please report it as a bug. (and try scp manually whether it works) -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Can't start acroread in F17/Alpha
On 02/23/2012 09:45 AM, drago01 wrote: > On Thu, Feb 23, 2012 at 9:21 AM, Joachim Backes > wrote: >> Did somebody try to run acroread in F17? I did it and got as result: >> >> acroread >> >> /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading >> shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as >> shared object requires: Permission denied >> > > Does > > setsebool allow_execstack=on > > fix it? Thanks, it fixed it :-) > > You can make it permanent using setsebool -P allow_execstack=on > > (It gets flipped pre release and back on GA). -- Joachim Backes http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Can't start acroread in F17/Alpha
On Thu, Feb 23, 2012 at 9:21 AM, Joachim Backes wrote: > Did somebody try to run acroread in F17? I did it and got as result: > > acroread > > /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading > shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as > shared object requires: Permission denied > Does setsebool allow_execstack=on fix it? You can make it permanent using setsebool -P allow_execstack=on (It gets flipped pre release and back on GA). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Can't start acroread in F17/Alpha
Did somebody try to run acroread in F17? I did it and got as result: acroread /opt/Adobe/Reader9/Reader/intellinux/bin/acroread: error while loading shared libraries: libcrypto.so.0.9.8: cannot enable executable stack as shared object requires: Permission denied Anybody can confirm this? Kind regards Joachim Backes http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grub2 mkconfig
On Wed, Feb 22, 2012 at 10:38 AM, Timothy Davis wrote: > > It's not the recovery mode entry that bothers me, but the fact that for > all of the kernels in my boot parttion gets assigned to F17 or what > every the last distro installed. Maybe the mkconfig program isn't samrt > enought or maybe I should go ahead and write my own. I don't have an install to look at at the moment but I'm not surprised that (assuming that F17's the "last distro installed") all your entries are called "F17..." given that you have the same 4GB "/boot" for all your distros. I don't have copies of "10_linux", "grub2-mkconfig", and "grub2-mkconfig_lib" (or maybe it's not renamed in Fedora and is "grub-mkconfig_lib") but I suspect that it's not only the "menuentry" titles that are the same in "grub.cfg" but that the "root=" values on the "linux" lines are all the same too and not pointing to the slackware "/" for the slackware kernels and the ubuntu "/" for the ubuntu kernels. Maybe you can combine the logic of "10_linux" and "30_os=prober" for grub2-mkconfig to do what you'd like it to do. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
