James Antill wrote:
> ยน There are ways to game it, if needed ... but that will likely involve
> pain for someone.
There are at least 2 very simple ways to game this system. Imagine we would
like to make kdebase-runtime the default notification daemon. (We actually
don't. It's just an example to
On Thu, 2010-04-08 at 18:05 +0200, Christoph Wickert wrote:
> I just imported lxpolkit into CVS, but it's not yet build because I
> don't want to break anything.
>
> We now have 3 PolicyKit-authentication-agents in Fedora:
> * polkit-gnome
> * polkit-kd
On Saturday 10 April 2010 05:02:52 pm Kevin Kofler wrote:
> Jaroslav Reznik wrote:
> > We explicitly require polkit-kde from F-12 in combination with polkit-1
> > (in kdebase-workspace). F-11 still require
> > PolicyKit-authentication-agent.
>
> That would be F-13 resp. F-12.
Yes, F-13.
>
> I t
Jaroslav Reznik wrote:
> We explicitly require polkit-kde from F-12 in combination with polkit-1
> (in kdebase-workspace). F-11 still require PolicyKit-authentication-agent.
That would be F-13 resp. F-12.
I think that for F-12, we should really do that grouped update to introduce
polkit-kde and
Christoph Wickert wrote:
> Then polkit-kde would win and it has even more deps. ;)
And it wouldn't even work outside of KDE as it has OnlyShowIn=KDE;.
All this is why I suggested on #fedora-kde that we should ban all usage of
PolicyKit-authentication-agent entirely (possibly even just remove the
In article you
wrote:
>> libsoup itself is a nice thing because it enables asynchronous HTTP
>> access. But our libsoup package ic compiled against GConf, so it's
>> rather GNOME than GTK.
>
> since lx* triggered this thread,
>
> I guess their (light desktops users) preferred browser is midori
> libsoup itself is a nice thing because it enables asynchronous HTTP
> access. But our libsoup package ic compiled against GConf, so it's
> rather GNOME than GTK.
since lx* triggered this thread,
I guess their (light desktops users) preferred browser is midori a
webkitgtk one, and that depends o
Am Freitag, den 09.04.2010, 14:38 +0300 schrieb Muayyad AlSadi:
> > It's not only GConf but also other things like gnome-keyring, **libsoup**,
>
> sorry for this off-topic,
> is libsoup a light gtk library, or a deeply integrated gnome library
> I'm asking this because webkitgtk depends on it
> rp
> It's not only GConf but also other things like gnome-keyring, **libsoup**,
sorry for this off-topic,
is libsoup a light gtk library, or a deeply integrated gnome library
I'm asking this because webkitgtk depends on it
rpm -qR webkitgtk | grep libsoup
libsoup-2.4.so.1
--
devel mailing list
devel
On Friday 09 April 2010 02:27:59 Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 17:01 -0700 schrieb Jesse Keating:
> > Part of the solution here is to not rely entirely on yum depsolving, and
> > instead add explicitly which polkit you want in the comps group, so that
> > a provider is a
On 08/04/10 05:53 PM, Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 19:05 -0400 schrieb Tony Nelson:
>> On 10-04-08 14:13:01, Christoph Wickert wrote:
>
> [snipped]
>
>>> I never said it is a useful decision rationale, it's something we
>>> cannot avoid. I agree it's not useful, but p
On Thu, 2010-04-08 at 15:38 -0700, Adam Williamson wrote:
> On Thu, 2010-04-08 at 17:56 -0400, Matthias Clasen wrote:
>
> > Just what do you want to strip out here ?
>
> Nothing; Christoph indicated his worry was not about current deps but
> future ones, and my suggestion was just that the agent
Am Donnerstag, den 08.04.2010, 17:01 -0700 schrieb Jesse Keating:
> Part of the solution here is to not rely entirely on yum depsolving, and
> instead add explicitly which polkit you want in the comps group, so that
> a provider is already selected.
Yes, I already wrote that in my very first ma
On Fri, 2010-04-09 at 01:53 +0200, Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 19:05 -0400 schrieb Tony Nelson:
> > On 10-04-08 14:13:01, Christoph Wickert wrote:
>
> [snipped]
>
> > > I never said it is a useful decision rationale, it's something we
> > > cannot avoid. I agree it's
Am Donnerstag, den 08.04.2010, 19:05 -0400 schrieb Tony Nelson:
> On 10-04-08 14:13:01, Christoph Wickert wrote:
[snipped]
> > I never said it is a useful decision rationale, it's something we
> > cannot avoid. I agree it's not useful, but please address your
> > complainants to the yum develope
On 10-04-08 14:13:01, Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> > Christoph Wickert (christoph.wick...@googlemail.com) said:
...
> > > 3. lxpolkit will be pulled in anyway due to the shortest
> > > name.
> >
> > That's not a use
On Thu, 2010-04-08 at 17:56 -0400, Matthias Clasen wrote:
> Just what do you want to strip out here ?
Nothing; Christoph indicated his worry was not about current deps but
future ones, and my suggestion was just that the agent make an explicit
commitment to restricting itself to GTK+-level, not G
Am Donnerstag, den 08.04.2010, 17:56 -0400 schrieb Matthias Clasen:
> First of all, the fear of GConf has really grown to quite irrational
> levels. Just look at
> http://wiki.lxde.org/en/Google_Summer_of_Code_2010#Fork_GVFS_to_provide_a_more_lightweight.2C_stripped_down_version_without_Gnome_depe
On Thu, 2010-04-08 at 14:02 -0700, Adam Williamson wrote:
> On Thu, 2010-04-08 at 20:13 +0200, Christoph Wickert wrote:
> > Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> > > Christoph Wickert (christoph.wick...@googlemail.com) said:
> > > > Suggestion:
> > > > GNOME and KDE
On Thu, 2010-04-08 at 20:13 +0200, Christoph Wickert wrote:
> Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> > Christoph Wickert (christoph.wick...@googlemail.com) said:
> > > Suggestion:
> > > GNOME and KDE use their agents, everything else, for example window
> > > manager
Am Donnerstag, den 08.04.2010, 14:22 -0400 schrieb Matthias Clasen:
> On Thu, 2010-04-08 at 14:19 -0400, Seth Vidal wrote:
> >
> > On Thu, 8 Apr 2010, Christoph Wickert wrote:
> >
> > >>> 3. lxpolkit will be pulled in anyway due to the shortest name.
> > >>
> > >> That's not a useful decisio
On Thu, 2010-04-08 at 14:19 -0400, Seth Vidal wrote:
>
> On Thu, 8 Apr 2010, Christoph Wickert wrote:
>
> >>> 3. lxpolkit will be pulled in anyway due to the shortest name.
> >>
> >> That's not a useful decision rationale.
> >
> > I never said it is a useful decision rationale, it's somethin
On Thu, 8 Apr 2010, Christoph Wickert wrote:
>>> 3. lxpolkit will be pulled in anyway due to the shortest name.
>>
>> That's not a useful decision rationale.
>
> I never said it is a useful decision rationale, it's something we cannot
> avoid. I agree it's not useful, but please address you
Am Donnerstag, den 08.04.2010, 13:37 -0400 schrieb Bill Nottingham:
> Christoph Wickert (christoph.wick...@googlemail.com) said:
> > Suggestion:
> > GNOME and KDE use their agents, everything else, for example window
> > managers like icewm or openbox, gets lxpolkit.
>
> I'd honestly prefer they
Christoph Wickert (christoph.wick...@googlemail.com) said:
> Suggestion:
> GNOME and KDE use their agents, everything else, for example window
> managers like icewm or openbox, gets lxpolkit.
I'd honestly prefer they use the GNOME one (maintained closer to the
source, etc.) unless there are speic
Am Donnerstag, den 08.04.2010, 12:50 -0400 schrieb Matthias Clasen:
> On Thu, 2010-04-08 at 18:05 +0200, Christoph Wickert wrote:
>
>
> > Does this all sound reasonable? Did I miss something?
>
> There are a few complications here: currently, both gnome-session and
> gdm explicitly require polki
On Thu, 8 Apr 2010, Christoph Wickert wrote:
> I just imported lxpolkit into CVS, but it's not yet build because I
> don't want to break anything.
>
> We now have 3 PolicyKit-authentication-agents in Fedora:
> * polkit-gnome
> * polkit-kde
> * lxpol
On Thu, 2010-04-08 at 18:05 +0200, Christoph Wickert wrote:
> Does this all sound reasonable? Did I miss something?
There are a few complications here: currently, both gnome-session and
gdm explicitly require polkit-gnome. gdm has to require it explicitly,
since it needs to install a separate de
I just imported lxpolkit into CVS, but it's not yet build because I
don't want to break anything.
We now have 3 PolicyKit-authentication-agents in Fedora:
* polkit-gnome
* polkit-kde
* lxpolkit
As you can see lxpolkit has the shortest name and will therefore be
cho
29 matches
Mail list logo