Bug#882642: RFS: quickcal/1.0 ITP

[Nathan SR]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "quickcal"

 * Package name: quickcal
   Version : 1.0
   Upstream Author :
 * URL : https://sourceforge.net/projects/quickcal/
 * License : GPL
   Section : utils

  It builds those binary packages:

quickcal   - It is a fast and easy to use calculator.

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/q/quickcal/quickcal_1.0.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

Closes ITP https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882566


  Regards,
   Nathan SR

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

On Fri, Nov 24, 2017 at 10:05:29PM +0100, Vincent Bernat wrote:
>  ❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni 
>  :
> For 8 packages, you can file the bug directly. As for severity, people
> may not agree with the interpretation of the policy: CC0 is equivalent
> to public domain and the license text is very verbose. It would be
> easier to push the change without a "threatening" severity.

Thanks a bunch for the explanation and upload  :)


signature.asc
Description: PGP signature

Re: How to find Multi-Arch path(s)

[Guillem Jover]

Hi!

On Fri, 2017-11-24 at 13:59:40 +0100, Ole Streicher wrote:
> Guillem Jover  writes:
> > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> >> So, how can I canonically (ideally from C) retrieve a sorted list of
> >> supported multi arch paths at runtime? Or is there another good way to
> >> solve this? I would think it is a standard use case for multi arch,
> >> isn't it?
> >
> > In general if you have to modify an upstream codebase to make it
> > package-manager aware (be that dpkg, rpm or whatever), that to me seems
> > like a big red sign too. In this case I think the problem is indeed that
> > the original question is flawed, so there's no good answer. :)
> 
> IRAF is a quite old program (>>30 years), with some unconventional
> solutions. And it is in "maintenance mode" yet.
> 
> The Multi-Arch solution upstream took is to put the binaries into
> directories
> 
> /iraf/iraf/bin.linuxfor 32 bit Linux (x86)
> /iraf/iraf/bin.linux64  for 64 bit Linux (x86)
> /iraf/iraf/bin.macosx   for 32 bit Mac OSX
> /iraf/iraf/bin.macintel for 32 bit Mac OSX
> 
> (similar subdirs bin. are under /iraf/iraf/unix, /iraf/iraf/noao etc.)

This is closer to the old multilib approach, which we are trying to
deprecate. I'd completely scrap and ignore this concept from upstream.

> and then have explicit if statements "if 64-bit linux also look in
> 32-bit dirs".  This is not applicable for Debian; first because of the
> FHS violation; but also because other archs are not really possible. The
> ARM architecture is however a working platform, with some use cases
> (people want to run it on their raspberry).

Exactly.

> Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because
> it is arch independent), except the bin.* dirs, which in a Debian
> Multiarch environment should go into /usr/lib//iraf, right?

Nope, as I've mentioned on my previous mail, I'd make the executables
also arch-neutral on their pathnames.

The point is that the Multi-Arch concept in Debian is all about the
interfaces. How packages and files interface with each other, and
what is possible and allowed. Some examples:

  * A script might be arch-independent in the contents sense; i.e., it
is the same on all architectures. But its interface might be
arch-dependent, because itself uses processor or kernel specific
interfaces, and its output changes depending on the architecture.
These cannot be marked as Mutli-Arch foreign.
  * A compiled binary might be arch-dependent in the contents sense;
i.e., it is different on each architecture. But its interface might
be arch-independent, because it does not change independently on
where it is executed, or for what arch it was built for. These can
be marked as Multi-Arch foreign.
  * A shared library that is being linked by some other package with
executables, needs to match their architecture and needs to be
coinstallable with itself, otherwise you could not install
packages of different architectures linking againts that library.
Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64.
These are usually as Multi-Arch same.

There are other fancy scenarios, and there's the more complex
"allowed" value, but the examples below should cover our case here.

> > So, going back. AFAIUI the iraf project supports plugins/extensions in
> > the form of executables. 
> 
> Yes.
> 
> > And some might only be available in a single arch.
> 
> No. They are available under 32-bit archs. At least armhf and
> i386 (linux + kfreebsd). Maybe x32.

