Bug#1037133:

[c . buhtz]

Hello,

I want to give an update of the situation because I migrated from Debian 
11 to 12 (old-stable to stable). Stable now has ownCloud client 2.11.0. 
The described bug is still in this version.


As upstream reported (https://github.com/owncloud/client/issues/10071) 
it might be fixed in 2.11.1.


I am just a user and don't know much about Debian Maintenance. From my 
perspective it is not "normal" bug. It is a problem that significantly 
restricts usability and functionality.


If it is not possible to fix this in current stable because of policies 
it would help much if there would be an stable-backports package with 
2.11.1 or later. I am aware that this is not an easy thing. I just want 
to mention.


Thanks in advance,
Christian Buhtz

Bug#985257: Location of example scripts?

[c . buhtz]

Hello,

I do have a side question regarding to a possible solution of this 
issue.
Back In Time (BIT) still have eight example callback scripts in a 
separate repo [1]. I plan to integrate them into the primary repo. But I 
ask myself where to install them when "./configure && make && sudo make 
install" is called?


BIT does look in "~/.config/backintime" for a file named 
"user-callback".


I would propose to install the 8 example scripts in this folder with a 
naming pattern that backintime does treat them as not active in the 
first place.


~./config/user-callback.example.default
~./config/user-callback.example.apt-backup
~./config/user-callback.example.sendmail
~./config/user-callback.example.notify
...

So this scripts would become a part of the "backintime-commen" package.

Is this acceptable for you as Debian Maintainers?

Kind
Christian Buhtz

[1] -- 

Bug#1067029: closed by Thomas Lange (closing)

[c . buhtz]

Dear Thomas,

thanks for your your reply.

My report was not about how to find donation info because I am looking 
for them. My intention was to improve Debian.


I still recommend to add "Donations" as a term to the landing page. 
Doing a text search (CTRL+F) on that page for "Donation" has 0 hits.


IMHO such an info should be obvious and not hidden behind a search 
engine or a "more" button. It is to important.


But I am not the maintainer here. Of course I do accept your decision. I 
simply offered my point of view as a user.


Kind
Christian buhtz

Am 17.03.2024 18:42 schrieb Debian Bug Tracking System:

This is an automatic notification regarding your Bug report
which was filed against the www.debian.org package:

#1067029: www.debian.org: Landing page missing donation information

It has been closed by Thomas Lange .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Thomas Lange
 by
replying to this email.

Bug#921239:

[c . buhtz]

I support this wish because of the low quality German translation of the 
current man page.


Translating it is waste of ressources.
It is also not clear where the translation comes from Upstream do not 
provide translations.
It is obvious that the German man page was translated by a machine or a 
none native speaker.


Kind

Bug#1062827: RFP: pydevtool -- CLI dev tools powered by pydoit

[c . buhtz]

I checked upstream README.md.
I have no clue what this is.

Can someone explain please?

Am 03.02.2024 18:05 schrieb dpars...@debian.org:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org
Control: affects -1 src:scipy

* Package name: pydevtool
  Version : 0.3.0
  Upstream Contact: Eduardo Schettino 
* URL : https://github.com/pydoit/pydevtool
* License : MIT
  Programming Lang: Python
  Description : CLI dev tools powered by pydoit

Python dev tool. doit powered, integration with:
- click and rich for custom CLI
- linters: pycodestlye, pyflakes

pydevtool is used by scipy's new dev.py developer script,
which upstream now intends us to use for running scipy tests, see
https://scipy.github.io/devdocs/dev/contributor/devpy_test.html

Until pydevtool is available, our scipy build will have to invoke
pytest directly, which means the debian test environment is discrepant
from that expected by scipy developers until pydevtool becomes
available.

Uses doit, so should be maintained by the Debian Python Team
alongside the doit package.

Bug#990343:

[c . buhtz]

The problem is fixed in version 1.4.2.

Bug#1061974:

[c . buhtz]

And also using "Package: backintime" do not work as expected.

A message like this result in new bugs and not in closing an existing 
one.


See this two examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061973
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061975

I am confused.

Kind

Bug#985260:

[c . buhtz]

Dear Francesco,

can you please have a look at the latest upstream release of Back In 
Time. Upstream assumes the problem is solved. Can you confirm this?


Kind
Christian

Bug#1037133:

[c . buhtz]

Upstream responded to my questions about how this was fixed.
They pointed to two PullRequests.

https://github.com/owncloud/client/pull/10058
https://github.com/owncloud/client/pull/10065

My apologize. I'm not experienced enough to provide this as a patch to 
the current Debian version. Hope someone else can go this way.


Kind
Christian

Bug#940319: [#940319 backintime] run test suite during build" : Request for maintainer feedback

[c . buhtz]

Dear Jonathan,
before investing my ressources into a solution can you please give me 
feedback about my proposal.

Would this fit to your needs as DM and solve this bug?

Kind
Christian

Bug#1043046:

[c . buhtz]

Dear Armin,
maybe you can save the time generating all the diagnostic output I asked 
for.


I'm not absolute sure about this point but based on my research it is 
not possible to configure Back In Time (BIT) that way that it run "Every 
Day" and at boot. "Every Day" do result in a crontab line like "0 12 * * 
* cmd" (or another value for minute and hour). And as we know cron does 
not catch up jobs.


My hypothesis is that you might have configured your Debian 11 machines 
explicit and without using BIT in a way that the described behavior is 
possible. You might have created an anacron job?
The behavior you describe for Debian 12 is usual and the expected. There 
is nothing wrong with it.


Kind
Christian

Bug#1043046:

[c . buhtz]

Please show the output of

cat /etc/anacrontab

Please also think hard about if you have configured something on your 
Debian 11 machines in the past?
I'm not an expert in cron and anacron but in my understanding anacron do 
not start cron-jobs after their scheduled time (in hours in minutes). 
But I might be wrong.


Maybe you manually configured your Debian 11 in the past that way and 
forgot it then?
The upgrade to Debian 12 might overwrite your anacron/cron config with 
some default behavior?


It is just an idea and I'll investigate further. It is also possible 
that there is a BIT bug.

Bug#1043046:

[c . buhtz]

Dear Armin,

thanks for reporting this. I'm member of the upstream maintainer team 
and not a Debian person. Please be aware that the current maintainer 
team is quit new to BIT and we are not yet familiar with all parts of 
the code and the behavior of BIT. But I'll try to assist you. I need to 
investigate the issue.


Let me try to rephrase. You have a snapshot profile schedule "Every 
day". This results in a crontab line like "00 12 * * *"


In Debian 11 (Bullseye, oldstable) the job was started at the first boot 
on each day and at a specified time (e.g. 12 o'clock). Correct?
In Debian 12 (Bookworm, stable) the job do not start at boot but only at 
the specified time (e.g. 12 o'clock).


This makes me wonder. I would assume that the Debian 12 behavior is 
"correct". I wonder why Debian 11 to run that job at boot when there is 
just a crontab line. On GNU Linux it is often that cron and anacron are 
somehow connected in several ways. Anacron is often involved while 
booting. Maybe something here changed between 11 and 12. I'll 
investigate that.


On Debian 11 you run BIT 1.2.1-3 from the official Debian repository?

Do you still have a working Debian 11 machine? Or did you updated all 
your machines?
If you have Debian 11 and 12 available please provide the following 
information from both machines. If not Debian 12 only is also OK.


Run "backintime --diagnostics" (only with BIT 1.3.4) in a terminal and 
give the output.


Show roots crontab with "sudo crontab -l" (as user) or "crontab -l" (as 
root).


Show the users crontab entries related to BIT with "crontab -l | grep 
backintime".


How did you verify (via "journalctl" ?) if BIT was run or not? Maybe it 
run but decided nothing changed and there is no need for a new snapshot.


Maybe you can provide the relevant syslog entries via

journalctl --since "two weeks" | grep -i -e backintime -e boot

Kind
Christian

Bug#1042428: qa.debian.org: Missing description for lintian warning tags (https://udd.debian.org/lintian/?packages=)

[c . buhtz]

Dear Sebastiaan,

thanks for reporting back.

Am 28.07.2023 10:00 schrieb Sebastiaan Couwenberg:

You can get the tag description from lintian-explain-tags:


I know that. The bug report wasn't a support question but a feature 
request.


The infos about the meaning of the tags need to be part of the linked 
website or somehow should linked there.

Bug#940319:

[c . buhtz]

No response to my questions.
I also asked on the debian python team mailing list.

Without response I'll close the ticket on next iteration.

Bug#1033829:

[c . buhtz]

Hello,

upstream maintainer here.

I just want to inform. I don't know how Debian would handle this 
usually.


The problem is fixed in upstream but unreleased. And this NMU tries to 
backport the fix.
The next Debian release will come in around 2 years. Until then upstream 
will do a new release.


Because of that and to my understanding there is no need anymore for 
that NMU and it can be removed from the system.


Kind
Christian

Bug#963849:

[c . buhtz]

Dear Felix,

can you please try to reproduce the problem with a newer release.
Debian 12 now has 1.3.3 on board which is the latest upstream version. 
This version is also available via an Ubuntu PPA or directly via git 
clone.


Feel free to ask if you need further help with installing.

Kind
Christian Buhtz

Bug#940319:

[c . buhtz]

Hello,

I try to learn here and that is why I asked.

Do I get it right that the problem is that BIT do write and read from 
the users home folder. And that is not possible or not recommended on 
Debian's own build and test system. Am I right so far?


To my knowledge as upstream maintainer this problem is not solved in 
upstream.


So how do you do it on the Debian side? Does our BIT still write to 
Debians build system's users home folder or not?

If not, how did you solved or worked around it?

Thanks for your reply.

Kind
Christian Buhtz

Bug#998105:

[c . buhtz]

Do I see it correct that the commit was done but not yet uploaded?

In result there should be a 1.3.3-5, right?

Bug#940319:

[c . buhtz]

Dear Jonathan,
what is the current situation about that issue?

There where some new releases of Back In Time in Debian. Do you 
workaround that problem on your Debian side? And how?


Kind
Christian

Bug#859115:

[c . buhtz]

Initial report based on a very old version of Back In Time.
No feedback from reporter.
Not able to reproduce.

Bug#985631:

[c . buhtz]

Seems to be a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985256

Bug#985256:

[c . buhtz]

Looks like a duplicate of this to me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985631

Bug#985258: closed by c.bu...@posteo.jp ()

[c . buhtz]

Dear Francesco,

thanks for the reply.

Am 20.01.2023 12:53 schrieb Francesco Potortì:

I understand that this is not an error hand has no consequences.
However, for someone using the progrma, it gives the impression of
inaccuracy, carelessness and possible unreliability, which is grave
for a backup utility.


That is a good point.


Why not setting XDG_RUNTIME_DIR to something bening and get rid of the
warning?  For example, I see that people use /tmp/runtime-root as a
fallback.


Can you do me a favour please and check again with the latest version 
1.3.3. (from "unstable" repo in Debian) or directly from our upstream 
github repo? I assume this is fixed as a side effect of this commit:

https://github.com/bit-team/backintime/commit/26d079a9f30c02ac91d8f0e5cbb6d94ef2065f78

A better solution would be to get rid of the Qt stuff. I assume that 
some of the Qt stuff can be replaced by Python-inbuild features.

Bug#985260:

[c . buhtz]

Tags: confirmed, upstream

Upstream do confirm this bug. Which is related to the fact how Back In 
Time reacts on failing user-callback scripts. It seems that BIT doesn't 
exit with an error code.


There is an upstream report about it:
https://github.com/bit-team/backintime/issues/1053

Bug#998105:

[c . buhtz]

Dear Sven,

there is a new release 1.3.3 in "unstable" branch of Debian.

Can you please try to reproduce the problem with that version and then 
report back.


Thanks
Christian

Bug#920050: Vote for close

[c . buhtz]

#Close
Close

Can I send commands myself?

I vote for closing this issue because it is not reproducible.

Kind
Christian

Bug#1025543: backintime: dependency on transitional policykit-1 package

[c . buhtz]

Dear Simon,

thanks for that report. I'm a member of the new upstream maintainer 
team.


Do I understand it correct that this ticket is relevant only for the 
Debian Package Maintainer?


Or can we as upstream do something about it?

Kind
Christian Buhtz

Bug#639537: backintime: messes with file access time when performing backups

[c . buhtz]

Dear Julian,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream version.
If you can reproduce it please open an Issue at upstream and link it 
here.


It seems rsync specific but we would take care of it if it is 
reproducable.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#985355: backintime-qt: runtime error - reentrant call

[c . buhtz]

Dear Francesco,

I'm a member of the new upstream maintainer team.

I assume this is reported at upstream
https://github.com/bit-team/backintime/issues/1003

and also fixed there
https://github.com/bit-team/backintime/pull/1380

Please try to reproduce that problem with the current upstream version.
If you can still reproduce it please open an Issue at upstream and link 
it here.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#985257: backintime-qt: no user callback example installed

[c . buhtz]

Hello,

I'm a member of the new upstream maintainer team.

It is not a bug but a feature request. It is still tracked at upstream.
So suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#985260: backintime-qt: cron jobs error not mailed to user

[c . buhtz]

Dear Francesco,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream version.
If you can reproduce it please open an Issue at upstream and link it 
here.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#985256: backintime-qt: unmount at wrong time leads to core dump

[c . buhtz]

Dear Francesco,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream version.
If you can reproduce it please open an Issue at upstream and link it 
here.


You still gave us the steps to reproduce.
Can you please give some more information about snapshot profile you 
setup?


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#978735: backintime-qt: crash and failure to create SSH profile

[c . buhtz]

Dear Sebastian,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream release.
If you can reproduce it please open an Issue at upstream and link it 
here.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#973760: backintime-common: in backintime.py function smartRemoveList missing return value

[c . buhtz]

Dear Greg,

I'm a member of the new upstream maintainer team.
Thank you for reporting this.

I opened an upstream Issue for that
https://github.com/bit-team/backintime/issues/1392

I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#920050: backintime-common: restoring file within a symbolic-linked directory removes symbolic link

[c . buhtz]

Dear Jacob,

I'm a member of the new upstream maintainer team.

Your report sounds serious but is IMHO not distro specific.

The bug is quit old. Please try to reproduce that problem with the 
current upstream release.
If you can reproduce it please open an Issue at upstream and link it 
here.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#888914: backintime adds current directory to path?

[c . buhtz]

Hello,

I'm a member of the new upstream maintainer team.

Please try to reproduce that problem with the current upstream release 
and report back.


I suspect that the fix Fabian linked to does fix your problem.

I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#866741: backintime-qt4: Freezes when pressing button "View last log"

[c . buhtz]

Hello,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream release. If you can reproduce it please open an Issue 
at upstream and link it here.


I suggest to close that Debian bug report because it seems not distro 
specific.


Kind
Christian Buhtz

Bug#859115: backintime-gnome: The 'backintime-gnome' blames Canberra, while 'backintime' blames keyring

[c . buhtz]

Hello,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream release.
If you can reproduce it please open an Issue at upstream and link it 
here.


Based on your report I'm not sure if this is maybe Debian specific.

Can you also please test the current BIT 1.3.2 from Debians "unstable" 
branch?


Kind
Christian Buhtz

Bug#995257: backintime-qt4: does not check if backup directory exists (or drive is mounted)

[c . buhtz]

Hello,

I'm a member of the new upstream maintainer team.

The bug is quit old. Please try to reproduce that problem with the 
current upstream release. If you can reproduce it please open an Issue 
at upstream and link it here.


I suggest to close that Debian bug report because it is not distro 
specific.


Kind
Christian Buhtz

Bug#639537:

[c . buhtz]

Thanks for the report.
Can you reproduce that problem with current "stable" Debian version?

Bug#607758:

[c . buhtz]

Thanks for the report.

This is a feature request not a bug.

And BIT does offer other ways (SSH, user-callback, ...) to access such 
devices.


smb:// urls wont be supported in the future. Access that machine via SSH 
or mount the smb share via an user-callback script.


Please close that report because it is not a bug.

Bug#985257:

[c . buhtz]

Thank you very much for your report and your idea.

We will take this into account at upstream. Currently there is no open 
Issue for that but it is on our internal TODO list.
Please feel free to open an Issue for that: 
https://github.com/bit-team/backintime/issues


I would suggest to close this Debian report because it is not highly 
related to Debian.

Bug#985631:

[c . buhtz]

Not exactly the same but maybe related Issue on upstream:
https://github.com/bit-team/backintime/issues/977

Bug#985355:

[c . buhtz]

Reported on a "testing" Debian with a now outdated BIT version.

I also can't see something helpfull in the traceback. Sorry.

Can you reproduce the problem with a current "stable" Debian?

Bug#985260:

[c . buhtz]

Thanks for the report.

But I'm sorry I don't understand all details. What does the 
user-callbacks have to do with cron?


Maybe the bug is related to cron and not to BIT?

Bug#983616:

[c . buhtz]

Thank you very much for the report.

This is fixed upstream.
https://github.com/bit-team/backintime/pull/1246

But not yet released.

Bug#985256:

[c . buhtz]

This was reported with a "testing" Debian with a now outdated BIT 
version.


Can you reproduce the problem with the current "stable" Debian?

Bug#978735:

[c . buhtz]

This was reported with a "testing" Debian.

Can you reproduce the problem with the current "stable" Debian?

Bug#866741:

[c . buhtz]

Thank you for the report.
Can you reproduce the problem with the current version 1.3.2 from 
"stable" Debian?

Bug#859115:

[c . buhtz]

Outdated. Please close.

Bug#816197:

[c . buhtz]

Fixed now and can be closed. Thanks.

Bug#989202:

[c . buhtz]

There is a closed Issue on Upstream.

I don't understand the details but it seems to be a usual behavior. 
KeePassXC keeps a local and a shareable config file.


https://github.com/keepassxreboot/keepassxc/issues/7990

So this isn't a bug?

Bug#985258:

[c . buhtz]

Apologize for multiple posts.

As upstream I vote for close. It is a comprehensible warning caused by 
running backintime in root mode. It is not an error.


It doesn't affect the functionality of backintime because it doesn't use 
XDG_RUNTIME_DIR or QStandardPaths. I checked the code for that.

Bug#985258:

[c . buhtz]

I can reproduce the warning with Version 1.2.1 as "root".

Does root need XDG_RUNTIME_DIR?

Is it relevant for the use of backintime?

Bug#1018757: minidlna.log permission denied (only in Debian 11) when using multiple instances

[c . buhtz]

Package: minidlna
Version: 1.3.0+dfsg-2+deb11u1

Hello,

this report is based on that German forum post where someone still 
helped me to solve the problem and also analyzed the root of the 
problem.

https://debianforum.de/forum/viewtopic.php?p=1307710#p1307710

I'm using multiple instances of minidlna on the same machine via systemd 
Template-Units. This worked like a charm on Debian 10 (and maybe 9).


In Debian 10 (Buster) minidlna doesn't used a log-file when the option 
-S was used and just logged to stdout. See [1] and [2].


Upstream did some modifications [3] but Debian patched [4] because of 
unknown reasons. Upstream still don't use a log-file. But Debian use a 
log-file when -S is used and set the log-folder to a default-value [5] 
and the log-filename is hardcoded [6]. That makes it hard to use 
multiple instances or make the need of unusual workarounds. Currently I 
set the log-folder not via Template-Unit but explicite for each Unit in 
the .conf file.


I don't know a solution or a good way to solve this. I don't take care 
much about log files in context of minidlna. I just wanted to report it.


[1] -- 

[2] -- 

[3] -- 

[4] -- 

[5] -- 

[6] -- 

Bug#940319: backintime: run test suite during build

[c . buhtz]

Dear Jonathan,


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 would like to suggest to save time and resources and not fixing that 
Issue.


The test infrastructure of BIT will be modified to a modern and more 
python-recommended solution (src-layout of the project folder and 
"tests" folder outside the package folder). To be honest this won't 
happen early because currently there are other more urgent problems for 
BIT that need to be fixed before restructuring the whole project 
layout/infrastructure (which would breaking everything in the first 
place).


And "writing to home" seems like a bad workaround/hack. A unittest 
shouldn't write to a real filesystem. And IMHO (personaly not as 
upstream) distributors should support such an unusual solution. This is 
a problem that I also will take into account at upstream.


I vote for closing this issue. Upstream will contact you when it is time 
to restructure the project infrastructure including the test suite.

Bug#869277: /usr/bin/notify-send: Improve the manpage

[c . buhtz]

Upstream moved its BugTracker

Here are the new links to two of the related Issues in upstream

https://gitlab.gnome.org/GNOME/libnotify/-/issues/24

https://gitlab.gnome.org/GNOME/libnotify/-/issues/23

Bug#995442: improve README.md on salsa repo

[c . buhtz]

Package: python-debian
Version: 0.1.41

This is about the salsa repository for this package.
https://salsa.debian.org/python-debian-team/python-debian

Issues are deactivated in that repo on salsa.

For new users (e.g. Me, who tries to dive deeper into python debian 
packaging) it is unclear what this package is for.
I would recommend to improve the README.md (e.g. with examples) to give 
a better understanding what it does.


The link to the "API documentation" in the README.md is dead. So I am 
not able to dive deeper into documentation.


Kind
Christian Buhtz

Bug#964816: (kein Betreff)

[c . buhtz]

This is a known problem.

The initial Debian bug ticket
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946788
and the corresponding upstream ticket
https://github.com/kurtmckee/feedparser/issues/198

Your problem specific to georss is upstream reported here
https://github.com/kurtmckee/feedparser/issues/181

This is not a "feedparser problem" anymore because feedparser fixed this 
long ago.


It is a Debian problem because no one upgrade the package even before 
the Debian 11 release.

Bug#946788: (kein Betreff)

[c . buhtz]

The problem still exists in Debian 11 because the packages was not 
updated.
I do not understand why this was n marked as a release stopping bug for 
Debian 11.

Bug#970380: (kein Betreff)

[c . buhtz]

1. Unclear log message about "Security Layer"
I assume this as upstream related so I opened an Issue there.
https://github.com/neutrinolabs/xrdp/issues/1974


Is fixed and merged in upstream.
https://github.com/neutrinolabs/xrdp/pull/1975#event-5252991803

Bug#697885: firefox-esr the same

[c . buhtz]

This problem still exists in firefox-esr (Debian 10 & 11).

I am not sure about that but I think on a Windows machine my Firefox-ESR 
does not lose the search shortcuts when I updated it.

So it could be related to  the debian packaing process.

Kind
Christian

Bug#860890: separate and close this report

[c . buhtz]

IMHO this report take three problems into account. Because of that I 
would suggest to close this report and redirect to the three surrogate 
and more atomic reports.


1. Unclear log message about "Security Layer"
I assume this as upstream related so I opened an Issue there.
https://github.com/neutrinolabs/xrdp/issues/1974

2. No clear and human understandable (log) warning about missing 
"ssl-cert" membership.
I can not decide if this is relevant to Debian only. I am looking 
forward to feedback and a suggestion if this should be re-opened here or 
upstream.


3. Add to "ssl-cert" group by default.
In my understanding this is Debian specific because only the "install 
scripts" in the deb-package are able to add the current user to a new 
group. Am I right?

If this wish make sense and is secure or not is not up to me.
If no one disagree here I would open a new Debian bug-report for that 
discussion.


Thanks in advance

Bug#926074: (kein Betreff)

[c . buhtz]

https://docs.djangoproject.com/en/2.2/ref/middleware/#module-django.middleware.http

Bug#859815: fixed in 1.1.20

[c . buhtz]

The bug is fixed in the lates release 1.1.20
https://github.com/bit-team/backintime/releases/tag/v1.1.20