[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1010004: RFS: odr-dabmod/2.6.0-1 [ITP] -- DAB modulator compliant to ETSI EN 300 401



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.

-- 
Robin ALEXANDER

Le mercredi 27 avril 2022 à 14:41 +0200, Bastian Germann a écrit :
> Am 27.04.22 um 14:13 schrieb Robin ALEXANDER:
> > 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?
> 
> You caompiled the package on a x86_64 PC, so that behaviour and your
> use of debuild is okay.
> 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.

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


Reply to: