Dear Python Team,
dear Jonathan,

first of all, please take my congratulations for the Debian 12 release yesterday.

I'm member of the upstream maintenance team of "Back In Time" [1].
In short: I would like to switch its Debian Maintainer to "Debian Python
Team (DPT)".

I'm a little concerned that the way I'm addressing this is perceived as
rude. I'm not that familiar with how things work here yet.
I tried to contact some persons in private before this.

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.

In the last weeks before the Debian release there where other people
around supporting me.
Fabio Fantoni, Fabian Wolff and Sven Geuner for example.

On the site of the Team is there a possibility to take over as DM for
the package?
Is there a defined process how this should be done?

Thanks in advance.
Christian Buhtz

[1] -- <https://tracker.debian.org/pkg/backintime>
[2] -- <https://bugs.debian.org/1033829>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

On 2023/06/12 09:51, c.buhtz@posteo.jp wrote:

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.

(just for the avoidance of confusion, I'm an entirely different Jonathan)

You're very likely correct that the freeze impacted the upload. To
upload newer versions of software (even for bug fixes) so late in the
freeze, you have to write a proper justification to the release team and convince them that the benefit of the upload outweighs the risk, so in
the last few weeks of the freeze, very few packages get updated.

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.

-Jonathan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Kind
Christian Buhtz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Christian,

Am 23.07.23 um 09:09 schrieb c.buhtz@posteo.jp:

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.

it might be sounds strange to you, but 5 or sometimes also 8 weeks and
longer isn't a long time within Debian. I know that my answer isn't
helping you, it's simply quite all of the DMs and DDs are doing their
work for Debian within their free and spare time and they can decide
when to work on something.
And Jonathan isn't only active as package maintainer, it's up to him
what are his priorities and on what he wanted to work on.

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?
Also the issue is marked correctly as wishlist, typically this indicates
also that the underlying issue isn't time critical.

If you want to get applied something quickly then make it easy to the maintainer to accept the suggested modifications. Means prepare one (or
more) patches which are easy and save to pick. I can't see anything like
this within the bug report.

For sure testing and test suites are always a good thing to add, but
basically they are not needed for the functionality of a package.

How can we proceed further?
IMHO it is blocking the process waiting on someone who do not answer.

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?
Do you like to have more power within the Debian package of your
upstream work?
Is there a issue in the Debian package that is causing trouble on the users?

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.
The Debian policy is quite clear that a maintainer of a package has more
or less the full power of the package, that's how Debian is build and
also working for years.

So far I've not seen any DPT member in the past weeks who would be
willing to do work on the package backintime. If you want to improve
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, but becoming a DM will
take time and requires to learn and accept the rules of being a DM.

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.

--
Regards
Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

On 2023-07-23 09:45 Carsten Schoenert
<c.schoenert@t-online.de> wrote:

their work for Debian within their free and spare time and they can
decide when to work on something.

It is the same on my upstream site. No one gets and wants applause. We
do this for our own.

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?

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.

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".

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.

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.

it might be sounds strange to you, but 5 or sometimes also 8 weeks
and longer isn't a long time within Debian.

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

Kind
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Mechtilde,

thanks for taking time to reply.

Am 28.07.2023 07:31 schrieb Mechtilde:

Did you try to build the last released version?
What are your problems to build backintime?

At upstream I have no problems to build and test it because I'm
upstream. ;)

But in my understanding the problem described in the bug ticket is about building the package in Debian's build environment (servers?) where I
have no idea about. Some of the checking tools (lintian?) might have a
problem because my unit tests do write to home filesystem which is not
allowed or possible in Debian's build environment. That is how I
understand the ticket.

At https://tracker.debian.org/pkg/backintime I can't find the right log
or info describing the problem in detail. I'm not familiar with the
system. That is why I ask questions like this because it is an
opportunity to improve my understanding of Debian's build environment
and learn more about all the fancy build-info (DD, UD, lintian, xyz,
...) links available.

May I open a separate thread about the problem described in the ticket?

Kind
Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Christian,

Am 27.07.23 um 21:56 schrieb c.buhtz@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.

https://www.debian.org/social_contract https://www.debian.org/doc/debian-policy/ https://www.debian.org/doc/manuals/developers-reference/

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
times.

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.

https://salsa.debian.org/jmw/pkg-backintime/-/commits/debian

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
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.

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.
https://wiki.debian.org/DebianMentorsFaq
https://mentors.debian.net/
https://lists.debian.org/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.

--
Regards
Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Carsten,

thanks for taking time and replying.

Am 28.07.2023 11:53 schrieb Carsten Schoenert:

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

I'll do.

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

Fascinating.

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.

I didn't realize this. I thought that the test suite is broken and not
it never works. ;)

Having a package in the official Debian repo was always kind of a
quality certificate for me. ;)

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.

Understood.

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

What else can be done than making upstream fix the buggy tests. ;)

Ubuntu

:D No way!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 28 Jul 2023 at 11:08:38 +0000, c.buhtz@posteo.jp wrote:

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.

Some packages can sensibly run tests at build-time, and for those packages,
we usually try to do so. Some packages can't sensibly run tests at
build-time (for instance if they need access to a GPU) so we don't; and
for some packages we run tests at build-time, but we need to skip or ignore specific tests, or even ignore failure entirely, because the tests are
known to be unreliable on some or all architectures.

