On Wed, Nov 28, 2012 at 05:50:38PM +0100, Santiago Vila wrote:
> After careful testing of the patches, I've just uploaded gettext_0.18.1.1-10
> for unstable (with only minor changes), as I consider this split is
> simple enough that it will hardly be disruptive for autobuilders.
Fantastic - thank
Colin, Wookey:
After careful testing of the patches, I've just uploaded gettext_0.18.1.1-10
for unstable (with only minor changes), as I consider this split is
simple enough that it will hardly be disruptive for autobuilders.
This will likely not be accepted for wheezy, but in case we try to
conv
On Fri, Nov 23, 2012 at 09:23:14PM +0100, Julien Cristau wrote:
> On Fri, Nov 23, 2012 at 13:31:12 +, Colin Watson wrote:
> > Well, on the one hand, multiarch is a release goal, but it can't
> > realistically be an open-ended one - we have to stop somewhere. It's
> > not as if there aren't ple
On Fri, Nov 23, 2012 at 13:31:12 +, Colin Watson wrote:
> Well, on the one hand, multiarch is a release goal, but it can't
> realistically be an open-ended one - we have to stop somewhere. It's
> not as if there aren't plenty of other cross-building issues. On the
> other hand, it's true tha
On Fri, Nov 23, 2012 at 02:22:25PM +, Wookey wrote:
> +++ Colin Watson [2012-11-23 13:31 +]:
> > Do you have an opinion on this part? If not, I think my default would
> > be for the next version of this patch to move autosprintf.info.gz back
> > to gettext, for safety.
>
> Doesn't this pr
+++ Colin Watson [2012-11-23 13:31 +]:
> On Fri, Nov 23, 2012 at 01:31:45PM +0100, Santiago Vila wrote:
> > On Fri, 23 Nov 2012, Colin Watson wrote:
> > >I've confirmed that these -dev packages are multiarch-coinstallable,
> > >which is good. There is one remaining niggle here: while
> > >/us
On Fri, Nov 23, 2012 at 01:31:45PM +0100, Santiago Vila wrote:
> On Fri, 23 Nov 2012, Colin Watson wrote:
> >It also occurred to me that gettext should depend on libasprintf-dev and
> >libgettextpo-dev, otherwise anything that Build-Depends on gettext
> >expecting to be able to use one of those lib
On Fri, 23 Nov 2012, Colin Watson wrote:
It also occurred to me that gettext should depend on libasprintf-dev and
libgettextpo-dev, otherwise anything that Build-Depends on gettext
expecting to be able to use one of those libraries will immediately
FTBFS. Perhaps it will be possible to get rid
On Wed, Nov 21, 2012 at 09:15:51PM +0100, Santiago Vila wrote:
> El 21/11/12 18:31, Colin Watson escribió:
> >I would say that only things tightly associated with libasprintf and
> >libgettextpo - so autosprintf.h / gettext-po.h respectively plus the
> >corresponding .a/.so - should go in the -dev
El 21/11/12 18:31, Colin Watson escribió:
I would say that only things tightly associated with libasprintf and
libgettextpo - so autosprintf.h / gettext-po.h respectively plus the
corresponding .a/.so - should go in the -dev package.
Everything else (and in particular everything under /usr/share
On Wed, Nov 21, 2012 at 05:00:08PM +, Wookey wrote:
> +++ Colin Watson [2012-11-21 12:57 +]:
> > On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> > > +Package: libgettextpo-dev
> > > +Section: libdevel
> > > +Architecture: any
> > > +Multi-Arch: same
> > > +Depends: libgettextpo0 (
+++ Colin Watson [2012-11-21 12:57 +]:
> On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> > OK. As I was getting very bored of marking Build-deps 'gettext:any' in
> > Ubuntu (and they'd all have to be changed back eventually anyway),
> > I've done the work to extend PJs patch to split
On Sun, Nov 18, 2012 at 03:08:35AM +, Wookey wrote:
> OK. As I was getting very bored of marking Build-deps 'gettext:any' in
> Ubuntu (and they'd all have to be changed back eventually anyway),
> I've done the work to extend PJs patch to split into two libraries.
> Not yet very carefully checke
+++ Santiago Vila [2012-09-24 18:22 +0200]:
> On Mon, 24 Sep 2012, Wookey wrote:
>
> >Santiago, have you reached an opinion on whether you'd prefer to
> >1) split the gettext package into an MA:same libgettext-dev part and
> >an MA:foreign gettext part (and change corresponding dependencies), or
>
On Mon, 24 Sep 2012, Wookey wrote:
Santiago, have you reached an opinion on whether you'd prefer to
1) split the gettext package into an MA:same libgettext-dev part and
an MA:foreign gettext part (and change corresponding dependencies), or
2) mark it MA:allowed and change all the dependencies th
Santiago, have you reached an opinion on whether you'd prefer to
1) split the gettext package into an MA:same libgettext-dev part and
an MA:foreign gettext part (and change corresponding dependencies), or
2) mark it MA:allowed and change all the dependencies that only need the
build-tool part to '
tags 683751 + patch
thanks
On 2012-08-14 17:05, Steve Langasek wrote:
> On Tue, Aug 14, 2012 at 10:52:38PM +0200, Santiago Vila wrote:
>> Now the question: Do libasprintf-dev and libgettextpo-dev really need
>> to be in a different package than gettext?
>
> I think that depends on whether there's
On Tue, Aug 14, 2012 at 10:52:38PM +0200, Santiago Vila wrote:
> On Tue, 14 Aug 2012, Steve Langasek wrote:
> >against the libs, are shipped in the 'gettext' binary package; when
> >cross-building a package that build-depends on gettext, we have to
> >know whether they're using the tools or the li
On Tue, 14 Aug 2012, Steve Langasek wrote:
against the libs, are shipped in the 'gettext' binary package; when
cross-building a package that build-depends on gettext, we have to
know whether they're using the tools or the libraries.
Please note that if they are using the libraries, they should
On Tue, 14 Aug 2012, P. J. McDermott wrote:
So there appear to be three ways to make gettext capable of satisfying
cross build dependencies of packages such as those Johannes listed:
1. Mark gettext Multi-Arch: allowed. All depending packages that are
to be cross built will need to depend o
On 2012-08-14 16:08, P. J. McDermott wrote:
> 2. Split the remaining libraries out of gettext (my original proposed
> solution). Mark gettext Multi-Arch: foreign and the new libraries
> package(s) Multi-Arch: same.
> 3. Remove the aforementioned symbolic links and declare the libraries
>
On 2012-08-13 13:06, P. J. McDermott wrote:
> On 2012-08-13 07:30, Santiago Vila wrote:
>> Moreover, all the libraries which are meant to be used by other
>> packages are already multi-arched and they are in their own package
>> (the last two in the list above).
>
> But this is a good point, which
Hi there,
On Mon, Aug 13, 2012 at 01:06:28PM -0400, P. J. McDermott wrote:
> On 2012-08-13 09:32, Johannes Schauer wrote:
> > On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote:
> >> So: What exactly did you mean by "split"?
> > Patrick's idea was to split the gettext binary package in
On 2012-08-13 09:32, Johannes Schauer wrote:
> On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote:
>> So: What exactly did you mean by "split"?
>
> Patrick's idea was to split the gettext binary package into two
> packages: one package that would contain those parts that satisfy
> depen
Hi,
On Mon, Aug 13, 2012 at 01:30:12PM +0200, Santiago Vila wrote:
> On Thu, 9 Aug 2012, P. J. McDermott wrote:
> > I wonder if the gettext binary package should instead be split.
> > Perhaps gettext-runtime (M-A: same) should provide the libraries,
> > gettext-tools (M-A: foreign) should provide
On Thu, 9 Aug 2012, P. J. McDermott wrote:
> I wonder if the gettext binary package should instead be split. Perhaps
> gettext-runtime (M-A: same) should provide the libraries, gettext-tools
> (M-A: foreign) should provide the tools, and gettext should be a
> metapackage that depends on both of t
On Thu, Aug 09, 2012 at 05:17:03PM -0400, P. J. McDermott wrote:
> I wonder if the gettext binary package should instead be split. Perhaps
> gettext-runtime (M-A: same) should provide the libraries, gettext-tools
> (M-A: foreign) should provide the tools, and gettext should be a
> metapackage that
I wonder if the gettext binary package should instead be split. Perhaps
gettext-runtime (M-A: same) should provide the libraries, gettext-tools
(M-A: foreign) should provide the tools, and gettext should be a
metapackage that depends on both of the former packages?
Steve, is there any particular
Package: gettext
Version: 0.18.1.1-9
Severity: normal
Hi,
the gettext binary package being Multi-Arch: None prevents the following
essential source packages from being cross compiled:
- acl
- attr
- bash
- binutils
- coreutils
- dpkg
- e2fsprogs
- gawk
- gcc-4.7
- grep
- shadow
- tar
29 matches
Mail list logo
