Re: Question about blocked package to testing

[Robin Gustafsson]

Hi Elías,

> -Under build system it's fine [2] but with salsa-ci pipeline[3] it fails.
>  Do you know why?

The error in the build output [1] implies that GPICK_BUILD_DATE is
expected, but not found, among the environment variables. You probably
have it set in your local environment, but it's not being set
automatically and thus it's not being set in the CI pipeline.

I'm not so sure that the status in buildd should be interpreted as
proof of a successful (automated) build. The QA page states that it
was "Not built on buildd" [2] because you uploaded it pre-built.

> How can I test under a local environment?

I find sbuild [3] to be very helpful. It'll probably produce the same
error for you locally.

[1] https://salsa.debian.org/elias-guest/gpick/-/jobs/631212#L1178
[2] https://qa.debian.org/excuses.php?package=gpick
[3] https://wiki.debian.org/sbuild

Regards,
Robin

Re: How to update upstream when upstream has no releases

[Robin Gustafsson]

Hi Tong Sun,

> I was using `gbp import-orig --sign-tags --uscan` but it seems that
> `--uscan` cannot be used with `gbp import-orig` under the case of no
> upstream releases.

I believe it'll work if the debian/watch file is set up such as to
have uscan download the upstream's git repo. The "direct access to the
git repository" sections in the uscan manual provides examples of what
I'm referring to.

Regards,
Robin

Re: package prevented from migration due to "regression", but regression bug is fixed

[Robin Gustafsson]

> > yes, that's exactly what you'll need to do.  Also, it would be better if
> > you closed it with a fixed version as well.
>
> Ok, I will skip this since it was closed by someone else but in the
> future it would require a package update, got it.

I think you can do that with the "fixed" command [1] too, instead of
through a package upload.

[1] https://www.debian.org/Bugs/server-control#fixed

Regards,
Robin

Re: tsvtree: A command line tool to display TSV data in tree-like format

[Robin Gustafsson]

Hi Marcelo,

I'm a new/inexperienced contributor myself, but I have some
suggestions that could hopefully be useful to you.

> I have split the package and the debianization in different
> repositories.

It is fairly common to keep the packaging on a separate branch, if
your actual preference is to maintain it in the same repo. The
git-buildpackage tool has good support for that.

I'd suggest moving/mirroring the packaging repo to salsa.debian.org.
There were some relevant guidelines sent out on debian-devel-announce
just yesterday [1], including that one. Then you could also utilize
salsa-ci [2].

> I believe all packaging problems are fixed now. Please let me know any
> further improvements I can do to make it suitable for Debian.