Well, ok, so arch-classes, all the same. :)

So, say, your native arch (the one dpkg was built for) is amd64,
and you have enabled i386 as a foreign arch. You then install the
main iraf package for amd64 (the default), and then want to use some
extension/plugin that is available only for 32-bit arches. apt for
example will just pull the i386 version, because it'd be marked as
Multi-Arch foreign and the dependencies would be fullfilled.

That of course means, that whoever is calling those extension should
not need to care what the arch is, because supposedly anything that
can be executed will do. And what to install is decided by the package
manager and/or the user. So that's why the executable pathnames should
be arch-neutral.

> > If that's the case, that looks like those extensions should be
> > placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
> > we allowed that!), and those package be marked "Multi-Arch: foreign",
> > then that's the package manager's problem to choose the most
> > appropriate architecture for those binaries (perhaps by using the
> > futurable executable attribute of an arch).
> 
> This does not work: I have no way to execute from these binaries the
> correct 64-bit binary, since it does not know its directory (the
> multiarch dir known at compile time is i386-linux-gnu, not
> x86_64-linux-gnu).

See above, you should not need to know what arch 

Bug#882568: marked as done (RFS: nq/0.2.1-1 [ITP])

[Debian Bug Tracking System]

Your message dated Fri, 24 Nov 2017 22:27:25 +
with message-id 
and subject line closing RFS: nq/0.2.1-1 [ITP]
has caused the Debian Bug report #882568,
regarding RFS: nq/0.2.1-1 [ITP]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
882568: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882568
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist
Control: block 882567 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear mentors,

I am looking for a sponsor for my package "nq"

 * Package name: nq
   Version : 0.2.1-1
   Upstream Author : Leah Neukirchen 
 * URL : https://github.com/chneukirchen/nq
 * License : CC0
   Section : utils

It builds those binary packages:

  nq- Lightweight queue system

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/n/nq/nq_0.2.1-1.dsc


Regards,
 Nicolas Braud-Santoni

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAloXeWcZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z41hHEACMlbQ7lpMz29Ye9Ue+JN94
CYns2tLK5gVYWaKVfWd1wyp7v182bulZv6y2+RgToRaDvy8XCZw1H9MAqK3fgT5P
Zbg6dJP64v6qbG0vl6vOl6nQeT6nBKVkgWplXcUrwPOG9sN+eo/O6S3tncnQAZtk
e1oy1WZz503VipIaHkYQf0m2lkyFxR8zzOtDngLTNCQ4JoxR3/ygy7WlqlQtNfdA
tskJM55dJvXhXW4nGce134511baG91ltTBQaVIANBZZtQSOAGrcmwNNySyOdgwjp
liXfEeTKFvCx88xF3vsBZxvqMx7mUZKtADAwMDHvjDwR2MvydvTFDHGQ41QpDK2Q
R9R607EFr57+5kUXwMW4/vJVN0gaIY/39qepUkurC0al3F5saufD8P2lMJ2J8Eu+
W/+ZoUPsgdxFyW+xhQLehPW+75+8zzeaKuddD5Tcs079nnVMw+E0Dj5MRg6ZEW8k
ZycxqqNkOiMS6OL1AFeKbGFx2bfP+kx56LLj4Rm9pzBXhq5X7DiuixfsUUNxmvCK
lcYnhWn69uKvIrphSfK9ejDD0+PE/YQIkT8wiaJTNaSLA/ECBWJ28UmYRcK9yu89
mXPCc/XRT0MNUptMCjnrvCy25tqJXdACaed2uyO/gHqzJZQyVIErVaNti7VdXmR4
TIoaRtJ8tyrq4p9EJcVPDQ==
=2pRn
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Package nq version 0.2.1-1 is in NEW now,
and the package at mentors is not newer (2017-11-24) than the package in NEW 
(2017-11-24),
so there is currently no package to sponsor.

