Re: google-chrome transaction error...
On Thu, May 3, 2012 at 9:56 PM, Rob Healey wrote: > Greetings: > > Upon trying to install this software, I got this issue... > > Transaction Check Error: > file /usr/bin from install of > google-chrome-unstable-20.0.1123.4-135092.x86_64 conflicts with file from > package filesystem-3.1-1.fc18.x86_64 It's a problem with Google's packaging and Rawhide that they need to fix. See http://thread.gmane.org/gmane.linux.redhat.fedora.testers/98099 -T.C. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
google-chrome transaction error...
Greetings: Upon trying to install this software, I got this issue... Transaction Check Error: file /usr/bin from install of google-chrome-unstable-20.0.1123.4-135092.x86_64 conflicts with file from package filesystem-3.1-1.fc18.x86_64 -- Sincerely yours, Rob G. Healey -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 17 updates-testing report
The following Fedora 17 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-2012-5785/python3-3.2.3-5.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6334/sectool-0.9.5-7.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7070/postgresql-pgpoolAdmin-3.1.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6494/wordpress-3.3.2-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7010/vdr-1.7.27-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7199/evolution-mapi-3.4.1-2.fc17,openchange-1.0-4.fc17,samba4-4.0.0-46alpha18.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7259/drupal6-og-2.3-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-/bind-dyndb-ldap-1.1.0-0.11.rc1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6674/puppet-2.7.13-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6704/asterisk-10.3.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6869/php-5.4.1-1.fc17,maniadrive-1.2-38.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6963/polarssl-1.1.3-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7086/seamonkey-2.9.1-1.fc17 The following Fedora 17 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/FEDORA-2012-7265/livecd-tools-17.11-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7271/xorg-x11-drv-intel-2.19.0-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7276/accountsservice-0.6.19-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7255/gtkhtml3-4.4.1-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7251/lorax-17.17-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7262/biosdevname-0.4.0-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7269/rpm-4.9.1.3-6.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7254/udisks2-1.94.0-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7198/libXi-1.6.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7203/libwacom-0.5-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7215/xorg-x11-drv-synaptics-1.6.0-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7078/gcc-4.7.0-3.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7105/mdadm-3.2.3-9.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7061/anaconda-17.24-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7091/nss-3.13.4-3.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-7064/fedora-logos-17.0.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6928/iproute-3.3.0-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6961/db4-4.8.30-10.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6978/gphoto2-2.4.14-1.fc17,libgphoto2-2.4.14-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6930/perl-Compress-Raw-Lzma-2.052-1.fc17,perl-Compress-Raw-Zlib-2.052-1.fc17,perl-Compress-Raw-Bzip2-2.052-1.fc17,perl-IO-Compress-2.052-1.fc17,perl-IO-Compress-Lzma-2.052-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6975/usbmuxd-1.0.8-2.fc17 https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-119.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6823/xorg-x11-drv-vesa-2.3.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6660/libvdpau-0.4.1-7.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6693/mactel-boot-0.9-5.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6698/perl-Net-SSLeay-1.48-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6598/openldap-2.4.31-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6475/gdisk-0.8.4-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6476/telepathy-glib-0.18.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6453/pcre-8.21-5.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6075/colord-0.1.19-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6111/sane-backends-1.0.22-10.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-6165/perl-IO-Socket-SSL-1.66-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-5976/pungi-2.11-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-5710/libpciaccess-0.13.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-5575/libxcb-1.8.1-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-5335/xmlrpc-c-1.29.3-1702.svn2290.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-4131/webkitgtk3-1.7.91-2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-3251/bluez-4.99-1.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-3174/xorg-x11-drv-nouveau-0.0.16-35.20120306gitf5d1cd2.fc17 https://admin.fedoraproject.org/updates/FEDORA-2012-1726/gpgme-1.3.0-8
Re: Palimsest discrepancy
Finally back in town again and back to Palimpsest. A little background first. My box is a Core 2 Quad Q6600 Kentsfield at 2.4GHz, Asus P5K mobo, 6GB core, XFX GeForce 8600 video card and two hard drive drawers. For OS, Grub1 multi-booting Fedora 15, 16, 17β, Win-XP and Win-7. By January 2011, Fedora 14 reported for the Maxtor 320GB drive: “DISK HAS MANY BAD SECTORS Age: 136.0 days PwrCycles: 1285Bad sectors: -4”, with a recommendation for immediate back-up and replacement. At that time a Seagate ST1000 1TB drive was installed internally in the box and partitioned to accept various data partitions and a Fedora OS to be used as a back-up OS. The system normally operates from one of the OSs in a drive slipped in one of the drive drawers. All data in the Maxtor 320GB was moved to the Seagate drive and is periodically imaged to another external drive via a drawer. The Maxtor 320 GB drive was imaged to a new WD 320GB drive for back-up. The Maxtor was kept in service to see when it would fail. So far it has not! What has changed in F-17β from F-14,F-15 and F-16 to change the report to OK with 0 bad sectors. All three previous Fedoras still report for the disk as of today: “DISK HAS MANY BAD SECTORS Age: 248.3 days PwrCycles: 3370 Bad sectors: -4”. This amounts to 2695.2 hours and 2085 power cycles: since the first warning. A Samsung 160GB that was removed from service o 2010-11-07 at age: 90.7 days with 1115 power cycles and 12 bad sectors, shows under F-14, F-15 and F-16 “ Disk has a few bad sectors” . With F-17β it shows “ Disk is OK Age: 104.7 daysPower Cycles: 1271 Bad Sectors: 12Pending Sectors: 0” hdtune-224 in Windows XP reports the Maxtor as OK. My question is one of trust, which one is accurate? However, I am inclined to believe that is the way Maxtor reports the parameter in question. Thanks to all, Cheers. - Original Message - On Mon, 2012-04-30 at 13:35 -0400, ergodic wrote: > Has anyone experienced Palimpsest discrepancies? > > Palimsest in Fedora 16 reports a disk (MAXTOR STM3320620AS) as > failing: "DISK HAS MANY BAD SECTORS" etc. > SMART: 197 Current pending Sector Count Value -4 sectors. > > Palimsest in Fedora 17 beta reports the same disk (MAXTOR > STM3320620AS) as "OK" > SMART: 197 Current pending Sector Count 0 sectors OK. > > Obviously one is incorrect, which one? Interpretation of the SMART data can be tricky. There's a longstanding bug where palimpsest considers numbers of 'bad' sectors that are well within manufacturers' tolerances to indicate a failing disk: https://bugzilla.redhat.com/show_bug.cgi?id=498115 and it's possible you hit that in F16 and it's been corrected, at least for your particular disk, in F17. That '-4' does seem odd, though, as another poster mentioned. The bug report linked above has some useful diagnostic steps you can take. -- 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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 15 updates-testing report
The following Fedora 15 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-2012-6996/expat-2.1.0-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6395/openssl-1.0.0i-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6511/wordpress-3.3.2-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6630/dokuwiki-0-0.10.20110525.a.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-7246/libsoup-2.34.3-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6629/gdb-7.3.1-50.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6730/openconnect-3.18-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6724/asterisk-1.8.11.1-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6759/bind-dyndb-ldap-1.1.0-0.11.rc1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6911/php-5.3.11-1.fc15,php-eaccelerator-0.9.6.1-9.fc15.3,maniadrive-1.2-32.fc15.3 https://admin.fedoraproject.org/updates/FEDORA-2011-17233/tor-0.2.1.32-1500.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-7131/seamonkey-2.9.1-1.fc15 The following Fedora 15 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/FEDORA-2012-7246/libsoup-2.34.3-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-7117/mdadm-3.2.3-9.fc15 https://admin.fedoraproject.org/updates/kernel-2.6.43.4-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-7149/thunderbird-12.0.1-1.fc15,thunderbird-lightning-1.4-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6996/expat-2.1.0-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6919/mysql-5.5.23-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6629/gdb-7.3.1-50.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6552/PackageKit-0.6.17-2.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6517/pcre-8.12-8.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6395/openssl-1.0.0i-1.fc15 https://admin.fedoraproject.org/updates/FEDORA-2012-6373/fuse-2.8.7-1.fc15.1 https://admin.fedoraproject.org/updates/dracut-009-15.fc15 The following builds have been pushed to Fedora 15 updates-testing 389-ds-base-1.2.10.8-1.fc15 drupal6-6.26-1.fc15 drupal6-pathauto-2.0-1.fc15 drupal7-7.14-1.fc15 libsoup-2.34.3-2.fc15 nickle-2.75-1.fc15 pcp-3.6.3-1.fc15 pcp-gui-1.5.5-1.fc15 perl-Pod-Wordlist-hanekomu-1.121231-1.fc15 perl-Test-Valgrind-1.13-3.fc15 strace-4.7-1.fc15 Details about builds: 389-ds-base-1.2.10.8-1.fc15 (FEDORA-2012-7237) 389 Directory Server (base) Update Information: fix ldclt crash in previous fix a couple of crashes Ticket #348 - crash in ldap_initialize with multiple threads Ticket #347 - IPA dirsvr seg-fault during system longevity test crash bug with multiple transactions and range searches ChangeLog: * Thu May 3 2012 Rich Megginson - 1.2.10.8-1 - Ticket #348 - crash in ldap_initialize with multiple threads - previous fix would crash in ldclt - this fixes that crash * Mon Apr 30 2012 Rich Megginson - 1.2.10.7-1 - Ticket #348 - crash in ldap_initialize with multiple threads - Ticket #347 - IPA dirsvr seg-fault during system longevity test drupal6-6.26-1.fc15 (FEDORA-2012-7234) An open-source content-management platform Update Information: New upstream release. ChangeLog: * Thu May 3 2012 Jon Ciesla - 6.26-1 - New upstream, 818537. References: [ 1 ] Bug #818537 - drupal6-6.26 is available https://bugzilla.redhat.com/show_bug.cgi?id=818537 drupal6-pathauto-2.0-1.fc15 (FEDORA-2012-7229) Automatically generates path aliases Update Information: New upstream version. ChangeLog: * Thu May 3 2012 Peter Borsa - 2.0-1 - Updated to the latest stable. * Fri Jan 13 2012 Fedora Release Engineering - 2.0-0.5.rc2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild --
Fedora 16 updates-testing report
The following Fedora 16 Security updates need testing: https://admin.fedoraproject.org/updates/FEDORA-2012-6529/argyllcms-1.4.0-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7124/postgresql-pgpoolAdmin-3.1.1-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-5833/python3-3.2.3-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6628/dokuwiki-0-0.10.20110525.a.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6542/wordpress-3.3.2-2.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-5924/python-2.7.3-1.fc16,python-docs-2.7.3-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6614/gdb-7.3.50.20110722-16.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6758/openconnect-3.18-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2011-14691/tomcat6-6.0.32-19.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6722/bind-dyndb-ldap-1.1.0-0.11.rc1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6382/samba4-4.0.0-38.alpha16.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6907/php-5.3.11-1.fc16,php-eaccelerator-0.9.6.1-9.fc16.3,maniadrive-1.2-32.fc16.3 https://admin.fedoraproject.org/updates/FEDORA-2012-7141/seamonkey-2.9.1-1.fc16 The following Fedora 16 Critical Path updates have yet to be approved: https://admin.fedoraproject.org/updates/FEDORA-2012-7238/xorg-x11-drv-nouveau-0.0.16-28.20120321gitab7291d.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7134/policycoreutils-2.1.4-16.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7172/NetworkManager-0.9.4-5.git20120502.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7145/mdadm-3.2.3-9.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7146/analitza-4.8.3-1.fc16,ark-4.8.3-1.fc16,blinken-4.8.3-1.fc16,cantor-4.8.3-1.fc16,filelight-4.8.3-1.fc16,gwenview-4.8.3-1.fc16,jovie-4.8.3-1.fc16,kaccessible-4.8.3-1.fc16,kactivities-4.8.3-1.fc16,kalgebra-4.8.3-1.fc16,kalzium-4.8.3-1.fc16,kamera-4.8.3-1.fc16,kanagram-4.8.3-1.fc16,kate-4.8.3-2.fc16,kbruch-4.8.3-1.fc16,kcalc-4.8.3-1.fc16,kcharselect-4.8.3-1.fc16,kcolorchooser-4.8.3-1.fc16,kdeaccessibility-4.8.3-1.fc16,kdeadmin-4.8.3-1.fc16,kdeartwork-4.8.3-1.fc16,kde-baseapps-4.8.3-1.fc16,kdebindings-4.8.3-1.fc16,kdeedu-4.8.3-1.fc16,kdegames-4.8.3-1.fc16,kdegraphics-4.8.3-1.fc16,kdegraphics-mobipocket-4.8.3-1.fc16,kdegraphics-strigi-analyzer-4.8.3-1.fc16,kdegraphics-thumbnailers-4.8.3-1.fc16,kde-l10n-4.8.3-1.fc16,kdelibs-4.8.3-1.fc16,kdemultimedia-4.8.3-1.fc16,kdenetwork-4.8.3-1.fc16,kdepim-4.8.3-2.fc16,kdepimlibs-4.8.3-1.fc16,kdepim-runtime-4.8.3-2.fc16,kdeplasma-addons-4.8.3-1.fc16,kde-printer-applet-4.8.3-1.fc16,kde-runtime-4.8.3-1.fc16,kdesdk-4.8.3-1.fc16,kdetoys-4.8.3-1.fc16,kdeutils-4.8.3-1.fc16,kde-wallpapers-4.8.3-1.fc16,kde-workspace-4.8.3-3.fc16,kdf-4.8.3-1.fc16,kfloppy-4.8.3-1.fc16,kgamma-4.8.3-1.fc16,kgeography-4.8.3-1.fc16,kgpg-4.8.3-1.fc16,khangman-4.8.3-1.fc16,kig-4.8.3-1.fc16,kimono-4.8.3-1.fc16,kiten-4.8.3-1.fc16,klettres-4.8.3-1.fc16,kmag-4.8.3-1.fc16,kmousetool-4.8.3-1.fc16,kmouth-4.8.3-1.fc16,kmplot-4.8.3-1.fc16,kolourpaint-4.8.3-1.fc16,konsole-4.8.3-1.fc16,kremotecontrol-4.8.3-1.fc16,kross-interpreters-4.8.3-1.fc16,kruler-4.8.3-1.fc16,ksaneplugin-4.8.3-1.fc16,ksecrets-4.8.3-1.fc16,ksnapshot-4.8.3-1.fc16,kstars-4.8.3-1.fc16,ktimer-4.8.3-1.fc16,ktouch-4.8.3-1.fc16,kturtle-4.8.3-1.fc16,kwallet-4.8.3-1.fc16,kwordquiz-4.8.3-1.fc16,libkdcraw-4.8.3-1.fc16,libkdeedu-4.8.3-1.fc16,libkexiv2-4.8.3-1.fc16,libkipi-4.8.3-1.fc16,libksane-4.8.3-1.fc16,marble-4.8.3-1.fc16,okular-4.8.3-1.fc16,oxygen-icon-theme-4.8.3-1.fc16,parley-4.8.3-1.fc16,pykde4-4.8.3-2.fc16,qyoto-4.8.3-1.fc16,rocs-4.8.3-1.fc16,ruby-korundum-4.8.3-1.fc16,ruby-qt-4.8.3-1.fc16,smokegen-4.8.3-1.fc16,smokekde-4.8.3-1.fc16,smokeqt-4.8.3-1.fc16,step-4.8.3-1.fc16,superkaramba-4.8.3-1.fc16,svgpart-4.8.3-1.fc16,sweeper-4.8.3-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-7168/NetworkManager-0.9.4-4.git20120403.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6993/iproute-2.6.39-6.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6994/upower-0.9.16-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6914/mysql-5.5.23-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6837/livecd-tools-16.14-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6726/livecd-tools-16.13-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6614/gdb-7.3.50.20110722-16.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6613/selinux-policy-3.10.0-86.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6516/pcre-8.12-9.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6389/taglib-1.7.2-1.fc16 https://admin.fedoraproject.org/updates/FEDORA-2012-6416/fuse-2.8.7-1.fc16.1 https://admin.fedoraproject.org/updates/FEDORA-2012-3319/GConf2-3.2.3-4.fc16 The following builds have be
Re: dependency problems: samba4-client-4.0.0-45alpha18.fc17.i686 from updates-testing
> Try "yum distro-sync". > > -- Thanks to all for the suggestions provided. # yum distro-sync does cure the problem :) [root@acer-aspire-1 ~]# yum distro-sync Loaded plugins: langpacks, presto, refresh-packagekit fedora/metalink | 14 kB 00:00 fedora | 4.2 kB 00:00 fedora/primary_db| 12 MB 00:22 fedora/group_gz | 434 kB 00:01 updates/metalink | 20 kB 00:00 updates-testing/metalink | 10 kB 00:00 http://download-i2.fedoraproject.org/pub/fedora/linux/updates/testing/17/i386/repodata/repomd.xml: [Errno 14] curl#7 - "Couldn't connect" Trying other mirror. updates-testing | 4.5 kB 00:00 Resolving Dependencies --> Running transaction check ---> Package libsmbclient.i686 1:3.6.5-85.fc17.1 will be a downgrade ---> Package libsmbclient.i686 1:4.0.0-41alpha18.fc17 will be erased ---> Package libwbclient.i686 1:3.6.5-85.fc17.1 will be a downgrade ---> Package libwbclient.i686 1:4.0.0-41alpha18.fc17 will be erased ---> Package samba4-client.i686 1:4.0.0-41alpha18.fc17 will be updated ---> Package samba4-client.i686 1:4.0.0-45alpha18.fc17 will be an update ---> Package samba4-common.i686 1:4.0.0-41alpha18.fc17 will be updated ---> Package samba4-common.i686 1:4.0.0-45alpha18.fc17 will be an update ---> Package samba4-dc.i686 1:4.0.0-41alpha18.fc17 will be updated ---> Package samba4-dc.i686 1:4.0.0-45alpha18.fc17 will be an update ---> Package samba4-dc-libs.i686 1:4.0.0-41alpha18.fc17 will be updated ---> Package samba4-dc-libs.i686 1:4.0.0-45alpha18.fc17 will be an update ---> Package samba4-libs.i686 1:4.0.0-41alpha18.fc17 will be updated ---> Package samba4-libs.i686 1:4.0.0-45alpha18.fc17 will be an update ---> Package setools-libs.i686 0:3.3.7-22.fc17 will be a downgrade ---> Package setools-libs.i686 0:3.3.7-23.fc17 will be erased ---> Package setools-libs-python.i686 0:3.3.7-22.fc17 will be a downgrade ---> Package setools-libs-python.i686 0:3.3.7-23.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved Package Arch Version Repository Size Updating: samba4-client i686 1:4.0.0-45alpha18.fc17updates-testing 757 k samba4-common i686 1:4.0.0-45alpha18.fc17updates-testing 573 k samba4-dc i686 1:4.0.0-45alpha18.fc17updates-testing 1.0 M samba4-dc-libsi686 1:4.0.0-45alpha18.fc17updates-testing 392 k samba4-libs i686 1:4.0.0-45alpha18.fc17updates-testing 3.4 M Downgrading: libsmbclient i686 1:3.6.5-85.fc17.1 fedora1.6 M libwbclient i686 1:3.6.5-85.fc17.1 fedora 69 k setools-libs i686 3.3.7-22.fc17 fedora406 k setools-libs-python i686 3.3.7-22.fc17 fedora209 k Transaction Summary Upgrade5 Packages Downgrade 4 Packages Total download size: 8.2 M Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata updates-testing/prestodelta | 681 kB 00:02 Processing delta metadata Package(s) data still to download: 6.0 M (1/9): libsmbclient-3.6.5-85.fc17.1.i686.rpm | 1.6 MB 00:09 (2/9): libwbclient-3.6.5-85.fc17.1.i686.rpm | 69 kB 00:00 (3/9): samba4-client-4.0.0-45alpha18.fc17.i686.rpm | 757 kB 00:01 (4/9): samba4-common-4.0.0-45alpha18.fc17.i686.rpm | 573 kB 00:01 (5/9): samba4-dc-4.0.0-45alpha18.fc17.i686.rpm | 1.0 MB 00:02 (6/9): samba4-dc-libs-4.0.0-45alpha18.fc17.i686.rpm | 392 kB 00:02 (7/9): samba4-libs-4.0.0-45alpha18.fc17.i686.rpm | 3.4 MB 00:12 (8/9): setools-libs-3.3.7-22.fc17.i686.rpm | 406 kB 00:01 (9/9): setools-libs-python-3.3.7-22.fc17.i686.rpm| 209 kB 00:00 Total 233 kB/s | 8.2 MB 00:36 Running Transaction Check Running Transaction Test Transaction Test Succeeded Running Transaction Updating : 1:samba4-libs-4.0.0-45alpha18.fc17.i686 1/18 Installing : 1:libsmbclient-3.6.5-85.fc17.1.i686 2/18 /sbin/ldconfig: /lib/libsmbclient.so.0 is not a symbolic link Updating : 1:samba4-dc-4.0.0-45alpha18.fc17.i686
re: gnome shell calendar colors
Greetings: Thanks for the idea of changing the theme or using the High Contrast, but the only thing that I want to change is the calendar portion not everything... I was hoping the colors would be in a css file somewhere... -- Sincerely yours, Rob G. Healey -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thursday, May 3, 2012, 4:01:44 PM, Adam Williamson wrote: > On Thu, 2012-05-03 at 13:41 -0400, Al Dunsmuir wrote: >> On Thursday, May 3, 2012, 1:22:29 PM, Adam Pribyl wrote: >> > On Thu, 3 May 2012, Adam Jackson wrote: >> >> On 5/3/12 7:36 AM, Adam Williamson wrote: >> >> The world is full of Adams, it appears! > If certain religions are to be believed, at one point the world's human > population was entirely composed of us. ;) Indeed. Could even call it one happy Adams Family. Oh wait, that was the TV show, not the book. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: gedit: drag & drop freezes forever mouse pointer on drag mode
On Thu, May 3, 2012 at 9:42 PM, Michael Schwendt wrote: > I've visited http://bugz.fedoraproject.org/gedit and found: > https://bugzilla.redhat.com/808789 > > Steps on how to reproduce attached to that ticket. Thanks! I SIGSEGV'd gedit during the hang and uploaded the backtrace to that bug report, I hope it's worth something. -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
I am not sure what caused this because i have fedora 17 beta installed on my old p4 pc and its working fine earlier i had fedora 16 installed i didn't faced any issue with selinux On Fri, May 4, 2012 at 2:14 AM, Michael Hennebry wrote: > On Wed, 2 May 2012, Adam Williamson wrote: > >> On Sat, 2012-04-28 at 23:46 -0500, Michael Hennebry wrote: >> >>> What should I do about the messages? >>> Would yum reinstalling some packages, e.g. selinux-policy-targeted, help? >>> What are the consequences of just ignoring them? >> >> >> At this point I'd say file a bug against selinux-policy for that issue, >> at least. I'm not sure what's going on there. > > > 'Tis done: https://bugzilla.redhat.com/show_bug.cgi?id=818748 > > I expect that it will be a while before the bug is either fixed or > abandoned. > What to do in the mean time? > Should I use it as-is? > Will something blow up if I try to enable selinux? > Should I stick with F14? > Should I yum reinstall packages? > > -- > 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 -- Akshay vyas -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome shell calendar colors...
On Thu, May 03, 2012 at 09:03:38PM +0100, Adam Williamson wrote: > On Thu, 2012-05-03 at 21:39 +0200, Michal Jaegermann wrote: > > On Thu, May 03, 2012 at 11:38:32AM -0700, Rob Healey wrote: > > > > > > Would anyone know where to look for the background and foreground colors > > > for the gnome-shell calendar? > > > > Strictly speaking you cannot do > > that. > > You'd think the High Contrast accessibility option would do something > about it, at least. "Something" it does. Not anything really useful where I tried. Maybe it helps somebody but vision problems do not fit into "one straightjacket fits all" model, I am afraid. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17 vs. Pentium 4
On Wed, 2 May 2012, Adam Williamson wrote: On Sat, 2012-04-28 at 23:46 -0500, Michael Hennebry wrote: What should I do about the messages? Would yum reinstalling some packages, e.g. selinux-policy-targeted, help? What are the consequences of just ignoring them? At this point I'd say file a bug against selinux-policy for that issue, at least. I'm not sure what's going on there. 'Tis done: https://bugzilla.redhat.com/show_bug.cgi?id=818748 I expect that it will be a while before the bug is either fixed or abandoned. What to do in the mean time? Should I use it as-is? Will something blow up if I try to enable selinux? Should I stick with F14? Should I yum reinstall packages? -- 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: F17: gedit: drag & drop freezes forever mouse pointer on drag mode
On Thu, 3 May 2012 21:00:21 +0200, MS (Michael) wrote: > On Thu, 3 May 2012 18:27:32 +0100, PF (Pedro) wrote: > > > Arg yes it stopped working for me as > > well > > > > Try this: > > $ gedit & > > $ killall nautilus ; nautilus /usr/share/doc/fedora-release-17 & > > > > Now, double-click the "GPL" file. A new gedit window should appear. > > > > To allow you to resume your work afterwards, on another console, do: > > $ sleep 15; killall gedit > > > > Try to drag and drop the gedit tab "GPL" to the other gedit window. > > > > Watch your mouse pointer freeze on drag mode, disabling it > > effectively; keyboard does not seem to respond as well. After ~15 > > seconds, when gedit windows are killed, you'll get your mouse and > > keyboard back. > > > > Can anyone confirm? > > Yes. Dragging the _tab_ of the gedit, that has loaded the GPL file, > to the empty gedit results in a freeze as described. I've visited http://bugz.fedoraproject.org/gedit and found: https://bugzilla.redhat.com/808789 Steps on how to reproduce attached to that ticket. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 loadavg: 0.00 0.03 0.05 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2012-05-04 @ 17:00 UTC - F17 Final Blocker Bug Review #4
# F17 Final Blocker Review meeting #4 # Date: 2012-05-04 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net Apparently we're trying to set a record for the number of blocker review meetings in one week. We should get through the rest of them this time, though. The next review meeting will be on Friday, 2012-05-04. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at: https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Tim signature.asc Description: PGP signature ___ 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
2012-05-03@ 17:00 UTC - F17 Final Blocker Bug Review #3 minutes
== #fedora-bugzappers: f17-final-blocker-review-3 == Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-03/f17-final-blocker-review-3.2012-05-03-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-03/f17-final-blocker-review-3.2012-05-03-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-03/f17-final-blocker-review-3.2012-05-03-17.00.log.html Meeting summary --- * Roll Call (tflink, 17:00:45) * introduction (tflink, 17:05:59) * Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs. (tflink, 17:06:11) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (tflink, 17:06:48) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (tflink, 17:07:10) * LINK: https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria (tflink, 17:07:41) * 13 proposed blockers (tflink, 17:07:58) * 12 accepted blockers (tflink, 17:07:59) * 10 proposed NTH\ (tflink, 17:07:59) * (816701) Anaconda should not default to gpt on BIOS systems (tflink, 17:10:10) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=816701 (tflink, 17:10:10) * Proposed Blocker, MODIFIED (tflink, 17:10:10) * AGREED: - 816701 - RejectedBlocker - While this is a sensible change, it doesn't hit any of the release criteria and we're still before the final code freeze (tflink, 17:18:23) * (814690) Users are not logged out correctly (tflink, 17:18:31) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=814690 (tflink, 17:18:31) * Proposed Blocker, NEW (tflink, 17:18:31) * AGREED: - 814690 - At the moment, this appears to be too much of a corner case to be a blocker but we want to give a bit more time for new reports and triage before making a final decision on blocker status (tflink, 17:35:19) * (799667) [abrt] gnome-settings-daemon-3.3.90.1-1.fc17: g_logv: Process /usr/libexec/gnome-settings-daemon was killed by signal 5 (SIGTRAP) (tflink, 17:35:36) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=799667 (tflink, 17:35:39) * Proposed Blocker, NEW (tflink, 17:35:42) * AGREED: - 799667 - RejectedBlocker - While this is ugly and the cause is not immediately obvious, it was deemed too much of a corner case to take as a blocker for F17 final (tflink, 17:56:18) * (815243) reset of gnome-shell starts NewtorkManager.service (tflink, 17:56:21) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=815243 (tflink, 17:56:24) * Proposed Blocker, NEW (tflink, 17:56:26) * AGREED: - 815243 - RejectedBlocker - This doesn't hit any of the release criteria, won't affect any of the livecds and could be fixed with an update. (tflink, 18:01:24) * (809111) grub2-probe fails during install (tflink, 18:01:44) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=809111 (tflink, 18:01:45) * Proposed Blocker, NEW (tflink, 18:01:45) * AGREED: - 809111 - AcceptedBlocker - Violates the F17 final release criterion "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" (tflink, 18:10:13) * (804363) kmix crashes when pulseaudio exits (tflink, 18:13:05) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=804363 (tflink, 18:13:05) * Proposed Blocker, VERIFIED (tflink, 18:13:05) * AGREED: - 804363 - The affected builds have already been pushed to stable and the fix has been verified - no need for blocker status and will close the bug (tflink, 18:17:22) * (817298) ipw2x00: backport patch for nl80211 cipher suite reporting (tflink, 18:17:33) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=817298 (tflink, 18:17:36) * Proposed Blocker, ON_QA (tflink, 18:17:39) * AGREED: - 817298 - RejectedBlocker, AcceptedNTH - This only affects a minority of hardware and only in fallback mode - deemed not common enough to justify blocker status but accepted as NTH. (tflink, 18:24:02) * (816495) Network time can't be enabled (tflink, 18:24:13) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=816495 (tflink, 18:24:13) * Proposed Blocker, ON_QA (tflink, 18:24:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=815748 (kparal, 18:26:05) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=816493 (kparal, 18:26:13) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=816495 (kparal, 18:26:21) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=815748 (tflink, 18:26:54) * AGREED: - 816495 - RejectedBlocker - This doesn't clearly hit any
Re: gnome shell calendar colors...
On Thu, 2012-05-03 at 21:39 +0200, Michal Jaegermann wrote: > On Thu, May 03, 2012 at 11:38:32AM -0700, Rob Healey wrote: > > > > Would anyone know where to look for the background and foreground colors > > for the gnome-shell calendar? I have a very hard time seeing with my > > limited sight, so I need to change the colors so that I may be able to see > > it... > > This is really waaay out of topic on a test list but I know perfectly > well what you are talking about (while this is apparently beyond limits > of comprehension to GNOME developers). Strictly speaking you cannot do > that. What you can, at least for now until somebody will "improve" it, You'd think the High Contrast accessibility option would do something about it, at least. -- 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: GMA500 vs. G3 software render
On Thu, 2012-05-03 at 13:41 -0400, Al Dunsmuir wrote: > On Thursday, May 3, 2012, 1:22:29 PM, Adam Pribyl wrote: > > On Thu, 3 May 2012, Adam Jackson wrote: > >> On 5/3/12 7:36 AM, Adam Williamson wrote: > > The world is full of Adams, it appears! If certain religions are to be believed, at one point the world's human population was entirely composed of us. ;) -- 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 calendar colors...
On Thu, May 03, 2012 at 11:38:32AM -0700, Rob Healey wrote: > > Would anyone know where to look for the background and foreground colors > for the gnome-shell calendar? I have a very hard time seeing with my > limited sight, so I need to change the colors so that I may be able to see > it... This is really waaay out of topic on a test list but I know perfectly well what you are talking about (while this is apparently beyond limits of comprehension to GNOME developers). Strictly speaking you cannot do that. What you can, at least for now until somebody will "improve" it, is to install gnome-tweak-tool and using it switch to some other than a default gnome-shell-theme with a hope that this, plus maybe some font tweaks, will give you something passable. This is changing more that you bargained for in the first place but this is AFAIK all what you can get; without your own code to rewrite the whole sheebang that is. You can find some gnome-shell-theme-... packages for Fedora and more if you will look around. Michal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: gedit: drag & drop freezes forever mouse pointer on drag mode
On Thu, 3 May 2012 18:27:32 +0100, PF (Pedro) wrote: > Arg yes it stopped working for me as well > > Try this: > $ gedit & > $ killall nautilus ; nautilus /usr/share/doc/fedora-release-17 & > > Now, double-click the "GPL" file. A new gedit window should appear. > > To allow you to resume your work afterwards, on another console, do: > $ sleep 15; killall gedit > > Try to drag and drop the gedit tab "GPL" to the other gedit window. > > Watch your mouse pointer freeze on drag mode, disabling it > effectively; keyboard does not seem to respond as well. After ~15 > seconds, when gedit windows are killed, you'll get your mouse and > keyboard back. > > Can anyone confirm? Yes. Dragging the _tab_ of the gedit, that has loaded the GPL file, to the empty gedit results in a freeze as described. -- Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 loadavg: 0.22 0.15 0.09 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
gnome shell calendar colors...
Greetings: Would anyone know where to look for the background and foreground colors for the gnome-shell calendar? I have a very hard time seeing with my limited sight, so I need to change the colors so that I may be able to see it... Could anyone help me with this? -- Sincerely yours, Rob G. Healey -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thursday, May 3, 2012, 1:22:29 PM, Adam Pribyl wrote: > On Thu, 3 May 2012, Adam Jackson wrote: >> On 5/3/12 7:36 AM, Adam Williamson wrote: The world is full of Adams, it appears! >>> On Thu, 2012-05-03 at 13:21 +0200, Adam Pribyl wrote: While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), >> >> When you say "latest development", what exactly are you referring to? >> > OK, your "latest development" is probably somewhere else, than mine, I > meant F16-17 kernel psb->gma500 that made things work somehow out of the > box. >>> I don't know if there's a plan to blacklist systems with sufficiently >>> 'bad' CPU performance from using software rendering, or if ajax is of >>> the opinion that just about anything should be able to run Shell >>> acceptably via software rendering and if a system doesn't, there's a bug >>> that needs fixing...ajax, is there an overview here? >> >> I don't currently have such a plan. I could, I guess. >> >> My personal opinion is that Core and up are pretty tolerable and >> anything less kind of isn't but also already kind of wasn't. But I no >> longer really have any idea whether my threshold for acceptable >> interactivity matches that of anyone else. Nor do I own any of the > This you will notice, as letters written on the screen via keyboard are > lagging behind what you type and gnome-shell is taking 100% cpu on any > action. >> non-free Intel kit - on the grounds of not rewarding Intel's duplicity - >> so I have no real idea what it's like there either. >> >> So if we want to blacklist low performers, okay, that's a thing we can >> do I suppose. Where do we draw the line? > I am not sure the blacklisting gets a wider support, thou just ideas: > 1. if software render is enabled and CPU is less then Core > (if you meant Intel Core) or AMD Athlon, use fallback. Since Gnome development is pressing for fallback to be removed, this will eventually no longer be an alternative. I've using Gnome 3 fallback on older Radeon hardware. I've tried to upgrade beyond 9200 SE level GPU, but am now hitting limitation with the power supply in the smaller desktops (AGP 8X) I am using as limited servers (DNS, DHCP, Samba). The reason I hopped on this thread is that the older cards that I was using use the R100 driver, and these newer ones use the R2xx driver. Both are currently blacklisted by Gnome 3. Since there was news that the ancient ATI Rage was updated to use current acceleration, one hope is that the R2xx drives will eventually follow suit. I owe Ajax some BZs, I suspect. > 2. ask testers during the test period and testdays to report Very subjective. Better to have an easy-to-use X configuration control. > 2a. measure difference between g3 sofware render and fallback (via > x11perf?) > 2b. check the cpu load caused by process ghome-shell during some simple > action like window gnome-terminal switching is higher than 50% for some > time? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thu, 3 May 2012, Bodhi Zazen wrote: Just thought I would weigh in on this issue ... I use the gma500 and, yes g3 is a bit slow, but performance has been improving. I follow your blog closely, I have 1.33GHz Atom and compared to fallback it is a big difference. With fallback it flies. It is on my to do list to take one of the F17 daily spins for a test drive. I am testing F17 TC2. If you find g3 slow, use another window manager, but I sort of like G3 on my netbook ;) Of cousrse I can, but booting F17 Live on any netbook with poulsbo atom 1.3GHz, makes clear decision - no way. In discussing the issue I think you need to be more specific , are you talking kernel ? The 3.4 kernel should be even better. Or are you talking llvmpipe ? OK.. This was just a simple question, I do not want to complicate things. Just wanted to point out, that software render is a double edge sword. Personally I can live with small gsettings set. Of course the best would be to have gma500 speed up - thats upstream work, but as gma500 is aging I doubt. But I may be wrong. Adam Pribyl - Original Message - From: "Adam Pribyl" To: test@lists.fedoraproject.org Sent: Thursday, May 3, 2012 5:21:06 AM Subject: GMA500 vs. G3 software render While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), G3 software render negates all this for gnome shell as this is extremely slow on Atom. With the fallback mode the G3 is working very well on gma500. But the obvious question is, beside the questionable future of acceleration on gma500 - what is the future of the fallback? Is there still a list of devices that should use fallback "by default"? If yes, then I would nominate the gma500 for it, as this is really horrible experience, making many users scared, just after live CD/USB boot. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: gedit: drag & drop freezes forever mouse pointer on drag mode
On Thu, May 3, 2012 at 5:54 PM, Adam Williamson wrote: > On Thu, 2012-05-03 at 16:55 +0100, Pedro Francisco wrote: >> I need to confirm a bug. > > Not easily, no. For a start, I've never quite figured out the trigger > for the case where a new window opens instead of the document opening in > the existing window: for me just following the above steps doesn't do > it, the .bashrc opens in the first gedit window, so I don't get two > windows at all). Arg yes it stopped working for me as well Try this: $ gedit & $ killall nautilus ; nautilus /usr/share/doc/fedora-release-17 & Now, double-click the "GPL" file. A new gedit window should appear. To allow you to resume your work afterwards, on another console, do: $ sleep 15; killall gedit Try to drag and drop the gedit tab "GPL" to the other gedit window. Watch your mouse pointer freeze on drag mode, disabling it effectively; keyboard does not seem to respond as well. After ~15 seconds, when gedit windows are killed, you'll get your mouse and keyboard back. Can anyone confirm? -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thu, 3 May 2012, Adam Jackson wrote: On 5/3/12 7:36 AM, Adam Williamson wrote: On Thu, 2012-05-03 at 13:21 +0200, Adam Pribyl wrote: While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), When you say "latest development", what exactly are you referring to? OK, your "latest development" is probably somewhere else, than mine, I meant F16-17 kernel psb->gma500 that made things work somehow out of the box. I don't know if there's a plan to blacklist systems with sufficiently 'bad' CPU performance from using software rendering, or if ajax is of the opinion that just about anything should be able to run Shell acceptably via software rendering and if a system doesn't, there's a bug that needs fixing...ajax, is there an overview here? I don't currently have such a plan. I could, I guess. My personal opinion is that Core and up are pretty tolerable and anything less kind of isn't but also already kind of wasn't. But I no longer really have any idea whether my threshold for acceptable interactivity matches that of anyone else. Nor do I own any of the This you will notice, as letters written on the screen via keyboard are lagging behind what you type and gnome-shell is taking 100% cpu on any action. non-free Intel kit - on the grounds of not rewarding Intel's duplicity - so I have no real idea what it's like there either. So if we want to blacklist low performers, okay, that's a thing we can do I suppose. Where do we draw the line? I am not sure the blacklisting gets a wider support, thou just ideas: 1. if software render is enabled and CPU is less then Core (if you meant Intel Core) or AMD Athlon, use fallback. 2. ask testers during the test period and testdays to report 2a. measure difference between g3 sofware render and fallback (via x11perf?) 2b. check the cpu load caused by process ghome-shell during some simple action like window gnome-terminal switching is higher than 50% for some time? - ajax Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thursday, May 3, 2012, 12:52:13 PM, Adam wrote: > On Thu, 2012-05-03 at 10:05 -0400, Adam Jackson wrote: >> So if we want to blacklist low performers, okay, that's a thing we can >> do I suppose. Where do we draw the line? > 'anything Atom is slow as hell' would be an obvious win, I suspect. If > your baseline of acceptable performance is 'Core and up', I think we can > be pretty confident that Atom is not going to make it. I personally believe that blacklisting based on CPU capacity is wrong. Blacklisting might have the side effect of blocking future Atom CPUs (perhaps in a multi-CPU configuration) with a better performance story. It certainly eliminates any pressure to further improve the code. Perhaps a given setup it may be slow, but blacklisting is a non-configurable and arbitrary way to prevent users from making that choice on their own. I am personally using some 32-bit Pentium 4 (desktop and laptop systems. My hardware. My choice. Someone who has a reason to use a given configuration may be more motivated to be patient than a developer who is used to the latest and greatest. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: gedit: drag & drop freezes forever mouse pointer on drag mode
On Thu, 2012-05-03 at 16:55 +0100, Pedro Francisco wrote: > I need to confirm a bug. > > Open one gedit window (MUST BE FROM GNOME-SHELL, either from ALT+F2 > and 'gedit' or using the gnome-shell menus). > > On a command line do, for example: > $ gedit ~/.bashrc > _Another_ gedit window should open. > > To allow you to resume your work afterwards, on another console, do: > $ sleep 15; killall gedit > > Try to drag and drop the ".bashrc" tab to the other gedit window. > > Watch your mouse pointer freeze on drag mode, disabling it > effectively; keyboard does not seem to respond as well. After ~15 > seconds, when gedit windows are killed, you'll get your mouse and > keyboard back. > > Can anyone confirm? Not easily, no. For a start, I've never quite figured out the trigger for the case where a new window opens instead of the document opening in the existing window: for me just following the above steps doesn't do it, the .bashrc opens in the first gedit window, so I don't get two windows at all). -- 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: GMA500 vs. G3 software render
On Thu, 2012-05-03 at 10:05 -0400, Adam Jackson wrote: > So if we want to blacklist low performers, okay, that's a thing we can > do I suppose. Where do we draw the line? 'anything Atom is slow as hell' would be an obvious win, I suspect. If your baseline of acceptable performance is 'Core and up', I think we can be pretty confident that Atom is not going to make it. -- 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: F17: Korganizer: tasks disappearing
On Thu, May 3, 2012 at 5:10 PM, Pedro Francisco wrote: > On Thu, May 3, 2012 at 3:10 PM, Rex Dieter wrote: >> Pedro Francisco wrote: >> >>> Just an heads-up, on F17 Korganizer seems to forget tasks after exiting. Forget it "Personal Calendar" was not checked on Calendar view. Adding a ToDo item would add it to "Personal Calendar"'s Tasks but on next start since it was not checked it would not show it. Checking "Personal Calendar" on Calendar view will show the added ToDo items... P.S.: this is an usability issue since by default "Personal Calendar" is unchecked. Bug report with it? On KDE's or Fedora's bugtracker? -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: kdm vs. gdm
On Thu, May 3, 2012 at 5:12 PM, Rob Healey wrote: > Transaction Check Error: > file /var/spool/gdm from install of kde-settings-kdm-4.8-8.fc18.noarch > conflicts with file from package gdm-1:3.4.1-1.fc18.x86_64 > > I have never had a problem like this before... Not sure but I'm hinting at packaging bug. If no-one else replies with a better answer, file a bug. -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
Just thought I would weigh in on this issue ... I use the gma500 and, yes g3 is a bit slow, but performance has been improving. It is on my to do list to take one of the F17 daily spins for a test drive. If you find g3 slow, use another window manager, but I sort of like G3 on my netbook ;) In discussing the issue I think you need to be more specific , are you talking kernel ? The 3.4 kernel should be even better. Or are you talking llvmpipe ? - Original Message - From: "Adam Pribyl" To: test@lists.fedoraproject.org Sent: Thursday, May 3, 2012 5:21:06 AM Subject: GMA500 vs. G3 software render While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), G3 software render negates all this for gnome shell as this is extremely slow on Atom. With the fallback mode the G3 is working very well on gma500. But the obvious question is, beside the questionable future of acceleration on gma500 - what is the future of the fallback? Is there still a list of devices that should use fallback "by default"? If yes, then I would nominate the gma500 for it, as this is really horrible experience, making many users scared, just after live CD/USB boot. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
kdm vs. gdm
Greetings: I was trying to add some kde packages to my gnome desktop x86_64 system, when I got this error: Transaction Check Error: file /var/spool/gdm from install of kde-settings-kdm-4.8-8.fc18.noarch conflicts with file from package gdm-1:3.4.1-1.fc18.x86_64 I have never had a problem like this before... -- Sincerely yours, Rob G. Healey -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: Korganizer: tasks disappearing
On Thu, May 3, 2012 at 3:10 PM, Rex Dieter wrote: > Pedro Francisco wrote: > >> Just an heads-up, on F17 Korganizer seems to forget tasks after exiting. > > that's a hint that you have an akonadi resource that points to a non- > existant target file/directory. > > you could try running > akonadiconsole > and in "Agents" tab, look for "Personal Calendar" resource, and see what it > points to. In general, it should point at something like: > ~/.kde/share/apps/korganizer/std.ics > > Make sure that the target folder/file exists. > It does: $ head -n2 /home/pedro/.kde/share/apps/korganizer/std.ics BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F17: gedit: drag & drop freezes forever mouse pointer on drag mode
I need to confirm a bug. Open one gedit window (MUST BE FROM GNOME-SHELL, either from ALT+F2 and 'gedit' or using the gnome-shell menus). On a command line do, for example: $ gedit ~/.bashrc _Another_ gedit window should open. To allow you to resume your work afterwards, on another console, do: $ sleep 15; killall gedit Try to drag and drop the ".bashrc" tab to the other gedit window. Watch your mouse pointer freeze on drag mode, disabling it effectively; keyboard does not seem to respond as well. After ~15 seconds, when gedit windows are killed, you'll get your mouse and keyboard back. Can anyone confirm? -- Pedro -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: OpenJDK update to J7u4 level?
* Fernando Cassia [2012-05-02 03:06]: >Hi there, >I hit a nasty bug with regards to OpenJDK 7 and GTK file requesters. >Currently the Sun Bugparade datase is having hiccups and it cannot >display bug reports (nevertheless it accepted my bug report and >assigned it a bug#). >Despite this, I think I may have found a "way too similar" bug report >on Bugparade wrt OpenJDK and GTK file requesters that -while I cannot >see its contents right now- might be exactly the bug I hit. >It apparently has been fixed as per Java 7u4 by Oracle. >My question is: what are the chances of getting OpenJDK 1.7.0 updated >to the J7u4 level?. >I did yum update java-1.7.0-openjdk* but it tells me there's nothing to >update. >This openjdk bug is a show stopper for me as it prevents one particular >Java app I use daily from working. Clicking on any file on a GTK file >requester gives me a thread null pointer exception. Our tentative plan was to move to u4 for F17 and more F16 to u5 directly in mid-june. Is there a bug open for the issue you are seeing? Deepak > >Exception in thread "Thread-7" java.lang.NullPointerException >Â Â Â at >sun.awt.X11.GtkFileDialogPeer.setFileInternal(GtkFileDialogPeer.java:79 >) >Â Â Â at sun.awt.X11.GtkFileDialogPeer.run(Native Method) >Â Â Â at >sun.awt.X11.GtkFileDialogPeer.showNativeDialog(GtkFileDialogPeer.java:1 >66) >Â Â Â at >sun.awt.X11.GtkFileDialogPeer.access$000(GtkFileDialogPeer.java:39) >Â Â Â at >sun.awt.X11.GtkFileDialogPeer$1.run(GtkFileDialogPeer.java:108) > >FC > -- > test mailing list > test@lists.fedoraproject.org > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17: Korganizer: tasks disappearing
Pedro Francisco wrote: > Just an heads-up, on F17 Korganizer seems to forget tasks after exiting. that's a hint that you have an akonadi resource that points to a non- existant target file/directory. you could try running akonadiconsole and in "Agents" tab, look for "Personal Calendar" resource, and see what it points to. In general, it should point at something like: ~/.kde/share/apps/korganizer/std.ics Make sure that the target folder/file exists. -- rex -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: reboot hangs with systemd-44-7.fc17
Joachim Backes wrote: > after updating to systemd-44-7.fc17 (and systemd-sysv-44-7.fc17), > rebooting hangs up. Pushing the reset button is needed :-( In my experience, it's delayed by ~2 minutes > I had to downgrade systemd to get rid from this bug. > No such problems with the previous version. > Anybody sees this too? Some related bugs: https://bugzilla.redhat.com/show_bug.cgi?id=816842 https://bugzilla.redhat.com/show_bug.cgi?id=739836#c61 -- rex -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On 5/3/12 7:36 AM, Adam Williamson wrote: On Thu, 2012-05-03 at 13:21 +0200, Adam Pribyl wrote: While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), When you say "latest development", what exactly are you referring to? G3 software render negates all this for gnome shell as this is extremely slow on Atom. With the fallback mode the G3 is working very well on gma500. But the obvious question is, beside the questionable future of acceleration on gma500 - what is the future of the fallback? Is there still a list of devices that should use fallback "by default"? If yes, then I would nominate the gma500 for it, as this is really horrible experience, making many users scared, just after live CD/USB boot. At least some parts of upstream Gnome really want fallback to go away. They will probably get their way eventually. You would be wise not to consider fallback mode a permanent thing. Well, the problem there is that the determining factor in how fast software rendering is is, obviously, not the graphics card - the whole point of software rendering is to *bypass* the graphics card - but the CPU. It's slightly more complicated than that, but, sure. I don't know if there's a plan to blacklist systems with sufficiently 'bad' CPU performance from using software rendering, or if ajax is of the opinion that just about anything should be able to run Shell acceptably via software rendering and if a system doesn't, there's a bug that needs fixing...ajax, is there an overview here? I don't currently have such a plan. I could, I guess. My personal opinion is that Core and up are pretty tolerable and anything less kind of isn't but also already kind of wasn't. But I no longer really have any idea whether my threshold for acceptable interactivity matches that of anyone else. Nor do I own any of the non-free Intel kit - on the grounds of not rewarding Intel's duplicity - so I have no real idea what it's like there either. So if we want to blacklist low performers, okay, that's a thing we can do I suppose. Where do we draw the line? - ajax -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17-Selinux troubles after upgrading
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/02/2012 06:44 PM, Adam Williamson wrote: > On Wed, 2012-05-02 at 16:24 -0400, Daniel J Walsh wrote: >> On 05/02/2012 04:22 PM, Adam Williamson wrote: >>> On Sat, 2012-04-28 at 20:30 +0100, Frank Murphy wrote: On 28/04/12 20:26, antonio wrote: > I upgraded from F-16 to F-17 Beta, then upgraded to find that I > couldn't delete my own files!!! after disabling Selinux and > enabling it again (i.e. relabeling) everything is o.k.Anybody > experiencing it?? No, but it's good practice to do a relabel after an update. As policies most likely have changed, even if subtly. I'm surprised a full relabel wasn't done automatically. >>> >>> Antonio doesn't really provide much detail on how exactly he upgraded. >>> I think anaconda-based upgrades do a relabel automatically, but >>> obviously upgrading via yum won't necessarily do so. >> >> We have not done a full relabel on upgrade,since it could take >> potentially a very long time. We could just drop the /.autorelabel file >> in preupgrade which would trigger the relabel. I have not heard of other >> people having SELinux labeling issues on upgrade, I wish we had the >> audit.log to see what the problem was. > > Well, I didn't say 'full relabel' =) But indeed I was vague. IIRC, anaconda > relabels some specific directories. Yes it fixes up any files/directories that are created by anaconda before SELinux policy is loaded. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+igmkACgkQrlYvE4MpobN/lgCgg3ftRS83sLTazhaRQfF5fhru 0jwAn3qcGAu8n1QE+vrI0ZyT6Pez3CMi =xlf7 -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F17-Selinux troubles after upgrading
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/2012 05:08 PM, antonio montagnani wrote:
> Il 02/05/2012 22:54, Daniel J Walsh ha scritto: On 05/02/2012 04:35 PM,
> antonio montagnani wrote:
Il 02/05/2012 22:24, Daniel J Walsh ha scritto: On 05/02/2012 04:22
PM, Adam Williamson wrote:
>>> On Sat, 2012-04-28 at 20:30 +0100, Frank Murphy wrote:
On 28/04/12 20:26, antonio wrote:
> I upgraded from F-16 to F-17 Beta, then upgraded to find
> that I couldn't delete my own files!!! after disabling
> Selinux and enabling it again (i.e. relabeling) everything
> is o.k.Anybody experiencing it??
No, but it's good practice to do a relabel after an update.
As policies most likely have changed, even if subtly.
I'm surprised a full relabel wasn't done automatically.
>>>
>>> Antonio doesn't really provide much detail on how exactly he
>>> upgraded. I think anaconda-based upgrades do a relabel
>>> automatically, but obviously upgrading via yum won't
>>> necessarily do so.
We have not done a full relabel on upgrade,since it could take
potentially a very long time. We could just drop the /.autorelabel
file in preupgrade which would trigger the relabel. I have not heard
of other people having SELinux labeling issues on upgrade, I wish we
had the audit.log to see what the problem was. Dan,
where do I find the audit.log file???
Tnx
>
> /var/log/audit/audit.log
>
> ausearch -m avc
>
> Will extract the parts I care about
>
>> ausearch -m avc time->Sat Apr 14 18:01:38 2012 type=SYSCALL
>> msg=audit(1334419298.900:159): arch=4003 syscall=11 success=yes
>> exit=0 a0=8aee390 a1=8aee400 a2=8aed980 a3=8aed980 items=0 ppid=20996
>> pid=20997 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51
>> fsgid=51 tty=pts0 ses=2 comm="newaliases"
>> exe="/usr/sbin/sendmail.sendmail"
>> subj=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
>> type=AVC msg=audit(1334419298.900:159): avc: denied { read } for
>> pid=20997 comm="newaliases" path="/home/antonio" dev=dm-2 ino=1048577
>> scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir type=AVC
>> msg=audit(1334419298.900:159): avc: denied { read } for pid=20997
>> comm="newaliases" path="/home/antonio" dev=dm-2 ino=1048577
>> scontext=unconfined_u:system_r:system_mail_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir
>> time->Thu Apr 19 18:35:45 2012 type=SYSCALL msg=audit(1334853345.590:66):
>> arch=4003 syscall=5 success=no exit=-13 a0=81159d0 a1=8000 a2=0 a3=0
>> items=0 ppid=1 pid=1845 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="NetworkManager"
>> exe="/usr/sbin/NetworkManager" subj=system_u:system_r:NetworkManager_t:s0
>> key=(null) type=AVC msg=audit(1334853345.590:66): avc: denied { read }
>> for pid=1845 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Thu
>> Apr 19 18:39:05 2012 type=AVC msg=audit(1334853545.115:41): avc: denied
>> { read } for pid=892 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Thu
>> Apr 19 21:40:30 2012 type=AVC msg=audit(1334864430.369:41): avc: denied
>> { read } for pid=902 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Fri
>> Apr 20 07:02:19 2012 type=AVC msg=audit(1334898139.025:41): avc: denied
>> { read } for pid=921 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Fri
>> Apr 20 18:11:40 2012 type=AVC msg=audit(1334938300.294:43): avc: denied
>> { read } for pid=886 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Fri
>> Apr 20 22:49:42 2012 type=AVC msg=audit(1334954982.484:40): avc: denied
>> { read } for pid=928 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file time->Sat
>> Apr 21 07:31:25 2012 type=AVC msg=audit(1334986285.449:40): avc: denied
>> { read } for pid=880 comm="NetworkManager" name="sysctl.conf" dev="dm-1"
>> ino=525148 scontext=system_u:system_r:NetworkManager_t:s0
>> tcontext=system_u:object_r:system_conf_t:s0 tclass=file tim
Re: GIMP 2.8
On Thu, 03 May 2012 07:49:28 -0400 Jonathan Kamens wrote: > The developer in question is perfectly happy with the idea that by > remaining true to its "vision," GIMP is going to drive away many users. Just another example of the Vogon Effect... http://home.comcast.net/~tomhorsley/game/rules-change.html -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GIMP 2.8
So, I took my concerns over to the gimp-user mailing list, where apparently this issue has been argued over a number of times. According to the developer who designed and implemented this change, GIMP has a "vision" for what it wants to be and a "target audience" of intended users, and people like me who find the new interface to be awful "are probably not a targeted GIMP user." The purpose of the new change was explained during the thread. Several alternative methods of accomplishing the same purpose without breaking any existing use cases were described. To every one of them, the developer responded that those methods either weren't in accord with the "vision" of the application or would interfere with unspecified functionality to be implemented later. The developer in question is perfectly happy with the idea that by remaining true to its "vision," GIMP is going to drive away many users. As for alternatives, krita (the RPM is "calligra-krita") and pinta, both of which are available in Fedora, were suggested for people who just aren't professional enough to grok the One True GIMP Way. jik -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GMA500 vs. G3 software render
On Thu, 2012-05-03 at 13:21 +0200, Adam Pribyl wrote: > While I consider the latest development on gma500, present in many Atom > base netbooks, a great success and would like to say thank you to > developer(s), G3 software render negates all this for gnome shell as this > is extremely slow on Atom. With the fallback mode the G3 is working very > well on gma500. But the obvious question is, beside the questionable > future of acceleration on gma500 - what is the future of the fallback? Is > there still a list of devices that should use fallback "by default"? If > yes, then I would nominate the gma500 for it, as this is really horrible > experience, making many users scared, just after live CD/USB boot. Well, the problem there is that the determining factor in how fast software rendering is is, obviously, not the graphics card - the whole point of software rendering is to *bypass* the graphics card - but the CPU. We can't blacklist systems from using software rendering on the basis that their graphics cards are slow, that's kind of missing the point. I don't know if there's a plan to blacklist systems with sufficiently 'bad' CPU performance from using software rendering, or if ajax is of the opinion that just about anything should be able to run Shell acceptably via software rendering and if a system doesn't, there's a bug that needs fixing...ajax, is there an overview here? -- 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: systemd-44-8.fc17 together with most recent F17 updates lets the reboot problem grow (BZ 816842)
On Thu, 2012-05-03 at 08:07 +0200, Joachim Backes wrote: > After having installed systemd-44-8.fc17 *and* applying the most recent > F17 updates (includes a *glibc* update) , the reboot problem has > deteriorated: > > 1) Even going from runlevel 5 into runlevel 3 and then rebooting (was > previously a workaround) no more helps. > > 2) Booting directly into to runlevel 3 and the trying to reboot now > shows the delay too! Why not just post this in the bug? We have bug reports to discuss known and under-active-development bugs. I can't see why it helps anyone to split discussion between the bug report and the mailing list. -- 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: RAID install proposed blocker
On Wed, 2012-05-02 at 22:21 -0700, Samuel Sieb wrote: > Adam Williamson wrote: > > /boot on RAID was, for a long time, considered a problematic > > configuration and is explicitly excepted from the release criteria. I > > believe the anaconda team's attitude towards this configuration is > > becoming somewhat more liberal, though, so we may have to re-consider > > the criterion. > > That part of the criterion was pointed out, so I tried the install again with > /boot being non-raid and it still had the same problem. I managed to do a > workaround, so it's now running the way I originally wanted it (/ on raid). > > Anaconda lets you make that configuration, the bootloader supports it, and it > works (other than that one bug), so it seems that that part of the criterion > may > be outdated now. The above three things have often been true in the past, but whenever anyone hit problems and filed a bug, the anaconda devs would usually say 'well, we don't really support /boot on RAID'. The criterion exception was added at their request, even though all the things you mention were true at that time. -- 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
GMA500 vs. G3 software render
While I consider the latest development on gma500, present in many Atom base netbooks, a great success and would like to say thank you to developer(s), G3 software render negates all this for gnome shell as this is extremely slow on Atom. With the fallback mode the G3 is working very well on gma500. But the obvious question is, beside the questionable future of acceleration on gma500 - what is the future of the fallback? Is there still a list of devices that should use fallback "by default"? If yes, then I would nominate the gma500 for it, as this is really horrible experience, making many users scared, just after live CD/USB boot. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Testing of f17 TC2 in USB
On Wed, 2012-05-02 at 21:30 -0500, Michael Cronenworth wrote: > On 05/02/2012 06:57 PM, Michael Cronenworth wrote: > > The image boots and installation (with *defaults*) begins. It gets to > > 160 packages of 1212 and errors on perl. > > > > "A unpack error occurred when installing the perl package..." > > I burned the image to a real DVD and installation succeeded. > > My guess is that my USB stick is bad. That would be my guess too. Do you have another you can test with? -- 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: GIMP 2.8
On Thu, 2012-05-03 at 12:31 +0200, Karel Volný wrote: > Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a): > > GIMP is a professional image editing suite, just like > > Photoshop. It's not a basic touch-up tool. It doesn't really > > make sense to criticise it on the basis that you want to use > > it for something it's not really designed to do. > > and which tool are we supposed to use? Even if the answer were 'there isn't one', that's not GIMP's fault. The GIMP authors want to write a professional photo editor. If no-one wants to write a simple touch-up tool, that's hardly the GIMP authors' fault, is it? > so far, Shotwell and Digikam were proposed > > but these aren't "basic touch-up tools" either: > Shotwell - A photo organizer for the GNOME desktop > digiKam - A digital camera accessing & photo management > application And we all know summary lines are always kept carefully up to date and fully accurate and contain a complete description of all the app's functionality in their 80 characters or less! (email really needs a :rolleyes: emoticon). It's really not difficult to actually _run_ either app and have a look at what it can do. Shotwell has some pretty basic editing tools - more 'enhancement' than editing - but Digikam has some pretty advanced functionality these days. See http://docs.kde.org/development/en/extragear-graphics/digikam/image-editor.html , for a quick indication of what it can do. -- 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
F-17 Branched report: 20120503 changes
Compose started at Thu May 3 08:15:05 UTC 2012 Broken deps for x86_64 -- [LuxRender] LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61 [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [eclipse-linuxprofilingframework] eclipse-linuxprofilingframework-0.10.0-4.fc17.x86_64 requires eclipse-birt-chart [eclipse-systemtapgui] eclipse-systemtapgui-1.2-2.fc17.noarch requires eclipse-birt-chart [egoboo] egoboo-2.7.5-11.fc17.x86_64 requires libenet-1.2.1.so()(64bit) [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 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0 [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) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-2.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-2.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [meshlab] meshlab-1.3.1-2.fc17.x86_64 requires libmuparser.so.0()(64bit) [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0 [openvrml] libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_filesystem-
Re: GIMP 2.8
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a): > GIMP is a professional image editing suite, just like > Photoshop. It's not a basic touch-up tool. It doesn't really > make sense to criticise it on the basis that you want to use > it for something it's not really designed to do. and which tool are we supposed to use? so far, Shotwell and Digikam were proposed but these aren't "basic touch-up tools" either: Shotwell - A photo organizer for the GNOME desktop digiKam - A digital camera accessing & photo management application K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp ka...@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity." 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: Testing Needed for F17 Final Blockers
On Tue, 1 May 2012, Tim Flink wrote: I just went through the sizable list of F17 final blockers and found a bunch of things that need to be tested. If you have some spare cycles and/or are looking for stuff to test - please take a look at the bugs and suggested tests below. Thanks, Tim https://bugzilla.redhat.com/show_bug.cgi?id=740280 - test liveusb w/ persistent overlay - if the persistant overlay works, this can probably be closed If making an live USB with liveusb-creator with overlay then booting the LiveUSB making a file, then rebooting and checking the file is present is the desired test, that it works with TC2. Adam Pribyl -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: dependency problems: samba4-client-4.0.0-45alpha18.fc17.i686 from updates-testing
On Wed, 2 May 2012 18:38:21 -0700 (PDT), AO (Antonio) wrote: > Dear folks, > > for a good while now, I have kept getting the following every time I yum > update : > If you run updates-testing, you may need to run "yum distro-sync" from time to time. The reason for that is simple. Test Updates are withdrawn because they are broken. They are not available in the repos anymore, but it could be that you've installed them or updated to them already. Often, broken test updates are replaced with a newer release, which would replace your installed packages. However, some test updates are not replaced, at least not too soon. And even if a newer test update replaces an earlier broken one, it could be that it doesn't even try to fix temporary packaging issues. > Resolving Dependencies > --> Running transaction check > ---> Package samba4-client.i686 1:4.0.0-41alpha18.fc17 will be updated > ---> Package samba4-client.i686 1:4.0.0-45alpha18.fc17 will be an update > ---> Package samba4-common.i686 1:4.0.0-41alpha18.fc17 will be updated > --> Processing Dependency: samba4-common = 1:4.0.0-41alpha18.fc17 for > package: 1:libsmbclient-4.0.0-41alpha18.fc17.i686 > The -41alpha18.fc17 release has been trouble-some. It could not be installed here with an ordinary F-17 Beta installation "yum update". > I don't see in the reports that the package(s) are broken, is the > updates-testing repo here conflicting with official pre 17 release repo? > The existing broken deps reports only search for dependency problems in the current repository contents. Typically, that is unable to catch all kinds of upgrade issues as older package releases are not in the repos anymore. > Any thoughts of what I should do to resolve this? Try "yum distro-sync". -- Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64 loadavg: 2.02 1.24 0.54 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird Firefox performance issue
On 3.5.2012 00:31, Jonathan Kamens wrote: Frequent hangs for anywhere from a second to 30 seconds. Lack of responsiveness to key and button presses. Delays from when I clicked a scroll bar and dragged it to when the window actually scrolled. Frequent long delays from when an external app tried to launch a page to when the tab actually opened. Is there anything interesting about your setup (e.g., $HOME on NFS, NTFS, or some other kind of non-obvious configuration)? Matěj -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
