[Test-Announce] Fedora 14 Beta RC Validation Test Summary
Greetings, It's time to summarize F-14 Beta RC validation tests. Apologies for the absence of some RC3 install testing, but I'm glad to see that it went on smoothly, so special thanks for the ones who helped executing the cases. Though Beta has been declared gold based on the Beta release criterion[1], the summary of it is still helpful to make the issues clear for the final release candidates cycle. * Installation *** * F14Blocker: 623956 NEW - VESA driver fails in qemu/kvm machines, system hangs at X init 635821 NEW - Attempting to submit (scp or bugzilla) an exception report fails if networking not active 627789 MODIFIED - Error setting up repository - 16, Device busy * Warnings: 585006 NEW - livecd-creator creates i386 and x86_64 ISOs which are larger than indicated by the ISO header 633815 NEW - Network installation fails when IPv4 DHCP fails/ IPv6 present 635873 MODIFIED - ImportError: No module named product 635887 MODIFIED - TypeError: getDiskPart() takes exactly 1 argument (2 given) ** Desktop *** * F14Blocker: 624136 NEW - [abrt] evolution-2.31.5-2.fc14: e_import_cancel: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) 625367 NEW - SELinux is preventing /usr/libexec/kde4/kdm_greet "write" access on /usr/libexec/kde4/lnusertemp 636118 NEW - Swell Foop fails to run in F14 Beta RC3 Desktop live install 542255 ASSIGNED - [abrt] crash detected in gmixer-1.3-11.fc12 * Warnings: 635897 NEW - SELinux is preventing /usr/sbin/lxdm-binary "execute" access on xauth. 636229 NEW - Wrong defaults for actions on pressing power, suspend and hibernate buttons 636380 NEW - Boot Failure from Live CD Desktop (F14B RC3) Can't mount root filesystem 636104 NEW - [abrt] nautilus-2.31.92-1.fc14: g_type_check_instance_cast: Process /usr/bin/nautilus was killed by signal 11 (SIGSEGV) 635895 MODIFIED - SELinux is preventing /lib64/dbus-1/dbus-daemon-launch-helper "execute" access on hald. For testing details, please visit: https://fedoraproject.org/wiki/Category:Fedora_14_Beta_RC_Test_Results If your bug is not listed, feel free to discuss it in the list, and next time please share your results on the result pages. Thanks, Hurry [1] https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria -- Contacts Hurry FAS Name: Rhe Timezone: UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 11:55, Owen Taylor wrote: > On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: > > > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > > > `G_IS_OBJECT (object)' failed > > > Segmentation fault (core dumped) > > > > There also seem to be problems with nautilus from GTK+ ABI changes - I > > see various warnings along the lines of: > > > > (nautilus:27082): GLib-GObject-WARNING **: specified class size for type > > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class > > size > > > > These indicate a definite need for rebuild, so I'll kick one off now, > > and maybe things will be better after that finishes. It's certainly not > > worth worrying about anything related to Nautilus until it's rebuild. > > The newer version still dies. It seemed to work for a while but segfaults again. Also, sftp doesn't work any more. Interestingly enough, it doesn't segfault under KDE. darrell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
I can't tell people Fedora is the best if it's not carrying the latest upstream KDE, its just not possible. I'm constantly recruiting new users. I'm in regular contact with the team of people who run Techrights. If a new release of KDE comes out, this is what happens currently 1) Kubuntu adds a backports PPA. Stable users do not get the latest KDE. 2) openSUSE will have it in their KDE Factory Repo, and it will turn into a release Repo later (not stable). Stable users do not get the latest KDE. 3) Mandriva will have official packages on kde.org but they aren't pushed as updates. Stable users do not get the latest KDE. 4) Fedora will have it entirely unofficially as a third party repo for a few weeks, it will also be in the official repo in updates-testing and then in updates. Stable users DO get the latest KDE. This makes Fedora BETTER than the rest. If we delegate the latest KDE to backports like everyone else, how does that make Fedora better? And we do want to be better than everyone else if we want to compete with Apple and Microsoft. On Sat, Sep 25, 2010 at 9:57 PM, Brandon Lozza wrote: > Wasn't this exception allowed for KDE at Fesco? Considering that a > typical KDE upgrade contains bug fixes, security fixes as well as new > features and UI changes. > > On Sat, Sep 25, 2010 at 4:02 PM, Kevin Fenzi wrote: >> On Sat, 25 Sep 2010 15:53:49 -0400 >> Brandon Lozza wrote: >> >>> It would be nice to list it somewhere as an exception, to avoid >>> panics :) >> >> Well, I personally do not want to say: >> >> "Hey, anytime you like down the road, you get an exception to push a >> new major version. Have fun". >> >> We still need to see what all is in the update, what the pros and cons >> are, etc. >> >> I could add an example showing this however. :) >> >> Let me do that. >> >> kevin >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/devel >> > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
Wasn't this exception allowed for KDE at Fesco? Considering that a typical KDE upgrade contains bug fixes, security fixes as well as new features and UI changes. On Sat, Sep 25, 2010 at 4:02 PM, Kevin Fenzi wrote: > On Sat, 25 Sep 2010 15:53:49 -0400 > Brandon Lozza wrote: > >> It would be nice to list it somewhere as an exception, to avoid >> panics :) > > Well, I personally do not want to say: > > "Hey, anytime you like down the road, you get an exception to push a > new major version. Have fun". > > We still need to see what all is in the update, what the pros and cons > are, etc. > > I could add an example showing this however. :) > > Let me do that. > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, 25 Sep 2010 15:53:49 -0400 Brandon Lozza wrote: > It would be nice to list it somewhere as an exception, to avoid > panics :) Well, I personally do not want to say: "Hey, anytime you like down the road, you get an exception to push a new major version. Have fun". We still need to see what all is in the update, what the pros and cons are, etc. I could add an example showing this however. :) Let me do that. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
It would be nice to list it somewhere as an exception, to avoid panics :) On Sat, Sep 25, 2010 at 12:04 PM, Rex Dieter wrote: > Brandon Lozza wrote: > >> It seems like the policy would kill the use of an upgraded KDE (4.5 to >> 4.6) because KDE almost always makes UI changes. > > The kde-sig asked FESCo to consider up to 1 KDE version upgrade per release, > and this was generally well-received during the last FESCo meeting, so no > reason to panic. > > References, > http://fedoraproject.org/wiki/SIGs/KDE/Update_policy > > -- Rex > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Thu, 23 Sep 2010 16:58:39 +0200 Jaroslav Reznik wrote: > Not a very latest thing but more like - more useful thing. Because > some useful "user experience" changes could lead to better user > experience even changing slightly the old one. It's not easy to catch > this in policy. I like the idea, I understand why we want it - I want > it too, why we need it, it's more relaxed than the first proposals > leading practically to frozen, dead and unmaintained releases. But > still there should be more space for packager's decision and of > course upstream - upstream releases for some reason. Sure sometimes things change for the better... a new UI is nicer than the old one. The thing is that most people don't want that to happen on some random day in the middle of a stable release. This would cause them to stop doing what they wanted to do to learn the new UI. Much better when it's in the new Fedora release where they realize that they need to learn how the new version works before using it. >Also this > stability proposal has to be coupled with a new release scheme - not > just update policy but also release schedules, what we are going to > call "release", how often (9 months? branch every 6 - we we talking > with Jesse a few minutes ago), how big changes we want in a new > release etc... I'm not sure it's going to work without deeper changes > here too. Feel free to put together a detailed proposal on a new release cycle and we can take a look. I've often thought a 9month cycle (18 or 19 months supported) would be nice and give us more time, but then we are misaligned with a number of projects upstream that are on a 6 month cycle, and also, we don't release at the same time(s) each year, resulting in hitting holidays or the like. :( I don't know a solution, but if you come up with one, please do let me know. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 22 Sep 2010 22:21:33 +0200 Till Maas wrote: > On Tue, Sep 21, 2010 at 03:47:04PM -0600, Kevin Fenzi wrote: > > > I'd like to ask for feedback and helping cleaning up an updates > > policy draft page: > > > > https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft > > > > How can we clarify the language or the layout of the page to be more > > clear? Are there places that it could be more like the existing > > package update howto page? Could we be more detailed about what > > bodhi enforces and whats just good practice? > > This here sounds strange: > | The update rate for any given release should drop off over time, > | approaching zero near release end-of-life; since updates are > primarily | bugfixes, fewer and fewer should be needed over time. > > This essentially says that after 12 or 18 months all software in > Fedora is bug free and does not need any updates. This is a very > strange assumption. E.g. why do we stop supporting the software after > it became totally stable? IMHO this claim cannot reasonably be made. I won't re-hash the rest of the thread here, but I think the observation here is that "Obvious" or "easily fixable" bugs would be apparent after 12-18months. If there's some obvious bug that affects a lot of people, it would stand to reason a lot of people would see it and someone would report it. > | All critical path updates MUST get one +1 karma from a proventester > | and +1 karma from another user before going stable. > | All non critical path updates MUST either reach the prescribed karma > | level for that update > > Why is the barrier for non critical path updates higher than for > critical path updates? E.g. with the default karma threshold of 3, two > +1 karma points would not be enough. You can change the default... 3 is just what was thought of for default. You could set it to 1 or 2. > Also is this really what you propose for critical path updates? E.g. > for the Package update acceptance criteria this was proposed, but > implemented was a net karma sum of 2 with at least one +1 from a > proventester. Yes, it should be the same as whats in effect now. Fixed. > Also can someone please explain the practical advantages of requiring > the autokarma threshold to approve the ability to push a non critical > path update to stable instead of just requiring a net karma sum of 1? > I asked for this several times on the Update Policy ticket but did not > get any answer: > https://fedorahosted.org/fesco/ticket/351#comment:55 I don't know that there are practical advantages, I think it's a implementation detail. I'd be fine to making it allow after +1 for non critical path updates. Could you file a RFE on bodhi for that? (please cc me?) > > Are there other exceptions cases that could be covered that you can > > think of? > > | Exceptions > [...] > | If upstream does not provide security fixes for a particular > release, | and if backporting the fix would be impractical, > > If not back porting is an exception, then something in the policy > should say that back porting is now expected from packagers. But it's not. It depends on the upstream. Many have "stable" branches where THEY backport fixes and security issues. So, It would still be "maintainers MAY need to backport fixes if their upstream has no stable branch to follow, is unwilling to help them backport, etc" > | Things to consider: > | Is this a "leaf" package? Would ABI/API change? Does the User > Interface | change? > > IMHO it would be better to really say what is the good answer to allow > changes, e.g. for the first question it is yes, for the others it is > no. And more information for unexperienced packagers to know what is a > "leaf" package and how to determine ABI/API changes would be better. I split that out into a new section with "more likely to grant exception" and "less likely to grant exception". See what you think? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Wed, 22 Sep 2010 20:14:45 +0100 Alex Hudson wrote: > On Wed, 2010-09-22 at 12:35 -0600, Kevin Fenzi wrote: > > Alex Hudson wrote: > > > I think there's one thing missing: some discussion about the > > > guiding principles about where these rules came from. > > > > Well, there is the Boards vision that this came out of: > > > > https://fedoraproject.org/wiki/Stable_release_updates_vision > > Yeah; and I think that's great - I think possibly the Updates Policy > could use some kind of practical view of that or reference to it. A > simple sentence in the intro along the lines of "This update policy is > an attempt to achieve this vision" might be enough - it's almost the > yardstick by which the update policy should be measured. I've added some more to the introduction and pointed to that. Thanks for the suggestion. ...snip... > > Absoletely. Can you think of anything specific to add to the updates > > policy that would express this? We do have a Philosophy section... > > can you re-work that to express this? > > I'll try to have a think about this and propose something. > > I think also there is a flip-side to this which hasn't been considered > so expressly: the update policy is almost a brake on updates, but what > happens when a bad update goes through? I think there ought to be > something in the policy which says "If a bad update gets through, you > either revert it or fix it. The more 'stable' the update should have > been, the stronger the urge should be to revert it.". (By revert, I > mean go to the previous package, but probably with a bumped version - > not some mechanism to pull bad updates). Good idea. I think this might require consensus from fesco, but adding something like that sounds good to me. > And if we're saying that there ought to be that "revert" escape route, > then in the same way we have a Plan B on features pages, that ought to > be another factor maintainers consider: "If this goes wrong and you > need to revert this, is that possible?". If the answer to that > question is "No", i.e. the new version app does some > one-direction-only data conversion when it's run for the first time, > then that ought to be another factor weighing against that update > going through. Good suggestion. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > > `G_IS_OBJECT (object)' failed > > Segmentation fault (core dumped) > > There also seem to be problems with nautilus from GTK+ ABI changes - I > see various warnings along the lines of: > > (nautilus:27082): GLib-GObject-WARNING **: specified class size for type > `EvPropertiesView' is smaller than the parent type's `GtkVBox' class > size > > These indicate a definite need for rebuild, so I'll kick one off now, > and maybe things will be better after that finishes. It's certainly not > worth worrying about anything related to Nautilus until it's rebuild. Turned out to be a bit of a red-herring I was actually testing with LD_LIBRARY_PATH including a fresh-from-git copy of GTK+. Another potential problem is modules in: /usr/lib64/nautilus/extensions-2.0/ That are linking against gtk2 - that will result in gtk2 and gtk3 in the same process, which will do bad things. There are certainly some problems with that in the current Rawhide package set but not sure if that's causing the problem you are seeing or not. Nautilus seem to work fairly well for me with the rebuild and the right LD_LIBRARY_PATH and most of the offending modules removed. (We'll work on rebuilds and checks in Nautilus to deal with the extensions linking against gtk2) - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
On Wed, 22 Sep 2010 16:39:00 -0400 Toshio Kuratomi wrote: > The problem is that we'd want to know what the ramifications of the > update are to the release. What if the fix for the FTBFS causes an > ABI break... but it's also the only way to fix the FTBFS within our > manpower needs? Better to do that before F14 has shipped than be > forced to do that after it has shipped. I can come up with other > scenarios that are similar but they're all just about identifying > what cascading problems could occur up front rather than defering it > to when we have a time-critical update to get out the door. True. So, I guess it gets down to why the thing was FTBFS and what needed to be done to fix it. In the past, all the ones I have had have been minor linking or build options that didn't seem to affect the end package much, but of course there could be other cases. So, yeah, you may be right that we should push these to branched releases as well just to be sure... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 11:19 AM, Owen Taylor wrote: > On Sat, 2010-09-25 at 09:31 -0700, Tom London wrote: >> 1. Nautilus no longer displays the desktop; believe I got some >> indication that this was part of the move to a newer desktop > > Since you aren't actually running the newer desktop (GNOME Shell is > temporarily not working in Rawhide, we'll get it fixed this week, and > the file management isn't fully there yet in any case), you can showing > the desktop back on with: > > gconftool -s -t bool /apps/nautilus/preferences/show_desktop true > > Of course, that once you've set that key you'll no longer get the > default experience. > > (See: > > http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00033.html > > for some discussion of the desktop situation) > >> 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb >> drives, hard drives, etc.). However, the device does appear in >> 'Places', and it mounts if you select it there. > > This is a fairly long-standing bug related to turning off "show_desktop" > - the automounting is part of the Nautilus process, and when not showing > the desktop, Nautilus just exits when there are no windows. > > See: https://bugzilla.gnome.org/show_bug.cgi?id=585545 > > - Owen > Thanks for the update Think I'll wait for the newer gnome-shell. I sort of got hooked on the compiz eye-candy. Any idea if that (e.g., wobbly windows, rotating cube, ...) will be part of the "new gnome-shell experience"? tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, 2010-09-25 at 09:31 -0700, Tom London wrote: > 1. Nautilus no longer displays the desktop; believe I got some > indication that this was part of the move to a newer desktop Since you aren't actually running the newer desktop (GNOME Shell is temporarily not working in Rawhide, we'll get it fixed this week, and the file management isn't fully there yet in any case), you can showing the desktop back on with: gconftool -s -t bool /apps/nautilus/preferences/show_desktop true Of course, that once you've set that key you'll no longer get the default experience. (See: http://mail.gnome.org/archives/desktop-devel-list/2010-September/msg00033.html for some discussion of the desktop situation) > 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb > drives, hard drives, etc.). However, the device does appear in > 'Places', and it mounts if you select it there. This is a fairly long-standing bug related to turning off "show_desktop" - the automounting is part of the Nautilus process, and when not showing the desktop, Nautilus just exits when there are no windows. See: https://bugzilla.gnome.org/show_bug.cgi?id=585545 - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, 2010-09-25 at 17:16 +0100, Paul F. Johnson wrote: > Hi, > > What is going on with Nautilus? It's not been usable for quite a while > now. Most recently, I've had it working by starting it from a terminal > window but now even that has stopped working and is giving me the > following > Gtk-Message: Failed to load module "gail-gnome": libgail-gnome.so: > cannot open shared object file: No such file or directory > > (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to > lookup signal "select" of unloaded type `GtkMenuItem' > > (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: > assertion `signal_id > 0' failed These messages are coming from accessibility support. That's not really at a usable state with GTK+ 3 at the moment, so I'd suggest doing: gconftool-2 -s -t bool /desktop/gnome/interface/accessibility false then log out and log back in. > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > `G_IS_OBJECT (object)' failed > Segmentation fault (core dumped) There also seem to be problems with nautilus from GTK+ ABI changes - I see various warnings along the lines of: (nautilus:27082): GLib-GObject-WARNING **: specified class size for type `EvPropertiesView' is smaller than the parent type's `GtkVBox' class size These indicate a definite need for rebuild, so I'll kick one off now, and maybe things will be better after that finishes. It's certainly not worth worrying about anything related to Nautilus until it's rebuild. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sat, Sep 25, 2010 at 9:16 AM, Paul F. Johnson wrote: > Hi, > > What is going on with Nautilus? It's not been usable for quite a while > now. Most recently, I've had it working by starting it from a terminal > window but now even that has stopped working and is giving me the > following > > Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: > cannot open shared object file: No such file or directory > Gtk-Message: Failed to load module "gail-gnome": libgail-gnome.so: > cannot open shared object file: No such file or directory > > (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to > lookup signal "select" of unloaded type `GtkMenuItem' > > (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: > assertion `signal_id > 0' failed > > (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to > lookup signal "deselect" of unloaded type `GtkMenuItem' > > (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: > assertion `signal_id > 0' failed > Initializing nautilus-gdu extension > > (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion > `G_IS_OBJECT (object)' failed > Segmentation fault (core dumped) > > (this is the same if I use nautilus -n [then double click on a drive > icon] or nautilus with no arguments) > > Any ideas on what is going on? > > I last updated the machine last night and things seem to have gone wrong > since about Tuesday (last update on koji). > > I did think it was related to the gir rebuilds, but that doesn't seem to > be the case. > > HELP > > TTFN > > Paul > > P.S. I have both .so files installed... > -- > Vertraue mir, ich weiss, was ich mache... > I've been running rawhide nautilus for a while (currently nautilus-2.90.1-4.gitf3bbee7.fc15.x86_64), and although there are some 'rough edges', it works well enough for me. Here are some things I've noticed: 1. Nautilus no longer displays the desktop; believe I got some indication that this was part of the move to a newer desktop 2. Nautilus no longer 'auto mounts' removable drives (e.g., thumb drives, hard drives, etc.). However, the device does appear in 'Places', and it mounts if you select it there. 3. Nautilus segfaults trying to open the device's root folder after selecting in 'Places': https://bugzilla.redhat.com/show_bug.cgi?id=636543 . But the device is mounted properly tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Nautilus still no go in rawhide
Hi, What is going on with Nautilus? It's not been usable for quite a while now. Most recently, I've had it working by starting it from a terminal window but now even that has stopped working and is giving me the following Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory Gtk-Message: Failed to load module "gail-gnome": libgail-gnome.so: cannot open shared object file: No such file or directory (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to lookup signal "select" of unloaded type `GtkMenuItem' (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: assertion `signal_id > 0' failed (nautilus:11408): GLib-GObject-WARNING **: gsignal.c:1152: unable to lookup signal "deselect" of unloaded type `GtkMenuItem' (nautilus:11408): GLib-GObject-CRITICAL **: g_signal_add_emission_hook: assertion `signal_id > 0' failed Initializing nautilus-gdu extension (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (core dumped) (this is the same if I use nautilus -n [then double click on a drive icon] or nautilus with no arguments) Any ideas on what is going on? I last updated the machine last night and things seem to have gone wrong since about Tuesday (last update on koji). I did think it was related to the gir rebuilds, but that doesn't seem to be the case. HELP TTFN Paul P.S. I have both .so files installed... -- Vertraue mir, ich weiss, was ich mache... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
Brandon Lozza wrote: > It seems like the policy would kill the use of an upgraded KDE (4.5 to > 4.6) because KDE almost always makes UI changes. The kde-sig asked FESCo to consider up to 1 KDE version upgrade per release, and this was generally well-received during the last FESCo meeting, so no reason to panic. References, http://fedoraproject.org/wiki/SIGs/KDE/Update_policy -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100925 changes
Compose started at Sat Sep 25 13:15:24 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-9.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gnome-python2-evolution-2.31.1-5.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 evolution-sharp-0.21.1-9.fc14.i686 requires libcamel-1.2.so.19 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gnome-python2-evolution-2.31.1-5.fc14.i686 requires libcamel-1.2.so.19 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 matahari-0.0.5-1.fc14.i686 requires libqmf.so.1 mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickCore.so.3 php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickWand.so.3 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_filesystem-mt.so.1.41.0 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_system-mt.so.1.41.0 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_thread-mt.so.1.41.0 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs >= 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, Sep 25, 2010 at 9:13 AM, Till Maas wrote: > On Thu, Sep 23, 2010 at 09:48:34AM -0400, Adam Jackson wrote: > >> Say you ship with 50 bugs in a package. As you update it through the >> lifetime of a release, that number should decrease more or less >> monotonically. The bugs that take longest to fix are presumably the >> hardest ones to fix, and thus the ones that either require significant >> rewrites (and become out of scope for an update release), or won't get >> fixed at all. So it's really just describing what _happens_ naturally >> if you don't rebase all the time. > > The bug number will probably decrease, but this does not meant that the > lifetime of a release is long enough to fix them all or even to find > them all. E.g. if 5 bugs are fixed every month, you will still have the > same rate of updates for 10 months, unless you just delay updates even > if the bugs could already be fixed. And also usually not all bugs are > known when at the beginning of the release. > > Regards > Till > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > It seems like the policy would kill the use of an upgraded KDE (4.5 to 4.6) because KDE almost always makes UI changes. For advocacy reasons I could no longer brag about how Fedora always has the latest upstream KDE. I could no longer tell people Fedora was the best KDE distro either. I'm not trolling, these are valid things I bring up when I try to talk people into trying Fedora who might have been using Mandriva, Kubuntu or openSUSE. Specifically i'm looking at the one example: "Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed." rewrite it for a standard kde update KDE releases a new version (4.6) that adds OpenGL compositing. It also completely updates the user interface to change the way the notification area works. This would be a feature enhancement with a major user experience change, and would not be allowed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Thu, Sep 23, 2010 at 09:48:34AM -0400, Adam Jackson wrote: > Say you ship with 50 bugs in a package. As you update it through the > lifetime of a release, that number should decrease more or less > monotonically. The bugs that take longest to fix are presumably the > hardest ones to fix, and thus the ones that either require significant > rewrites (and become out of scope for an update release), or won't get > fixed at all. So it's really just describing what _happens_ naturally > if you don't rebase all the time. The bug number will probably decrease, but this does not meant that the lifetime of a release is long enough to fix them all or even to find them all. E.g. if 5 bugs are fixed every month, you will still have the same rate of updates for 10 months, unless you just delay updates even if the bugs could already be fixed. And also usually not all bugs are known when at the beginning of the release. Regards Till pgpl3m31XtNZs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100925 changes
Compose started at Sat Sep 25 08:15:25 UTC 2010 Broken deps for x86_64 -- ImageMagick-6.6.4.1-14.fc15.i686 requires libgs.so.8 ImageMagick-6.6.4.1-14.fc15.x86_64 requires libgs.so.8()(64bit) almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) < 0:1.3.0 clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0 clutter-gtkmm-0.9.5-1.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires pkgconfig(clutter-gtk-0.10) >= 0:0.10.2 clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) >= 0:0.10.2 dvisvgm-1.0.3-1.fc15.x86_64 requires libgs.so.8()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-totem-2.31.1-5.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libchamplain-gtk-0.6.1-4.fc14.i686 requires libclutter-gtk-0.10.so.0 libchamplain-gtk-0.6.1-4.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) libchamplain-gtk-devel-0.6.1-4.fc14.i686 requires pkgconfig(clutter-gtk-0.10) libchamplain-gtk-devel-0.6.1-4.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-book-1.2.so.3()(64bit) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-cal-1.2.so.8()(64bit) libspectre-0.2.6-1.fc14.i686 requires libgs.so.8 libspectre-0.2.6-1.fc14.x86_64 requires libgs.so.8()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) meego-panel-devices-0.2.4-2.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) meego-panel-zones-0.2.0-0.1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-app-installer-0.4.0-0.9.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Gtk2-MozEmbed-0.08-7.fc15.x86_64 requires gecko-libs = 0:1.9.3.0 pyclutter-gtk-0.10.0-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc15.noarch r