https://ftp-master.debian.org/new/nq_0.2.1-1.html
https://mentors.debian.net/package/nq

Please remove the package from mentors or mark it "needs sponsor = no".
If for some reason you need to replace the package in NEW,
then you can upload an updated package to mentors
and feel free to reopen this RFS 882568 or open a new RFS.--- End Message ---

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Vincent Bernat]

 ❦ 24 novembre 2017 21:25 +0100, Nicolas Braud-Santoni 
 :

>> Any MBF should be discussed first on debian-devel@ first. For me,
>> this seems a small violation and it would be preferable to stick with
>> severity normal to not appear too agressive.
>
> Only 8 source packages are concerned (re: not shipping the CC0 text),
> so I didn't realise that constituted a MBF.
>
> Thanks for the advise on the severity, I was under the impression that all
> policy violations should be `serious` or greater.  How should I
> proceed?

For 8 packages, you can file the bug directly. As for severity, people
may not agree with the interpretation of the policy: CC0 is equivalent
to public domain and the license text is very verbose. It would be
easier to push the change without a "threatening" severity.

>> > Thanks a bunch for the review,
>> 
>> Looks good. Tell me what you want to do about the remaining lintian
>> warning.
>
> If that's fine by you, I would rather have it uploaded as-is.

So, it's uploaded.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

On Fri, Nov 24, 2017 at 08:21:39PM +0100, Vincent Bernat wrote:
>  ❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni 
>  :
> 
> > - include the whole CC0 license in debian/copyright
> >   (this is already uploaded to mentors.d.n);
> > - open a bug against base-files to ship the CC0 in 
> > /usr/share/common-licences
> > - open bugs against concerned packages, to refer to the licence's text
> >   as installed by base-files;  (what should the severity be? I guess 
> > serious,
> >   since it is a violation of Debian policy 12.5 [1])
> >
> > [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0
> > [1]: https://www.debian.org/doc/debian-policy/#copyright-information
> 
> Any MBF should be discussed first on debian-devel@ first. For me,
> this seems a small violation and it would be preferable to stick with
> severity normal to not appear too agressive.

Only 8 source packages are concerned (re: not shipping the CC0 text),
so I didn't realise that constituted a MBF.

Thanks for the advise on the severity, I was under the impression that all
policy violations should be `serious` or greater.  How should I proceed?


> >> You override the debian-watch-may-check-gpg-signature, but you also need
> >> to override orig-tarball-missing-upstream-signature. Since the tooling
> >> to check signatures the way you need it is not here, an alternative
> >> would be to not ship upstream GPG signature.
> >
> > That's something lintian picks up in the changes file, and there is 
> > currently
> > no way to override those, if I'm not mistaken:
> >
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400
> 
> Oh, yes, I remember now. On my own packages, I have removed the GPG
> signature because of this. I don't know what's the stance of the FTP
> masters on this particular problem, so I don't know if it's best to get
> rid of the warning or just leave it as is. In your case, I would just
> remove the key since it is not used.

I would rather keep it there, to make it obvious which signing (sub)key
I am trusting for upstream.  :)


> > Thanks a bunch for the review,
> 
> Looks good. Tell me what you want to do about the remaining lintian
> warning.

If that's fine by you, I would rather have it uploaded as-is.


Thanks,

  nicoo


signature.asc
Description: PGP signature

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Vincent Bernat]

 ❦ 24 novembre 2017 17:48 +0100, Nicolas Braud-Santoni 
 :

