A large number of packages, particularly development packages, are not
multi-arch aware. This raises the barrier of entry for performing 32 bit
development on a 64 bit system and actively hurts some projects like
Wine where it is very important to be able to compile both versions.
Looking into
On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
> So I looked to see whether the Debian Policy was saying multi-arch is a
> should, a must or something else.
>
> It turns out it does not say anything of value: multi-arch is mentioned
> as being an exception to the FHS in section
On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
> A large number of packages, particularly development packages, are not
> multi-arch aware.
...
>3.10 Multi-arch support
>
>Packages must be multi-arch aware and architecture-specific
>development packages must be tagged
On Tue, 3 May 2016, Holger Levsen wrote:
[...]
> there are already 7 or so bugs about multi-arch missing in various
> places in policy, I'd suggest you go to the BTS, search for those and
> help there.
Those are not the same. They are about documenting various aspects of
multi-arch, not about sta
Package: wnpp
Severity: wishlist
Owner: Pablo Oliveira
User: debian-scie...@lists.debian.org
Usertags: field..statistics
Package name: r-cran-maptree
Version : 1.4-7
Upstream Author : Denis White, Robert B. Gramacy
URL : https://cran.r-project.org/web/packages/map
Package: wnpp
Severity: wishlist
Owner: Jonathon Love
* Package name: python3-protobuf3
Version : 0.2.1
Upstream Author : Sergey Petrov
* URL : https://github.com/Pr0Ger/protobuf3
* License : MIT
Programming Lang: Python
Description : Implementation of
Simon McVittie (2016-05-03):
> On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
> > A large number of packages, particularly development packages, are not
> > multi-arch aware.
> ...
> >3.10 Multi-arch support
> >
> >Packages must be multi-arch aware and architecture-specifi
+++ Holger Levsen [2016-05-03 11:33 +0200]:
> On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
> > So I looked to see whether the Debian Policy was saying multi-arch is a
> > should, a must or something else.
> >
> > It turns out it does not say anything of value: multi-arch is me
On Tue, May 03, 2016 at 02:33:34PM +0200, Francois Gouget wrote:
> Those are not the same. They are about documenting various aspects of
> multi-arch, not about stating whether multi-arch *should* or *must* be
> implemented by packages.
well, before we can require something must be implemented,
On 03.05.2016 13:25, Simon McVittie wrote:
On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
A large number of packages, particularly development packages, are not
multi-arch aware.
...
3.10 Multi-arch support
Packages must be multi-arch aware and architecture-specific
+++ Simon McVittie [2016-05-03 12:25 +0100]:
> On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
> A mass-bug-filing or mass-patch-attaching to make libraries and development
> packages Multi-arch: same would be more in line with how things like this
> usually go.
There has already be
On 03.05.2016 11:33, Holger Levsen wrote:
On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
So I looked to see whether the Debian Policy was saying multi-arch is a
should, a must or something else.
It turns out it does not say anything of value: multi-arch is mentioned
as being a
Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni
* Package name: golang-github-kr-binarydist
Version : 0.0~git20120828.0.9955b0a-1
Upstream Author : Keith Rarick
* URL : https://github.com/kr/binarydist
* License : MIT
Programming Lang: Go
Desc
Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit. We can't do anything automated about the former, only fix the
assembly. But regarding
On 03.05.2016 22:50, Josh Triplett wrote:
Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit. We can't do anything automated about the fo
On Wed, May 04, 2016 at 12:41:25AM +0200, Matthias Klose wrote:
> On 03.05.2016 22:50, Josh Triplett wrote:
> > Debian Policy requires the use of -fPIC for shared libraries, but
> > documents potential exceptions for libraries with position-dependent
> > assembly, and for libraries that would incur
Hi and sorry for what is a basic question, but I can't find a clear
answer.
It seems that dpkg-maintscript-helper is the tool to remove conffiles,
but it doesn't seem to have any special handling for init scripts. Which
means that simply calling "rm_conffile …" will just remove the
/etc/init.d/ sc
Hi all,
I'm very glad for the automatic debug packages, but I wonder if I'm
doing something wrong since I get this warning:
dpkg-genchanges: warning: package foo-dbgsym listed in files list
but not in control info
The package is generated, so this mostly seems like a harmless warning
On Wed, May 04, 2016 at 02:06:56AM +0200, Iustin Pop wrote:
> I'm very glad for the automatic debug packages, but I wonder if I'm
> doing something wrong since I get this warning:
>
> dpkg-genchanges: warning: package foo-dbgsym listed in files list
> but not in control info
>
> The pac
Am 04.05.2016 um 01:21 schrieb Iustin Pop:
> Hi and sorry for what is a basic question, but I can't find a clear
> answer.
>
> It seems that dpkg-maintscript-helper is the tool to remove conffiles,
> but it doesn't seem to have any special handling for init scripts. Which
> means that simply calli
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-markdown
Version : 0.7.7
Upstream Author : Yihui Xie
* URL : https://cran.r-project.org/web/packages/markdown
* License : GPL
Programming Lang: R
Description : GNU R package
Processing commands for cont...@bugs.debian.org:
> block 820036 with 823003
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 820041 821053 821055 820010 821084 820008 820052 820124
820050 821051 820038 821054 820129 821088 821307
820036 was not
On May 03, Josh Triplett wrote:
> While this doesn't make PIC absolutely free, it does eliminate almost
> all of the cost, to the point that it no longer seems worthwhile to
> build without -fPIC. Apart from that, building *all* code with -fPIC
> (including both programs and libraries) helps wit
23 matches
Mail list logo
