(In reply to comment #0)
> Hi.
> 
> I am not sure whether it's a requirement or a bug somewhere, but the new polkit
> (testing 0.99 currently) requires that glib is compiled with support for
> credentials, i.e. GCredentials.
> Otherwise it fails in ways like (example using polkit-gnome):
> 
> (polkit-gnome-authentication-agent-1:13555): polkit-gnome-1-WARNING **: Error
> getting authority: Error initializing authority: In WaitingForData: unexpected
> response `REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS'
> 
> Are GCredentials really needed? If so, then there should be a check in
> configure.ac or so. The need to have support for GCredentials make polkit
> usable only on linux and freebsd currently.
> 
> Thanks.

There is no way to compile GLib without GCredentials support. You need a working version of GLib if you want to use PolicyKit...

> There is no way to compile GLib without GCredentials support. You need a

That's a joke right? Glib 2.28 compiles just fine without GCredentials support.

> working version of GLib if you want to use PolicyKit...

(In reply to comment #2)
> > There is no way to compile GLib without GCredentials support. You need a
> 
> That's a joke right? Glib 2.28 compiles just fine without GCredentials support.
> 
> > working version of GLib if you want to use PolicyKit...

Err, I pushed the send button a bit fast.
So when you mean a "working version of GLib", you mean a Glib compiled on FreeBSD or Linux right?
Good to know other OS aren't supported anymore.

(In reply to comment #2)
> > There is no way to compile GLib without GCredentials support. You need a
> 
> That's a joke right? Glib 2.28 compiles just fine without GCredentials support.

Just because something compiles doesn't mean it actually works; for example, the test suite has to pass as well. Which, in the case of GLib, it _cannot_ do if there is no GCredentials support.

(In reply to comment #3)
> (In reply to comment #2)
> > > There is no way to compile GLib without GCredentials support. You need a
> > 
> > That's a joke right? Glib 2.28 compiles just fine without GCredentials support.
> > 
> > > working version of GLib if you want to use PolicyKit...
> 
> Err, I pushed the send button a bit fast.
> So when you mean a "working version of GLib", you mean a Glib compiled on
> FreeBSD or Linux right?
> Good to know other OS aren't supported anymore.

No, what I said was that if you want PolicyKit to work, then you need to make sure GLib works properly on your OS. That includes making sure GCredentials works as expected, making sure the test suite passes and so on and so on.

Complaining about GLib not working on your OS in the PolicyKit bugzilla, is definitely not helping.

> No, what I said was that if you want PolicyKit to work, then you need to make
> sure GLib works properly on your OS. That includes making sure GCredentials
> works as expected, making sure the test suite passes and so on and so on.
> 
> Complaining about GLib not working on your OS in the PolicyKit bugzilla, is
> definitely not helping.

Just for the sake of it, I was not complaining about Glib. I was asking that a check was added to configure.ac to make sure Glib was compiled with credentials support before actually compiling polkit.

(In reply to comment #6)
> > No, what I said was that if you want PolicyKit to work, then you need to make
> > sure GLib works properly on your OS. That includes making sure GCredentials
> > works as expected, making sure the test suite passes and so on and so on.
> > 
> > Complaining about GLib not working on your OS in the PolicyKit bugzilla, is
> > definitely not helping.
> 
> Just for the sake of it, I was not complaining about Glib. I was asking that a
> check was added to configure.ac to make sure Glib was compiled with credentials
> support before actually compiling polkit.

And my response was that it's not possible to compile GLib without credentials. E.g. GCredentials is part of the ABI that GLib provides. E.g. there is no --enable-credentials build option in GLib.

The problem is that GLib lacks support for credentials on your OS. This means that certain GLib applications (in particular the ones using GDBus) just doesn't work. But you will only find out at runtime, not at GLib compile time. We could change GLib such that things fail at GLib compile time (by using e.g. #error) but that's not how GLib currently works.

Hope this clarifies...