Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, severity of 874206 is minor

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was 
spwhit...@spwhitton.name).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> severity 874206 minor
Bug #874206 [debian-policy] debian-policy: allow a trailing comma in package 
relationship fields
Severity set to 'minor' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
874206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874206
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#749826: Documenting `Multi-Arch: foreign`

[Helmut Grohne]

On Sat, Sep 02, 2017 at 08:44:14AM -0700, Sean Whitton wrote:
> Rather than introduce the new terminology 'intended interface', which we
> would definitely have to define, how about something like this:
> 
> If all a package's architecture-dependent interfaces are listed in
> README.multiarch, the package is not considered to have any
> architecture-dependent interfaces for the purposes of determining
> whether it may be labelled Multi-Arch: foreign.

This is not how it works. It's not like you can just mark any package
Multi-Arch: foreign after saying that it is architecture-dependent. That
documentation must come with a contract saying that reverse dependencies
must not use those architecture-dependent interfaces.

> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.

Well, it's not exactly legitimate. It's more like unavoidable as Simon
pointed out in his reply. Technically, libc6's behaviour is wrong and
causes unpack errors. The reasonable solution would be prohibiting
coinstallation of libc6:mips and libc6:mipsel, but package metadata does
not allow us to do that currently (#747261 -> self-conflicts are always
ignored). The other option of removing Multi-Arch: same from libc6 would
essentially render Multi-Arch useless. So all we can do now is pretend
the issue wasn't there.

> > * If you rebuild the source package with a very different
> > installation set (i.e. much newer Build-Depends), does it still
> > have to match with older instances? Example: #825146. What
> > divergence in installation sets is ok?
> 
> We could just say that it must match the instances in the target suite.

We could. That would render libgiac0 rc buggy for instance, because it
was built on mips64el three weeks later than on other architectures and
thus uses an incompatible gettext.

That definition is pretty annoying for bootstraps though as replicating
ancient toolchain is kinda the opposite of what bootstrappers do.

> >(A simple way to satisfy this requirement is to use
> >architecture-dependent paths exclusively. That works except for
> >/usr/share/doc/$pkg.)
> >
> >  * The maintainer scripts must handle multiple configuration and
> >multiple deconfiguration correctly. In particular, a package can be
> >purged for one architecture while being installed for another.
> >Example: #682420.
> >
> >(A simple way to satisfy this requirement is to not ship maintainer
> >scripts.)
> >
> >  * Source packages carrying any binary package marked `Multi-Arch: same`
> >must always be binNMUed in lock-step. (Presently violated e.g. by
> >libselinux1)
> 
> Could you turn this into some commits against my branch, please?

I tried and ran into a new problem: I am now convinced that we cannot
just describe one Multi-Arch value after another as they do share some
common values. That "interface" aspect and architecture-constraints on
dependencies is a common theme and likely deserves an introductory text.

Yet, I am attaching what I have.

> It sounds like we need to just drop the whole bullet point.
> Architecture: all packages need to be checked carefully, just like
> Architecture: any packages.

Reworded.

> To my mind, the most important ways to achieve readability in this case
> are
> 
> - avoid repetition
> - avoid "probably", "likely" sentences.

The latter is particularly hard, because we violate the strict
definitions more often than is immediately apparent.

As Simon's mail demonstrates, we likely need more answers/consensus
before continuing. I'll reply in a separate mail.

Helmut
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 509a96e..e6451d5 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -1028,6 +1028,18 @@ control file.
 We consider the meaning of each possible value of this field
 separately.
 
+``Multi-Arch: no``
+++
+
+This value is the default. When satisfying a dependency on a package
+(implicitly) marked ``Multi-Arch: no``, the depender and the dependee
+must have the same architecture. For the purpose of this matching,
+``Architecture: all`` packages are treated as if they had the
+architecture value of ``dpkg``.
+
+The value ``no`` cannot currently be used in binary packages due to
+limitations of the archive processing.
+
 ``Multi-Arch: foreign``
 +++
 
