[backintime] Naming of documentation directory

[c . buhtz]

Hello together,
I am upstream maintainer of "Back In Time" (src package: backintime 
[1]).


The source package results in two binary packages "backintime-common" 
(the CLI) and "backintime-qt" (the GUI).

Based on that package naming two folders are created in /usr/share/doc/*

/usr/share/doc/backintime-common/
/usr/share/doc/backintime-qt/

I would like to ask if there is any convention or policy that would 
forbid to have a third folder like this?


/usr/share/doc/backintime/
/usr/share/doc/backintime-common/
/usr/share/doc/backintime-qt/

The reason is that the user itself is often not aware about the 
separation between "common" and "qt" and know this piece of software 
just as "backintime". The latter is also the name of the shell command.


More details. Here is a selection of files that get installed for both 
packages in /usr/share/doc/*


/usr/share/doc/backintime-common/LICENSE
/usr/share/doc/backintime-common/README.md.gz
/usr/share/doc/backintime-common/changelog.Debian.gz
/usr/share/doc/backintime-common/changelog.gz
/usr/share/doc/backintime-common/copyright
/usr/share/doc/backintime-common/examples/config-example-local.gz
/usr/share/doc/backintime-common/examples/config-example-ssh.gz

/usr/share/doc/backintime-qt/changelog.Debian.gz
/usr/share/doc/backintime-qt/changelog.gz
/usr/share/doc/backintime-qt/copyright

Especially the "example" files (config-example*) I would like to have in 
a general folder named "backintime". Currently I am adding (at upstream) 
some more other example files to the project.


Or would it make sense doing something like this?

/usr/share/doc/backintime/
/usr/share/doc/backintime/common/
/usr/share/doc/backintime/qt/

Thanks in advance.

Best regards,
Christian Buhtz

[1] -- 

Re: OK to create a new package in "python-team/packages/"

[c . buhtz]

Dear Stefano,

thanks for the advice.

Am 03.04.2024 16:48 schrieb Stefano Rivera:

If you do create a repo and then never upload the package, please
delete/archive the repo when you're done.


Done.


Personally, I usually get the package ready to upload before creating a
git repo in the team.


I believe you. But the Wiki states otherwise. There creating the salsa 
repo is the first step.


Kind
Christian

Re: Docu: Need help to understand section about package creation

[c . buhtz]

Thanks for the reply.

Am 20.03.2024 22:43 schrieb Andrey Rakhmatullin:

As I said before, we no longer use git-dpm and git-dpm-specific
documentation is no longer relevant.


OK, then someone should remove it from the DPT packaging wiki page.


One should use git-buildpackage which
is described on https://wiki.debian.org/PackagingWithGit.


What is the difference to https://wiki.debian.org/Python/GitPackaging ?

Am I working on the wrong and out-dated wiki page here?


Yes, uscan doesn't make sense in that context.


I know that. But I don't know how to solve and I don't see in the wiki 
how to solve.

Re: Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs

[c . buhtz]

Sorry, guys but I don't understand nearly nothing of what you explain 
here because I don't know the tool chain nor the process. But I hope you 
all do.


I modified the section:
https://wiki.debian.org/Python/GitPackaging#Policies

Feel free to improve my modification.
But please keep the target audience of this wiki page in mind. Keep it 
short and simple. Background infos and reationals should go into another 
document (e.g. a policy or DPT guide).


Kind
Christian Buhtz

Salsa: Setup tokens

[c . buhtz]

Hello,

this is not a regular support message. I was not able to find clear 
information in the wiki or somewhere else. Please point me to it if 
exist. My intention is to improve the related wiki pages about it.


The command "salsa create_repo" do not work because of a missing 
SALSA_TOKEN. Technically it is clear to me why this happens. My question 
is how am I supposed to handle that in the context of DPT and its 
policy.


The error message:

salsa warn: SALSA_TOKEN not set in configuration files. Some 
commands may fail
salsa warn: Project not created: Error POSTing 
https://salsa.debian.org/api/v4/projects (HTTP 401): Unauthorized 
{"message":"401 Unauthorized"} at 
/usr/share/perl5/Devscripts/Salsa/create_repo.pm line 36.


OK, I logged into Salsa and navigated to "User Settings" -> "Access 
Tokens".
I assume I have to create a "Personal Access Tokens" instead of a "Feed 
Token" or "Incoming mail token"?


Are there any suggestions or recommendations from DPT about the 
"Expiration date"?


What is about "select scopes"? I see 10 unchecked items. They are 
described but it is not totally clear for new users what they are about 
or what the implications are. Any recommendations from DPT about that? 
Just select all?


A more broad question: I never used tokens before. I do use SSH keys 
when accessing Codeberg, GitHub or something else. Are this tokens a 
replacement for SSH keys? Should I prefer one of this two methods?


Thanks in advance
Christian Buhtz

Wiki: Setup the environment, e.g. "salsa" script / Request to review modified docs

[c . buhtz]

Hello together,

I still struggle with the docs but also improving them.

First of all please review my modifications to make sure there are no 
misleading errors in the content. I restructured the "Policy" section 
[1]. I shortened and rephrased the text. I also added a sub section 
"Setup and configure the system" with missing details.


I think in the long run I will add setup information to 
https://wiki.debian.org/Salsa and link to it from Python/GitPackaging 
wiki page.

Please see my Salsa related questions in the other thread.

As a side note: There is an open discussion at MoinWiki to improve the 
handling of headings and page titles [2]. The later should not be part 
of the TOC.


Best Regards,
Christian Buhtz

[1] -- 
[2] -- 

Re: Feature Request (docu): Define "dsc-file"

[c . buhtz]

Close via 
https://wiki.debian.org/Python/GitPackaging?action=diff&rev1=97&rev2=98

Re: "debian/main" support or ticket open?

[c . buhtz]

Dear Simon,

thanks for drawing that big picture for me.

That info goes to my Zettelkasten.

Kind
Christian Buhtz

Re: Feature Request (docu): Define "dsc-file"

[c . buhtz]

Thanks for all your answers.

Am 15.03.2024 11:07 schrieb Andreas Tille:

Please try a web search for instance with the terms
[...]
which brought several helpful links.  Alternatively you can ask 
ChatGPT,

Gemini or the LLM of your choice


I am a bit shocked about that advise. For what was Hypertext invented?

My mail was not a support question but a Feature Request. Of course I am 
able to search this myself. But this won't help future readers and also 
won't improve the quality of the docs. The latter is my intention.


Basic knowledge is needed to understand? Of course this is always the 
case in every section of live and the world.
But why not point to that knowledge? That is what Hypertext is invented 
for.



I do not think that things which are easy to find


No it is not "easy" when I have to run search engine for it. It is also 
not sustainable.



and is pretty clear
for the average reader of the text you want to extend should be written
down here.


I don't understand that section.

"debian/main" support or ticket open?

[c . buhtz]

Hello,

my question is technically only. I don't want to troll or start a 
discussion. So please just say yes or no. ;)


To my knowledge in context of DPT and Salsa the branch name 
"debian/master" is used. When creating a new package are there any 
technical reasons not renaming that to "debian/main"?


It might be that the existing toolchain is not yet able to adapt to it. 
Do we have an open ticket somewhere that I can monitor?


Thanks
Christian Buhtz

Feature Request (docu): Define "dsc-file"

[c . buhtz]

Hi,

this is a feature request to someone who has access and the knowledge to 
improve.


Description of the problem:

The second paragraph in 
 
tell me about importing a "dsc-file" without explaining what a dsc-file 
is or why I have to import it. The knowledge background is missing.


There is a hyper link behind the text "import an existing .dsc file" 
pointing to . 
Regarding that URL I assume this wiki entry is not maintained by DPT. 
But it also do not explain about dsc-file.


Suggested solution:
Create or locate the dsc-file definition in the wiki. It should be an 
extra page. Then just use a hyperlink in your own docu to point to that 
definition.


"import an existing .dsc file"
 ^^ ^
 I  L 
 L 

Please let me know if there is another "channel" where I should open 
such requests.


Thanks in advance
Christian Buhtz

OK to create a new package in "python-team/packages/"

[c . buhtz]

Hi,
for practicing packaging I start again with the docu and stumbled across 
this paragraph:






It tells me to create a package in "python-team/packages/". I ask myself 
if I am allowed to and if it is a "good" idea?
Technically I am allowed. And formally also because I am an formally 
accepted member of the DPT. But I wouldn't call me an active member 
despite asking dump questions and wining about the docu. ;)


On the long run it is my goal to make the package [1] ready for official 
upload. But I suspect this is a long way. So on short view that repo 
will be for practicing only. Am I allowed to create such a repo in my 
position?


Kind
Christian

[1] -- 

Re: Spinx help needed

[c . buhtz]

It is always hard to follow such threads.

It is unclear if this message is about the Sphinx package itself or a 
package that do use Sphinx in its build process.


There are two bug numbers in the CC fields. But the mail miss links to 
the bug reports or other information giving more context.
This makes it very hard for new contributors participating. A bit more 
transparency would improve the process itself and attract more 
contributors.


Thanks in advance
Christian

How to provide AppStream data by upstream?

[c . buhtz]

Hello,

imagine an upstream project providing an AppStream data file 
(foobar.metainfo.xml) and it is a full qualified Python project using 
state of the art build system (pyproject.toml, setuptools or something 
similiar, src-layout).


Should the foobar.metainfo.xml file be a part of the upstream build 
process (e.g. as custom build step in setuptools)? Or shouldn't that 
file be involved in the upstreams Python-native build process?
Does distro maintainers (you) recognize the existance of such files and 
you take care yourself via an exceptional magic debian-build-rule that 
this file is part of the deb-package and installed into 
/usr/share/metainfo/ ?


What is your preferet way?

The location /usr/share/metainfo is specified by freedesktop.org and 
should be the same on all distros. But their might be exceptions.


The question is who is responsible for locating that xml file into the 
correct place? How can decide what the correct place is?


Thanks
Christian

AppStream examples

[c . buhtz]

Hello,

as upstream maintainer want to start providing AppStream meta data for 
the package.


I can create an XML file. But I also want to know and check how this 
will look like in real world. I never used a "Software Center". The 
question is how can I check the "rendering" of an AppStream XML file in 
such a "center" without messing up my system? Maybe there is an online 
renderer available? I couldn't find something like this at the Wiki or 
AppStream website itself.


Kind
Christian

Re: Recommended way of installing system-wide python application and libraries

[c . buhtz]

Hello Ivan,

I am not an expert in Python Packaging and also not in Debian-specific 
Packaging of Python stuff. So please take my advice with care. But I do 
have some experience and did a lot of experiments.


When it comes to pure Python Packaging I would suggest my demo 
repository. It is not finished yet but it explains some packaging issues 
and use cases with examples.




When this repo is "finished" and well reviewed by the Python community I 
will start a similar repo with demos about Debian Python Packaing. That 
is the plan.


The background of all that is that I have to migrate a quit old project 
("Back In Time") from a make-based build-system to modern state of the 
art Python build-system.



update is now asking that I use a venv. More details and a link to a


That is a a "new thing" with Debian 12 following PEP 668 
().

Currently myself I do struggle with this PEP in my development process.
Im the end I do use "--break-system-packages" or "export 
PIP_BREAK_SYSTEM_PACKAGES=1".
It is not a solution but a workaround until I find a better way to 
integrate PEP 668 into my workflow.


I am not sure about it but to my understanding the recommended way to 
install packages via "pip" (e.g. from PyPi) is to use "pipx" instead of 
"pip". "pipx" will handle virtuel environments in the back. But this 
will cause some other issues I haven't solved yet.


Kind
Christian

Wiki "AppStyleGuide": Not clear to new users

[c . buhtz]

Hello,

related to https://wiki.debian.org/Python/AppStyleGuide

There are several problems with that page.

It is to short to be a single instance. Just add it as a section to the 
"LibraryStyleGuide" and rename it to "StyleGuide". This would help 
against to much fractioning of the documentation.


There are some codeblocks in that page. They lack of description and 
introduction. It is totally unclear in which language that code is. No 
shebang in the beginning. Is this bash? Which file should contain that 
code?


The date of that wiki page is from year 2014. So maybe its content is 
outdated and not relevant anymore?


Kind
Christian Buhtz

Wiki "LibraryStyleGuide": pyproject.toml not mentioned

[c . buhtz]

Hello,

related to https://wiki.debian.org/Python/LibraryStyleGuide

The "pyproject.toml" file is not mentioned here. But it is current 
recommended way (and central file) to do python packaging. If it is not 
possible to use that file in context of debian packaging this also 
should be mentioned in that wiki page.


Thanks

Wiki: How to discuss problems and improvements

[c . buhtz]

Hello,

to me it is not clear how to discuss problems and improvements of the 
wiki. There is no dedicated mailing list to that topic. I assume this 
mailing list here should not polluted with stuff like this. In the 
footer of the wiki (e.g. https://wiki.debian.org/Python/FAQ) is a ling 
to a wiki-related pseudo package. So I assume I can open bug tickets 
against this package. But I also assume that the "wiki-team" reading 
such tickets are not related to content related discussions and 
problems.


First of all I would suggest to add this topic to the FAQ at 
https://wiki.debian.org/Python/FAQ.


Thanks
Christian

Do unit tests on Debian Servers/Build system?

[c . buhtz]

Hello,

I try to understand some basics about debian packaging Python 
applications and the upload and test process.
My question in short: When (at which time point in the process of 
packaging python applications for Debian) do the Python unit tests run?


I know about the Salsa instance. Maintainers do create deb files out of 
it and then upload them to the official package repository.


Starting from tracker.debian.org I can link to a lot of status packages 
indicating success or problems; e.g. Linitian, CI, ...
No where I was able to find an indicator about if unit tests are 
successful or not.


Do such tests to run at the Debian Servers? Or do the maintainers only 
start them at their own local machines? Is this a manual step in the 
process?
If they run automatically when do they run? Before or after the deb 
files is created? If it is the latter then the test_*.py files need to 
be contained in the deb file I assume.


Thanks in advance
Christian Buhtz

Re: [backintime] I'll package the next release

[c . buhtz]

Dear Carsten,

thanks for your reply.

Am 15.09.2023 11:19 schrieb Carsten Schoenert:

the DPT isn't the maintainer of this package, you are aware of this?


DPT = Debian Python Team ?

Yes I'm aware of this. But to my knowledge the list is not restricted to 
DPT package topics.



Do you have talked to the Maintainer and/or Uploader if they are
interested in help with any packaging work done by you?


The communication is not the most fluent. I'm not sure which kind of 
help he would accept. I'll see.



Not that you not can do this for yourself


I do.


if the Debian Maintainers refuse your packaging work to merge.


I expect that. :D

Kind
Christian

[backintime] I'll package the next release

[c . buhtz]

Hello together,

I hope different from the past this announcement will work this time. 
Last time I announced the will to package something ("feedparser") but 
someone else did it without communication.


Back In Time [1][2] will have a new upstream release [3] in the next 
days. I [4] will try to prepare the packaging for Debian this time. The 
next Debian release is minimum 2 years away so I have enough time. ;)


Kind
Christian Buhtz

[1] -- 
[2] -- 
[3] -- 
[4] -- 

Re: How to realize different test categories?

[c . buhtz]

Hello Timo,

thanks for reply.

Am 28.07.2023 14:56 schrieb Timo Röhling:

I had a look at the backintime sources, and I noticed that you


First of all: I haven't nothing. :D I'm not the founder of backintime 
(BIT) just the 3rd generation maintainer trying to modernize an over 15 
year old python application. ;)



implemented a very unusual (for Python, at least) build system.


Yes, pyproject.toml etc is on my list.


There are also tools for test isolation such as [2].


Tox? How can tox help me here? It is to run multiply python versions, 
virtual env and things like this.
Tox, poetry etc would just make a build system more complex then it 
need. Currently I see no advantage of it from upstream perspective but 
I'm open to new arguments.



increasing your workload by maintaining an extra set of tests
for Debian


No, that is not how it is. It is not an extra set of tests.

In theory you have three kinds of tests: unit-, integration- and 
system-tests.
To my knowledge only unittests are making sense to run on a Debian build 
system using chroot.


BIT's problem is having no real unittests. But if I want to make them 
accessible to Debians build system excluding the other tests.


It won't be a set of tests realted to Debian. It will just be a set of 
real unittests running everywhere.



why not let backintime take advantage of established
practices and tools?


I'm working on it. But breaking the whole project structure without 
knowing all details of it (because I'm not the founder) is to risky at 
the current time. Maybe when Debian 14 is stable. ;)


Kind
Christian

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

[c . buhtz]

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.

How to realize different test categories?

[c . buhtz]

Hello,

I'm upstream maintainer (but not founder) of "backintime".

I realized that most of the tests in my test suite are integration or 
system tests which are impossible to handle by Debians build server and 
testing system (how do you name it?).
My package do use something like "./configure && make && make test && 
sudo make install" to test and build. Works fine on a local Debian box.


I would like to have an advice from you as DPT how I should separate my 
tests into the two categories "run by debian" and "don't run by debian".


One approach in my mind is to add one new make target "make unittests" 
containing real unittests able to run on Debians build system in a 
chroot.


Another approach in my mind is asking for environment variables that 
might exists on a Debian build box? I know this approach from TravisCI 
and ReadTheDocs.


Or any other idea on your site?

Kind
Christian

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

[c . buhtz]

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!

Re: [backintime] Switch the maintainer to "Debian Python Team (DPT)"

[c . buhtz]

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

Re: how to properly split up into python3-foo and foo-util package?

[c . buhtz]

Am 12.07.2023 13:25 schrieb Andrey Rakhmatullin:

On Wed, Jul 12, 2023 at 11:05:57AM +, c.bu...@posteo.jp wrote:

You build two Debian packages (deb-files) out of one source tarball?
Interesting to know that this is possible.

It's definitely possible and I would expect any good guide to mention
this.


I really need to see the full repo to better understand whats going on 
here.


One pyproject.toml indicates one and only "Python Distribution Package". 
I can not imagine why someone would split it up into two "Debian 
packages"?


Isn't it easier (from Debian Package Maintainers view) to have one 
"Python Distribution Package" per "Debian package". So when I want two 
Debian packages I would create to Python Distro packages in my upstream 
repo.

Re: how to properly split up into python3-foo and foo-util package?

[c . buhtz]

Dear Christoph,

I'm sure I can not help you but I'm asking because I want to learn.

Do you have a link to your repository?

What do you mean by the terms "simple Python package" and "two 
packages"? These terms do not exists in Python context. Python do 
differentiate between "Distribution Package" (the name you would find 
e.g. on PyPI) and "Import Packages" (the name you use with your "import" 
statement). And there is also a difference with "Debian Package" (a 
deb-file). Of course all three type of packages can be the same but 
don't have to.


Am 12.07.2023 02:21 schrieb Christoph Anton Mitterer:

debian/control (all boring fields removed):
  Source: foo


I assume that "foo" is the "Distribution Package" ?


1) Is there some mechanism in dh_python that would automatically split
   (respectively install) the files to the two packages, and I'm just
   to dumb to use it?


I don't understand why there are two packages? Why two? I can not find 
that in your setup.


Am 12.07.2023 02:21 schrieb Christoph Anton Mitterer:

debian/control (all boring fields removed):
  Source: foo
  Package: python3-foo
  Package: foo-util


You build two Debian packages (deb-files) out of one source tarball?
Interesting to know that this is possible.

It would be great if you could upload your "foo" repository somewhere 
when it works as an example.

[backintime] Switch the maintainer to "Debian Python Team (DPT)"

[c . buhtz]

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] -- 
[2] -- 

NMU: backintime

[c . buhtz]

Hello,

I know we are in a Freeze and all of you have a lot to do. So I make it 
short.

Please consider that NMU.

I'm part of upstream maintainer team "backintime".
I wasn't able to establish contact with Jonathan Wiltshire (jmw) who is 
the Debian Maintainer of that package.

The fabulous Fabio Fantoni still opened an NMU for that package.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033829

Would be great of some of you could have a look at it.

Kind
Christian Buhtz

Re: Unittests writing to HOME (backintime)

[c . buhtz]

Dear Andrey,

thank you for the reply.

Am 29.03.2023 11:40 schrieb Andrey Rakhmatullin:
The usual solution is AFAIK to set a temporary $HOME inside d/rules 
though.


I was looking into

https://salsa.debian.org/jmw/pkg-backintime/-/blob/debian/debian/rules


I don't see creation of a HOME or deactivation of a test.

I assume I have to wait of an answer from the package maintainer.

Thanks in advance

Re: BTS: What are Unclassified bugs?

[c . buhtz]

Thanks for your reply.

Am 29.03.2023 11:35 schrieb Andrey Rakhmatullin:

One example is the backintime package

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=backintime

(I don't see the word "Unclassified" on that page)


Yes it is gone. Bug is closed or modified. Can't figure out which one it 
was exactly. Sorry, bad example.

Re: BTS: Merging bugs not working because of "forwarded" to upstream bug

[c . buhtz]

Dear Hilmar,

thanks for the reply.

Am 29.03.2023 10:33 schrieb preusse:

Do, what it says: the forwarded value must be equal for both bugs.


The system should do what I say: merge. :D

Looking into the BTS's own bug tracker it seems it has no effect when 
opening a bug report about that.

BTS: Merging bugs not working because of "forwarded" to upstream bug

[c . buhtz]

Hello,

I try to understand a problem with the Bug Tracking System. I tried to 
merge two bugs because one is a duplicate. I send to control@


merge 985631 985256

I also tried the other way around switching the numbers.

But I got back that message that I don't understand. The link to the 
upstream bug might be a problem but I don't understand why.


Bug #985631 [backintime-qt] backintime-qt: for volumes mounted on 
demand, exiting backupintime-qt during the backup fails

Unable to merge bugs because:
forwarded of #985256 is '' not 
'https://github.com/bit-team/backintime/issues/724'

Failed to merge 985631: Did not alter merged bugs.

Kind
Christian

BTS: What are Unclassified bugs?

[c . buhtz]

Hello,

I couldn't find a mailing list specific to the Bug Tracking System.

In the bugs summary list for a specific package I can find 
"Unclassified" bugs. But what is "Unclassified"?


Looking into other (not "Unclassified") bugs all have a "severity", some 
are "confirmed" some not. So a missing "confirmed" doesn't make a bug 
"Unclassified".


One example is the backintime package


https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=backintime


Kind
Christian

Unittests writing to HOME (backintime)

[c . buhtz]

Hello,

I assume this topic is not specific to one package but to the whole 
python packaging universe.


There is "backintime" which unittests do write to $HOME. I'm one of the 
new upstream maintainers and know that this isn't a good idea. It will 
take time to fix this.

About that problem there is a debian bug report nearly 4 years old

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

It tells that this is a problem because writing to HOME during build "is 
disabled on Debian auto-builders".


My question now is why newer version of this package are uploaded then? 
I couldn't find that the tests where deactivated. Maybe this "disabled 
on Debian auto-builders" is outdated and today it is possible to write 
to HOME during build?

Re: Location of translations for package description

[c . buhtz]

Dear Joost,

thanks for the reply.

I understand there is a project doing this manually.

Am 20.02.2023 15:07 schrieb Joost van Baal-Ilić:
See https://ddtp.debian.org/ and https://wiki.debian.org/DDTP for 
information

on the translation infrastructure for package descriptions.


Puh... How do I say that? It is far away from being a documentation 
understandable by extern persons. I just want to understand how the 
translations are integrated in the packaging process.


I assume from the side of upstream maintainers and debian maintainers no 
actions required. Correct?


I also assume there is an automatic mechanism that the translations are 
marked as outdated when the original source (e.g. the control file on 
salsa) is modified. Correct?


Kind
Christian Buhtz

Location of translations for package description

[c . buhtz]

Hello,

there is a German package description
https://packages.debian.org/de/bookworm/backintime-common

this is also available in English
https://packages.debian.org/en/bookworm/backintime-common

It seems to me that the English version is extracted from the control 
file

https://salsa.debian.org/jmw/pkg-backintime/-/blob/debian/debian/control

But I'm not able to find the German (or any other translated) version in 
the source repo.


Is this done on the fly in the back somehow?

btw: I'm upstream maintainer of that package.

Kind
Christian Buhtz

Re: How should upstream document/communicate none-Python dependencies?

[c . buhtz]

Thanks for your reply.

Am 02.02.2023 14:46 schrieb Jeremy Stanley:

with https://pypi.org/project/bindep which is effectively a manifest
of distribution package names and a grammar for indicating


Awesome.

The upstream maintainers have to create a binddep.txt file.
And the distro maintainers do need to use binddep do parse that file and 
"translate" it into the package names of their distro.

Am I right so far?

What does other debian python package maintainers think about such a 
tool? Would this ease your (burden) of work preparing a new package 
(release)?

How should upstream document/communicate none-Python dependencies?

[c . buhtz]

Hello,

I'm part of upstream maintainer team of "backintime" (BIT).

A modern Python project (which BIT is currently not) would specify 
dependencies and other build related information's into a pyproject.toml 
file.
But some Python applications (e.g. BIT) do have non-Python dependencies 
to specific Debian packages e.g. "rsync".


As upstream I do document that into README or somewhere else in a human 
readable file.


But is there a machine readable way to specify things like this? Maybe 
there is a special pyproject.toml section I don't know about yet? Or 
something like MANIFEST or requirements files I've heard of but never 
used.


How would you wish this as distro maintainers?

Side question: Do you, as distro maintainers, have automatic tools to 
translate dependencies from pyproject.toml (e.g. "pyfakefs") into the 
related Debian package (e.g. "python3-pyfakefs")?


Kind
Christian Buhtz

Re: What is this about the metainfo-file?

[c . buhtz]

Please let me add one additional thought.

It seems easy to me to extract he meta data (via importlib.metadata) 
from a python project that suites to the python packaging standards 
(providing a pyproject.toml, setup.cfg and things like that).


In that case it seems easy to have a debian-python-packaging-magic-tool 
on your site that will extract the data, generate a metainfo file and 
add it to the debian package.


Kind
Christian

What is this about the metainfo-file?

[c . buhtz]

Hello,

I try to understand the "metainfo" file I was pointed to by an 
"AppStream hint".


https://appstream.debian.org/sid/main/issues/backintime-qt.html

There are some links pointing to freedesktop.org. There is also 
appstream.debian.org.

I read that and got the keys of that concept.

But I want to know how this is related to Debian especially Python 
projects. Python projects to offer meta data in form of pyproject.toml 
or setup.cfg. So why should I add another (redundant) meta data file?


Where is the location of that file? Should it be in the root of the repo 
or is it part of the "/debian" (with control file, etc) folder in that 
repo?


What is the advantage for Debian users of such a file? Debian doesn't 
offer a "software center". ;)


Kind
Christian

Docu about Salsa workflow

[c . buhtz]

Hello,

sorry for asking. I'm looking or the right document explaining the 
workflows on Salsa.

Am I on the right way here: https://wiki.debian.org/Teams/PythonTeam ?

Most projects on Salsa do have three branch names. I need an explanation 
of them and how they interact.


Kind
Christian

Re: How do you create entry-points for Python applications?

[c . buhtz]

Dear Scott,

thanks for the reply.

Am 19.12.2022 06:25 schrieb Scott Kitterman:

Pybuild using the pyproject plugin will build a wheel and
then install the necessary files in the package using the installer
module.  The entry point scripts are in the wheel, just like an
upstream built wheel.


Do I get that correct?
The entry scripts (their content and their location) is the same 
installing a package via pip and apt?


In that case I'm right trying to make the "pip install" process as 
correct as possible to save resources for the distro maintainers.



Your best bet is to find a package in the archive that's similar and
see how it was done.


That is why I'm asking here. ;)

Re: How do you create entry-points for Python applications?

[c . buhtz]

Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی:

AFAIK Debian helper for Python handles this


;) Yes, but how?

Does it ignore the pip-default-entry-point-scripts? Does it create its 
own script?

Do you have to explicit write a script?

How do you create entry-points for Python applications?

[c . buhtz]

Hello,
a python application isn't a binary but a script. So to invoke such an 
application there need to be a shell script somewhere in PATH that 
invoke that script via python3 interpreter. Imagine an application with 
a GUI (qt, tikinter, gtk, ...).


On the upstream site modern python projects using pyproject.toml (only), 
some use setup.cfg.
There you can define "entry points" and the "pip" installer does 
generate a shell script based on that information and place it in PATH.

That is a nice mechanism when installing via pip.

On your site as distro maintainers. How do you take care of then when 
creating deb files?
When a project do follow modern python packaging standards using 
pyproject.toml/setup.cfg and doesn't offer any other explict start shell 
script. Do you use that pip mechanic for the deb package?

Or how do you create your shell scripts?

I don't have an real world example of a python application for that.

I only have an example of a project (backintime) that don't use 
pyproject.toml/setup.cfg and offer its own shell script. I'm part of the 
new maintainer team and we will evolve the project to current python 
packaging standards; which means using pyproject.toml.

Re: Python 3.11 for bookworm?

[c . buhtz]

Am 13.12.2022 10:15 schrieb Timo Röhling:

One remaining problem is the unmaintained nose package
[...]
done some work patching up nose


This question is just for my learning: Why is nose patched? Upstream 
nose is unmaintained for years.


I understand that you cannot drop nose from Debian in the current 
situation of a freeze in one months and so many dependencies.


But isn't there a Debian process/workflow to "warn" package maintainers 
about an upcoming package drop of one of there dependend packages to put 
some pressure into it? Looking into the list of over 200 packages I see 
this also as a chance to clean out some other unmaintained (and maybe 
not so important) packages from the Debian repo.

pyfakefs: Outdate version was migrated today

[c . buhtz]

Hello folks,
my question is not critic but just learning purpose. Because in the 
Debian universe I always assume that there is a good reason behind each 
activity, no matter if I understand it or not.


Here is one I don't understand.
Today (9th December '22) pyfakefs 4.6.3 was migrated [1] into testing. 
But the latest stable release at upstream is 5.0.0 release two months 
ago [2].


So why does a Debian package maintainer invest time and resources into 
packaging an out dated version of a package?


Greetings
Christian

[1] -- 


[2] -- 

Python distributions with multiple packages

[c . buhtz]

Hello,

today I found out that it is possible to create a Python "Distribution 
Package" [1] (e.g. a whl-file) that contain more then one "Importable 
Packages" [2].


So you can do "pip3 install mydistropackage" and after that you can do 
"import mya" and "import myb".


Are you aware of any packages in Debian that are related to upstream 
projects using that "technic"?


And if so how do you (as debian distro maintainers) handle that? Do you 
create one deb-file for "mydistropackage" (e.g. 
"python3-mydistropackage.deb") or do you separate into "python3-mya.deb" 
and "python3-myb.deb"?


Kind
Christian Buhtz

[1] -- 

[2] -- 

dh_python or pybuild

[c . buhtz]

Hello,

I am not sure if I misunderstand something or if the documentation is 
inconsistent.


The PythonPolicy
https://www.debian.org/doc/packaging-manuals/python-policy/
tells me that dh_python should be the preferred tool for packaging 
(https://www.debian.org/doc/packaging-manuals/python-policy/#versions)


But the LibraryStyleGuide
https://wiki.debian.org/Python/LibraryStyleGuide
tells me it is pybuild 
(https://wiki.debian.org/Python/LibraryStyleGuide#Overview).


And the DPT policy
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
tells me something about git-buildpackage and gbp.

So as a novice I am confused.

Kind
Christian

Wiki: Debian Python Policy docu not on team site

[c . buhtz]

Hello,

this is about the wiki page of that team.
https://wiki.debian.org/Teams/PythonTeam

I accidentally found the "Debian Python Policy documentation".
https://www.debian.org/doc/packaging-manuals/python-policy/

Looks nice and very important for new team members.

Maybe it would help if it is linked on the team wiki page.

Kind
Christian Buhtz

Difference between "python-debian team" and "Debian Python Team"

[c . buhtz]

Hello together,

what are the differences between this two salsa groups?

https://salsa.debian.org/python-team

https://salsa.debian.org/python-debian-team

As a novice in debian python packaging it extremely confuses me. And I 
have impression that "team sites" in salsa (e.g. the two links above) do 
not contain detailed descriptions about the teams.


Kind
Christian

Re: xlsxwriter: How to change homepage url

[c . buhtz]

Dear Emmanuel,

Am 15.09.2021 21:36 schrieb Emmanuel Arias:
Looking in the salsa repo [0], it is very old. And that shouldn't 
happen. I

can updated to the last unstable version tonight/tomorrow.


Just to improve my knowledge about Debian processes: What does it mean 
to update the salsa repo to the current upstream? Is it the same as 
create a new package? Or is it just one step into creating a new 
package?


Or, perhaps Christian (the initial of this thread) can/want to do it 
(Christian,

write to me if you need help)?


Not yet, thanks. I am to fresh and will focus on one package only 
("feedparser") to improve my learning.

But I will look at "xlsxwriter" and learn.


btw: I am not sure if this list is the right place. But the DPMT is
named as "uploaders" of that package. And I am confused about that the
"maintainer" is a ubuntu-list (Team?).


That would be great, but I would leave it to the current maintainer to 
do

that, also seems to be a group ¿?.  I cc to the maintainer(s).


They still answered my question on their own list:
https://lists.ubuntu.com/archives/checkbox-devel/2021-September/000491.html

They do not want to maintain anymore. And they asked about open a WNPP 
for it.


This would have been my question, too. If we do not create a new package 
version now how could we document the new information's about the 
maintainership somewhere for someone in the future?


As a newcomer, I am taking a step back so as not to cause more trouble. 
;) I would like to suggest that someone from the experienced DD here 
answer the maintainer direct what the next steps should be and who 
should do them. Would be nice if you could put me into CC.


Kind
Christian

Re: Python style guide checker (formerly called pep8)

[c . buhtz]

Am 12.09.2021 10:23 schrieb Geert Stappers:

In which package is a pep8 code style checker?


Upstream "pep8" was renamed to "pycodestyle".
So look at
https://tracker.debian.org/pkg/pycodestyle

feedparser: New packaging

[c . buhtz]

Dear list members,
dear Mr. Millon,

I am interested in packaging “feedparser” 
(https://tracker.debian.org/pkg/feedparser) for Debian. I addressed Mr. 
Millon directly because he is named as "uploader" for that package. The 
"maintainer" is the "Debian Python Team". So is this list the right 
place to contact that team?


The stable package (6 years old) is far behind upstream. I am motivated 
because a) my own work depends on feedparser and b) I want to learn and 
will invest more resources in packaging other packages (e.g. 
"backintime"). Therefore, feedparser would be my learning start. I know 
the maintainer and packaging guides. Of course, I need to dive deeper 
into them but beside the technical issues, I have an idea about the 
"social system" behind it.


First, I want to be sure not stealing work from someone. Is there an 
active maintainer on the Debian side for the package "feedparser"?


Second, I am aware that I need an "uploader" because I do not have (and 
do not want to) have write access to the repository. However, this is a 
far away problem because the package itself needs to get done first. ;)


Third (and most important), I need someone like a mentor. Whom can I ask 
when I have background questions that are not mentioned in the wiki or 
if I have technical problems? I need someone take my hand and someone to 
kick my butt when I need it. ;)


I am sure it is helpful to introduce myself to the community. Which 
place would be the best for it? The Debian Python Mailinglist or 
anywhere else? Or a link to a Debian Wiki Entry?


Best regards,
Christian Buhtz