Re: How to calculate priority for missing tests or %check
On 02/28/2014 09:54 PM, David Cantrell wrote: On Fri, Feb 28, 2014 at 11:24:48AM -0800, Adam Williamson wrote: On Fri, 2014-02-28 at 15:56 +0200, Alexander Todorov wrote: I'm not sure what purpose does the URL field serve nowadays but it looks like it can be removed from the spec file (and RPM for that matter)! No, please. It could be made *optional*. But there are certainly cases where the upstream is non-discoverable - the generic-release one is a fun one, for instance. There are cases where a project has forked, and Google does not make it particularly obvious which side of the fork is which. It's not a useless field. I'd vote for optional, but there are plenty of other useless fields in spec files. Group, for instance. Considering we don't even use those groupings. URL is and has always been optional. Group used to be mandatory but has been optional for about five years by now. Fedora policies could of course differ with the technical side. And FWIW no, I dont follow the there are some packages with incorrect URL, thus the field must be useless and should be removed logic here. Upstream project website does not change twice a week, more like perhaps twice a decade if even that. If the package maintainers role is not to save all the users from the trouble of doing the same job, then why are we packaging stuff in the first place. Just google it up! - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: errors upgrading to 2
On 06/09/2013 09:42 PM, Richard Vickery wrote: In the middle of updating , I got these; how important are they? and,I supopose, is the command to recover db_runrecovery? error: rpmdb: BDB0113 Thread/process 3820/139765024729088 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4155/139803070191616 failed: BDB1507 Thread died in Berkeley DB library 28 kB/s | 15 MB 01:57:16 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4198/140301288781824 failed: BDB1507 Thread died in Berkeley DB library 20 kB/s | 17 MB 02:38:16 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4438/140296451778560 failed: BDB1507 Thread died in Berkeley DB library8.0 kB/s | 86 MB 04:15:19 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4526/140586095818752 failed: BDB1507 Thread died in Berkeley DB library109 kB/s | 101 MB 00:16:13 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4656/139997326555136 failed: BDB1507 Thread died in Berkeley DB library311 kB/s | 114 MB 00:05:00 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4689/140320299190272 failed: BDB1507 Thread died in Berkeley DB library492 kB/s | 122 MB 00:02:54 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in error: rpmdb: BDB0113 Thread/process 4733/140155315288064 failed: BDB1507 Thread died in Berkeley DB library325 kB/s | 138 MB 00:03:34 ETA error: db5 error(-30973) from dbenv-failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in Thanks for the feedback, if any? Should I even reboot the computer before I correct it? If the error went away by itself and the upgrade actually proceeded, you can basically ignore it. Otherwise 'rm -f /var/lib/rpm/__db*' is needed, 'rpm --rebuilddb' isn't normally needed but shouldn't hurt either. The problem is old race condition(s) in rpm and/or Berkeley DB, which the parallel deltarpm processing exposes, should be fixed in rpm = 4.11.0.1-2.fc19. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RAWHIDE USERS: BEWARE RPM 4.11.0-0.beta1.2.fc19!
Apologies for shouting but we have a genuine, rare, rpmdb-eating bug (shade of dark paperbag) at hand: DO NOT UPGRADE TO rpm-4.11.0-0.beta1.2.fc19! The buggy version is expected to appear in todays rawhide-push. I've built a new version where the broken %ghost-related patch is reverted but there's a day-long danger-zone before the new build will be pushed. It's best just to avoid upgrading to the buggy rpm version at all, but if you have already happened to update to it one way or the other, DONT PANIC but BACK UP /var/lib/rpm/ before anything else. Merely upgrading to that version wont kill your rpmdb, but on the next update of rpm itself, it will COMPLETELY ERASE /var/lib/rpm/ contents. Recovering isn't exactly hard if you have an up-to-date backup, but otherwise... - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: An arbitrarily sized /tmp does not fit all
On 12/20/2012 11:17 PM, Matthew Miller wrote: On Thu, Dec 20, 2012 at 01:03:37PM -0800, Chuck Forsberg WA7KGX N2469R wrote: For whatever reason Anaconda generates a separate file system for /tmp using an arbitrary size. One one machine it is about 4GB, causing Brasero to fail on larger jobs. Meanwhile there is some 30GB unused in the root filesystem. If /tmp is no longer part of / then its size should be easily adjustable. Check the filesystem -- it's in RAM by default using tmpfs, and tmpfs defaults to a size of half of physical ram. To disable and go back to haivng it be part of /, sudo systemctl mask tmp.mount To change the limit while leaving it in-ram, I assume you'd put the desired size in the Options line in the systemd tmp.mount file, but there may be a better way. I believe the argument is that if Brasero needs more space, /var/tmp would be a better place. This is a fine example of what a facepalm (to put it mildly) the whole /tmp-on-tmpfs is, really... - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is RPM now stricter about checking for file conflicts?
On 10/27/2012 09:41 PM, Bruno Wolff III wrote: On Sun, Oct 28, 2012 at 00:45:33 +0700, Michel Alexandre Salim sali...@fedoraproject.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ever since I started tracking Fedora 18, Google Music Manager is no longer installable, and now Oracle's Virtual Box cannot be installed either (both from upstream Yum repositories). https://bugzilla.redhat.com/show_bug.cgi?id=870655 In both cases, RPM and yum aborts with file conflicts -- /lib/modules for VirtualBox and /usr/bin for google-musicmanager. It is stricter for F18 or F19, but I am only aware of checks for meta data (timestamps I think) being stricter. I don't know if that is what Just FWIW, timestamps do not and in reality, can never cause a conflict, otherwise sharing (generated) content between eg multilib packages would be impossible in practise. you are seeing though. I saw some packages that had conflicts on one fedora release not have them on another, even though it was the same version (there hadn't been a build for the newer release). I don't remember if the difference was between F17 and F18 or F18 and F19 though. The exact difference between rpm = 4.10 (ie Fedora = 18) and older is that differing file/directory permissions (mode, user- and groupname) are considered a conflict now. This is how it always should've been, but the change is disruptive enough (as witnessed here) that existing Fedora etc releases are better left alone. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: yum update failed today with....
On 04/25/2012 07:45 PM, Chris Adams wrote: Once upon a time, Kevin Martinktm...@gmail.com said: Transaction Check Error: file /usr/bin from install of google-chrome-unstable-20.0.1115.1-133713.x86_64 conflicts with file from package filesystem-3.1-1.fc18.x86_64 It looks like a bunch of the common directories have been changed to read-only in the filesystem package (haven't seen any notice/discussion about that, but maybe I missed it). The permission difference might've been there forever, rpm has only very recently (in rawhide) started to raise file conflicts when user/group/mode differences. The other issue would be: why is google-chrome-unstable (wherever you are getting that from) packaing the /usr/bin directory? It shouldn't do that. Yup, its a packaging bug in google-chrome. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: big initial login delay?
On 09/27/2011 06:58 AM, Joachim Backes wrote: On 09/26/2011 08:21 PM, Tom Horsley wrote: I've been noticing long delays when logging in after booting to my f16 partition. I just tried an experiment. If I boot the system, and login as soon as the KDM prompt appears, there is a 20 or 30 second delay between hitting return in the login screen and getting the gnome-shell display to appear. I have the same effect! If I boot the system then wait 20 or 30 seconds after the login prompt to type my password, then there is only a 2 or 3 second delay for the gnome-shell to appear. Same! Anyone know what is going on between the time it pretends I can login and the time a login will actually finish? I remember that in the early beginnings of F15, there had been a similar effect, but don't remember the BZ. 30s delay in login sounds indeed a whole lot like the one in pre-F15, that one was caused by incorrect DBUS argument type in at-spi2-core. The funny thing with that was that wasn't actually the login that was hanging, it was the session where GDM login screen runs whose logout was taking ages. For reference, here's the bug: https://bugzilla.redhat.com/show_bug.cgi?id=691995. - Panu - -- 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 08/24/2011 08:11 PM, seth vidal wrote: On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote: On Wed, 24 Aug 2011 17:26:44 +0100 Richard Hughes wrote: I'm seriously wondering if multilib is worth all this hassle... Oh I've never wondered that: It has clearly never been a good idea. Starting with the total lack of documentation about how the heck it actually works when (for instance) multilib rpms both contain /usr/bin binaries of the same name and going through all the problems it causes with updates (like these). It is documented it is just confusing When you have two pkgs sharing the same binary path - the pkg in the preferred/compat arch for that platform has its files installed. Except when you install them in the wrong order - and then rpm will cough out a conflict. This, I think, has been fixed in more recent changes but I'm not 100% certain of that. The conflict behavior should be consistent regardless of the order since rpm = 4.6.0, ie since F10. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Broken dependencies with Fedora 15 + updates-testing - 2011-04-13
On 04/13/2011 12:19 PM, Rahul Sundaram wrote: On 04/13/2011 02:42 PM, Michael Schwendt wrote: erlang-js-0.5.0-2.fc15.i686 requires libjs.so.1 gxine-0.5.905-5.fc15.i686 requires libjs.so.1 jeuclid-fop-3.1.3-13.fc15.noarch requires fop = 0:0.95 mediatomb-0.12.1-9.fc15.i686 requires libjs.so.1 meego-panel-status-0.3.2-2.fc15.i686 requires libchamplain-0.8.so.1 mongodb-1.7.5-5.fc15.i686 requires libjs.so.1 mongodb-server-1.7.5-5.fc15.i686 requires libjs.so.1 What changed here that broken all these packages? js library apparently changed soname: [root@turre ~]# repoquery --provides js-1.8.5-3.fc15.x86_64 js = 1:1.8.5-3.fc15 js(x86-64) = 1:1.8.5-3.fc15 libjs = 1.8.5-3.fc15 libmozjs185.so.1.0()(64bit) [root@turre ~]# repoquery --provides js-1.70-13.fc15.x86_64 js = 1.70-13.fc15 js(x86-64) = 1.70-13.fc15 libjs = 1.70-13.fc15 libjs.so.1()(64bit) Whether that's intentional or not I dunno... - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: since last update system does not boot any more
On 03/31/2011 07:51 PM, cornel panceac wrote: 2011/3/31 Scott Robbins scot...@nyc.rr.com mailto:scot...@nyc.rr.com Yet another reason setting grub's timeout to 0 was a very bad idea, especially in VMs. indeed, i had to boot another operating system to increase the timeout so that i can change the kernel line when needed Holding left shift during early boot used to bring up the grub menu, timeout or not. Doesn't seem to work in F15 anymore, although having swithed to a usb-keyboard might have something to do with it. In any case getting the system to boot to single-user equivalent to workaround this systemd/selinux issue was unnecessarily painful. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: since last update system does not boot any more
On 03/31/2011 10:40 PM, Adam Pribyl wrote: On Thu, 31 Mar 2011, Panu Matilainen wrote: On 03/31/2011 07:51 PM, cornel panceac wrote: 2011/3/31 Scott Robbinsscot...@nyc.rr.commailto:scot...@nyc.rr.com Yet another reason setting grub's timeout to 0 was a very bad idea, especially in VMs. indeed, i had to boot another operating system to increase the timeout so that i can change the kernel line when needed Holding left shift during early boot used to bring up the grub menu, timeout or not. Doesn't seem to work in F15 anymore, although having swithed to a usb-keyboard might have something to do with it. In any case getting the system to boot to single-user equivalent to workaround this systemd/selinux issue was unnecessarily painful. Did you found any way how to force systemd to boot to single-user? So far my installation of F15 with systemd has only one runlevel, I can not switch it - nor with grub option, neither with inittab or init command. The good old single keyword on the kernel line is what I used and worked fine (it might be just an alias for something else in systemd, I dunno). - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Extremly long login time in F15?
On 03/30/2011 08:07 AM, Joachim Backes wrote: Hi, I'm running F15 with gnome-shell. Having the following effect: after having entered the login password, it takes about 10-15 secs until the session is running and the gnome-shell panel appears at the desktop's top. For me, that extreme long: I have a dual core Intel CPU, both with 1.8 Ghz, and 2 Gigs of mem. Somebody can explain this effect? I'm seeing this too, both in Gnome 3 and XFCE sessions (where especially the latter should fire up in a blink of an eye), so it's something else than gnome-shell as such. Haven't got around to look into it (yet) though. Oh and no network filesystems involved here either. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Extremly long login time in F15?
On 03/30/2011 10:22 AM, Joachim Backes wrote: On 03/30/2011 09:14 AM, Panu Matilainen wrote: On 03/30/2011 08:07 AM, Joachim Backes wrote: Hi, I'm running F15 with gnome-shell. Having the following effect: after having entered the login password, it takes about 10-15 secs until the session is running and the gnome-shell panel appears at the desktop's top. For me, that extreme long: I have a dual core Intel CPU, both with 1.8 Ghz, and 2 Gigs of mem. Somebody can explain this effect? I'm seeing this too, both in Gnome 3 and XFCE sessions (where especially the latter should fire up in a blink of an eye), so it's something else than gnome-shell as such. Haven't got around to look into it (yet) though. Oh and no network filesystems involved here either. - Panu - Hi Panu, I took a look in /var/log/messages, and there is a time leap of 30 secs between Mar 30 08:57:03 . gdm-simple-greeter[6636]: DEBUG(+): GdmGreeterSession: Disposing greeter_session and Mar 30 08:57:33 . gdm-simple-slave[6573]: DEBUG(+): GdmCommon: process (pid:6597) done (status:0) Do you see similar things? Yes, very much the same, there's a 30 sec pause in the log: [...] Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Stopping welcome_session Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: sending signal 15 to process 2184 Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Waiting on process 2184 Mar 30 10:45:48 turre gnome-session[2184]: WARNING: Invalid method call: Argument 0 is specified to be of type boolean, but is actually of type uint32#012 Mar 30 10:45:50 turre gnome-session[2184]: WARNING: Client '/org/gnome/SessionManager/Client2' failed to reply before timeout Mar 30 10:45:50 turre gnome-session[2184]: WARNING: Invalid method call: Argument 0 is specified to be of type boolean, but is actually of type uint32#012 Mar 30 10:45:50 turre gdm-simple-greeter[2219]: DEBUG(+): GdmGreeterSession: Disposing greeter_session Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: process (pid:2184) done (status:0) Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: WelcomeSession died Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: De-registering session from ConsoleKit Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Stopping D-Bus daemon Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: sending signal 15 to process -2182 Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GreeterServer: Stopping greeter server... [...] So quite apparently something is misfiring and there's a 30sec timeout on something, somewhere... Also I /think/ this didn't happen in F15-alpha originally when I installed it, but I could easily be wrong on that (too many things going on for the poor mind to keep up :) - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Extremly long login time in F15?
On 03/30/2011 11:05 AM, Joachim Backes wrote: On 03/30/2011 10:02 AM, Panu Matilainen wrote: On 03/30/2011 10:22 AM, Joachim Backes wrote: On 03/30/2011 09:14 AM, Panu Matilainen wrote: On 03/30/2011 08:07 AM, Joachim Backes wrote: Hi, I'm running F15 with gnome-shell. Having the following effect: after having entered the login password, it takes about 10-15 secs until the session is running and the gnome-shell panel appears at the desktop's top. For me, that extreme long: I have a dual core Intel CPU, both with 1.8 Ghz, and 2 Gigs of mem. Somebody can explain this effect? I'm seeing this too, both in Gnome 3 and XFCE sessions (where especially the latter should fire up in a blink of an eye), so it's something else than gnome-shell as such. Haven't got around to look into it (yet) though. Oh and no network filesystems involved here either. - Panu - Hi Panu, I took a look in /var/log/messages, and there is a time leap of 30 secs between Mar 30 08:57:03 . gdm-simple-greeter[6636]: DEBUG(+): GdmGreeterSession: Disposing greeter_session and Mar 30 08:57:33 . gdm-simple-slave[6573]: DEBUG(+): GdmCommon: process (pid:6597) done (status:0) Do you see similar things? Yes, very much the same, there's a 30 sec pause in the log: [...] Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Stopping welcome_session Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: sending signal 15 to process 2184 Mar 30 10:45:48 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Waiting on process 2184 Mar 30 10:45:48 turre gnome-session[2184]: WARNING: Invalid method call: Argument 0 is specified to be of type boolean, but is actually of type uint32#012 Mar 30 10:45:50 turre gnome-session[2184]: WARNING: Client '/org/gnome/SessionManager/Client2' failed to reply before timeout Mar 30 10:45:50 turre gnome-session[2184]: WARNING: Invalid method call: Argument 0 is specified to be of type boolean, but is actually of type uint32#012 Mar 30 10:45:50 turre gdm-simple-greeter[2219]: DEBUG(+): GdmGreeterSession: Disposing greeter_session Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: process (pid:2184) done (status:0) Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: WelcomeSession died Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: De-registering session from ConsoleKit Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmWelcomeSession: Stopping D-Bus daemon Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GdmCommon: sending signal 15 to process -2182 Mar 30 10:46:20 turre gdm-simple-slave[2160]: DEBUG(+): GreeterServer: Stopping greeter server... [...] So quite apparently something is misfiring and there's a 30sec timeout on something, somewhere... Also I /think/ this didn't happen in F15-alpha originally when I installed it, Hi Panu, I can confirm this. This behaviour appeared after some updates. I don't know what updates are the culprit :-( Turns out the bug is in at-spi2-core, exposed by a change in the way gdm runs its login-screen gnome-session. Was fun to dig up :) For the impatient, 'yum remove at-spi2*' should do the trick until an update is built for https://bugzilla.redhat.com/show_bug.cgi?id=691995. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Running nautilus from Alt+F2 dialog is invoking nautilus twice
On 03/17/2011 02:38 PM, James Laska wrote: On Thu, 2011-03-17 at 16:27 +0530, Pratyush Sahay wrote: Hello all, Trying to run nautilus through Run Application dialog box (ALT+F2) is invoking nautilus twice.. Screenshot links given below : http://goo.gl/LnDTN : Running Alt+F2 and typing nautilus http://goo.gl/ruS68 : Taken immediately after invoking the above If a bug hasn't already been filed (I'm not seeing one, atm) ... please do file a bug against nautilus. Actually it's not specific to nautilus. Anything you launch from the alt-f2 dialog gets invoked twice, be it gnome-terminal, xchat, firefox... - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F15 ping must run as root?
On 03/14/2011 01:49 PM, Jon Stanley wrote: On Mon, Mar 14, 2011 at 7:40 AM, Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: I saw that in F15 ping must be started with root rights, otherwhise I get: ping: icmp open socket: Operation not permitted Ping has *always* needed root privs, it generally gets them by being suid root. Don't have an F15 box here handy to look, but I'm suspecting that either it somehow isn't suid root, or something else is preventing suid from working (no suid mount option? SELinux?) In F15, capabilities are used instead of suid root (see http://fedoraproject.org/wiki/Features/RemoveSETUID): [pmatilai@turre ~]$ ls -l /bin/ping -rwxr-xr-x. 1 root root 40840 Feb 9 18:00 /bin/ping [pmatilai@turre ~]$ getcap /bin/ping /bin/ping = cap_net_raw+ep As for the actual problem: are you using a custom-built kernel? That's one possible reason for lacking capability support. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: gnome-shell???
On 02/28/2011 08:25 AM, Adam Williamson wrote: On Sun, 2011-02-27 at 23:06 -0600, Jason D. Clinton wrote: , running 'startx' from a vt just gives me a blank background. I'm posting this from Xfce. Don't know the root cause but using the fallback force method posted by mclasen will get you in to fallback mode until it's fixed. The root cause turned out to be at-spi2 breakage. Again. I don't want this to come across the wrong way, but this: [...] really doesn't make me happy. See caillon's comment starting Note that in order to get things working, one needs to disable a11y - which makes it clear that he knows, unless you manually disable a feature by using an arcane command or by removing a package, GNOME will fail to run at all...yet he gives the update +1 karma? This really isn't how the update approval system is supposed to work. If you (corporate 'you', Fedora desktop team) know about such a critical bug, you should fix it and edit the update. Unless this gets fixed soon, we are in a state where anyone who installs the Alpha and does an update will find their system apparently utterly broken (it boots to a crashing gdm and if you boot to 'runlevel 3' and do startx, GNOME fails to run). I know we're in early pre-release state and we don't guarantee anything, but it doesn't really excuse submitting and then pushing to 'stable' code you know to be badly broken. I upgraded my home box to F15-pre-alpha over the weekend, first with yum and when the result was a utterly broken heap thought oh well it's the unsupported way, then reinstalled from scratch and got the very same broken heap... and couldn't help thinking we're about to release THIS?? Anaconda seems to default to enabling updates-testing, so unless the testing-repo is in a reasonable shape at the time of alpha release there's going to be a lot of grumpy testers. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
