-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
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,
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
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
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
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
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
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
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
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
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
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
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
--
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
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
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
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 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 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 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
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 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
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 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
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, 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, 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
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
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
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
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
-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 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
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 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
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 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
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
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 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
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 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
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
44 matches
Mail list logo
