rblaze / haskell-dbus Goto Github PK

Hi, thanks for this great package, I'm loving it! 👍

This isn't a bug report nor a feature request. Just a minor thought I wanted to share. When building MatchRule as matchAny {matchSender = ..., matchMember = ...}, the rule is such that the signal must match all those conditions, not just any of them. But when read, it sounds a bit as if it would match if any of those conditions is met. Therefore, matchAll would sound like a more correct name to me. I had the impression that it's matchAny because one can use it as such without giving matchSender etc and then it's a rule that matches any signal. But the name matchAll also gives that impression that it matches all signals. But when given the match conditions, the code makes a bit more sense when read, at least to me.

Well, I might be missing something because I just started using the package. Even if this thought made sense, making such a change would break all packages using this package, so wouldn't make sense to implement such a change. But anyway, I just wanted to share the thought. Feel free to just close this issue.

[13 of 14] Compiling DBus.Generation ( lib/DBus/Generation.hs, dist/build/DBus/Generation.o, dist/build/DBus/Generation.dyn_o )

lib/DBus/Generation.hs:151:24: error:
• Couldn't match expected type ‘Pat’
with actual type ‘[Pat] -> Pat’
• Probable cause: ‘ConP’ is applied to too few arguments
In the expression: ConP 'Just [VarP name]
In an equation for ‘makeJustPattern’:
makeJustPattern name = ConP 'Just [VarP name]
|
151 | makeJustPattern name = ConP 'Just [VarP name]
| ^^^^^^^^^^^^^^^^^^^^^^

lib/DBus/Generation.hs:151:36: error:
• Couldn't match expected type ‘Type’ with actual type ‘Pat’
• In the expression: VarP name
In the second argument of ‘ConP’, namely ‘[VarP name]’
In the expression: ConP 'Just [VarP name]
|
151 | makeJustPattern name = ConP 'Just [VarP name]
| ^^^^^^^^^
cabal: Failed to build dbus-1.2.21

libxml-sax is not supported, last release was in 2014. Need to replace it with up-to-date XML library before it breaks.

@jmillikin @rblaze
Is there a way to expose properties (as in org.freedesktop.DBus.Properties) in this library?

Benchmarks expect quite old version of the criterion. Also, NFData instances can't be derived for dbus data types.

A main loop is necessary because we don't want multiple threads writing to the dbus socket. I think the best way to solve this issue would be to simplify the main loop so that forks (a thread) for each request, but still handles actually writing responses. This could be accomplished by having a writeback channel to which methods responding to requests would write the responses they want to send.

I am currently using dbus with the following in cabal.project to enable it to build with 9.6:

allow-newer: template-haskell, unix, transformers

The result seems to work fine.

The now deprecated dbus-core library was able to parse documents that introduced new namespaces. Specifically, ones that utilized the Dbus Spec (see below). I am getting a parse error when attempting to parse these same documents with this library. Removing them allows the parser to proceed.

Spec tag: <node xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0" name="/">
Example of new namespace items: <tp:docstring>, <tp:enumvalue>, etc

Usage of parser that throws an error: DBus.Introspection.Parse.parseXML "/" xml_file_contents, where xml_file_contents is just the Text object read from the document.

Any insight to this? Thanks,

Niko

If you expose an object at /a/b/c

and request the path a/b

dbus-send --session           \
  --dest=interfacename\
  --type=method_call          \
  --print-reply               \
  /a/b       \
  org.freedesktop.DBus.Introspectable.Introspect

you get an unknown object response with any object exposed by this library.

The path concept is supposed to be hierarchical, but we represent things as a simple ObjectPath -> InterfaceMap. Well need to change the way that object paths are represented to get this to work.

I also think that it might be a good time to consider that interfaces and object paths ought to be more independent than they are in the current implementation. The reason they are separate concepts is that it is supposed to be possible to expose the same interface on different object paths. Its kinda like the class/object distinction.

This would avoid having almost every function take a Client object as the first parameter...

This is caused by #55 bumping the version of Template Haskell. See also: build failures on Hackage.

I think the right solution is that either the version range on template-haskell needs to be loosened, or the supported versions of base need to be tightened to exclude older GHCs.