@@ -1037,12 +1049,15 @@ architecture.
 In order to determine whether this holds, you should consider
 
 the files installed by the package
-``Architecture: all`` packages always provide
-architecture-independent interfaces.  Shared and static libraries
-provide architecture-dependent ABIs.  Binary executables may
-provide architecture-independent interfaces: could software
-interacting with the executable determine the architecture for
-which it was built without reading the executable file?
+``Architecture: all`` packages tend to provide

Bug#749826: Documenting `Multi-Arch: foreign`

[Helmut Grohne]

Hi Simon,

On Sat, Sep 02, 2017 at 05:26:57PM +0100, Simon McVittie wrote:
> That seems like it might be a bug (or design flaw if you prefer). If a
> package (build-)depends on foo:any, it is saying "I am only using the
> arch-indep parts of foo's interface", whatever those are.

You may call it feature. The idea here was that :any should not be used
mindlessly. Thus it is only allowed on packages properly marked for that
used with ``Multi-Arch: allowed``. In Build-Depends, you can mostly
achieve the same effect with :native (which essentially is :any on any
package (but Architecture: all packages (though our dependency resolvers
don't agree here))).

> Perhaps a dependency on foo:any by (for example) bar:mips should
> always be satisfiable by foo:mips (as though the :any had been omitted),
> regardless of foo's multi-arch status? This would bring it back to the
> same meaning as omitting the :any, in the trivial case where only one
> architecture is enabled.

That proposal may ease meta data changes indeed. I suspect that it would
also cause a lot of useless :any annotations. It's a two-sided sword.

> Perhaps a dependency on foo:any should be satisfiable by any instance
> of foo that is Multi-Arch: foreign? (In this case the :any is completely
> redundant, because foreign sets up a similar situation from the other end)

After studying Multi-Arch for many years now, I recognize that a core
idea is to almost always flag the architecture constraint on the target
of an edge. To understand this wicked sentence, consider a dependency
graph and label each node (package) with an architecture. Now Multi-Arch
says that by default every edge (dependency) must enforce equal
architecture on both ends. Most of the header's job is relaxing this
restriction. The designers of Multi-Arch decided that this relaxing
should not be a property of the edges (e.g. :any), but a property of the
dependee.

Thus the current implementation ensures that :any cannot be used in
situations where it is inappropriate. As you point out, that design is
annoying for meta data transitions.

> > > I think "the files installed by ``Architecture: all`` packages always
> > > provide architecture-independent interfaces." is too broad. The counter
> > > example is haskell-devscripts-minimal. This needs to be weakened
> > > somehow.
> 
> I would argue that these interfaces are architecture-independent from
> the perspective of the package's (lack of) architecture. What they
> are not independent of is the *build machine* architecture, just like
> running uname -m or inspecting /proc/cpuinfo aren't independent of the
> build machine architecture. This is certainly a problem for
> cross-compilation, but it isn't the same issue as in dpkg or pkg-config,
> where the architecture for which dpkg or pkg-config was built gets
> hard-coded into its installed files (as the output of --print-architecture
> or part of the default search path, respectively).

That's a nice view, but it is not the view expressed by Multi-Arch. The
meaning of the header considers the whole installation set as a unit.
Whether you view this in a package building context or runtime context
does not matter, what matters is whether the tools behave differently
when you swap the architecture of underlying parts.

As a side note, we marked pkg-config Multi-Arch: foreign, but that is
technically wrong on another level. The marking would imply that it
doesn't matter which architecture you use to supply the package. A
prospective README.multiarch would need to say that you must not use
plain pkg-config (without a triplet prefix). Yet that is what most
packages do. If you perform an archive rebuild of pkg-config build-rdeps
on amd64 in a chroot with preinstalled pkg-config:i386, the majority of
builds will fail even though their Build-Depends are installable.

This is another place where we bend the rules just to make it barely
useful. For performing useful cross builds, one needs to discard host
architecture instances of ``Multi-Arch: foreign`` packages.

> > > For instance, the policy should make it
> > > clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see
> > > #843023) would be a policy violation.
> 
> It is not clear to me that doing so *should* be a policy violation. If
> libmdds-dev contains only headers (no shared or static library), and it
> exposes architecture-independent libboost-dev headers (but no Boost
> shared or static library), is there really anything wrong with having
> libboost-dev from "the wrong architecture"?

As long as everything is header-only, you can use ``Multi-Arch:
foreign``.  The thing is, even if libboost-dev was
architecture-independent, it would expose libstdc++-7-dev. Since
exposure is transitive, that carries over to libmdds-dev.

Boost's dependency on libstdc++-4.8-dev | libstdc++-dev looks a bit
strange though. Since libc++-dev provides libstdc++-dev (and no compiler
will just use libc++-dev when it is installed without further 

Bug#874291: developers-reference: security uploads should go to *.security.upload.d.o

[Ansgar Burchardt]

Package: src:developers-reference
Version: 3.4.18
Severity: normal
Tags: patch

Security uploads should not be uploaded to security-master.d.o, but
ftp.security.upload.debian.org or (in the future)
ssh.security.upload.debian.org.

A patch to refer to *.security.upload.d.o or ftp.security.upload.d.o
instead of security-master.d.o is attached.

Ansgar
--- pkgs.dbk.ori2017-09-04 20:55:50.143885377 +0200
+++ pkgs.dbk2017-09-04 20:52:17.635087895 +0200
@@ -443,7 +443,7 @@
 Security uploads
 
 Do NOT upload a package to the security
-upload queue (on security-master.debian.org)
+upload queue (on *.security.upload.debian.org)
 without prior authorization from the security team.  If the
 package does not exactly meet the team's requirements, it will cause many
 problems and delays in dealing with the unwanted upload.  For details, please
@@ -1193,7 +1193,7 @@
 Uploading the fixed package
 
 Do NOT upload a package to the security
-upload queue (on security-master.debian.org)
+upload queue (on *.security.upload.debian.org)
 without prior authorization from the security team.  If the
 package does not exactly meet the team's requirements, it will cause many
 problems and delays in dealing with the unwanted upload.
@@ -1212,7 +1212,7 @@
 Once you have created and tested the new package and it has been approved by
 the security team, it needs to be uploaded so that it can be installed in the
 archives.  For security uploads, the place to upload to is
-ftp://security-master.debian.org/pub/SecurityUploadQueue/.
+ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue/.
 
 
 Once an upload to the security queue has been accepted, the package will

Processed: fix versions…

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfound 874206 3.9.8
Bug #874206 [debian-policy] debian-policy: allow a trailing comma in package 
relationship fields
There is no source info for the package 'debian-policy' at version '3.9.8' with 
architecture ''
Unable to make a source version for version '3.9.8'
No longer marked as found in versions 3.9.8.
> found 874206 3.9.8.0
Bug #874206 [debian-policy] debian-policy: allow a trailing comma in package 
relationship fields
Marked as found in versions debian-policy/3.9.8.0.
> --
Stopping processing here.

Please contact me if you need assistance.
-- 
874206: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874206
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#874206: debian-policy: allow a trailing comma in package relationship fields

[Mattia Rizzolo]

Package: debian-policy
Version: 3.9.8

I use the `wrap-and-sort` tool to keep my list of dependencies neatly
sorted and wrapped.  In particular, I use the `-t` flag to have a
trailing comma at the end of the list.  For example

Build-Depends:
 foo,
 bar,
Homepage: …

There, notice how there is a comma after "bar", the last item of the
list.

I've heard several people in several forums assert that such syntax is
totally undocumented, despite being accepted by all tools I know of.
Indeed, policy doesn't explicitly allow (but AFAIK neither disallow)
such syntax.  Nonetheless, I'd prefer if some tweaks could be done to
the policy to stop these annoying comments :)

I think such stuff belongs to § 7.1 "Syntax of relationship fields", but
I can't really image what to write and where.



FTR, this bug was triggered by .

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature