Re: morph's abandoned packages (list)

[Bo YU]

hi!

On Sat, Mar 30, 2024 at 8:20 AM Thomas Goirand  wrote:
>
> On 3/29/24 21:18, Timo Röhling wrote:
> > Hi Thomas,
> >
> > * Thomas Goirand  [2024-03-17 23:09]:
> >> Anyone is welcome to join, it's just that I'm using git tag workflow,
> >> so it doesn't fit in the DPT, but that's the only thing.
> > I am not familiar with that workflow and could not find any
> > documentation. Can you give me a quick overview what I should do
> > differently from the "regular" DPT workflow?
> >
> > Cheers
> > Timo
>
> I'm not using pristine-tar, or gbp import-orig, and don't use upstream
> tarballs, but git only. Everything is done in a single (debian) branch.
Just share the workflow of DPT I always follow[0]:
```
$ uscan   # Download your package's upstream original tarball
$ tar -xvf srcpkgname_1.0.orig.tar.gz
$ cd srcpkgname_1.0
$ git init
$ git checkout -b upstream
$ git add .
$ git commit -m "import srcpkgname_1.0.orig.tar.gz"
$ git tag -s upstream/1.0
$ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream
$ git checkout -b debian/master
```
And upgrade upstream release[1]. These should be enough.
If given team maintenance, I would like to suggest to follow this.

[0]: https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package
[1]: https://wiki.debian.org/Python/GitPackaging#New_upstream_release

> The only thing that needs to be done, is to push upstream tags to the
> Debian repository. The git history contains all upstream commits then,
> because the workflow is to merge upstream tag.
>
> To upgrade to a newer upstream tag, simply do:
>
> ./debian/rules fetch-upstream-remote
> git merge -X theirs 
> dch --newversion  -m "New upstream release."
>
> Then simply generate the upstream tarball from the git tag:
> ./debian/rules gen-orig-xz
>
> The fetch-upstream-remote and gen-orig-xz are from the
> openstack-pkg-tools package, though I heard others in Debian have
> standardized on something else. But who cares what wrapper one is using,
> really. The point is to fetch upstream tags, merge them, and use "git
> archive" to generate an orig tarball before building and uploading to
> Debian.
>
> If the upstream release was already uploaded to Debian, best is to
> download it instead of generating it, as (like with pristine-tar)
> regenerating it may (in some cases) lead to a different checksum.
>
TIL also, thanks.

BR,
Bo
> Cheers,
>
> Thomas Goirand (zigo)
>

Re: morph's abandoned packages (list)

[Thomas Goirand]

On 3/29/24 21:18, Timo Röhling wrote:

Hi Thomas,

* Thomas Goirand  [2024-03-17 23:09]:
Anyone is welcome to join, it's just that I'm using git tag workflow, 
so it doesn't fit in the DPT, but that's the only thing.
I am not familiar with that workflow and could not find any 
documentation. Can you give me a quick overview what I should do 
differently from the "regular" DPT workflow?


Cheers
Timo


I'm not using pristine-tar, or gbp import-orig, and don't use upstream 
tarballs, but git only. Everything is done in a single (debian) branch. 
The only thing that needs to be done, is to push upstream tags to the 
Debian repository. The git history contains all upstream commits then, 
because the workflow is to merge upstream tag.


To upgrade to a newer upstream tag, simply do:

./debian/rules fetch-upstream-remote
git merge -X theirs 
dch --newversion  -m "New upstream release."

Then simply generate the upstream tarball from the git tag:
./debian/rules gen-orig-xz

The fetch-upstream-remote and gen-orig-xz are from the 
openstack-pkg-tools package, though I heard others in Debian have 
standardized on something else. But who cares what wrapper one is using, 
really. The point is to fetch upstream tags, merge them, and use "git 
archive" to generate an orig tarball before building and uploading to 
Debian.


If the upstream release was already uploaded to Debian, best is to 
download it instead of generating it, as (like with pristine-tar) 
regenerating it may (in some cases) lead to a different checksum.


Cheers,

Thomas Goirand (zigo)

Re: Uscan: watch and changelog

[Soren Stoutner]

I agree.  Much of Debian’s documentation is not written for people who are new 
to the topic, but for people who already know the information and just want to 
be reminded about some of the tricky parts.

Anything you can do to improve the documentation would be greatly appreciated.

On Friday, March 29, 2024 1:12:12 PM MST c.bu...@posteo.jp wrote:
> On 2024-03-29 11:29 Soren Stoutner  wrote:
> > One of the interesting things about uscan
> 
> This is that kind of "big picture" explanations that should be written
> to the Wiki. Texts like this are the missing link between man pages,
> references and policy documents.
> 
> Thanks in advance


-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: morph's abandoned packages (list)

[Timo Röhling]

Hi Thomas,