>> In d/copyright: you need to include the complete CC0 license.
>
> OK; I did so based on what other packages were doing, according to
> codesearch.d.n [0].  If that's an acceptable solution, I will
> - include the whole CC0 license in debian/copyright
>   (this is already uploaded to mentors.d.n);
> - open a bug against base-files to ship the CC0 in /usr/share/common-licences
> - open bugs against concerned packages, to refer to the licence's text
>   as installed by base-files;  (what should the severity be? I guess serious,
>   since it is a violation of Debian policy 12.5 [1])
>
> [0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0
> [1]: https://www.debian.org/doc/debian-policy/#copyright-information

Any MBF should be discussed first on debian-devel@ first. For me,
this seems a small violation and it would be preferable to stick with
severity normal to not appear too agressive.

>> You override the debian-watch-may-check-gpg-signature, but you also need
>> to override orig-tarball-missing-upstream-signature. Since the tooling
>> to check signatures the way you need it is not here, an alternative
>> would be to not ship upstream GPG signature.
>
> That's something lintian picks up in the changes file, and there is currently
> no way to override those, if I'm not mistaken:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575400

Oh, yes, I remember now. On my own packages, I have removed the GPG
signature because of this. I don't know what's the stance of the FTP
masters on this particular problem, so I don't know if it's best to get
rid of the warning or just leave it as is. In your case, I would just
remove the key since it is not used.

> Thanks a bunch for the review,

Looks good. Tell me what you want to do about the remaining lintian
warning.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.im/en/debian-package-sponsoring


signature.asc
Description: PGP signature

FEP Automotive injection Mold-- one of your mold suppliers' choice in the future

[Lily]

Hello Sir, 




I'm Lily from FEP Mold. How's it going today? Fine very well, i hope. 
if not, i also would like become your loyal listener. 



 


As the head of the mold market, Have you ever concerned your molds' 
price and quality? or want to find the better suppliers 
that can let you have absolute advantage in the mold market? 



 


From now on, why not try our company? we can help you solve the 
mold problem that bothers you, may be we can become the 
best partner, welcome to contact me at any time.
 
如果你不想再收到该产品的推荐邮件，请点击这里退订

Bug#882568: RFS: nq/0.2.1-1 [ITP]

[Nicolas Braud-Santoni]

On Fri, Nov 24, 2017 at 08:14:51AM +0100, Vincent Bernat wrote:
> 
> In d/changelog: you forgot to include the ITP bug number.

Thanks for the catch; it seems I had included the ITP number in git
(present on my laptop and alioth) but forgot to rebuild before dput...


> In d/copyright: you need to include the complete CC0 license.

OK; I did so based on what other packages were doing, according to
codesearch.d.n [0].  If that's an acceptable solution, I will
- include the whole CC0 license in debian/copyright
  (this is already uploaded to mentors.d.n);
- open a bug against base-files to ship the CC0 in /usr/share/common-licences
- open bugs against concerned packages, to refer to the licence's text
  as installed by base-files;  (what should the severity be? I guess serious,
  since it is a violation of Debian policy 12.5 [1])

[0]: https://codesearch.debian.net/search?q=path%3Adebian%2Fcopyright+CC0
[1]: https://www.debian.org/doc/debian-policy/#copyright-information


> You override the debian-watch-may-check-gpg-signature, but you also need
> to override orig-tarball-missing-upstream-signature. Since the tooling
> to check signatures the way you need it is not here, an alternative
> would be to not ship upstream GPG signature.

That's something lintian picks up in the changes file, and there is currently
no way to override those, if I'm not mistaken:

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


> Also, I don't care about the use of short commands like fq, nq, tq (they
> are currently free), but that's something others may feel is
> inappropriate. You could keep them as is and see if the upload is
> accepted by FTP masters.

Yeah, I thought it would be more confusing than anything to rename the binaries
(and I checked that the names were free using `command-not-found`).


Thanks a bunch for the review,

  nicoo


signature.asc
Description: PGP signature

Re: How to find Multi-Arch path(s)

[Ole Streicher]

Hi Guillem,

thanks for the quick answer.

Guillem Jover  writes:
> On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
>> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf
>
> It that was to be used, then it should be DEB_HOST_MULTIARCH, the
> _TARGET_ variants are for canadian cross-compilers. :) If this is not
> clear from the man page, I'm happy to clarify it further.

OK; I was not sure.

>> So, how can I canonically (ideally from C) retrieve a sorted list of
>> supported multi arch paths at runtime? Or is there another good way to
>> solve this? I would think it is a standard use case for multi arch,
>> isn't it?
>
> In general if you have to modify an upstream codebase to make it
> package-manager aware (be that dpkg, rpm or whatever), that to me seems
> like a big red sign too. In this case I think the problem is indeed that
> the original question is flawed, so there's no good answer. :)

IRAF is a quite old program (>>30 years), with some unconventional
solutions. And it is in "maintenance mode" yet.

The Multi-Arch solution upstream took is to put the binaries into
directories

/iraf/iraf/bin.linuxfor 32 bit Linux (x86)
/iraf/iraf/bin.linux64  for 64 bit Linux (x86)
/iraf/iraf/bin.macosx   for 32 bit Mac OSX
/iraf/iraf/bin.macintel for 32 bit Mac OSX

(similar subdirs bin. are under /iraf/iraf/unix, /iraf/iraf/noao etc.)

and then have explicit if statements "if 64-bit linux also look in
32-bit dirs".  This is not applicable for Debian; first because of the
FHS violation; but also because other archs are not really possible. The
ARM architecture is however a working platform, with some use cases
(people want to run it on their raspberry).

Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because
it is arch independent), except the bin.* dirs, which in a Debian
Multiarch environment should go into /usr/lib//iraf, right?

> So, going back. AFAIUI the iraf project supports plugins/extensions in
> the form of executables. 

Yes.

> And some might only be available in a single arch.

No. They are available under 32-bit archs. At least armhf and
i386 (linux + kfreebsd). Maybe x32.

> If that's the case, that looks like those extensions should be
> placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
> we allowed that!), and those package be marked "Multi-Arch: foreign",
> then that's the package manager's problem to choose the most
> appropriate architecture for those binaries (perhaps by using the
> futurable executable attribute of an arch).

This does not work: I have no way to execute from these binaries the
correct 64-bit binary, since it does not know its directory (the
multiarch dir known at compile time is i386-linux-gnu, not
x86_64-linux-gnu).

And I also don't think it is a clean way to make the place of a 32-bit
executable dependent on whether a 64-bit executable exists. Also I would
also like to be able to choose the 32-bit plugin even when a 64-bit one
exists.

I could even think of more exotic test cases, like loading some
qemu-aware kernel modules that enable to run armhf binaries on my intel
machine, and then debug a small plugin for armhf -- so the list of
supported archs may even change at runtime.

To me, this all looks like the perfect use case for "Why do we need
Multi-Arch at the end?", and that's why I would like to have it
implemented in a clean way. I don't see that the problem appears from an
ugly upstream code either: I have no problem with heavily patching it
(in fact, the version being packages is my own fork that significantly
deviates from the original code base). If you think this should be
solved upstream, please tell me how :-)

Best regards

Ole

Re: How to find Multi-Arch path(s)

[Guillem Jover]

Hi!

On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> I want to package a software, "iraf" (with extensions) that uses some
> system dependent binaries internally. Some of the extensions will be
> available in 32 bit only, so this is a good use case for
> Multi-Arch. That means, that the binaries will go to
> 
> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf

It that was to be used, then it should be DEB_HOST_MULTIARCH, the
_TARGET_ variants are for canadian cross-compilers. :) If this is not
clear from the man page, I'm happy to clarify it further.

> At run time, I would now need to get the list of paths that are
> supported by the system, in their "preferred" order (so, even from a
> binary compiled for i386, it would be preferred to call a x86_64 binary
> if that is supported on the system). This list is generally not known at
> compile time, since it depends on the details of the target system
> configuration (f.e. an architecture may be supported via a software
> emulation).
> 
> However, I could not find out how to get this list?
> 
> "dpkg --print-architecture" and "dpkg --print-foreign-architectures"
> gives only what dpkg is configured for, not what is supported as
> executable. And, it does not return the multi-arch triplet.

While there are requests to include this information, so that it can
be retrieved and used, in this case it does not seem this is what you
should be using anyway, even if it was there.

