Re: Resume still broken on Thinkpad X1 Carbon
On Tue, 18 Nov 2014 20:54:26 +0100 "valent.turko...@gmail.com" wrote: > Issue was with missing TPM modules! One solution would be to disable > TPM in EFI/BIOS and other to install missing kernel-modules-extra > package. > > Now resume finally works! Just for closure, I'll chime in to say this was my problem too. Really annoyed that I somehow missed it when I was looking at differences in the set of loaded modules between F20 and F21... Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Resume still broken on Thinkpad X1 Carbon
On Mon, 10 Nov 2014 15:33:51 -0500 "Jared K. Smith" wrote: > I had the same problem with mine (X1 Carbon second generation) until I > updated the UEFI firmware on it. Since updating that, I haven't had any > problems with suspend or resume. Which version of the firmware are you at? I upgraded mine as one of my very first acts with the new machine, but maybe I'm still behind? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Resume still broken on Thinkpad X1 Carbon
On Tue, 4 Nov 2014 09:17:25 -0500 Jonathan Corbet wrote: > I'm pretty well mystified, but, given my general lack of skills in this > part of the system, that's not surprising. My next step, perhaps, is to > start disabling boot-time unit files until I find the one that makes > resume work, then try to see what's different under F21. Just in case anybody's curious, systemd-udev-trigger.service seems to be the one that makes the difference on F20. Something is happening there that isn't happening the same way under F21, but I've not had a chance to delve more deeply into it. My investigation would be aided if I could get into the emergency or rescue targets from the live image. But that wants the root password, and an empty password doesn't fly. Is there any way to boot the live image into one of those modes, or is that completely unsupported and out of scope? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Resume still broken on Thinkpad X1 Carbon
On Tue, 04 Nov 2014 10:48:00 -0800 Adam Williamson wrote: > Check the modules loaded in working and non-working cases? Should have mentioned...I did that. About the only promising sounding discrepancy was ec_sys, but loading it didn't change anything. Of course, I loaded it after boot; guess I should retry with ec_sys loaded from the outset. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Resume still broken on Thinkpad X1 Carbon
Just FYI, I tried out the F21 beta image in the vain hope that my resume problems would have magically gone away. No such luck. In case anybody is interested, here is what (little) I know... - Resume works great under F20. - Under F21, suspend seems to work fine, but there is no response to the power button (or any other input). One has to hold the power button until the firmware gets fed up and powers things down hard. - The kernel doesn't seem to matter; running an F20 kernel with F21 user space still fails. - Booting with init=/bin/bash produces a system that will not resume under either release; it fails in pretty much the same way. Single-user mode, instead, resumes properly under F20. So some sort of setup is happening that enables proper resume, but only on F20. - Running the F21 udev configuration on an F20 system still resumes properly. - As far as I can tell, the configuration of wakeup events, as found in sysfs, is the same on both systems. I'm pretty well mystified, but, given my general lack of skills in this part of the system, that's not surprising. My next step, perhaps, is to start disabling boot-time unit files until I find the one that makes resume work, then try to see what's different under F21. But if anybody has a better idea, I'm all ears. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some F21 Alpha impressions
On Mon, 06 Oct 2014 13:15:54 -0400 Matthias Clasen wrote: > Hey Jonathan, thanks for the feedback. Thanks to everybody for the responses! > > - The main thing is that resume does not work in F21. Things appear > >to suspend just fine, but there is no response to pressing the > >blinking power button. I simply have to hold it until it powers > >down hard and start over. > > On my own Carbon with F21, suspend/resume seems to work fine, with lid > close, power button or systemctl suspend. Given that you seem to have > ruled out a kernel problem, I would point at systemd as the best > starting point for further investigation. Is your system using EFI for > booting ? Yes, EFI. I have secure turned off at the moment, but for no particular reason; everything worked the same with it turned on. > > - Emacs is *totally* confused about its window size. Any new window > >comes up essentially full screen, but the sizes it shows when one > >resizes indicates that it thinks its window is quite small - even > >though text display works just fine. F20 shows this too, it's not an > >F21 specific thing. > > Emacs is using GTK+ in 'interesting' way, things could certainly go > wrong here. My system is not hidpi, but if I manually force a scale with > GDK_SCALE=2 emacs, it seems to mostly work as I would expect it - > everything is twice as big (except for the content font - thats the area > where emacs is most special). You can see the screenshot I sent for an example of how it looks. Running Emacs with GDK_SCALE set to 1 makes everything happy again. The HiDPI pixel scaling stuff seems to be full of surprises, though. I've been exploring the intersection with external monitors, which is...not fully pleasing. > > - The huge onscreen keyboard seems to be easy to provoke and hard to > >make go away; this does seem to be new with F21. Is there any way to > >just turn that off? I like my touchscreen, but it's permanently > >attached to a physical keyboard a few cm away; I will *never* want > >the onscreen one. > > To make it go away, use the keyboard button in the lower right corner. > Of course, having it come up unexpectedly is not great, and we need to > improve this. Just as a data point, this hasn't been a problem at all with F20; something changed in 21 to make it much more aggressive. > > - Whatever happened to the ability to associate actions with mouse > >button events? That seems to be gone in F20 too? Is that another > >one of those things we're not supposed to worry our pretty little > >heads about anymore? > > What actions do you mean here ? I could imagine at least 2 things you > might mean here - first, the modifier-click to trigger wm actions on the > content of windows or second, various titlebar click actions. The former. One other thing I've noticed, while I'm typing, is that something seems to reset the keyboard map occasionally. The X1 keyboard is a bit weird, requiring some repairs with xmodmap; occasionally those want to go away. They are easy to get back, of course, but it's a bit of an annoyance. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Emacs (was: Some F21 Alpha impressions)
On Sat, 4 Oct 2014 21:02:15 +0200 drago01 wrote: > Do you have a screenshot of the wrong looking emacs? Attached, finally. Took me a while to get back to a nominally working system after the scaling experiment - had to go to backups in the end. Whatever gnome-tweak-tool tweaks in that case, it's not a simple reversable transformation. Anyway, here's an Emacs window being resized; it thinks it's 39x18, but, as can be seen, it's actually a little more than double that in both directions. Setting GDK_SCALE=1 makes Emacs behave rationally, thanks! jon-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Emacs (was: Some F21 Alpha impressions)
On Sat, 4 Oct 2014 15:23:30 -0400 Matthew Miller wrote: > > The scaling factor I talking about is an integer it cannot go to 0.5 > > ... I am currently not in front of a F21 system so not sure how > > exactly it is labled in tweak tool but it should be there. > > I think the one Jonathan is looking at is the Scaling Factor under Fonts. > That's definitely a floating point value. (And setting it to anything other > than 1 puts the accessibility icon on your top bar forever; one of _my_ > small gripes.) > > The number you're talking about is "Window scaling", under "Windows" in > Tweak Tool, down at the bottom under HiDPI. OK, I'll admit that I hadn't updated GNOME from Matthew's repository; so many of the problems described there seem to be absent on my machine, so I sort of thought it wasn't needed. Anyway, I didn't have that HiDPI section at all. So I updated. Surprisingly little joy has resulted from that move. The value displayed in gnome-tweak-tool was 1. It wouldn't let me set it below that. The following sequence is roughly from memory... - Set to 2. Nothing really appears to change. - Set back to 1. Windows like gnome-terminal and the tweak tool miniaturize. Emacs behaves rationally, instead. - Set back to 2. Everything gets HUGE. I am no longer able to reach the bottom of the tweak tool window. I'm sure there's a standard way of moving it up, but it's not in my brain...I'm used to setting alt-mouse-1 to do that, but that's one of the things you can't do anymore. So I end up switching to a VC and rebooting. - The login screen works fine. Once logged in, though, the display is gray except for a box in the upper left, half the screen's width and maybe 2/3 of its height. That shows my background and the top panel as far as it can be seen. Something is clearly hosed in my configuration, but I don't know what it is. Is there a dconf incantation to set the scaling factor outside of the tweak tool? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Emacs (was: Some F21 Alpha impressions)
On Sat, 4 Oct 2014 19:46:32 +0200 drago01 wrote: > Jonathan can you try to install gnome-tweak-tool and set the scaling > factor to 1 (warning: everything will be smaller) to verify that > (default is 0) ? It was already set to 1 — dunno how it got there, but that's what I had. It won't let me go below 0.5, seemingly. Anyway, at 1, the reported size of the emacs window does appear to be half of reality; I get a "normal" window when it thinks the window is 40 characters wide. Not that it has trouble displaying 80 characters within it... And yes, I should have said from the outset that this is a hidpi screen, sorry, that was sloppy on my part. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Some F21 Alpha impressions
So, feeling like life has kind of sucked recently, I've been compensating by buying toys. One of those is a shiny new Thinkpad X1 Carbon laptop. The first thing I installed on it was the F21 Workstation alpha; here's a few impressions... - The main thing is that resume does not work in F21. Things appear to suspend just fine, but there is no response to pressing the blinking power button. I simply have to hold it until it powers down hard and start over. Interesting data points: It works fine with an F20 install, even with the original 3.11 kernel. But it doesn't work on F21, even booting the F20 kernel. So I don't think it's a kernel thing; something has changed on the user-space side to screw up the wakeup event somehow. I'd like to go chasing after it but time is tight; this particular issue has forced me to go with F20 for now. - Emacs is *totally* confused about its window size. Any new window comes up essentially full screen, but the sizes it shows when one resizes indicates that it thinks its window is quite small - even though text display works just fine. F20 shows this too, it's not an F21 specific thing. - The huge onscreen keyboard seems to be easy to provoke and hard to make go away; this does seem to be new with F21. Is there any way to just turn that off? I like my touchscreen, but it's permanently attached to a physical keyboard a few cm away; I will *never* want the onscreen one. - Whatever happened to the ability to associate actions with mouse button events? That seems to be gone in F20 too? Is that another one of those things we're not supposed to worry our pretty little heads about anymore? Despite that final whine, it mostly looks pretty good. It's only the resume issue that's a total show-stopper for now. Thanks, as always, for all the great work. jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Weird rawhide desktop behavior
On Sat, 24 Mar 2012 12:23:26 -0700 Adam Williamson wrote: > Jonathan, Chuck - if you try holding down a key that ought to do > something for half a second instead of just pressing it, does it work? I'll try that next time the problem hits. I don't have any real way to provoke it now, though, so I don't know when that will be...stay tuned. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Weird rawhide desktop behavior
Here's a strange pathology that just bit me for the first time in a while, though I've seen it before. I'm not sure where to file a bug on this one... In short: I'll be working away, minding my own business, when the desktop goes completely dead - no response to any key or mouse events. That said, the X server is still running; the pointer still moves with the mouse. I can also switch to another virtual console with alt-ctrl-Fn. Sometimes things start working again after some time (measured in minutes); sometimes I lose patience and start over. Today I went and made lunch and it never came back. I've tried killing off applications to see if somebody has some sort of all-inclusive grab, but I can't find the right one if that's the case. I can kill something like Firefox and verify that the process is gone, but the Firefox window remains on-screen when I return to X. For a while I could reliably cause this by hitting the audio mute button on my keyboard, but that went away just when I was about to take a moment and write a note like this. When it hit me today, I was scrolling a LibreOffice window with the scrollwheel. Anybody got a clue what's going on, or where I could look to get more information? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Emacs "yank" behavior change
Well, it only took me a month and a half to get around to figuring this out. I just bet I'm not going to be the only one to ask this question once this version of Emacs spreads more widely, so it's worth posting the solution. On Wed, 1 Feb 2012 10:47:22 -0700 Stephen John Smoogen wrote: > > One thing has changed, though, and it drives me nuts. The Emacs "yank" > > command has, since time immemorial, yanked text from the X clipboard if a > > selection had been made with the mouse. > > Actually it doesn't always... it could choose from what is highlighted > OR what is in its own copy buffer. I have had it randomly choose one > or the other at times. Looking at the emacs faq I think they have been > making it more sticky to one behaviour or another. > > http://www.emacswiki.org/emacs/CopyAndPaste > > So I can't answer if it is soemthing new in X or EMacs but it looks > like there are ways to now fix it to which version of selection you > want. First of all, I was sloppy in my description of the problem. The real problem is that Emacs used to yank from the *primary* selection, but now only yanks from the clipboard. That forces me to do lots of explicit "copy" operations and makes me grumpy. It turns out that the Emacs developers explicitly changed the default behavior in this regard for the 24 release. But, of course, this is Emacs, so there is certainly a knob that can be tweaked to get the old behavior back. In this case, that knob is well hidden, but I have discovered its secret name: x-select-enable-primary The default value is now nil; setting it back to t in .emacs restores the behavior $DEITY intended and reduces the grumpiness level considerably. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: rawhide report: 20120205 changes
On Sun, 5 Feb 2012 17:59:38 +0100 Harald Hoyer wrote: > > Running Transaction Check > > ERROR You need to update rpm to handle: > > rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.i686 > > RPM needs to be updated > > > > I have the lastest rpm build for rawhide (rpm-4.9.1.2-11.fc17.i686) and > > this version is supposed to have this patch. > > The check is correct. It prevents you from installing filesystem-3-2 on an > unconverted system. So...what is the advice for rawhide folks who are running into this message? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Emacs "yank" behavior change
So I finally got around to updating the Rawhide system after my last round of travel. When yum informed me that there were 1300 packages to update, I got a little worried. But things actually mostly work, modulo a suspend problem that I want to investigate further when time allows. One thing has changed, though, and it drives me nuts. The Emacs "yank" command has, since time immemorial, yanked text from the X clipboard if a selection had been made with the mouse. It worked whether that selection was done within an Emacs window, or in another application altogether. Now it doesn't; one has to explicitly place text into that more Windows-like selection area with a "copy" command of some type or other, or something like a kill-ring-save command for selections within Emacs. (Sorry, I'm not good enough at X to use the right terms for the different clipboard/selection areas). Does anybody know if this is an intended behavioral change in Emacs, and if there's any way to get back to the way things used to be? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Grub -> grub2?
So today yum wants to put grub2 onto my rawhide system, nudging grub out of the way in the process. This makes me nervous. Last time I read about this, it wasn't a straightforward update from one to the other. If that has changed, could somebody please give me a warm fuzzy feeling that allowing that update would be a rational thing to do? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Still singing the fallback mode blues
On Wed, 05 Oct 2011 14:40:03 -0700 Adam Williamson wrote: > So, what's left to determine is whether all that goomph above is just > telepathy pooping its pants, or whether that's actually what's causing > Shell to crash (or quit). > > Do you have any abrt crash reports for gnome-shell? Nothing in abrt, no. It doesn't seem to be an actual SEGV-style crash that would bring abrt into the picture. If I start in the fallback mode, then do "gnome-shell --replace" by hand, I get something similar: JS ERROR: !!! Exception was: TypeError: this._accountManager.get_factory is not a function JS ERROR: !!! lineNumber = '124' JS ERROR: !!! fileName = '"/usr/share/gnome-shell/js/ui/telepathyClient.js"' JS ERROR: !!! stack = '"()@/usr/share/gnome-shell/js/ui/telepathyClient.js:124 Client()@/usr/share/gnome-shell/js/ui/telepathyClient.js:77 _createUserSession()@/usr/share/gnome-shell/js/ui/main.js:84 start()@/usr/share/gnome-shell/js/ui/main.js:223 @:1 "' JS ERROR: !!! message = '"this._accountManager.get_factory is not a function"' Window manager warning: Log level 32: Execution of main.js threw exception: TypeError: this._accountManager.get_factory is not a function gnome-shell-calendar-server[2444]: Got HUP on stdin - exiting FWIW, that telepathyClient.js file actually belongs to gnome-shell; I'm not sure that telepathy itself has much to do with it. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Still singing the fallback mode blues
So the roadblock that kept {cl,m}utter off my Rawhide box cleared and I
figured I could now happily to back to swearing at gnome-shell. Alas, no
such luck. "Something went wrong" still; for an added bonus, the login
screen is now only willing to give me a choice of sessions the first time
around. If I pick the wrong one, I have to reboot for my sins...
Here's my .xsession-errorsthere does seem to be any confusion around.
Anybody got any ideas?
Thanks,
jon
gnome-session[1092]: EggSMClient-WARNING: Desktop file
'/h/corbet/.config/autostart/sealertauto.desktop' has malformed Icon key
'setroubleshoot_icon.png'(should not include extension)
gnome-session[1092]: EggSMClient-WARNING: Desktop file
'/h/corbet/.config/autostart/puplet.desktop' has malformed Icon key
'pup.png'(should not include extension)
GNOME_KEYRING_CONTROL=/tmp/keyring-q8OkKo
GNOME_KEYRING_CONTROL=/tmp/keyring-q8OkKo
GNOME_KEYRING_CONTROL=/tmp/keyring-q8OkKo
GPG_AGENT_INFO=/tmp/keyring-q8OkKo/gpg:0:1
GNOME_KEYRING_CONTROL=/tmp/keyring-q8OkKo
GPG_AGENT_INFO=/tmp/keyring-q8OkKo/gpg:0:1
SSH_AUTH_SOCK=/tmp/keyring-q8OkKo/ssh
gnome-session[1092]: WARNING: Application 'gnome-settings-daemon.desktop'
failed to register before timeout
JS ERROR: !!! Exception was: TypeError: this._accountManager.get_factory
is not a function
JS ERROR: !!! lineNumber = '124'
JS ERROR: !!! fileName =
'"/usr/share/gnome-shell/js/ui/telepathyClient.js"'
JS ERROR: !!! stack =
'"()@/usr/share/gnome-shell/js/ui/telepathyClient.js:124
Client()@/usr/share/gnome-shell/js/ui/telepathyClient.js:77
_createUserSession()@/usr/share/gnome-shell/js/ui/main.js:84
start()@/usr/share/gnome-shell/js/ui/main.js:223
@:1
"'
JS ERROR: !!! message = '"this._accountManager.get_factory is not a
function"'
Window manager warning: Log level 32: Execution of main.js threw exception:
TypeError: this._accountManager.get_factory is not a function
gnome-shell-calendar-server[1361]: Got HUP on stdin - exiting
JS ERROR: !!! Exception was: TypeError: this._accountManager.get_factory
is not a function
JS ERROR: !!! lineNumber = '124'
JS ERROR: !!! fileName =
'"/usr/share/gnome-shell/js/ui/telepathyClient.js"'
JS ERROR: !!! stack =
'"()@/usr/share/gnome-shell/js/ui/telepathyClient.js:124
Client()@/usr/share/gnome-shell/js/ui/telepathyClient.js:77
_createUserSession()@/usr/share/gnome-shell/js/ui/main.js:84
start()@/usr/share/gnome-shell/js/ui/main.js:223
@:1
"'
JS ERROR: !!! message = '"this._accountManager.get_factory is not a
function"'
Window manager warning: Log level 32: Execution of main.js threw exception:
TypeError: this._accountManager.get_factory is not a function
gnome-shell-calendar-server[1508]: Got HUP on stdin - exiting
gnome-session[1092]: WARNING: App 'gnome-shell.desktop' respawning too quickly
(gnome-settings-daemon:1110): PackageKit-WARNING **: failed to get properties:
Launch helper exited with unknown return code 127
(gnome-settings-daemon:1110): PackageKit-WARNING **: failed to set proxy:
Launch helper exited with unknown return code 127
(gnome-settings-daemon:1110): updates-plugin-WARNING **: could not get
properties
(gnome-settings-daemon:1110): PackageKit-WARNING **: failed to set root: Launch
helper exited with unknown return code 127
(gnome-settings-daemon:1110): updates-plugin-WARNING **: failed to set proxies:
Launch helper exited with unknown return code 127
(gnome-settings-daemon:1110): updates-plugin-WARNING **: failed to set install
root: Launch helper exited with unknown return code 127
common-plugin-Message: checking whether we have a device for 4: yes
common-plugin-Message: checking whether we have a device for 5: yes
common-plugin-Message: checking whether we have a device for 6: yes
common-plugin-Message: checking whether we have a device for 7: yes
common-plugin-Message: checking whether we have a device for 8: yes
common-plugin-Message: checking whether we have a device for 9: yes
common-plugin-Message: checking whether we have a device for 10: yes
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Good thing I build my own kernels
As I was booting my system after today's Rawhide update, I noticed that there were no Fedora kernels on offer at all. It seems like, once again, grubby is going weird and refusing to add lines for new kernels to grub.conf as they are installed. Is this, perhaps, a subtle hint that I should switch the system to grub2? :) Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some notes from fallback mode
On Fri, 23 Sep 2011 18:50:16 +0200 Michael Schwendt wrote: > > 3.7.9 never showed the problem - > > Let's not argue about that, please. 3.7.9-0.3.20110409cvs was the first to > suffer from focus problems, and 3.7.9-4 was the one to "fix" it. Sorry, I was being sloppy. I meant "recent 3.7.9" of course... In particular, claws-mail-3.7.9-6.fc17.x86_64.rpm did not exhibit focus issues; claws-mail-3.7.10-1.fc17.x86_64.rpm did. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some notes from fallback mode
On Fri, 23 Sep 2011 16:09:43 +0100 Peter Robinson wrote: > Looks more like you need gnome-shell 3.1.92 amd clutter-gst-1.3.14-2 > > https://admin.fedoraproject.org/updates/FEDORA-2011-13111 > > They're both in the update, you might want to try another mirror, or > "yum clean all" The thing they are *not* in is rawhide; it still has gnome-shell-3.1.91.1-2.fc17.x86_64.rpm until that changes, updating on rawhide seems to not be possible. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some notes from fallback mode
On Fri, 23 Sep 2011 00:50:24 +0200 Michael Schwendt wrote: > The old focus issue was due to a side-effect of a work-around for > https://bugzilla.gnome.org/show_bug.cgi?id=653061 > which had caused Claws Mail to start minimized. That bug is still > not fixed in GNOME Shell, but we have switched to a different work-around. > That work-around only takes out a single line of code, so Claws Mail > does not even try to start minimized. > > Filing a ticket would be a start. Please mention whether it is reproducible > with the previous Claws Mail 3.7.9 builds. 3.7.9 never showed the problem - I ended up downgrading to that version after each attempt with 3.7.10. As of this morning, 3.7.10 is working just fine for me (modulo missing plugins), but remember: I'm currently stuck in fallback mode. Until I can get back to a working gnome shell, I can't properly test claws in rawhide. About gnome shell, it looks like the problem is here: --> Processing Dependency: libcogl.so.2()(64bit) for package: clutter-gst-1.3.14-1.fc16.x86_64 --> Processing Dependency: libcogl.so.2()(64bit) for package: gnome-shell-3.1.91.1-2.fc17.x86_64 --> Processing Dependency: libcogl.so.5()(64bit) for package: mutter-3.1.92-1.fc17.x86_64 --> Processing Dependency: libcogl.so.5()(64bit) for package: clutter-1.8.0-1.fc17.x86_64 It seems that things have been rather inconsistently built? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some notes from fallback mode
On Thu, 22 Sep 2011 23:05:28 +0200 Michael Schwendt wrote: > IMO, it could be much more productive if you also > evaluated Fedora 16 development instead of Fedora 17 development. Sigh. I've been running Rawhide for a very long time. As of the last year or so, though, almost every post I make draws a response like this. I'm dense, I'll admit, but I'm getting the hint. Rawhide probably does not have much of a future on this machine. I just don't know, yet, what I'll replace it with. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Some notes from fallback mode
There's something about that "oh no something went wrong" screen that just
makes it clear that you're not going to have as good a day as you'd hoped
for. Now that I've finished re-educating the window manager about my
peculiarities ("yes, I do like more than one workspace, thank you"),
here's a few things that are on my mind.
1) Chances are the "oh no" will go away once I install the latest versions
of clutter and mutter; that has been my experience in the past. But yum
won't do that for me. Somehow, in recent times, it has gotten rather
harder to figure out *why* a given installation fails; "skipped because of
dependency problems" is rather uninformative. I *think* the information I
need can be found in lines like these:
--> Processing Dependency: libcogl.so.2()(64bit) for package:
clutter-gst-1.3.14-1.fc16.x86_64
--> Processing Dependency: libcogl.so.5()(64bit) for package:
clutter-1.8.0-1.fc17.x86_64
...but it takes some digging. But, just maybe, if I nuke clutter-gst and
everything that needs it I can move forward.
Meanwhile, experience tells me that the dependencies between gnome-shell
and clutter/mutter aren't quite understood by the packaging system.
2) When running under gnome-shell, I have all kinds of problems with
partial and/or delayed updates to the screen; these have been mentioned on
this list before. Emacs and claws-mail seem particularly susceptible to
this problem, for what it's worth. In fallback mode, instead, display
updates Just Work.
3) Speaking of claws, the current Rawhide version remains hosed. It has
the old pop-under and focus problems that got fixed earlier this year, and
a number of the plugin packages are a rev behind and no longer work.
4) This morning my system OOMed for the first time in years. ConsoleKit
appears to be going on a memory binge; its virtual size leave pikers like
firefox way in the dust.
Enough for one day, guess I should get some real work done now.
Thanks,
jon
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
On Mon, 05 Sep 2011 19:50:53 +0200 Hans de Goede wrote: > Jonathan, can you give bluez-4.96-3.fc17 a spin? It should fix your > mouse + keyboard issue. OK, I finally got a chance to install this. Mouse and keyboard work great, thanks. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
On Mon, 05 Sep 2011 19:50:53 +0200 Hans de Goede wrote: > Jonathan, can you give bluez-4.96-3.fc17 a spin? It should fix your > mouse + keyboard issue. Will do, but not before the weekend - I forgot to bring the desktop system to LPC :) Thanks for addressing this, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: bluez and hci's which initially come up as hid (was Re: Some days it just doesn't pay to update)
On Fri, 02 Sep 2011 09:18:31 +0200 Hans de Goede wrote: > Which is in essence the problem you are seeing here Jonathan, after > my bluez update, your bluetooth dongle is actually being out into > HCI mode, so that it can for example also be used to sync with your > phone, use a bluetooth headset, etc. IOW this is a feature not a bug > but this does mean that in order to use your bluetooth mouse / > keyboard, you need to explicitly pair them with the bluetooth HCI once, > which will require the use of a regular usb keyboard, which is, erm, > not so good, one could even argue this is a bug after all. I guess I would argue that the vast majority of users who get one of these Logitech keyboards simply want a keyboard; they don't really care that they got a general-purpose Bluetooth adapter in the deal. So breaking that by default doesn't necessarily seem like the right idea. That said... > This also brings us back to my: "I'm really really surprised about the > "has Just Worked for years" bit", since we've been shipping hid2hci > + udev rules for years (and this issue has been reported by others long > before). ...it sounds like it's maybe been broken in this way for a while? My machine has been riding the Rawhide train for years, it's possible it doesn't correspond to what I'd get if I just dumped F15 onto it. > The questions is how do we want to handle this? At least we should > release note this I guess, but perhaps we can do something smarter? Perhaps the first thing to do is to try to figure out if it's only me. Nobody else has griped on the Rawhide front, but, then, I think I may be about the only Rawhide user left (and people keep telling me that I shouldn't be there either). If it's only me I'll figure out how to put the keyboard into a mode where it's agreeable to pairing, grumble for a moment, and get on with my life. If others are affected, it would be nice to detect the situation and put up a little warning, preferably on the login screen. Not sure how easy that would be to do. Thanks for the explanation, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On Wed, 31 Aug 2011 16:21:13 -0700 Adam Williamson wrote: > Obvious suspects there - gnome-bluetooth and udev for the BT keyboard > issue, None of the above, as it turns out. These guys: bluez-libs-4.96-2.fc17.x86_64 bluez-4.96-2.fc17.x86_64 break my keyboard. Downgrading to: bluez-libs-4.96-1.fc17.x86_64 bluez-4.96-1.fc17.x86_64 makes me happy. Downgrading claws-mail fixes that problem, naturally; it also gets me rssyl back, which is nice. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On Wed, 31 Aug 2011 16:21:13 -0700 Adam Williamson wrote: > Obvious suspects there - gnome-bluetooth and udev for the BT keyboard > issue, claws-mail itself for the claws update. I don't think Bluetooth itself should come into play at all; the device simply looks like a keyboard, even the BIOS can cope with it. I don't even have Bluetooth built into my kernel (but note, again, that the Fedora kernel behaves the same way). The system *seems* to recognize it properly: Aug 31 16:49:15 bike kernel: [ 648.761264] usb 2-4.2.2: new full speed USB device number 18 using ehci_hcd Aug 31 16:49:15 bike kernel: [ 648.853757] usb 2-4.2.2: New USB device found, idVendor=046d, idProduct=c713 Aug 31 16:49:15 bike kernel: [ 648.853763] usb 2-4.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 31 16:49:15 bike kernel: [ 648.853767] usb 2-4.2.2: Product: Logitech BT Mini-Receiver Aug 31 16:49:15 bike kernel: [ 648.853770] usb 2-4.2.2: Manufacturer: Logitech Aug 31 16:49:15 bike kernel: [ 648.853773] usb 2-4.2.2: SerialNumber: 0007617AC3F9 Aug 31 16:49:15 bike kernel: [ 648.858614] input: Logitech Logitech BT Mini-Receiver as /devices/pci:00/:00:1d.7/usb2/2-4/2-4.2/2-4.2.2/2-4.2.2:1.0/input/input12 Aug 31 16:49:15 bike kernel: [ 648.858919] generic-usb 0003:046D:C713.000A: input,hidraw1: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-4.2.2/input0 (There is another set of stuff for the built-in mouse too; mouse doesn't work either). The syslog output is the same regardless of whether the device actually works or not. udev is an interesting idea, I may mess with that. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Some days it just doesn't pay to update
On Wed, 31 Aug 2011 16:03:44 -0700 Adam Williamson wrote: > it would probably help to know what *was* in the update set. OK, from yum.log: Aug 31 07:17:02 Updated: atk-2.1.5-1.fc16.x86_64 Aug 31 07:17:03 Updated: gtk3-3.1.12-1.fc16.x86_64 Aug 31 07:17:07 Updated: mono-core-2.10.5-1.fc17.x86_64 Aug 31 07:17:08 Updated: GConf2-3.1.6-1.fc16.x86_64 Aug 31 07:17:08 Updated: libuuid-2.20-1.fc17.x86_64 Aug 31 07:17:10 Updated: pulseaudio-libs-0.9.23-1.fc16.x86_64 Aug 31 07:17:10 Updated: libudev-173-2.fc17.x86_64 Aug 31 07:17:10 Updated: libgudev1-173-2.fc17.x86_64 Aug 31 07:17:11 Updated: gstreamer-plugins-base-0.10.35-3.fc17.x86_64 Aug 31 07:17:11 Updated: perl-Git-1.7.6.1-1.fc17.noarch Aug 31 07:17:13 Updated: git-1.7.6.1-1.fc17.x86_64 Aug 31 07:17:13 Updated: 1:NetworkManager-glib-0.9.0-1.fc17.x86_64 Aug 31 07:17:13 Updated: libblkid-2.20-1.fc17.x86_64 Aug 31 07:17:14 Updated: gnutls-2.12.9-1.fc17.x86_64 Aug 31 07:17:14 Updated: libmount-2.20-1.fc17.x86_64 Aug 31 07:17:15 Updated: 1:gnome-bluetooth-libs-3.1.4-2.fc16.x86_64 Aug 31 07:17:15 Updated: at-spi2-core-2.1.5-1.fc16.x86_64 Aug 31 07:17:15 Updated: 12:dhcp-libs-4.2.2-4.fc17.x86_64 Aug 31 07:17:16 Updated: pam-1.1.4-4.fc17.x86_64 Aug 31 07:17:17 Updated: util-linux-2.20-1.fc17.x86_64 Aug 31 07:17:18 Updated: udev-173-2.fc17.x86_64 Aug 31 07:17:18 Updated: bluez-libs-4.96-2.fc17.x86_64 Aug 31 07:17:18 Updated: mdadm-3.2.2-8.fc17.x86_64 Aug 31 07:17:18 Updated: 12:dhcp-common-4.2.2-4.fc17.x86_64 Aug 31 07:17:19 Updated: 12:dhclient-4.2.2-4.fc17.x86_64 Aug 31 07:17:20 Updated: 1:NetworkManager-0.9.0-1.fc17.x86_64 Aug 31 07:17:20 Updated: gitk-1.7.6.1-1.fc17.noarch Aug 31 07:17:20 Updated: pulseaudio-libs-glib2-0.9.23-1.fc16.x86_64 Aug 31 07:17:20 Updated: pulseaudio-utils-0.9.23-1.fc16.x86_64 Aug 31 07:17:20 Updated: GConf2-gtk-3.1.6-1.fc16.x86_64 Aug 31 07:17:20 Updated: mono-data-sqlite-2.10.5-1.fc17.x86_64 Aug 31 07:17:20 Updated: mono-winfx-2.10.5-1.fc17.x86_64 Aug 31 07:17:21 Updated: mono-extras-2.10.5-1.fc17.x86_64 Aug 31 07:17:21 Updated: mono-winforms-2.10.5-1.fc17.x86_64 Aug 31 07:17:22 Updated: mono-mvc-2.10.5-1.fc17.x86_64 Aug 31 07:17:22 Updated: mono-wcf-2.10.5-1.fc17.x86_64 Aug 31 07:17:23 Updated: mono-data-2.10.5-1.fc17.x86_64 Aug 31 07:17:24 Updated: mono-web-2.10.5-1.fc17.x86_64 Aug 31 07:17:26 Updated: monodoc-2.10.5-1.fc17.x86_64 Aug 31 07:17:26 Updated: 1:gnome-utils-libs-3.1.5-1.fc16.x86_64 Aug 31 07:17:27 Updated: gtkhtml3-4.1.90-1.fc17.x86_64 Aug 31 07:17:27 Updated: adwaita-gtk3-theme-3.1.5-1.fc16.x86_64 Aug 31 07:17:27 Updated: polkit-gnome-0.102-1.fc16.x86_64 Aug 31 07:17:28 Updated: gnome-session-3.1.5-1.fc16.x86_64 Aug 31 07:17:28 Updated: atk-devel-2.1.5-1.fc16.x86_64 Aug 31 07:17:30 Updated: gtk3-devel-3.1.12-1.fc16.x86_64 Aug 31 07:17:30 Updated: jpackage-utils-1.7.5-14.fc17.x86_64 Aug 31 07:17:31 Updated: SDL-1.2.14-13.fc17.x86_64 Aug 31 07:17:31 Updated: adwaita-gtk2-theme-3.1.5-1.fc16.x86_64 Aug 31 07:17:31 Updated: yelp-xsl-3.1.4-1.fc16.noarch Aug 31 07:17:31 Updated: 1:yelp-libs-3.1.2-1.fc16.x86_64 Aug 31 07:17:32 Updated: 1:yelp-3.1.2-1.fc16.x86_64 Aug 31 07:17:32 Updated: smolt-1.4.3-5.fc17.noarch Aug 31 07:17:41 Updated: pypy-libs-1.6-4.fc17.x86_64 Aug 31 07:17:41 Updated: 2:vim-filesystem-7.3.289-1.fc17.x86_64 Aug 31 07:17:44 Updated: 2:vim-common-7.3.289-1.fc17.x86_64 Aug 31 07:17:44 Updated: xmlrpc-c-1.27.5-1700.svn2185.fc17.x86_64 Aug 31 07:17:44 Updated: 1:autocorr-en-3.4.3.2-3.fc17.noarch Aug 31 07:17:46 Updated: selinux-policy-3.10.0-22.fc17.noarch Aug 31 07:17:47 Updated: setroubleshoot-server-3.0.38-3.fc17.x86_64 Aug 31 07:17:48 Updated: tzdata-java-2011i-1.fc17.noarch Aug 31 07:17:58 Installed: 1:java-1.7.0-openjdk-1.7.0.0-0.1.20110803.fc17.x86_64 Aug 31 07:18:01 Updated: 1:libreoffice-ure-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:01 Updated: adwaita-cursor-theme-3.1.5-1.fc16.noarch Aug 31 07:18:02 Updated: gnome-themes-standard-3.1.5-1.fc16.x86_64 Aug 31 07:18:03 Updated: gnome-desktop3-3.1.5-1.fc16.x86_64 Aug 31 07:18:03 Installed: graphite2-1.0.2-3.fc17.x86_64 Aug 31 07:18:04 Updated: 1:libreoffice-opensymbol-fonts-3.4.3.2-3.fc17.noarch Aug 31 07:18:30 Updated: 1:libreoffice-core-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:32 Updated: 1:libreoffice-presenter-screen-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:32 Updated: 1:libreoffice-impress-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:32 Updated: 1:libreoffice-graphicfilter-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:33 Updated: 1:libreoffice-pdfimport-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:33 Updated: 1:libreoffice-draw-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:35 Updated: 1:libreoffice-writer-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:37 Updated: 1:libreoffice-calc-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:38 Updated: 1:libreoffice-math-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:38 Updated: 1:libreoffice-xsltfilter-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:38 Updated: 1:libreoffice-langpack-en-3.4.3.2-3.fc17.x86_64 Aug 31 07:18:39 Updated: gnome-settings-daemon-3.1.5-1.fc16.x86_64 Aug 31 07:18:39 Updated: icedtea-web-1.1.1-3.fc17.
Some days it just doesn't pay to update
So, I thought...LWN writing is almost done for the day, why not do an update and see what happens? What happened: - My Logitech bluetooth keyboard, which has Just Worked for years, doesn't work anymore. Grub still sees it fine, but the running system does not. Sometimes unplugging and replugging the USB receiver makes it come back. Usually not. - I've had one display freeze (unrecoverable) accompanied by "GPU lockup" messages in the log. - claws-mail is back to its old tricks: pop-under compose windows, focus weirdness, etc. It's worth noting that the kernel didn't update in this batch, so none of the above is caused by a kernel change. I see the keyboard unpleasantness with both the kernel-3.1.0-0.rc4.git0.0.fc17.x86_64 kernel and my own -rc4 kernel. Here's to hoping that tomorrow's a better day...:) jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 24 Aug 2011 11:08:52 -0400 Matthias Clasen wrote: > > Error: Protected multilib versions: > > gnome-panel-libs-3.1.5-2.fc16.x86_64 != > > gnome-panel-libs-3.0.2-3.fc16.i686 > > > > I have no idea what these errors mean or how to fix them. > Any advice would be appreciated. Actually, this one is kind of > understandable, but I have also seen 'protected multilib' stuff where > both sides of the != were the same arch, which left me wondering. I've worked my way through this kind of mess a couple of times now, most recently yesterday. Here's my experience: - Do a big rawhide update - in this case, at least two weeks worth. - Somewhere in the middle, while I'm not looking, the update kills the running session and/or X server - I come back to a login screen. It used to be safe to run "yum update" from a terminal window, but, seemingly, not anymore. Not really a step in the right direction. - If I try to rerun the update, it will tell me to try yum-complete-transaction. Each time, actually trying that leads to an infinite loop printing dependency information. - If I just run "yum update", I get the "protected multilib versions" message. What I have found in these cases is that there are *two* versions of the indicated library installed simultaneously (for the same architecture). In each case, simply removing the older version clears the problem. Once I've gotten past the gripes, the update actually works. Dunno if that helps anybody... never a dull moment... jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha ATI Radeon issues?
On Wed, 10 Aug 2011 13:00:34 +0200 Michael Schwendt wrote: > Not always, but at random times. Also: > - perceived lag (compared with F15) > - areas of the screen not getting refreshed in time, staying blank >until I touch the window or move a GTK slider, >e.g. individual mailbox subject lines in Claws Mail summary view Just FYI, I've been seeing some of this in rawhide on my Radeon for a while. Claws does seem to be especially prone to the partial update thing, but emacs shows it too. I've not had the time to even begin to track it down. I see the partial updates with the 3.0 kernel. When I run kernel-3.1.0-0.rc0.git21.1.fc17.x86_64 instead, what I see, in addition, is horrific performance. GNOME shell achieves a new level of pain there, but even fallback mode hurts. I've not had any time to try to figure out what's going on there either. jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Oh no, something went wrong!
On Tue, 05 Jul 2011 09:11:00 -0700 Adam Williamson wrote: > You need Mutter 3.1.3.1 (not 3.1.3). 3.1.3 mistakenly bumped that > namespace. Indeed, that was the problem. All is happy now, thanks! jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Oh no, something went wrong!
Seeing the black screen of death with $SUBJECT is becoming an increasingly
common part of my rawhide experience; today's update brought it back again.
Would it really be too hard for it to way *what* went wrong? I did manage
to find an error in .xsession-errors - but only, of course, if I looked
before logging in with fallback mode. It shouldn't be that hard.
The error, anyway, seems to be this (several times):
JS ERROR: !!! stack = '"("Requiring Shell, version none: Requiring
namespace 'Meta' version '3.0', but '3.1' is already loaded")@gjs_throw:0
@/usr/share/gnome-shell/js/ui/main.js:18
"'
JS ERROR: !!! message = '"Requiring Shell, version none: Requiring
namespace 'Meta' version '3.0', but '3.1' is already loaded"'
JS ERROR: !!! Exception was: Error: Requiring Shell, version none:
Requiring namespace 'Meta' version '3.0', but '3.1' is already loaded
JS ERROR: !!! lineNumber = '0'
JS ERROR: !!! fileName = '"gjs_throw"'
I'm running gnome-shell-3.0.2-4.fc16.x86_64. Any ideas?
Thanks,
jon
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grubby templates [was Somebody hosed grub.conf]
On Fri, 13 May 2011 08:43:30 -0600 Jonathan Corbet wrote: > I watched closely as today's kernel update came through: > > > Installing : kernel-2.6.39-0.rc7.git3.0.fc16.x86_64 > > 19/37 > > grubby fatal error: unable to find a suitable template In case anybody's watching: today's kernel update (being kernel-2.6.39-0.rc7.git6.1.fc16.x86_64) produced the same message from grubby. BUT it also managed to add the proper line to grub.conf anyway. Not sure what's going on, but the situation seems improved. jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Grubby templates [was Somebody hosed grub.conf]
On Thu, 12 May 2011 18:47:56 + Jóhann B. Guðmundsson wrote: > Anywho it most likely was caused by a post-install script failure. I watched closely as today's kernel update came through: > Installing : kernel-2.6.39-0.rc7.git3.0.fc16.x86_64 > 19/37 > grubby fatal error: unable to find a suitable template Some digging suggests that this is not an uncommon failure mode for grubby... https://bugzilla.redhat.com/show_bug.cgi?id=124246 dates back to 2004. The man page is rather unhelpful on the subject of templates. I've tried restoring older kernel entries to grub.conf from a backup, but that hasn't helped a whole lot. Anything else I can look at? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Somebody hosed grub.conf
On Thu, 12 May 2011 13:13:00 -0500 "Jason D. Clinton" wrote: > On Thu, May 12, 2011 at 12:52, Jonathan Corbet wrote: > > So I went to boot my rawhide system > > You're sending this question to the wrong list. This list is for > people testing the F15 release so you're almost certainly not going to > run in to someone having a problem with rawhide if indeed there is > such a problem. Um...I've been having rawhide-related discussions on this list for some years now - well before F15, or separate frozen branches, or any of that stuff. If you look at http://fedoraproject.org/wiki/Releases/Rawhide, you see: There are two important things all Rawhide testers should do. First, read the test mailing list, where Rawhide users discuss the latest changes. You'll find discussion of significant changes and warnings of severe breakage here. Reading test-list daily is key to staying on top of Rawhide. If you've repurposed the test list, perhaps you would like to update the documentation and tell both of us remaining rawhide users where to go? :) Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Somebody hosed grub.conf
So I went to boot my rawhide system the other day, only to notice that none of the usual fedora kernel options were there. I've long since had my own kernels there, of course, and those have not been touched - but somebody cleared out all of the Fedora options from grub.conf. Am I the only one who has seen this, or did somebody somehow break grub.conf updating? FWIW, I currently have: kernel-2.6.39-0.rc5.git5.0.fc16.x86_64 kernel-2.6.39-0.rc6.git0.0.fc16.x86_64 kernel-2.6.39-0.rc7.git0.0.fc16.x86_64 grub-0.97-74.fc16.x86_64 grubby-7.0.16-3.fc15.x86_64 Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fallback mode further hosed?
On Fri, 22 Apr 2011 18:29:48 -0500 Bruno Wolff III wrote: > The advice there on using alt right click to adjust panels worked. I haven't > set everything back up, but I have one larger panel at the bottom again. It worked for me too - almost. I used to have a single, non-expanded panel in the lower right; now it's centered on the bottom and I can't get it to shift over into the corner. There also doesn't seem to be a way to add a volume control - you have to start with the panel that already has it. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Fallback mode further hosed?
On Fri, 22 Apr 2011 12:19:41 -0500 "Jason D. Clinton" wrote: > Are you still running rawhide despite recommendations not to? Yes...my understanding is that updates will be slow while everybody's busy with F15; I honestly didn't expect it to break my panel at this stage. But, then, rawhide is good at the unexpected. One wonders...what is rawhide for if we're not supposed to run it? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fallback mode further hosed?
Up until now, the fallback mode has preserved (to an approximation) my older panel setup - a single panel, not full width, on the bottom. Today all that's gone; now I have two panels. My launchers are gone, as is a fair amount of my vertical screen space. Is this deliberate? If so, why? It was tolerable before, now it's not. Is there any way to get my old setup back? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
claws-mail hosed in today's Rawhide
[Repeat after me: "never jump into daily rawhide updates in the hope that they'll fix the things that broke yesterday"] What broke today is claws-mail. It reads mail just fine, and will happily let you put time into composing messages, but it is totally unable to send them. Clicks on the "send" button are apparently ignored. Hitting "draft" yields a helpful dialog saying "Can't save draft" and no more. I've had to run screaming to an older version... Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Today's GNOME pathologies
On Mon, 28 Mar 2011 21:59:58 + "Jóhann B. Guðmundsson" wrote: > Note it's not uncommon for reporters to accidently continue to stay on > the rawhide train instead of disabling rawhide and enable > updates-testing when it get's branched. > > If you need a usable system I recommend that you stay away from the > rawhide train until it hits alpha which is sometime late August if > memory serves me correct. FWIW, I've been running Rawhide for many years - I'm well aware of what I'm getting into. Are you saying I shouldn't report Rawhide problems? jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Today's GNOME pathologies
On Mon, 28 Mar 2011 18:03:38 + "Jóhann B. Guðmundsson" wrote: > > - Blinking cursors are on everything and cannot be turned off. I *hate* > > blinking cursors. They make me Grumpy. > > You should be able to disable that with gconf-editor/gsettings > /desktop/gnome/interface/cursor_blink if we follow the common > workarounds for new nuances ;) Nope, that shows it already disabled (as does the "keyboard" settings dialog). It's just that the applications don't seem to be paying attention anymore... Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Today's GNOME pathologies
On Mon, 28 Mar 2011 12:42:43 -0500 Bruno Wolff III wrote: > > So I just updated my Rawhide system. Items noticed in the first few > > minutes: > > Rawhide or branched? Rawhide. jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Today's GNOME pathologies
So I just updated my Rawhide system. Items noticed in the first few minutes: - Blinking cursors are on everything and cannot be turned off. I *hate* blinking cursors. They make me Grumpy. - Lots of icons are missing. The "system settings" dialog is now mostly text. - Setting the background no longer works; it is pure black. Obviously something has gone a little funky somewhere; or is it only me? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GNOME Tweak Tool now ready for testing
On Fri, 25 Mar 2011 16:56:05 +0100 Michel Alexandre Salim wrote: > I just checked Rawhide's gnome-shell and pygobject2, and pygobject2 does > contain gi, so I'm not sure what's going on. Sigh, I am. My bad, sorry. I have my own python in /usr/local/bin; that breaks a *lot* of Fedora-supplied Python programs. I'm not sure why the #! line doesn't just point straight to the version of Python that the program has as a dependency, but so be it. Once I use Fedora's Python, all is well. I should have thought of that before posting, sorry. Nice tool - my menu bars fit again and that makes me happy :) Thanks, jon Jonathan Corbet / LWN.net / cor...@lwn.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: GNOME Tweak Tool now ready for testing
On Thu, 24 Mar 2011 10:48:08 +0100 Michel Alexandre Salim wrote: > For those wanting to more easily tweak their GNOME 3 desktop (e.g. font > adjustment), GNOME Tweak Tool should now be in your updates-testing. > > https://admin.fedoraproject.org/updates/gnome-tweak-tool-2.91.92-3.fc15 I installed gnome-tweak-tool-2.91.92-3.fc16.noarch onto my rawhide system, but no joy: Traceback (most recent call last): File "/usr/bin/gnome-tweak-tool", line 19, in import gi ImportError: No module named gi Missing dependency, maybe? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [solved] On making a proper kernel for gnome-shell
On Fri, 11 Mar 2011 18:02:52 -0500 Dave Jones wrote: > > Nope, I do have ACLs built into my kernel. > > You need the XATTR options, as well as ACL ones. I have that too, the problem would appear to be elsewhere. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [solved] On making a proper kernel for gnome-shell
On Fri, 11 Mar 2011 16:25:24 -0600 "Jason D. Clinton" wrote: > Actually, it's probably somehow related to ACL's which are supposed to > automatically be append to the device node in question on ConsoleKit > activation of the user session: > > [jclinton@jclinton-laptop ~]$ getfacl /dev/dri/card0 > getfacl: Removing leading '/' from absolute path names > # file: dev/dri/card0 > # owner: root > # group: video > user::rw- > user:jclinton:rw- > group::rw- > mask::rw- > other::--- Indeed, I get: # file: dev/dri/card0 # owner: root # group: video user::rw- group::rw- other::--- Guess I need to start figuring out how all this consolekit stuff works... > Maybe you're missing ACL's support, generally? Nope, I do have ACLs built into my kernel. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [solved] On making a proper kernel for gnome-shell
On Fri, 11 Mar 2011 14:45:29 -0700 Jonathan Corbet wrote: > Something tells me that this difference probably has some bearing on my > little problem. Found it. The root cause is that I was unable to open /dev/dri/card0. In the end, every system management problem in existence can be diagnosed with strace... I added myself to the "video" group and everything is happy now. I have not delved further, but I am guessing that the problem is that I don't build SELinux into my kernels. I've never had anything break as the result of leaving out SELinux before... Worth noting, I bet I'm not the only one who will run into this one. Thanks to everybody who took a look at this, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: On making a proper kernel for gnome-shell
On Fri, 11 Mar 2011 14:24:43 -0500 Dave Jones wrote: > > So I'm mystified. Any ideas? Might there be some magic in the Fedora > > initrd that I'm missing (I've never used initrd on my systems)? > > An easy test would be to actually build one for your test kernel. > make install should do it all automatically for you. Tried it - no change. I've encountered a strange clue, though. I looked at the differences in glxinfo output between the Fedora and mainline 38-rc8 kernels; of most interest, perhaps, is this. The Fedora kernel tells me: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) Q35 GEM 20100330 DEVELOPMENT OpenGL version string: 1.4 Mesa 7.10-devel Mainline kernel tells me this: OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe OpenGL version string: 2.1 Mesa 7.10-devel Something tells me that this difference probably has some bearing on my little problem. xdriinfo just tells me "i915" either way. No user space changes between the two. I'm trying to learn quickly about how all this stuff works, but, if anybody has any ideas that might help me learn even quicker, I'd be most appreciative. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On making a proper kernel for gnome-shell
So I'm still trying to find my way into this gnome-shell 3D world. In the process, I'm running into display corruption on my Intel Q35-based system. I'd like to try to track it down; in particular, I'd like to figure out if the problem exists in the mainline kernel so I can report it right to the source, preferably with a bisection. My problem: I can't build a kernel which consents to run gnome-shell. What I get (on typing "gnome-shell --replace") is: failed to create drawable Window manager error: Unable to initialize Clutter. As far as I can tell, my kernel configuration is the same as Fedora's for the relevant options - i915, KMS by default, etc. But the Fedora kernel works, mine does not. Other interesting observations: - The Xorg.0.log output appears to be identical in both cases. - The glxgears benchmark (known to be the definitive measure of 3D performance :) runs ten times faster on my custom kernel than on the Fedora kernel. On my kernel, I don't get the "using vertical sync" message. So I'm mystified. Any ideas? Might there be some magic in the Fedora initrd that I'm missing (I've never used initrd on my systems)? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell performance (was gnome-applets and rawhide updates)
On Sat, 19 Feb 2011 13:56:34 +0100 drago01 wrote: > OK, can you please try this scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=2851093 ? No change with that installed. > And also please file a bug it makes tracking it easier than here. Done: https://bugzilla.redhat.com/show_bug.cgi?id=678791 Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell performance (was gnome-applets and rawhide updates)
On Fri, 18 Feb 2011 19:32:36 +0100 drago01 wrote: > Please name your hardware "onboard intel" is too vague. According to X: [12.376] (II) intel(0): Integrated Graphics Chipset: Intel(R) Q35 [12.376] (--) intel(0): Chipset: "Q35" lspci sees it as: VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) FWIW, I'm actually running the current rawhide kernel instead of some creation of my own too. > Also there has been a recent fix in upstream clutter that should improve that. I have clutter-1.6.4-1.fc16.x86_64, which, by your other mail, should be recent enough. Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
gnome-shell performance (was gnome-applets and rawhide updates)
On Thu, 17 Feb 2011 16:42:43 -0800 Adam Williamson wrote: > No. You only need to remove gnome-applets. gnome-python2-applet too, then it worked. But...the result is unusably slow - as in it can't keep up with me typing in a gnome-terminal. Now, I am a fairly fast typist, but still... A quick look shows mutter running flat-out most of the time. I'm running fairly standard onboard Intel graphics; it all works beautifully under metacity. Is gnome-shell just too cool for my hardware, or is there something else going on? Thanks, jon Jonathan Corbet / LWN.net / cor...@lwn.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
gnome-applets and rawhide updates
So, it's been a while since I've been able to update my rawhide desktop and see what breaks - long enough that I've forgotten the pain and want to feel it again. The blocking factor should be familiar to many: Error: Package: 1:gnome-applets-2.32.0-3.fc15.x86_64 (@rawhide) Requires: libpanel-applet-2.so.0()(64bit) Removing: gnome-panel-libs-2.31.92-1.fc15.x86_64 (@rawhide) libpanel-applet-2.so.0()(64bit) Updated By: gnome-panel-libs-2.91.6-5.fc15.x86_64 (rawhide) Not found Now I understand thus we panel users are supposed to move out of the stone age and bow before our gnome-shell overlords. I'd like to give it a try, but attempts to install gnome-shell run into the same roadblock. My question: is the only way forward here to obliterate any trace of the panel and applets from my system and commit to the gnome-shell experience for once and for all? Or might there be a way to keep both on my system for a little while until I'm sure I can function under gnome-shell? Thanks, jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
