1. Multiarch and interpreters/runtimes
 
 Questions from maintainers welcome

  Status of multiarching various interpreters/runtimes?
   * Python done in ubuntu: https://wiki.debian.org/Python/MultiArch
   * Perl done as prototype (Should go to experimental after 5.18 transition)
   * Tcl done
   * ruby 2.0 has multiarch support upstream, final packaging bits pending. once done can^Wcould be backported to ruby 1.9
   * Java, mono, node.js, R, php?

  What shall we do about chains of embedded interpreter and arch-indep, arch-dep, arch-indep modules, which need either some enhancement to the multiarch spec or changing all affected arch-dep modules to arch any.
  i.e pkgA:i386 -> pkgB:all -> pkgC:i386 (not all, and not amd64)

  Debconf discussion documented here: https://wiki.debian.org/Multiarch/debconf2013notes



  How big a problem is this?
 Max of: 178 perl packages, 81 python, 28 java, 159 mono, 52 ruby, 10 node.js


 2 Multiarch-cross spec at https://wiki.ubuntu.com/MultiarchCross

  * Are there any problem with this? Should we just make it official and change the main spec accordingly?
   action: wookey will fix wiki.
  * arch-indep headers stay in /usr/include, arch-dep ones go in /usr/include/$MULTIARCH_DIR
  * :any and :native and :<arch> Already implemented in dpkg and sbuild in wheezy, but not so should be OK to upload.

 3 Should apt in Debian assume arch-all _build_-deps as MA:foreign? Or should we fix all the packages
   * See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666772
   Some solutions to 1 make this unnecessary.

 4 Can we define MA-related release goals for jessie?
   Very out of date page at: https://wiki.debian.org/ReleaseGoals/MultiArch

   suggested goals:
    * make -dev packages multi-arch capable
    * some QA

   action: cjwatson to set up auto-cross-builder for unstable once cross-compilers are in the archive

 5 What about Mingw partial arch? Can we support non-posix libc in multiarch? Move all of libc headers into /usr/include/$MULTIARCH?
  - please include -w64- in dpkg os/arch/triplet tables
 
 6 Questions from maintainers?
    * Building OOT modules for foreign kernel (linux-headers-* packages), e.g. i386/amd64, x32/amd64
      - Currently works for many architectures with fake-native packages and multilib compiler
    * is it useful/needed to have $(triplet)-interpreter in $PATH?
      -> no

 7 enable i386 as a default foreign architecture on amd64
     * doesn't this double the amount of stuff APT downloads by default?