Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker
Hello all, I'm still looking for a sponsor for this package. Would anyone have a bit of spare time to look at it and let me know how it can be made fit for upload? Is there any specific reason why this package is harder to review than others? It is a bit discouraging not having received any feedback after five package updates and more than a month from the first RFS. Thanks! Cheers, Dan On 4/28/18 6:18 PM, Daniele Nicolodi wrote: > Dear mentors, > > I am looking for a sponsor for my "dbus-broker" package > > * Package name: dbus-broker > Version : 13-2 > Upstream Author : David Herrmann <dh.herrm...@gmail.com> et al. > * URL : https://github.com/bus1/dbus-broker/ > * License : Apache-2.0 > Section : admin > Programming Lang: C > Description : Linux D-Bus Message Broker > > It builds those binary packages: > > dbus-broker - Linux D-Bus Message Broker > > To access further information about this package, please visit the > following URL: https://mentors.debian.net/package/dbus-broker > > Alternatively, one can download the package with dget: > > dget -x > https://mentors.debian.net/debian/pool/main/d/dbus-broker/dbus-broker_13-2.dsc > > Or from the git repository: > > https://salsa.debian.org/dnn-guest/dbus-broker > > Cheers, > Dan > ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker
Hello Michael, On 29/05/2018 09:30, Michael Biebl wrote: > I had a short look at the package Thank you very much. > a/ a hard dep on systemd-sysv. Is dbus-broker strictly systemd-only? The > launcher part probably is, but the messaging part should be init system > agnostic? Would it be possible that a launcher for sysvinit could > replace the systemd specific launcher? Should this be reflected in the > packaging by splitting of the launcher part? > If this is not possible and not intended, then it might possibly be a > good idea to document somewhere why dbus-broker is systemd-only. dbus-broker depends on systemd for launching bus activated services. I thought about splitting the launcher and the message broker parts, but upstream does not yet consider the interface between the two components stable thus I decided to postpone splitting the two components. I'll add the reason for the systemd dependency to README.Debian. > b/ /etc/systemd/user/dbus.service -> > /usr/lib/systemd/user/dbus-broker.service symlink > > I know that systemd user services currently are not yet supported by > init-system-helpers. Shipping a symlink in /etc in the package is > semi-optimal though. Afair, symlinks are not treated like real conffiles > and are re-created on package upgrades. So if an admin disables the user > part of dbus-broker, it will be re-enabled, so you might just as well > ship the symlink in /usr/lib/systemd/user. I debated what to do for a while, and I decided to enable the user service by default because I imagined that this was most likely what was expected. I didn't add the symlink in /usr/lib/systemd/user to do not conflict with the dbus package, which is required by dbus-broker for the dbus utilities and for the bus policy. There is a little explanation in README.Debian. > The alternative is to ship the user part not-enabled by default and > document that this needs to be enabled manually. I will revert this and put back the instructions to enable the user service in README.Debian. What would it take to have user services managed in a similar way as system services? Should I look into implementing that in init-system-helpers or should a new dh helper be created? Thanks for your review. Cheers, Dan ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker
On 29/05/2018 11:39, Michael Biebl wrote: > Am 29.05.2018 um 19:30 schrieb Daniele Nicolodi: >> What would it take to have user services managed in a similar way as >> system services? Should I look into implementing that in >> init-system-helpers or should a new dh helper be created? > > > It would need changes to both init-system-helpers and debhelper. > Without having given this too much thought, I think we could add the > missing functionality to dh_installsystemd and wouldn't need a > completely new helper for this. > > If you are interested, there is > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890509 > and an older bug report > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678 > > Help on this would be really appreciated! I started implementing support for systemd user instance units in deb-systemd-helper. I would like to run the tests for that script, but they currently fail also for a pristine checkout of init-system-helpers. I see that the tests are run as autopkgtests, but with TEST_ON_REAL_SYSTEM=1. However, running the tests like that is a bit heavy, and not really convenient for development. Are the tests supposed to run fin without that? The first failure looks like this: > (deb-systemd-helper DEBUG) is purge = no > (deb-systemd-helper DEBUG) action = enable, scriptname = > unit\x2dfSOUr.service, service_path = > /lib/systemd/system/unit\x2dfSOUr.service > (deb-systemd-helper DEBUG) Using systemctl preset to enable > unit\x2dfSOUr.service > /bin/systemctl: error while loading shared libraries: > libsystemd-shared-238.so: cannot open shared object file: No such file or > directory > /home/daniele/src/init-system-helpers/t/../script/deb-systemd-helper: error: > systemctl preset failed on unit\x2dfSOUr.service: No such file or directory > not ok 14 - enable command succeeded > # Failed test 'enable command succeeded' > # at t/001-deb-systemd-helper.t line 100. > # got: '256' > # expected: '0' 'libsystemd-shared-238.so' is installed in /lib/systemd and it cannot be found because the test harness bind mounts a temporary directory on that path. It seems that no one has recently run the tests in that configuration. Thank you. Cheers, Dan ___ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
