On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
> Hi,
>
> I'm concerned about the default behaviour of mounting encrypted volumes.
>
> The default behaviour is that a user must know and supply a passphrase
> in order to mount an encrypted volume. This is good: know the
> passphrase, you get t
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
> Hi,
>
> I'm concerned about the default behaviour of mounting encrypted volumes.
>
> The default behaviour is that a user must know and supply a passphrase
> in order to mount an encrypted volume. This is good: know the
> passphrase, you get to
2010/10/25 Kevin Fenzi
> On Sun, 24 Oct 2010 21:24:30 +0300
> Kalev Lember wrote:
>
> > On 10/20/2010 03:02 PM, Jaroslav Reznik wrote:
> > > The question is (we agreed on KDE SIG meeting yesterday) - should we
> > > update Qt to 4.7 too or build KDE stack with current 4.6 series? As
> > > there
On Sun, 24 Oct 2010 21:24:30 +0300
Kalev Lember wrote:
> On 10/20/2010 03:02 PM, Jaroslav Reznik wrote:
> > The question is (we agreed on KDE SIG meeting yesterday) - should we
> > update Qt to 4.7 too or build KDE stack with current 4.6 series? As
> > there are a few Qt packages outside of KDE S
nodata wrote:
> Hi,
>
> I'm concerned about the default behaviour of mounting encrypted volumes.
>
> The default behaviour is that a user must know and supply a passphrase
> in order to mount an encrypted volume. This is good: know the
> passphrase, you get to mount the volume.
>
> What I am c
On Tue, Oct 26, 2010 at 00:40:41 +0200,
nodata wrote:
>
> My point is that if the disk is encrypted, and the user knows the
> passphrase to access files on the device, then it doesn't make sense to
> let everyone else see what's on the device as well: it only make sense
> to decrypt the devi
On Mon, Oct 25, 2010 at 15:52:38 -0700,
Adam Williamson wrote:
>
> Having said that, I don't think this seems serious enough to be a
> blocker, though obviously we'd like the minimal install to be as minimal
> as possible. Does it cause major problems for any spins? I doubt it, I
> expect most
Peter Robinson wrote:
> On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson wrote:
>> On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
>>> Colin Walters (walt...@verbum.org) said:
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
> Unfortunately we didn't notice this dependenc
On Mon, Oct 25, 2010 at 11:52 PM, Adam Williamson wrote:
> On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
>> Colin Walters (walt...@verbum.org) said:
>> > On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
>> > >
>> > > Unfortunately we didn't notice this dependency until pretty lat
On Mon, 2010-10-25 at 17:55 -0400, Bill Nottingham wrote:
> Colin Walters (walt...@verbum.org) said:
> > On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
> > >
> > > Unfortunately we didn't notice this dependency until pretty late in
> > > F14...I'm not sure what can be done reasonably at th
On 10/25/2010 04:40 PM, nodata wrote:
>> Wouldn't they be restricted based on the contents of the encrypted volume?
>
> Yes. Once the volume is mounted it will be treated with normal UNIX
> permissions. So you would have to create a sub-directory on the volume
> where the permissions were strict a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/25/10 8:09 AM, Mamoru Tasaka wrote:
> Hello:
>
> Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> As you might be aware, there was a period of roughly two weeks where a
>> gcc build (gc
On 26/10/10 00:31, Nathanael D. Noblet wrote:
> On 10/25/2010 04:28 PM, nodata wrote:
>> Hi,
>>
>> I'm concerned about the default behaviour of mounting encrypted volumes.
>>
>> The default behaviour is that a user must know and supply a passphrase
>> in order to mount an encrypted volume. This is
On 26/10/10 00:31, Nathanael D. Noblet wrote:
> On 10/25/2010 04:28 PM, nodata wrote:
>> Hi,
>>
>> I'm concerned about the default behaviour of mounting encrypted volumes.
>>
>> The default behaviour is that a user must know and supply a passphrase
>> in order to mount an encrypted volume. This is
On 10/25/2010 04:28 PM, nodata wrote:
> Hi,
>
> I'm concerned about the default behaviour of mounting encrypted volumes.
>
> The default behaviour is that a user must know and supply a passphrase
> in order to mount an encrypted volume. This is good: know the
> passphrase, you get to mount the volu
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase
in order to mount an encrypted volume. This is good: know the
passphrase, you get to mount the volume.
What I am concerned about is that the volum
Colin Walters (walt...@verbum.org) said:
> On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
> >
> > Unfortunately we didn't notice this dependency until pretty late in
> > F14...I'm not sure what can be done reasonably at this point, since
> > all of these packages are critical path.
>
> Th
On Mon, Oct 25, 2010 at 5:21 PM, Colin Walters wrote:
>
> Unfortunately we didn't notice this dependency until pretty late in
> F14...I'm not sure what can be done reasonably at this point, since
> all of these packages are critical path.
Though I will say that if this was determined to be a bloc
On Mon, Oct 25, 2010 at 3:33 PM, Dave Jones wrote:
> I did a minimal install yesterday, and was surprised to find that
> cairo, and a bunch of X libs were still installed.
>
> The dependancy chain that pulled them in looks like this..
>
> policycoreutils -> dbus-glib -> gobject-introspection -> fo
On Mon, 2010-10-25 at 21:42 +0200, Thorsten Leemhuis wrote:
> On 25.10.2010 20:49, Adam Williamson wrote:
> > On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote:
> >> Sorry if this has been discussed, but has there every been discussion
> >> of a dual 32/64-bit install media? I realize that th
On Mon, 25 Oct 2010 12:59:22 -0600
Kevin Fenzi wrote:
> On Mon, 25 Oct 2010 19:56:27 +0100
> Paul Howarth wrote:
>
> > On Mon, 25 Oct 2010 18:35:54 +0200
> > Jindrich Novy wrote:
> >
> > > Hi!
> > >
> > > xz-5.0.0 is now released and soname is now bumped to 5.0.0 in
> > > rawhide. The most i
Thorsten Leemhuis wrote:
> But a combo x86-32/x86-64 install media OTOH would be very interesting
> for magazines that want to ship Fedora on a enclosed DVD, as that's
> cheaper than two and makes way more readers happy than a x86-32 only
> DVD. Ohh, and a combo install media might be interesting a
On 25.10.2010 20:49, Adam Williamson wrote:
> On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote:
>> Sorry if this has been discussed, but has there every been discussion
>> of a dual 32/64-bit install media? I realize that the default package
>> selection would be reduced but with a high spee
I did a minimal install yesterday, and was surprised to find that
cairo, and a bunch of X libs were still installed.
The dependancy chain that pulled them in looks like this..
policycoreutils -> dbus-glib -> gobject-introspection -> fontconfig -> cairo
Could any part of that chain have its depen
On Mon, 25 Oct 2010 19:56:27 +0100
Paul Howarth wrote:
> On Mon, 25 Oct 2010 18:35:54 +0200
> Jindrich Novy wrote:
>
> > Hi!
> >
> > xz-5.0.0 is now released and soname is now bumped to 5.0.0 in
> > rawhide. The most important changes are:
> >
> > * The compression settings associated with th
On Mon, 25 Oct 2010 18:35:54 +0200
Jindrich Novy wrote:
> Hi!
>
> xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide.
> The most important changes are:
>
> * The compression settings associated with the preset levels
> -0 ... -9 have been changed. --extreme was changed a li
On Sun, 2010-10-24 at 19:31 -0700, Kevin Higgins wrote:
> I can not tell you exactly which day but approximately Oct 18th auto
> mount for data DVD's worked and now it does not . Did a clean install
> to test again. with same result. Blank DVD's auto mount Movies and
> data DVD's do not auto mount.
On Sun, 2010-10-24 at 12:25 -0500, Garrett Holmstrom wrote:
> On 10/24/2010 10:17, Branched Report wrote:
> > Broken deps for x86_64
> > --
> > qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
> > rakudo-0.0.2010.08_2.7.0-1.fc
On Sun, 2010-10-24 at 10:45 -0400, Mark Bidewell wrote:
> Sorry if this has been discussed, but has there every been discussion
> of a dual 32/64-bit install media? I realize that the default package
> selection would be reduced but with a high speed connection it
> shouldn't be too big of an issu
Join us on irc.freenode.net #fedora-meeting for this important meeting.
Tuesday October 26, 2010 @ 21:00 UTC (17:00 EDT/14:00 PDT)
"Before each public release Development, QA, and Release Engineering
meet to determine if the release criteria are met for a particular
release. This meeting is cal
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=557485
--- Comment #5 from Fedora Update System 2010-10-25
12:38:23 EDT ---
perl-SOAP-Lite-0.710.07-3.el5 has been pushed to the Fedor
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=557485
Fedora Update System changed:
What|Removed |Added
--
Hi!
xz-5.0.0 is now released and soname is now bumped to 5.0.0 in rawhide.
The most important changes are:
* The compression settings associated with the preset levels
-0 ... -9 have been changed. --extreme was changed a little too.
It is now less likely to make compression worse, but with so
W dniu 25 października 2010 17:19 użytkownik Eric Sandeen
napisał:
> Michał Piotrowski wrote:
>> Hi,
>>
>> 2010/10/6 Eric Sandeen :
>>> OK gang, it's in e2fsprogs-1.41.12-6.fc15
>>>
>>> you have to invoke it with "-test" options to make it go ;)
>>>
>>> Word of warning, it's not had a lot of atten
Compose started at Mon Oct 25 13:15:08 UTC 2010
Broken deps for x86_64
--
qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires
libparrot.so.2.7.0()(64bit)
Broken deps fo
Michał Piotrowski wrote:
> Hi,
>
> 2010/10/6 Eric Sandeen :
>> OK gang, it's in e2fsprogs-1.41.12-6.fc15
>>
>> you have to invoke it with "-test" options to make it go ;)
>>
>> Word of warning, it's not had a lot of attention, and the whole
>> design could change in the future, but it's something
Hello:
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> As you might be aware, there was a period of roughly two weeks where a
> gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
> Fedora 15. Items built with this could h
Hi,
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).
You can test it against your package with this scratch-build:
http://koji.fedoraproject.o
Hi,
2010/10/6 Eric Sandeen :
> OK gang, it's in e2fsprogs-1.41.12-6.fc15
>
> you have to invoke it with "-test" options to make it go ;)
>
> Word of warning, it's not had a lot of attention, and the whole
> design could change in the future, but it's something to play with :)
>
> -Eric
Would it m
On 10/24/2010 01:25 PM, Garrett Holmstrom wrote:
>> qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit)
>> >rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires
>> > libparrot.so.2.7.0()(64bit)
> Any chance these are going to be fixed before release?
I looked at qtgpsc, but that's unlik
Compose started at Mon Oct 25 08:15:05 UTC 2010
Broken deps for x86_64
--
PyKDE4-4.5.2-5.fc15.x86_64 requires PyQt4 >= 0:4.8n
ScientificPython-2.8-11.fc14.x86_64 requires libmpi.so.0()(64bit)
ScientificPython-2.8-11.fc
Maxim Burgerhout writes:
> Hi,
>
> I am the maintainer for ykpers and libyubikey for Fedora. It's great
> to see Fedora starting to use these nifty devices!
>
> If there is anything I can do to help out and make the use of
> Yubikey's in the Fedora project into a success, just holler.
Hi -- I li
Paul Wouters writes:
> On Fri, 8 Oct 2010, Nathanael D. Noblet wrote:
>
>> On 10/07/2010 10:58 PM, Paul Wouters wrote:
>>> One usage of yubikey I would like very much is as storage for the AES
>>> encryption key for disk encryption. I'd prefer the disk crypto key to
>>> not be on the disk at all,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/23/2010 06:39 PM, Javier Prats wrote:
> Hello all,
>
> I was wondering if this is the correct place to discuss the default
> partitioning scheme after installation. If not, could someone please
> direct me to the correct place?
>
It's as good
44 matches
Mail list logo
