Re: Fedora-Live-LXDE-i686-19-TC5-1.iso 18-Jun-2013 01:55 658M
On Tue, 2013-06-18 at 04:14 -0400, Joerg Lechner wrote: Hi, is it possible. that there is an error in Fedora-Live-LXDE-i686-19-TC5-1.iso 18-Jun-2013 01:55 658M ? I have downloaded this build twice. The first time tried to burn with Brasero twice, second time to burn once. Always the checksum test stopped to continue after having completed about 60%. My error? Build error? Did you check the sha256sum? I've tested the x86_64 LXDE live and it booted and installed fine in a VM for me, but not the i686 yet. -- 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
screengrabber istanbul in F19
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 -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.6-301.fc19.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
rawhide report: 20130618 changes
Compose started at Tue Jun 18 08:15:03 UTC 2013 Broken deps for x86_64 -- [PyQwt] PyQwt-5.2.0-20.fc19.2.i686 requires sip-api(9) = 0:9.1 PyQwt-5.2.0-20.fc19.2.x86_64 requires sip-api(9) = 0:9.1 [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-23.fc20.i686 requires ruby(abi) = 0:1.9.1 eruby-libs-1.0.5-23.fc20.x86_64 requires ruby(abi) = 0:1.9.1 [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 [qgis] qgis-python-1.8.0-13.fc19.i686 requires sip-api(9) = 0:9.1 qgis-python-1.8.0-13.fc19.x86_64 requires sip-api(9) = 0:9.1 [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) [rubygem-qpid_messaging] rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidtypes.so.1()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidmessaging.so.3()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.x86_64 requires libqpidcommon.so.5()(64bit) rubygem-qpid_messaging-0.20.2-1.fc19.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
Re: screengrabber istanbul in F19
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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: screengrabber istanbul in F19
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 -- Fedora release 19 (Schrödinger’s Cat): Kernel-3.9.6-301.fc19.x86_64 Joachim Backes joachim.bac...@rhrk.uni-kl.de https://www-user.rhrk.uni-kl.de/~backes -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-19 Branched report: 20130618 changes
Compose started at Tue Jun 18 09:15:03 UTC 2013 Compose finished at Tue Jun 18 12:49:06 UTC 2013 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
On Mon, 2013-06-17 at 19:23 -0600, Chris Murphy wrote: While anaconda is running an installation, gnome-shell is hogging a whole core on its own, and X is using about 25% of the other core. Is this expected? This is on baremetal, with a nouveau supported GPU: NVIDIA Corporation G84M [GeForce 8600M GT] [10de:0407]. I wouldn't expect gnome-shell to need to fall back to a rendering method that'd be this CPU intensive. I assume you mean the live installer by this, as the normal anaconda doesn't run gnome-shell at all. A compositor has some of the same properties as the X server itself: it _has_ to respond when an app draws something, otherwise the bits don't show up on the screen. So it's possible that what you're seeing there is anaconda updating the screen often (more than 60fps, at least), and X and the shell struggling to keep up. But this is what profilers are for. - ajax -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
While anaconda is running an installation, gnome-shell is hogging a whole core on its own, and X is using about 25% of the other core. Is this expected? This is on baremetal, with a nouveau supported GPU: NVIDIA Corporation G84M [GeForce 8600M GT] [10de:0407]. I wouldn't expect gnome-shell to need to fall back to a rendering method that'd be this CPU intensive. If I try to do this in KVM (2x CPU), I see gnome-shell taking 5%, X not even displayed in top, and all CPU power going to rsync (2x 10%) and loop3 (80%). I guess the high X+gnome-shell usage is caused by the nouveau driver. -- 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/18/2013 06:25 AM, Adam Jackson wrote: On Mon, 2013-06-17 at 19:23 -0600, Chris Murphy wrote: While anaconda is running an installation, gnome-shell is hogging a whole core on its own, and X is using about 25% of the other core. Is this expected? This is on baremetal, with a nouveau supported GPU: NVIDIA Corporation G84M [GeForce 8600M GT] [10de:0407]. I wouldn't expect gnome-shell to need to fall back to a rendering method that'd be this CPU intensive. I assume you mean the live installer by this, as the normal anaconda doesn't run gnome-shell at all. A compositor has some of the same properties as the X server itself: it _has_ to respond when an app draws something, otherwise the bits don't show up on the screen. So it's possible that what you're seeing there is anaconda updating the screen often (more than 60fps, at least), and X and the shell struggling to keep up. But this is what profilers are for. - ajax I did a pxeboot install of today's rsync using the anaconda from TC5. I ran top(1) during the install and did not notice any unusual CPU utilization. This is on a 32 GB 3770K. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
If I try to do this in KVM (2x CPU), I see gnome-shell taking 5%, X not even displayed in top, and all CPU power going to rsync (2x 10%) and loop3 (80%). Please tell us how much virtual RAM was allocated to the KVM instance. loop3 at 80% CPU for long periods is page thrashing: re-decompressing parts of the .exe over and over because the resulting pages are discarded too quickly. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell cpu usage during installation
I did a pxeboot install of today's rsync using the anaconda from TC5. I ran top(1) during the install and did not notice any unusual CPU utilization. This is on a 32 GB 3770K. Which video graphics card, and which driver? -- 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 7:25 AM, Adam Jackson a...@redhat.com wrote: On Mon, 2013-06-17 at 19:23 -0600, Chris Murphy wrote: While anaconda is running an installation, gnome-shell is hogging a whole core on its own, and X is using about 25% of the other core. Is this expected? This is on baremetal, with a nouveau supported GPU: NVIDIA Corporation G84M [GeForce 8600M GT] [10de:0407]. I wouldn't expect gnome-shell to need to fall back to a rendering method that'd be this CPU intensive. I assume you mean the live installer by this, Yes this is occurring with Fedora-Live-Desktop-x86_64-19-TC3-1.iso So it's possible that what you're seeing there is anaconda updating the screen often (more than 60fps, at least), and X and the shell struggling to keep up. 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. But this is what profilers are for. OK? 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 18, 2013, at 12:22 PM, John Reiser jrei...@bitwagon.com wrote: If I try to do this in KVM (2x CPU), I see gnome-shell taking 5%, X not even displayed in top, and all CPU power going to rsync (2x 10%) and loop3 (80%). Please tell us how much virtual RAM was allocated to the KVM instance. loop3 at 80% CPU for long periods is page thrashing: re-decompressing parts of the .exe over and over because the resulting pages are discarded too quickly. I have the same issue with loop3 on baremetal, it's variable between 45-80% CPU. 4GB RAM on that computer. 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/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. But this is what profilers are for. OK? You are free to profile gnome-shell and see exactly why so much CPU is used to move a window around. Maybe you could provide a patch to Gnome to reduce it. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
failure to remove old efi boot entry
https://bugzilla.redhat.com/show_bug.cgi?id=975537 I'm not understanding what's happening in this bug. Comment 15 is the result of efibootmgr while booted from a USB stick made via dd of Fedora-Live-Desktop-x86_64-19-TC5-1.iso. The Boot entry is valid, that's a successful, working Fedora 19 installation with /boot on partition 4. But it's not clear to me why anaconda reports: 15:31:42,471 INFO program: Running... efibootmgr -b -B 15:31:42,516 DEBUG program: Return code: 1 When I do it manually *before* anaconda has a chance to, it works. But for some reason the same command issued by anaconda (when the entry exists), returns a code of 1. Weird. 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 Tue, 2013-06-18 at 15:02 -0500, John Morris wrote: On Sat, 2013-06-15 at 12:12 -0700, Adam Williamson wrote: No, that's not the point at all. The point is that there is only so much space for text in the UI. Have you tried running anaconda in Japanese or German at 800x600? When there's too much text on a spoke (those are both languages which use a lot of characters to say the same thing compared to English), the display of the spoke becomes entirely corrupted. 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. Or am I just being a Negative Nancy? I don't think so. Specifying UI in pixels is an outdated 20th Century concept that was justified in a day of 16bit computers with pitiful resources and bitmapped fonts. We have surrendered to the notion of wasting cycles on darned near everything else, why not blow some on something actually useful? Yet Anaconda has went through more than one major rework/rewrite/retool since the turn of the Century and the entry into the era of computing 'plenty' and is still bound to an 800x600 SVGA display that hasn't even been seen on the surplus market in a decade. Ok, it does help install on a netbook, but it really is time to make it variable and give every install screen a vertical scrollbar to eliminate the possibility of dialogs that won't fit. 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! anaconda's a complex application operating under a lot of different constraints: work at low resolutions (people ALWAYS bitch and moan when it doesn't, all those millions of Eee 701s that were sold are still out there somewhere and apparently all their owners want to run Fedora), provide as much information as possible to the user, look good, keep the code simple so it can be maintained, provide lots of complex functionality. 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. -- 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 18, 2013, at 1:38 PM, Michael Cronenworth m...@cchtml.com 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. On the older hardware with NVIDIA card, OS X's compositor doesn't have this issue with the NVIDIA produced native driver. During gnome 3's life, testing on this hardware, I intermittantly get messages of Gnome starting in fall back mode, even though it shouldn't have to do that on this hardware. So I wonder if effectively I'm getting whatever the new fallback mode CPU based compositor is. But this is what profilers are for. OK? You are free to profile gnome-shell and see exactly why so much CPU is used to move a window around. Maybe you could provide a patch to Gnome to reduce it. Maybe when I have the interest level and spare time to gain the prerequisite of knowing how to write code, and then specifically for gnome, yes maybe I can provide a patch … by which time I won't care much at all about the hardware in question. Chris Murphy -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F-19 Branched report: 20130618 changes
Compose started at Tue Jun 18 17:12:36 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
Re: consider people with poor vision
On 2013-06-18 13:51 (GMT-0700) Adam Williamson composed: On Tue, 2013-06-18 at 15:02 -0500, John Morris wrote: though because well because. 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! The urgency is because it's inanely long overdue. Whenever it was that F17 was forked from Rawhide it had long been known current device densities were wider in range, averaging higher than the past, and accelerating upward further. The reason they aren't already averaging higher than they are is lack of software capability holding back their utility, causing manufacturer caution to hold back tooling investment unlikely to be recouped through sales. I'm not saying make text bigger unconditionally. I'm saying text needs to be sized in a reasonable (aka fully rational) relationship to both device density and user characteristics, not stuffing gray 9px or 10px text down the throats of all regardless of their hardware or visual acuity. I'm also saying that those who need text bigger than average need an accessible way to have it. Everyone not legally blind ought to be able to use a normally equipped generic PC if he wants or needs to. The stumbling blocks to a state that it were so are a shameful paradox, considering the power of computers and related technology. The way it is now is like it was for coloreds before Martin Luther King's legacy, unable to go places and do things because of the misfortune of being born with the wrong skin color, only now it's the misfortune of eyesight not as good as naive and/or inconsiderate software creators. The only solace for today's visually challenged is that today's young software creators lucky enough to reach old age and accumulate the wisdom that should accompany it will in fact survive to old age, where likely good eyesight will exist only in what's left of their cranial memories. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: consider people with poor vision
On Tue, 2013-06-18 at 18:26 -0400, Felix Miata wrote: I'm not saying make text bigger unconditionally. I'm saying text needs to be sized in a reasonable (aka fully rational) relationship to both device density and user characteristics, not stuffing gray 9px or 10px text down the throats of all regardless of their hardware or visual acuity. And the other point I'm making is that that's a) not anaconda's problem to solve and b) not an easy problem for *anyone* to solve. You can't just assume the DPI given for a display is correct or appropriate; the situation is far more complex. That's what all those links I pasted in your bug report are about. 'Let's size everything physically!' seems like a neat idea when you first read about it, but it never works out quite that well in practice. The only solace for today's visually challenged is that today's young software creators lucky enough to reach old age and accumulate the wisdom that should accompany it will in fact survive to old age, where likely good eyesight will exist only in what's left of their cranial memories. The anaconda team is hardly a bunch of 20-somethings... -- 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 2013-06-18 16:26 (GMT-0700) Adam Williamson composed: You can't just assume the DPI given for a display is correct or appropriate; the situation is far more complex. I agree unconditionally. 'Let's size everything physically!' seems like a neat idea when you first read about it, but it never works out quite that well in practice. It is most certainly not a neat idea. It can work well only in limited circumstances. Even if controlling physical size was more workable conceptually, simply the idea of control begets the bigger problem of choosing size. A11Y means the people doing the reading should be the only ones with real control over physical size. The anaconda team is hardly a bunch of 20-somethings... 70-somethings non-zero? 60? 50? Are more than a pittance over 40? Any with visual acuity below 33rd percentile? Do more than zero primarily use a desktop display that is smaller than average? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fedora 19 Final status, testing/karma requests and needed fixes
It feels like time for a status summary mail again! Fedora 19 Final TC5 is the current compose: it contains most of the final churn for F19, change should be fairly restricted from here on out. So this is a good time to take stock of where we are and get all testing done. tl;dr summary - Desktop team: please look at reducing size of desktop live (958426) Installer team: please fix 924162 Selinux team: please roll a new selinux-policy ASAP (964006) Releng team: when a new selinux-policy is available, roll some new cloud test images (964006) Karma required for: https://admin.fedoraproject.org/updates/gnome-initial-setup-0.12-1.fc19 https://admin.fedoraproject.org/updates/gnome-packagekit-3.8.2-2.fc19 https://admin.fedoraproject.org/updates/livecd-tools-19.5-1.fc19 https://admin.fedoraproject.org/updates/python-meh-0.25-1.fc19 https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19 Blocker status -- https://qa.fedoraproject.org/blockerbugs/milestone/19/final/buglist is the current list of proposed and accepted blockers and freeze exception bugs. There are a half dozen proposed blockers that we will be voting on at tomorrow's blocker review meeting. Please do come out to the blocker review meeting and provide your input if you possibly can, especially if you're a reporter of a proposed blocker or a maintainer of an affected component. 975159 anacondaMODIFIEDUnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 0: ordinal not in range(128) 975537 anacondaASSIGNEDBootLoaderError: failed to remove old efi boot entry 974711 fedora-logosNEW Drop HAL and beefy install 'ad banners' for F19 final(?) 975204 mesaMODIFIEDradeon card lost opengl 3.1 support 974691 rsyslog NEW Since cleaning up from #974132, nothing gets written to /var/log/messages 679486 xorg-x11-xauth ASSIGNEDLiveinst doesn't start if hostname changes Here's the status of the accepted blockers: 964586 - Anaconda does not isntall ntfs tools to allow OS-Prober to find windows partition and therefore creates no grub.cfg entry - this ought to be fixed in Final TC5 and just needs to be tested. The test is to do a (BIOS) minimal install of Fedora 19 alongside a (BIOS) install of Windows and check that a grub entry for the Windows install is created. 971191 - DVD install option unavailable in TUI - a fix for this narrowly missed TC5, and will be in the next build. We could test it with an updates.img in the mean time. 971763 - disable updates-testing - this is mostly a 'reminder' bug to put a 'final' version of fedora-release into RC1. No action needed yet. 968951 - g-i-s created user's accounts and settings are copied to new users created after g-i-s completes but before a reboot - the fix for this is in Final TC5, I have verified it appears to work. Further verification would be welcome, and the update that fixes it - https://admin.fedoraproject.org/updates/gnome-initial-setup-0.12-1.fc19 - needs karma. 969852 - Software Update fails to update - two people have verified the fix for this. The update that fixes it - https://admin.fedoraproject.org/updates/gnome-packagekit-3.8.2-2.fc19 - needs karma. 958426 - 19 Final TC1 x86_64 Desktop Live is oversized (larger than 1 GB) - we need the desktop team to look at fixing this. At this point, as noted above, repo and spin-kickstarts churn should be mostly done, so now's the time to take a look at what's in the TC5 image and start cutting. 974784 - live image composing in koji broken - the fix for this, https://admin.fedoraproject.org/updates/livecd-tools-19.5-1.fc19 , is clearly good, or else we wouldn't have TC5 lives. The update has sufficient karma to go stable, so no action needed here. 974032 - bug reporting doesn't work from LiveCD - the update that fixes this just barely missed TC5. It may be possible to test it by booting the TC5 live and doing 'yum update python-meh' before installing, otherwise it may have to wait for TC6. The update that should fix it, https://admin.fedoraproject.org/updates/python-meh-0.25-1.fc19 , needs karma. 964006 - cloud-init hostname service failing on initial boot - we have initial indication that the planned fix for this works, but we need a new selinux-policy to be built and new cloud images built with that selinux-policy to confirm. 974198 - missing letters on various anaconda screens with spice graphics - the fix for this has been reported to work by one tester, but it'd be good if other testers could confirm it. The update that fixes it - https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19 - needs karma. 924162 - A software selection with dependency errors is allowed to proceed if the dependency check runs twice - we are waiting on a fix for this one. Looks like progress is being made in that direction,
Final Test Compose - Error
Just tried installing from DVD selecting KDE Desktop + other components and custom disk partitions and allowing download of updates. I hit https://bugzilla.redhat.com/show_bug.cgi?id=975348 even though the bugzilla specifies netinstall. -- The only thing worse than a poorly asked question is a cryptic answer. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Final Test Compose - Error
On Wed, 2013-06-19 at 09:47 +0800, Ed Greshko wrote: Just tried installing from DVD selecting KDE Desktop + other components and custom disk partitions and allowing download of updates. I hit https://bugzilla.redhat.com/show_bug.cgi?id=975348 even though the bugzilla specifies netinstall. Well, you 'allowed downloading of updates', so...yeah. The problem is in the mariadb package somehow. -- 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: Final Test Compose - Error
On 06/19/13 10:00, Adam Williamson wrote: On Wed, 2013-06-19 at 09:47 +0800, Ed Greshko wrote: Just tried installing from DVD selecting KDE Desktop + other components and custom disk partitions and allowing download of updates. I hit https://bugzilla.redhat.com/show_bug.cgi?id=975348 even though the bugzilla specifies netinstall. Well, you 'allowed downloading of updates', so...yeah. The problem is in the mariadb package somehow. Duh(lack of coffee will be my excuse) FWIW, I couldn't get VBox to drop into a terminal session to examine the logs. -- The only thing worse than a poorly asked question is a cryptic answer. -- 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: Age URL 348 https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17 160 https://admin.fedoraproject.org/updates/FEDORA-2013-0455/fedora-business-cards-1-0.1.beta1.fc17 88 https://admin.fedoraproject.org/updates/FEDORA-2013-4234/stunnel-4.55-1.fc17 83 https://admin.fedoraproject.org/updates/FEDORA-2013-4501/libxslt-1.1.28-1.fc17 80 https://admin.fedoraproject.org/updates/FEDORA-2013-4581/libuser-0.57.6-2.fc17 13 https://admin.fedoraproject.org/updates/FEDORA-2013-10128/ssmtp-2.61-20.fc17 13 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 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10830/fail2ban-0.8.10-1.fc17 5 https://admin.fedoraproject.org/updates/FEDORA-2013-9123/kernel-3.9.5-101.fc17 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10929/xen-4.1.5-6.fc17 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10940/tomcat6-6.0.37-1.fc17 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10980/clamav-0.97.8-2.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 300 https://admin.fedoraproject.org/updates/FEDORA-2012-12509/PackageKit-0.7.6-1.fc17 108 https://admin.fedoraproject.org/updates/FEDORA-2013-3304/libvpx-1.2.0-1.fc17 13 https://admin.fedoraproject.org/updates/FEDORA-2013-10172/gnome-bluetooth-3.4.2-2.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 anthy-9100h-23.fc17 augeas-1.0.0-4.fc17 cvs-1.11.23-27.fc17 ddate-0.2.1-1.fc17 drupal6-backup_migrate-2.7-1.fc17 drupal7-7.22-6.fc17 haproxy-1.4.24-1.fc17 ibus-typing-booster-1.0.3-1.fc17 kde-workspace-4.10.4-5.fc17 libmetalink-0.1.2-3.fc17 printrun-0.0-26.20130604git80e313d.fc17 proftpd-1.3.4d-2.fc17 python-itsdangerous-0.21-3.fc17 rubygem-qpid_messaging-0.22.0-1.fc17 sugar-labyrinth-15-1.fc17 sugar-maze-24-1.fc17 wireshark-1.6.16-2.fc17 Details about builds: anthy-9100h-23.fc17 (FEDORA-2013-11214) Japanese character set input library Update Information: Fix a segfault issue ChangeLog: * Mon Jun 17 2013 Akira TAGOH ta...@redhat.com - 9100h-23 - Fix a segfault issue. (#973127) * Wed Mar 27 2013 Akira TAGOH ta...@redhat.com - 9100h-22 - Rebuilt for aarch64 support (#925002) * Fri Mar 8 2013 Akira TAGOH ta...@redhat.com - 9100h-21 - Apply a patch from Mike FABIAN to get anthy.el working back on Emacs 24.3.1. * Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 9100h-20 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Tue Aug 14 2012 Akira TAGOH ta...@redhat.com - 9100h-19 - Update License tag. * Wed Jul 18 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 9100h-18 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild References: [ 1 ] Bug #973127 - [abrt] ibus-anthy-1.5.3-1.fc18: anthy_xstrcmp: Process /usr/bin/python2.7 was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=973127 augeas-1.0.0-4.fc17 (FEDORA-2013-11222) A library for changing configuration files Update Information: Fix parsing of /etc/sysconfig/network. ChangeLog: * Tue Jun 18 2013 Richard W.M. Jones rjo...@redhat.com - 1.0.0-4 - Fix /etc/sysconfig/network (RHBZ#904222). * Wed Jun 5 2013 Richard W.M. Jones rjo...@redhat.com - 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 cvs-1.11.23-27.fc17 (FEDORA-2013-11213) Concurrent Versions System Update Information:
Fedora 18 updates-testing report
The following Fedora 18 Security updates need testing: Age URL 161 https://admin.fedoraproject.org/updates/FEDORA-2013-0416/fedora-business-cards-1-0.1.beta1.fc18 95 https://admin.fedoraproject.org/updates/FEDORA-2013-3935/puppet-3.1.1-1.fc18 88 https://admin.fedoraproject.org/updates/FEDORA-2013-4243/stunnel-4.55-1.fc18 75 https://admin.fedoraproject.org/updates/FEDORA-2013-4823/microcode_ctl-2.0-3.fc18 60 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 14 https://admin.fedoraproject.org/updates/FEDORA-2013-9962/subversion-1.7.10-1.fc18 10 https://admin.fedoraproject.org/updates/FEDORA-2013-10440/owncloud-4.5.12-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10713/openstack-keystone-2012.2.4-4.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10806/fail2ban-0.8.10-1.fc18 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10724/qemu-1.2.2-12.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10953/clamav-0.97.8-2.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10941/xen-4.2.2-7.fc18 2 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 129 https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18 13 https://admin.fedoraproject.org/updates/FEDORA-2013-6209/ibus-1.5.2-4.fc18 11 https://admin.fedoraproject.org/updates/FEDORA-2013-10318/system-config-keyboard-1.3.1-14.fc18 10 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 5 https://admin.fedoraproject.org/updates/FEDORA-2013-10832/cups-1.5.4-28.fc18 2 https://admin.fedoraproject.org/updates/FEDORA-2013-10939/dosfstools-3.0.20-2.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11198/dbus-1.6.12-1.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11221/kernel-3.9.6-200.fc18 0 https://admin.fedoraproject.org/updates/FEDORA-2013-11248/kde-workspace-4.10.4-5.fc18 The following builds have been pushed to Fedora 18 updates-testing adevs-2.6-4.fc18 amanda-3.3.2-4.fc18 anthy-9100h-23.fc18 augeas-1.0.0-4.fc18 cas-client-3.2.1-2.fc18 cvs-1.11.23-30.fc18 dbus-1.6.12-1.fc18 ddate-0.2.1-1.fc18 dh-make-0.61-1.fc18 drupal6-backup_migrate-2.7-1.fc18 drupal7-7.22-6.fc18 eruby-1.0.5-23.fc18 haproxy-1.4.24-1.fc18 ibus-typing-booster-1.0.3-1.fc18 kde-plasma-applicationname-1.7g18437d0-2.fc18 kde-workspace-4.10.4-5.fc18 kernel-3.9.6-200.fc18 kryo-2.21-1.fc18 lhapdf-5.8.9-4.fc18 libmetalink-0.1.2-3.fc18 lifeograph-0.11.1-2.fc18 mate-themes-1.6.1-2.fc18 nodejs-collections-0.1.20-2.fc18 nodejs-console-dot-log-0.1.3-2.fc18 nodejs-dep-graph-1.1.0-2.fc18 nodejs-i-0.3.1-1.fc18 nodejs-isodate-0.1.4-2.fc18 nodejs-mimeparse-0.1.4-1.fc18 printrun-0.0-26.20130604git80e313d.fc18 proftpd-1.3.4d-2.fc18 python-doit-0.21.0-2.fc18 python-fedmsg-meta-fedora-infrastructure-0.1.7-1.fc18 python-itsdangerous-0.21-2.fc18 python-kerberos-1.1-10.fc18 qelectrotech-0.30-0.8.beta.fc18 rubygem-qpid_messaging-0.22.0-1.fc18 screen-4.1.0-0.15.20120314git3c2946.fc18 subethasmtp-3.1.7-1.fc18 sugar-labyrinth-15-1.fc18 sugar-maze-24-1.fc18 targetcli-2.1.fb26-2.fc18 wireshark-1.8.8-2.fc18 Details about builds: adevs-2.6-4.fc18 (FEDORA-2013-11238) C++ library for constructing discrete event simulation Update Information: Adevs (A Discrete EVent System simulator) is a C++ library for constructing discrete event simulations based on the Parallel DEVS and Dynamic DEVS (dynDEVS) formalism. References: [ 1 ] Bug #971244 - Review Request: adevs - C++ library for constructing discrete event simulation https://bugzilla.redhat.com/show_bug.cgi?id=971244 amanda-3.3.2-4.fc18 (FEDORA-2013-11239) A network-capable tape backup solution
Fail2ban denied again by selinux
After recent updates fail2ban was broken again.
* Plugin catchall (100. confidence) suggests
***
If you believe that python2.7 should be allowed write access on the
fail2ban directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep fail2ban-client /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Contextsystem_u:system_r:fail2ban_client_t:s0
Target Contextsystem_u:object_r:fail2ban_var_run_t:s0
Target Objectsfail2ban [ dir ]
Sourcefail2ban-client
Source Path /usr/bin/python2.7
Port Unknown
Host s198.xx.yy.ro
Source RPM Packages python-2.7.5-1.fc19.x86_64
Target RPM Packages
Policy RPMselinux-policy-3.12.1-52.fc19.noarch
Selinux Enabled True
Policy Type targeted
Enforcing ModeEnforcing
Host Name s198.xx.yy.ro
Platform Linux s198.xx.yy.ro 3.9.5-301.fc19.x86_64
#1
SMP Tue Jun 11 19:39:38 UTC 2013 x86_64
x86_64
Alert Count 35
First Seen2013-06-17 14:04:13 EEST
Last Seen 2013-06-19 08:28:22 EEST
Local ID 9d6fd1b8-250e-4425-b3e3-7590dc3bc1f1
Raw Audit Messages
type=AVC msg=audit(1371619702.236:67): avc: denied { write } for
pid=871 comm=fail2ban-client name=fail2ban dev=tmpfs ino=11022
scontext=system_u:system_r:fail2ban_client_t:s0
tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
type=SYSCALL msg=audit(1371619702.236:67): arch=x86_64 syscall=access
success=no exit=EACCES a0=1ab48c0 a1=3 a2=32adbbbf88 a3=0 items=0 ppid=1
pid=871 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 ses=4294967295 tty=(none) comm=fail2ban-client
exe=/usr/bin/python2.7 subj=system_u:system_r:fail2ban_client_t:s0
key=(null)
Hash: fail2ban-client,fail2ban_client_t,fail2ban_var_run_t,dir,write
** Fixing **
[cristi@s198 ~]$ systemctl status fail2ban.service
fail2ban.service - Fail2ban Service
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled)
Active: failed (Result: start-limit) since Wed 2013-06-19 08:28:22
EEST; 1min 45s ago
Process: 871 ExecStart=/usr/bin/fail2ban-client -x start (code=exited,
status=255)
Jun 19 08:28:21 s198.xx.yy.ro systemd[1]: fail2ban.service holdoff
tim
Jun 19 08:28:21 s198.xx.yy.ro systemd[1]: Stopping Fail2ban Service...
Jun 19 08:28:21 s198.xx.yy.ro systemd[1]: Starting Fail2ban Service...
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: fail2ban.service: control
pr...5
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: Failed to start Fail2ban
Ser
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: Unit fail2ban.service
entere
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: fail2ban.service holdoff
tim
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: Stopping Fail2ban Service...
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: Starting Fail2ban Service...
Jun 19 08:28:22 s198.xx.yy.ro systemd[1]: fail2ban.service: control
pr...5
[cristi@s198 ~]$ sudo grep fail2ban-client /var/log/audit/audit.log |
audit2allow -M myfail2ban_client
[sudo] password for cristi:
IMPORTANT ***
To make this policy package active, execute:
semodule -i myfail2ban_client.pp
[cristi@s198 ~]$ sudo semodule -i myfail2ban_client.pp
[cristi@s198 ~]$ sudo systemctl restart fail2ban.service
[cristi@s198 ~]$ systemctl status fail2ban.servicefail2ban.service -
Fail2ban Service
Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled)
Active: active (running) since Wed 2013-06-19 08:33:09 EEST; 7s ago
Process: 2083 ExecStart=/usr/bin/fail2ban-client -x start
(code=exited, status=0/SUCCESS)
Main PID: 2086 (fail2ban-server)
CGroup: name=systemd:/system/fail2ban.service
└─2086 /usr/bin/python /usr/bin/fail2ban-server -b
-s /var/run/fai...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.server : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.jail : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.jail : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.jail : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.filter : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.filter : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.filter : ...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban.actions[2086]: INFO Set
banTim...
Jun 19 08:33:09 s198.xx.yy.ro fail2ban-server[2086]:
fail2ban.jail : ...
Jun 19 08:33:09 s198.xx.yy.ro systemd[1]: Started Fail2ban Service.
Cristian Sava
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
