Steve Langasek writes:
> On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote:
> > Steve Langasek writes:
> > > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > > > Please consider moving the following packages to testing:
>
> > > > gcj-4.1
>
> > > I'm wonderi
On Fri, Nov 03, 2006 at 07:37:33AM +0100, Matthias Klose wrote:
> > > no, only the upstream tarball is used from gcc-4.1-source. the
> > > patches are used from the gcj-4.1 source. The patches in
> > > gcc-4.1-source are needed to build cross compilers, based on
> > > gcc-4.1-source.
> > My point
I sent this email to the ia64 buildd admin about two weeks ago, and it
looks like w-b still hasn't been updated for cynthiune.app on ia64.
Can someone look into this? The ia64 build is the only thing keeping
cynthiune.app out of testing, AFAICT.
Thanks.
-- Forwarded message
On Fri, Nov 03, 2006 at 03:20:17AM +, Wookey wrote:
> Rebuilds of packages that built OK but have wrong versions of libs:
> --
> Gnome uninstallable:
> gnome-control-center_2.14.2-3+b1_arm.deb binNMU has been uploaded (it
> was
On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > > Please consider moving the following packages to testing:
> > > gcj-4.1
> > I'm wondering whether the build-dependencies of gcj-4.1
On Thu, Nov 02, 2006 at 01:11:24PM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > so in the absence of any movement in this area, I still need to
> > know what Debian is going to do with gcj on ARM for the upcoming etch
> > release.
> in the worst case, remove the binaries built from gc
See http://wiki.debian.org/ArmBuilddWatch for details.
Rebuilds of packages that built OK but have wrong versions of libs:
--
Gnome uninstallable:
gnome-control-center_2.14.2-3+b1_arm.deb binNMU has been uploaded (it
was incorrectly
On Thursday 02 November 2006 11:50, Goswin von Brederlow wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> > There have been some (expected) delays in getting all needed udebs
> > into testing, but they are finally there. No reports of blocking
> > issues, so I've just uploaded the build of debian-i
On Wed, 1 Nov 2006 23:56:17 +0100, Christian T Steigies <[EMAIL PROTECTED]>
said:
> On Tue, Oct 31, 2006 at 06:01:57PM -0800, Steve Langasek wrote:
>> On Mon, Oct 23, 2006 at 01:09:13AM -0500, Manoj Srivastava wrote:
>> > On Sun, 22 Oct 2006 00:52:59 +0200 (CEST), Michael Schmitz
>> > <[EMAIL PR
Package: openbsd-inetd
Severity: critical
Justification: breaks unrelated software
The recent priority exchange of openbsd-inetd (extra in 3.1r3,
important in 3.1r4) and netkit-inetd (vice versa) was said to have
happened only in Etch/Sid, but in fact it did also happen in Sarge and
there it break
giskard -- 2.11.2006 16:47 --:
> Il giorno gio, 02/11/2006 alle 11.21 +0200, Damyan Ivanov ha scritto:
>> severity 390742 grave
>> thanks
>>
>> The package is unusable with the gaim in unstable. I am raising the
>> severity. Please rebuild as promised or ask for a binNMU.
>>
> it needs only a rebu
Fabio Tranchitella wrote:
> Hello,
> upstream won't support school{tool,bell} untill their next upstream
> release, which will probably take place after the Etch release (or at
> least we hope so :)).
>
> schooltool and schoolbell packages are blocking zope3 to propagate to
> testing, so they
Hello,
upstream won't support school{tool,bell} untill their next upstream
release, which will probably take place after the Etch release (or at
least we hope so :)).
schooltool and schoolbell packages are blocking zope3 to propagate to
testing, so they should be removed from testing.
Thanks,
Steve Langasek writes:
> Hi Matthias,
>
> On Sun, Oct 29, 2006 at 02:20:39PM +0100, Matthias Klose wrote:
> > gcc-4.1 4.1.1-19 in unstable now looks like not showing build time
> > regressions compared to 4.1.1-13 in testing, validated on amd64.
> > Lucas Nussbaum volunteered to build testing from
Steve Langasek writes:
> On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > Please consider moving the following packages to testing:
>
> > gcj-4.1
>
> I'm wondering whether the build-dependencies of gcj-4.1 are really accurate.
> Is it really the case that gcj-4.1 will buil
Steve Langasek writes:
> so in the absence of any movement in this area, I still need to
> know what Debian is going to do with gcj on ARM for the upcoming etch
> release.
in the worst case, remove the binaries built from gcj-4.1,
ecj-bootstrap-gcj. How many build-dependencies will be broken? Did
Andrew Haley writes:
> Steve Langasek writes:
> > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > > Please consider moving the following packages to testing:
> >
> > > - arm: debian only port, not yet submitted to upstream; runtime is
> > >currently non-functional, te
On Wed, Nov 01, 2006 at 09:53:37AM +, Andrew Haley wrote:
> > > Going back to gcj-4.0 for arm could be an alternative, at least simple
> > > programs did compile to native code and run sucessfully. The testsuite
> > > in 4.0 shows over 100 test failures, in 4.1 over 700. Reverting back
> >
Frans Pop <[EMAIL PROTECTED]> writes:
> There have been some (expected) delays in getting all needed udebs into
> testing, but they are finally there. No reports of blocking issues, so
> I've just uploaded the build of debian-installer that should become RC1.
Will that include m68k? I looked fo
Hi Jonas,
I've looked at the FTBFS and I think the best thing to do would be to
change debian/rules so that dpatches are applied before the configure
script is executed (thereby allowing the dpatch to change Makefile.in
instead of the generated Makefile).
I'll write a patch, test it and commit it
severity 390742 grave
thanks
The package is unusable with the gaim in unstable. I am raising the
severity. Please rebuild as promised or ask for a binNMU.
CC-ing release to make them aware.
Thanks for considering,
dam
--
Damyan Ivanov Modular Software Systems
[
reopen 394297 !
thanks
Hi,
From discussion on -release I assume that a binNMU was planned for
gaim-extendedprefs, but I see no traces of such a binNMU. The bug is
still here.
Can it be closed by the actual binNMU .changes, instead of manually
(which seems to differ from reality)?
Thanks,
22 matches
Mail list logo