I just wanted to let you know that I've used my Hackage trustee permissions to push some Hackage revisions for dbus in order to prevent build failures with GHC 9.0.1, e.g.:

• http://hackage.haskell.org/package/dbus-1.0.0/revisions/
• http://hackage.haskell.org/package/dbus-1.2.2/revisions/

Related to #24

Currently file descriptors are just (de)serialized as regular integers. However, since file descriptors are an index into a per-process table, and d-bus normally operates between different processes, the file descriptors passed from one dbus client process will not normally make any sense on the receiving client process. Moreover this does not seem to be the way the dbus protocol is intended to be implemented.

The spec says that "...file descriptors need to be transferred via platform specific mechanism out-of-band. They must be sent at the same time as part of the message itself. They may not be sent before the first byte of the message itself is transferred or after the last byte of the message itself.".

In practice (i.e. the reference implementation), this seems to mean the following:

• File descriptor passing is only supported for unix sockets (not TCP).
• This uses a special feature that Unix sockets have for passing file descriptors (see e.g. https://blog.cloudflare.com/know-your-scm_rights/).
• The file descriptors in the message itself are serialized as indices into the array of file descriptors that are passed in SCM_RIGHTS for that particular message (rather than indices into the per-process array)
• Where a client wants to send/receive file descriptors they need to request permission during the connection process by sending "NEGOTIATE_UNIX_FD" and getting back "AGREE_UNIX_FD".

This ticket is to request that unix-socket-fd-passing be supported in haskell-dbus-client.

I'd be happy to implement this myself, if this meets with approval. I have some prototype code to prove it works, but this needs a lot of finishing / cleaning up.

Motivation: the xdg-desktop-portal API requires that the user attach a signal handler to an object path of /org/freedesktop/portal/desktop/request/$SENDER/$TOKEN. $SENDER here is the unique client name.

Currently it looks like connectWith ignores the client name that comes back from the "Hello" request.

Maybe this is for performance reasons, but I don't know of any other safe way to obtain the client id (currently I am calling ListNames and assuming that the highest unique name is the one for the connection, but this seems very fragile).

There could perhaps be an alternative connection method that returns the unique client name? I'd be happy to send a PR if this is deemed acceptable.

Cheers

Hi,

we would like to update our package set for the openSUSE Linux distribution to include xml-conduit-1.9.0.0, but unfortunately dbus won't accept that new version as a build dependency. Therefore I wonder whether you have any plans to update dbus to support the most recent version of xml-xonduit?

Best regards
Peter

How can I tell dbus that I have a signal which I want to emit to? It appears that calls to emit aren't causing the interface to change in d-feet, so I'm wondering if I can export the signal somehow before attempting to call it. Any help with this would be tremendous, your library has already saved me a great deal of pain!

BTW there's also no tags for versions 1.2.2 and 1.2.3 in the repo.

It appears systemd and dbus are moving away from setting DBUS_SESSION_BUS_ADDRESS by default. It was actually removed for some time but it had to be reintroduced because many software still rely on it.

Could you handle the case when it's not set?

Hi! This is a question, not an issue. If this is not the right place to ask, I hope you could point me to a better forum.

I'm writing a simple program which listens to DBus signals and executes a given (external) command/executable when a signal is received (https://github.com/jluttine/dbus-listen). I'd like to pass the body of the signal to the command as an environment variable. I'm trying to figure out how I could convert the signal body to a string so I could use that string as the value of the environment variable. Would you have any suggestions how to achieve this?

The body has type [Variant] so I could of course just use show but that seems quite bad.. The receiving side would get a lot of unnecessary "Variant" substrings and all type information is basically lost.

I read through the entire documentation but I just couldn't figure out any way to construct a decent function of type [Variant] -> String (or alternatively [Variant] -> [String] perhaps). I couldn't even find a way to access the raw signal body so that I could just forward it as it was received (if that is even possible in principle).

Any ideas?

I implemented a useful function to actually generate a file from a client which is actually much safer than the current approach involving unsafePerformIO. This should be added to this libarary eventually:
https://github.com/IvanMalison/status-notifier-item/blob/738197e4dc56aa6bf7f3c99c0759e5b797540b0e/src/StatusNotifier/Util.hs#L28

Dbus 1.2.2 fails on hackage:

https://matrix.hackage.haskell.org/#/package/dbus

cabal v2-build for dbus fails with a puzzling error:

[ 2 of 14] Compiling DBus.Internal.Types ( lib/DBus/Internal/Types.hs, /home/greg/s/dbus-1.2.3/dist-newstyle/build/x86_64-openbsd/ghc-8.6.4/dbus-1.2.3/build/DBus/Internal/Types.o )
                                                                                             
lib/DBus/Internal/Types.hs:469:308: error:                                                   
    Not in scope: type constructor or class ‘HsType’                                         
    Perhaps you meant ‘Type’ (line 51)                                                       
    |                                         
469 | IS_ATOM(Bool,       AtomBool,       TypeBoolean)                                       

After some head scratching the error reduces to a difference in a pair of invocations on this pared down input file:

#define IS_ATOM(HsType, AtomCons, TypeCons) \
    instance IsAtom HsType where \
    { }; \
    instance IsValue HsType where \
    { typeOf' _ = TypeCons \
    }; \
    instance IsVariant HsType where \
    { }

IS_ATOM(Bool,       AtomBool,       TypeBoolean)

cpphs generates a working version:

$ cpphs y
#line 1 "y"

instance IsAtom Bool where     { };     instance IsValue Bool where     { typeOf' _ = TypeBoolean     };     instance IsVariant Bool where     { }

whereas clang cc -E generates this beauty:

$ cc --version ; cc -E  -x assembler-with-cpp /tmp/y
OpenBSD clang version 8.0.1 (tags/RELEASE_801/final) (based on LLVM 8.0.1)
Target: amd64-unknown-openbsd6.6
Thread model: posix
InstalledDir: /usr/bin
# 1 "/tmp/y"
# 1 "<built-in>" 1
# 1 "/tmp/y" 2

instance IsAtom Bool where { }; instance IsValue Bool where { typeOf' _ = TypeCons };     instance IsVariant HsType where     { }

Notice the bashfully preserved HsType in the cc -E output. It's due to the apostrophe in typeOf' which screws up the tokenization in the 40 year old catastrophe also known as CPP.

I also tested with gcc -E 4.2.1 and 8.3.0 and they too generate broken code:

egcc --version; egcc -E  -x assembler-with-cpp /tmp/y
egcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# 1 "/tmp/y"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/tmp/y"
# 9 "/tmp/y"
instance IsAtom Bool where { }; instance IsValue Bool where { typeOf' _ = TypeCons };     instance IsVariant HsType where     { }

This is probably pretty terrible for performance...

I'd like to use dbus library to write a D-Bus service application.

Coming from QtDbus, I was expecting that the library should provide some way to transform .xml service specification into some boilerplate code. However, I can't find anything related in the documentation.

DBus.Generation looks somewhat related, but there is no documentation for this module.

I have tried to compile dbus-1.2.11 with the release candidate for ghc-8.10.1 and got the following error:

[  157s] lib/DBus/Generation.hs:235:79: error:
[  157s]     • Couldn't match type ‘Exp’ with ‘Maybe Exp’
[  157s]       Expected type: [Exp] -> Exp
[  157s]         Actual type: [Maybe Exp] -> Exp
[  157s]     • In the third argument of ‘mapOrHead'’, namely ‘TupE’
[  157s]       In the expression:
[  157s]         mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]       In an equation for ‘fromVariantExp’:
[  157s]           fromVariantExp
[  157s]             = mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]     |
[  157s] 235 |         fromVariantExp = mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]     |                                                                               ^^^^
[  157s] 
[  157s] lib/DBus/Generation.hs:236:61: error:
[  157s]     • Couldn't match type ‘Exp’ with ‘Maybe Exp’
[  157s]       Expected type: [Exp] -> Exp
[  157s]         Actual type: [Maybe Exp] -> Exp
[  157s]     • In the third argument of ‘mapOrHead'’, namely ‘TupE’
[  157s]       In the expression: mapOrHead' VarE finalOutputNames TupE
[  157s]       In an equation for ‘finalResultTuple’:
[  157s]           finalResultTuple = mapOrHead' VarE finalOutputNames TupE
[  157s]     |
[  157s] 236 |         finalResultTuple = mapOrHead' VarE finalOutputNames TupE
[  157s]     |                                                             ^^^^
[  157s] 
[  157s] lib/DBus/Generation.hs:435:79: error:
[  157s]     • Couldn't match type ‘Exp’ with ‘Maybe Exp’
[  157s]       Expected type: [Exp] -> Exp
[  157s]         Actual type: [Maybe Exp] -> Exp
[  157s]     • In the third argument of ‘mapOrHead'’, namely ‘TupE’
[  157s]       In the expression:
[  157s]         mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]       In an equation for ‘fromVariantExp’:
[  157s]           fromVariantExp
[  157s]             = mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]     |
[  157s] 435 |         fromVariantExp = mapOrHead' makeFromVariantApp fromVariantOutputNames TupE
[  157s]     |                                                                               ^^

Is this, by any chance, easy to fix?

        no-usable-addresses:     FAIL
          tests/DBusTests/Util.hs:295:
          unexpected exception TransportError {transportErrorMessage = "Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_ADDRCONFIG], addrFamily = AF_INET, addrSocketType = Stream, addrProtocol = 0, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just \"256.256.256.256\", service name: Nothing): does not exist (Name or service not known)", transportErrorAddress = Just (Address "tcp:family=ipv4,host=256.256.256.256,port=1234")}

The test passes with the previous version of network, 2.6.3.2.

An old issue brought up way back in jmillikin/haskell-dbus#7 is still affecting up for me, it would be great if multiple addresses (e.g. in DBUS_SESSION_BUS_ADDRESS) could be supported, either by just taking the first one (see patch in that issue), or actually trying them in order.

I wrote a module that uses haskell-dbus to provide functions to proxy a dbus service under a different name a while ago (see https://github.com/IvanMalison/notifications-tray-icon/blob/master/src/DBus/Proxy.hs).

I'd like to use it in a new place now, so I'm going to have to pull it out of its current home. If you think its a good idea, I'd like to simply move it into this library itself, but if you'd rather not add it, I completely understand and I will simply make a new library.

What do you think?

I use this package in various Linux distros, and have no problems, but when using it in FreeBSD I get

*** Exception: SocketError {socketErrorMessage = "Authentication failed", socketErrorFatal = True, socketErrorAddress = Just (Address "unix:guid=2fb1d926d67497d679a521255e41b85e,path=/tmp/dbus-4vBp0kLUee")}

I am not entirely sure what is going on. If I add some print statements I can see:

"AUTH EXTERNAL 31303031\r\n" <- sent
"REJECTED EXTERNAL" <- returned

The dbus session address is set. I tried connection with packages in python, and go just to be sure. Both of those are able to connect just fine. I don't know go but did notice in the go code there is some calls to UnixCredentials. Have no idea if the Haskell code is doing that for sure, but doesn't seem like it from what I can tell. Any ideas why this is failing on FreeBSD?

The latest version of dbus depends on xml-conduit 1.9.x, but that version has been deprecated on Hackage. So, what version am I supposed to pick now?

dbus 1.2.19 can build with latest bytestring and template-haskell without any modifications, which allows GHC 9.0.1

Cheers!

See the example here: https://hackage.haskell.org/package/dbus

I couldn't find the definition of (//) anywhere and it's not in scope in my ghci if I import those three packages. Build also fails. But if I remove those three lines, then it builds. Maybe they should be removed?

When I run travis-ci with the (admittedly old) ghc 7.6 which sadly is the current debian-jessie version, I ran into an compile error on the dbus package.

https://travis-ci.org/Ongy/monky/jobs/236682148#L1207

Given the following snapper.xml:

<node name='/org/opensuse/Snapper'>
  <interface name='org.opensuse.Snapper'>
    <method name='ListSnapshots'>
      <arg name='config-name' type='s' direction='in'/>
      <arg name='snapshots' type='a(uquxussa{ss})' direction='out'/>
    </method>
  </interface>
</node>

generateFromFilePath defaultGenerationParams { genBusName = Just "org.opensuse.Snapper"
                                             , genObjectPath = Just "/org/opensuse/Snapper"
                                             , genInterfaceName = "org.opensuse.Snapper"
                                             } "snapper.xml"

fails with:

error:
    Illegal variable name: ‘config-name’
    When splicing a TH declaration:
      listSnapshots client_0 config-name_1 = do {let {methodCall_2 = listSnapshotsMethodCall{DBus.Internal.Message.methodCallBody = [DBus.Internal.Types.toVariant config-name_1]}};
                                           callResult_3 <- DBus.Client.call client_0 methodCall_2;
                                           GHC.Base.return GHC.Base.$ (case callResult_3 of
                                                                           Data.Either.Right replySuccess_4 -> case DBus.Internal.Message.methodReturnBody replySuccess_4 of
                                                                                                                   [snapshots_5] -> case DBus.Internal.Types.fromVariant snapshots_5 of
                                                                                                                                        GHC.Base.Just snapshots_6 -> Data.Either.Right snapshots_6
                                                                                                                                        _ -> Data.Either.Left GHC.Base.$ (DBus.Generation.clientArgumentUnpackingError GHC.Base.$ DBus.Internal.Message.methodReturnBody replySuccess_4)
                                                                                                                   _ -> Data.Either.Left GHC.Base.$ (DBus.Generation.clientArgumentUnpackingError GHC.Base.$ DBus.Internal.Message.methodReturnBody replySuccess_4)
                                                                           Data.Either.Left e_7 -> Data.Either.Left e_7)}
   |
19 | generateFromFilePath defaultGenerationParams { genBusName = Just "org.opensuse.Snapper"
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

The arg name config-name isn't a valid Haskell identifier. Perhaps it should be escaped, e.g. turned into config_name? configName?

haskell-dbus fails to build on Debian's s390x architecture with the following error:

[11 of 11] Compiling DBus.TH          ( lib/DBus/TH.hs, dist-ghc/build/DBus/TH.o )

lib/DBus/TH.hs:1:1: error:
    Exception when trying to run compile-time code:
      Prelude.head: empty list
    Code: generateFromFilePath
            defaultGenerationParams
              {genBusName = Just dbusName, genObjectPath = Just dbusPath}
            $ "idlxml" </> "dbus.xml"
  |
1 | {-# LANGUAGE OverloadedStrings #-}
  | ^

You can see the build logs here.

The same has been reported at Fedora's bug tracker.

Could you please take a look? Let me know if I can provide any further information.

Nvm. I've made a mistake and overlooked something. Closing.

abb6732 introduced a new base constraint.

That base constraint means this package can only be used on the newest GHC version 9.2. Why is support for older GHC suddenly dropped?

Given the following snapper.xml

<node name='/org/opensuse/Snapper'>
  <interface name='org.freedesktop.DBus.Introspectable'>
    <method name='Introspect'>
      <arg name='xml_data' type='s' direction='out'/>
    </method>
  </interface>
  <interface name='org.opensuse.Snapper'>
    <signal name='ConfigCreated'>
      <arg name='config-name' type='s'/>
    </signal>
    <signal name='ConfigModified'>
      <arg name='config-name' type='s'/>
    </signal>
    <signal name='ConfigDeleted'>
      <arg name='config-name' type='s'/>
    </signal>
    ...
  </interface
</node

Running the following Template Haskell:

generateFromFilePath defaultGenerationParams { genBusName = Just "org.opensuse.Snapper"
                                             , genObjectPath = Just "/org/opensuse/Snapper"
                                             , genInterfaceName = "org.opensuse.Snapper"
                                             } "snapper.xml"

only gives me the following method:

introspectMethodCall :: DBus.Internal.Message.MethodCall
introspect ::
  Client -> IO (Either DBus.Internal.Message.MethodError String)

Which is the one in the first interface, org.freedesktop.DBus.Introspectable. I was hoping for the methods in the second interface in the file, org.opensuse.Snapper.