* Thomas Goirand  [2024-03-17 23:09]:
Anyone is welcome to join, it's just that I'm using git tag 
workflow, so it doesn't fit in the DPT, but that's the only thing.
I am not familiar with that workflow and could not find any 
documentation. Can you give me a quick overview what I should do 
differently from the "regular" DPT workflow?


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Uscan: watch and changelog

[c.buhtz]

On 2024-03-29 11:29 Soren Stoutner  wrote:
> One of the interesting things about uscan

This is that kind of "big picture" explanations that should be written
to the Wiki. Texts like this are the missing link between man pages,
references and policy documents.

Thanks in advance

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Rene Engelhard]

Hi,

Am 25.03.24 um 19:17 schrieb Julian Gilbey:

   * Reading and writing file formats (like CSV, Apache ORC, and Apache
 Parquet)


liborcus supports this (Apache Parquet) if built with Apache Arrow. And 
thus makes LibreOffice being able to handle it.


I didn't invest any time in Apache Arrow since I am already too low on 
time anyway and I deemed it too a "low popularity" thing anyway.



So this is a plea for anyone looking for something really helpful to
do: it would be great to have a group of developers finally package
this!

Indeed.

There was some initial work done (see the RFP bug report for
details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
but that is fairly old now.  As Apache Arrow supports numerous
languages, it may well benefit from having a group of developers with
different areas of expertise to build it.  (Or perhaps it would make
more sense to split the upstream source into a collection of different
Debian source packages for the different supported languages.  I don't
know.)


Would definitely make transitions easier.


  Unfortunately I don't have the capacity to devote any time to
it myself.


Dito.


Regards,


Rene

Re: Seeking a small group to package Apache Arrow (was: Bug#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics)

[Diane Trout]

On Mon, 2024-03-25 at 18:17 +, Julian Gilbey wrote:
> 
> 
> So this is a plea for anyone looking for something really helpful to
> do: it would be great to have a group of developers finally package
> this!  There was some initial work done (see the RFP bug report for
> details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021),
> but that is fairly old now.  As Apache Arrow supports numerous
> languages, it may well benefit from having a group of developers with
> different areas of expertise to build it.  (Or perhaps it would make
> more sense to split the upstream source into a collection of
> different
> Debian source packages for the different supported languages.  I
> don't
> know.)  Unfortunately I don't have the capacity to devote any time to
> it myself.
> 
> Thanks in advance for anyone who can step forward for this!

I've been maintain dask and anndata and saw that apache arrow was
getting increasingly popular.

I took the current science-team preliminary packaging 7.0.0 packaging
and managed to get it to build through a combination of patches and
turning off features.

I even mostly managed to get pyarrow to build. (Though some tests fail
due to pytest lazy-fixture being abandoned).

I pushed my current work in progress to.

https://salsa.debian.org/diane/arrow.git

Was anyone else planning on working on it or should I push my updates
to the science-team package?

Diane

Re: Uscan: watch and changelog

[Soren Stoutner]

On Friday, March 29, 2024 10:16:56 AM MST c.bu...@posteo.jp wrote:
> There is no "opts=". So again. Why would you suggest to use "opts="? I want 
to
> learn. I don't want to fight.

One of the interesting things about uscan is there are often multiple different 
ways to connect to an upstream source and get what you want out of it.

So, for example, if upstream posts tarballs, you can scan the HTML for those 
and find one that matches the latest version number in the changelog (or one 
with a newer version number, which uscan can use to notify you an update is 
available).

However, uscan also speaks git.  If you use `opts=git`, then instead of 
scanning the HTML looking for a tarball, it connects through git and looks at 
the tags to find a suitable release.  It then clones that commit and uses the 
source to produce a tarball.

Some upstream repositories both produce release tarballs and tag their 
releases in git, so either approach would work.  Some only do one or the 
other.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: Updated package list with packages open for adoption (Was: morph's abandoned packages (list))

[Andreas Metzler]

On 2024-03-28 Andreas Tille  wrote:
[...]
> ? #1065221 O: py7zr -- pure Python 7-zip library
>rdepends: recoll (Kartik Mistry )
>  calibre (YOKOTA Hiroshi ,
>   Martin Pitt ,
>   Nicholas D Steeves )
>   Hint: This package is lagging quite behind upstream
>   Latest upstream needs https://github.com/miurahr/multivolume
>   However:
>   This repository has been archived by the owner on Jul 17, 2022. It 
> is now read-only.
>   It might make sense to either 
>  ask py7zr authors whether this will be needed in future releass or
>  pick latest py7zr version that does not need multivolume


Hello,

I think there might be a misunderstanding here, the github site was
archived with the remark:
| This project has given up GitHub. (See Software Freedom Conservancy's give up 
GitHub site for details.)

| You can now find this project at CodeBerg.org instead.

linking to https://codeberg.org/miurahr/multivolume . Currently
both repositories are identical (i.e. no commits since April 2022).

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Uscan: watch and changelog

[Paul Boddie]

On Friday, 29 March 2024 17:39:04 CET c.bu...@posteo.jp wrote:
> 
> On 2024-03-29 16:23 Carsten Schoenert  wrote:
> > You need to use "opts=mode=git, ...", see the man page of uscan.
> 
> Are you sure. For example this watch file do not use "opts="
> https://sources.debian.org/src/backintime/1.4.3-1/debian/watch/

If I look at your releases page, I see that you have one release that you will 
probably be wanting to package:

https://codeberg.org/buhtz/hyperorg/releases

However, uscan seems to be driven by the debian/changelog and debian/watch 
files, with the former supplying the version or release to be searched for, 
and the latter specifying the mechanism by which the searching will occur.

So, I imagine that your debian/changelog would need an entry starting with 
something like this:

hyperorg (0.1.0-1) unstable; urgency=low

If you hadn't tagged a release in the repository, then you would probably have 
to invent a suitable version number based on the changeset identifier. 
Something like this perhaps:

hyperorg (0.1.0+git20240329.4a77811214-1) unstable; urgency=low

Here, I've used the changeset identifier of 4a77811214 which is the latest 
commit that I can see, and that hopefully serves to illustrate the principle.

I suppose that the watch file would then need to use the "mode=git" option.

[...]

> > And uscan will find the most recent version matching the regexp.
> 
> I see 3 different regex patterns in this line. Why?

I must admit to just copying the recommended patterns for my packaging 
exercises, largely because although I can happily explore the process of 
downloading a Web page - in your case, the one mentioned above - and parsing 
the HTML to get at the download links, I assume that someone has already done 
that hard work.

But to answer your question, what is happening is that the release or version 
from the changelog is transformed into something that might appear on the 
downloaded page. You need to get from "hyperorg-0.1.0-1" to this:

https://codeberg.org/buhtz/hyperorg/archive/v0.1.0.tar.gz

Or if a specific changeset is involved, the process is a bit more complicated, 
but would involve transforming "hyperorg-0.1.0+git20240329.4a77811214-1" into 
this:

https://codeberg.org/buhtz/hyperorg/archive/
4a77811214e5bd73247a197dbb5d1a4367c99109.tar.gz

To summarise, uscan is just searching a page listing releases or, in the 
second case, a specific Web page for an appropriate download that it can then 
obtain.

Hope this helps a little!

Paul

Re: Uscan: watch and changelog

[c.buhtz]

On 2024-03-29 18:07 Carsten Schoenert  wrote:
> Am 29.03.24 um 17:39 schrieb c.bu...@posteo.jp:
> > On 2024-03-29 16:23 Carsten Schoenert 
> > wrote:
> >> You need to use "opts=mode=git, ...", see the man page of uscan.
> > 
> > Are you sure.
> 
> Of course I'm sure, I've tested the snippets before posting it on the 
> list. Did you test this on your side and have any issues?

Again I was not clear. You wrote "need". So it is mandatory?
Then I gave you an example where "opts=" is not used. So it seems not
to be mandatory in all cases.

> > For example this watch file do not use "opts="
> > https://sources.debian.org/src/backintime/1.4.3-1/debian/watch/
> 
> You need to ask the person that did probably this creation or 
> modification. I can't answering this.

This line seems to work:

https://codeberg.org/buhtz/hyperorg/tags .*\/v(\d+).(\d+).(\d+).tar.gz

There is no "opts=". So again. Why would you suggest to use "opts="? I want to 
learn. I don't want to fight.

Re: Uscan: watch and changelog

[Carsten Schoenert]

Am 29.03.24 um 17:39 schrieb c.bu...@posteo.jp:

Dear Carsten,

thank for your reply and your patience with me. :)

On 2024-03-29 16:23 Carsten Schoenert  wrote:

You need to use "opts=mode=git, ...", see the man page of uscan.


Are you sure.


Of course I'm sure, I've tested the snippets before posting it on the 
list. Did you test this on your side and have any issues?



For example this watch file do not use "opts="
https://sources.debian.org/src/backintime/1.4.3-1/debian/watch/


You need to ask the person that did probably this creation or 
modification. I can't answering this.



Also some examples on the wikipage about "debian/watch" do not use
"opts=".


You seems to expect that the wiki is all known and answering place. No, 
that is this not. It's by nature always "outdated". But it's a wiki, 
everyone can edit it.



Please be aware that I don't only want to solve one technical problem
with one specific package. I want to understand the whole thing ("big
picture") to improve the documentation.


Well, that's not that complicated for uscan, it does mainly one thing 
(which is done in multiple steps, have a look into the man page), it's 
scanning upstream resources, fetching data and creates an tarball ready 
for importing.



opts="mode=git, \
   
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/,
\ dversionmangle=s/\+ds(\.?\d+)?$//" \
https://codeberg.org/buhtz/hyperorg.git \
   refs/tags/v(\d+\S+)


And uscan will find the most recent version matching the regexp.


I see 3 different regex patterns in this line. Why?


I see one that is relevant to your original question. The other two you 
mean are used in other "opts" variables, these variable are also 
explained too in the man page of uscan.


--
Regards
Carsten

Re: Uscan: watch and changelog

[c.buhtz]

Dear Carsten,

thank for your reply and your patience with me. :)

On 2024-03-29 16:23 Carsten Schoenert  wrote:
> You need to use "opts=mode=git, ...", see the man page of uscan.

Are you sure. For example this watch file do not use "opts="
https://sources.debian.org/src/backintime/1.4.3-1/debian/watch/

Also some examples on the wikipage about "debian/watch" do not use
"opts=".

Please be aware that I don't only want to solve one technical problem
with one specific package. I want to understand the whole thing ("big
picture") to improve the documentation.


> > opts="mode=git, \
> >   
> > uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/,
> > \ dversionmangle=s/\+ds(\.?\d+)?$//" \
> > https://codeberg.org/buhtz/hyperorg.git \
> >   refs/tags/v(\d+\S+)
> 
> And uscan will find the most recent version matching the regexp.

I see 3 different regex patterns in this line. Why?

Re: Uscan: watch and changelog

[c.buhtz]

On 2024-03-29 19:26 Andrey Rakhmatullin  wrote:
> On Fri, Mar 29, 2024 at 02:05:41PM +, c.bu...@posteo.jp wrote:
> > The Wiki page  is not
> > up-2-date
> What's wrong with it?

I was not clear in my initial mail, where I only wrote that "Uscan
don't work without having a changelog.". The Wiki page do not mention
that.

But I will edit the page after I figured out some details.

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

[c.buhtz]

On 2024-03-29 15:34 weepingclown  wrote:
> As I understand it, the current
> problem we have is more about the wiki being less organized than
> there not being sufficient resources or them not being easily
> accessible to everyone.

Correct. The information is there. But the linkage between them is
often missing. But there is also some outdated or redundant information.

As a positive (but of course not perfect) example I can name the "Guide
for Debian Maintainers" [1] by Osamu Aoki. In its preface these
describe its own location related to all the other packaging
documentation existing. Some pages later it gives a short introduction
to some tools and how they belong together. He gives the "big picture".

[1] -- 

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

[c.buhtz]

On 2024-03-29 14:48 Carsten Schoenert  wrote:
> BTW: I posted my way on how I created a new Python package for Debian
> in the German Debian forum extensively and in length last year while
> DC [1]. Because I also know were starters typically struggle with and
> I was in the need to introduce a new Python package as a dependency
> for another package.
> I'm unsure if Christian did follow my steps
> [...]
> [1] https://debianforum.de/forum/viewtopic.php?t=187764

I followed this steps these days. We discussed some details but the
discussion got stuck. I didn't received an answer of my last question
in that thread.

Kind
Christian Buhtz

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

[weepingclown]

Hi,

As an addendum, there is also dedicated wiki pages[0] intended to be of help to 
newcomers. Not saying that solves everything mentioned before, but it does help 
quite a lot. As I understand it, the current problem we have is more about the 
wiki being less organized than there not being sufficient resources or them not 
being easily accessible to everyone.

[0] https://wiki.debian.org/Packaging/Learn

Best,
Ananthu

Re: Uscan: watch and changelog

[Carsten Schoenert]

Am 29.03.24 um 15:05 schrieb c.bu...@posteo.jp:


I assume I have not yet understood the purpose of the changelog in
context of uscan. What do I miss?

This is "debian/watch":

version=4
# RegEx in Perl dialect
https://codeberg.org/buhtz/hyperorg/archive/v(\d+).(\d+).(\d+).tar.gz

This is a dummy "debian/changelog":

hyperorg (0.0-dev) UNRELEASED; urgency=low

   * Changes made in this version

  -- Maintainer Name   Thu, 01 Jul 2021 12:00:00
  +


You need to use "opts=mode=git, ...", see the man page of uscan.

e.g. like this


$ cat debian/watch
version=4

opts="mode=git, \
  
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/, \
  dversionmangle=s/\+ds(\.?\d+)?$//" \
https://codeberg.org/buhtz/hyperorg.git \
  refs/tags/v(\d+\S+)


And uscan will find the most recent version matching the regexp.

$ uscan --verbose --no-download 
uscan info: uscan (version 2.23.7) See uscan(1) for help

uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="hyperorg" version="0.0-dev" (as seen in debian/changelog)
uscan info: package="hyperorg" version="0.0" (no epoch/revision)
uscan info: ./debian/changelog sets package="hyperorg" version="0.0"
uscan info: Process watch file at: debian/watch
package = hyperorg
version = 0.0
pkg_dir = .
uscan info: opts: mode=git, 
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/, 
dversionmangle=s/\+ds(\.?\d+)?$//
uscan info: line: https://codeberg.org/buhtz/hyperorg.git refs/tags/v(\d+\S+)
uscan info: Parsing mode=git
uscan info: Parsing  
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\.?\d*)$/$1~$2/
uscan info: Parsing  dversionmangle=s/\+ds(\.?\d+)?$//
uscan info: line: https://codeberg.org/buhtz/hyperorg.git refs/tags/v(\d+\S+)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.0
uscan info: Execute: git ls-remote https://codeberg.org/buhtz/hyperorg.git
uscan info: Found the following matching refs:
 refs/tags/v0.1.0 (0.1.0)
 HEAD ()
 refs/heads/fix/131subfolders ()
 refs/heads/fix/30_and_70_links ()
 refs/heads/latest ()
 refs/pull/138/head ()
 refs/pull/139/head ()
uscan info: Looking at $base = https://codeberg.org/buhtz/hyperorg.git with
$filepattern = refs/tags/v(\d+\S+) found
$newfile = refs/tags/v0.1.0
$newversion  = 0.1.0
$lastversion = 0.0
uscan info: Upstream URL(+tag) to download is identified as
https://codeberg.org/buhtz/hyperorg.git refs/tags/v0.1.0
uscan info: Filename (filenamemangled) for downloaded file: 
hyperorg-0.1.0.tar.xz
Newest version of hyperorg on remote site is 0.1.0, local version is 0.0
 => Newer package available from:
=> https://codeberg.org/buhtz/hyperorg.git refs/tags/v0.1.0
uscan info: Scan finished


--
Regards
Carsten

Re: Uscan: watch and changelog

[Andrey Rakhmatullin]

On Fri, Mar 29, 2024 at 02:05:41PM +, c.bu...@posteo.jp wrote:
> The Wiki page  is not up-2-date
What's wrong with it?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Uscan: watch and changelog

[Andrey Rakhmatullin]

On Fri, Mar 29, 2024 at 07:21:48PM +0500, Andrey Rakhmatullin wrote:
> > I assume I have not yet understood the purpose of the changelog in
> > context of uscan. What do I miss?
> It needs debian/changelog to know the current upstream version of the
> package.
(also this is answered explicitly in uscan(1))



-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Uscan: watch and changelog

[Andrey Rakhmatullin]

On Fri, Mar 29, 2024 at 02:05:41PM +, c.bu...@posteo.jp wrote:
> X-Post: 
> 
> Hi,
> 
> try to get uscan working with an upstream repo hosted at Codeberg.org
> (Forgejo based).
> 
> The Wiki page  is not up-2-date
> and I try to figuring out how it works to update that page. Uscan don't
> work without having a changelog. So I created one. But uscan can not
> find my tarball.
> 
> I assume I have not yet understood the purpose of the changelog in
> context of uscan. What do I miss?
It needs debian/changelog to know the current upstream version of the
package.

> version=4
> # RegEx in Perl dialect
> https://codeberg.org/buhtz/hyperorg/archive/v(\d+).(\d+).(\d+).tar.gz
[...]
> uscan info: Requesting URL:
>https://codeberg.org/buhtz/hyperorg/archive/
> uscan warn: In watchfile debian/watch, reading webpage
>   https://codeberg.org/buhtz/hyperorg/archive/ failed: 404 Not Found
> uscan info: Scan finished
I can confirm it's 404.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

New upstream version for python-pint

[Antonio Valentino]

Dear Thomas and Ondřej,
a couple of packages that I maintain are impacted by an RC bug in 
python-pint (#1067318).
I think that an update to the to the latest pint version 0.23 should be 
sufficient to fix the issue.


If you agree, I would like prepare the package for the new upstream 
version in the salsa.

Of course I will let to you the review and upload.

Please let me know,


kind regards
--
Antonio Valentino

Uscan: watch and changelog

[c.buhtz]

X-Post: 

Hi,

try to get uscan working with an upstream repo hosted at Codeberg.org
(Forgejo based).

The Wiki page  is not up-2-date
and I try to figuring out how it works to update that page. Uscan don't
work without having a changelog. So I created one. But uscan can not
find my tarball.

I assume I have not yet understood the purpose of the changelog in
context of uscan. What do I miss?

This is "debian/watch":

version=4
# RegEx in Perl dialect
https://codeberg.org/buhtz/hyperorg/archive/v(\d+).(\d+).(\d+).tar.gz

This is a dummy "debian/changelog":

hyperorg (0.0-dev) UNRELEASED; urgency=low

  * Changes made in this version

 -- Maintainer Name   Thu, 01 Jul 2021 12:00:00
 +


The output of "uscan --no-download --verbose --debug":


uscan info: uscan (version 2.21.3+deb11u1) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="hyperorg" version="0.0-dev" (as seen in
debian/changelog) uscan info: package="hyperorg" version="0.0" (no
epoch/revision) uscan info: ./debian/changelog sets package="hyperorg"
version="0.0" uscan info: Process watch file at: debian/watch
package = hyperorg
version = 0.0
pkg_dir = .
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.0
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.0
uscan info: Requesting URL:
   https://codeberg.org/buhtz/hyperorg/archive/
uscan warn: In watchfile debian/watch, reading webpage
  https://codeberg.org/buhtz/hyperorg/archive/ failed: 404 Not Found
uscan info: Scan finished

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

[Carsten Schoenert]

Hello Paul,

Am 29.03.24 um 13:49 schrieb Paul Boddie:

On Friday, 29 March 2024 09:52:14 CET Carsten Schoenert wrote:


Starting with Debian packaging isn't a easy thing and there is *not* the
one way to do it right. And there are for sure hundreds of HowTos out
there. You will need to try a few of them and chose in the end the
workflow that fit's best for you.


The problem with this advice is that for the Debian Python Team, there
probably aren't many ways to "do it right". Instead, as I understand it, there
will be very few ways that people tolerate, as recent discussion on this list
has indicated.


the question in general was not about the right and correct way in the 
DPT, it was about starting from scratch. At least I don't know of a 
right way from scratch that is written down as policy, would also make 
no real sense to me.
Starting Debian packaging isn't easy, but it's going to be more 
complicated if you think there is only one way that's correct. In the 
end DAK needs some files, how you create them is on your own.
The DPT policy doesn't say you need to do packaging a very specif way, 
it stated that git-buildpackage is the tool for organizing the VCS data.


The DPT policy gives you the freedom to do your packaging preparation 
how ever you like, but it is expected you finally upload the data of 
your work into a git tree with a specific layout so others can take your 
work and reproduce a package by using gbp.


gbp is very flexible, so if you like to use sbuild in favor of pbuilder 
e.g. than you can simply do so.


BTW: I posted my way on how I created a new Python package for Debian in 
the German Debian forum extensively and in length last year while DC 
[1]. Because I also know were starters typically struggle with and I was 
in the need to introduce a new Python package as a dependency for 
another package.
I'm unsure if Christian did follow my steps by trying to reproduce the 
package I was working on. I'm thinking he didn't, if he did then I'm 
wondering where he is having problems to prepare his package. Until now 
there is no "I did this and this, ..., I failed."


The feedback on my mini HowTo was quite low. So I wont do such things again.


In the end, I did my usual thing and distilled the documentation's prose down
to a concise workflow to remind me of what I might need to do if I were to
start packaging something else. In fact, I wrote the following for the Moin
2.0 packages and then made use of it for the other package:

git branch -c master upstream
git checkout -b debian/master

git add debian
git commit

git push origin 
gbp buildpackage --git-debian-branch=debian/master \
   --git-upstream-tag='upstream/%(version)s' --git-builder=sbuild


gbp makes all these steps easier I think. Even if you want to do it 
completely manually. Basically I do this


mkdir new-package && cd new-package
git init
# create a file debian/gbp.conf if you want to have it more convenient
gbp import-orig [--verbose] --sign-tags --pristine-tar 
/path/to/tarball-version.tar.{gz,...,xz}

# add required files into debian/
gbp dch -aR
gbp buildpackage --git-ignore-new [--git-builder=what_ever_you_like]
# run lintian, squash issues, prepare autopkgtest, commit changes atomically
# create a patch queue if needed
gbp pq import [--ignore-new]
# work on patches, commit them
gbp qp export
git add debian/patches && git commit
# hack further, finalize the package, create the final changelog entry 
if needed

git commit debian/changlog
gbp buildpackage ...
# upload, wait for the DAK email
gbp tag --sig-tags
git remote add salsa 
gbp push [salsa]

But we will find ten more possible ways to create a new package from 
scratch. :)


...

P.S. The argument made about needing to understand what happens "under the
hood" is something of an indictment of the way technology is developed these
days. A tool that is meant to simplify something should present its own
coherent level of abstraction; deferring to lower-level mechanisms is
something that the Git developers and community like to do, which is why the
usability of Git is the subject of occasional jokes and somewhat more
infrequent attempts to wrap it in more usable interfaces.


A good tool is always helpful, and a good first time user experience is 
also important. But I've seen a lot of people and contributors that were 
completely lost once a errors message was coming up and they did not 
know what to do and were to look. A good developer or engineer is always 
able to help themselves. Means he need to know how things work or at 
least were to look next to solve problems.


[1] https://debianforum.de/forum/viewtopic.php?t=187764

--
Regards
Carsten

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

[Paul Boddie]

On Friday, 29 March 2024 09:52:14 CET Carsten Schoenert wrote:
> 
> Starting with Debian packaging isn't a easy thing and there is *not* the
> one way to do it right. And there are for sure hundreds of HowTos out
> there. You will need to try a few of them and chose in the end the
> workflow that fit's best for you.

The problem with this advice is that for the Debian Python Team, there 
probably aren't many ways to "do it right". Instead, as I understand it, there 
will be very few ways that people tolerate, as recent discussion on this list 
has indicated.

> git-buildpackage is one of the high level tools that can and should
> packaging tasks easier, to use it effective you will need to know what
> it is doing under the hood, means you need to be familiar with the low
> level tools that getting called by gbp.

I packaged stuff for Debian about ten years ago or so and recently repackaged 
one tool, whose package is now parked in a state where it could conceivably be 
incorporated into Debian but is evidently not of interest to anyone here (or I 
need to promote it more, perhaps). I have also been packaging Moin 2.0 which 
is coincidentally relevant to these documentation discussion threads.

After following the advice on the Debian Wiki about suitable approaches for 
packaging Python libraries and applications, I ended up reading all about gbp 
and trying out the different suggestions in its documentation. Although quite 
helpful, this documentation does not give concrete advice about what would-be 
packagers should do, so it really does fall on context-specific advice to fill 
in those gaps.

In the end, I did my usual thing and distilled the documentation's prose down 
to a concise workflow to remind me of what I might need to do if I were to 
start packaging something else. In fact, I wrote the following for the Moin 
2.0 packages and then made use of it for the other package:

git branch -c master upstream
git checkout -b debian/master

git add debian
git commit

git push origin 
gbp buildpackage --git-debian-branch=debian/master \
  --git-upstream-tag='upstream/%(version)s' --git-builder=sbuild

This saves me from having to re-read the gbp documentation or find the 
appropriate mention on the Debian Wiki of whatever the accepted approach might 
be. I also wrote summaries to maintaining patches since it seemed that gbp 
could be quite obstructive if not operated in precisely the right fashion, not 
entirely obvious from its documentation.

Obviously, this leaves a lot of stuff out, but it is a reminder and not a 
complete guide. Indeed, the issue of what the Debian directory might contain 
is almost an orthogonal topic to the mechanics of gbp. And then there are the 
social or collaborative aspects of the exercise as well, like setting up a 
Salsa account and project, filing an ITP, and so on.

Yes, such matters are covered in the more general documentation, at least if 
it was updated and no longer refers to Alioth or whatever. But in this context 
the advice will be quite specific and not vague suggestions that present more 
choices to be made rather than eliminating them.

In any case, I commend this effort to improve the documentation. In some ways, 
it really is quite a brave endeavour. I would have made edits to various pages 
myself, but I don't want to tread on any toes, and I don't really have much 
time to spend on this matter alongside numerous other commitments at the 
moment.

Paul

P.S. The argument made about needing to understand what happens "under the 
hood" is something of an indictment of the way technology is developed these 
days. A tool that is meant to simplify something should present its own 
coherent level of abstraction; deferring to lower-level mechanisms is 
something that the Git developers and community like to do, which is why the 
usability of Git is the subject of occasional jokes and somewhat more 
infrequent attempts to wrap it in more usable interfaces.

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

[c.buhtz]

On 2024-03-29 09:52 Carsten Schoenert  wrote:
> New Maintainer Guide:
> https://www.debian.org/doc/manuals/maint-guide/

That document itself points to a new rewritten "tutorial" in its first
paragraph.



I suggest to remove one of them. There is to much redundant and
sometimes out dated "documentation".

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

[Carsten Schoenert]

Am 29.03.24 um 08:51 schrieb c.bu...@posteo.jp:

This document is not Python related. The section about Python is empty.
See section 15 at PDF page 65.


This isn't really needed yet, packaging Debian packages is technically 
always the same.
You seems to have a general problem to understand what is the basic 
workflow, what are the steps, what are the various files in the debian/ 
folders are for, what are the constraints and relationships of these 
files and how the low level tools work together. You need to work on 
this first before starting to dive into special handling for different 
languages done by the helper tools.


So Mechtilde pointed correctly to the

New Maintainer Guide:
https://www.debian.org/doc/manuals/maint-guide/

and to the
Developer Reference:
https://www.debian.org/doc/manuals/developers-reference/

Asking meta questions (It's not working, what do I wrong?) isn't 
helpful, ask specific questions and describe what you already did befor 
you encountered the problem.


Starting with Debian packaging isn't a easy thing and there is *not* the 
one way to do it right. And there are for sure hundreds of HowTos out 
there. You will need to try a few of them and chose in the end the 
workflow that fit's best for you.


git-buildpackage is one of the high level tools that can and should 
packaging tasks easier, to use it effective you will need to know what 
it is doing under the hood, means you need to be familiar with the low 
level tools that getting called by gbp.


--
Regards
Carsten

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

[Mechtilde]

Hello everyone,

first some general information.

As I understand the information from the python-team in the wiki is to 
inform special handlin here.


Newcommers should first read
the New Maintainer Guide and the Developer Reference

You want a "complete" description about packaging also for newcommers?
At the start you don't want to read a companion with several hundred pages.

If some want to have more information you can read

https://ddp-team.pages.debian.net/dpb/BuildWithGBP.pdf in German

The automated translation to English is deactivated yet but in the 
sources at salsa.debian.org


It is still work in Progress.

Kind regards

Mechtilde
Am 29.03.24 um 04:45 schrieb Boyuan Yang:

Hi,

(I am off debian-python mailing list -- please CC me.
Also, I cannot include previous text in the threads because
I don't have them in my mailbox. Sorry!)

Reading https://lists.debian.org/debian-python/2024/03/msg00152.html
and https://lists.debian.org/debian-python/2024/03/msg00151.html ,
I can see that
https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package is
indeed poorly written:

*) It still points to pages of GitDpm, which the Python team is not
using anymore.

*) It does not describe the procedure of packaging from scratch very
well. To be precise, it lacks info about packaging from a status where
both git repo and the .dsc source package are nonexistant. It doesn't
describe the "gbp import-orig" subcommand for packaging initialization,
which is suprising. The same issue applies to
https://wiki.debian.org/PackagingWithGit .

For newcomers, I believe they will get lost at the very first line on
https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package ,
which is "uscan". No one knows why uscan can work with an empty
directory. The newcomer may not even know what uscan is (actually they
are supposed to know what uscan is in advance -- but explanation should
be added here anyway).

If you really want a readily-available better documentation, consider
reading the official documentation of git-buildpackage at
https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ .
After you understand that, merge the remaining useful information from
https://wiki.debian.org/Python/GitPackaging to get a thorough
understanding.

I don't have a good solution to Wiki pages yet since the article logic
needs some major editing.

Thanks,
Boyuan Yang


--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[c.buhtz]

Dear Boyuan Yang,

Thanks for your feedback.

> I can see that
> https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package is
> indeed poorly written:
> 
> *) It still
> [...]

I agree to your list of aspects that need to be improved.
It seems you really understood the "workflow" of a newbie.

> For newcomers, I believe they will get lost at the very first line on
> https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package

Exactly.

> If you really want a readily-available better documentation, consider
> reading the official documentation of git-buildpackage at
> https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ .
> After you understand that, merge the remaining useful information from
> https://wiki.debian.org/Python/GitPackaging to get a thorough
> understanding.

I am not willing to do this. With all respect to the DPT but I don't
write new documentation from scratch. I am not in the position. I can
improve existing documentation as I did in the past.

But this thread is about that I am on a point where I am lost in the
current documentation and someone else with more experience and
knowledge should take over and clear the path.

Thanks,
Christian Buhtz

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

[c.buhtz]

On 2024-03-29 07:48 Andreas Tille  wrote:
> Perhaps a hint to my Live packaging workshop
> 
> https://debconf23.debconf.org/talks/34-live-packaging-workshop/

Also not Python (but Go?) related but I will check it out.

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

[c.buhtz]

Dear Metchtilde,

Thanks for the reply.

On 2024-03-29 08:28 Mechtilde  wrote:
> If some want to have more information you can read
> 
> https://ddp-team.pages.debian.net/dpb/BuildWithGBP.pdf in German

This document is not Python related. The section about Python is empty.
See section 15 at PDF page 65.

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

[Andreas Tille]

Hi,

Am Thu, Mar 28, 2024 at 11:45:36PM -0400 schrieb Boyuan Yang:
> 
> I don't have a good solution to Wiki pages yet since the article logic
> needs some major editing.

I can't provide any help for the Wiki page for DPMT.  In Debian Med we
provide some resources for newcomers:

  Mentoring of the Month:

https://salsa.debian.org/med-team/community/MoM/-/wikis/Mentoring-of-the-Month-(MoM)

  Debian Med policy is more verbose about packaging details
https://med-team.pages.debian.net/policy/


Perhaps a hint to my Live packaging workshop

https://debconf23.debconf.org/talks/34-live-packaging-workshop/

might be helpful as well.  I did more of these[1] - unfortunately not
all recordings are available.

Kind regards
Andreas.

[1] https://people.debian.org/~tille/talks/other_en.html

-- 
https://fam-tille.de