- debian/patches is not needed if there are no patches.
- debian/README.Debian also seems unnecessary, considering its current
content is just the package's synopsis.
- debian/copyright lists GPL-3 for *, but debian/* is actually
(presumably unintentionally) LGPL-3 according to the LICENSE file in
your new repo.

[1] https://lists.debian.org/debian-devel-announce/2020/04/msg9.html
[2] 
https://salsa.debian.org/salsa-ci-team/pipeline#debian-pipeline-for-developers

Regards,
Robin

Re: A question about uscan and MUT with different versions

[Robin Gustafsson]

Hi Leopold,

> However, when I push it to salsa and run ci, the command executed is this:
>
> uscan --download --download-current-version
>
> and fails because the "data" modules has different version number that
> the original main or this is what I understand [2].
>
> Some of you knows how to manage this situation or complete the watch
> file to make it works?

I think the real problem is on line 123:
> gbp:error: upstream/1.6.0+ds1 is not a valid treeish

You've probably forgotten to push that tag.

With that tag present, gbp can recreate the .orig.tar files using
pristine-tar and then origtargz won't try to use uscan at all.

FWIW, the --download-current-version option does indeed not work for
MUT packages with different version numbers; the package only has one
current version.

Regards,
Robin

Re: A question about uscan and MUT with different versions

[Robin Gustafsson]

Hi Leopold,

> salsa ci build the package but other test fails and I don't know if it's
> a package issue or salsa ci.

Unfortunately, I don't know the cause of those failures. Considering
how early the jobs failed I'd guess your package wasn't even involved
yet, though.

> > FWIW, the --download-current-version option does indeed not work for
> > MUT packages with different version numbers; the package only has one
> > current version.
>
> but this option is configured in salsa, right?

The CI job runs origtargz from devscripts [1]. It tries several things
to find/reproduce the .orig.tar. That uscan command is the last thing
it tries [2].

[1] https://salsa.debian.org/science-team/soqt/-/jobs/685582#L205
[2] 
https://salsa.debian.org/debian/devscripts/-/blob/master/scripts/origtargz.pl#L304

Regards,
Robin

Re: RFS: stateserial -- Displays serial port modem status lines

[Robin Gustafsson]

Hi Aristo Chen,

I recommend you follow the sponsorship process outlined here [1]. That
would make it easier for potential sponsors to find your package.

[1] https://mentors.debian.net/sponsor/rfs-howto

Regards,
Robin

Re: Debian package postupgrade script

[Robin Gustafsson]

Hi Tong Sun,

> I've made some breaking changes to my package,
> https://github.com/suntong/dbab/commit/3ab123e5a90f2b37021a8a1b27dc6eaf2a9b87d6#diff-087e6c3b5855f52a443f266d08a555d1R77-R78
> and would like to remove the old configure files in postupgrade step.

Judging from the commit message, it seems they should possibly be
moved rather than removed.

> Would you be so kind as show me how it could be done please? Thanks!

Have a look at dpkg-maintscript-helper. It can do either and its
man-page contains instructions for both.

Regards,
Robin

Re: Packaging pyca

[Robin Gustafsson]

Hi Sven,

I'm a new contributor myself and cannot sponsor the package nor answer
all of your questions, but I can offer some suggestions.

> Currently there is a Lintian error, due to the fact, that PyCA
> itself ships an own version of jquery

This would not be allowed in Debian. Firstly, the jQuery file is
minified and would thus be considered to be missing sources (policy
4.16 [1]) which is against the DFSG. Secondly, embedded code copies
are normally not permitted (policy 4.13 [2]). Luckily, jQuery is
already packaged (libjs-jquery [3]), so you would just have to remove
the embedded copy of jQuery and replace it with a dependency on that
package (coupled with the appropriate patches to actually load the
packaged version instead, I assume).


On a side note, the versions seem to be out of date for a package
targeting unstable:
- The current Standards-Version is 4.5.0.
- The current debhelper-compat version is 13.
Have you tried building it in Debian unstable and checked it with Lintian there?

Also, consider using ...
- a debian/clean file instead of rm in override_dh_clean in debian/rules.
- e.g. "Build-Depends: debhelper-compat (= 13)" in debian/control
instead of the debian/compat file.
- "Build-Depends: dh-sequence-python3" in debian/control instead of
"--with python3" in debian/rules.
- substitution variables (@PACKAGE@, etc.) in debian/watch (details in
uscan's man page [4])


[1] 
https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources
[2] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
[3] https://packages.debian.org/sid/libjs-jquery
[4] 
https://manpages.debian.org/unstable/devscripts/uscan.1.en.html#FORMAT_OF_THE_WATCH_FILE

Re: Packaging pyca

[Robin Gustafsson]

> I created the current package with the tools installed under Buster
> using dh_make and the Lintian on Buster seems to be happy, except to the
> jquery stuff of course. Maybe this leads to the outdated versions.

It does indeed.

> Currently I provide this for people installing PyCA on their current
> version of Debian, so this package is mostly for Buster.
>
> I will try to build directly on unstable again and check the result, if
> I find a mentor for this and probably have then to maintain packaging
> for the two different versions in parallel, or is there a better way to
> do this?

It'd be fine to stay on a lower debhelper compat level and avoid newer
features that would make it fail to build from source on buster. In
that case, debhelper 12 is likely as far as you would want to go.
Except for using 12 instead of 13, I think my other suggestions would
still be compatible with buster.

I think it'd make sense to treat the buster version as a backport,
even if it's published in a non-Debian apt repo. Especially keeping
the diff to a minimum and using a backport version number (e.g.
2.2-2~bpo10+1) for the buster build to ensure that it upgrades cleanly
in the future.

On an unrelated note: maybe dh_installsystemd could be useful to you.


Regards,
Robin

Bug#961428: RFS: python-discord/1.3.3+dfsg-1 [ITP] -- API wrapper for Discord written in Python

[Robin Gustafsson]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-discord"

 * Package name: python-discord
   Version : 1.3.3+dfsg-1
   Upstream Author : Rapptz
 * URL : https://github.com/Rapptz/discord.py
 * License : Expat
 * Vcs : https://salsa.debian.org/rgson/python-discord
   Section : python

It builds those binary packages:

  python3-discord - API wrapper for Discord written in Python

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/python-discord

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-discord/python-discord_1.3.3+dfsg-1.dsc

Changes since the last upload:

   * Initial release (Closes: #961427)

Regards,

--
  Robin Gustafsson

Re: Maintaining a package across several debian codenames

[Robin Gustafsson]

On Mon, Apr 10, 2023 at 11:30 AM Robin ALEXANDER
 wrote:
>
> Hi,
>
> Let's assume I wish to maintain package_A across unstable and bullseye-
> backports. I understand from
> https://dep-team.pages.debian.net/deps/dep14/ that:
>
> 1. I need to create 3 branches in my git repository:
> - upstream/latest
> - debian/latest
> - debian/bullseye-backports
>
> 2. Since I am using git-buildpackage, I presume I would generate 3 tags
> when creating a new package version (ex: v3.0.0)
> - upstream/3.0.0 (when running gbp import-orig)
> - debian/3.0.0-1 (when running gbp buildpackage inside branch
> debian/latest)
> - ??? (when running gbp buildpackage inside branch debian/bullseye-
> backports)
>
> If the above is correct, what should be the name of the last tag (the
> one issued by gbp buildpackage inside branch debian/bullseye-backports
> ?
>
> Thank you for your help.
>
> Robin Alexander

The debian version tag "debian/3.0.0-1" matches the package's version number.

You can find the conventions for backport version numbers documented
in section 5.6.12.2 of the policy. [1]

If your backport version is "3.0.0-1~bpo11+1" then the tag should be
"debian/3.0.0-1_bpo11+1" (as ~ is disallowed in git tags).

As mentioned, `gbp tag` will do it for you though.

[1] 
https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

Re: Questions about ITP in Debian

[Robin Gustafsson]

Hi,

On Mon, May 29, 2023 at 5:36 PM Tadeu Sampaio  wrote:
>
> Hi, thx for your attention! Please, can you clarify this for me? For an ITP 
> to be submitted, it is necessary that the person applies to become a member 
> (Debian New Maintainers)? I am asking regarding this ITP: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024547
>
> Thx,
> Tadeu

No. Anyone can submit an ITP.

You'd need to find a sponsor to actually get a package into Debian
though. That's generally how you'd get started with packaging. See
https://mentors.debian.net/intro-maintainers/.

Regards,
Robin

Re: Questions about ITP in Debian

[Robin Gustafsson]

On Mon, May 29, 2023 at 6:24 PM Tadeu Sampaio  wrote:
>
> Thx Robin for the fast response! So what is needed in order to proceed with 
> the ITP below, we need a sponsor?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024547
>
> Best regards,
> Tadeu

The (currently) last message [1] on that ITP already mentioned what
needs to be done and provided useful links to get started.

In short, to proceed you'd need to:
1. Coordinate with the current owner of that ITP (unless that's you).
2. Prepare a source package that conforms to Debian policy and can
build the binary packages (.deb files) using the standard Debian build
tools. (Note that upstream's .deb files are not sufficient.)
3. Find a sponsor willing to review and upload the source package for
you. For example through mentors.debian.net and this mailing list.

Documentation on what this means in practice is found in the links
already provided in the ITP. [1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024547#25

Regards,
Robin

Re: Looking to find a sponsor

[Robin Gustafsson]

Hi Jordan,

(I'm CC:ing you this time in case you're not subscribed to the list.)


[...]
The package is a Python app called CraftServerSetup that allows the user 
to  create and manage game servers for the popular video game Minecraft. 


CraftServerSetup seems to be non-free software. If so, it cannot be 
included in Debian. See the Debian Free Software Guidelines [1].


As a result of the app's choice in programming language, it does not 
need any building or compiling at all (so I have it as a binary deb file 
right from the start).


You must have a source package for inclusion in Debian [2], regardless 
of the app's build system.


If you're packaging a Python app, I suggest you learn from existing 
Python packages in the Python packaging team [3].


On the "New Packager's Guide" page I saw something about requesting 
sponsors with a certain skillset..?


For that, I don't care very much. Just someone who is willing to upload 
the deb files to apt.
It's indeed just a suggestion. You may have more luck finding a sponsor 
who's familiar with Python packaging, as the sponsor has to review your 
package and feel comfortable uploading it.



[1] https://wiki.debian.org/DebianFreeSoftwareGuidelines
[2] https://wiki.debian.org/Packaging/Intro#What_is_a_.22package.22.3F
[3] https://wiki.debian.org/Teams/PythonTeam

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057332: sponsorship-requests: Bottom/0.9.6 -- A customizable cross-platform graphical process/system monitor for the terminal

[Robin Gustafsson]

Hi Douglas,

On 12/3/23 16:29, Douglas Baggett wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: doug.bagg...@gmail.com

This package `bottom` is **REALLY NICE**.

https://github.com/ClementTsang/bottom

The author has packages for debian already made from nightlys. It should
be easy to include them.

thanks!


Sounds like you may want a "Request for Package" (RFP) [1] instead.

The upstream's .deb files are not sufficient for inclusion in Debian. A 
Debian source package [2,3] is needed.


[1] https://wiki.debian.org/RFP
[2] https://www.debian.org/doc/debian-policy/ch-source.html
[3] https://wiki.debian.org/Packaging/SourcePackage

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for moving Salsa repository to debian group

[Robin Gustafsson]

Hi Soren,

On 1/11/24 23:59, Soren Stoutner wrote:
I am working on a QA upload for the hunspell-uz package, which has not 
previously used a VCS for the Debian packaging.  I created a repository at:



https://salsa.debian.org/soren/uzbek-wordlist 




Would someone be able to move it to the the debian group and give me 
write permissions in the new location? 


I can move it for you if you add me to your repository as an Owner. My 
Salsa username is "rgson" [1].


[1] https://salsa.debian.org/rgson

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Salsa repository requested

[Robin Gustafsson]

On 1/14/24 21:09, Bruno Naibert wrote:

I am a maintainer of the html2text package
https://tracker.debian.org/pkg/html2text
and I would like to have access as a maintainer in the Salsa
repository https://salsa.debian.org/debian/html2text/.

Could you adjust my access permissions?


Done.

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Request for moving Salsa repository to debian group

[Robin Gustafsson]

On 1/15/24 18:00, Soren Stoutner wrote:

Done.

On Saturday, January 13, 2024 3:54:46 PM MST Robin Gustafsson wrote:

I am working on a QA upload for the hunspell-uz package, which has not
previously used a VCS for the Debian packaging.  I created a repository

at:



https://salsa.debian.org/soren/uzbek-wordlist
<https://salsa.debian.org/soren/uzbek-wordlist>


Would someone be able to move it to the the debian group and give me
write permissions in the new location?



I can move it for you if you add me to your repository as an Owner. My
Salsa username is "rgson" [1].

[1] https://salsa.debian.org/rgson


Moved to https://salsa.debian.org/debian/uzbek-wordlist.

--
Regards,
Robin

GPG: B26C 2ED3 7324 6221 9C3D 1DFE 293A 3C91 D188 369C


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian

[Robin Gustafsson]

I recall another RFS [1] with the same problem (binary-only package
containing binaries produced with Lazarus). Perhaps something from
that thread could help you.

[1]: http://bugs.debian.org/964087

Regards,
Robin

Build fails on i386 due to overflows in tests

[Robin Gustafsson]

Dear mentors,

A package I'm maintaining fails to build on i386 [1]. Specifically,
the build-time tests are failing. I believe numerical overflows to be
the cause. I'm unsure about the best course of action.

The built package is architecture-independent (interpreted code).
However, the packaged library deals specifically with dates, time
ranges, etc. Some functionality relies on arithmetics on a
microsecond-level; a 32-bit signed integer cannot hold more than about
36 minutes worth of those. Other functionality deals with dates,
possibly on the wrong side of the Epochalypse. Both of these scenarios
are demonstrated in the failing tests.

What are my options in such a situation (from an "acceptable in
Debian" point of view)? What would be the preferred course of action?

[1]: https://salsa.debian.org/php-team/pear/php-nesbot-carbon/-/jobs/1020055

Thanks,

Robin

Bug#972402: RFS: libphp-swiftmailer/6.2.3-1 [ITA] -- Swiftmailer, free feature-rich PHP mailer

[Robin Gustafsson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libphp-swiftmailer":

 * Package name: libphp-swiftmailer
   Version : 6.2.3-1
   Upstream Author :
 * URL : http://swiftmailer.org/
 * License : Expat
 * Vcs : https://salsa.debian.org/php-team/pear/php-swiftmailer
   Section : php

It builds those binary packages:

  php-swiftmailer - Swiftmailer, free feature-rich PHP mailer

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libphp-swiftmailer/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libp/libphp-swiftmailer/libphp-swiftmailer_6.2.3-1.dsc

Changes since the last upload:

 libphp-swiftmailer (6.2.3-1) unstable; urgency=medium
 .
   [ Nicolas Roudaire ]
   * Imported upstream version 6.2.3 (Closes: #951591)
   * Upgrade Standards-Version to 4.5.0
   * debian/control: Update debhelper-compat to 12
   * debian/compat: Remove because of debhelper-compat in debian/control
   * Update debian/copyright
   * Add debian/upstream/metadata
 .
   [ Robin Gustafsson ]
   * Add pkg-php-tools dependency overrides
   * Change name of license from MIT to Expat
   * Remove unnecessary debian/dirs
   * Install docs instead of tests as documentation
   * Reformat files
   * Update maintainer info due to team adoption
   * Remove transitional package (Closes: #878656)
   * Clean up dependencies
   * Fix VCS URLs
   * Install an autoload.php file (Closes: #951605)
   * Bump debhelper-compat to 13
   * Tweak gbp.conf
   * Run tests during build
   * Add autopkgtest tests

--

Adoption into the PHP PEAR team was discussed with the current
maintainer on the team's mailing list [1].

Please feel free to review and/or sponsor this even if you're not
active within the team. All help is appreciated.


[1]: 
https://alioth-lists.debian.net/pipermail/pkg-php-pear/2020-September/014730.html


Regards,
--
  Robin Gustafsson

Finding files for d/clean when using sbuild

[Robin Gustafsson]

Hi mentors,

More than once now, I've made the mistake of missing certain files
that ought to be added to debian/clean. I typically use sbuild when
building packages, so these extra files get thrown out after the build
anyways, so they're not obvious to me.

What's the recommended way to find such left-over files after an sbuild build?

I imagine a diff between the original source tree and whatever's left
after a build and a subsequent clean could accomplish it. The external
command functionality in sbuild could perhaps be used for this. I
thought I'd ask for existing solutions before I put something together
for myself, though.

Regards,
Robin

Re: Finding files for d/clean when using sbuild

[Robin Gustafsson]

Thank you, Baptiste and Paul!

Glad to know I'm not the only one in need of this.


Baptiste Beauplat  wrote:
> [...]
> I tried to give it a more serious thought and I came up with the
> alternative of using the commands hooks as recommended in #424846[1].
>
> I came up with the following:
> [...]

Great! This is exactly what I'm after. I've configured it and tried it
out, and it works perfectly for me so far. I'll be using this from now
on. Thank you!


Paul Wise  wrote:
> You could hack something up by running git init+add+commit+status+diff
> at the appropriate times in debian/rules. You would need to remove
> that debugging before uploading the source package though.

Nice idea. I'm not too fond of having to temporarily edit debian/rules
though, but it'd be good enough in a pinch.


Regards,
Robin

Bug severity for blocking a transition

[Robin Gustafsson]

Hi mentors,

Is blocking a transition always RC?
Or how would I deduce the appropriate bug severity?

I'm particularly interested due to the relation between bug severity
and the policy for NMUs.

Regards,
Robin

Bug#977898: RFS: movim/0.17.1-1.1 [NMU] [RC] -- decentralised social network fully based on XMPP

[Robin Gustafsson]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: pkg-xmpp-de...@lists.alioth.debian.org, 
pkg-php-p...@alioth-lists.debian.net

Dear mentors,

I am looking for a sponsor for my NMU of the package "movim":

 * Package name: movim
   Version : 0.17.1-1.1
   Upstream Author : Timothée Jaussoin 
 * URL : https://movim.eu/
 * License : AGPL-3, Apache-2.0
 * Vcs : https://salsa.debian.org/xmpp-team/movim
   Section : php

It builds those binary packages:

  movim - decentralised social network fully based on XMPP

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/movim/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/m/movim/movim_0.17.1-1.1.dsc

Changes since the last upload:

 movim (0.17.1-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Use php-illuminate-database 6 (Closes: #976886)

Regards,
--
  Robin Gustafsson

Re: Question about lintian bad-whatis-entry warning

[Robin Gustafsson]

Hi Aaron,

> How can I get more insight into the problem?

Lintian's explanation for bad-whatis-entry [1] mentions that it's
"lexgrog" that fails to parse your header. (Looking at Lintian source
[2], it's indeed just running lexgrog on your file and checking the
exit code.)

The lexgrog man page contains more info about how specifically the
NAME section is parsed and some requirements for it to work. Perhaps
that could help. The part about "\-" might be of particular interest.
It also mentions a "--debug" option that could perhaps provide you
with some leads if you try running lexgrog on your file manually.

[1] https://lintian.debian.org/tags/bad-whatis-entry.html
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/c9601fc5/lib/Lintian/Check/Documentation/Manual.pm#L241

Re: Package ghostwriter E source-is-missing

[Robin Gustafsson]

Hi seb,

On Sat, Jan 23, 2021 at 6:54 PM  wrote:
>
> I'm not sure how to resolve the error indicated by Lintian on the
> Ghostwriter package (https://mentors.debian.net/package/ghostwriter/).
>
> > ghostwriter source
> >
> > E source-is-missing
> > debian / missing-sources / 3rdparty / MathJax / bin / a11y /
> > assistive-mml.js line length is 6982 characters (> 512)
> [...]
>
> But I have included what was needed in debian / missing-sources ".

You seem to have included minified Javascript code, not the original
code in the preferred form for making modifications. These files are
already the output of a build process. They are of little value to
someone who would like to modify the source code.

> So what should I do?

Include the source code in its original form.

However, the "3rdparty" directory makes me think that these files are
actually dependencies that should be packaged separately. For example,
the MathJax code is perhaps what's already in the package
libjs-mathjax (judging from the name alone), in which case you should
depend on and use that instead.

Regards,
Robin

Does 32-bit arithmetic overflow mean arch incompatibility?

[Robin Gustafsson]

Hi mentors,

Does the possibility of arithmetic overflow on 32-bit systems mean
that the software is to be considered incompatible with 32-bit
architectures?

A package I'm working on has some test failures on 32-bit due to
overflows. I only maintain architecture-independent packages and I'm
not sure how this scenario would usually be treated.

Regards,
Robin

Bug#981987: RFS: cbonsai/0.0~git20210115.e107005-1 [ITP] -- terminal-based bonsai tree generator

[Robin Gustafsson]

Package: sponsorship-requests
Severity: wishlist
Control: block 981965 by -1

Dear mentors,

I am looking for a sponsor for my package "cbonsai":

 * Package name: cbonsai
   Version : 0.0~git20210115.e107005-1
   Upstream Author : John Allbritten
 * URL : https://gitlab.com/jallbrit/cbonsai
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/rgson/cbonsai
   Section : games

It builds those binary packages:

  cbonsai - terminal-based bonsai tree generator

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/cbonsai/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cbonsai/cbonsai_0.0~git20210115.e107005-1.dsc

Changes for the initial release:

 cbonsai (0.0~git20210115.e107005-1) unstable; urgency=medium
 .
   * Initial release (Closes: #981965)

Regards,
--
  Robin Gustafsson

Bug#983146: sponsorship-requests: Backup next generation (bung)

[Robin Gustafsson]

Hi Charles,

Where can I find the Debian source package? I found .deb files, but
not how they're generated.

Also, installing the files under /opt is disallowed for official packages.

Regards,
Robin

Bug#983146: sponsorship-requests: Backup next generation (bung)

[Robin Gustafsson]

Charles,

> I tried hard to make a source .deb but did not manage to do so.  Would
> you like me to share the system I use to create the .deb?

A source package is required for inclusion in Debian. The binary
packages are built automatically on Debian infrastructure and must use
certain build tools for that to work. So, to proceed, there needs to
be a compliant source package.

If you want to maintain this package in Debian yourself, see the
"Introduction for maintainers" [1] page. If you hope to find someone
else to maintain it in Debian, you should instead file a "Request for
package" (RFP) bug to add it to the list of requested packages [2].

[1] https://mentors.debian.net/intro-maintainers/
[2] https://www.debian.org/devel/wnpp/requested

Regards,
Robin

Re: avoiding autoremoval for what seems like a spurious build error

[Robin Gustafsson]

Hi Stephen,

On Thu, Apr 29, 2021 at 5:26 PM Stephen Sinclair  wrote:
>
> Hi Mentors,
>
> My package siconos currently has a bug filed [1] and has been marked
> for autoremoval from testing.
>
> The problem is that I cannot reproduce it.

Did you build the package in a clean environment? Against only
dependencies in testing?

Otherwise, I'd recommend sbuild.

I tried building it myself to confirm, but it failed due to lack of
disk space, so I can't currently.

> The failure is on a test
> that depends on another package, so I am wondering if there was just a
> glitch here?  I have replied to the bug report with working build
> logs, but there has been no further activity, so I am not sure what
> further action I can take to avoid that the package gets removed.
>
> Thanks for any help.
> Steve
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986515

Regards,
Robin

Re: avoiding autoremoval for what seems like a spurious build error

[Robin Gustafsson]

On Tue, May 4, 2021 at 7:48 PM Stephen Sinclair  wrote:
>
> In any case, I was not so much asking for help building/reproducing,
> as I was asking what I can do other than to reply to the bug, which
> seems not to be eliciting a response, to either avoid or delay the
> auto-removal process.  Is auto-removal policy documented somewhere?

For that you'd follow Tobias' suggestion:
> I'd either downgrade it to non RC and tag it unreproducible or close it with
> the request to reopen if it pops up again.

Practically, that means you'd either downgrade the bug's severity [1]
to "important" or below to make it non-RC [2], or close it [3].

The connection between RC bugs and auto-removal is documented here [4].

[1] https://www.debian.org/Bugs/server-control#severity
[2] https://www.debian.org/Bugs/Developer#severities
[3] https://www.debian.org/Bugs/Developer#closing
[4] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#removals-from-testing

Bug#990424: RFS: cbonsai/1.2.1-1 -- terminal-based bonsai tree generator

[Robin Gustafsson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cbonsai":

 * Package name: cbonsai
   Version : 1.2.1-1
   Upstream Author : https://gitlab.com/jallbrit/cbonsai/-/issues
 * URL : https://gitlab.com/jallbrit/cbonsai
 * License : GPL-3
 * Vcs : https://salsa.debian.org/rgson/cbonsai
   Section : games

It builds those binary packages:

  cbonsai - terminal-based bonsai tree generator

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/cbonsai/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cbonsai/cbonsai_1.2.1-1.dsc

Changes since the last upload:

 cbonsai (1.2.1-1) unstable; urgency=medium
 .
   [ Helmut Grohne ]
   * Fix FTCBFS (Closes: #984908)
 .
   [ Robin Gustafsson ]
   * Track upstream's versioned releases
   * New upstream version 1.2.1
   * Remove obsolete patches
   * Set upstream metadata fields: Bug-Database, Bug-Submit.
   * Avoid explicitly specifying -Wl,--as-needed linker flag.

Note that cbonsai is not in testing.

I'm also seeking DM upload rights for this package. Please consider
it, but feel free to sponsor regardless.

Regards,
-- 
  Robin Gustafsson

Re: libgrokj2k: version 9.2 uploaded

[Robin Gustafsson]

Hi Aaron,

> I've upgraded this package priority to high as it fixes a CVE
> present in previous version.
> It would be great if we can get this migrated.

> oops, never mind - I see Bullseye is in freeze.

You could ask the release team for an unblock [1]. Security fixes are
usually important and may qualify.

[1] https://release.debian.org/bullseye/freeze_policy.html

Regards,
Robin

Re: include additional git repo in package

[Robin Gustafsson]

Hi Peymaneh,

> the dist-repo has no releases or tags, so uscan would usually download HEAD.

Perhaps you could ask upstream for tags matching their releases? It
seems they're already updating version numbers within the "dist" repo
for every release anyway.

> A situation were one would want to package a specific commit is very 
> unlikely: the different repos are not builddeps of each other and could not 
> mismatch or "break" each other.

Surely they could mismatch. For example, "dist" contains shell
completion scripts. Those would need to be kept in sync with the
application's actual interface, which could presumably change between
versions.

Regards,
Robin

Re: How to revive an abandoned package? (Qtile)

[Robin Gustafsson]

Hi Damien,

On Sun, Nov 21, 2021 at 10:09 PM Damien Calloway
 wrote:
>
> Hello!
>
> I am an avid Pythonista and I was disappointed to learn that
>
> sudo apt install qtile
>
> No longer works. In my research, it appears that the qtile project relies on 
> packagers for each distribution - they do not do the packaging themselves.
>
> I see that the Debian package is abandoned for some time now, and I wanted to 
> know if:
>
> 1) Would I need to use the procedure for submitting a new package, since this 
> one has been stale for so long?

Yes. That and possibly a bit more, actually. There's a section about
it in the Debian Developer's Reference [1].

> 2) Would I need to build for all the architectures that Debian supports?

Yes.

To be perfectly clear though: you don't have to build the binary
package on all the architectures yourself; you have to make such
builds possible from your source package. Debian's build
infrastructure will build all the binary packages from that.

> 3) Also, wanted to confirm that I would just need to ensure a reproducible 
> build with valid metadata for aptitude, then package and submit the results?

You need a valid source package that conforms to Debian policy [2] and
that someone is willing to sponsor [3]. There's a Q&A with more useful
links on mentors.debian.net [4].


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#reintroducing-packages
[2] https://www.debian.org/doc/debian-policy/
[3] https://mentors.debian.net/sponsors/
[4] https://mentors.debian.net/qa/

Regards,
Robin

Re: Packaging help: users and directories

[Robin Gustafsson]

Hi Gavin,

On Wed, Dec 29, 2021 at 12:35 PM Gavin Henry  wrote:
> [...]
> Is it best practice to have:
>
> 1. debian folder in your main repo
> 2. debian folder branch in main repo
> 3. Separate repo for this

A separate repo hosted on salsa.debian.org.

On Wed, Dec 29, 2021 at 12:37 PM Gavin Henry  wrote:
>
> What's this for, when it looks like this was written manually? Google
> shows nothing:
>
> https://salsa.debian.org/dns-team/bind9/-/blob/debian/main/debian/bind9.postinst#L35
>
> #DEBHELPER#

The debhelper man page explains it. [1]

[1] 
https://manpages.debian.org/unstable/debhelper/debhelper.7.en.html#Automatic_generation_of_Debian_install_scripts

Re: Packaging help: users and directories

[Robin Gustafsson]

On Wed, Dec 29, 2021 at 2:03 PM Gavin Henry  wrote:
>>
>> > Is it best practice to have:
>> >
>> > 1. debian folder in your main repo
>> > 2. debian folder branch in main repo
>> > 3. Separate repo for this
>>
>> A separate repo hosted on salsa.debian.org.
>
> Thanks. That's for an official package, or?

Yes, that's assuming you're pursuing inclusion in Debian. Otherwise
alternative 2, a separate branch in your existing repository.

Re: debian folder and version control system repository

[Robin Gustafsson]

On Wed, Dec 29, 2021 at 2:00 PM Geert Stappers  wrote:
> In-Reply-To: 
> 
> Subject: Re: Packaging help: users and directories
>
> On Wed, Dec 29, 2021 at 01:03:52PM +0100, Robin Gustafsson wrote:
> > On Wed, Dec 29, 2021 at 12:35 PM Gavin Henry wrote:
> > > [...]
> > > Is it best practice to have:
> > >
> > > 1. debian folder in your main repo
> > > 2. debian folder branch in main repo
> > > 3. Separate repo for this
> >
> > A separate repo hosted on salsa.debian.org.
>
> ?
>
> as "Why pointing to salsa?"
>
>
> Options  2. and 3. are both OK.  Document the location with `Vcs-Browser:`
> and `Vcs-...:` in debian/control.
> [...]

Absolutely, both are OK. My impression is that Salsa is best practice,
but not the only good practice. I'm sure different situations warrant
different decisions.

To expand on that, I think Salsa is a fine choice in general, and
especially for new maintainers to collaborate with sponsors and to get
help from tools like the Salsa CI pipeline.

Regards,
Robin

Re: RFS: python-decouple/3.6-3 -- Helps you to organize your Django/Flask settings

[Robin Gustafsson]

> Question (cc'ing d-m): it took me several iterations uploading to
> mentors (and fixing the feedback items, etc).  Since dcut does not
> operate on the mentors repository, how can I replace an upload with the
> same revision number?  (Hope that makes sense..)
>
> Thanks!
> Matt

You can upload the same version multiple times to mentors. You can
also remove previously uploaded versions on the website.

Regards,
Robin

Bug#1023775: RFS: php-laravel-framework/8.83.26+dfsg-1 [RC] -- web application framework for PHP

[Robin Gustafsson]

Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: Debian PHP PEAR Maintainers 

Dear mentors,

I am looking for a sponsor for my package "php-laravel-framework":

 * Package name : php-laravel-framework
   Version  : 8.83.26+dfsg-1
   Upstream contact : Taylor Otwell 
 * URL  : https://laravel.com/
 * License  : Expat, BSD-3-clause
 * Vcs  :
https://salsa.debian.org/php-team/pear/php-laravel-framework
   Section  : php

The source builds the following binary packages:

  php-laravel-framework - web application framework for PHP
  php-illuminate-auth - Illuminate Auth library component for PHP
  php-illuminate-broadcasting - Illuminate Broadcasting library
component for PHP
  php-illuminate-bus - Illuminate Bus library component for PHP
  php-illuminate-cache - Illuminate Cache library component for PHP
  php-illuminate-collections - illuminate Collections library component for PHP
  php-illuminate-config - Illuminate Config library component for PHP
  php-illuminate-console - Illuminate Console library component for PHP
  php-illuminate-container - Illuminate Container library component for PHP
  php-illuminate-contracts - Illuminate Contracts library component for PHP
  php-illuminate-cookie - Illuminate Cookie library component for PHP
  php-illuminate-database - Illuminate Database library component for PHP
  php-illuminate-encryption - Illuminate Encryption library component for PHP
  php-illuminate-events - Illuminate Events library component for PHP
  php-illuminate-filesystem - Illuminate Filesystem library component for PHP
  php-illuminate-hashing - Illuminate Hashing library component for PHP
  php-illuminate-http - Illuminate HTTP library component for PHP
  php-illuminate-log - Illuminate Log library component for PHP
  php-illuminate-macroable - Illuminate Macroable component for PHP
  php-illuminate-mail - Illuminate Mail library component for PHP
  php-illuminate-notifications - Illuminate Notifications library
component for PHP
  php-illuminate-pagination - Illuminate Pagination library component for PHP
  php-illuminate-pipeline - Illuminate Pipeline library component for PHP
  php-illuminate-queue - Illuminate Queue library component for PHP
  php-illuminate-redis - Illuminate Redis library component for PHP
  php-illuminate-routing - Illuminate Routing library component for PHP
  php-illuminate-session - Illuminate Session library component for PHP
  php-illuminate-support - Illuminate Support library component for PHP
  php-illuminate-testing - Illuminate Testing library component for PHP
  php-illuminate-translation - Illuminate Translation library component for PHP
  php-illuminate-validation - Illuminate Validation library component for PHP
  php-illuminate-view - Illuminate View library component for PHP

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/php-laravel-framework/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/php-laravel-framework/php-laravel-framework_8.83.26+dfsg-1.dsc

Changes since the last upload:

 php-laravel-framework (8.83.26+dfsg-1) unstable; urgency=medium
 .
   [ Robin Gustafsson ]
   * New upstream version 8.83.26+dfsg
 - Fix compatibility with Symfony 5 (Closes: #1000560)
   * Fix capitalization error in description
   * Update standards version to 4.6.1, no changes needed.
   * Patch egulias/email-validator v3 compatibility
   * Patch voku/portable-ascii v2 compatibility
   * Avoid extra composer.json files at build
   * Use phpabtpl to generate autoloaders
   * Install an autoloader override for phpabtpl
   * Add superficial tests to load the library code
 .
   [ Katharina Drexel ]
   * Adding more laravel components in control file.
 - New packages: php-illuminate-collections, php-illuminate-macroable,
   php-illuminate-testing
   * Completing missing packages in autoload.tpl.
   * Removing obsolete patches.
   * Correcting lintian-overrides statement.
   * Cosmetics in control file.

---
I'm looking for a sponsor to upload this to the NEW queue due to the
added binary packages. I can handle a subsequent source-only upload (I
have DM upload rights).

Regards,
Robin

Bug#1024452: RFS: cbonsai/1.3.1-1 -- terminal-based bonsai tree generator

[Robin Gustafsson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cbonsai":

 * Package name : cbonsai
   Version  : 1.3.1-1
   Upstream contact : https://gitlab.com/jallbrit/cbonsai/-/issues
 * URL  : https://gitlab.com/jallbrit/cbonsai
 * License  : GPL-3
 * Vcs  : https://salsa.debian.org/rgson/cbonsai
   Section  : games

The source builds the following binary packages:

  cbonsai - terminal-based bonsai tree generator

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/cbonsai/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cbonsai/cbonsai_1.3.1-1.dsc

Changes since the last upload:

 cbonsai (1.3.1-1) unstable; urgency=medium
 .
   [ Matthias Geiger ]
   * New upstream version 1.3.1
   * Added myself to Uploaders
   * Imported upstream patch for manpage section
   * Switched to scdoc in d/control for generating the manpage
   * Updated year in d/copyright
 .
   [ Debian Janitor ]
   * Set upstream metadata fields
   * Update standards version to 4.6.1, no changes needed.
 .
   [ Robin Gustafsson ]
   * Restore debian/manpages
   * Remove rebuild in cross-arch builds
   * Build manpage with upstream's Makefile
   * Wrap-and-sort control files

Regards,
Robin