Re: Intro and Seeking Sponsor

[Daniele Nicolodi]

On 25/06/2019 23:58, Geert Stappers wrote:
> On Tue, Jun 25, 2019 at 03:46:41PM -0600, Daniele Nicolodi wrote:
>> One of the criteria for software to enter Debian is it being generally
>> useful and balance the added functionality with the inevitable resources
>> that will be required to keep a package in the archive.  In this case,
>> unless I am missing something, your utility does not offer any function
>> that cannot be readily obtained combining standard utilities already in
>> Debian.  This is also a balance in discoverability: anyone familiar with
>> an Unix command line would find the above solution more quickly reading
>> the relevant man pages, than searching the archive for a package doing
>> the same.  Additionally, because of the flat hierarchy of the binaries
>> in $PATH, I think that any command line utility with a two characters
>> name is very likely to incur in a name collision.
> 
> That is mostly true but it mismatches
>  Subject: Intro and Seeking Sponsor

How is what I wrote not relevant for a request for sponsor?

Cheers,
Dan

Re: Intro and Seeking Sponsor

[Daniele Nicolodi]

On 25-06-2019 08:40, swiftg...@gmail.com wrote:
>   I have written a simple command line utility in Rust that I hope may be
> useful to others.  The repo is https://github.com/swiftgist/diskspace.  I
> am releasing a minimal debian package currently and need a sponsor.

Hello Eric,

I may be missing something, but what does you utility do that is not
handled by 'du -h | sort -h | tail -n 20' ?

One of the criteria for software to enter Debian is it being generally
useful and balance the added functionality with the inevitable resources
that will be required to keep a package in the archive.  In this case,
unless I am missing something, your utility does not offer any function
that cannot be readily obtained combining standard utilities already in
Debian.  This is also a balance in discoverability: anyone familiar with
an Unix command line would find the above solution more quickly reading
the relevant man pages, than searching the archive for a package doing
the same.  Additionally, because of the flat hierarchy of the binaries
in $PATH, I think that any command line utility with a two characters
name is very likely to incur in a name collision.

Cheers,
Dan

Re: Cleaning up after 'gbp buildpackage'

[Daniele Nicolodi]

On 7/8/18 8:21 PM, Tong Sun wrote:
> See the recommendation here
>  https://lists.debian.org/debian-mentors/2018/07/msg00086.html
> from Shengjing on using `gbp buildpackage export-dir`
> feature and see if it might help. It helped for my case. 

I believe that you are referring too the '--git-export-dir' option.

Cheers,
Dan

Re: Cleaning up after 'gbp buildpackage'

[Daniele Nicolodi]

On 7/9/18 12:49 AM, Andrey Rahmatullin wrote:
> On Sun, Jul 08, 2018 at 07:52:19PM -0600, Daniele Nicolodi wrote:
>> The package builds just fine without intermediated cleaning, it is just
>> gbp that complains about uncommitted changes to the source tree. That's
>> why I think I'm missing something about the gbp workflow, as I think
>> that systematically using --git-ignore-new is not the right thing.
>
> The gbp workflow implies you are not building in-tree.

Thanks! That is what I was missing.

Would it make sense to have this highlighted more prominently in the
documentation of gbp? I don't recall seeing it mentioned anywhere. I can
prepare a patch. Where would be a good place to add it?

Why is building off-tree the recommended workflow?

Cheers,
Dan

Re: Cleaning up after 'gbp buildpackage'

[Daniele Nicolodi]

On 08/07/2018 19:28, Henrique de Moraes Holschuh wrote:
> On Sun, 08 Jul 2018, Daniele Nicolodi wrote:
>> After a successful package build done with 'gbp buildpackage' the
>> package directory is left in a state which requires to run 'debuild --
>> clean' before being able to build the package again.
> 
> Packages must be buildable several times in a row *without* the need to
> *manually* call the clean target.
> 
> If it needs intermediate cleaning, arrange for it to detect and do so
> automatically.

The package builds just fine without intermediated cleaning, it is just
gbp that complains about uncommitted changes to the source tree. That's
why I think I'm missing something about the gbp workflow, as I think
that systematically using --git-ignore-new is not the right thing.

Cheers,
Dan