> "dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture
> (default, or specified by the arch name), but from the manpage and the
> package description of dpkg-dev it is not intended for runtime, but for
> package build/development.

Exactly. When one needs the matching triplet or multiarch normalized
triplet for the package's arch, that's best solved by injecting that
at build time, which is already known at that point. In most cases
when one needs to know those matching triplets for *any* arch at
run-time, that's a sign there's something wrong with the design, and
I'd recommend going back to the drawing board. :)

> So, how can I canonically (ideally from C) retrieve a sorted list of
> supported multi arch paths at runtime? Or is there another good way to
> solve this? I would think it is a standard use case for multi arch,
> isn't it?

In general if you have to modify an upstream codebase to make it
package-manager aware (be that dpkg, rpm or whatever), that to me seems
like a big red sign too. In this case I think the problem is indeed that
the original question is flawed, so there's no good answer. :)

So, going back. AFAIUI the iraf project supports plugins/extensions in
the form of executables. And some might only be available in a single
arch. If that's the case, that looks like those extensions should be
placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
we allowed that!), and those package be marked "Multi-Arch: foreign",
then that's the package manager's problem to choose the most
appropriate architecture for those binaries (perhaps by using the
futurable executable attribute of an arch).

Hope that helps!

Thanks,
Guillem

How to find Multi-Arch path(s)

[Ole Streicher]

Hi,

I want to package a software, "iraf" (with extensions) that uses some
system dependent binaries internally. Some of the extensions will be
available in 32 bit only, so this is a good use case for
Multi-Arch. That means, that the binaries will go to

/usr/lib/${DEB_TARGET_MULTIARCH}/iraf

At run time, I would now need to get the list of paths that are
supported by the system, in their "preferred" order (so, even from a
binary compiled for i386, it would be preferred to call a x86_64 binary
if that is supported on the system). This list is generally not known at
compile time, since it depends on the details of the target system
configuration (f.e. an architecture may be supported via a software
emulation).

However, I could not find out how to get this list?

"dpkg --print-architecture" and "dpkg --print-foreign-architectures"
gives only what dpkg is configured for, not what is supported as
executable. And, it does not return the multi-arch triplet.

"dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture
(default, or specified by the arch name), but from the manpage and the
package description of dpkg-dev it is not intended for runtime, but for
package build/development.

So, how can I canonically (ideally from C) retrieve a sorted list of
supported multi arch paths at runtime? Or is there another good way to
solve this? I would think it is a standard use case for multi arch,
isn't it?

Best regards

Ole

Bug#882392: RFS: dmg2img/1.6.7-1 [ITA]

[Stephen Kitt]

Hi Denys,

On Wed, Nov 22, 2017 at 04:08:05AM +, Denys Berkovskyy wrote:
> I am looking for a sponsor for my package "dmg2img"

Excellent, thanks for taking care of this!

> Changes since the last upload:
>  * New upstream version 1.6.6 (Closes: #778827)
>  * New upstream version 1.6.7
>  * Fix FTCBFS: Let cdbs' makefile.mk pass cross compilers. (Closes: #864511)
>  * Update patches
>  * Update debhelper compatibility level to v10
>  * Bump standards version to 4.1.1 (No changes required)
>  * Fix homepage URL, remove obsolete URLs
>  * Update debian/copyright file
>  * Fix typo in packet description
>  * New maintainer (Closes: #881838)

I have a few review comments...

In the changelog, I don’t think there’s much point in repeating “New
upstream version”. I also prefer distinguishing close reasons in
detail: so “New upstream version” would close a bug requesting a new
upstream version, but not bugs which happen to be fixed in the
upstream release. This would result in something like

  * New upstream release:
- fixes a crash on invalid block signatures (Closes: #778827)

While you’re at it, could you check to see whether the other crashing
bugs are fixed? I think some of them might be...

It would be nice too to see whether bindnow and fortify can be enabled
(unless those are false positives in Lintian’s output).

Regards,

Stephen


signature.asc
Description: PGP signature