From pemboa at gmail.com Tue Oct 2 17:43:36 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 2 Oct 2007 12:43:36 -0500
Subject: Default Firefox settings
Message-ID: <16de708d0710021043q1414a664mff0b605dd285bfeb@mail.gmail.com>
Hello,
I recently asked about ways to benchmark Firefox[1] because of how
slow I found Firefox to be on Fedora 7. It was almost unusably slow,
prompting me to switch to Konqueror as much as possible.
However I have found a short tutorial which after following the speed
seems to at least be on par which my laptop (which has half the
processing speed, and a slower, IDE hard drive, and slower memory)
Assuming I haven't encountered some freak situation, it may be
necessary to consider changing the default Firefox settings, one of
which is IPV6 DNS. I have zero issues against IPV6 myself, but if it
helps make Firefox useful, by all means.
Again, if I can provide any objective metrics, please let me know.
[1] http://www.redhat.com/archives/fedora-desktop-list/2007-September/msg00135.html
[2] http://www.zolved.com/synapse/view_content/28106/How_to_speed_up_Mozilla_Firefox_on_Ubuntu
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
From mclasen at redhat.com Wed Oct 3 16:47:54 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 03 Oct 2007 12:47:54 -0400
Subject: Desktop SIG meeting today ?
Message-ID: <1191430074.3293.1.camel@localhost.localdomain>
I just realized I will be on the road between 2 and 3, so I can't make
the lead sig meeting. Maybe David or Chris can step up ?
Matthias
From bkonrath at redhat.com Wed Oct 3 19:34:04 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Wed, 03 Oct 2007 15:34:04 -0400
Subject: new user creation module in firstboot
Message-ID: <1191440044.7817.28.camel@toast.toronto.redhat.com>
Hi,
I'm working on a new user creation module for the new and improved
firstboot. I created a little video to give people an idea of the UI
interaction:
http://bagu.org/scratch/createuser.ogv
One open issue that I have is that I'd like to require that a user
account be created by greying out the 'next' button until the
information requested is complete and correct.
If requiring a user account be created is not the best approach, what is
the best way to allow the user skip this step? An initial idea I had was
to grey out the 'next' button only when the user starts to enter
information. The problem with this approach is that it's not easy for a
user to cancel out of the account creation if they start the process but
decide halfway through that they don't want a user account anymore. Any
thoughts or comments would be appreciated.
I've also been looking into using cheese to allow users to take a
snapshot of their face with a webcam when they are creating their
account in firstboot. The stock_person button in the video posted above
would activate a dialog for this. I sent a message to cheese-list and
one of the developers suggested that a dbus interface might work for
this task.
I created a mockup of what the interface for choosing a user image could
look like:
http://bagu.org/scratch/create-user-file.png
http://bagu.org/scratch/create-user-webcam.png
As you can see, there is a video preview from the webcam in the second
mockup. I don't know dbus well enough to comment on if it's appropriate
for this type of task. Does anybody know if dbus could work for this or
have any other ideas? I'm also looking for comments on the UI design of
the mockups.
Thanks, Ben
From mattdm at mattdm.org Wed Oct 3 19:43:45 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 3 Oct 2007 15:43:45 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
Message-ID: <20071003194345.GA1952@jadzia.bu.edu>
On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
> I'm working on a new user creation module for the new and improved
> firstboot. I created a little video to give people an idea of the UI
> interaction:
> http://bagu.org/scratch/createuser.ogv
Email address? Where's that going to go? What will it be used for? And isn't
my e-mail address username at localhost?
There should also be an advanced button so that parameters like userid can
be selected.
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From bkonrath at redhat.com Wed Oct 3 21:35:33 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Wed, 03 Oct 2007 17:35:33 -0400
Subject: new user creation module in firstboot
In-Reply-To: <20071003194345.GA1952@jadzia.bu.edu>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
Message-ID: <1191447333.7817.42.camel@toast.toronto.redhat.com>
On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote:
> On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
> > I'm working on a new user creation module for the new and improved
> > firstboot. I created a little video to give people an idea of the UI
> > interaction:
> > http://bagu.org/scratch/createuser.ogv
>
> Email address? Where's that going to go? What will it be used for? And isn't
> my e-mail address username at localhost?
The Email address is intended to used to pull in account information
from mugshot so using username at localhost wouldn't really work.
> There should also be an advanced button so that parameters like userid can
> be selected.
This user creation module is intended to be used by desktop users, not
systems administrators so having a place to select advanced options like
userid doesn't really make sense. FWIW, the current user creation module
doesn't have those options for local users either.
Cheers, Ben
From davidz at redhat.com Wed Oct 3 21:51:29 2007
From: davidz at redhat.com (David Zeuthen)
Date: Wed, 03 Oct 2007 17:51:29 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
Message-ID: <1191448289.3414.22.camel@oneill.fubar.dk>
Hi,
On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
> Hi,
>
> I'm working on a new user creation module for the new and improved
> firstboot. I created a little video to give people an idea of the UI
> interaction:
>
> http://bagu.org/scratch/createuser.ogv
This looks pretty smooth, thanks a lot for working on this. My first
reaction is that this is not something that should be limited to
firstboot; ideally stuff like that should be able to run from the
desktop environment when adding / deleting / managing users, right?
If we want that we probably need to look at existing functionality in
the desktop.. that includes system-config-users (Fedora specific) and
the GNOME About Me dialog and how this would fit in. I'd probably say
that we want to replace both. And in the same breath I would approach
the GNOME community to get this done upstream so all distros can rally
around it (share development and maintenance efforts). What is your take
on that?
Also, if we want this in the desktop environment (and I think we do) it
needs to be written in a way that separates the mechanism (would run
privileged, e.g. uid 0 however locked down by SELinux or whatever) from
the user interface (would run unprivileged user). I'd probably suggest
to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus
(for activating the mechanism) for that, both of these (especially PK)
are kinda written for this kind of thing [2].
Finally, it would be good to have this feature as a "Component" so it's
easy to embed into other applications; e.g. if I want to write a OS
installer app, then I can easily embed this component. Same, FWIW, goes
for the work we're doing on the clock applet and in the future any
system configuration bits. I think firstboot has /some/ notion of
plug-in architecture but actually haven't reviewed it since I'm not sure
it's appropriate in an environment where the UI should run unprivileged.
But it just might work.
David
[1] : http://hal.freedesktop.org/docs/PolicyKit/
[2] : See e.g. http://blog.fubar.dk/?p=93 and http://blog.fubar.dk/?p=94
for some background
From pemboa at gmail.com Wed Oct 3 21:58:14 2007
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 3 Oct 2007 16:58:14 -0500
Subject: new user creation module in firstboot
In-Reply-To: <1191447333.7817.42.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
Message-ID: <16de708d0710031458p29ee6537u2615b4459cca5ad6@mail.gmail.com>
On 10/3/07, Ben Konrath wrote:
> On Wed, 2007-10-03 at 15:43 -0400, Matthew Miller wrote:
> > On Wed, Oct 03, 2007 at 03:34:04PM -0400, Ben Konrath wrote:
> > > I'm working on a new user creation module for the new and improved
> > > firstboot. I created a little video to give people an idea of the UI
> > > interaction:
> > > http://bagu.org/scratch/createuser.ogv
> >
> > Email address? Where's that going to go? What will it be used for? And isn't
> > my e-mail address username at localhost?
>
> The Email address is intended to used to pull in account information
> from mugshot so using username at localhost wouldn't really work.
>
> > There should also be an advanced button so that parameters like userid can
> > be selected.
>
> This user creation module is intended to be used by desktop users, not
> systems administrators so having a place to select advanced options like
> userid doesn't really make sense. FWIW, the current user creation module
> doesn't have those options for local users either.
>
> Cheers, Ben
if this is only targeted at desktop users.. what's wrong with firstboot?
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
From walters at redhat.com Wed Oct 3 22:09:32 2007
From: walters at redhat.com (Colin Walters)
Date: Wed, 3 Oct 2007 18:09:32 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191448289.3414.22.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
Message-ID:
On 10/3/07, David Zeuthen wrote:
>
> This looks pretty smooth, thanks a lot for working on this. My first
> reaction is that this is not something that should be limited to
> firstboot; ideally stuff like that should be able to run from the
> desktop environment when adding / deleting / managing users, right?
We had a design session on this; the idea was actually that you could
create new users from the login dialog (GDM).
From davidz at redhat.com Wed Oct 3 23:44:57 2007
From: davidz at redhat.com (David Zeuthen)
Date: Wed, 03 Oct 2007 19:44:57 -0400
Subject: new user creation module in firstboot
In-Reply-To:
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
Message-ID: <1191455097.18732.1.camel@oneill.fubar.dk>
On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
> On 10/3/07, David Zeuthen wrote:
> >
> > This looks pretty smooth, thanks a lot for working on this. My first
> > reaction is that this is not something that should be limited to
> > firstboot; ideally stuff like that should be able to run from the
> > desktop environment when adding / deleting / managing users, right?
>
> We had a design session on this; the idea was actually that you could
> create new users from the login dialog (GDM).
I agree that's an interesting idea that would replace the need for a
firstboot module (and probably firstboot entirely). However, I think
it's still needed as a program you can launch in the desktop session
along with an icon in System->Administration. If only we had a component
system...
David
From mclasen at redhat.com Wed Oct 3 23:55:15 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 03 Oct 2007 19:55:15 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191440044.7817.28.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
Message-ID: <1191455715.2648.10.camel@localhost.localdomain>
On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
> Hi,
>
> I'm working on a new user creation module for the new and improved
> firstboot. I created a little video to give people an idea of the UI
> interaction:
>
> http://bagu.org/scratch/createuser.ogv
>
> One open issue that I have is that I'd like to require that a user
> account be created by greying out the 'next' button until the
> information requested is complete and correct.
>
> If requiring a user account be created is not the best approach, what is
> the best way to allow the user skip this step? An initial idea I had was
> to grey out the 'next' button only when the user starts to enter
> information. The problem with this approach is that it's not easy for a
> user to cancel out of the account creation if they start the process but
> decide halfway through that they don't want a user account anymore. Any
> thoughts or comments would be appreciated.
If we don't want to make the user creation mandatory, then it is
probably best to not make the button insensitive at all. Instead, we
can pop up a message telling the user why creating an account is a good
idea when he tries to just click through.
If he clicks the next button while the entered data is inconsistent or
incomplete, we can pop up a warning telling him that the entered data
does not allow to create an account.
> I've also been looking into using cheese to allow users to take a
> snapshot of their face with a webcam when they are creating their
> account in firstboot. The stock_person button in the video posted above
> would activate a dialog for this. I sent a message to cheese-list and
> one of the developers suggested that a dbus interface might work for
> this task.
Not sure how dbus would come into this. I'd suggest to investigate a)
just launching cheese with some argument that tells it to take a single
snapshot and where to save it or b) just steal the relevant code from
cheese and embed the video directly in the user dialog.
Anyway, cool stuff.
Matthias
From mattdm at mattdm.org Thu Oct 4 01:26:24 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 3 Oct 2007 21:26:24 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191447333.7817.42.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
Message-ID: <20071004012624.GA14939@jadzia.bu.edu>
On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote:
> > Email address? Where's that going to go? What will it be used for? And
> > isn't my e-mail address username at localhost?
> The Email address is intended to used to pull in account information
> from mugshot so using username at localhost wouldn't really work.
My point is: how is the user presented with that form supposed to guess
that? Mugshot integration sounds like a cool idea -- but why not present it
as that?
> > There should also be an advanced button so that parameters like userid
> > can be selected.
> This user creation module is intended to be used by desktop users, not
> systems administrators so having a place to select advanced options like
> userid doesn't really make sense. FWIW, the current user creation module
> doesn't have those options for local users either.
I'm a desktop user. I want to select my user id. This is a flaw in the
current user creation module; if we're changing it, now's the time to fix
it.
Good design makes easy things easy and more complicated things possible.
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From mclasen at redhat.com Thu Oct 4 02:49:06 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 03 Oct 2007 22:49:06 -0400
Subject: new user creation module in firstboot
In-Reply-To: <20071004012624.GA14939@jadzia.bu.edu>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
Message-ID: <1191466146.2648.18.camel@localhost.localdomain>
On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote:
> I'm a desktop user. I want to select my user id. This is a flaw in the
> current user creation module; if we're changing it, now's the time to fix
> it.
>
> Good design makes easy things easy and more complicated things possible.
It also hides irrelevant things.
Why do you need to select a specific user id when creating a new user ?
I guess you are not creating a new user at all, but trying to recreate
an existing one, to reuse the home directory, etc. Right ?
From mattdm at mattdm.org Thu Oct 4 12:36:20 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Thu, 4 Oct 2007 08:36:20 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191466146.2648.18.camel@localhost.localdomain>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
<1191466146.2648.18.camel@localhost.localdomain>
Message-ID: <20071004123620.GA513@jadzia.bu.edu>
On Wed, Oct 03, 2007 at 10:49:06PM -0400, Matthias Clasen wrote:
> > Good design makes easy things easy and more complicated things possible.
> It also hides irrelevant things.
Hence the "advanced" button.
> Why do you need to select a specific user id when creating a new user ?
> I guess you are not creating a new user at all, but trying to recreate
> an existing one, to reuse the home directory, etc. Right ?
Often, yes. But I also like to have all user ids the same at home so
usernames on removable media just match up. I don't have complicated enough
home network (or enough users!) to justify LDAP or even NIS, and anyway I
need disconnected operation. So matching up user ids is nice.
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From gmureddu at prodigy.net.mx Thu Oct 4 14:07:38 2007
From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu)
Date: Thu, 04 Oct 2007 10:07:38 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191455097.18732.1.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
Message-ID: <4704F3AA.9030506@prodigy.net.mx>
David Zeuthen escribi?:
> On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
>
>> On 10/3/07, David Zeuthen wrote:
>>
>>> This looks pretty smooth, thanks a lot for working on this. My first
>>> reaction is that this is not something that should be limited to
>>> firstboot; ideally stuff like that should be able to run from the
>>> desktop environment when adding / deleting / managing users, right?
>>>
>> We had a design session on this; the idea was actually that you could
>> create new users from the login dialog (GDM).
>>
That would actually be a very cool idea, in my opinion.
>
> I agree that's an interesting idea that would replace the need for a
> firstboot module (and probably firstboot entirely). However, I think
> it's still needed as a program you can launch in the desktop session
> along with an icon in System->Administration. If only we had a component
> system...
>
> David
>
I thought that's why we had system-config-users for? Or am I missing
something here?
From abo at kth.se Thu Oct 4 15:37:48 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Thu, 04 Oct 2007 17:37:48 +0200
Subject: new user creation module in firstboot
In-Reply-To: <20071004123620.GA513@jadzia.bu.edu>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
<1191466146.2648.18.camel@localhost.localdomain>
<20071004123620.GA513@jadzia.bu.edu>
Message-ID: <1191512268.5560.40.camel@home.alexander.bostrom.net>
tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller:
>
> Often, yes. But I also like to have all user ids the same at home so
> usernames on removable media just match up. I don't have complicated enough
> home network (or enough users!) to justify LDAP or even NIS, and anyway I
> need disconnected operation. So matching up user ids is nice.
Yeah, I do that too.
Though perhaps it's time to start thinking about how to solve this
automatically. I personally feel that user ids should be local and that
anything that's not local to a host (removable media, network file
systems etc.) should use something else which then gets mapped to a
local uid when necessary. I'm not sure what that something would be,
though. Usernames, username at domain, mugshot accounts, user at uuid or
whatever.
For example, a USB drive with an ext3 file system could contain some
database that maps uids for that file system to usernames. Then when you
plug that into a machine, the uids are automatically remapped according
to this database to match what the host actually uses.
Btw, this isn't about improving security, it's just a way to make things
work more smoothly.
/abo
From davidz at redhat.com Thu Oct 4 16:15:59 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 04 Oct 2007 12:15:59 -0400
Subject: new user creation module in firstboot
In-Reply-To: <4704F3AA.9030506@prodigy.net.mx>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
<4704F3AA.9030506@prodigy.net.mx>
Message-ID: <1191514559.18756.2.camel@oneill.fubar.dk>
On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
> I thought that's why we had system-config-users for? Or am I missing
> something here?
As I wrote in my original mail there's overlap between this new cool
thing, the GNOME About Me dialog and system-config-users. Ideally we
should just have a single tool.
David
From notting at redhat.com Thu Oct 4 17:00:54 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Oct 2007 13:00:54 -0400
Subject: esc by default?
Message-ID: <20071004170054.GA7448@nostromo.devel.redhat.com>
Should this be optional? Does this actually get used under Fedora?
Bill
From skvidal at fedoraproject.org Thu Oct 4 17:10:21 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 04 Oct 2007 13:10:21 -0400
Subject: esc by default?
In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
Message-ID: <1191517821.6741.101.camel@cutter>
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
> Should this be optional? Does this actually get used under Fedora?
it should be optional, imo.
-sv
From mclasen at redhat.com Thu Oct 4 17:17:31 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 04 Oct 2007 13:17:31 -0400
Subject: esc by default?
In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
Message-ID: <1191518251.3151.0.camel@localhost.localdomain>
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
> Should this be optional? Does this actually get used under Fedora?
Yeah, it should certainly be optional.
From notting at redhat.com Thu Oct 4 17:26:49 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Oct 2007 13:26:49 -0400
Subject: esc by default?
In-Reply-To: <1191518251.3151.0.camel@localhost.localdomain>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191518251.3151.0.camel@localhost.localdomain>
Message-ID: <20071004172649.GA8170@nostromo.devel.redhat.com>
Matthias Clasen (mclasen at redhat.com) said:
>
> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
> > Should this be optional? Does this actually get used under Fedora?
>
> Yeah, it should certainly be optional.
OK, done.
Bill
From bclark at redhat.com Thu Oct 4 18:05:36 2007
From: bclark at redhat.com (Bryan Clark)
Date: Thu, 4 Oct 2007 14:05:36 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191514559.18756.2.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
<4704F3AA.9030506@prodigy.net.mx>
<1191514559.18756.2.camel@oneill.fubar.dk>
Message-ID: <4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com>
On 10/4/07, David Zeuthen wrote:
>
>
> On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
> > I thought that's why we had system-config-users for? Or am I missing
> > something here?
>
> As I wrote in my original mail there's overlap between this new cool
> thing, the GNOME About Me dialog and system-config-users. Ideally we
> should just have a single tool.
>
Yes, I think what we talked about in the GDM discussion was to reuse the
user dialog inside GNOME. So there would be a dialog for creating / editing
a user account that can be called from GDM as well as a dialog for doing the
same inside the Desktop. (i.e. the person probably shouldn't have to log
out to create / edit new users) To save effort we should attempt to reuse
code paths because the dialogs and actions will be almost exactly the same.
~ Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From davidz at redhat.com Thu Oct 4 18:03:59 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 04 Oct 2007 14:03:59 -0400
Subject: new user creation module in firstboot
In-Reply-To: <4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
<4704F3AA.9030506@prodigy.net.mx>
<1191514559.18756.2.camel@oneill.fubar.dk>
<4600a0ae0710041105i7ca528ddk6c2ab1300716e588@mail.gmail.com>
Message-ID: <1191521039.18756.6.camel@oneill.fubar.dk>
On Thu, 2007-10-04 at 14:05 -0400, Bryan Clark wrote:
> Yes, I think what we talked about in the GDM discussion was to reuse
> the user dialog inside GNOME. So there would be a dialog for
> creating / editing a user account that can be called from GDM as well
> as a dialog for doing the same inside the Desktop. ( i.e. the person
> probably shouldn't have to log out to create / edit new users) To save
> effort we should attempt to reuse code paths because the dialogs and
> actions will be almost exactly the same.
Cool. Btw, in passing, another thing I'd really like to see is support
for setting up the fingerprint reader via thinkfinger [1].
David
[1] : in F8 (and maybe F7), HAL can tell you whether you have the
hardware installed
From bpepple at fedoraproject.org Thu Oct 4 19:13:20 2007
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 04 Oct 2007 15:13:20 -0400
Subject: esc by default?
In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
Message-ID: <1191525200.18627.1.camel@kennedy>
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
> Should this be optional? Does this actually get used under Fedora?
I'd be for disabling it by default.
/B
--
Brian Pepple
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From jmagne at redhat.com Thu Oct 4 20:50:15 2007
From: jmagne at redhat.com (Jack Magne)
Date: Thu, 04 Oct 2007 13:50:15 -0700
Subject: esc by default?
In-Reply-To: <1191525200.18627.1.camel@kennedy>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy>
Message-ID: <47055207.6090707@redhat.com>
We need to have this installed on the machine by default because it
allows a user to enroll a smart card.
This is required to make use of the smart card login feature.
thanks,
Jack
Brian Pepple wrote:
> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
>
>> Should this be optional? Does this actually get used under Fedora?
>>
>
> I'd be for disabling it by default.
>
> /B
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL:
From skvidal at fedoraproject.org Thu Oct 4 20:54:19 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 04 Oct 2007 16:54:19 -0400
Subject: esc by default?
In-Reply-To: <47055207.6090707@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
Message-ID: <1191531259.6741.109.camel@cutter>
On Thu, 2007-10-04 at 13:50 -0700, Jack Magne wrote:
> We need to have this installed on the machine by default because it
> allows a user to enroll a smart card.
> This is required to make use of the smart card login feature.
1. smart cards are extremely uncommon.
2. if you have an infrastructure requiring this then your sysadmin/user
can install the pkg with a single command
why would it need to be on the default install?
-sv
From notting at redhat.com Thu Oct 4 20:56:27 2007
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 4 Oct 2007 16:56:27 -0400
Subject: esc by default?
In-Reply-To: <47055207.6090707@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
Message-ID: <20071004205627.GA11204@nostromo.devel.redhat.com>
Jack Magne (jmagne at redhat.com) said:
> We need to have this installed on the machine by default because it allows
> a user to enroll a smart card.
> This is required to make use of the smart card login feature.
That's a logical fallacy.
Number of bugs filed against esc by non-RH people relating to its use: 0
Number of bugs filed against thinkfinger by non-RH people relating to
its use: 2
And yet, we don't install thinkfinger by default. (We could then compare the
number of users with fingerprint scanning hardware vs. smart cards.)
Bill
From davidz at redhat.com Thu Oct 4 21:25:17 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 04 Oct 2007 17:25:17 -0400
Subject: esc by default?
In-Reply-To: <20071004170054.GA7448@nostromo.devel.redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
Message-ID: <1191533117.15479.6.camel@oneill.fubar.dk>
On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
> Should this be optional? Does this actually get used under Fedora?
As a general rule of thumb we do try hard to ship as many drivers /
hardware enablement features as possible. I'm not sure why esc is any
different?
Maybe.. because of the fact that it's a resource hog (both in terms of
eating cycles and taking up disk space). At least it was like this the
last time I looked [1].
(Btw, for me, the resource hog issue alone should be enough to kick it
out of the default install. Think boot time, live image size etc. And if
this is the case, we should just say it like it is. It might also help
get someone to fix it.)
David
[1] : for starters, they ship their own mozilla stack
From jmagne at redhat.com Thu Oct 4 21:51:19 2007
From: jmagne at redhat.com (Jack Magne)
Date: Thu, 04 Oct 2007 14:51:19 -0700
Subject: esc by default?
In-Reply-To: <1191533117.15479.6.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191533117.15479.6.camel@oneill.fubar.dk>
Message-ID: <47056057.7070601@redhat.com>
You are correct about the physical size.
The upcoming system wide Xulrunner should help us there.
By default , only a smaller smart card detection daemon run until
someone puts in an actual card.
thanks,
jack
David Zeuthen wrote:
> On Thu, 2007-10-04 at 13:00 -0400, Bill Nottingham wrote:
>
>> Should this be optional? Does this actually get used under Fedora?
>>
>
> As a general rule of thumb we do try hard to ship as many drivers /
> hardware enablement features as possible. I'm not sure why esc is any
> different?
>
> Maybe.. because of the fact that it's a resource hog (both in terms of
> eating cycles and taking up disk space). At least it was like this the
> last time I looked [1].
>
> (Btw, for me, the resource hog issue alone should be enough to kick it
> out of the default install. Think boot time, live image size etc. And if
> this is the case, we should just say it like it is. It might also help
> get someone to fix it.)
>
> David
>
> [1] : for starters, they ship their own mozilla stack
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL:
From davidz at redhat.com Thu Oct 4 21:57:41 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 04 Oct 2007 17:57:41 -0400
Subject: esc by default?
In-Reply-To: <47056057.7070601@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191533117.15479.6.camel@oneill.fubar.dk>
<47056057.7070601@redhat.com>
Message-ID: <1191535061.15479.20.camel@oneill.fubar.dk>
On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote:
> By default , only a smaller smart card detection daemon run until
> someone puts in an actual card.
Even this is wrong. You should use either udev or hal to ensure that the
daemon is running only when the hardware is present (assuming USB; if
people still use serial ports then they can manually edit some config
file to make sure the daemon starts up.)
David
From jmagne at redhat.com Thu Oct 4 22:52:03 2007
From: jmagne at redhat.com (Jack Magne)
Date: Thu, 04 Oct 2007 15:52:03 -0700
Subject: esc by default?
In-Reply-To: <1191535061.15479.20.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191533117.15479.6.camel@oneill.fubar.dk> <47056057.7070601@redhat.com>
<1191535061.15479.20.camel@oneill.fubar.dk>
Message-ID: <47056E93.8070808@redhat.com>
Yes, we have a bug on the issue to to tie smart card detection to hal.
thanks,
jack
David Zeuthen wrote:
> On Thu, 2007-10-04 at 14:51 -0700, Jack Magne wrote:
>
>> By default , only a smaller smart card detection daemon run until
>> someone puts in an actual card.
>>
>
> Even this is wrong. You should use either udev or hal to ensure that the
> daemon is running only when the hardware is present (assuming USB; if
> people still use serial ports then they can manually edit some config
> file to make sure the daemon starts up.)
>
> David
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL:
From jkeating at redhat.com Fri Oct 5 00:39:00 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 4 Oct 2007 20:39:00 -0400
Subject: esc by default?
In-Reply-To: <47055207.6090707@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
Message-ID: <20071004203900.5b98d6e5@redhat.com>
On Thu, 04 Oct 2007 13:50:15 -0700
Jack Magne wrote:
> We need to have this installed on the machine by default because it
> allows a user to enroll a smart card.
> This is required to make use of the smart card login feature.
That's an argument for having it on the install media, but not an
argument to install it by default.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From bkonrath at redhat.com Fri Oct 5 03:37:10 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Thu, 04 Oct 2007 23:37:10 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191512268.5560.40.camel@home.alexander.bostrom.net>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
<1191466146.2648.18.camel@localhost.localdomain>
<20071004123620.GA513@jadzia.bu.edu>
<1191512268.5560.40.camel@home.alexander.bostrom.net>
Message-ID: <1191555430.13236.8.camel@toast.toronto.redhat.com>
On Thu, 2007-10-04 at 17:37 +0200, Alexander Bostr?m wrote:
> tor 2007-10-04 klockan 08:36 -0400 skrev Matthew Miller:
> >
> > Often, yes. But I also like to have all user ids the same at home so
> > usernames on removable media just match up. I don't have complicated enough
> > home network (or enough users!) to justify LDAP or even NIS, and anyway I
> > need disconnected operation. So matching up user ids is nice.
>
> Yeah, I do that too.
>
> Though perhaps it's time to start thinking about how to solve this
> automatically. I personally feel that user ids should be local and that
> anything that's not local to a host (removable media, network file
> systems etc.) should use something else which then gets mapped to a
> local uid when necessary. I'm not sure what that something would be,
> though. Usernames, username at domain, mugshot accounts, user at uuid or
> whatever.
>
> For example, a USB drive with an ext3 file system could contain some
> database that maps uids for that file system to usernames. Then when you
> plug that into a machine, the uids are automatically remapped according
> to this database to match what the host actually uses.
I agree, solving the real problem is the better way to go. But
unfortunately that's out of scope for user creation stuff I'm working
on.
Matt: How do you get around not being able to specify the uid in the
current firstboot user creation module? - Just curious.
Cheers, Ben
From bkonrath at redhat.com Fri Oct 5 03:58:57 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Thu, 04 Oct 2007 23:58:57 -0400
Subject: new user creation module in firstboot
In-Reply-To: <20071004012624.GA14939@jadzia.bu.edu>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
Message-ID: <1191556737.13236.27.camel@toast.toronto.redhat.com>
On Wed, 2007-10-03 at 21:26 -0400, Matthew Miller wrote:
> On Wed, Oct 03, 2007 at 05:35:33PM -0400, Ben Konrath wrote:
> > > Email address? Where's that going to go? What will it be used for? And
> > > isn't my e-mail address username at localhost?
> > The Email address is intended to used to pull in account information
> > from mugshot so using username at localhost wouldn't really work.
>
> My point is: how is the user presented with that form supposed to guess
> that? Mugshot integration sounds like a cool idea -- but why not present it
> as that?
Good point. But since there are other uses for the email address (think
any application that asks for the users email address), it's best to
just keep it generic.
> > > There should also be an advanced button so that parameters like userid
> > > can be selected.
> > This user creation module is intended to be used by desktop users, not
> > systems administrators so having a place to select advanced options like
> > userid doesn't really make sense. FWIW, the current user creation module
> > doesn't have those options for local users either.
>
> I'm a desktop user. I want to select my user id. This is a flaw in the
> current user creation module; if we're changing it, now's the time to fix
> it.
When I said desktop user I really meant 'non-computer-savy desktop
user', sorry about that. I think for this case uid is not required, but
by that logic neither is the unix username (and some might argue that
passwords are in the same boat). So maybe an advanced would be useful.
Thanks for your input, Ben
From mattdm at mattdm.org Fri Oct 5 04:01:57 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 5 Oct 2007 00:01:57 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191555430.13236.8.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
<1191466146.2648.18.camel@localhost.localdomain>
<20071004123620.GA513@jadzia.bu.edu>
<1191512268.5560.40.camel@home.alexander.bostrom.net>
<1191555430.13236.8.camel@toast.toronto.redhat.com>
Message-ID: <20071005040157.GA10906@jadzia.bu.edu>
On Thu, Oct 04, 2007 at 11:37:10PM -0400, Ben Konrath wrote:
> Matt: How do you get around not being able to specify the uid in the
> current firstboot user creation module? - Just curious.
Skip it. Log in as root on text console, create user with useradd. Which I'm
fine with continuing to do, although it'd be *nice* to skip this step.
(If I'm installing BU Linux, I can, because we've made our own replacement
firstboot module which looks up the user id from our ph/qi server. But I
often install vanilla Fedora or CentOS.)
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From mattdm at mattdm.org Fri Oct 5 04:05:48 2007
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 5 Oct 2007 00:05:48 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191556737.13236.27.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<20071003194345.GA1952@jadzia.bu.edu>
<1191447333.7817.42.camel@toast.toronto.redhat.com>
<20071004012624.GA14939@jadzia.bu.edu>
<1191556737.13236.27.camel@toast.toronto.redhat.com>
Message-ID: <20071005040548.GB10906@jadzia.bu.edu>
On Thu, Oct 04, 2007 at 11:58:57PM -0400, Ben Konrath wrote:
> > > The Email address is intended to used to pull in account information
> > > from mugshot so using username at localhost wouldn't really work.
> > My point is: how is the user presented with that form supposed to guess
> > that? Mugshot integration sounds like a cool idea -- but why not present it
> > as that?
> Good point. But since there are other uses for the email address (think
> any application that asks for the users email address), it's best to
> just keep it generic.
Ouch. I don't *want* to provide a working e-mail address to any application
that generically asks. And I don't think I'm the only one who's sensitive to
this.
Anyway, from an old school Unix perspective it just feels weird to ask it
the way you are, because e-mail address is exactly equal to
username at hostname.
But overall I'm with you on this. It's useful to have an external e-mail
address. In fact, I'd like to see an option on this screen to automatically
alias the root e-mail address to the given address.
--
Matthew Miller mattdm at mattdm.org
Boston University Linux ------>
From gmureddu at prodigy.net.mx Fri Oct 5 03:30:43 2007
From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu)
Date: Thu, 04 Oct 2007 23:30:43 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191514559.18756.2.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
<4704F3AA.9030506@prodigy.net.mx>
<1191514559.18756.2.camel@oneill.fubar.dk>
Message-ID: <4705AFE3.1030604@prodigy.net.mx>
David Zeuthen escribi?:
> On Thu, 2007-10-04 at 10:07 -0400, Gian Paolo Mureddu wrote:
>
>> I thought that's why we had system-config-users for? Or am I missing
>> something here?
>>
>
> As I wrote in my original mail there's overlap between this new cool
> thing, the GNOME About Me dialog and system-config-users. Ideally we
> should just have a single tool.
>
> David
>
>
>
Again, I thought system-config-users was for adding users (admin) and
changing properties of users as per administration policies, and the
about-me tool was for users to *modify* their profiles, password and
other preferences, rather than do the *exact* same thing as
system-config-users... I'm a bit confused now...
From bkonrath at redhat.com Fri Oct 5 04:39:25 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Fri, 05 Oct 2007 00:39:25 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191448289.3414.22.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
Message-ID: <1191559165.13236.51.camel@toast.toronto.redhat.com>
On Wed, 2007-10-03 at 17:51 -0400, David Zeuthen wrote:
> Hi,
>
> On Wed, 2007-10-03 at 15:34 -0400, Ben Konrath wrote:
> > Hi,
> >
> > I'm working on a new user creation module for the new and improved
> > firstboot. I created a little video to give people an idea of the UI
> > interaction:
> >
> > http://bagu.org/scratch/createuser.ogv
>
> This looks pretty smooth, thanks a lot for working on this. My first
> reaction is that this is not something that should be limited to
> firstboot; ideally stuff like that should be able to run from the
> desktop environment when adding / deleting / managing users, right?
As Colin pointed out, the goal here is to allow users to create accounts
at more obvious places - at login, when switching users, at firstboot -
and share the code / UI for this. This firstboot module was just an easy
place for me to start experimenting. So yeah, having the ability to run
an account creation app inside the desktop environment is definitely
what we want.
> If we want that we probably need to look at existing functionality in
> the desktop.. that includes system-config-users (Fedora specific) and
> the GNOME About Me dialog and how this would fit in. I'd probably say
> that we want to replace both. And in the same breath I would approach
> the GNOME community to get this done upstream so all distros can rally
> around it (share development and maintenance efforts). What is your take
> on that?
I think that seems like a good plan.
> Also, if we want this in the desktop environment (and I think we do) it
> needs to be written in a way that separates the mechanism (would run
> privileged, e.g. uid 0 however locked down by SELinux or whatever) from
> the user interface (would run unprivileged user). I'd probably suggest
> to use PolicyKit [1] (for flexible fine grained lock down) and D-Bus
> (for activating the mechanism) for that, both of these (especially PK)
> are kinda written for this kind of thing [2].
Yes, I agree. I just read those pages and they will be a good starting
point. Thanks for the info :)
> Finally, it would be good to have this feature as a "Component" so it's
> easy to embed into other applications; e.g. if I want to write a OS
> installer app, then I can easily embed this component. Same, FWIW, goes
> for the work we're doing on the clock applet and in the future any
> system configuration bits. I think firstboot has /some/ notion of
> plug-in architecture but actually haven't reviewed it since I'm not sure
> it's appropriate in an environment where the UI should run unprivileged.
> But it just might work.
Yeah, firstboot does have a plugin architecture so making a component is
probably what I want. Can you elaborate on what you mean by component? -
What technologies should I be looking at using?
Thanks, Ben
From bkonrath at redhat.com Fri Oct 5 04:40:12 2007
From: bkonrath at redhat.com (Ben Konrath)
Date: Fri, 05 Oct 2007 00:40:12 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191455097.18732.1.camel@oneill.fubar.dk>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
Message-ID: <1191559212.13236.52.camel@toast.toronto.redhat.com>
On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote:
> On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
> > On 10/3/07, David Zeuthen wrote:
> > >
> > > This looks pretty smooth, thanks a lot for working on this. My first
> > > reaction is that this is not something that should be limited to
> > > firstboot; ideally stuff like that should be able to run from the
> > > desktop environment when adding / deleting / managing users, right?
> >
> > We had a design session on this; the idea was actually that you could
> > create new users from the login dialog (GDM).
>
> I agree that's an interesting idea that would replace the need for a
> firstboot module (and probably firstboot entirely). However, I think
> it's still needed as a program you can launch in the desktop session
> along with an icon in System->Administration. If only we had a component
> system...
If the account creation was only in gdm, how would a user know that they
need to create an account before they login? - would this be an obvious
step? IMO presenting the account creation in firstboot is the way to let
a user know that they should create a user account. And since the code
would be reused from the other account creation code it shouldn't be too
hard to create the module.
Ben
From bclark at redhat.com Fri Oct 5 14:47:24 2007
From: bclark at redhat.com (Bryan Clark)
Date: Fri, 5 Oct 2007 10:47:24 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191559212.13236.52.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191455097.18732.1.camel@oneill.fubar.dk>
<1191559212.13236.52.camel@toast.toronto.redhat.com>
Message-ID: <4600a0ae0710050747u2e4d3067n9294b2875bc7b987@mail.gmail.com>
On 10/5/07, Ben Konrath wrote:
>
> On Wed, 2007-10-03 at 19:44 -0400, David Zeuthen wrote:
> > On Wed, 2007-10-03 at 18:09 -0400, Colin Walters wrote:
> > > On 10/3/07, David Zeuthen wrote:
> > > >
> > > > This looks pretty smooth, thanks a lot for working on this. My first
> > > > reaction is that this is not something that should be limited to
> > > > firstboot; ideally stuff like that should be able to run from the
> > > > desktop environment when adding / deleting / managing users, right?
> > >
> > > We had a design session on this; the idea was actually that you could
> > > create new users from the login dialog (GDM).
> >
> > I agree that's an interesting idea that would replace the need for a
> > firstboot module (and probably firstboot entirely). However, I think
> > it's still needed as a program you can launch in the desktop session
> > along with an icon in System->Administration. If only we had a component
> > system...
>
> If the account creation was only in gdm, how would a user know that they
> need to create an account before they login? - would this be an obvious
> step?
If there are no accounts listed in the GDM user list then you'd have to
create one. GDM could even prompt for this since it knows if user accounts
are present (or rather it has a blacklist of non-user accounts). The
thought was that GDM could easily make it obvious that you needed to create
a user account when none existed by prompting you. (i.e. if
(user_accounts.length == 0) { show_account_creation_dialog(); } ).
The other reason GDM was a good entry point for creating accounts was
because in (fast) user switching scenarios you will be shown the GDM screen
to login as another user, if another user doesn't exist you might want to
create them at that point instead of switching back to your original user
and finding the system-* dialog that allows that.
~ Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From davidz at redhat.com Fri Oct 5 15:26:59 2007
From: davidz at redhat.com (David Zeuthen)
Date: Fri, 05 Oct 2007 11:26:59 -0400
Subject: esc by default?
In-Reply-To: <20071004203900.5b98d6e5@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
Message-ID: <1191598019.17992.1.camel@oneill.fubar.dk>
On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
> That's an argument for having it on the install media, but not an
> argument to install it by default.
Bogus. Extend this argument to other device drivers etc. and you pretty
soon have a system that won't install / work anywhere.
David
From skvidal at fedoraproject.org Fri Oct 5 15:44:48 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 05 Oct 2007 11:44:48 -0400
Subject: esc by default?
In-Reply-To: <1191598019.17992.1.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
Message-ID: <1191599088.6741.128.camel@cutter>
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
> On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
> > That's an argument for having it on the install media, but not an
> > argument to install it by default.
>
> Bogus. Extend this argument to other device drivers etc. and you pretty
> soon have a system that won't install / work anywhere.
extend it in the other direction and pretty soon you have a system that
won't be able to fit on any media, anywhere.
I think the point we're making here is that we need to find a happy
balance. I think smart cards are obscure enough to not include them by
default.
-sv
From mclasen at redhat.com Fri Oct 5 15:55:17 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 05 Oct 2007 11:55:17 -0400
Subject: esc by default?
In-Reply-To: <1191598019.17992.1.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
Message-ID: <1191599717.23375.1.camel@localhost.localdomain>
On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
> On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
> > That's an argument for having it on the install media, but not an
> > argument to install it by default.
>
> Bogus. Extend this argument to other device drivers etc. and you pretty
> soon have a system that won't install / work anywhere.
I have a hard time imagining a system that won't install because of
missing smart card drivers.
From davidz at redhat.com Fri Oct 5 15:52:44 2007
From: davidz at redhat.com (David Zeuthen)
Date: Fri, 05 Oct 2007 11:52:44 -0400
Subject: new user creation module in firstboot
In-Reply-To: <1191559165.13236.51.camel@toast.toronto.redhat.com>
References: <1191440044.7817.28.camel@toast.toronto.redhat.com>
<1191448289.3414.22.camel@oneill.fubar.dk>
<1191559165.13236.51.camel@toast.toronto.redhat.com>
Message-ID: <1191599564.17992.21.camel@oneill.fubar.dk>
On Fri, 2007-10-05 at 00:39 -0400, Ben Konrath wrote:
> > Finally, it would be good to have this feature as a "Component" so it's
> > easy to embed into other applications; e.g. if I want to write a OS
> > installer app, then I can easily embed this component. Same, FWIW, goes
> > for the work we're doing on the clock applet and in the future any
> > system configuration bits. I think firstboot has /some/ notion of
> > plug-in architecture but actually haven't reviewed it since I'm not sure
> > it's appropriate in an environment where the UI should run unprivileged.
> > But it just might work.
>
> Yeah, firstboot does have a plugin architecture so making a component is
> probably what I want. Can you elaborate on what you mean by component? -
> What technologies should I be looking at using?
Unfortunately not, hence why I used quotes around component above.
There's things like Bonobo, KParts, COM, Eclipse extensions, Mono addins
etc.. In NetworkManager, for VPN plugins, we use (or used too, don't
know how it works post 0.6) a pretty simplistic in-process approach (not
even GObject based)
http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RELEASE/vpn-daemons/README?revision=1545&view=markup
http://svn.gnome.org/viewcvs/NetworkManager/branches/NETWORKMANAGER_0_6_0_RELEASE/gnome/vpn-properties/nm-vpn-ui-interface.h?revision=1545&view=markup
whereby the UI for managing VPN connections would load a GModule
providing the UI and functionality (there's at least three different
open source plug-ins at this point). Nautilus has a similar concept with
it's extension system; see the nautilus-devel package and some of the
extensions.
The idea was simply that this functionality, along with other things
(such as selecting your location/timezone etc.), would be targets for
embedding in, say, containers like the OS installer, firstboot, gdm or
whatever. Depending on the audience for the OS (or spin), you'd select
where each component then goes. For example for home-user oriented
desktops you'd want everything to go into the live cd installer, for
other targets you want something else.
I'm not really sure it's worth worrying about at this point; I'd just
focus on creating a single program for now then it can always be
retrofitted it into one or more component system later on (and it sounds
like you want a firstboot module as well so perhaps writing the program
as a library might be a good idea too).
Anyway, I'll stop the architecture astronaut thing now (need air!) but I
thought it was important to mention that retrofitting the code so it can
be used in different contexts is desirable.
David
From davidz at redhat.com Fri Oct 5 16:06:40 2007
From: davidz at redhat.com (David Zeuthen)
Date: Fri, 05 Oct 2007 12:06:40 -0400
Subject: esc by default?
In-Reply-To: <1191599088.6741.128.camel@cutter>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
<1191599088.6741.128.camel@cutter>
Message-ID: <1191600400.17992.37.camel@oneill.fubar.dk>
On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
> > On Thu, 2007-10-04 at 20:39 -0400, Jesse Keating wrote:
> > > That's an argument for having it on the install media, but not an
> > > argument to install it by default.
> >
> > Bogus. Extend this argument to other device drivers etc. and you pretty
> > soon have a system that won't install / work anywhere.
>
> extend it in the other direction and pretty soon you have a system that
> won't be able to fit on any media, anywhere.
>
> I think the point we're making here is that we need to find a happy
> balance. I think smart cards are obscure enough to not include them by
> default.
Maybe. But it shouldn't have to be that way; smart cards (or anything
where you verify more than one thing about the user (e.g. the classic
something you a) have; b) know; c) are) are inherently more secure than
just passwords and SSH keys. Hence, I think we should be interested in
getting this working. Same for thinkfinger; people are doing very good
work at integrating this into the distro.
(Heck, if I'm a big company interested in this I should be able to
participate in the Fedora project and get my stuff into the distro so it
Just Works(tm) out of the box. Maybe even offer some or all Fedora
developers a smart card. Just a thought.)
But you're right; it's about balance; there's a couple of kernel drivers
we don't ship because they're just too obscure. Or they're too buggy. Or
too bloated. Whatever. Ideally our OS should be able to detect the
hardware and properly request for the driver / enabling software to be
installed (clearly, this won't work for kernel drivers now that kmod's
are banned but there's a lot of other stuff in userspace).
(I do think, however, that pscs-lite and esc should be installed by
default as soon they've fixed their resource consumption issues; at
least until our OS is smart enough to detect what RPM's to install when
we see the hardware [1])
David
[1] : e.g. modalias; the package will have a
Provides: usb:v413Cp8103d2422dcE0dsc01dp01icFEisc01ip00
From jdennis at redhat.com Fri Oct 5 16:37:52 2007
From: jdennis at redhat.com (John Dennis)
Date: Fri, 05 Oct 2007 12:37:52 -0400
Subject: esc by default?
In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy>
<47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter>
<1191600400.17992.37.camel@oneill.fubar.dk>
Message-ID: <47066860.4020603@redhat.com>
David Zeuthen wrote:
> On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
>> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
>> I think the point we're making here is that we need to find a happy
>> balance. I think smart cards are obscure enough to not include them by
>> default.
>
> Maybe. But it shouldn't have to be that way; smart cards (or anything
> where you verify more than one thing about the user (e.g. the classic
> something you a) have; b) know; c) are) are inherently more secure than
> just passwords and SSH keys. Hence, I think we should be interested in
> getting this working. Same for thinkfinger; people are doing very good
> work at integrating this into the distro.
Everything Red Hat is doing is driving towards the use of stronger
authentication. We have made huge monetary investments in this area.
Fedora is supposed to be a test ground for emerging technology,
especially emerging technology be driven by us. These observations
should help answer the question of whether these packages should be
candidates for default installation because that will help move the
technology forward we have a vested interest in.
--
John Dennis
From sundaram at fedoraproject.org Fri Oct 5 16:41:12 2007
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 05 Oct 2007 22:11:12 +0530
Subject: esc by default?
In-Reply-To: <47066860.4020603@redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk>
<47066860.4020603@redhat.com>
Message-ID: <47066928.9070700@fedoraproject.org>
John Dennis wrote:
> David Zeuthen wrote:
>> On Fri, 2007-10-05 at 11:44 -0400, seth vidal wrote:
>>> On Fri, 2007-10-05 at 11:26 -0400, David Zeuthen wrote:
>>> I think the point we're making here is that we need to find a happy
>>> balance. I think smart cards are obscure enough to not include them by
>>> default.
>>
>> Maybe. But it shouldn't have to be that way; smart cards (or anything
>> where you verify more than one thing about the user (e.g. the classic
>> something you a) have; b) know; c) are) are inherently more secure than
>> just passwords and SSH keys. Hence, I think we should be interested in
>> getting this working. Same for thinkfinger; people are doing very good
>> work at integrating this into the distro.
>
> Everything Red Hat is doing is driving towards the use of stronger
> authentication. We have made huge monetary investments in this area.
It be would useful if some of the investments were directed to not
making ti start by default unnecessary. The majority of end users in
Fedora are unlikely to be using smart cards anytime soon unlike the
audience for RHEL.
Rahul
From jspaleta at gmail.com Fri Oct 5 18:48:45 2007
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 5 Oct 2007 10:48:45 -0800
Subject: esc by default?
In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
<1191599088.6741.128.camel@cutter>
<1191600400.17992.37.camel@oneill.fubar.dk>
Message-ID: <604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com>
On 10/5/07, David Zeuthen wrote:
> But you're right; it's about balance; there's a couple of kernel drivers
> we don't ship because they're just too obscure. Or they're too buggy. Or
> too bloated. Whatever. Ideally our OS should be able to detect the
> hardware and properly request for the driver / enabling software to be
> installed (clearly, this won't work for kernel drivers now that kmod's
> are banned but there's a lot of other stuff in userspace).
Detection of this at install time? Even if all the pieces to do that
are available, doesn't that require some significant re-think in
installer package management? At the very least we'd have to have a
list of packages associated which each sort of hardware detection flag
that could be parsed by the installer. Using what we have currently as
a starting point, you'd essentially have to group things in a comps
group associated with each detection criteria, and then teach anaconda
to set that group to install by default if the detection criteria is
met.
And when installing from livecd targets... could you discriminate in a
similar fashion and only install to disk the hardware specific
userspace bits that system needed? I think that'd be tougher since the
livecd's install a pre-cooked disk image with all the bells and
whistles already installed.
-jef
From davidz at redhat.com Fri Oct 5 19:01:30 2007
From: davidz at redhat.com (David Zeuthen)
Date: Fri, 05 Oct 2007 15:01:30 -0400
Subject: esc by default?
In-Reply-To: <604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
<1191599088.6741.128.camel@cutter>
<1191600400.17992.37.camel@oneill.fubar.dk>
<604aa7910710051148q2ac61488obecc3684313112d1@mail.gmail.com>
Message-ID: <1191610890.7397.17.camel@oneill.fubar.dk>
On Fri, 2007-10-05 at 10:48 -0800, Jeff Spaleta wrote:
> On 10/5/07, David Zeuthen wrote:
> > But you're right; it's about balance; there's a couple of kernel drivers
> > we don't ship because they're just too obscure. Or they're too buggy. Or
> > too bloated. Whatever. Ideally our OS should be able to detect the
> > hardware and properly request for the driver / enabling software to be
> > installed (clearly, this won't work for kernel drivers now that kmod's
> > are banned but there's a lot of other stuff in userspace).
>
> Detection of this at install time?
No, it's basically the wrong mindset to think that we only need to
detect hardware at install time; with hot pluggable buses like USB,
Firewire, whatever, hardware can come and go at any time. So any
solution that only works at install time is just fundamentally wrong.
In fact, the installer just be just an installer; not it's own little OS
with it's own private hardware detection routines; that kind of services
should be part of the core OS and the installer should take advantage of
it as should the environment the user normally use too (e.g. the desktop
or commandline tools)
> Even if all the pieces to do that
> are available, doesn't that require some significant re-think in
> installer package management? At the very least we'd have to have a
> list of packages associated which each sort of hardware detection flag
> that could be parsed by the installer. Using what we have currently as
> a starting point, you'd essentially have to group things in a comps
> group associated with each detection criteria, and then teach anaconda
> to set that group to install by default if the detection criteria is
> met.
Yes, it's a can of worms; basically what most "Enterprise" distros do
(because they have a kABI and support vendor drivers not shipped with
the OS etc.) is to use RPM Provides: with the modalias for what the
driver in the RPM support. So it goes like this
1. Plug in your hardware
2. Find the modalias for the device (look e.g. in sysfs)
3. yum search $modalias
4. yum install package-that-you-found
It's not really difficult to imagine this could be automated; you'd have
a small tray icon saying "yo, I don't have a driver for this device;
would you like to search for one?".
Of course the party line of Fedora is (or used to be) that we install
all drivers in the default install and that renders the problem moot. In
fact, I think it's a bit silly to build all this infrastructure just
because
- we've changed the party line from "we ship all drivers in the default
install" to "we don't ship all drivers in the default install". This
kind of baffles me; I'm not really sure DVD space and hard disk space
is that expensive.
- it creates the illusion that Fedora has a stable kABI; that's just
wrong
- it'll never work for kernel drivers anyway and the majority of
interesting drivers are indeed in the kernel
- it's just plain annoying having to click through crap like that
just because we decided not to ship all drivers in the default
install. Of course, such a gizmo has the side effect to tell
you if the hardware you just plugged in is supported or not so
we may end up doing something similar *anyway*.
> And when installing from livecd targets... could you discriminate in a
> similar fashion and only install to disk the hardware specific
> userspace bits that system needed? I think that'd be tougher since the
> livecd's install a pre-cooked disk image with all the bells and
> whistles already installed.
I can't really see what's wrong with "we ship all drivers in the default
install" but if we want to change it we need some of that silly
infrastructure above to make the system Just Work(tm) when you e.g. plug
in a USB smart card reader.
David
From notting at redhat.com Fri Oct 5 19:12:37 2007
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 5 Oct 2007 15:12:37 -0400
Subject: esc by default?
In-Reply-To: <1191600400.17992.37.camel@oneill.fubar.dk>
References: <20071004170054.GA7448@nostromo.devel.redhat.com>
<1191525200.18627.1.camel@kennedy> <47055207.6090707@redhat.com>
<20071004203900.5b98d6e5@redhat.com>
<1191598019.17992.1.camel@oneill.fubar.dk>
<1191599088.6741.128.camel@cutter>
<1191600400.17992.37.camel@oneill.fubar.dk>
Message-ID: <20071005191237.GA28973@nostromo.devel.redhat.com>
David Zeuthen (davidz at redhat.com) said:
> I do think, however, that pscs-lite and esc should be installed by
> default as soon they've fixed their resource consumption issues;
I have no problems with that. But running a separate daemon and xulrunner
stack on login for hardware that a fairly minute fraction of our users
will ever have isn't really up to snuff right now.
Bill
From jmagne at redhat.com Fri Oct 5 20:29:54 2007
From: jmagne at redhat.com (Jack Magne)
Date: Fri, 05 Oct 2007 13:29:54 -0700
Subject: esc by default?
In-Reply-To: <20071005191237.GA28973@nostromo.devel.redhat.com>
References: <20071004170054.GA7448@nostromo.devel.redhat.com> <1191525200.18627.1.camel@kennedy>
<47055207.6090707@redhat.com> <20071004203900.5b98d6e5@redhat.com> <1191598019.17992.1.camel@oneill.fubar.dk> <1191599088.6741.128.camel@cutter> <1191600400.17992.37.camel@oneill.fubar.dk>
<20071005191237.GA28973@nostromo.devel.redhat.com>
Message-ID: <47069EC2.7080409@redhat.com>
Thanks everyone for the thoughtful responses and suggestions.
We will continue to work to solve these issues.
thanks,
jack
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL:
From mclasen at redhat.com Wed Oct 10 16:05:20 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 10 Oct 2007 12:05:20 -0400
Subject: Desktop SIG meeting
Message-ID: <1192032320.6464.3.camel@localhost.localdomain>
...should take place again today, at 18:00 UTC.
Possible things to talk about are pressing issues that need to be
adressed before F8 (ie F8Blocker / F8Target bugs) and what is planned
for F9.
From detonated at o2.pl Sun Oct 14 08:01:08 2007
From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=)
Date: Sun, 14 Oct 2007 10:01:08 +0200
Subject: madwifi in fedora 8
Message-ID: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl>
Good morning,
I wonder why madwifi was not included in fedora 6 & 7 by default.
I had a big trouble configuring my wireless network.
Will it be included in fedora 8?
Greetings
From martin at gamesplace.info Sun Oct 14 10:32:52 2007
From: martin at gamesplace.info (Martin =?ISO-8859-1?Q?J=FCrgens?=)
Date: Sun, 14 Oct 2007 12:32:52 +0200
Subject: madwifi in fedora 8
In-Reply-To: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl>
References: <14f64136.23bccf1e.4711ccc4.9bfa6@o2.pl>
Message-ID: <1192357972.3032.4.camel@localhost6.localdomain6>
Hi!
The reason for this is that some parts of madwifi are non-free (the
HAL).
The Fedora project decided not to ship non-free parts, which includes
proprietary ATI drivers, proprietary NVIDIA drivers and Madwifi in order
to encourage the vendors to publish specifications and / or free
drivers. This worked for ATI, and we will have free drivers supporting
newer chipsets available soon.
Fedora 8 will ship with ath5k, which is open source and supports Atheros
chipsets, also. The madwifi developers develop it now.
Martin
Am Sonntag, den 14.10.2007, 10:01 +0200 schrieb a3ukasz Peb3szynski:
> Good morning,
> I wonder why madwifi was not included in fedora 6 & 7 by default.
> I had a big trouble configuring my wireless network.
> Will it be included in fedora 8?
>
> Greetings
>
From detonated at o2.pl Wed Oct 17 15:47:15 2007
From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=)
Date: Wed, 17 Oct 2007 17:47:15 +0200
Subject: how to run fedora 8 test 3
Message-ID:
Good afternoon,
First of all I'd like to thank Martin Jorgens for his answer to my question about madwifi.
My today's question:
Is there any way to log in after booting F8 test 3 live cd ?
Looks like there's an error, becuse counter on gdm screen goes below zero.
Has anyone noticed that and if so, how did you solve it ?
Thanks in advance.
Lukasz Pelszynski
From martin at gamesplace.info Wed Oct 17 16:34:11 2007
From: martin at gamesplace.info (Martin =?ISO-8859-1?Q?J=FCrgens?=)
Date: Wed, 17 Oct 2007 18:34:11 +0200
Subject: how to run fedora 8 test 3
In-Reply-To:
References:
Message-ID: <1192638851.2914.16.camel@localhost6.localdomain6>
Hi!
This is related to a ath5k bug in the kernel, see
https://bugzilla.redhat.com/show_bug.cgi?id=254192
I run into the same problem having my Atheros card plugged in, but when
I remove it out of my computer, everything works fine.
I did not yet find a way to run Fedora 8 Test 3 live cd successfully
having the Atheros card plugged in.
Martin
Am Mittwoch, den 17.10.2007, 17:47 +0200 schrieb a3ukasz Peb3szynski:
> Good afternoon,
>
> First of all I'd like to thank Martin Jorgens for his answer to my question about madwifi.
>
> My today's question:
> Is there any way to log in after booting F8 test 3 live cd ?
> Looks like there's an error, becuse counter on gdm screen goes below zero.
> Has anyone noticed that and if so, how did you solve it ?
> Thanks in advance.
>
> Lukasz Pelszynski
>
From detonated at o2.pl Fri Oct 19 06:33:00 2007
From: detonated at o2.pl (=?UTF-8?Q?a3ukasz_Peb3szynski?=)
Date: Fri, 19 Oct 2007 08:33:00 +0200
Subject: Fedora-desktop-list Digest, Vol 44, Issue 9
In-Reply-To: <20071018160025.C3A8973667@hormel.redhat.com>
References: <20071018160025.C3A8973667@hormel.redhat.com>
Message-ID: <743ce82d.4ffdc8d2.47184f9c.7ed@o2.pl>
> Hi!
>
> This is related to a ath5k bug in the kernel, see
> https://bugzilla.redhat.com/show_bug.cgi?id=254192
...
> Martin
Hi!
I wasn't aware that it might be an ath5k driver. It all looked like gdm's error... but I hope everything will be OK with atheros driver.
Greetings
From mclasen at redhat.com Tue Oct 23 19:27:16 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 23 Oct 2007 15:27:16 -0400
Subject: Desktop SIG meeting tomorrow
Message-ID: <1193167636.16178.6.camel@localhost.localdomain>
I will most likely not around tomorrow, so interested people will have
to self-organize and find something useful to talk about. One topic that
I'll throw on the agenda:
We should pick a different time for the sig meeting, because several
people (jrb, mcepl) said that they have difficulty making the current
time. And from now on, I will only be available until 2:15 on most
Wednesdays, too.
Matthias
From caillon at redhat.com Wed Oct 24 10:22:19 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 24 Oct 2007 06:22:19 -0400
Subject: Desktop SIG meeting tomorrow
In-Reply-To: <1193167636.16178.6.camel@localhost.localdomain>
References: <1193167636.16178.6.camel@localhost.localdomain>
Message-ID: <471F1CDB.8090502@redhat.com>
Matthias Clasen wrote:
> I will most likely not around tomorrow, so interested people will have
> to self-organize and find something useful to talk about. One topic that
> I'll throw on the agenda:
>
> We should pick a different time for the sig meeting, because several
> people (jrb, mcepl) said that they have difficulty making the current
> time. And from now on, I will only be available until 2:15 on most
> Wednesdays, too.
http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
So, I had a look at the schedule above. I propose to move it to 1500
UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start that
schedule until next week since o/~ Tuesday's Gone... Like the Wind. o/~
From wtogami at redhat.com Wed Oct 24 19:51:08 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 24 Oct 2007 15:51:08 -0400
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <1193248515.22958.111.camel@localhost.localdomain>
References:
<1193248515.22958.111.camel@localhost.localdomain>
Message-ID: <471FA22C.8060105@redhat.com>
Tom "spot" Callaway wrote:
> On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote:
>> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8
>> Request description: Inclusion into Fedora 8 final
>>
>> Rationale:
>> Compiz Fusion has been one of the major attraction to Linux lately,
>> and with Ubuntu already providing CF out of the box, users will expect
>> other distros to have it too. There no full featured configurator for
>> current compiz-fusion in F-8.
>>
>> Impact not accepting:
>> Users will have to use gconf-editor to configure compiz-fusion
>> manually. Marketing value might be affected.
>>
>> Others:
>> current compiz in F-8 uses 'glib gconf' as its configuration
>> backend, if FedoraProject decided to use libcompizconfig as the
>> configuration backend, changes are needed in desktop-effects and
>> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM
>> requires compiz to use 'ccp' for it to function properly.
>
> +1
>
Spot, did you notice that this requires changes to desktop-effects and
gnome-session? It sounds like they expect it to be part of the default
install, not just an add-on to the compiz of today. Is the desktop team
aware and in agreement with these changes?
Warren Togami
wtogami at redhat.com
From mclasen at redhat.com Wed Oct 24 19:53:13 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 24 Oct 2007 15:53:13 -0400
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <471FA22C.8060105@redhat.com>
References:
<1193248515.22958.111.camel@localhost.localdomain>
<471FA22C.8060105@redhat.com>
Message-ID: <1193255593.4201.0.camel@localhost.localdomain>
On Wed, 2007-10-24 at 15:51 -0400, Warren Togami wrote:
>
> Spot, did you notice that this requires changes to desktop-effects and
> gnome-session? It sounds like they expect it to be part of the default
> install, not just an add-on to the compiz of today. Is the desktop team
> aware and in agreement with these changes?
>
No and no
From wtogami at redhat.com Wed Oct 24 20:04:44 2007
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 24 Oct 2007 16:04:44 -0400
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <1193255688.22958.114.camel@localhost.localdomain>
References:
<1193248515.22958.111.camel@localhost.localdomain>
<471FA22C.8060105@redhat.com>
<1193255688.22958.114.camel@localhost.localdomain>
Message-ID: <471FA55C.2010100@redhat.com>
Tom "spot" Callaway wrote:
> On Wed, 2007-10-24 at 15:51 -0400, Warren Togami wrote:
>> Tom "spot" Callaway wrote:
>>> On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote:
>>>> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8
>>>> Request description: Inclusion into Fedora 8 final
>>>>
>>>> Rationale:
>>>> Compiz Fusion has been one of the major attraction to Linux lately,
>>>> and with Ubuntu already providing CF out of the box, users will expect
>>>> other distros to have it too. There no full featured configurator for
>>>> current compiz-fusion in F-8.
>>>>
>>>> Impact not accepting:
>>>> Users will have to use gconf-editor to configure compiz-fusion
>>>> manually. Marketing value might be affected.
>>>>
>>>> Others:
>>>> current compiz in F-8 uses 'glib gconf' as its configuration
>>>> backend, if FedoraProject decided to use libcompizconfig as the
>>>> configuration backend, changes are needed in desktop-effects and
>>>> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM
>>>> requires compiz to use 'ccp' for it to function properly.
>>> +1
>>>
>> Spot, did you notice that this requires changes to desktop-effects and
>> gnome-session? It sounds like they expect it to be part of the default
>> install, not just an add-on to the compiz of today. Is the desktop team
>> aware and in agreement with these changes?
>
> Good point, I read this too quickly. :) I pull back my vote, pending
> desktop team signoff.
>
> ~spot
>
We could include the requested packages because they alone are harmless,
but not make the suggested changes to desktop-effects and gnome-session.
Mohd, what exact N-V-R's are you requesting? I would like to inspect them.
Warren Togami
wtogami at redhat.com
From izhar at fedoraproject.org Wed Oct 24 22:16:50 2007
From: izhar at fedoraproject.org (Mohd Izhar Firdaus Ismail)
Date: Thu, 25 Oct 2007 06:16:50 +0800
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <471FA55C.2010100@redhat.com>
References:
<1193248515.22958.111.camel@localhost.localdomain>
<471FA22C.8060105@redhat.com>
<1193255688.22958.114.camel@localhost.localdomain>
<471FA55C.2010100@redhat.com>
Message-ID:
On 10/25/07, Warren Togami wrote:
> We could include the requested packages because they alone are harmless,
> but not make the suggested changes to desktop-effects and gnome-session.
>
> Mohd, what exact N-V-R's are you requesting? I would like to inspect them.
(call me Izhar please, as 'Mohd' is a very common prefix in boys name
in my country, and we dont use firstname-lastname format, but
name-"bin"-fathername instead)
the NVRs are
compizconfig-python-0.6.0-1.fc8
ccsm-0.6.0-3.fc8
you might want to look at libcompizconfig-0.6.0-3.fc8 if its not
included yet, (spec bugfix due to compiz's update to 0.6.2)
thank you
--
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
From bclark at redhat.com Thu Oct 25 12:55:07 2007
From: bclark at redhat.com (Bryan Clark)
Date: Thu, 25 Oct 2007 08:55:07 -0400
Subject: think finger
Message-ID: <4720922B.2080000@redhat.com>
Pushing off from Ben's email on new user creation [1] I wanted to get
some setup for the think finger support that david mentioned [2].
So to start off with some technical questions about think finger, some
of these might be obvious to other people besides me:
Can it's presence be detected automatically? And it's (pam)
authentication be added automatically?
How many times does it take to train think finger support initially?
Can it be (re)trained incrementally? Is this required?
What are the security models required for this? Thinkfinger &&
password? Thinkfinger || password? Just Thinkfinger? My assumption
here is that either is accepted.
Can we get the image from think finger for user feedback? Ray mentioned
we might be able to fake it, which would probably be good enough.
Can we detect / remember the number of failed think finger attempts
before a successful one? This is related to retraining, if it's
possible to retrain the reader or human to scan better over time.
I think that's all for now, I'd like to work off responses.
~ Bryan
[1]
https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00002.html
[2]
https://www.redhat.com/archives/fedora-desktop-list/2007-October/msg00021.html
From skvidal at fedoraproject.org Thu Oct 25 12:58:07 2007
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 25 Oct 2007 08:58:07 -0400
Subject: think finger
In-Reply-To: <4720922B.2080000@redhat.com>
References: <4720922B.2080000@redhat.com>
Message-ID: <1193317087.3517.16.camel@cutter>
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
> Pushing off from Ben's email on new user creation [1] I wanted to get
> some setup for the think finger support that david mentioned [2].
>
> So to start off with some technical questions about think finger, some
> of these might be obvious to other people besides me:
>
> Can it's presence be detected automatically? And it's (pam)
> authentication be added automatically?
It's a device it should be able to be looked up in hal.
> How many times does it take to train think finger support initially?
3 good finger swipes that it checks against one another.
> Can it be (re)trained incrementally? Is this required?
not that I've seen.
>
> What are the security models required for this? Thinkfinger &&
> password? Thinkfinger || password? Just Thinkfinger? My assumption
> here is that either is accepted.
I tested it on my rawhide laptop and while afaict thinkfinger doesn't
care gdm and logins and everything else are unprepared for 2-factor
auth. They'll accept a finger swipe or a password but cannot handle it
if your pam config requires both.
> Can we get the image from think finger for user feedback? Ray mentioned
> we might be able to fake it, which would probably be good enough.
the image of your fingerprint?
-sv
From mclasen at redhat.com Thu Oct 25 13:09:23 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 25 Oct 2007 09:09:23 -0400
Subject: think finger
In-Reply-To: <1193317087.3517.16.camel@cutter>
References: <4720922B.2080000@redhat.com> <1193317087.3517.16.camel@cutter>
Message-ID: <1193317763.3598.1.camel@localhost.localdomain>
On Thu, 2007-10-25 at 08:58 -0400, seth vidal wrote:
> > Can we get the image from think finger for user feedback? Ray mentioned
> > we might be able to fake it, which would probably be good enough.
>
> the image of your fingerprint?
>
I had to give up my fingerprints to the USCIS recently, and they have
impressive scanners that show you your fingerprint in fullscreen.
Unfortunately, the fingerprint scanners of your average laptop don't
produce anything near that resolution. There simply is no image to
show...
From rstrode at redhat.com Thu Oct 25 14:00:12 2007
From: rstrode at redhat.com (Ray Strode)
Date: Thu, 25 Oct 2007 10:00:12 -0400
Subject: think finger
In-Reply-To: <4720922B.2080000@redhat.com>
References: <4720922B.2080000@redhat.com>
Message-ID: <4720A16C.5080102@redhat.com>
Hi,
>
> Can we get the image from think finger for user feedback? Ray
> mentioned we might be able to fake it, which would probably be good
> enough.
To be clear, what I was saying was:
- It would be really cool if we could show a finger print on screen when
the user scans their finger
- The fingerprint wouldn't have to be the user's fingerprint, just as
long as it looked like a fingerprint and looked different than other
people's fingerprints
I don't know what fingerprint scanners store (actual image data, or just
enough information to identify the print or what). Even if we don't
have a full image to show, we could potentially just perturb a fake
fingerprint seeded by whatever data we do have.
Having said that, I think some scanners do give image data. David
pointed me to this post he made a long time ago:
http://blog.fubar.dk/?p=35
--Ray
From katzj at redhat.com Thu Oct 25 14:06:13 2007
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 25 Oct 2007 10:06:13 -0400
Subject: think finger
In-Reply-To: <4720922B.2080000@redhat.com>
References: <4720922B.2080000@redhat.com>
Message-ID: <1193321173.8896.43.camel@localhost.localdomain>
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
> Pushing off from Ben's email on new user creation [1] I wanted to get
> some setup for the think finger support that david mentioned [2].
I'd actually like to make it a teensy bit more general and think about
the non-Thinkfinger readers also. From my Pile Of Laptops, the
Authentec readers are pretty common. And davidz has already done some
prodding with them based on his blog ;)
While not very relevant to the interaction, it's mostly important so
that we don't make assumptions of hardware capabilities that may or may
not be present.
> Can it's presence be detected automatically? And it's (pam)
> authentication be added automatically?
They're all usb devices, so pretty detectable. Adding the pam config is
just a matter of deciding we're doing it and then adding to the stacks
written out by authconfig
> How many times does it take to train think finger support initially?
This probably depends on the hardware. Thinkfinger is 3 swipes and
trained in hardware. Some of the other readers just give you back an
image and you have to do verification[1] on your own. But probably 3 is
a reasonable guess there too. It's at least the range of "more than
one, less than many"
> Can it be (re)trained incrementally? Is this required?
Nope, you pretty much have to do the initial readings upfront.
> Can we get the image from think finger for user feedback? Ray mentioned
> we might be able to fake it, which would probably be good enough.
This is definitely going to be dependent on the hardware, so probably
can't be counted on.
> Can we detect / remember the number of failed think finger attempts
> before a successful one? This is related to retraining, if it's
> possible to retrain the reader or human to scan better over time.
PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think.
Jeremy
From krh at bitplanet.net Thu Oct 25 14:16:02 2007
From: krh at bitplanet.net (=?UTF-8?Q?Kristian_H=C3=B8gsberg?=)
Date: Thu, 25 Oct 2007 10:16:02 -0400
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <471FA22C.8060105@redhat.com>
References:
<1193248515.22958.111.camel@localhost.localdomain>
<471FA22C.8060105@redhat.com>
Message-ID: <59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com>
On 10/24/07, Warren Togami wrote:
> Tom "spot" Callaway wrote:
> > On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote:
> >> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8
> >> Request description: Inclusion into Fedora 8 final
> >>
> >> Rationale:
> >> Compiz Fusion has been one of the major attraction to Linux lately,
> >> and with Ubuntu already providing CF out of the box, users will expect
> >> other distros to have it too. There no full featured configurator for
> >> current compiz-fusion in F-8.
> >>
> >> Impact not accepting:
> >> Users will have to use gconf-editor to configure compiz-fusion
> >> manually. Marketing value might be affected.
> >>
> >> Others:
> >> current compiz in F-8 uses 'glib gconf' as its configuration
> >> backend, if FedoraProject decided to use libcompizconfig as the
> >> configuration backend, changes are needed in desktop-effects and
> >> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM
> >> requires compiz to use 'ccp' for it to function properly.
> >
> > +1
> >
>
> Spot, did you notice that this requires changes to desktop-effects and
> gnome-session? It sounds like they expect it to be part of the default
> install, not just an add-on to the compiz of today. Is the desktop team
> aware and in agreement with these changes?
This has come up before, and while it would be nice to have a more
capable configuration program for compiz the current libcompizconfig
is not the right solution. Ideally we would have a configuration
application per desktop environment and the GNOME configurator would
just talk to gconf directly, similarly for the KDE configurator.
If somebody wants to write a settings manager that works with several
DEs, I think the burden is on the settings manager to talk to the
different configuration systems it wants to operate under. Or this
could be part of libcompizconfig, so that setting managers that want
to be DE-agnostic can just link to this library and not worry about
the underlying config mechanism in use.
The current compiz setup is compatible with the above scheme, somebody
just need to do the necessary libcompizconfig adjustments.
thanks,
Kristiani
From bnocera at redhat.com Thu Oct 25 14:54:44 2007
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 25 Oct 2007 15:54:44 +0100
Subject: think finger
In-Reply-To: <1193321173.8896.43.camel@localhost.localdomain>
References: <4720922B.2080000@redhat.com>
<1193321173.8896.43.camel@localhost.localdomain>
Message-ID: <1193324084.25405.144.camel@cookie.hadess.net>
Heya,
On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote:
> On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
> > Pushing off from Ben's email on new user creation [1] I wanted to get
> > some setup for the think finger support that david mentioned [2].
>
> I'd actually like to make it a teensy bit more general and think about
> the non-Thinkfinger readers also. From my Pile Of Laptops, the
> Authentec readers are pretty common. And davidz has already done some
> prodding with them based on his blog ;)
The plan for the F9 feature[1] was to not use pam_thinkfinger (it's real
crap, and has some gross hacks, such as sending line feeds to accept
password auth), and switch to a dbus service instead (so that we don't
do threading in pam_thinkfinger).
The dbus service would be a HAL singleton, and we could obviously use a
different implementation that could drive Authentec readers, or any
other, given a sane API.
> While not very relevant to the interaction, it's mostly important so
> that we don't make assumptions of hardware capabilities that may or may
> not be present.
>
> > Can it's presence be detected automatically? And it's (pam)
> > authentication be added automatically?
>
> They're all usb devices, so pretty detectable. Adding the pam config is
> just a matter of deciding we're doing it and then adding to the stacks
> written out by authconfig
And for which PAM services we'd want to enable this.
Cheers
From davidz at redhat.com Thu Oct 25 21:57:38 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 25 Oct 2007 17:57:38 -0400
Subject: think finger
In-Reply-To: <1193321173.8896.43.camel@localhost.localdomain>
References: <4720922B.2080000@redhat.com>
<1193321173.8896.43.camel@localhost.localdomain>
Message-ID: <1193349458.4248.51.camel@oneill.fubar.dk>
On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote:
> On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
> > Pushing off from Ben's email on new user creation [1] I wanted to get
> > some setup for the think finger support that david mentioned [2].
>
> I'd actually like to make it a teensy bit more general and think about
> the non-Thinkfinger readers also. From my Pile Of Laptops, the
> Authentec readers are pretty common. And davidz has already done some
> prodding with them based on his blog ;)
So the one way to do this sanely is to build a simple API that will work
for our purposes; e.g. make it high-level driven by application
requirements. Since messing around with auth tokens / whatever is a
privileged operation, expose it over D-Bus and lock it down via
PolicyKit. It doesn't need to be more complicated than the API offered
by tf-tool
> # tf-tool --help
>
> ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/)
> Copyright (C) 2006, 2007 Timo Hoenig
>
> Usage: tf-tool [--acquire | --verify | --add-user |
> --verify-user ] [--verbose]
Notably, to make fingerprint enrollment work in a sane way (we're so not
going to do crazy stuff like running X11 apps as root) _anyway_ you need
to expose it over D-Bus. And, really, it's pretty trivial, only a matter
of a few hours in C; see
http://blog.fubar.dk/?p=94
on details how to do it. Hey, you can even do it in Python and since it
only involves shelling out to tf-tool, it's probably on the order of
hundreds of lines. Now, when we have this API we'll just merge the
following properties on the hal device object
info.capabilities += 'fingerprint_reader'
fingerprint_reader.dbus_service = 'com.example.ThinkfingerService'
fingerprint_reader.dbus_obj = '/'
fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
so if someone wants to do Authentec or whatever they just do a D-Bus and
make an object that implements the org.freedesktop.FingerPrinterReader
D-Bus interface. Then they merge
info.capabilities += 'fingerprint_reader'
fingerprint_reader.dbus_service = 'com.example.AuthentecService'
fingerprint_reader.dbus_obj = '/'
fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
Our UI apps simply don't care what fingerprint_reader.dbus_service is;
they only care about poking an object with the D-Bus interface
org.freedesktop.FingerPrinterReader. So the UI simply does
1. hal.find_by_caps('fingerprint_reader')
2. read .dbus_service, .dbus_obj, .dbus_iface
3. checks that .dbus_iface=='org.freedesktop.FingerPrinterReader'
4. calls into the service
5. profit
David
>
> While not very relevant to the interaction, it's mostly important so
> that we don't make assumptions of hardware capabilities that may or may
> not be present.
>
> > Can it's presence be detected automatically? And it's (pam)
> > authentication be added automatically?
>
> They're all usb devices, so pretty detectable. Adding the pam config is
> just a matter of deciding we're doing it and then adding to the stacks
> written out by authconfig
>
> > How many times does it take to train think finger support initially?
>
> This probably depends on the hardware. Thinkfinger is 3 swipes and
> trained in hardware. Some of the other readers just give you back an
> image and you have to do verification[1] on your own. But probably 3 is
> a reasonable guess there too. It's at least the range of "more than
> one, less than many"
>
> > Can it be (re)trained incrementally? Is this required?
>
> Nope, you pretty much have to do the initial readings upfront.
>
> > Can we get the image from think finger for user feedback? Ray mentioned
> > we might be able to fake it, which would probably be good enough.
>
> This is definitely going to be dependent on the hardware, so probably
> can't be counted on.
>
> > Can we detect / remember the number of failed think finger attempts
> > before a successful one? This is related to retraining, if it's
> > possible to retrain the reader or human to scan better over time.
>
> PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think.
>
> Jeremy
>
From davidz at redhat.com Thu Oct 25 22:05:21 2007
From: davidz at redhat.com (David Zeuthen)
Date: Thu, 25 Oct 2007 18:05:21 -0400
Subject: think finger
In-Reply-To: <1193324084.25405.144.camel@cookie.hadess.net>
References: <4720922B.2080000@redhat.com>
<1193321173.8896.43.camel@localhost.localdomain>
<1193324084.25405.144.camel@cookie.hadess.net>
Message-ID: <1193349921.4248.58.camel@oneill.fubar.dk>
On Thu, 2007-10-25 at 15:54 +0100, Bastien Nocera wrote:
> The dbus service would be a HAL singleton, and we could obviously use a
> different implementation that could drive Authentec readers, or any
> other, given a sane API.
Maybe a bit off-topic, but as I said in my other mail, now that we have
D-Bus system bus activation, the current advice from the HAL team is to
use dedicated services (with standardized interfaces) and use HAL as the
directory for looking up the service. That way, there's no HAL
dependencies which gives us more freedom to rewrite HAL.
(More off-topic but perhaps interesting: As a matter of fact, I talked
to Marcel Holtmann about this and it's probably how Bluetooth and
Wireless USB audio (and other cloud services) is going to work; the
interface will be exactly the same (org.fd.WirelessAudio or whatever)
but the services providing them will differ e.g. org.bluez.Audio,
org.wusb.Audio and so. The main consumer for Fedora of this, PulseAudio,
thus does not need to care at all about the _implementation_ (only the
interface) and it will enable us to plug new wireless protocols in
without modifying any consumers.)
David
From izhar at fedoraproject.org Fri Oct 26 12:50:22 2007
From: izhar at fedoraproject.org (Mohd Izhar Firdaus Ismail)
Date: Fri, 26 Oct 2007 20:50:22 +0800
Subject: Request for inclusion of compizconfig-python and ccsm into F-8
In-Reply-To: <59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com>
References:
<1193248515.22958.111.camel@localhost.localdomain>
<471FA22C.8060105@redhat.com>
<59ad55d30710250716i726523a4ua216fa754299836a@mail.gmail.com>
Message-ID:
On 10/25/07, Kristian H?gsberg wrote:
> On 10/24/07, Warren Togami wrote:
> > Tom "spot" Callaway wrote:
> > > On Thu, 2007-10-25 at 01:28 +0800, Mohd Izhar Firdaus Ismail wrote:
> > >> Package: compizconfig-python-0.6.0-1.fc8 , ccsm-0.6.0-3.fc8
> > >> Request description: Inclusion into Fedora 8 final
> > >>
> > >> Rationale:
> >> Compiz Fusion has been one of the major attraction to Linux lately,
> > >> and with Ubuntu already providing CF out of the box, users will expect
> > >> other distros to have it too. There no full featured configurator for
> > >> current compiz-fusion in F-8.
> > >>
> > >> Impact not accepting:
> > >> Users will have to use gconf-editor to configure compiz-fusion
> > >> manually. Marketing value might be affected.
> > >>
> > >> Others:
> > >> current compiz in F-8 uses 'glib gconf' as its configuration
> > >> backend, if FedoraProject decided to use libcompizconfig as the
> > >> configuration backend, changes are needed in desktop-effects and
> > >> /usr/bin/gnome-wm to load 'ccp' plugin instead of 'glib gconf'. CCSM
> > >> requires compiz to use 'ccp' for it to function properly.
> > >
> > > +1
> > >
> >
> > Spot, did you notice that this requires changes to desktop-effects and
> > gnome-session? It sounds like they expect it to be part of the default
> > install, not just an add-on to the compiz of today. Is the desktop team
> > aware and in agreement with these changes?
>
> This has come up before, and while it would be nice to have a more
> capable configuration program for compiz the current libcompizconfig
> is not the right solution. Ideally we would have a configuration
> application per desktop environment and the GNOME configurator would
> just talk to gconf directly, similarly for the KDE configurator.
>
> If somebody wants to write a settings manager that works with several
> DEs, I think the burden is on the settings manager to talk to the
> different configuration systems it wants to operate under. Or this
> could be part of libcompizconfig, so that setting managers that want
> to be DE-agnostic can just link to this library and not worry about
> the underlying config mechanism in use.
>
> The current compiz setup is compatible with the above scheme, somebody
> just need to do the necessary libcompizconfig adjustments.
Thanks Kristian for the input ..
compizconfig-backend-gconf-0.6.0-2.fc8 has just been built in koji (i
couldnt build it before due to waiting for libcompizconfig-0.6.0-3.fc8
to get into the buildroot) .. if we include that together on F-8 , it
will be running properly on GNOME according to your plans right?
--
Mohd Izhar Firdaus Bin Ismail
Amano Hikaru
??? ???? ????
http://fedoraproject.org/wiki/MohdIzharFirdaus
http://blog.kagesenshi.org
92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331
From jkeating at redhat.com Sun Oct 28 02:54:17 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 27 Oct 2007 22:54:17 -0400
Subject: Detecting dbus session
Message-ID: <20071027225417.3833101c@redhat.com>
I'm trying to write a couple NetworkManager Dispatcher calls to futz
with a few things that don't yet have NM capabilities. However I'm
running into a snag, particularly with pidgin. Pidgin has a
purple-remote call that uses dbus. nm-dispatcher runs as root so I
have to switch to my user to accomplish things (currently via su -
-c "command args"). Seems though that a 'su - ' from root
doesn't add the DBUS_SESSION_BUS_ADDRESS env entry, and purple-remote
can't find dbus or can't find pidgin on the bus.
How can I programmatically figure out what the dbus address is, or
otherwise accomplish what I'm trying to do?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From dcbw at redhat.com Sun Oct 28 05:10:37 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 28 Oct 2007 01:10:37 -0400
Subject: Detecting dbus session
In-Reply-To: <20071027225417.3833101c@redhat.com>
References: <20071027225417.3833101c@redhat.com>
Message-ID: <1193548237.7779.6.camel@localhost.localdomain>
On Sat, 2007-10-27 at 22:54 -0400, Jesse Keating wrote:
> I'm trying to write a couple NetworkManager Dispatcher calls to futz
> with a few things that don't yet have NM capabilities. However I'm
> running into a snag, particularly with pidgin. Pidgin has a
> purple-remote call that uses dbus. nm-dispatcher runs as root so I
> have to switch to my user to accomplish things (currently via su -
> -c "command args"). Seems though that a 'su - ' from root
> doesn't add the DBUS_SESSION_BUS_ADDRESS env entry, and purple-remote
> can't find dbus or can't find pidgin on the bus.
>
> How can I programmatically figure out what the dbus address is, or
> otherwise accomplish what I'm trying to do?
This sounds pretty wrong; root isn't supposed to know about the session
bus, and you're going to have a very hard time finding out the address
of some random user session bus by design.
If you want to do stuff from your user session, the best bet is to have
a session-bus dispatcher daemon. Can you just clone the DBus Example
Plugin from pidgin and make it do what you want?
dan
From abo at kth.se Sun Oct 28 09:10:28 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sun, 28 Oct 2007 10:10:28 +0100
Subject: Detecting dbus session
In-Reply-To: <1193548237.7779.6.camel@localhost.localdomain>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
Message-ID: <1193562628.9273.57.camel@home.alexander.bostrom.net>
s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams:
> This sounds pretty wrong; root isn't supposed to know about the
> session
> bus, and you're going to have a very hard time finding out the address
> of some random user session bus by design.
Yup. And a user might have multiple sessions on a single computer. Think
multiple logins to the guest account, or one log in through GDM and one
session established via ssh. Stuff like that happens.
/abo
From jkeating at redhat.com Sun Oct 28 11:53:50 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 28 Oct 2007 07:53:50 -0400
Subject: Detecting dbus session
In-Reply-To: <1193562628.9273.57.camel@home.alexander.bostrom.net>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
Message-ID: <20071028075350.281fffcd@redhat.com>
On Sun, 28 Oct 2007 10:10:28 +0100
Alexander Bostr?m wrote:
> s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams:
> > This sounds pretty wrong; root isn't supposed to know about the
> > session
> > bus, and you're going to have a very hard time finding out the
> > address of some random user session bus by design.
>
> Yup. And a user might have multiple sessions on a single computer.
> Think multiple logins to the guest account, or one log in through GDM
> and one session established via ssh. Stuff like that happens.
If this is the case, then wouldn't it make sense to have a
NetworkManagerDispatcher option to run things in the active session?
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From dcbw at redhat.com Sun Oct 28 21:02:57 2007
From: dcbw at redhat.com (Dan Williams)
Date: Sun, 28 Oct 2007 17:02:57 -0400
Subject: Detecting dbus session
In-Reply-To: <20071028075350.281fffcd@redhat.com>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
<20071028075350.281fffcd@redhat.com>
Message-ID: <1193605377.16758.1.camel@localhost.localdomain>
On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote:
> On Sun, 28 Oct 2007 10:10:28 +0100
> Alexander Bostr?m wrote:
>
> > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams:
> > > This sounds pretty wrong; root isn't supposed to know about the
> > > session
> > > bus, and you're going to have a very hard time finding out the
> > > address of some random user session bus by design.
> >
> > Yup. And a user might have multiple sessions on a single computer.
> > Think multiple logins to the guest account, or one log in through GDM
> > and one session established via ssh. Stuff like that happens.
>
> If this is the case, then wouldn't it make sense to have a
> NetworkManagerDispatcher option to run things in the active session?
Except for the fact that as root, NMD can't find out the session bus
address, nor should it be able to.
Dan
From abo at kth.se Sun Oct 28 22:26:59 2007
From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=)
Date: Sun, 28 Oct 2007 23:26:59 +0100
Subject: Detecting dbus session
In-Reply-To: <20071028075350.281fffcd@redhat.com>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
<20071028075350.281fffcd@redhat.com>
Message-ID: <1193610419.9273.77.camel@home.alexander.bostrom.net>
s?n 2007-10-28 klockan 07:53 -0400 skrev Jesse Keating:
> > Yup. And a user might have multiple sessions on a single computer.
> > Think multiple logins to the guest account, or one log in through
> GDM
> > and one session established via ssh. Stuff like that happens.
>
> If this is the case, then wouldn't it make sense to have a
> NetworkManagerDispatcher option to run things in the active session?
I really don't know enough about NM and DBus to understand all the
issues, but perhaps it's better if such things go through the system
bus? If root or some part of the system wants to tell me something, I
should have something that hooks up to the system bus and accepts input
of that kind. Would that work? There could be several of those on each
system, for different sessions and different users.
/abo
From alexl at redhat.com Mon Oct 29 09:51:29 2007
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 29 Oct 2007 10:51:29 +0100
Subject: Detecting dbus session
In-Reply-To: <1193605377.16758.1.camel@localhost.localdomain>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
<20071028075350.281fffcd@redhat.com>
<1193605377.16758.1.camel@localhost.localdomain>
Message-ID: <1193651489.14445.32.camel@dhcp-208-188.arn.redhat.com>
On Sun, 2007-10-28 at 17:02 -0400, Dan Williams wrote:
> On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote:
> > On Sun, 28 Oct 2007 10:10:28 +0100
> > Alexander Bostr?m wrote:
> >
> > > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams:
> > > > This sounds pretty wrong; root isn't supposed to know about the
> > > > session
> > > > bus, and you're going to have a very hard time finding out the
> > > > address of some random user session bus by design.
> > >
> > > Yup. And a user might have multiple sessions on a single computer.
> > > Think multiple logins to the guest account, or one log in through GDM
> > > and one session established via ssh. Stuff like that happens.
> >
> > If this is the case, then wouldn't it make sense to have a
> > NetworkManagerDispatcher option to run things in the active session?
>
> Except for the fact that as root, NMD can't find out the session bus
> address, nor should it be able to.
Can't something in the desktop connect to the session bus and get a
callback when a dispatch happens there, which it then proxies to a list
of session bus dispatchers.
From caillon at redhat.com Mon Oct 29 13:53:48 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 29 Oct 2007 14:53:48 +0100
Subject: Desktop SIG meeting tomorrow
In-Reply-To: <471F1CDB.8090502@redhat.com>
References: <1193167636.16178.6.camel@localhost.localdomain>
<471F1CDB.8090502@redhat.com>
Message-ID: <4725E5EC.6030103@redhat.com>
Christopher Aillon wrote:
> Matthias Clasen wrote:
>> I will most likely not around tomorrow, so interested people will have
>> to self-organize and find something useful to talk about. One topic that
>> I'll throw on the agenda:
>>
>> We should pick a different time for the sig meeting, because several
>> people (jrb, mcepl) said that they have difficulty making the current
>> time. And from now on, I will only be available until 2:15 on most
>> Wednesdays, too.
>
> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
>
> So, I had a look at the schedule above. I propose to move it to 1500
> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start that
> schedule until next week since o/~ Tuesday's Gone... Like the Wind. o/~
Feedback would be nice :)
From drago01 at gmail.com Mon Oct 29 14:02:59 2007
From: drago01 at gmail.com (dragoran)
Date: Mon, 29 Oct 2007 15:02:59 +0100
Subject: Desktop SIG meeting tomorrow
In-Reply-To: <4725E5EC.6030103@redhat.com>
References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com>
<4725E5EC.6030103@redhat.com>
Message-ID: <4725E813.8050905@gmail.com>
Christopher Aillon wrote:
> Christopher Aillon wrote:
>> Matthias Clasen wrote:
>>> I will most likely not around tomorrow, so interested people will have
>>> to self-organize and find something useful to talk about. One topic
>>> that
>>> I'll throw on the agenda:
>>>
>>> We should pick a different time for the sig meeting, because several
>>> people (jrb, mcepl) said that they have difficulty making the current
>>> time. And from now on, I will only be available until 2:15 on most
>>> Wednesdays, too.
>>
>> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
>>
>> So, I had a look at the schedule above. I propose to move it to 1500
>> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start
>> that schedule until next week since o/~ Tuesday's Gone... Like the
>> Wind. o/~
>
> Feedback would be nice :)
>
you asked for it ;)
1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok.
From mclasen at redhat.com Mon Oct 29 14:07:39 2007
From: mclasen at redhat.com (Matthias Clasen)
Date: Mon, 29 Oct 2007 10:07:39 -0400
Subject: Desktop SIG meeting tomorrow
In-Reply-To: <4725E813.8050905@gmail.com>
References: <1193167636.16178.6.camel@localhost.localdomain>
<471F1CDB.8090502@redhat.com> <4725E5EC.6030103@redhat.com>
<4725E813.8050905@gmail.com>
Message-ID: <1193666859.4067.9.camel@localhost.localdomain>
On Mon, 2007-10-29 at 15:02 +0100, dragoran wrote:
> Christopher Aillon wrote:
> > Christopher Aillon wrote:
> >> Matthias Clasen wrote:
> >>> I will most likely not around tomorrow, so interested people will have
> >>> to self-organize and find something useful to talk about. One topic
> >>> that
> >>> I'll throw on the agenda:
> >>>
> >>> We should pick a different time for the sig meeting, because several
> >>> people (jrb, mcepl) said that they have difficulty making the current
> >>> time. And from now on, I will only be available until 2:15 on most
> >>> Wednesdays, too.
> >>
> >> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
> >>
> >> So, I had a look at the schedule above. I propose to move it to 1500
> >> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start
> >> that schedule until next week since o/~ Tuesday's Gone... Like the
> >> Wind. o/~
> >
> > Feedback would be nice :)
> >
> you asked for it ;)
> 1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok.
Those all work for me. I can't do later than 17:00 UTC (13:00 EST).
From caillon at redhat.com Mon Oct 29 14:52:50 2007
From: caillon at redhat.com (Christopher Aillon)
Date: Mon, 29 Oct 2007 15:52:50 +0100
Subject: Desktop SIG meeting tomorrow
In-Reply-To: <4725E813.8050905@gmail.com>
References: <1193167636.16178.6.camel@localhost.localdomain> <471F1CDB.8090502@redhat.com> <4725E5EC.6030103@redhat.com>
<4725E813.8050905@gmail.com>
Message-ID: <4725F3C2.5050904@redhat.com>
dragoran wrote:
> Christopher Aillon wrote:
>> Christopher Aillon wrote:
>>> Matthias Clasen wrote:
>>>> I will most likely not around tomorrow, so interested people will have
>>>> to self-organize and find something useful to talk about. One topic
>>>> that
>>>> I'll throw on the agenda:
>>>>
>>>> We should pick a different time for the sig meeting, because several
>>>> people (jrb, mcepl) said that they have difficulty making the current
>>>> time. And from now on, I will only be available until 2:15 on most
>>>> Wednesdays, too.
>>>
>>> http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel
>>>
>>> So, I had a look at the schedule above. I propose to move it to 1500
>>> UTC (11:00am US/Eastern) on Tuesday, but obviously we can't start
>>> that schedule until next week since o/~ Tuesday's Gone... Like the
>>> Wind. o/~
>>
>> Feedback would be nice :)
>>
> you asked for it ;)
> 1500 UTC on Thuesday is to early for me. 1600 or 1700 UTC would be ok.
Except 1600 and 1700 are taken...
From davidz at redhat.com Mon Oct 29 14:54:27 2007
From: davidz at redhat.com (David Zeuthen)
Date: Mon, 29 Oct 2007 10:54:27 -0400
Subject: Detecting dbus session
In-Reply-To: <1193605377.16758.1.camel@localhost.localdomain>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
<20071028075350.281fffcd@redhat.com>
<1193605377.16758.1.camel@localhost.localdomain>
Message-ID: <1193669667.2969.6.camel@oneill.fubar.dk>
On Sun, 2007-10-28 at 17:02 -0400, Dan Williams wrote:
> On Sun, 2007-10-28 at 07:53 -0400, Jesse Keating wrote:
> > On Sun, 28 Oct 2007 10:10:28 +0100
> > Alexander Bostr?m wrote:
> >
> > > s?n 2007-10-28 klockan 01:10 -0400 skrev Dan Williams:
> > > > This sounds pretty wrong; root isn't supposed to know about the
> > > > session
> > > > bus, and you're going to have a very hard time finding out the
> > > > address of some random user session bus by design.
> > >
> > > Yup. And a user might have multiple sessions on a single computer.
> > > Think multiple logins to the guest account, or one log in through GDM
> > > and one session established via ssh. Stuff like that happens.
> >
> > If this is the case, then wouldn't it make sense to have a
> > NetworkManagerDispatcher option to run things in the active session?
>
> Except for the fact that as root, NMD can't find out the session bus
> address, nor should it be able to.
Plus lots of other things as it would have to change user / selinux
context etc. etc. I think maybe you want nm-applet (or a NMD with a
--session option) to just run stuff from
/etc/NetworkManager/session-dispatcher.d/
as the user of the session. Then the natural progression is that you
also want
~/.NetworkManager/session-dispatcher.d
so an unprivileged user can drop stuff in his own home directory that
gets run on events. Thoughts?
David
From jkeating at redhat.com Mon Oct 29 15:35:44 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 29 Oct 2007 11:35:44 -0400
Subject: Detecting dbus session
In-Reply-To: <1193669667.2969.6.camel@oneill.fubar.dk>
References: <20071027225417.3833101c@redhat.com>
<1193548237.7779.6.camel@localhost.localdomain>
<1193562628.9273.57.camel@home.alexander.bostrom.net>
<20071028075350.281fffcd@redhat.com>
<1193605377.16758.1.camel@localhost.localdomain>
<1193669667.2969.6.camel@oneill.fubar.dk>
Message-ID: <20071029113544.252f1dd2@redhat.com>
On Mon, 29 Oct 2007 10:54:27 -0400
David Zeuthen wrote:
> /etc/NetworkManager/session-dispatcher.d/
>
> as the user of the session. Then the natural progression is that you
> also want
>
> ~/.NetworkManager/session-dispatcher.d
>
> so an unprivileged user can drop stuff in his own home directory that
> gets run on events. Thoughts?
Seems right to me.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From ml at deadbabylon.de Mon Oct 29 22:15:22 2007
From: ml at deadbabylon.de (Sebastian Vahl)
Date: Mon, 29 Oct 2007 23:15:22 +0100
Subject: The KDE-SIG needs (your) help
Message-ID: <200710292315.23149.ml@deadbabylon.de>
This is a request for participation:
The KDE-SIG [1] is atm lacking active contributors. And we really need some
help in doing our job to provide a good KDE version in Fedora - especially
with the upcoming KDE 4.0 and the inclusion in Fedora 9.
If you don't know how you could help us here is a list (which is also in the
wiki):
* Packagers: There are so many interesting packages that are not yet packaged
for Fedora. Package it to improve the user experience.
* Reviewers: Only a few persons are doing the kde-related reviews. Help us
reviewing so that more packages could be included.
* Testers: If you love KDE use the development version or the updates-testing
repository and report bugs, bugs, bugs, request enhancements or features. We
need your feedback to improve KDE.
* Bugs: Become a BugZapper and help us with kde-related bugs.
* Documentation writers: The documentation (esp. the DesktopUserGuide) is
GNOME-centered. Help us to provide an equivalent for KDE.
* Release Notes: The few people that are working on the new KDE-Spin are quite
busy with development issues. If you want to help us in writing the release
notes for the next version of Fedora we would give you all the info you need.
* Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated with
end user information.
* Artists: To provide a matching theme for nodoka-metacity-theme and provide
an unified desktop experience.
But this is not a complete list. If you're interested in making KDE in Fedora
better, you're more than welcome.
The list of participants in the wiki is atm not a list of active contributors.
When setting up the wiki the only demand was an interest in KDE to be listed
on this page. This list would be changed in the future to be culled down to
the list of active (or reactivated) participants. This has become necessarely
because there are only (less or more) 3 active contributors atm (plus Than
Ngo). But the list indicates that there are enough people helping with KDE.
If you are interested in joining the KDE-SIG please add your name to this
list, answer to this mail, join us in #fedora-kde at freenode or attend the
weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic to
the agenda of the meeting next week to introduce new contributors. [2]
The attendance at the SIG-Meetings is of course not required. But this way we
would know of each other. And they are also the main place of discussing the
next steps in the development (besides fedora-devel-list).
If you have any further questions please answer to this mail or write me
directly. And be sure: If your are willing to help you're welcome (regardless
of your skills). :)
Sebastian
[1] http://fedoraproject.org/wiki/SIGs/KDE
[2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
From mark.bidewell at alumni.clemson.edu Tue Oct 30 13:47:01 2007
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Tue, 30 Oct 2007 09:47:01 -0400
Subject: The KDE-SIG needs (your) help
In-Reply-To: <200710292315.23149.ml@deadbabylon.de>
References: <200710292315.23149.ml@deadbabylon.de>
Message-ID:
I am certainly interested in helping with KDE. Is there any way to use
testing kde without using full rawhide?
Thanks.
Mark Bidewell
On 10/29/07, Sebastian Vahl wrote:
>
> This is a request for participation:
> The KDE-SIG [1] is atm lacking active contributors. And we really need
> some
> help in doing our job to provide a good KDE version in Fedora - especially
> with the upcoming KDE 4.0 and the inclusion in Fedora 9.
>
> If you don't know how you could help us here is a list (which is also in
> the
> wiki):
>
> * Packagers: There are so many interesting packages that are not yet
> packaged
> for Fedora. Package it to improve the user experience.
>
> * Reviewers: Only a few persons are doing the kde-related reviews. Help us
> reviewing so that more packages could be included.
>
> * Testers: If you love KDE use the development version or the
> updates-testing
> repository and report bugs, bugs, bugs, request enhancements or features.
> We
> need your feedback to improve KDE.
>
> * Bugs: Become a BugZapper and help us with kde-related bugs.
>
> * Documentation writers: The documentation (esp. the DesktopUserGuide) is
> GNOME-centered. Help us to provide an equivalent for KDE.
>
> * Release Notes: The few people that are working on the new KDE-Spin are
> quite
> busy with development issues. If you want to help us in writing the
> release
> notes for the next version of Fedora we would give you all the info you
> need.
>
> * Wiki: Maintain http://fedoraproject.org/wiki/KDE and keep it updated
> with
> end user information.
>
> * Artists: To provide a matching theme for nodoka-metacity-theme and
> provide
> an unified desktop experience.
>
> But this is not a complete list. If you're interested in making KDE in
> Fedora
> better, you're more than welcome.
>
>
> The list of participants in the wiki is atm not a list of active
> contributors.
> When setting up the wiki the only demand was an interest in KDE to be
> listed
> on this page. This list would be changed in the future to be culled down
> to
> the list of active (or reactivated) participants. This has become
> necessarely
> because there are only (less or more) 3 active contributors atm (plus Than
> Ngo). But the list indicates that there are enough people helping with
> KDE.
>
>
> If you are interested in joining the KDE-SIG please add your name to this
> list, answer to this mail, join us in #fedora-kde at freenode or attend
> the
> weekly KDE-SIG-Meetings (every tuesday 17:00 UTC). I will also add a topic
> to
> the agenda of the meeting next week to introduce new contributors. [2]
> The attendance at the SIG-Meetings is of course not required. But this way
> we
> would know of each other. And they are also the main place of discussing
> the
> next steps in the development (besides fedora-devel-list).
>
>
> If you have any further questions please answer to this mail or write me
> directly. And be sure: If your are willing to help you're welcome
> (regardless
> of your skills). :)
>
> Sebastian
>
>
> [1] http://fedoraproject.org/wiki/SIGs/KDE
> [2] http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2007-11-06
>
> --
> Fedora-desktop-list mailing list
> Fedora-desktop-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-desktop-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jkeating at redhat.com Tue Oct 30 13:55:43 2007
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 30 Oct 2007 09:55:43 -0400
Subject: The KDE-SIG needs (your) help
In-Reply-To:
References: <200710292315.23149.ml@deadbabylon.de>
Message-ID: <20071030095543.3edce776@redhat.com>
On Tue, 30 Oct 2007 09:47:01 -0400
"Mark Bidewell" wrote:
> I am certainly interested in helping with KDE. Is there any way to
> use testing kde without using full rawhide?
Using Live images is excellent for testing without commitment. You can
boot a live image and use it all you want without replacing the
installed operating system on your hardware.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From angazi2181 at hotmail.com Tue Oct 30 19:39:47 2007
From: angazi2181 at hotmail.com (Jack Badger)
Date: Wed, 31 Oct 2007 06:39:47 +1100
Subject: The KDE-SIG needs (your) help IDEAZ PEOPS
In-Reply-To:
Message-ID:
Although i'm fairly new to the team here, and to the linux thing as a whole,
i have a theory for a UI that could see linux through to a professional and
more 3d based operating system, including maybe even full support for new
release games, software and hardware.
if you want me to tell more, just mail me back.
Jah
Dave
_________________________________________________________________
Advertisement: Search for local singles online at Lavalife
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Flavalife9%2Eninemsn%2Ecom%2Eau%2Fclickthru%2Fclickthru%2Eact%3Fid%3Dninemsn%26context%3Dan99%26locale%3Den%5FAU%26a%3D30290&_t=764581033&_r=email_taglines_Search_OCT07&_m=EXT
From angazi2181 at hotmail.com Tue Oct 30 19:43:28 2007
From: angazi2181 at hotmail.com (Jack Badger)
Date: Wed, 31 Oct 2007 06:43:28 +1100
Subject: Detecting dbus session
In-Reply-To: <20071029113544.252f1dd2@redhat.com>
Message-ID:
such strange logic you have
maybe its best to redesign the gui completely?
>From: Jesse Keating
>Reply-To: Discussions about development for the Fedora desktop
>
>To: fedora-desktop-list at redhat.com
>Subject: Re: Detecting dbus session
>Date: Mon, 29 Oct 2007 11:35:44 -0400
>
>On Mon, 29 Oct 2007 10:54:27 -0400
>David Zeuthen wrote:
>
> > /etc/NetworkManager/session-dispatcher.d/
> >
> > as the user of the session. Then the natural progression is that you
> > also want
> >
> > ~/.NetworkManager/session-dispatcher.d
> >
> > so an unprivileged user can drop stuff in his own home directory that
> > gets run on events. Thoughts?
>
>
>Seems right to me.
>
>--
>Jesse Keating
>Fedora -- All my bits are free, are yours?
><< signature.asc >>
>--
>Fedora-desktop-list mailing list
>Fedora-desktop-list at redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-desktop-list
_________________________________________________________________
Advertisement: Make shopping exciting. Join eBay for free @ www.eBay.com.au
http://direct.ninemsn.com.au/adclick/CID=02fda8540000000000000000
From davidz at redhat.com Tue Oct 30 20:54:07 2007
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 30 Oct 2007 16:54:07 -0400
Subject: Detecting dbus session
In-Reply-To:
References:
Message-ID: <1193777647.2899.18.camel@oneill.fubar.dk>
Hi,
On Wed, 2007-10-31 at 06:43 +1100, Jack Badger wrote:
> such strange logic you have
>
> maybe its best to redesign the gui completely?
There's nothing strange about this; it's just the classic "split code
into mechanism and policy" pattern that is widely accepted as a secure
practice throughout computing.
David
From angazi2181 at hotmail.com Tue Oct 30 20:59:39 2007
From: angazi2181 at hotmail.com (Jack Badger)
Date: Wed, 31 Oct 2007 07:59:39 +1100
Subject: Detecting dbus session
In-Reply-To: <1193777647.2899.18.camel@oneill.fubar.dk>
Message-ID:
thats not what i was getting at really, but yea, i get that now anyway.
i'm sort of new to the whole linux thing, and im not that big on coding,
i've really only done 3d related, and maybe some visual basic, and some c++,
nothing too deep.
designing GUI's is my thing, thats what im good at. ive done a few, none of
them have really been adapted for commercial use, but thats mostly because
they're been build around a 3d interface, annd weren't practical at the
time...
>From: David Zeuthen
>Reply-To: Discussions about development for the Fedora desktop
>
>To: Discussions about development for the Fedora desktop
>
>Subject: Re: Detecting dbus session
>Date: Tue, 30 Oct 2007 16:54:07 -0400
>
>
>Hi,
>
>On Wed, 2007-10-31 at 06:43 +1100, Jack Badger wrote:
> > such strange logic you have
> >
> > maybe its best to redesign the gui completely?
>
>There's nothing strange about this; it's just the classic "split code
>into mechanism and policy" pattern that is widely accepted as a secure
>practice throughout computing.
>
> David
>
>
>--
>Fedora-desktop-list mailing list
>Fedora-desktop-list at redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-desktop-list
_________________________________________________________________
Advertisement: It's simple! Sell your car for just $30 at CarPoint.com.au
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT