Currently Jonathan Wiltshire is official DM for that package.
I'm sure he makes a good job as DM. But other packages might have higher priorities. He do not response in time and in some topics never. As
upstream maintainer I miss the dialog with "my distro maintainer". Also
there was a RFS [2] without concrete response/decision. It wasn't clear
to me if it wasn't uploaded because of the Freeze or just because no one
was there to do it.
Adding DPT to at least uploaders and having the package VCS in the python-team namespace would probably be a good idea, but that's up to Jonathan Wiltshire.
Hello,
On 2023-06-12 10:40 Jonathan Carter <jcc@debian.org> wrote:
Adding DPT to at least uploaders and having the package VCS in the
python-team namespace would probably be a good idea, but that's up to
Jonathan Wiltshire.
I have to state that after 5 weeks of waiting there is no reaction from Jonathan Wiltshire by mail, any bug-ticket (in context of backintime)
and even IRC.
There is also this bug ticket where I had specific questions (in August
last year) only the maintainer can answer but got no reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319
How can we proceed further?
IMHO it is blocking the process waiting on someone who do not answer.
their work for Debian within their free and spare time and they can
decide when to work on something.
There is also this bug ticket where I had specific questions (in
August last year) only the maintainer can answer but got no
reaction. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940319
Why can't only the maintainer answer this?
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 maintainer?
[..]
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.
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
So you want to process further something?
Provide patches, improve packages, enhance documentation, do some
kind of the work. That's the typical answers to that question.
it might be sounds strange to you, but 5 or sometimes also 8 weeks
and longer isn't a long time within Debian.
Did you try to build the last released version?
What are your problems to build backintime?
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.
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.
But without any reaction it feels to me that the package is not
important to the maintainer.
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
times.
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.
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.
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.
%---
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
maintainer?
[..]
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.
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.
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".
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 know this and I'm not that new to Debian. :)
Waiting weeks and months for a reaction (not work) is IMHO not OK.
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.
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.
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 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
Ubuntu
Am 28.07.2023 11:53 schrieb Carsten Schoenert:
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.
Maybe this is again about my expectations and wrong assumptions.
So it is possible to have packages in the debian repo that don't run any tests? I wasn't expecting this.
So Back In Time is in Debian for many years and never run tests on the
Debian build system? I'm shocked.
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.
The other angle this could be approached from is as an upstream
developer:
fake HOME directory
So it is possible to have packages in the debian repo that don't run any tests? I wasn't expecting this.Many packages don't have tests at all. For many of them tests are not
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 115:49:39 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,796 |