Password security issues in GDM
I've filed bug number 1092274 ( https://bugzilla.redhat.com/show_bug.cgi?id=1092274) about a week ago, and so far there's been no response. I have a lab full of fedora desktops and I have disabled the standard login method so the users have to type their username (so that other usernames are not exposed). The problem is that GDM is asking for the username twice. So what happens is that the user types their username, and the their password (which is what you would expect next in a normal log in process) but their password is typed in plain text on the screen for all to see. This has to be a serious security issue (if not just bloody annoying to the user). Obviously I'm asking if someone could look at this and address it. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome desktop not always logging in properly.
And the link to the bug is https://bugzilla.redhat.com/show_bug.cgi?id=1076981 On 17 March 2014 10:22, Rodd Clarkson r...@clarkson.id.au wrote: Hi Guys, I've files a bug about gnome desktop logging in with squashed icons and being basically unusable. Applications work, but you can't log out or restart and everything is squashed. I'm seeing this in two environments (my laptop, and the schools computer lab). Is anyone else having issues. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Gnome desktop not always logging in properly.
Hi Guys, I've files a bug about gnome desktop logging in with squashed icons and being basically unusable. Applications work, but you can't log out or restart and everything is squashed. I'm seeing this in two environments (my laptop, and the schools computer lab). Is anyone else having issues. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome desktop not always logging in properly.
On 17 March 2014 12:21, Michal Jaegermann mic...@harddata.com wrote: On Mon, Mar 17, 2014 at 10:22:24AM +1100, Rodd Clarkson wrote: Applications work, but you can't log out or restart and everything is squashed. I'm seeing this in two environments (my laptop, and the schools computer lab). Is anyone else having issues. https://bugzilla.redhat.com/show_bug.cgi?id=1063093 Not even acknowledged. OTOH I do not see any squashing. That may be another bug. Maybe something is mixed up about your screens resolution? Michal I've got a few bugs that haven't been acknowledged recently (read a lot). This bug isn't what I'm seeing. I have however seen this problem in the lab and have added to it and CCed myself. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Gnome desktop not always logging in properly.
On 17 March 2014 12:49, Sérgio Basto ser...@serjux.com wrote: On Seg, 2014-03-17 at 10:23 +1100, Rodd Clarkson wrote: And the link to the bug is https://bugzilla.redhat.com/show_bug.cgi?id=1076981 and this one ? , is also about logging : https://bugzilla.redhat.com/show_bug.cgi?id=1073128 Yeah, this one doesn't seem to be my problem. Log in always works, it's just that the vast majority of the icons on the desktop don't appear to work. Rodd On 17 March 2014 10:22, Rodd Clarkson r...@clarkson.id.au wrote: Hi Guys, I've files a bug about gnome desktop logging in with squashed icons and being basically unusable. Applications work, but you can't log out or restart and everything is squashed. I'm seeing this in two environments (my laptop, and the schools computer lab). Is anyone else having issues. Rodd -- Sérgio M. B. -- 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
CUPS in F17 doesn't include BrowseRemoteProtocols=CUPS
Hi All CUPS in F17 doesn't include BrowseRemoteProtocols=CUPS Is this a bug or is this deliberate. In the past my shared printers (using cups on another server) have just appeared in Fedora, but I've had to manually add BrowseRemoteProtocols=CUPS (which was missing) to get the printers to appear. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: CUPS in F17 doesn't include BrowseRemoteProtocols=CUPS
CUPS in F17 doesn't include BrowseRemoteProtocols=CUPS Also, the firewalld settings don't seem to allow this to work (I have to stop the firewalld.service) to let me print. I've tried using firewall-config but all it does is stick a firewall icon in the bottom panel and I can't seem to change anything. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Installing fedora while running fedora?
Using a liveCD I can install fedora on my system while running the LiveCD. Can you do the same thing just running vanilla Fedora? This would be a really useful feature, but I'm not seeing any information on how to do it. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Interactive white boards and Fedora Xorg setup
On Wed, 2010-07-07 at 11:01 +1000, Peter Hutterer wrote: [faked-up reply, I'm not on the list, ajax pointed it out to me on the archives. please make sure you CC me for any replies] Unlike a mouse, these pointer devices move the mouse pointer to where you touch the screen. For example, if the IWB is to the right of my laptop screen and I touch the right edge of the screen then the mouse pointer appears on the right side of my laptop screen, and not where I've touched the screen. The pointer device included with the IWB needs to be able to be configured to do two things: 1. Only work as a device for the IWB screen. The mouse shouldn't be able to be moved off the screen, only around it. 2. Calibrate the pointer so that you can declare the top/bottom/left/right of the screen (as where the image falls on the pointer device isn't usually at the extremes of the device.) Is this possible? The 1.9 X server that's already in rawhide has an coordinate transformation matrix to restrict absolute devices to essentially any rectangle on the screen. The matrix is a property on each device and can be modified with the xinput commandline tool (no GUI tools yet). For example, I've got a 1440x900 and a 1920x1200 display. To restrict my tablet to the right (larger) screen: $ xinput --set-prop Wacom Intuos4 6x9 Coordinate Transformation Matrix 0.58 0 0.42 0 1 0 0 0 1 The matrix thus looks like this: | 0.58 0 0.42 | | 01 0| | 00 1| giving us a scale into 58% of the screen range with an offset of 42%. Your numbers will likely vary but that should fix the issue for you. Peter, I've finally found a chance to take a look at this (now that I've got f14 running on my laptop) and I need a little help understanding the matrix. In your case you have two screens with the same aspect ratio (16:10), so I can see you your right hand screen is 0.58 of the total width and 0.42 across from the left hand side of the span. However, I've got a situation where one of my screens (on my laptop) is 16:9 (1920x1080) and the other is 5:4 (1280x1024) and I'm not sure how to set up the matrix for this. Are you able to supply some extra 'clues'? Can we assume the laptop screen will be on the left hand side (as this is how it defaults in Fedora, and I should be able to figure out how to adjust it if it's not)? Also, where do I get the name for the pointer device? I'm sorry to ask, but I've done some searching on google and couldn't come up with the answers. regards Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Comparing other distros kernels to Fedora.
2010/9/28 Michał Piotrowski mkkp...@gmail.com W dniu 27 września 2010 23:13 użytkownik Michał Piotrowski mkkp...@gmail.com napisał: 2010/9/27 Rodd Clarkson r...@clarkson.id.au: I've been having troubles getting 2.6.34.x kernels on f13 and 2.6.35.x kernels on f14 to resume from suspend. https://bugzilla.redhat.com/show_bug.cgi?id=628897 To try and resolve this I've been trying out other recent distros to see if they have similar kernels and whether I have the same problem resuming. Recent ubuntu is still only using 2.6.32 but openSUSE 11.3 has a 2.6.34 kernel and I can suspend and resume from it using the live CD. How can I compare this kernel to ones in f13/f14 to see why it works in one and not in the other? You can download source package and check whether there are any patches that fixes suspend. I grepped the source and I have not found anything obvious. I've downloaded the Ubuntu 10.10 LiveCD which uses kernel 2.6.35 and suspend and resume works fine in Ubuntu too. What difference in the Fedora kernels could be causing this problem? I know it seems strange to some, but suspend and resume are one of the most important features for me on my laptop. I can (and have) put up with (a lot) less than optimal video, no sound and even wireless network issues, but without a functioning suspend and resume it's quite arduous having to wait for a system to shutdown and reboot. Each to their own I guess, but I'd really like this to work and it appears that it does work on other distros which makes me wonder what Fedora isn't doing right. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 4:54 AM, Michal Jaegermann mic...@harddata.comwrote: What difference in the Fedora kernels could be causing this problem? Did you look into /var/log/pm-suspend.log after a failed attempt? Some clues could be there. I've been through this, but in case something was missed: Initial commandline parameters: Sun Oct 10 15:43:41 EST 2010: Running hooks for suspend. /usr/lib64/pm-utils/sleep.d/00logging suspend suspend:Linux moose.localdomain 2.6.35.6-39.fc14.x86_64 #1 SMP Fri Oct 8 16:23:12 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Module Size Used by rfcomm 67220 4 sco17180 2 bnep 15390 2 l2cap 51240 16 rfcomm,bnep sunrpc201180 1 cpufreq_ondemand9278 4 acpi_cpufreq7329 1 freq_table 3955 2 cpufreq_ondemand,acpi_cpufreq mperf 1481 1 acpi_cpufreq ip6t_REJECT 4279 2 nf_conntrack_ipv6 18078 7 ip6table_filter 1687 1 ip6_tables 17481 1 ip6table_filter ipv6 286249 40 ip6t_REJECT,nf_conntrack_ipv6 uinput 7368 0 snd_hda_codec_atihdmi 2727 1 snd_hda_codec_idt 55579 1 snd_hda_intel 24399 2 snd_hda_codec 86743 3 snd_hda_codec_atihdmi,snd_hda_codec_idt,snd_hda_intel snd_hwdep 6392 1 snd_hda_codec snd_seq53791 0 snd_seq_device 6191 1 snd_seq snd_pcm80190 2 snd_hda_intel,snd_hda_codec snd_timer 19892 2 snd_seq,snd_pcm btusb 15482 2 bluetooth 89276 9 rfcomm,sco,bnep,l2cap,btusb lib80211_crypt_tkip 7987 0 uvcvideo 55489 0 videodev 41889 1 uvcvideo wl 1961114 0 iTCO_wdt 11256 0 joydev 9737 0 tg3 110866 0 v4l1_compat12970 2 uvcvideo,videodev snd63968 12 snd_hda_codec_idt,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_p cm,snd_timer soundcore 6576 1 snd v4l2_compat_ioctl32 9869 1 videodev snd_page_alloc 7559 2 snd_hda_intel,snd_pcm dell_laptop 6477 0 iTCO_vendor_support 2610 1 iTCO_wdt lib802115095 2 lib80211_crypt_tkip,wl dell_wmi3323 0 i2c_i801 11088 0 rfkill 17622 3 bluetooth,dell_laptop dcdbas 8524 1 dell_laptop microcode 18548 0 wmi 8138 1 dell_wmi sdhci_pci 7569 0 firewire_ohci 21170 0 sdhci 18448 1 sdhci_pci firewire_core 45817 1 firewire_ohci mmc_core 64113 1 sdhci crc_itu_t 1563 1 firewire_core video 21637 0 output 2253 1 video radeon635137 2 ttm55006 1 radeon drm_kms_helper 25743 1 radeon drm 177972 4 radeon,ttm,drm_kms_helper i2c_algo_bit5205 1 radeon i2c_core 26900 6 videodev,i2c_i801,radeon,drm_kms_helper,drm,i2c_algo_bit total used free sharedbuffers cached Mem: 3982524 4350483547476 0 70004 116480 -/+ buffers/cache: 2485643733960 Swap: 8389624 08389624 success. /usr/lib64/pm-utils/sleep.d/00powersave suspend suspend:success. /usr/lib64/pm-utils/sleep.d/01grub suspend suspend:not applicable. /usr/lib64/pm-utils/sleep.d/49bluetooth suspend suspend:not applicable. /usr/lib64/pm-utils/sleep.d/55NetworkManager suspend suspend:success. /usr/lib64/pm-utils/sleep.d/56atd suspend suspend:success. /usr/lib64/pm-utils/sleep.d/56dhclient suspend suspend:success. /usr/lib64/pm-utils/sleep.d/75modules suspend suspend:not applicable. /usr/lib64/pm-utils/sleep.d/90clock suspend suspend:not applicable. /usr/lib64/pm-utils/sleep.d/94cpufreq suspend suspend:success. /usr/lib64/pm-utils/sleep.d/95led suspend suspend:not applicable. /usr/lib64/pm-utils/sleep.d/95packagekit suspend suspend:success. /usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:success. /usr/lib64/pm-utils/sleep.d/99hd-apm-restore.hook suspend suspend:saving level 96 for device sda success. /usr/lib64/pm-utils/sleep.d/99video suspend suspend:kernel.acpi_video_flags = 0 success. Sun Oct 10 15:43:42 EST 2010: performing suspend -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 6:46 AM, Adam Williamson awill...@redhat.comwrote: On Tue, 2010-10-12 at 21:39 +1100, Rodd Clarkson wrote: I've downloaded the Ubuntu 10.10 LiveCD which uses kernel 2.6.35 and suspend and resume works fine in Ubuntu too. What difference in the Fedora kernels could be causing this problem? One more triaging step I'd recommend is to try an upstream kernel of the same vintage. If that works, you know that some change Fedora adds is breaking it. If it doesn't work, you know that Ubuntu and SUSE both have a patch that Fedora doesn't which fixes it. (I suspect this may come down to graphics code; Fedora generally carries rather newer upstream versions of intel, nouveau and radeon than other distros, and these can introduce regressions). I'm pretty confident that I've tried every f13 kernel that's been through koji. If I haven't, I've come close. I've also tried all the 'released' f14 kernels along with a couple of others (I'm still to try the two kernel suggestions above, I'm downloading Kyle's now and will rebuild the kernel if needed). Early in F13's move to 2.6.34 there was another bug that caused issues with suspending the system. This was resolved, which revealed problems with resuming from a suspend (which seems to have worked properly). So, it's hard to tell if this bug was in the first 2.6.34 kernel for f13 or not. I know it seems strange to some, but suspend and resume are one of the most important features for me on my laptop. I can (and have) put up with (a lot) less than optimal video, no sound and even wireless network issues, but without a functioning suspend and resume it's quite arduous having to wait for a system to shutdown and reboot. Each to their own I guess, but I'd really like this to work and it appears that it does work on other distros which makes me wonder what Fedora isn't doing right. It's not strange, suspend/resume is critical to most laptop users. It's just pretty hard to diagnose and fix. I'm aware of this which is why I'm trying to supply as much information as possible to the kernel developers to try and rectify this problem I have. It may be that isn't not actually the kernel, but some other related part of the software stack, but I wouldn't know where to start looking. R. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org 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
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 4:34 AM, Kyle McMartin k...@mcmartin.ca wrote: On Tue, Oct 12, 2010 at 01:09:18PM +0200, Micha? Piotrowski wrote: It might be a patch added by one of Fedora kernel developers. CC'ing fedora-kernel Honestly, there's nothing particularly relevant in F-14's kernel. Can you please try: http://kyle.fedorapeople.org/kernel/2.6.36-0.36.rc7.git3.fc15/x86_64/ Which is a nodebug rawhide kernel, which is even closer to upstream than the F-14 2.6.35 is, and let us know if that's any more helpful? (I could swear someone was doing pre-built vanilla kernels, we should bring that back if not.) I've tried this kernel (sans perf) and I can suspend and resume again. This is in f14. Should I try this in f13? Will this help isolate what's wrong with the 2.6.34 and 2.6.35 kernels for my system? I should ask, are there other fedora testers using a Dell Studio XPS 1547? R. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 12:32 PM, Rodd Clarkson r...@clarkson.id.au wrote: On Wed, Oct 13, 2010 at 12:15 PM, Richard Ryniker ryni...@alum.mit.eduwrote: are there other fedora testers using a Dell Studio XPS 1547? I have a Dell Studio XPS 1645 that runs F13: it suspends and resumes just fine. Not your machine exactly, therefore this information may be more tantalizing than useful. Yeah, I think those 2 each units might be important. Arghhh, that should have been a 1647 (not 1547 as I wrote). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Comparing other distros kernels to Fedora.
On Wed, Oct 13, 2010 at 12:43 PM, Michal Jaegermann mic...@harddata.comwrote: On Wed, Oct 13, 2010 at 10:39:46AM +1100, Rodd Clarkson wrote: On Wed, Oct 13, 2010 at 4:54 AM, Michal Jaegermann mic...@harddata.com wrote: What difference in the Fedora kernels could be causing this problem? Did you look into /var/log/pm-suspend.log after a failed attempt? Some clues could be there. I've been through this, but in case something was missed: /usr/lib64/pm-utils/sleep.d/99video suspend suspend:kernel.acpi_video_flags = 0 success. Sun Oct 10 15:43:42 EST 2010: performing suspend There _is_ something missing here. After that last line I would expect to see a bunch of log entries from an attempt to resume. A resume part was either not really running at all or failed early enough before anything had a chance to write in a log. This seems to be an information although I am not sure what to do with it. Do you see the same if you try to hibernate/thaw? I would also compare with pm-suspend.log from when you are running a rawhide kernel which you say does these things for you I get exactly the same issue with hibernate/thaw too. I've compared the log files and with the exception of a couple of modules being absent (lib80211_crypt_tkip, wl[1], lib80211) and a couple of modules being present (fuse, shpchp, intel_ips) there isn't a lot of difference except that the log file above is 'missing' something. The missing bit is the bit where it resumes properly ;-] Rodd [1] I know that wl is a proprietary driver, but I can assure you that I have tested extensively with it not loaded (and not even loaded at boot up). I'm aware that this module taints the kernel, but I've got it installed on the kernel that works and it's not causing problems. I'm happy to supply proof of this bug without wl installed. It should read like this: Wed Oct 13 11:15:21 EST 2010: Awake. Wed Oct 13 11:15:21 EST 2010: Running hooks for resume /usr/lib64/pm-utils/sleep.d/99video resume suspend:success. /usr/lib64/pm-utils/sleep.d/99hd-apm-restore.hook resume suspend:restoring level 96 for device sda /dev/sda: setting Advanced Power Management level to 0x60 (96) APM_level= 96 success. /usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler resume suspend:success. /usr/lib64/pm-utils/sleep.d/95packagekit resume suspend:method return sender=:1.43 - dest=:1.90 reply_serial=2 success. /usr/lib64/pm-utils/sleep.d/95led resume suspend:not applicable. /usr/lib64/pm-utils/sleep.d/94cpufreq resume suspend:success. /usr/lib64/pm-utils/sleep.d/90clock resume suspend:not applicable. /usr/lib64/pm-utils/sleep.d/75modules resume suspend:success. /usr/lib64/pm-utils/sleep.d/56dhclient resume suspend:success. /usr/lib64/pm-utils/sleep.d/56atd resume suspend:Stopping atd: [ OK ] Starting atd: [ OK ] [ OK ] success. /usr/lib64/pm-utils/sleep.d/55NetworkManager resume suspend:success. /usr/lib64/pm-utils/sleep.d/49bluetooth resume suspend:not applicable. /usr/lib64/pm-utils/sleep.d/01grub resume suspend:not applicable. /usr/lib64/pm-utils/sleep.d/00powersave resume suspend:success. /usr/lib64/pm-utils/sleep.d/00logging resume suspend:success. Wed Oct 13 11:15:21 EST 2010: Finished. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Wed, Sep 8, 2010 at 8:25 PM, Rodd Clarkson r...@clarkson.id.au wrote: I've already tried this kernel and doesn't fix things for me. I'm now having (what I suspect are) the same suspend issues in both f13 and f14. It's being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=628897 I've made a couple of suggestions based on research using google for bugs that look similar to mine, and I'm awaiting some feedback from the kernel guys. I've been trying kernels from other distros and while ubuntu is still using 2.6.32, opensuse 11.3 is using 2.6.34 and this kernel works for me with regard to suspend and resume. How can I compare this kernel with the kernels in fedora13 to see what's different? Or is this to big a job? Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Tue, Sep 7, 2010 at 10:56 PM, Jan Wildeboer jwild...@redhat.com wrote: On 09/07/2010 02:45 PM, drago01 wrote: http://koji.fedoraproject.org/koji/buildinfo?buildID=193772 This one addresses some suspend issues so it is worth testing. Bingo! Suspend/resume now works again. (Still have to do a service NetworkManager restart after resume some times, minor to me) I've already tried this kernel and doesn't fix things for me. I'm now having (what I suspect are) the same suspend issues in both f13 and f14. It's being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=628897 I've made a couple of suggestions based on research using google for bugs that look similar to mine, and I'm awaiting some feedback from the kernel guys. Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 3:55 PM, pbrobin...@gmail.com pbrobin...@gmail.comwrote: On Thu, Sep 2, 2010 at 3:12 AM, Rodd Clarkson r...@clarkson.id.au wrote: My system suspends and resumes fine on f13 with the 2.6.33 kernels, so it isn't unreasonable to expect this functionality to continue on a stable release. On the other hand the 2.6.34 kernel has made my F-13 laptop 100% more usable than the entire release. I've been having massive issues and I've been actually meaning to reinstall F-12 but haven't actually had the time to do so. It got pushed from updates-testing to updates very quickly because a lot of people tested it before it even hit updates-testing and hence got the karma required to go through to updates very quickly. Ah, and here I guess lies the problem. The email from the fedora engineers (some weeks ago) quite clearly stated not to give this kernel karma points so that it didn't get pushed until they were sure it wouldn't cause issues, so I haven't been giving it negative karma as a result. I'm really not happy with this entire process. I've also received an email saying that my 99 votes have been removed because someone at fedora decided to change the rules regarding my bug and voting and that my votes don't count any more. What a way to run an election. Anyhow, what a waste of time all around. I spend a couple of painful hours booting and rebooting my system to try and isolate this bug and the developers couldn't take two minutes to mention that they needed to post the kernel and that they would address my bug some time soon. R. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.
On Thu, Sep 2, 2010 at 4:34 PM, Matthias Runge mru...@matthias-runge.dewrote: Although I think, this is the wrong way, putting exclude=kernel-* in your /etc/yum.conf will exclude the kernel from updating. Thanks Matthias, I don't like excluding kernels either, but I don't need to be adding --exclude=kernel\* to each run of yum update until this is resolved, and since there's an open bug for this, I'll know when it's resolved because I'm following the bug. At this time I can allow the new kernels again. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fedora 14 updates-testing report
On Sat, Aug 21, 2010 at 3:53 PM, Rodd Clarkson r...@clarkson.id.au wrote: Out put from recent yum upgrade snip Oh, and after doing the above yum update --skip-broken $ sudo yum update Loaded plugins: langpacks, presto, refresh-packagekit Adding en_AU to language list Setting up Update Process Resolving Dependencies -- Running transaction check --- Package evince.x86_64 0:2.31.90-1.fc14 set to be updated --- Package evince-libs.x86_64 0:2.31.90-1.fc14 set to be updated --- Package evince-nautilus.x86_64 0:2.31.90-1.fc14 set to be updated --- Package gimp.x86_64 2:2.6.10-4.fc14 set to be updated --- Package gimp-help-browser.x86_64 2:2.6.10-4.fc14 set to be updated --- Package gimp-libs.x86_64 2:2.6.10-4.fc14 set to be updated -- Processing Dependency: libpoppler.so.6()(64bit) for package: 1:openoffice.org-pdfimport-3.3.0-4.3.fc14.x86_64 --- Package poppler.x86_64 0:0.14.2-1.fc14 set to be updated --- Package poppler-glib.x86_64 0:0.14.2-1.fc14 set to be updated --- Package poppler-utils.x86_64 0:0.14.2-1.fc14 set to be updated -- Finished Dependency Resolution Error: Package: 1:openoffice.org-pdfimport-3.3.0-4.3.fc14.x86_64 (@updates-testing) Requires: libpoppler.so.6()(64bit) Removing: poppler-0.14.1-1.fc14.x86_64 (@anaconda-InstallationRepo-201008070243.x86_64/14-Alpha) libpoppler.so.6()(64bit) Updated By: poppler-0.14.2-1.fc14.x86_64 (updates-testing) Not found You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Can't read last ~5% of a remote file
I'm getting the same symptoms as a bug that was closed during f11 (and f12) in f13. https://bugzilla.redhat.com/show_bug.cgi?id=516165 Any chance that this bug has re-emerged? R. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Musicians' Guide Draft Now Posted
On Tue, Aug 3, 2010 at 3:03 PM, Christopher Antila crant...@gmail.comwrote: I am pleased to let you know that the first official draft of the Musicians' Guide is now available under the Draft Documentation category on the Fedora Documentation website, http://docs.fedoraproject.org I'm not seeing this yet. I've looked under Draft Documentation but I'm not seeing Musicians Guide as an option. Am I looking in the wrong place, do I need some special permissions, or is it just not there? R. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Interactive white boards and Fedora Xorg setup
On Wed, 2010-07-07 at 11:01 +1000, Peter Hutterer wrote: [faked-up reply, I'm not on the list, ajax pointed it out to me on the archives. please make sure you CC me for any replies] Thanks for the reply, and it's nice to know that ajax noticed this (as it appears ajax has much to do with Xorg on fedora (and I'm guessing elsewhere)). Unlike a mouse, these pointer devices move the mouse pointer to where you touch the screen. For example, if the IWB is to the right of my laptop screen and I touch the right edge of the screen then the mouse pointer appears on the right side of my laptop screen, and not where I've touched the screen. The pointer device included with the IWB needs to be able to be configured to do two things: 1. Only work as a device for the IWB screen. The mouse shouldn't be able to be moved off the screen, only around it. 2. Calibrate the pointer so that you can declare the top/bottom/left/right of the screen (as where the image falls on the pointer device isn't usually at the extremes of the device.) Is this possible? The 1.9 X server that's already in rawhide has an coordinate transformation matrix to restrict absolute devices to essentially any rectangle on the screen. The matrix is a property on each device and can be modified with the xinput commandline tool (no GUI tools yet). For example, I've got a 1440x900 and a 1920x1200 display. To restrict my tablet to the right (larger) screen: $ xinput --set-prop Wacom Intuos4 6x9 Coordinate Transformation Matrix 0.58 0 0.42 0 1 0 0 0 1 The matrix thus looks like this: | 0.58 0 0.42 | | 01 0| | 00 1| giving us a scale into 58% of the screen range with an offset of 42%. Your numbers will likely vary but that should fix the issue for you. This looks like a great start, but I'm guessing it only works in 1.9 at this stage. Will this also work in 1.8? Obviously a nice GUI tool for this where you can specify the pointer and the region visually would be the finishing touches (as this will vary for me from IWB to IWB and I'm a Relief Teacher that sees a lot of different IWBs.) Presumably this would be easy enough to implement in the Monitor Preferences (System Preferences Monitor) by including options to limit pointer devices to a particular display. The other bit of the problem is defining the mouse region for the pointer device. Unlike your wacom device (and similar devices) where the top left point of the device is quite easier to assume as the top left corner of the display, IWBs aren't so simple. IWBs have the image projected onto the screen which is also the pointer device, but it's very unlikely that the top left corner of the projected image is also at the same place as the top left corner of the screen. Since the mouse pointer moves to where you place you finger on the screen, it's important that this maps precisely so you can click buttons and drag items without a level of hit and miss (and incorrectly buttons pressed). I've even seen IWBs where the image isn't even square on the IWB, and I guess this needs to be addressed too. Any suggestions for this? Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Interactive white boards and Fedora Xorg setup
Hi, I regularly use (a variety of) interactive white boards and the single biggest frustration is getting the pointer device working so it's actually useable. Let me give you an example. I plug and IWB into my laptop and Fedora configures is as an extension to my desktop. This is great because I can drag what I want to appear on the IWB and not have to reveal my entire desktop. The pointer device in the IWB works and I can use it as a mouse, but it's rendered unusable because the mouse acts across the entire desktop (both my laptop screen and the IWB). Unlike a mouse, these pointer devices move the mouse pointer to where you touch the screen. For example, if the IWB is to the right of my laptop screen and I touch the right edge of the screen then the mouse pointer appears on the right side of my laptop screen, and not where I've touched the screen. The pointer device included with the IWB needs to be able to be configured to do two things: 1. Only work as a device for the IWB screen. The mouse shouldn't be able to be moved off the screen, only around it. 2. Calibrate the pointer so that you can declare the top/bottom/left/right of the screen (as where the image falls on the pointer device isn't usually at the extremes of the device.) Is this possible? Does this make sense? Is this something that's included in f13 (if it is I can't find it) or could it be included as a part of f14. As far as I'm concerned this is a huge feature as I'm constantly finding IWB pointer devices are useless unless I mirror (and mirroring reveals my desktop and usually squashes the icons as the laptop screen has to be sized down and then I have to move the icons back). Rodd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