Cleaning up after 'gbp buildpackage'

[Daniele Nicolodi]

Hello,

apparently I don't grok something about the git-buildpackage workflow.

After a successful package build done with 'gbp buildpackage' the
package directory is left in a state which requires to run 'debuild --
clean' before being able to build the package again.

I imagine that keeping the generated files around for inspection on a
failed build is a good thing, but I would like a way to instruct gbp to
clean up after a successful build. I haven't found it. Am I missing
something?

Thanks! Cheers,
Dan

Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

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!

Hello Michael,

my attempt to implement user service management in init-system-helpers
and debhelper unfortunately stalled by lack of review of the
init-system-helper patches.  Before I loose all interest, how do prefer
to solve the issue of user units in the dbus-broker package?

Thanks. Cheers,
Dan

Re: numpy boolean subtract, the `-` operator, is deprecated, use the bitwise_xor, the `^` operator, or the logical_xor function instead (Was: Bug#899205: python-cogent: Test suite fails with latest ma

[Daniele Nicolodi]

On 05/06/2018 01:00, Andreas Tille wrote:

> ==
> ERROR: test_consistent_gap_degen_handling 
> (test_core.test_sequence.ModelSequenceTests)
> gap degen character should be treated consistently
> --
> Traceback (most recent call last):
>   File 
> "/tmp/autopkgtest-lxc.5a99fnj6/downtmp/autopkgtest_tmp/tests/test_core/test_sequence.py",
>  line 660, in test_consistent_gap_degen_handling
> self.assertEqual(dna.stripBadAndGaps(), raw_ungapped)
>   File "/usr/lib/python2.7/dist-packages/cogent/core/sequence.py", line 1251, 
> in stripBadAndGaps
> valid_indices -= self._data == i
> TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the 
> bitwise_xor, the `^` operator, or the logical_xor function instead.
> 
> ==
> 
> 
> I would be happy for some suggested patch how to solve this.  The line
> in question is
> 
>
> https://salsa.debian.org/med-team/python-cogent/blob/master/cogent/core/sequence.py
> 
>Line 1251
> 
> If my feeling is not totally wrong the correct patch would be 
> 
>valid_indices -= (self._data == i)
> 
> since the left value is rather an integer than boolean.
> 
> What do you think?

Without analyzing the code in the fine details, and assuming self._data
is a numpy array or a subclass, I think the name of the variable is
misleading.  Looking at the whole function it seems to be a bool array.
It should be easy to confirm this with pdb or simply inserting a print()
statement in the right place.

def stripBadAndGaps(self):
"""Returns copy of self with bad chars and gaps excised."""
gap_indices = map(self.Alphabet.index, self.MolType.Gaps)
valid_indices = self._data < len(self.Alphabet)
for i in gap_indices:
valid_indices -= self._data == i
result = compress(valid_indices, self._data)
return self.__class__(result, Info=self.Info)

The fix should be to replace the subtraction with:

valid_indices ^= self._data == i

Cheers,
Dan

Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

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

Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

On 29/05/2018 10: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!

My Perl is very rusty but I will have a look at this.

Cheers,
Dan

Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

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

Re: Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

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
> 

Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

retitle 895261 RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker
stop

Dear mentors,

I am looking for a sponsor for my "dbus-broker" package

* Package name: dbus-broker
  Version : 13-2
  Upstream Author : David Herrmann  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

Bug#895261: retitle to RFS: dbus-broker/13-1 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

retitle 895261 RFS: dbus-broker/13-1 [ITP] -- Linux D-Bus Message Broker
stop

I made a silly mistake in the mentors.debian.net upload order.
The latest version is 13-1. Retitle accordingly.

Bug#895261: Acknowledgement (RFS: dbus-broker/11-1 [ITP] -- Linux D-Bus Message Broker)

[Daniele Nicolodi]

Dear mentors,

I uploaded a new version of the package that polishes a bit the
packaging and updates to the latest upstream release.

The latest version of the package (and intermediate versions) can be
found at the following URL:

  https://mentors.debian.net/package/dbus-broker

Alternatively, the package can be downloaded with with dget:

  dget -x
https://mentors.debian.net/debian/pool/main/d/dbus-broker/dbus-broker_13-1.dsc

Or obtained from the repository:

  https://salsa.debian.org/dnn-guest/dbus-broker


Thanks. Cheers,
Dan

Bug#895261: RFS: dbus-broker/11-1 [ITP] -- Linux D-Bus Message Broker

[Daniele Nicolodi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my "dbus-broker" package

* Package name: dbus-broker
  Version : 11
  Upstream Author : David Herrmann  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_11-1.dsc

Or from the repository:

  https://salsa.debian.org/dnn-guest/dbus-broker

Cheers,
Dan

Re: ed25519 keys and mentors.d.n

[Daniele Nicolodi]

On 08/04/2018 17:10, Mattia Rizzolo wrote:
> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote:
>> I just tried to upload a package to mentors.debian.net and it got
>> rejected because is is signed with an ed25519 key:
>>
>> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D
>> gpg: Can't check signature: unknown pubkey algorithm
>>
>> I guess the infrastructure has not been upgraded to GnuPG 2.
> 
> Yes, when we upgraded the host 1,5 months ago we tried also moving to
> gpg2, but that wasn't as straightforward as we'd hoped…
> So, we've installed gnupg1 and changed the binary used.
> 
> Patches welcome, as usual :)

I can look into that. What code needs to be patched?

Cheers,
Dan

ed25519 keys and mentors.d.n

[Daniele Nicolodi]

Hello,

I just tried to upload a package to mentors.debian.net and it got
rejected because is is signed with an ed25519 key:

gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D
gpg: Can't check signature: unknown pubkey algorithm

I guess the infrastructure has not been upgraded to GnuPG 2.

I know that elliptic curve cryptography is a bit bleeding edge but I
thought that GnuPG had support for it for long enough to make it safe to
use it in the context of Debian.  Does this limitation apply only to
mentors.d.n or does it apply to the Debian infrastructure in general?

/me generates a new signing subkey...

Cheers,
Dan

Re: Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

On 08/04/2018 05:28, Simon McVittie wrote:
> On Sat, 07 Apr 2018 at 18:18:11 -0600, Daniele Nicolodi wrote:
>> I'm working on a package that installs a systemd user instance unit file
>> that needs to be enabled with
>>
>> # systemctl --global enable foo.service
> 
> I believe the only way to do this is currently to make
> it be statically enabled for all users (ship a symlink in
> /usr/lib/systemd/user/${something}.wants).
> 
> What is the package?
> 
> Is it something that all users are going to want?>
> Is it something that makes sense to run every time any user logs in in
> any way (ssh, console login, graphical login) or only on entry to a
> graphical session?
> 
> Would it make sense to arrange for it to be socket-activated (like
> dbus-user-session, gpg-agent, pulseaudio) or D-Bus-activated (like
> gnome-terminal-server) or autostarted on login to a graphical session (via
> /etc/xdg/autostart), rather than being started eagerly on every login?
> 
> (The way packages like dbus-user-session, gpg-agent and pulseaudio set
> themselves up for socket activation is to have their *.socket unit be
> statically enabled in sockets.target, but not their *.service unit in
> default.target.)

Hi Simon,

the package is dbus-broker, a replacement for dbus-deamon. You may have
heard of it: there has been a short exchange about its packaging for
Debian with its developers with the Debian dbus maintainers in Cc.

dbus-broker ships an user instance unit file with this Install section:

[Install]
Alias=dbus.service

with

# systemctl --global enable foo.service

a /etc/systemd/user/dbus.service symlink is created that overrides the
unit installed by dbus-daemon obtaining that dbus-broker "takes over"
the bus activation units installed by dbus-daemon. A similar thing is
done for the system bus, but that is taken care of by dh_systemd_enable
just fine.

I can create the link manually.

Cheers,
Dan

Systemd user instance equivalent of dh_systemd_enable?

[Daniele Nicolodi]

Hello,

I'm working on a package that installs a systemd user instance unit file
that needs to be enabled with

# systemctl --global enable foo.service

Using debhelper, dh_systemd_enable takes care of this automatically for
system unit files, but not for user unit files.  Is there some other
(semi)automatic way of doing it or should I take care of it manually in
the postinst and prerm maintainer scripts?

Thanks! Cheers,
Dan