On Sat, Nov 19, 2016 at 05:53:04PM +0100, Julien Cristau wrote:
> On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
>
> > The -dbg package is Multi-Arch same. It Depends on the packages for
> > which it provides debugging symbols, some of which are Multi-Arch:
>
On Tue, Nov 1, 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> The -dbg package is Multi-Arch same. It Depends on the packages for
> which it provides debugging symbols, some of which are Multi-Arch:
> allowed.
That Depends seems wrong, there's no reason a -dbg package needs a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear David,
Le 02/11/2016 à 01:05, David Kalnischkies a écrit :
> I would add:
>
> * Check if gyoto-bin really needs to be M-A:allowed. Name,
> Description and the list of filenames included in the package
> suggest to me that the package can and
On Tue, Nov 01, 2016 at 09:24:10PM +, Simon McVittie wrote:
> On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> > The -dbg package is Multi-Arch same. It Depends on the packages for
> > which it provides debugging symbols, some of which are Multi-Arch:
>
On Tue, 01 Nov 2016 at 18:11:27 +0100, Thibaut Paumard wrote:
> The -dbg package is Multi-Arch same. It Depends on the packages for
> which it provides debugging symbols, some of which are Multi-Arch:
> allowed. Lintian complains when I don't specify an architecture for
> those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear David,
Le 01/11/2016 à 15:57, David Kalnischkies a écrit :
> On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote:
>> How do you actually use Multi-Arch: allowed? Should a dependent
>> package then specify either :s
On Tue, Nov 01, 2016 at 02:43:21PM +0100, Thibaut Paumard wrote:
> How do you actually use Multi-Arch: allowed? Should a dependent
> package then specify either :same or :foreign? Looks
Neither is valid syntax.
What you do with these is depending on a package with the literal
architecture
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dear all,
How do you actually use Multi-Arch: allowed? Should a dependent
package then specify either :same or :foreign? Looks
like it's not working:
https://piuparts.debian.org/sid/fail/gyoto-dbg_1.1.1-1.log
I was able to find documentation
Am 09.01.2014 20:20, schrieb Colin Watson:
> Apparently, though, quite a few packages do fail to build with
> /usr/bin/libtool split out. I don't have numbers yet - Matthias said he
> was going to summarise. Still, I think this will be easier to fix than
> trying to get an M-A: allowed libtool to
On Thu, Jan 09, 2014 at 07:20:40PM +, Colin Watson wrote:
> If you weren't one of the people in the "thinking extremely hard about
> multiarch" BOF at DebConf, note that Multi-Arch: foreign denotes a point
> in the dependency graph where you're allowed to switc
On Thu, Jan 09, 2014 at 07:20:40PM +, Colin Watson wrote:
>
> Overall, I would therefore prefer option 1 (not the option I expected to
> prefer when I started analysing this!), because as far as I can see it
> will unblock cross-building for both packages that need /usr/bin/libtool
> and those
> discovered today, it totally hoses cross-building as a result. If
> > libtool is Multi-Arch: allowed, then everything that build-depends on it
> > gets libtool: (i.e. the architecture you're building for). Now,
> > that initially seems like what you want, because it giv
On Thu, Jan 09, 2014 at 07:20:40PM +, Colin Watson wrote:
> On Thu, Jan 02, 2014 at 06:14:07PM +, Dimitri John Ledkov wrote:
> > The correct solution is for libtool package to be marked as
> > "multi-arch: allowed" without splitting this tiny package into two
On Thu, Jan 02, 2014 at 06:14:07PM +, Dimitri John Ledkov wrote:
> The correct solution is for libtool package to be marked as
> "multi-arch: allowed" without splitting this tiny package into two
> even smaller packages.
This analysis makes sense as far as it goes, but the
The correct solution is for libtool package to be marked as
"multi-arch: allowed" without splitting this tiny package into two
even smaller packages.
Here is the reasoning:
libtool binary package can be used in both native and cross
compilation cases, when used correctly. That is in
15 matches
Mail list logo
