Re: [F19] More than 2 kernel entries in grub2.cfg?
On 06/20/2013 11:12 AM, Kashyap Chamarthy wrote:
> Heya,
>
> I've been using F19 for a while. For the past couple of days, I don't see
> grub picking up
> latest kernel.
>
> -> Kernel in use (despite rebooting, after installing newer kernels):
> --
> $ uname -r
> 3.10.0-0.rc2.git1.2.fc20.x86_64
> --
>
>
> -> Available kernels:
> --
> $ rpm -q kernel
> kernel-3.10.0-0.rc2.git1.2.fc20.x86_64
> kernel-3.10.0-0.rc5.git0.1.fc20.x86_64
> kernel-3.10.0-0.rc6.git0.4.fc20.x86_64
> --
>
> -> I only notice 2 Kernel entries in grub2.conf: (shouldn't it be 3?)
> --
> $ grep menuentry /etc/grub2.cfg
> if [ x"${feature_menuentry_id}" = xy ]; then
> menuentry_id_option="--id"
> menuentry_id_option=""
> export menuentry_id_option
> menuentry 'Fedora (3.10.0-0.rc2.git1.2.fc20.x86_64) 19 (Schrödinger’s Cat)'
> --class fedora
> --class gnu-linux --class gnu --class os $menuentry_id_option
> 'gnulinux-simple-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
> menuentry 'Fedora 19 Rescue 988414e5ab3a40bf886d07aa5bcf8b4b
> (3.9.0-0.rc5.git1.301.fc19.x86_64)' --class fedora --class gnu-linux --class
> gnu --class
> os $menuentry_id_option
> 'gnulinux-simple-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
> submenu 'Advanced options for Fedora' $menuentry_id_option
> 'gnulinux-advanced-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
> --
>
>
> -> Version info of grub, kernel:
> --
> $ rpm -qa | grep -i grub
> grubby-8.26-2.fc19.x86_64
> grub2-tools-2.00-20.fc19.x86_64
> grub2-2.00-20.fc19.x86_64
> --
>
> $ cat /etc/redhat-release
> Fedora release 19 (Schrödinger’s Cat)
> --
>
>
> Any hints?
>
> Meantime, I just edited grub2.cfg, added
>
> default="5"
>
> and rebooted to see if it boots into latest kernels again.
No dice here. Still the current kernel remains in rc2, while rc6 is available
locally.
I wonder if I'm missing anything trivial here.
--
/kashyap
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
[F19] More than 2 kernel entries in grub2.cfg?
Heya,
I've been using F19 for a while. For the past couple of days, I don't see grub
picking up
latest kernel.
-> Kernel in use (despite rebooting, after installing newer kernels):
--
$ uname -r
3.10.0-0.rc2.git1.2.fc20.x86_64
--
-> Available kernels:
--
$ rpm -q kernel
kernel-3.10.0-0.rc2.git1.2.fc20.x86_64
kernel-3.10.0-0.rc5.git0.1.fc20.x86_64
kernel-3.10.0-0.rc6.git0.4.fc20.x86_64
--
-> I only notice 2 Kernel entries in grub2.conf: (shouldn't it be 3?)
--
$ grep menuentry /etc/grub2.cfg
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
menuentry_id_option=""
export menuentry_id_option
menuentry 'Fedora (3.10.0-0.rc2.git1.2.fc20.x86_64) 19 (Schrödinger’s Cat)'
--class fedora
--class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-simple-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
menuentry 'Fedora 19 Rescue 988414e5ab3a40bf886d07aa5bcf8b4b
(3.9.0-0.rc5.git1.301.fc19.x86_64)' --class fedora --class gnu-linux --class
gnu --class
os $menuentry_id_option 'gnulinux-simple-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
submenu 'Advanced options for Fedora' $menuentry_id_option
'gnulinux-advanced-21a75476-6f84-4f1b-ab92-be7c42d5b8c2' {
--
-> Version info of grub, kernel:
--
$ rpm -qa | grep -i grub
grubby-8.26-2.fc19.x86_64
grub2-tools-2.00-20.fc19.x86_64
grub2-2.00-20.fc19.x86_64
--
$ cat /etc/redhat-release
Fedora release 19 (Schrödinger’s Cat)
--
Any hints?
Meantime, I just edited grub2.cfg, added
default="5"
and rebooted to see if it boots into latest kernels again.
--
/kashyap
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Wed, 2013-06-19 at 16:21 -0400, Matthias Clasen wrote: > On Wed, 2013-06-19 at 15:19 -0400, Bill Nottingham wrote: > > Adam Williamson (awill...@redhat.com) said: > > > It's not a reason not to 'have a feature', but it may be a reason not to > > > implement a feature in a particular way. > > > > > > There are probably a thousand questions we could ask at the first stage > > > of install that would allow various small groups of people to have a > > > more 'tailored' installer in some way. How do you decide which to ask > > > and which not to ask? > > > > Shouldn't this just be solved by getting anaconda to hook into the existing > > a11y framework? > > > > No need to hook anything, you just need to run the installer in a > session, then all the infrastructure is available: accessibility, input > methods, etc. > > Anaconda with large text: > http://mclasen.fedorapeople.org/anaconda-large-text.png > Anaconda with zoom: > http://mclasen.fedorapeople.org/anaconda-zoom.png Right, right now you could run anaconda from the desktop live and use GNOME's A11y features. We don't really test that, but it's there as an option. -- 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: gnome-shell cpu usage during installation
On Jun 19, 2013, at 8:44 PM, John Reiser wrote: > On 06/19/2013 06:04 PM, Chris Murphy wrote: > >> Hmm, neither the Fedora 18 or 19 Xorg.0.logs contain 'software renderer' or >> 'llvmpipe'. >> >> https://dl.dropboxusercontent.com/u/3253801/F18_Xorg.0.log >> https://dl.dropboxusercontent.com/u/3253801/F19_Xorg.0.log >> >> For 'glxinfo' on both F18 and 19 live media, I get Error: unable to open >> display. > > Running Fedora-Live-Desktop-i686-19-TC3-1.iso with (lspci -nn) > 05:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce > 8400 GS Rev. 3] [10de:10c3] (rev a2) > then I see 98% or more idle on a 2.0GHz Athlon 64. My Xorg.0.log is > http://ur1.ca/ednn9 -> http://paste.fedoraproject.org/19780/69567113 > From a Terminal (gnome-terminal): > $ glxinfo | grep renderer > OpenGL renderer string: Gallium 0.4 on NVA8 From your Xorg log, I'm not seeing why glxinfo works for you but doesn't work for me. But for that matter I don't see why gnome-shell is using so much more CPU with F19 than F18. It doesn't seem to be nouveau related, or at least Xorg isn't revealing what the issue is. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
On 06/19/2013 06:04 PM, Chris Murphy wrote: > Hmm, neither the Fedora 18 or 19 Xorg.0.logs contain 'software renderer' or > 'llvmpipe'. > > https://dl.dropboxusercontent.com/u/3253801/F18_Xorg.0.log > https://dl.dropboxusercontent.com/u/3253801/F19_Xorg.0.log > > For 'glxinfo' on both F18 and 19 live media, I get Error: unable to open > display. Running Fedora-Live-Desktop-i686-19-TC3-1.iso with (lspci -nn) 05:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 8400 GS Rev. 3] [10de:10c3] (rev a2) then I see 98% or more idle on a 2.0GHz Athlon 64. My Xorg.0.log is http://ur1.ca/ednn9 -> http://paste.fedoraproject.org/19780/69567113 From a Terminal (gnome-terminal): $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on NVA8 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 162 https://admin.fedoraproject.org/updates/FEDORA-2013-0416/fedora-business-cards-1-0.1.beta1.fc18 96 https://admin.fedoraproject.org/updates/FEDORA-2013-3935/puppet-3.1.1-1.fc18 89 https://admin.fedoraproject.org/updates/FEDORA-2013-4243/stunnel-4.55-1.fc18 76 https://admin.fedoraproject.org/updates/FEDORA-2013-4823/microcode_ctl-2.0-3.fc18 61 https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18 33 https://admin.fedoraproject.org/updates/FEDORA-2013-8381/varnish-3.0.3-5.fc18 19 https://admin.fedoraproject.org/updates/FEDORA-2013-9707/livecd-tools-18.16-2.fc18 15 https://admin.fedoraproject.org/updates/FEDORA-2013-9962/subversion-1.7.10-1.fc18 11 https://admin.fedoraproject.org/updates/FEDORA-2013-10440/owncloud-4.5.12-1.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-10713/openstack-keystone-2012.2.4-4.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-10806/fail2ban-0.8.10-1.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-10941/xen-4.2.2-7.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-10950/nagios-3.5.0-5.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11198/dbus-1.6.12-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11212/haproxy-1.4.24-1.fc18 The following Fedora 18 Critical Path updates have yet to be approved: Age URL 130 https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18 12 https://admin.fedoraproject.org/updates/FEDORA-2013-10318/system-config-keyboard-1.3.1-14.fc18 11 https://admin.fedoraproject.org/updates/FEDORA-2013-10428/NetworkManager-0.9.8.2-1.fc18,network-manager-applet-0.9.8.2-1.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-10635/emacs-24.2-19.fc18 7 https://admin.fedoraproject.org/updates/FEDORA-2013-10643/dnsmasq-2.65-6.fc18 6 https://admin.fedoraproject.org/updates/FEDORA-2013-10832/cups-1.5.4-28.fc18 3 https://admin.fedoraproject.org/updates/FEDORA-2013-10939/dosfstools-3.0.20-2.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11278/make-3.82-14.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11198/dbus-1.6.12-1.fc18 The following builds have been pushed to Fedora 18 updates-testing alien-8.88-2.fc18 augeas-1.1.0-1.fc18 dyninst-8.1.2-1.fc18 fcitx-4.2.7-4.fc18 ghc-crypto-api-0.11-2.fc18 guacamole-0.8.1-1.fc18 libgit2-0.18.0-4.fc18 libgit2-0.18.0-5.fc18 libguac-client-ssh-0.8.0-2.fc18 libtevent-0.9.18-2.fc18 libxdiff-1.0-2.fc18 make-3.82-14.fc18 mawk-1.3.4-1.20130219.fc18 nodejs-less-1.4.0-1.fc18 os-prober-1.58-2.fc18 python-rosdistro-0.2.8-2.20130602git6e83551.fc18 rcssserver3d-0.6.7-1.fc18 scl-utils-20130529-1.fc18 simspark-0.2.4-1.fc18 Details about builds: alien-8.88-2.fc18 (FEDORA-2013-11290) Converter between the rpm, dpkg, stampede slp, and Slackware tgz file formats Update Information: Alien is a program that converts between the rpm, dpkg, stampede slp, and Slackware tgz file formats. If you want to use a package from another distribution than the one you have installed on your system, you can use alien to convert it to your preferred package format and install it. augeas-1.1.0-1.fc18 (FEDORA-2013-11282) A library for changing configuration files Update Information: See https://github.com/hercules-team/augeas/blob/master/NEWS for details Fix parsing of /etc/sysconfig/network. ChangeLog: * Wed Jun 19 2013 David Lutterkort - 1.1.0-1 - Update to 1.1.0; remove all patches * Tue Jun 18 2013 Richard W.M. Jones - 1.0.0-4 - Fix /etc/sysconfig/network (RHBZ#904222). * Wed Jun 5 2013 Richard W.M. Jones - 1.0.0-3 - Don't package lenses in tests/ subdirectory. References: [ 1 ] Bug #904222 - augeas-libs-1.0.0-1.el5 update prevents setting /etc/sysconfig/network https://bugzilla.redhat.com/show_bug.cgi?id=904222 dyninst-8.1.2-1.fc18 (FEDORA-2013-11302) An API for Run-time Code Generation Update Information: Update to Dyninst 8.1.2
Fedora 17 updates-testing report
The following Fedora 17 Security updates need testing:
Age URL
349
https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17
161
https://admin.fedoraproject.org/updates/FEDORA-2013-0455/fedora-business-cards-1-0.1.beta1.fc17
89
https://admin.fedoraproject.org/updates/FEDORA-2013-4234/stunnel-4.55-1.fc17
84
https://admin.fedoraproject.org/updates/FEDORA-2013-4501/libxslt-1.1.28-1.fc17
81
https://admin.fedoraproject.org/updates/FEDORA-2013-4581/libuser-0.57.6-2.fc17
14
https://admin.fedoraproject.org/updates/FEDORA-2013-10128/ssmtp-2.61-20.fc17
14
https://admin.fedoraproject.org/updates/FEDORA-2013-10121/subversion-1.7.10-1.fc17
12
https://admin.fedoraproject.org/updates/FEDORA-2013-10233/php-5.4.16-1.fc17
6
https://admin.fedoraproject.org/updates/FEDORA-2013-10830/fail2ban-0.8.10-1.fc17
6
https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.5-101.fc17
3 https://admin.fedoraproject.org/updates/FEDORA-2013-10929/xen-4.1.5-6.fc17
3
https://admin.fedoraproject.org/updates/FEDORA-2013-10940/tomcat6-6.0.37-1.fc17
0
https://admin.fedoraproject.org/updates/FEDORA-2013-11234/haproxy-1.4.24-1.fc17
The following Fedora 17 Critical Path updates have yet to be approved:
Age URL
301
https://admin.fedoraproject.org/updates/FEDORA-2012-12509/PackageKit-0.7.6-1.fc17
109
https://admin.fedoraproject.org/updates/FEDORA-2013-3304/libvpx-1.2.0-1.fc17
7
https://admin.fedoraproject.org/updates/FEDORA-2013-10602/dnsmasq-2.65-6.fc17
The following builds have been pushed to Fedora 17 updates-testing
fcitx-4.2.7-4.fc17
ghc-crypto-api-0.11-1.1.fc17
libxdiff-1.0-2.fc17
make-3.82-14.fc17
mawk-1.3.4-1.20130219.fc17
os-prober-1.58-2.fc17
rcssserver3d-0.6.7-1.fc17
simspark-0.2.4-1.fc17
Details about builds:
fcitx-4.2.7-4.fc17 (FEDORA-2013-11277)
Free Chinese Input Toy for X (XIM)
Update Information:
Enable Lua support; fcitx-libs support multilib; Fix fcitx-gtk2 description
ChangeLog:
* Wed Jun 19 2013 Robin Lee - 4.2.7-4
- BR: lua-devel (BZ#974729)
- Move %{_datadir}/gir-1.0/Fcitx-1.0.gir %{_bindir}/fcitx4-config to devel
subpackage (BZ#965914)
- Co-own %{_datadir}/gir-1.0/, %{_libdir}/girepository-1.0/
- Own %{_libdir}/%{name}/qt/, %{_libdir}/%{name}/
- Other minor cleanup
* Mon Apr 29 2013 Robin Lee - 4.2.7-3
- Fix gtk2 subpackage description (#830377)
* Sat Mar 23 2013 Liang Suilong - 4.2.7-2
- Fix to enable Lua support
References:
[ 1 ] Bug #830377 - fcitx-gtk2 package's description is wrong
https://bugzilla.redhat.com/show_bug.cgi?id=830377
ghc-crypto-api-0.11-1.1.fc17 (FEDORA-2013-11279)
A generic interface for cryptographic operations
Update Information:
A generic interface for cryptographic operations
References:
[ 1 ] Bug #925987 - Review Request: ghc-crypto-api - A generic interface for
cryptographic operations
https://bugzilla.redhat.com/show_bug.cgi?id=925987
libxdiff-1.0-2.fc17 (FEDORA-2013-11286)
Basic functionality to create difference/patches in binary and text
Update Information:
fix function on big-endian arches
ChangeLog:
make-3.82-14.fc17 (FEDORA-2013-11295)
A GNU tool which simplifies the build process for users
Update Information:
Fix Makefile archive rules of the form X.a( Y Z) (with space preceding internal
components).
ChangeLog:
* Wed Jun 19 2013 Petr Machata - 1:3.82-14
- Add another fix for upstream bug 30612
mawk-1.3.4-1.20130219.fc17 (FEDORA-2013-11292)
Interpreter for the AWK prog
Re: gnome-shell cpu usage during installation
On Jun 19, 2013, at 4:45 PM, John Reiser wrote: >>> Is there a more definitive way to tell if gnome-shell is or isn't >>> offloading onto the GPU? > > During installation, look in /tmp/X.log for which modules get loaded. > Here is what I see during install for [R200] [RV280] (PCI 1002:5960) Radeon > 9250 (9200 PRO) > where the installed Gnome3 system will try to use llvmpipe: > > [48.510] (EE) AIGLX error: dlopen of /usr/lib/dri/r200_dri.so failed > (/usr/lib/dri/r200_dri.so: cannot open shared object file: No such file or > directory) > [48.510] (EE) AIGLX: reverting to software rendering > [48.510] (II) AIGLX: Screen 0 is not DRI capable > [48.510] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed > (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or > directory) > [48.510] (EE) GLX: could not load software renderer > [48.510] (II) GLX: no usable GL providers found for screen 0 Hmm, neither the Fedora 18 or 19 Xorg.0.logs contain 'software renderer' or 'llvmpipe'. https://dl.dropboxusercontent.com/u/3253801/F18_Xorg.0.log https://dl.dropboxusercontent.com/u/3253801/F19_Xorg.0.log For 'glxinfo' on both F18 and 19 live media, I get Error: unable to open display. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
On Jun 19, 2013, at 5:17 PM, drago01 wrote: > On Thu, Jun 20, 2013 at 1:00 AM, Chris Murphy wrote: >> >> On Jun 19, 2013, at 3:53 PM, John Reiser wrote: >> Is there a more definitive way to tell if gnome-shell is or isn't offloading onto the GPU? >>> >>> $ glxinfo | grep renderer >>> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) >>> "llvmpipe" is the software CPU (SSE2) renderer >>> >>> OpenGL renderer string: Gallium 0.4 on AMD REDWOOD >>> One of the hardware renderers. >> >> >> Fedora 18: >> [root@localhost ~]# glxinfo | grep renderer >> Error: unable to open display > > 1. You don't have to do it as root > 2. X has to be running I tried it as liveuser and root, and X is running. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
On Thu, Jun 20, 2013 at 1:00 AM, Chris Murphy wrote: > > On Jun 19, 2013, at 3:53 PM, John Reiser wrote: > >>> Is there a more definitive way to tell if gnome-shell is or isn't >>> offloading onto the GPU? >> >> $ glxinfo | grep renderer >> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) >>"llvmpipe" is the software CPU (SSE2) renderer >> >> OpenGL renderer string: Gallium 0.4 on AMD REDWOOD >>One of the hardware renderers. > > > Fedora 18: > [root@localhost ~]# glxinfo | grep renderer > Error: unable to open display 1. You don't have to do it as root 2. X has to be running -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
On Jun 19, 2013, at 3:53 PM, John Reiser wrote: >> Is there a more definitive way to tell if gnome-shell is or isn't offloading >> onto the GPU? > > $ glxinfo | grep renderer > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) >"llvmpipe" is the software CPU (SSE2) renderer > > OpenGL renderer string: Gallium 0.4 on AMD REDWOOD >One of the hardware renderers. Fedora 18: [root@localhost ~]# glxinfo | grep renderer Error: unable to open display Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
>> Is there a more definitive way to tell if gnome-shell is or isn't offloading >> onto the GPU? During installation, look in /tmp/X.log for which modules get loaded. Here is what I see during install for [R200] [RV280] (PCI 1002:5960) Radeon 9250 (9200 PRO) where the installed Gnome3 system will try to use llvmpipe: [48.510] (EE) AIGLX error: dlopen of /usr/lib/dri/r200_dri.so failed (/usr/lib/dri/r200_dri.so: cannot open shared object file: No such file or directory) [48.510] (EE) AIGLX: reverting to software rendering [48.510] (II) AIGLX: Screen 0 is not DRI capable [48.510] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) [48.510] (EE) GLX: could not load software renderer [48.510] (II) GLX: no usable GL providers found for screen 0 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: screengrabber istanbul in F19
On Wed, Jun 19, 2013 at 8:23 PM, Joachim Backes wrote: > On 06/19/2013 07:51 PM, Louis Lagendijk wrote: >> >> On Tue, 2013-06-18 at 14:58 +0200, Joachim Backes wrote: >>> >>> On 06/18/2013 02:30 PM, Ryan Lerch wrote: On Tue 18 Jun 2013 05:48:50 AM EDT, Joachim Backes wrote: > > Hi all testers, > > I'm running the screen capture program istanbul in F19/gnome3, but I > don't see any istanbul icon on the screen, so I can't control it. > > On the other hand, if using mate or gnome classical, the istanbul > icons appear in the notification area so I can manage the istanbul > program. > > What I'm doing wrong? > > >> This application probably uses the deprecated trayicon that by default >> is not shown anymore. I installed the topicon plugin (not in Fedora but >> available from https://extensions.gnome.org/extension/495/topicons/) >> for another application that had the same problem >> >> kind regards, Louis >> >> > > Hi Louis, > > this solved my problem! Thank you very much! GNOME has a built in screen recorder that you can start / stop using Ctrl-Alt-Shift-R ... videos will be saved to ~/Videos. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
> Is there a more definitive way to tell if gnome-shell is or isn't offloading > onto the GPU? $ glxinfo | grep renderer OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits) "llvmpipe" is the software CPU (SSE2) renderer OpenGL renderer string: Gallium 0.4 on AMD REDWOOD One of the hardware renderers. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
> On Jun 18, 2013, at 1:38 PM, Michael Cronenworth wrote: > >> On 06/18/2013 01:27 PM, Chris Murphy wrote: >>> With the system installed, dragging e.g. a Firefox window, around the >>> screen approximates the same behavior. gnome-shell is pegged. This doesn't >>> seem right. >> >> The system I am typing from has the NVIDIA binary driver and experiences >> the same "pegged" behavior. Gnome Shell has always worked this way. > > Not for me. On a 2011 Macbook Pro I don't get either the anaconda or Firefox > induced gnome-shell pegging behavior. It uses at most 7% CPU on that system, > which has both MD Radeon HD 6750M and Intel HD Graphics 3000. I'm not sure > which one is being used. So on the originally reported hardware with NVIDIA card, this excessive CPU usage with gnome-shell is not reproducible with Fedora 18 live media. It appears to be a new problem. Combined with the 60%-80% CPU consumption of yumbackend.py on first boot after installation of F19 for about 30 minutes while it downloads updates without my permission, the resulting sluggish behavior of the system isn't exactly the most positive initial experience. Is there a more definitive way to tell if gnome-shell is or isn't offloading onto the GPU? Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Wed, 2013-06-19 at 15:19 -0400, Bill Nottingham wrote: > Adam Williamson (awill...@redhat.com) said: > > It's not a reason not to 'have a feature', but it may be a reason not to > > implement a feature in a particular way. > > > > There are probably a thousand questions we could ask at the first stage > > of install that would allow various small groups of people to have a > > more 'tailored' installer in some way. How do you decide which to ask > > and which not to ask? > > Shouldn't this just be solved by getting anaconda to hook into the existing > a11y framework? > No need to hook anything, you just need to run the installer in a session, then all the infrastructure is available: accessibility, input methods, etc. Anaconda with large text: http://mclasen.fedorapeople.org/anaconda-large-text.png Anaconda with zoom: http://mclasen.fedorapeople.org/anaconda-zoom.png -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
Adam Williamson (awill...@redhat.com) said: > It's not a reason not to 'have a feature', but it may be a reason not to > implement a feature in a particular way. > > There are probably a thousand questions we could ask at the first stage > of install that would allow various small groups of people to have a > more 'tailored' installer in some way. How do you decide which to ask > and which not to ask? Shouldn't this just be solved by getting anaconda to hook into the existing a11y framework? Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Wed, 2013-06-19 at 12:59 -0300, Bruno Medeiros wrote: > > > > It'd be an improvement for the still small number of people > who need it. > For everyone else it'd be a pointless question, which is one > of the > things we've been trying to take *out* of the installer, not > add to it. > See? Different imperatives. > > > I don't think that having a small number of users needing a feature is > a valid reason to not consider the feature. If we follow that way of > thinking, we are acting like the developer that don't support > GNU/Linux because of the small market share. It's not a reason not to 'have a feature', but it may be a reason not to implement a feature in a particular way. There are probably a thousand questions we could ask at the first stage of install that would allow various small groups of people to have a more 'tailored' installer in some way. How do you decide which to ask and which not to ask? -- 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: Fedora 19 Final status, testing/karma requests and needed fixes
On Wed, Jun 19, 2013 at 08:26:12 -0600, Tim Flink wrote: On Wed, 19 Jun 2013 07:44:25 -0500 Bruno Wolff III wrote: On Tue, Jun 18, 2013 at 18:02:35 -0700, Adam Williamson wrote: >Releng team: when a new selinux-policy is available, roll some new >cloud test images (964006) Are we going to start getting non-desktop type live images or have those all been dropped for f19? They were moved for F19 and are now in the Spins/ directory instead of the Live/ dir.. I'm seeing MATE, LXDE, XFCE and SoaS unless you were looking for one of the other spins. I'm not sure those are being built for F19 I am referring to other ones, such as scientific, security lab, games robotics, design suite, and Jam / audio. If these are't going to get ISOs, then hopefully the release web pages will not point to them. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: screengrabber istanbul in F19
On 06/19/2013 07:51 PM, Louis Lagendijk wrote: On Tue, 2013-06-18 at 14:58 +0200, Joachim Backes wrote: On 06/18/2013 02:30 PM, Ryan Lerch wrote: On Tue 18 Jun 2013 05:48:50 AM EDT, Joachim Backes wrote: Hi all testers, I'm running the screen capture program istanbul in F19/gnome3, but I don't see any istanbul icon on the screen, so I can't control it. On the other hand, if using mate or gnome classical, the istanbul icons appear in the notification area so I can manage the istanbul program. What I'm doing wrong? This application probably uses the deprecated trayicon that by default is not shown anymore. I installed the topicon plugin (not in Fedora but available from https://extensions.gnome.org/extension/495/topicons/) for another application that had the same problem kind regards, Louis Hi Louis, this solved my problem! Thank you very much! Kind regards Joachim Backes -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.6-301.fc19.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: screengrabber istanbul in F19
On Tue, 2013-06-18 at 14:58 +0200, Joachim Backes wrote: > On 06/18/2013 02:30 PM, Ryan Lerch wrote: > > On Tue 18 Jun 2013 05:48:50 AM EDT, Joachim Backes wrote: > >> Hi all testers, > >> > >> I'm running the screen capture program istanbul in F19/gnome3, but I > >> don't see any istanbul icon on the screen, so I can't control it. > >> > >> On the other hand, if using mate or gnome classical, the istanbul > >> icons appear in the notification area so I can manage the istanbul > >> program. > >> > >> What I'm doing wrong? > >> > >> Kind regards > > > > Not sure if this is your issue, but in GNOME 3 all the tray icons are > > placed in the message tray at the bottom on the screen. It can be > > activated by moving the mouse to the bottom edge of the screen. > > > > The instanbul applet should be in there. > > > > regards, > > ryanlerch > > > > > > Hi ryanlerch, > > I know that the applet should appear at the location you mentioned, but > nothing appears at the screen's buttom, nor at the screen's button edges > (if moving the mouse pointer to such a location)! Other notifications > (for received thunderbird emails for example) appear definitely in the > notification area. > > Kind regards > > Joachim Backes This application probably uses the deprecated trayicon that by default is not shown anymore. I installed the topicon plugin (not in Fedora but available from https://extensions.gnome.org/extension/495/topicons/) for another application that had the same problem kind regards, Louis -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On 19 June 2013 17:46, Adam Williamson wrote: > > On Wed, 2013-06-19 at 10:41 -0500, Michael Hennebry wrote: > > On Tue, 18 Jun 2013, Adam Williamson wrote: > > > > > On Tue, 2013-06-18 at 15:02 -0500, John Morris wrote: > > > > >> So lemme recap what you have been saying in this and other posts > > >> The > > >> current design breaks both internationalization and accessability and > > >> you recognize that reality. Fixing these problems isn't an option > > >> though because well because. > > >> > > >> Tearing Anaconda apart and rebuilding it from the ground up was an > > >> imperative, complaints be damned, because the Anaconda devs had a > > >> hankering to do that; they had a fever and the only cure was some > > >> more > > >> cowbell. But making it useable while they already had it tore apart? > > >> Nobody was interested in that. > > > > > What I'm saying is that there isn't a quick fix to this, which is what > > > Felix always suggests; his suggestions always boil down to "make the > > > fonts bigger! now!" > > > > > Given all of that, it's almost never the case that there's a 'quick > > > fix' > > > for anything when it comes to the UI. If we're going to make anaconda > > > more accessible we need to take an overview of how to do it without > > > compromising its other design goals, not just start throwing out quick > > > fix ideas. > > > > While I doubt that there is a quick road to perfection, > > making things better should not be all that nasty. > > There is no need to ask the display how big it is. > > Just ask the user if a bigger font is desired. > > The user does not need to be given a lot of choices. > > 96, 192 and something in between would be an improvement. > > It'd be an improvement for the still small number of people who need it. I haven't tested the F19 installer, but in the F18 installer, under "Troubleshooting", there's an "Install Fedora using basic graphics mode" option which makes Anaconda use the Vesa driver. I think anyone can see the text in the installer under that mode. [] -- Ahmad Samir -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Wed, 19 Jun 2013 12:59:57 -0300 Bruno Medeiros wrote: > > I don't need this problem fixed personally, but if I were in > position, I would consider ideas to fix the problem for people who > have it, specially if the problem is a big problem (not being able > to read the text, for example). My daughter since age 12 (now 23) is almost blind in one eye, bad vision in the other. Her solution to small text PC or otherwise a magnifying glass on a cap. Which gave her back large text. -- Regards, Frank "When in doubt PANIC!" I check for new mail app. 20min www.frankly3d.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 19 Final status, testing/karma requests and needed fixes
On Wed, 2013-06-19 at 07:44 -0500, Bruno Wolff III wrote: > On Tue, Jun 18, 2013 at 18:02:35 -0700, >Adam Williamson wrote: > >Releng team: when a new selinux-policy is available, roll some new cloud > >test images (964006) > > Are we going to start getting non-desktop type live images or have those > all been dropped for f19? I think dgilmore said he wasn't planning to build them because they don't seem to have any kind of active maintenance or user base. -- 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: consider people with poor vision
On Wed, 2013-06-19 at 10:41 -0500, Michael Hennebry wrote: > On Tue, 18 Jun 2013, Adam Williamson wrote: > > > On Tue, 2013-06-18 at 15:02 -0500, John Morris wrote: > > >> So lemme recap what you have been saying in this and other posts The > >> current design breaks both internationalization and accessability and > >> you recognize that reality. Fixing these problems isn't an option > >> though because well because. > >> > >> Tearing Anaconda apart and rebuilding it from the ground up was an > >> imperative, complaints be damned, because the Anaconda devs had a > >> hankering to do that; they had a fever and the only cure was some more > >> cowbell. But making it useable while they already had it tore apart? > >> Nobody was interested in that. > > > What I'm saying is that there isn't a quick fix to this, which is what > > Felix always suggests; his suggestions always boil down to "make the > > fonts bigger! now!" > > > Given all of that, it's almost never the case that there's a 'quick fix' > > for anything when it comes to the UI. If we're going to make anaconda > > more accessible we need to take an overview of how to do it without > > compromising its other design goals, not just start throwing out quick > > fix ideas. > > While I doubt that there is a quick road to perfection, > making things better should not be all that nasty. > There is no need to ask the display how big it is. > Just ask the user if a bigger font is desired. > The user does not need to be given a lot of choices. > 96, 192 and something in between would be an improvement. It'd be an improvement for the still small number of people who need it. For everyone else it'd be a pointless question, which is one of the things we've been trying to take *out* of the installer, not add to it. See? Different imperatives. -- 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: consider people with poor vision
On Tue, 18 Jun 2013, Adam Williamson wrote: On Tue, 2013-06-18 at 15:02 -0500, John Morris wrote: So lemme recap what you have been saying in this and other posts The current design breaks both internationalization and accessability and you recognize that reality. Fixing these problems isn't an option though because well because. Tearing Anaconda apart and rebuilding it from the ground up was an imperative, complaints be damned, because the Anaconda devs had a hankering to do that; they had a fever and the only cure was some more cowbell. But making it useable while they already had it tore apart? Nobody was interested in that. What I'm saying is that there isn't a quick fix to this, which is what Felix always suggests; his suggestions always boil down to "make the fonts bigger! now!" Given all of that, it's almost never the case that there's a 'quick fix' for anything when it comes to the UI. If we're going to make anaconda more accessible we need to take an overview of how to do it without compromising its other design goals, not just start throwing out quick fix ideas. While I doubt that there is a quick road to perfection, making things better should not be all that nasty. There is no need to ask the display how big it is. Just ask the user if a bigger font is desired. The user does not need to be given a lot of choices. 96, 192 and something in between would be an improvement. -- Michael henne...@web.cs.ndsu.nodak.edu "On Monday, I'm gonna have to tell my kindergarten class, whom I teach not to run with scissors, that my fiance ran me through with a broadsword." -- Lily -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 19 Final status, testing/karma requests and needed fixes
On Wed, 19 Jun 2013 08:26:12 -0600 Tim Flink wrote: > > Are we going to start getting non-desktop type live images or have > > those all been dropped for f19? > > They were moved for F19 and are now in the Spins/ directory > instead of the Live/ dir.. > > I'm seeing MATE, LXDE, XFCE and SoaS unless you were looking for > one of the other spins. I'm not sure those are being built for F19 > > Tim Other Gnome\KDE based spins usually appear at final. -- Regards, Frank "When in doubt PANIC!" I check for new mail app. 20min www.frankly3d.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: More yuim update problems
Dne 19.6.2013 15:25, Sandro Mani napsal(a): I would look at yum check and then solve the problems one by one. Try reinstalling problematic packages (i.e. the ones which yum check reports as duplicates) one at a time, possibly forcefully using rpm directly (grab the rpms from koji [1] and use rpm -e --nodeps followed by a rpm -i). Once yum check is happy, run a yum update to update any remaining packages. [1] http://koji.fedoraproject.org/koji/ On Wed, Jun 19, 2013 at 3:05 PM, Frank McCormick mailto:bea...@videotron.ca>> wrote: I suffered a big problem during this mornings update of 19. Yum QUIT after doing the first three items in the update. The download and rebuilding of delta rpms had gone well. Now it's suggesting to run yum-complete-transaction...but that results in pages and pages of changes yum wants to make, including erasing glibc and hundreds of others. What's my best move - I am afraid to do anything at this point. https://bugzilla.redhat.com/show_bug.cgi?id=972722 Zdenek -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-19 Branched report: 20130619 changes
Compose started at Wed Jun 19 09:15:03 UTC 2013 Broken deps for x86_64 -- [avgtime] avgtime-0-0.5.git20120724.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.i686 requires PQ derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires pq derelict-pq-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires PQ derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.i686 requires TCOD derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires tcod derelict-tcod-devel-3-13.20130516gitd8aa11d.fc19.x86_64 requires TCOD [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [dsqlite] dsqlite-1.0-4.fc19.i686 requires libphobos-ldc.so.60 dsqlite-1.0-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [dustmite] dustmite-1-8.20121031git1fb3ac4.fc18.x86_64 requires libphobos-ldc.so.60()(64bit) [freeipa] freeipa-server-strict-3.2.1-1.fc19.x86_64 requires pki-ca = 0:10.0.2 freeipa-server-strict-3.2.1-1.fc19.x86_64 requires 389-ds-base = 0:1.3.1.0 [gl3n] gl3n-0.20120813-4.fc19.i686 requires libphobos-ldc.so.60 gl3n-0.20120813-4.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc19.noarch requires python-virtinst [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [nodejs-tilelive] nodejs-tilelive-4.4.3-2.fc19.noarch requires npm(optimist) < 0:0.4 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [tango] tango-2-12.20120821git7b92443.fc19.i686 requires libphobos-ldc.so.60 tango-2-12.20120821git7b92443.fc19.x86_64 requires libphobos-ldc.so.60()(64bit) [zarafa] php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 Broken deps for i386 -- [avgtime] avgtime-0-0.5.git20120724.fc19.i686 requires libphobos-ldc.so.60 [derelict] derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires ogg derelict-ogg-devel-3-13.20130516gitd8aa11d.fc19.i686 requires OGG derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires pq derelict-pq-3-13.20130516gitd8aa11d.fc19.i686 requires PQ der
Fedora 19 updates-testing report
The following Fedora 19 Security updates need testing: Age URL 63 https://admin.fedoraproject.org/updates/FEDORA-2013-5801/mantis-1.2.15-1.fc19 18 https://admin.fedoraproject.org/updates/FEDORA-2013-9715/heat-jeos-9-1.fc19 10 https://admin.fedoraproject.org/updates/FEDORA-2013-10381/owncloud-4.5.12-1.fc19 6 https://admin.fedoraproject.org/updates/FEDORA-2013-10678/python-keystoneclient-0.2.3-4.fc19 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10742/fail2ban-0.8.10-1.fc19 3 https://admin.fedoraproject.org/updates/FEDORA-2013-10908/xen-4.2.2-7.fc19 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10996/nagios-3.5.0-5.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11142/dbus-1.6.12-1.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11257/java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc19 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11135/haproxy-1.4.24-1.fc19 The following builds have been pushed to Fedora 19 updates-testing augeas-1.1.0-1.fc19 autofs-5.0.7-22.fc19 cloud-utils-0.27-5.fc19 cp2k-2.4-1.fc19 dyninst-8.1.2-1.fc19 eclipse-birt-4.3.0-1.fc19 eclipse-dtp-1.11.0-1.fc19 ecore-1.7.7-1.fc19 esc-1.1.0-20.fc19 evas-1.7.7-1.fc19 fcitx-4.2.7-4.fc19 fedmsg-notify-0.5.1-1.fc19 ghc-crypto-api-0.11-2.fc19 ibus-hangul-1.4.2-5.fc19 ibus-typing-booster-1.0.3-1.fc19 icedtea-web-1.4-2.fc19 initial-setup-0.3.6-2.fc19 java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc19 libeina-1.7.7-1.fc19 libgit2-glib-0.0.2-2.fc19 libxdiff-1.0-2.fc19 mawk-1.3.4-1.20130219.fc19 nodejs-less-1.4.0-1.fc19 os-prober-1.58-2.fc19 python-rosdistro-0.2.8-2.20130602git6e83551.fc19 roundcubemail-0.9.2-1.fc19 rubygem-qpid_messaging-0.22.0-1.fc19 scl-utils-20130529-1.fc19 targetcli-2.1.fb26-2.fc19 Details about builds: augeas-1.1.0-1.fc19 (FEDORA-2013-11267) A library for changing configuration files Update Information: See https://github.com/hercules-team/augeas/blob/master/NEWS for details Fix parsing of /etc/sysconfig/network. ChangeLog: * Wed Jun 19 2013 David Lutterkort - 1.1.0-1 - Update to 1.1.0; remove all patches * Tue Jun 18 2013 Richard W.M. Jones - 1.0.0-4 - Fix /etc/sysconfig/network (RHBZ#904222). * Wed Jun 5 2013 Richard W.M. Jones - 1.0.0-3 - Don't package lenses in tests/ subdirectory. References: [ 1 ] Bug #904222 - augeas-libs-1.0.0-1.el5 update prevents setting /etc/sysconfig/network https://bugzilla.redhat.com/show_bug.cgi?id=904222 autofs-5.0.7-22.fc19 (FEDORA-2013-11256) A tool for automatically mounting and unmounting filesystems Update Information: - misc man page fixes (bz948517). - fix probe each nfs version in turn for singleton mounts. - add a couple of upstream fixes and a bunch of changes based on a Covarity report. - dont probe rdma mounts. - fix interface address null check. - add fixes for bug 961312 and add configure option to control sloppy mount option. ChangeLog: * Wed Jun 19 2013 Ian Kent - 1:5.0.7-22 - misc man page fixes (bz948517). * Wed Jun 12 2013 Ian Kent - 1:5.0.7-21 - fix probe each nfs version in turn for singleton mounts (bz973537). * Tue Jun 11 2013 Ian Kent - 1:5.0.7-20 - fix master map mount options matching. - fix master map bogus keywork match. - fix fix map entry duplicate offset detection. - add a number of fixes based on a Covarity report. * Mon May 27 2013 Ian Kent - 1:5.0.7-19 - dont probe rdma mounts. * Fri May 24 2013 Ian Kent - 1:5.0.7-17 - fix interface address null check. * Mon May 13 2013 Ian Kent - 1:5.0.7-16 - make dump maps check for duplicate indirect mounts (bz961312). - document allowed map sources in auto.master(5) (bz961312). - add enable sloppy mount option to configure. References: [ 1 ] Bug #973537 - [abrt] autofs-5.0.7-20.fc19: mount_mount: Process /usr/sbin/automount was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=973537 [ 2 ] Bug #961312 - Autofs ignore additional files from /etc/auto.master.d on same mountpoint https://bugzilla.redhat.com/show_bug.cgi?id=961312 ==
Re: Fedora 19 Final status, testing/karma requests and needed fixes
On Tue, Jun 18, 2013 at 18:02:35 -0700, Adam Williamson wrote: Releng team: when a new selinux-policy is available, roll some new cloud test images (964006) Are we going to start getting non-desktop type live images or have those all been dropped for f19? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Delta rpm times and reliability?
Tom Horsley gmail.com> writes: > Is it my imagination, or is it taking fantastically longer > in f19 to do the "rebuild rpms from delta" phase of yum > update? The only change I've noticed is that the progress indicator when rebuilding deltas is updated much less often than it did with yum-presto, so it goes from 0 to 100% in several jumps instead of continuously. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20130619 changes
Compose started at Wed Jun 19 08:15:02 UTC 2013 Broken deps for x86_64 -- [aries-blueprint] aries-blueprint-0.3.1-5.fc19.noarch requires asm2 [cxf] 1:cxf-rt-2.6.6-1.fc19.noarch requires asm2 [drbd] drbd-heartbeat-8.4.2-2.fc19.x86_64 requires heartbeat [ekiga] ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit) [eruby] eruby-libs-1.0.5-24.fc20.i686 requires ruby(abi) eruby-libs-1.0.5-24.fc20.x86_64 requires ruby(abi) [evolution-rss] 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeutil.so()(64bit) 1:evolution-rss-0.3.93-3.fc20.x86_64 requires libeshell.so()(64bit) [ffgtk] ffgtk-plugin-evolution-0.8.5-1.fc19.x86_64 requires libeutil.so()(64bit) ffgtk-plugin-evolution-0.8.5-1.fc19.x86_64 requires libeshell.so()(64bit) [gdb-heap] gdb-heap-0.5-12.fc19.x86_64 requires glibc(x86-64) = 0:2.17 [gnuplot] gnuplot-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) gnuplot-minimal-4.6.2-2.fc20.x86_64 requires libgd.so.2()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [koji] koji-vm-1.8.0-1.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) kyua-cli-tests-0.5-3.fc19.x86_64 requires liblutok.so.0()(64bit) [lancet] lancet-1.0.1-6.fc19.noarch requires ant-nodeps >= 0:1.7.1 [mail-notification] mail-notification-evolution-plugin-5.4-71.git.eab5c13.fc20.x86_64 requires libeutil.so()(64bit) mail-notification-evolution-plugin-5.4-71.git.eab5c13.fc20.x86_64 requires libeshell.so()(64bit) [nodejs-better-assert] nodejs-better-assert-1.0.0-1.fc20.noarch requires npm(callsite) = 0:1.0.0 [openbox] gdm-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel gnome-panel-control-3.5.0-11.20121001git782b28.fc19.x86_64 requires gnome-panel [openlierox] openlierox-0.59-0.11.beta10.fc20.x86_64 requires libgd.so.2()(64bit) [ovirt-engine] ovirt-engine-notification-service-3.1.0-1.fc19.noarch requires classpathx-mail [ovirt-guest-agent] ovirt-guest-agent-gdm-plugin-1.0.6-6.fc19.x86_64 requires libgdmsimplegreeter.so.1()(64bit) [oyranos] oyranos-libs-0.4.0-7.fc19.i686 requires libraw.so.5 oyranos-libs-0.4.0-7.fc19.x86_64 requires libraw.so.5()(64bit) [perl-Bio-ASN1-EntrezGene] perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) [perl-Bio-SamTools] perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) [perl-PDL] perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) [python-TraitsBackendQt] python-TraitsBackendQt-3.5.0-5.fc19.noarch requires python-TraitsGUI [python-flask-admin] python-flask-admin-1.0.5-3.fc20.noarch requires python-wtf-peewee [ruby-RMagick] ruby-RMagick-2.13.1-11.fc20.1.x86_64 requires ImageMagick = 0:6.8.3.9 [rubygem-openshift-origin-common] rubygem-openshift-origin-common-1.8.10-1.fc20.noarch requires rubygem(safe_yaml) [rubygem-openshift-origin-node] rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires rubygem(safe_yaml) rubygem-openshift-origin-node-1.9.15-1.fc20.noarch requires openshift-origin-node-proxy [rubygem-qpid] rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid-0.16.0-14.fc20.x86_64 requires libqpidclient.so.5()(64bit) [sagemath] sagemath-core-5.9-5.fc20.i686 requires libgd.so.2 sagemath-core-5.9-5.fc20.x86_64 requires libgd.so.2()(64bit) [scala] scala-2.9.2-2.fc19.noarch requires osgi(org.scala-ide.scala.library) [shim-signed] shim-0.2-4.4.fc20.x86_64 requires shim-unsigned >= 0:0.3-2.fc20 [spacewalk-web] spacewalk-dobby-1.9.22-2.fc19.noarch requires perl(Spacewalk::Setup) [spring] spring-94.1-1.fc20.x86_64 requires libassimp.so.2()(64bit) [sumwars] sumwars-0.5.6-12.fc20.x86_64 requires libenet-1.3.7.so()(64bit) [texlive] 2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.x86_64 requires libgd.so.2()(64bit) [zarafa] libmapi-7.0.13-1.fc19.i686 requires libicalss.so.0 libmapi-7.0.13-1.fc19.i686 requires libical.so.0 libmapi-7.0.13-1.fc19.x86_64 requires libicalss.so.0()(64bit) libmapi-7.0.13-1.fc19.x86_64 requires libical.so.0()(64bit) php-mapi-7.0.13-1.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapi-7.0.13-1.fc19.x86_64 requires php(api) = 0:20100412-x86-64 zarafa-ical-7.0.13-1.fc19.x86_64 requires libi
Delta rpm times and reliability?
Is it my imagination, or is it taking fantastically longer in f19 to do the "rebuild rpms from delta" phase of yum update? It also seems like there are always a half dozen or so rpms that report deltas don't match and it has to download the whole thing. (The update I just did had dbus-libs and a bunch of nss* rpms that didn't match as well as some others I don't remember). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fail2ban denied again by selinux
On Tue, 2013-06-18 at 23:01 -0700, Adam Williamson wrote: > On Wed, 2013-06-19 at 08:51 +0300, Cristian Sava wrote: > > After recent updates fail2ban was broken again. > > For this kind of thing, the appropriate thing to do is file a bug > report. It doesn't make much sense to post it to the mailing list: you > cause noise for the 99% of people who don't use fail2ban, but your > report is not easily findable by anyone who does use fail2ban after a > few days - a bug report against fail2ban is going to be much easier to > find later. Done https://bugzilla.redhat.com/show_bug.cgi?id=975695 You're right. sorry for the noise. C. Sava -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
