Dear mentors,

I am looking for a sponsor for my package "odr-dabmod":

 * Package name    : odr-dabmod
   Version         : 2.6.0-1
   Upstream Author : Matthias P. Braendli <matthias@mpb.li>
 * URL             : https://www.opendigitalradio.org/mmbtools
 * License         : FSFAP, GPL-2+ with Autoconf-data exception, GPL-
3.0+ with autoconf exception, GPL-3.0+, Apache-2.0, BSD-3-Clause,
EXPAT, LGPL-3, GPL-2.0+, Expat
 * Vcs             : https://salsa.debian.org/ralex/odr-dabmod
   Section         : hamradio

The source builds the following binary packages:

  odr-dabmod - DAB modulator compliant to ETSI EN 300 401

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

  https://mentors.debian.net/package/odr-dabmod/

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

  dget -x
https://mentors.debian.net/debian/pool/main/o/odr-dabmod/odr-dabmod_2.6.0-1.dsc

Changes for the initial release:

 odr-dabmod (2.6.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #1007104

Regards,

Control: tags -1 moreinfo

Please fix the lintian error (JS minified, source missing) by having the unminified source in debian/missing-sources.
When you have uploaded a new revision (not changing the changelog), untag moreinfo.

Hi Bastian,

thank you very much. I followed your instructions and uploaded again
both odr-dabmod (Bug#1010004) and odr-dabmux (Bug#1009867). I also
removed the tag "moreinfo" on both bugs (hoping I did it right).

I now have 1 question. When I built these packages, debuild generated
the xxx_amd64.changes files. Why do I have "amd64" in the filename (I
understand it relates to the X86_64 architecture)?
For your information, the source is mainly C++ based and it compiles
properly under arm64 and arm/v7 as well. Should I have ran debuild in a
different manner or is it going to be taken care of by the debian
packaging process later on?

Kind regards.

Am 27.04.22 um 14:13 schrieb Robin ALEXANDER:
When you set "Architecture: any" on a binary package, the buildd network will try to compile the package on every
Debian-supported architecture and kernel, which includes armel, armhf, and arm64.

Hi Bastian,

Thank you for your answer: it is crystal clear!

As I wrote to you, I:
  1. Uploaded on Wednesday (April 27) the corrected versions of odr-
dabmux (https://mentors.debian.net/package/odr-dabmux/) and odr-dabmod
(https://mentors.debian.net/package/odr-dabmod/)

  2. Removed the moreinfo tag on odr-dabmux
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009867) and odr-
dabmod (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010004)

Assuming I did everything correctly, is there anything else I must do
to have these 2 packages pushed to the NEW queue (like what was done
with odr-padenc)? Or is it the sponsor/you who pushes the packages to
the NEW queue by closing the above 2 bugs (1009867 and  1010004) ?

Kind regards.

Am 29.04.22 um 11:07 schrieb Robin ALEXANDER:

You just have to wait until someone will review the packages.
My comments were just to help getting the packages to a state where a DD would have a look at it.

Hi Bastian,

I just realized that I need to make a slight change to file
debian/rules by calling dh_auto_configure with an additional argument
in order to avoid compiling odr-dabmod with the option "-march=native".

Since the odr-dabmod package was not moved to the NEW queue yet, can I
just reload the package with the updated debian/rules file or do I also
need to modify file debian/changelog indicating the change on
debian/rules? In the latter case, do I need to change the package
version (ie. moving to 2.6.0-2 from 2.6.0-1)?

Have a nice week.

Am 02.05.22 um 08:27 schrieb Robin ALEXANDER:

Reupload without changing the changelog.