Re: Empathy default in F12?
2009/8/16 Christoph Höger > Am Sonntag, den 16.08.2009, 13:10 +0530 schrieb Rahul Sundaram: > > On 08/16/2009 01:05 PM, Gregory Maxwell wrote: > > > The F12 feature still indicates the switch to Empathy as a default IM > > > client in Fedora. > > > > > > However, the talk page for the feature > > > (https://fedoraproject.org/wiki/Talk:Features/Empathy) raises material > > > concerns that the switch to Empathy would result in an insufficiently > > > justified loss of functionality. > > > > > > Where does this currently stand? > > > > My understanding is that Empathy is still planned to be the default. > > What specific concerns do you have? > > Well on fedora 10 it cannot connect to irc. Which makes it pretty > unusable. Same for Fedora 11, as far as I could tell. > > > -- > fedora-devel-list mailing list > fedora-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A question about allow_unconfined_mmap_low in f11 amd selinux
On Mon, Nov 9, 2009 at 2:40 PM, Mike Cloaked wrote: > Eric Paris redhat.com> writes: > >> > I have Crossover installed and not wine, and just checked: >> > [mike home1 ~]$ cat /proc/sys/vm/mmap_min_addr >> > 65536 >> > >> > This is an f11 box. I also set the boolean by doing >> > # setsebool -P allow_unconfined_mmap_low 1 >> >> Bad news! For maximum protection would want that bool off. You do not >> want to ALLOW unconfined to mmap low memory. >> >> -Eric > > Many thanks Eric - I just tried unsetting the boolean - > # setsebool -P allow_unconfined_mmap_low 0 > > Excel and Word 2003 still run in Crossover after resetting it without AVCs > popping up - I will unset it in the other machines where I have this also - > I guess selinux policy may have changed so that setting it as I did originally > is no longer necessary. Really? For me there is no "allow_unconfined_mmap_low" at all and I'm definitely still getting the error with any Wine application with mmap_low_allowed set to 0. selinux-policy-3.6.32-41.fc12.noarch -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 10:36 AM, David Zeuthen wrote: > (I'm not subscribed to fedora-devel-list so if you expect an answer > please Cc me) > > On Tue, 2009-11-17 at 09:52 -0500, Chris Ball wrote: >> * Ray says not to invent a new system-config-blah, and instead to talk >> with davidz about Palimpsest. David, what do you think? > > Yep, we're planning to add support to DeviceKit-disks for exposing the > (privileged) operations that btrfs may expose (locked down by polkit, > etc etc). There are also plans to expose these operations in the UI in > Palimpsest and/or Nautilus. I don't think snapshots is going to have any > Palimpsest UI (it belongs in Nautilus I think) but the multi-disk stuff > definitely will. > Talking about sliders and various btrfs bits in Nautilus, I would just like to point out that there are other desktops and file managers to consider. It should be possible to perform the same operations via GUI in KDE or xfce. Whether this means keeping stuff in a seperate, desktop agnostic, application (like a system-config or Palimpset) or making changes to Dolphin, etc as well I don't know. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
> We've gotten enough feedback. We don't need 300 more people giving the same > arguments over and over or empty +1s or votes. Please relax and let the > developer handle it, followed by fesco. > I'm on Fedora largely for the security policy (best SELinux implementation available, for example), but I can't be the only one seriously considering a switch because of this. Not because the mistake was made, but because I actually watched Fedora developers try to defend it when the only response should have been an immediate fix followed by revocation of all privileges of the package maintainer until his permanent status could be decided. The total turn around since the initial discovery will be three days come tomorrow's FESCo meeting, plus whatever time it takes after that to get a fix pushed out. That's completely unacceptable. I think an emergency meeting would have been more than appropriate given the situation and general reaction here. In short: If it hasn't been handled yet, you apparently haven't had nearly enough feedback. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Vote for the bug (was Re: Local users get to play root?)
> Fedora users -- keep on voting, that is why the feature exists. > Seconded. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Nov 19, 2009 at 02:27:32AM +0100, Kevin Kofler wrote: > Gregory Maxwell wrote: > > I noticed that http://fedoraproject.org/get-fedora appears to be > > strongly promoting i386 Fedora over x86_64. Is this intentional or an > > oversight? > > IMHO, the right solution is to make the 64-bit edition the default download > and to work on making the error message people get when trying to install it > on a 32-bit machine nicer: "We're sorry, but your computer is too old to > install this 64-bit version of Fedora. Please download the legacy 32-bit > edition instead." This is not the right solution. For much of the world, the time it takes to download an ISO is meaningful. As much as I would like to see 64bit as the default, it just isn't possible. What would make more sense is having the defaults state more clearly that they are the 32bit version. Perhaps make the 64bit version more prominent than it is now. Fedora has been available for x86_64 for 5.5 years now, and a large portion of the hardware out there is 64bit capable. Leave the defaults as 32bit so that people who don't know what they have will get an ISO that works, but make it clear that 64bit versions are available with something visible on the main page. People who don't know what it is won't bother, people who do will not have to dig to find it. Justin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposed F13 feature: drop separate updates repository
On Wed, Dec 02, 2009 at 02:39:30PM +, Matthew Booth wrote: > The separate updates directory has been a pain for as long as I've been > using RHL/Fedora Core/Fedora. It means you have two places to look when > searching for packages manually, and twice as much to configure when you're > configuring yum. It has never benefitted me, or anybody I know, but it has > caught me out on any number of occasions. What's more, nobody really seems > to know why it's like that: it seems it's always been that way, and nobody > ever bother to fix it. > The only downside to merging updates into the main repository is that network installs from the repository will no longer install the "release" they will install the updated release. QA that goes into that first impression is no longer there, and your installs are not repeatable because installing system A on one day and system B on another could end up with different versions of packages. Of course you can always install from the ISOs to avoid these problems. As things are, you have the choice of the "release" as it was, or the updated release at install time. I am not saying that this is a bad idea, in fact I rather like it, but there are things to consider. Justin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Thu, Dec 10, 2009 at 12:20:28PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 09 December 2009 at 22:11, Kevin Kofler wrote: > > Dominik 'Rathann' Mierzejewski wrote: > > > Actually, x86_64 is an AMD invention (originally called AMD64) > > > and is called EM64T by Intel. The only "Intel 64" I can think of > > > is IA64, i.e. Itanium (called "Itanic" by some). > > > > EM64T was renamed to Intel 64 eons ago. > > Call me a dinosaur, then. ;) > I stand corrected. > Easy mistake to make considering it started as CT, then was IA-32e, then EM64T, and finally Intel 64. All of them refer to the same thing at some point. Justin -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
