Daniel J Walsh dwalsh at redhat.com writes:
definitely still getting the error with any Wine application with
mmap_low_allowed set to 0.
selinux-policy-3.6.32-41.fc12.noarch
The name has changed between RHEL5 - allow_unconfined_mmap_low
and F12 - mmap_low_allowed
The meaning
Daniel J Walsh dwalsh at redhat.com writes:
The name has changed between RHEL5 - allow_unconfined_mmap_low and F12 -
mmap_low_allowed
The meaning has also changed
in RHEL5
unconfined domains are allowed to mmap_low if the boolean is set. vbetool
and wine are allowed whether or
Mike Cloaked mike.cloaked at gmail.com writes:
Daniel J Walsh dwalsh at redhat.com writes:
On 11/04/2009 10:23 AM, mike cloaked wrote:
By moving forward do you mean that one can, in f11, reset the
original boolean and set boolean mmap_low_allowed instead, in a
forthcoming
Daniel J Walsh dwalsh at redhat.com writes:
You can run with SELinux in enforcement.
mmap_low_allowed is the name of the boolean moving forward.
By moving forward do you mean that one can, in f11, reset the
original boolean and set boolean mmap_low_allowed instead, in a
forthcoming policy
For people running wine or Crossover and using MS Office 2003 and related codes
it is necessary to do:
# setsebool -P allow_unconfined_mmap_low 1
To prevent AVC denials.
However there is recent publicity at
http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/
which highlights that
Two weeks ago I reported https://bugzilla.redhat.com/show_bug.cgi?id=527137
Since this could well affect quite a few people with scanners of various
flavours I though that some response to the report might have been seen on the
above link by now. Am I barking up the wrong tree or is my diagnosis
Mike Cloaked mike.cloaked at gmail.com writes:
How does one know if the maintainer concerned has seen the report,
and if there is no action following up on the bz, how does one ask
for a second maintainer to have a look at it?
I was not aware the maintainer was away - this is now answered
Mike Cloaked mike.cloaked at gmail.com writes:
Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11
when it is released?
From MozillaWiki I note that the plan is: Start build: 3rd November
(est 10th Nov) so this will likely be around 3 weeks away.
I just started
Julian Sikorski belegdol at gmail.com writes:
Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11
when it is released?
What makes you think it won't?
Julian
I did wonder what the process would be after all the kerfuffle with TB3.0b4
I presume that it will go out
In F11 every laptop I installed had support for the touchpad under Gnome, but in
order to have touchpad tap action at the greeter stage in kdm I need to put in
place a suitable hal/fdi file.
Is touchpad support in kdm going to be available by default in F12?
--
fedora-devel-list mailing list
drago01 drago01 at gmail.com writes:
No, tapping is disabled by default distrowide, there's nothing KDM can or
should do about this. This is an intentional decision by the upstream
Well it can enable it via input properties (configuration interface
for xorg input drivers).
Using the
Matěj Cepl mcepl at redhat.com writes:
I have no experience with KDE, but in Gnome I have it set in the Gnome
configuration (not sure whether it works in gdm). Otherwise /etc/hal/fdi
file is your safest bet.
https://fedoraproject.org/wiki/Input_device_configuration has some more
information
Will a build of Thunderbird 3.0rc1 be pushed to updates-testing for F11 when it
is released?
From MozillaWiki I note that the plan is: Start build: 3rd November (est 10th
Nov) so this will likely be around 3 weeks away.
Thanks
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
Richard Hughes hughsient at gmail.com writes:
Anyway, by PackageKit we really mean kpackagekit and gnome-packagekit,
as the PackageKit bits are already usable, e.g.
* Enable this testing repo
* Get the updates from this repo
* Install them
* Wait a week
* Ask user for feedback, and point
Rahul Sundaram sundaram at fedoraproject.org writes:
problems was known then reversing the release was not really an option.
Why not? The maintainer says it is a option and it is definitely
feasible to release a update that disables these couple of features by
default rather than make
Jeff Garzik jgarzik at pobox.com writes:
I hope a thunderbird update is being prepared, to make 2 config tweaks
for F11?
And a warning / release note for F12 users, noting that a __lot__ of
additional disk space is required in ~/.thunderbird.
Jeff
Hopefully the default will be
Rahul Sundaram sundaram at fedoraproject.org writes:
Anyway,
this debate is essentially over at this point since a update with the
defaults changed is being pushed out.
http://mether.wordpress.com/2009/10/14/thunderbird-problem-gets-fixed/
Rahul
OK - I hope this runs smoothly and
Mike McGrath mmcgrath at redhat.com writes:
And that's a people problem more than a process problem. If nobody
tests it in updates-testing, then how is the maintainer to know that it
is problematic? Certainly not solvable with even more repos for testing
content...
You let me know
Christopher Aillon caillon at redhat.com writes:
The UI change was obvious, but as it was upstream's decision, and we
follow upstream, didn't think much of it. In retrospect, we should have
considered undoing that change. We are looking into that now.
Not everyone had issues with the
Rahul Sundaram sundaram at fedoraproject.org writes:
The general attitude in this thread (not you) and elsewhere that it was
ok to cause problems was worrying me. Thanks for looking into this problem.
Rahul
I am not sure that there is evidence for that! I think that some people were
Is there any chance there will be a build of Thunderbird 3.0PRE in
Koji soon? It would be nice to see a build for F11 and F12 as I
believe there are significant fixes compared to 3.0beta 4 in the
3.0pre build.
--
mike
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
Drag01 wrote
like?
Well someone I know has had dreadful problems with the x64 version of
b4 build for F11 from updates-testing - with huge memory usage and
never completed the re-indexing process - in the end it hung the
machine completely. He took 3.0pre from the mozilla download site and
it
Tomorrow - 2009-09-09 - is ATI/AMD Radeon graphics card Test Day (1).
I have been trying to follow the procedure to get the liveusb key to
boot - but changing the kernel line to either of
root=live:LABEL=F12-Snap1-i686-Live
to: root=live:LABEL=F12-i686 or to LABEL=LIVE won't work for me!
I
Bob Arendt wrote:
Try using /sbin/dosfslabel or /sbin/e2label to read the actual label.
Then use that for the label on the boot line.
Bingo! That works - excellent - I think I will add this to the
reference page - others will doubtless be bitten by this also.
Now I hope I can test later this
Bob Arendt wrote:
Glad it helped. I tried out the Snapshot 1 liveusb, and
was puzzled when it didn't work; My original post to
those bugs was based on /sbin/dosfslabel (it was a vfat stick).
I'm curious - what *was* the label reported? How did you
create your live boot? I'd used the
On Wed, Sep 9, 2009 at 8:55 PM, mike cloakedmike.cloa...@gmail.com wrote:
The live usbkey was created with the livecd-iso-to-disk command as per
the Fedora wiki, from within a running F11 system (up to date).
I had previously labelled the stick using e2label (if I remember correctly!)
Mike Cloaked wrote:
In F11 the contents contain
/var/named/chroot and within this directory are
/dev containing file null, random and zero
and /etc containing file localtime
and nothing else.
This is surely a packing error since the bind-chroot package should
install the proper chrooted directory
I checked the contents of the bind-chroot package in both F10 and f11
- as I was puzzled about running bind-chroot since things seemed
rather different to previous behaviour.
In F11 the contents contain
/var/named/chroot and within this directory are
/dev containing file null, random and zero
28 matches
Mail list logo