Re: Ubuntu moving towards Wayland
On Sat, Nov 06, 2010 at 03:14:57PM +, Pierre Carrier wrote: On Sat, Nov 6, 2010 at 13:51, Camilo Mesias cam...@mesias.co.uk wrote: With virtualization I have more Linux machines than ever (about 50 in active use at last count). All on my local 1GB network. Consequently I use X to them and to other physical machines _all the time_. If there is no way to provide remote access for Weyland based systems (and I hope there will be a way that is more than adequate) then I can see the day when desktop users wanting a high quality experience and server users part company... Am I the only one would wants to scream SPICE since the beginning of this discussion? We could have a virtualization-free userspace SPICE server and I believe that could be an excellent replacement to VNC, with significantly better performance and features (stuff like sound, anyone?). Richard, you're even specifying virtualization! SPICE is already here! AFAIK SPICE is just faster, better VNC with more features. It doesn't allow you to remote a single app, doesn't work transparently through ssh, and doesn't allow multiple servers and clients connecting in ad hoc ways at the same time. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote: Le samedi 06 novembre 2010 à 14:21 +, Richard W.M. Jones a écrit : Why throw away everything just so we can make input better? Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others. And yet despite all this, it's working fine. Really, I have no problem using my keyboard, managing photographs, scrolling through web pages, or anything else people have been talking about. The proposed solution [possibly] omits a vital feature which sets X apart from being just another windowing system, and for me at least it will be far less useful. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libpoppler soname bump in rawhide
Marek Kasik wrote: I plan to rebase poppler in rawhide to poppler-0.15.1. There are some API changes and 1 soname bump of libpoppler.so.8 to libpoppler.so.9. API changes mostly involve addition of new functions (see below). OK, all rebuilds have been done or are still building. 2 notable failures: inkscape: seems related to api change wrt - type change change in struct GfxPatch: GfxColor color[2][2] - ColorValue color[2][2] tracker: failed in (unrelated) evolution plugin -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 06, 2010 at 05:28:08PM +0100, Dennis Jacobfeuerborn wrote: First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there. It's already been done, and the developers have been busily rejecting them out of hand, eg: http://lists.freedesktop.org/archives/wayland-devel/2010-November/28.html [1] http://lists.freedesktop.org/archives/wayland-devel/2010-November/31.html https://groups.google.com/group/wayland-display-server/browse_thread/thread/e7ed0c0118fb31b4?hl=en.# Rich. [1] As an aside, the point the original poster in that thread makes about client-side decorations is very valid. If you've used Windows or OS X at all, you'll have seen how a buggy application can monopolize the display so nothing can be moved or killed or switched. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/6/2010 11:28, Dennis Jacobfeuerborn wrote: As for the if all apps are ported to Wayland I will not be able to use them remotely anymore I think this is bogus. Nowadays virtually all application aren't X application but gtk/qt applications and the toolkits tend to support different backends. So you will be able to use your apps as long as the toolkits support X and I think that's going to be a long time unless Wayland is dramatically successfull. Does this sort of portability make any difference in a distribution where package maintainers make that decision at compilation time? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 6, 2010 at 02:43, Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Nov 06, 2010 at 01:36:43AM +0100, Dennis Jacobfeuerborn wrote: On 11/06/2010 12:21 AM, Richard W.M. Jones wrote: On Fri, Nov 05, 2010 at 03:16:11PM -0400, Bill Nottingham wrote: Richard W.M. Jones (rjo...@redhat.com) said: Has anyone looked into bringing Wayland to Fedora? If not this might be the right time getting involved in the discussion. http://wayland.freedesktop.org/ What's the implication for people who absolutely need to use X applications remotely? Use VNC. (Or your similar protocol of choice.) That's not a serious alternative. From what I've read so far you can run rootless X as a Wayland client so you can just use your remote X apps like you did in the past next to native Wayland apps. Also if there is a real interest in this feature then this could be implemented for Wayland it would just not be part of the core. And what happens when all the apps are native Wayland apps and none of those can be run remotely? If I wanted to step back to the pre-net era, I'd run Windows. Well when the X people say there is a limit to what X can do over a network reasonably and that a different approach is needed then maybe just maybe they know what they are talking about. Jeez. its not like people are taking X away tomorrow. Nor are they saying X is going away just that the monolithic nature it was designed around does not make sense anymore and changes need to be done. But hey.. it is fun to be the guy who yells They will take X away from me when they can pry it from my cold dead hand! I wonder if X doesn't kill people, I do. sounds as good.. nah.. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
fedora 14: pulseaudio eating cpu and memory without reason...
Hi, Even when not playing any audio, pulseaudio uses CPU and memory PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 2257 marius20 0 941m 7524 3188 S 2.9 0.4 14:22.57 chrome 2956 marius20 0 2026m 537m 9612 S 2.9 26.8 27:40.42 java 1500 marius20 0 437m 3100 1768 S 2.0 0.2 14:53.45 pulseaudio There are numerous reports about this http://www.google.com/search?sourceid=chromeie=UTF-8q=pulseaudio+cpu Do you have any suggestions for fixing or replacing it with something else? Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 06, 2010 at 10:57:27AM +, Richard W.M. Jones wrote: We want to ditch extremely useful, ground-breaking features because of tearing when scrolling in a browser window? [I do *not* see any of I actually read it as we want to ditch features that were groundbreaking in 1975 since the limits on technology from back then no longer mandate them and the advances in technology today are not as easily taken advantage of with those considerations. Not saying you're wrong, just offering another viewpoint. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, 2010-11-06 at 15:48 +, Ben Boeckel wrote: Camilo Mesias cam...@mesias.co.uk wrote: [..] As much as I love Nouveau's freeness, last time I checked I couldn't even run gnome shell on it. I was doing that back in November[1]. It depends on your hardware. Works on some cards, doesn't on others. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, 2010-11-06 at 16:00 +, Camilo Mesias wrote: You mention gnome shell but not nouveau, how do you enable the missing 3d support for Nouveau? And does it only work for a subset of hardware? I'd be interested to try it. Lately I just get: Accelerated 3D graphics is not available Desktop effects require hardware 3D support. yum install mesa-dri-drivers-experimental -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Should gpg use alternatives?
Should gpg 1.x be installed as /usr/bin/gpg1, gpg 2.x be installed as /usr/bin/gpg2 (as is already the case), and /usr/bin/gpg replaced with a symlink managed by alternatives? pgpiqSHAQTCkm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Hi, how do you enable the missing 3d support for Nouveau? It came with mesa-dri-drivers-experimental. I just wanted to say thanks, I am running with this now, it seems to be certainly more than adequate ;-) to run gnome shell. No more akmod-nvidia for a while! -Cam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora - Cold Boot Attack
Hi all, I have read some articles about the Cold Boot Attacks and I am wondering whether my Fedora box is protected against such kinds of attack, at least to some extent. I work like an Embedded SW/HW Developer and my experience is that data could remain in the dynamic memory for quite long time, even in the room temperature. I have used it successfully for debugging, when a booting routine after the cold reset copies some parts of memory to another location which could be read lately. It would be usefull to overwrite some parts of memory (keys etc.), before the computer is switched off. So, my question is: Is there already implemented and used some kind of protection? Vaclav M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Multilib issue with hard-coded paths in mash script
Hi, During the F14 release cycle gtk2 was updated from 2.20.x to 2.22.x. During this change gdk-pixbuf2 was split off into a separate package and the location of the gdk-pixbuf loaders has changed from: F13: /usr/lib/gtk-2.0/2.10.0/loaders/ to F14: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders This caused now some strange effects due to the hard-coded paths in the mash script for creating the x86_64 repository: From mash/mash/multilib.py: if fnmatch(dirname, '/usr/lib*/gtk-2.0/*/loaders'): return True So in F13 the mash script picked up all i686 packages which provided gdk-pixbuf loaders. In F14 the script does not pick them up anymore (because of the changed path) and so the i686 versions of some loaders are missing in the x86_64 repository. This has now caused e.g. the following bug https://bugzilla.redhat.com/show_bug.cgi?id=649339 . The whole issue raises now some questions: 1. Specifically with respect to the problem with gdk-pixbuf: Should the gdk-pixbuf loaders be multilib or not? If yes, the mash script must be adjusted. 2. Should the mash script be reviewed whether there are any other hard-coded paths outdated? Should the script even be Fedora release specific? Best regards, Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
proventester needed: libgsf-1.14.18-1.fc13
Dear proventesters, please add karma to https://admin.fedoraproject.org/updates/libgsf-1.14.18-1.fc13 This should be relatively harmless, as there was only one fix in the upstream code since 1.14.17: fix of writing compressed files. Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101107 changes
Compose started at Sun Nov 7 08:15:34 UTC 2010 Broken deps for x86_64 -- abrt-gui-1.1.13-2.fc15.x86_64 requires libnotify.so.1()(64bit) alex-2.3.3-1.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) cabal-install-0.8.2-1.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) claws-mail-plugins-notification-3.7.6-7.fc15.x86_64 requires libnotify.so.1()(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(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 compiz-fusion-extras-0.8.6-1.fc14.x86_64 requires libnotify.so.1()(64bit) db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 deja-dup-15.3-2.fc14.x86_64 requires libnotify.so.1()(64bit) dh-make-0.55-2.fc15.noarch requires debhelper edje-0.9.99.49898-1.fc14.i686 requires libecore_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libembryo-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libevas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libembryo-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) edje-devel-0.9.99.49898-1.fc14.i686 requires pkgconfig(eina-0) edje-devel-0.9.99.49898-1.fc14.x86_64 requires pkgconfig(eina-0) eekboard-0.0.5-3.fc15.x86_64 requires libnotify.so.1()(64bit) efreet-0.5.0.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) efreet-devel-0.5.0.49898-1.fc14.i686 requires pkgconfig(eina-0) efreet-devel-0.5.0.49898-1.fc14.x86_64 requires pkgconfig(eina-0) empathy-2.91.0-4.fc15.x86_64 requires libnotify.so.1()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeconnman-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libehal-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libedbus-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libebluez-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeofono-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_x-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit)
nouveau gnome-shell (was: Re: Ubuntu moving towards Wayland)
On Sat, 2010-11-06 at 16:00 +, Camilo Mesias wrote: You mention gnome shell but not nouveau, how do you enable the missing 3d support for Nouveau? There's an Mesa package labelled experimental you need to install. I don't know what the subset of hardware it works for is, but my Quadro NVS 135M has been running smoothly so far: it's not fast, and the frame rate is not great, but it's out of the box and usable. I blogged about this yesterday, but nouveau has taken serious strides in F14 - I've been using it the past couple of releases, and the progress has been stark. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Unresponsive maintainer ixs alias Andreas Thienemann (fast track?)
Hi everyone, I just noticed that Andreas Thienemann seems to be unresponsive: There are 48 open bugs assigned to him including 3 security bugs: https://bugzilla.redhat.com/buglist.cgi?resolution=---emailtype1=exactquery_format=advancedemailassigned_to1=1bug_status=NEWbug_status=ASSIGNEDbug_status=MODIFIEDbug_status=ON_DEVbug_status=ON_QAbug_status=VERIFIEDbug_status=RELEASE_PENDINGbug_status=POSTproduct=Fedoraproduct=Fedora%20EPELemail1=andreas%40bawue.net They include some bugs that are very old about broken packages: https://bugzilla.redhat.com/show_bug.cgi?id=460557 https://bugzilla.redhat.com/show_bug.cgi?id=445598 https://bugzilla.redhat.com/show_bug.cgi?id=507886 Also there are 28 WONTFIX bugs since 2008-01-01 assigned to him: https://bugzilla.redhat.com/buglist.cgi?resolution=WONTFIXemailtype1=exactchfieldto=Nowemailassigned_to1=1query_format=advancedchfieldfrom=2008-01-01bug_status=CLOSEDproduct=Fedoraproduct=Fedora%20EPELemail1=andreas%40bawue.net This list also includes security bugs. The last build is from 2009-10-21: http://koji.fedoraproject.org/koji/builds?userID=ixs He is the owner of 55 packages: https://admin.fedoraproject.org/pkgdb/users/packages/ixs?acls=owner I did not spot any nonresponsive maintainer procedure contact attemtps, but this looks like a candidate for the fast track procedure: http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#Fast_Track_procedure I CC'ed him on this email. I created a FESCo ticket here: https://fedorahosted.org/fesco/ticket/488 Regards Till pgpwzhE5mOWCM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
proventester needed: libgsf-1.14.18-1.fc13
Dear proventesters, please add karma to https://admin.fedoraproject.org/updates/libgsf-1.14.18-1.fc13 This should be relatively harmless, as there was only one fix in the upstream code since 1.14.17: fix of writing compressed files. Julian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 6, 2010 at 12:41 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote: Le samedi 06 novembre 2010 à 14:21 +, Richard W.M. Jones a écrit : Why throw away everything just so we can make input better? Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others. And yet despite all this, it's working fine. Really, I have no problem using my keyboard, managing photographs, scrolling through web pages, or anything else people have been talking about. The proposed solution [possibly] omits a vital feature which sets X apart from being just another windowing system, and for me at least it will be far less useful. I find the fact that there is this much argumentation against something that: 1) isn't even proposed for Fedora at the moment 2) isn't even complete (or close to) in the distro it _is_ proposed for and 3) none of this discussion is taking place on any list relevant to the actual subject a bit hilarious. I think I'll just start new threads with subjects like Arch Linux moving towards KDE as default or Gentoo moving towards razor package management just to see how much time this community is capable of wasting. It should be lolz. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: fedora 14: pulseaudio eating cpu and memory without reason...
On Sat, Nov 6, 2010 at 3:43 PM, Marius Andreiana wrote: Hi, Even when not playing any audio, pulseaudio uses CPU and memory PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2257 marius 20 0 941m 7524 3188 S 2.9 0.4 14:22.57 chrome 2956 marius 20 0 2026m 537m 9612 S 2.9 26.8 27:40.42 java 1500 marius 20 0 437m 3100 1768 S 2.0 0.2 14:53.45 pulseaudio There are numerous reports about this http://www.google.com/search?sourceid=chromeie=UTF-8q=pulseaudio+cpu Do you have any suggestions for fixing or replacing it with something else? Jack, or even plain Alsa. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On 10-11-06 07:36 PM, Vaclav Mocek wrote: Hi all, I have read some articles about the Cold Boot Attacks and I am wondering whether my Fedora box is protected against such kinds of attack, at least to some extent. I work like an Embedded SW/HW Developer and my experience is that data could remain in the dynamic memory for quite long time, even in the room temperature. I have used it successfully for debugging, when a booting routine after the cold reset copies some parts of memory to another location which could be read lately. It would be usefull to overwrite some parts of memory (keys etc.), before the computer is switched off. So, my question is: Is there already implemented and used some kind of protection? Vaclav M. It's a bit of a tangent, but I think Xen's dom0 kernel does this on boot. If so, perhaps it's code can be adapted? I think it would be a nice (optional?) feature, to be honest. Of course, this doesn't help if power is suddenly cut, but combined with encrypted storage, it would help remove another vector. -- Digimer E-Mail: digi...@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On 11/06/2010 07:39 PM, Richard W.M. Jones wrote: On Sat, Nov 06, 2010 at 05:28:08PM +0100, Dennis Jacobfeuerborn wrote: First I think you should probably head over to the Wayland mailing list and get involved there. That's something I also recommend to Richard because if you want certain features to be present now is a good time to make your voices heard over there. It's already been done, and the developers have been busily rejecting them out of hand, eg: http://lists.freedesktop.org/archives/wayland-devel/2010-November/28.html [1] http://lists.freedesktop.org/archives/wayland-devel/2010-November/31.html https://groups.google.com/group/wayland-display-server/browse_thread/thread/e7ed0c0118fb31b4?hl=en.# Rich. [1] As an aside, the point the original poster in that thread makes about client-side decorations is very valid. If you've used Windows or OS X at all, you'll have seen how a buggy application can monopolize the display so nothing can be moved or killed or switched. So they consider this a layering violation which makes sense given that Wayland has a much smaller scope than X. That doesn't mean you cannot implement remote applications at all it just means you have to implemented in a different way. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On Sun, 07 Nov 2010 00:36:58 +0100, Vaclav Mocek wrote: I have read some articles about the Cold Boot Attacks and I am wondering whether my Fedora box is protected against such kinds of attack, at least to some extent. If you have physical access to the box there is no security left. Attacked can install there a trojan to catch+store boot password, install backdoor into the booted kernel, use SMM (System Management Hook) etc. Attacker can also solder in a sniffer of memory accesses. Other variants also exist. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On Sun, Nov 07, 2010 at 18:44:48 +0100, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Sun, 07 Nov 2010 00:36:58 +0100, Vaclav Mocek wrote: I have read some articles about the Cold Boot Attacks and I am wondering whether my Fedora box is protected against such kinds of attack, at least to some extent. If you have physical access to the box there is no security left. Attacked can install there a trojan to catch+store boot password, install backdoor into the booted kernel, use SMM (System Management Hook) etc. Attacker can also solder in a sniffer of memory accesses. Other variants also exist. Having the laptop stolen, modified, put back and then stolen again later, may not be a threat he is concerned about. His concern seems to be that shutting the machine down may not be good enough to protect against the laptop simply being stolen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, 01.11.10 20:28, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote: Any suggestions? We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them? tmpfs as of now does not support user xattrs. Only SELinux labels are supported. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora - Cold Boot Attack
On Sat, Nov 6, 2010 at 17:36, Vaclav Mocek little@email.cz wrote: Hi all, I have read some articles about the Cold Boot Attacks and I am wondering whether my Fedora box is protected against such kinds of attack, at least to some extent. Ok there are several different cold boot attacks. The one I think you are talking about is the removing memory from the system and reading its contents with a special board. The kernel does not generally provide a defense against that would be encrypting all data in memory. Not sure how feasible it would be... you would also need to make sure the video ram and other somehow supported it. In the end, if someone has physical access to your system, you are not going to be able to completely defend against a cold boot attack. Encrypting the drive and keeping it reasonably secure is about all you can do without having hardware that helps. [Due to the fact that Intel hardware is really still trying to boot an 8088? when it starts up and then become a better computer leaves all kinds of ways for some sort of cold boot attack.] In the end, one would need to a) design the hardware to be more resistant, b) use a cpu/hardware boot sequence that isn't so crufty, and c) still do a good job of keeping the hardware away from the maid. I work like an Embedded SW/HW Developer and my experience is that data could remain in the dynamic memory for quite long time, even in the room temperature. I have used it successfully for debugging, when a booting routine after the cold reset copies some parts of memory to another location which could be read lately. It would be usefull to overwrite some parts of memory (keys etc.), before the computer is switched off. So, my question is: Is there already implemented and used some kind of protection? Vaclav M. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Let us be kind, one to another, for most of us are fighting a hard battle. -- Ian MacLaren -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should gpg use alternatives?
On Sat, Nov 06, 2010 at 05:20:02PM -0400, Sam Varshavchik wrote: Should gpg 1.x be installed as /usr/bin/gpg1, gpg 2.x be installed as /usr/bin/gpg2 (as is already the case), and /usr/bin/gpg replaced with a symlink managed by alternatives? If you check the list archives, this has come up before and the answer was no. gpg1 and gpg2 are intended to provide separate functionality. -Toshio pgpSH8pWWhIkK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Le samedi 06 novembre 2010 à 16:41 +, Richard W.M. Jones a écrit : On Sat, Nov 06, 2010 at 04:52:02PM +0100, Nicolas Mailhot wrote: Le samedi 06 novembre 2010 à 14:21 +, Richard W.M. Jones a écrit : Why throw away everything just so we can make input better? Because those are just the examples I know where X11 has been blocking progress for *years*. I'm sure there are lots of others. And yet despite all this, it's working fine. It is working fine for a don't look there it is broken definition of fine. You don't notice it because you've been formatted not to use the bits where it falls over. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Changes in FAmSCo and why it matters, or how to get stuff.
As you may know, FAmSCo among other things, is responsible for handling a portion of Fedora's discretionary budget.[0],[1]. We typically run under-budget, sometimes by a relatively large amount. FAmSCo recognizes that leaving money on the table every quarter is effectively a lost opportunity. There's also been talk recently of FAmSCo's role changing a bit to deal with more of Fedora's discretionary budget[2],[3], But enough background, my purpose in this message is to let you know that there are resources available to help you 'Get Stuff Done.' If there's something that helps your efforts in Fedora, be that attending a conference like LISA, Guadec, Akademy, or Pycon, or specific pieces of hardware to accomplish something, we want to help make that happen. FAmSCo is actively going to be looking for opportunities to help contributors, but honestly, Fedora's scope and contributor base is so large that we might never come across many of those opportunities without your help. So how do you get access to these resources? It's relatively easy - you can speak to a FAmSCo member, or preferably, create a ticket in FAmSCo's trac instance[4]. You may also want to review the reimbursement guidelines[5] If you have any questions, please don't hesitate to ask me or any other FAmSCo member. Thanks, David Nalley on behalf of FAmSCo [0] http://fedoraproject.org/wiki/FAmSCo_budget [1] http://fedoraproject.org/wiki/Accounting [2] http://lists.fedoraproject.org/pipermail/advisory-board/2010-August/009047.html [3] http://lists.fedoraproject.org/pipermail/famsco/2010-November/000402.html [4] https://fedorahosted.org/famsco/ [5] https://fedoraproject.org/wiki/Reimbursements -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why should I ever bother filing another bug?
https://bugzilla.redhat.com/show_bug.cgi?id=623742 was duped to newer bug https://bugzilla.redhat.com/show_bug.cgi?id=624297 The older: 1-began life with equivalent summary: system-config-display fails 2-contains same comment 0 information as the latter 3-was directed to be filed by triagers on IRC 4-has 48 CCs If bug fixers plan to only fix bugs they themselves file or randomly choose to attach patches to, there's no need for anyone else to file bugs, as the fixers obviously can't be bothered to see what bugs already have been filed. They might as well be the only testers too. If I was a regular triager in Redhat's Bugzilla, this would put an end to it. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why should I ever bother filing another bug?
On 10-11-07 07:00 PM, Felix Miata wrote: https://bugzilla.redhat.com/show_bug.cgi?id=623742 was duped to newer bug https://bugzilla.redhat.com/show_bug.cgi?id=624297 The older: 1-began life with equivalent summary: system-config-display fails 2-contains same comment 0 information as the latter 3-was directed to be filed by triagers on IRC 4-has 48 CCs If bug fixers plan to only fix bugs they themselves file or randomly choose to attach patches to, there's no need for anyone else to file bugs, as the fixers obviously can't be bothered to see what bugs already have been filed. They might as well be the only testers too. If I was a regular triager in Redhat's Bugzilla, this would put an end to it. I've personally filed a good number of bugs that have, in fact, been resolved and closed. I've also posted bugs that have never been acted on. Generally, the more detailed your bug is, specifically in regards to how to reproduce it, the more likely it is that it will be acted on. I suspect that most of the bugs that are submitted by redhat folks themselves get dealt with because they know what other developers want and need in a bug. Try popping by IRC and asking why a particular bug hasn't been acted on. If it's a lack of time, then there you go. If it's a lack of information though, then someone might be able to help guide you as to what else is needed. You can also reply to your own bugs asking for follow-up. Regardless, I am certain that the developers appreciate people who attempt to submit bugs more than users who don't even bother. -- Digimer E-Mail: digi...@alteeve.com AN!Whitepapers: http://alteeve.com Node Assassin: http://nodeassassin.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101107 changes
alex-2.3.3-1.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) : ghc-Boolean-0.0.1-2.fc15.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) : : ghc-zlib-0.5.2.0-4.fc14.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) : xmobar-0.11.1-4.fc15.x86_64 requires libHSffi-ghc6.12.3.so()(64bit) Sorry these should be fixed in ghc-6.12.3-9.fc15 building now in koji. Jens -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 596103] perl-Net-Patricia-1.18 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=596103 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-11-06 19:42:11 EDT --- perl-Net-Patricia-1.18-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-Patricia-1.18_01.tar.gz uploaded to lookaside cache by philipp
A file has been added to the lookaside cache for perl-Net-Patricia: 322326acedb249df29c4f3605dbb77f2 Net-Patricia-1.18_01.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia] Updating to maintenance release: bug in AFINET6 version of add() method.
commit 7db7141d6e0b1cf5b43cf17fbe27dece9f74068b
Author: Philip Prindeville phil...@fedoraproject.org
Date: Sun Nov 7 23:30:20 2010 -0700
Updating to maintenance release: bug in AFINET6 version of add() method.
.gitignore |1 +
perl-Net-Patricia.spec |8 ++--
sources|2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a87cd0e..58d5de2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Net-Patricia-1.17_01.tar.gz
/Net-Patricia-1.18.tar.gz
+/Net-Patricia-1.18_01.tar.gz
diff --git a/perl-Net-Patricia.spec b/perl-Net-Patricia.spec
index 4c4162e..1ae9941 100644
--- a/perl-Net-Patricia.spec
+++ b/perl-Net-Patricia.spec
@@ -1,6 +1,6 @@
Name: perl-Net-Patricia
-Version:1.18
-Release:1%{?dist}
+Version:1.18_01
+Release:2%{?dist}
Summary:Patricia Trie perl module for fast IP address lookups
License:Distributable, see COPYING
Group: Development/Libraries
@@ -61,6 +61,10 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Sun Nov 7 2010 Philip Prindeville phil...@fedoraproject.org - 1.18_01-01
+- new upstream version, maintenance fix
+ - bug in AFINET6 version of add() method.
+
* Tue Oct 26 2010 Philip Prindeville phil...@fedoraproject.org - 1.18-1
- new upstream version, official release
diff --git a/sources b/sources
index 4ecdafb..ac7e48d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-26f808adb9c7a3a7904d60caf2845de4 Net-Patricia-1.18.tar.gz
+322326acedb249df29c4f3605dbb77f2 Net-Patricia-1.18_01.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia/f14/master: 2/2] Merge branch 'master' into f14
commit 618acad14f35c97e727a0d4285180c085dbf2f48 Merge: 61510be 7db7141 Author: Philip Prindeville phil...@fedoraproject.org Date: Sun Nov 7 23:33:06 2010 -0700 Merge branch 'master' into f14 .gitignore |1 + perl-Net-Patricia.spec |8 ++-- sources|2 +- 3 files changed, 8 insertions(+), 3 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-Patricia/f13/master] Updating to maintenance release: bug in AFINET6 version of add() method.
Summary of changes: 7db7141... Updating to maintenance release: bug in AFINET6 version of (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
