Hello Christian,

Am 27.07.23 um 21:56 schrieb c.bu...@posteo.jp:
Dear Carsten,

thanks for your feedback, your kind words and your patience with my
frustration. :)

I was thinking about what it is what bothers me here. It is not that
"the work" isn't done or bugs not fixed. It is that there is no
reaction; zero; total silence.

you really should read the Social Contract/DFSG, the Debian policy and the Developers reference a few times.


There is no rule that any DD or DM *must* do something in Debian, so you probably have the wrong expectations.

The current Debian release is fresh. All of you maintainers have done a
lot of extra work in the last weeks to get it done. The next release is
two years in the future. Totally understandable if someone now would
take half or one year off from the maintainers job.

But this needs to be communicated somehow. A simple mail with "I'm on
holiday for the next 6 months" would be OK for me.

There is a private list there such information *can* be given, again, there is no rule that I need to do this. There are options if some other DD believes a package is needing an update, that process is called NMU (non maintainer upload). Or if you think the other maintainer isn't doing his work in a time able manner, a DD can salvage a package.
But these options are only doable by DDs! And that for a reason.

But without any reaction it feels to me that the package is not
important to the maintainer.

This depends heavily from the POV. As written, taking a 6 month off time might be an important time span for you, but this isn't true for other people.

This is not about a simple bug ticket. I asked seriously in public on
the list if the DPT could take over the package. Especially in this
situation I would expect a reaction. Asking in public is quit
impolite by me. But before I've done this I tried to reach jmw several

Debian isn't working that way! It's all a project of volunteers, that why I'm did chose to be part of it. We are not bound to a company and we wont this to happen. So we all have no obligation to do something in a specific time window. If you expect this than you should move to Canonical/Ubuntu, thats there businesses is made off.

Why can't only the maintainer answer this?

You might haven't read all ticket comments or I wasn't able to make my
question clear. The intention of my last comments to that ticket are to
understand how Jonathan worked around the problem while packaging. It
is my learning on the way becoming a Debian packager myself.

The "workaround", if there is one, is visible within the Debian package source.


I don't see any workaround and there is non needed. The bug issue is about the not usable upstream test suite that would need to be called through d/rules.

As he describes the problem and I as understand, it must be impossible
to build and package backintime for Debian. But as it is obvious it is
somehow possible and I want to know how. I want to learn something
specific about that packaging here.

To quote from the BTS:
In 1.2 upstream added a test suite. We should run it during build
(cd common && $(MAKE) test) but it needs to be able to write to the home
directory, which is disabled on Debian auto-builders. Need to find
a solution to that.

To me it's clear what the problem is. The test requires a $HOME folder, but the build environment doesn't provide something like this.

You nee to dive into the Debian package build process if you want to learn the "why". But this list is the wrong place for this. This list can help if you have specific questions about Python and Python packaging (as Mechtilde did mention).

I don't understand what or who is blocking whom here?
Is it that you feel you are blocked with your upstream work by the
If you only think that the maintainer of backintime should be
switched to the DPT then this is only a wish. And I don't think doing
such a switch is improving the situation for you, still someone needs
to do the work you requesting.

All this is not about work in the meaning of fixing, uploading or
something else. It is just about having a dialog. Without dialog I'm
not able to learn and to take over packaging someday to save your
resources. Not sure if it is against the Debian rules that upstream do
its own Debian packaging.

So you want and need to talk about how the Debian packaging is done? So you may be lucky to have some Debian folks around you which can explain this in one or more hacking session.

Or you went to Debian Mentors.

This is the place there a few Debian contributors are willing to answer questions around that topic, but you wont find a ready to use HowTo for your case. Learning Debian packaging is more of a marathon run that doing a 4 week long intensive learning.

Participating to Debian sometimes feels like talking to a wall. I want
to learn and improve my skills to someday jump into the Debian
packaging wheel. From my experience with this list it seems easier to
have dialog with the DPT.

May impression is simply you need to try to start in a much simpler way. You can not expect that a DD or DM is happy you tried to get in contact with him because of you have a problem as upstream. Your options as a non Debian Member are quite limited. And you currently not experienced enough to discuss things and try to enforce something.

this then you are welcome to become a member of the DPT by doing work
on packages which are in the maintenance of the DPT

Exactly! That is why I want my package being switch from jmw to the DPT
to make it "in the maintenance of the DPT".

Sorry, but this is not your package! You are upstream, that's fine, but you want something to happen outside "your" world there you have no control of. We are here in Debian.

I hope I made my point clear now that I want and still do this. E.g. I
checked all debian bug tickets for backintime. But I'm not able doing
this further when there is no dialog.

I don't see the Debian Maintainer is wanting something from you as Upstream, so again, your expectation is wrong to me. There is a open report that the upstream test can't be running while build, if you can provide useful tips to solve this fine, if not than this is also o.k. The package isn't in bad and unusable state due the not running tests.

I know this and I'm not that new to Debian. :)
Waiting weeks and months for a reaction (not work) is IMHO not OK.

For me it is. I have a real life beside Debian.


Reply via email to