On Fri, Dec 02, 2005 at 01:23:34PM -0500, Nathanael Nerode wrote:
> >> And the following library packages haven't built in c2 versions on
> >> all architectures, and therefore prevent other packages from
> >> transitioning:
> >> pdfkit.framework -- m68k (blocks viewpdf.app, gworkspace.app)
> >m68
On Fri, Dec 02, 2005 at 08:47:47PM +0100, Mike Hommey wrote:
> As you may or may not know, I'm currently working on packaging
> xulrunner, which is ought to be the central point for all future mozilla
> technology, meaning that at more or less long term, all mozilla products
> (firefox, thunderbir
On Fri, Dec 02, 2005 at 03:06:01PM -0800, Ross Boylan wrote:
> For quite awhile (one or two months?) I've noticed that upgrading KDE
> in testing, or doing a dist-upgrade, knocks out lyx and lyx-qt. Some
> of the bug reports indicate lyx was removed from testing to let KDE
> in.
> Is there any pr
For quite awhile (one or two months?) I've noticed that upgrading KDE
in testing, or doing a dist-upgrade, knocks out lyx and lyx-qt. Some
of the bug reports indicate lyx was removed from testing to let KDE
in.
Is there any prospect of this situation improving? I'd like to move
to the new KDE, b
Hi,
if I'm not mistaken, qbankmanager needs a binNMU for the aqbanking C++
transition.
Is it possible to schedule it now on
alpha amd64 arm i386 mips mipsel powerpc s390 sparc (i.e. all but m86k
ia64 hppa which haven't compiled aqbanking yet)?
Kind regards and TIA
T.
--
Thomas Viehmann, http://
Mike Hommey wrote:
> - Now, the problem is that we can't really use the sonames correctly,
> because if we succeed in the clue stick batting, we'll have different
> sonames, which, in the long term, would be painful. So, I'd like to
> provide a dummy gecko-x.y-serial or such package, which would co
Hi
As you may or may not know, I'm currently working on packaging
xulrunner, which is ought to be the central point for all future mozilla
technology, meaning that at more or less long term, all mozilla products
(firefox, thunderbird, etc.) will be built on top of it.
That will be indeed a great i
>> And the following library packages haven't built in c2 versions on
>> all architectures, and therefore prevent other packages from
>> transitioning:
>
>> pdfkit.framework -- m68k (blocks viewpdf.app, gworkspace.app)
>
>m68k should just be ignored for these purposes; the arch is doing much
>bette
On Fri, Dec 02, 2005 at 12:23:37PM +0100, Domenico Andreoli wrote:
> On 12/2/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> > ...
> > ***
> > The following library packages have been renamed for the C++
> > allocator change but haven't built on all architectures yet. The
> > ones near the top
On 12/2/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:
> ...
>
> ***
> The following library packages have been renamed for the C++
> allocator change but haven't built on all architectures yet. The
> ones near the top have other problems which must be addressed too.
>
> boost -- FTBFS on hppa,
On Fri, Dec 02, 2005 at 12:43:26AM -0500, Nathanael Nerode wrote:
> It's going pretty well, really. :-)
>
>
> The following packages are still linked with g++ 2.95 (!):
>
> The following library packages still need renaming for the C++ ABI change
> (see http://people.debian.org/~djpi
On Fri, Dec 02, 2005 at 12:37:11PM +0200, Damyan Ivanov wrote:
> I am puzzled about how to proceed.
> firebird2 packages are uploaded on i386, built with new allocator and don't
> export any suspicious symbols.
> At the time of the upload, however, amd64 buildd were still with g++ with c2
> allo
[Please CC me]
Hi,
I am puzzled about how to proceed.
firebird2 packages are uploaded on i386, built with new allocator and don't
export any suspicious symbols.
At the time of the upload, however, amd64 buildd were still with g++ with c2
allocator and therefore the amd64 packages are still usin
13 matches
Mail list logo