The only requirements on testing are:

* the package's uploader has done whatever amount of automated or manual
testing they feel is appropriate;
* if automated tests *are* run, then they must succeed (or the failures
must be explicitly ignored, if they're not believed to reflect a serious
problem)
* if the package runs build-time tests, they must meet the requirements in
Policy (not writing to the user's home directory, not accessing the
internet, etc.)

If the uploader of backintime has tested it manually, either by running
the test suite themselves or in real-world use of the updated package, then that's fine for an upload.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 28 Jul 2023 at 11:53:29 +0200, Carsten Schoenert wrote:

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.

If backintime uses $HOME, and doesn't rely on $HOME being the same as
$(getent passwd $(id -u)|cut -d: -f6), then it might actually be possible
to run its test suite with a dependency on a suitably new debhelper.

In debhelper compatibility level 13, dh_auto_test sets $HOME to a temporary directory (#942111) which might well be enough to run the test suite non-destructively. If that's sufficient, I'm sure the maintainer of the backintime package would appreciate a tested patch sent to #940319.
The way to test this would be to build backintime in sbuild, with a uid
whose "official" home directory in /etc/passwd doesn't exist in the chroot.

The other angle this could be approached from is as an upstream developer:
as an upstream, would you really want running the backintime test suite
to make potentially destructive changes to your real home directory? As
an upstream developer of other packages, I wouldn't want that: if I have
made an implementation mistake, I want to be able to find out about that
by running the test suite, knowing that the test suite won't damage my
real home directory.

Making the test suite write to a mock home directory instead of to the
real home directory, and changing or unsetting environment variables that
point to the real home directory (again, see #942111) during automated
testing, would make the test suite safer and more predictable.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Simon,

thanks for your thougths.

Am 28.07.2023 14:44 schrieb Simon McVittie:

The other angle this could be approached from is as an upstream
developer:

IMHO this is the only angle it should be approached from because it is upstreams responsibility and Debian shouldn't waste resources and
solving other ones problems. ;)

fake HOME directory

To my defense I have to say I'm not the founder just a member of the
current upstream maintenance team. I haven't written that tests. Using a
fake file ystem or temp folder as HOME won't solve problems with the
test suite because there is much more hidden in it. In summary despite
some exceptions there are no unit tests just integration and system
tests.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jul 28, 2023 at 11:08:38AM +0000, c.buhtz@posteo.jp wrote:

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
possible or don't make much sense.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Carsten Schoenert <c.schoenert@t-online.de> writes:

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.

Yes, a new contributor requires a DD for sponsored uploads; however, new contributors are not discriminated against when salvaging a package.
"Thanks to this [salvaging] process, new contributors should no longer
be afraid to take over packages that have been neglected or entirely forgotten." https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging

While it's true that no one can force anyone to do anything in Debian,
it's also true that if someone salvages a chronically ignored package,
that is a consequence of not having taken care of it, and then not
having replied to the ITS bug for a month. All this assumes both good
faith, and that new contributors educate themselves sufficiently well to
submit upload candidates on debian-mentors (and file RFS) that
sufficiently improves on the status quo of a neglected or forgotten
package.

It's important to note that the value expressed by this policy is that consistent, periodic (or better) long-term contributions are valued in
Debian. It's also important to highlight that this value is attainable
as a Debian Maintainer (uploading a set of approved packages), or as a
Debian Contributor who requires a sponsor for all uploads.

Best,
Nicholas

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmTEGRYQHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYZ8qD/4wsYCj8KDItqPq0AedjGnuPKnJmpvBkrqz RlCypy5f62kbzE6J8KL3oXGjkGeXpV0fnXsxY0r3U0wqxfVErrxGEAMvGcB5vj/H 4IK3TQB1wUo0wPIRNTAVShJvKLdKLrNshv+KZeVqtW35+mnolT9c8MSWDbtW2vAD Qdgycw0x85yOltNZHaXoXJL4jkOgCBryKj7+Uboa+u0AekikiZ0jeDB/nQYAVh5+ UWQocfEfFAdX6eUrosGUIEbNbxbtW1ts9FnI9u8ogWwXktD/Cl343LOwr8iuCYkH SZpruaz69X8j3e3VVK0+h3oUtgBtNK71/N50/zGYBkI97ENYKhKvJ1Ql3ynIv4P8 shfAroALLZoh5jOCtWqqt40u19QaxN7Y9cRUBYCiNnpZcl7BD3c/s0zawNtEK12w SDqYIKe3ZOVdpbjdX58lZDiN05dYvU1vI0yhq+mc0stWehTTdRH9dXrOxaI8l68Y IVPG/0Csw2U0BhKIbrbTQzgHlbUZpwGAz3E5b6J7TBnVF7sG7piGluZw/RkPs92h mEe5wdqD+gN6VKObnVQz8r+bJTb6jOxSIh/WEzst+Ys10bNQujnuIPJkkbC7e+J7 RZPA+VJhksJS8pF00+mTrjvcQC9qWRHDxnEMKOgN56VeYwwncARB76KfVP32KiKD
QCc1yviO+w=u4Q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)