On Mon, 29 Jun 2020 at 19:23:49 +0200, Giuseppe Sacco wrote:
> Well, this is another problem I am facing. I installed debian linux and
> it has been officially supported until a two versions ago, when kernel
> 3.16 was current.
To be clear about this: neither of the currently-supported Debian rele
On Fri, 06 Sep 2019 at 09:52:56 +0200, Vojtěch Trefný wrote:
> On 9/6/19 4:56 AM, Pau Amma wrote:
> > So it
> > should be possible to use the library with a FreeBSD-specific daemon (that
> > already exists) providing the same messaging interface.
>
> There might be some other issues with this, lib
On Mon, 05 Dec 2016 at 11:39:10 +0200, Marius Vollmer wrote:
> I feel that the only sane thing is to have UTF-8 filenames, and we
> should optimize for that. If we have to deal with multiple encodings,
> the API should ideally protect the client from that by converting to and
> from UTF-8 on D-Bus
On Fri, 02 Dec 2016 at 15:23:19 +0100, Vratislav Podzimek wrote:
> (e.g. byte arrays instead of strings, everything synchronous,...)
There is probably a reason for these design decisions. Think carefully
before breaking them.
Byte arrays on D-Bus, in places where you expect a string, usually mean
On Mon, 28 Nov 2016 at 14:09:06 +0100, Tomáš Smetana wrote:
> On Fri, 25 Nov 2016 15:32:22 +0100
> Martin Pitt wrote:
> > My instinct tells me that the hardest part of this will (as usually)
> > be the naming: udisks or storaged. Quite a lot of upstream and
> > third-party software builds/links ag
On 09/03/15 12:32, Simon McVittie wrote:
> I'm developing a patch for udisks to fix its interaction with systemd
> user-sessions (, and I would like to check that the behaviour I propose
> is consistent with udisks' and systemd's security models.
Forgot to men
velopers: is this consistent with how you think
situations like this should work in the kdbus-based future?
(This sort of thing is one of the reasons I was keen to make D-Bus
support user sessions without requiring kdbus - if we can get this sort
of thing fixed now, in parallel with the kdbus deve