[sorry for not replying earler. please CC the package maintainer address, I
don't read debian-java
on a daily basis]
Florian Weimer schrieb:
Here are the results of building some OpenJDK packages on the security
buildd infrastructure (with the test suites disabled).
thanks for doing this.
please consider twisted 8.1.0-4 for testing, fixing an upgrade problem
with the plugin cache, a build failure on GNU/kFreeBSD and some minor
things.
Matthias
twisted (8.1.0-4) unstable; urgency=low
* Move the cache update from python-twisted into python-twisted-core.
Closes: #500942.
The gcc-4.2 branch did see some ( 10) fixes. I'll prepare an upload
of both gcc-4.2 and gcj-4.2 next weekend, and upload to unstable, if
there are no concerns about the upload. The changes are in the gcccvs
repository. The packages build without regressions on amd64 and i386.
Matthias
gcc-4.2
this is pending for two weeks. if this is not yet decided I'm
considering an update to the current packaging branch and the upstream
gcc 4.3 release branch (gcc-4.3 source package only).
Matthias
Matthias Klose writes:
now that the packages are all built on all architectures I'm proposing
Rene Engelhard writes:
Hi,
Matthias Klose wrote:
If all there packages are unblocked, please consider unblocking
gcc-defaults as well, adjusting just the package versions and
constraining the dependencies.
That upload(s) (through bumped shlibs for libgcj-bc) makes at least
Florian Weimer writes:
the openjdk-6 package runs the testsuite. if the security team prefers
shorter build times, then the testuite can be disabled in security
uploads.
Uhm, okay.
I didn't change this in the -2 upload.
the testsuite is not run in the cacao-oj6 package.
And build
Florian Weimer writes:
* Luk Claes:
Matthias Klose wrote:
proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including
Bastian Blank writes:
On Sun, Aug 24, 2008 at 09:43:38PM +0200, Florian Weimer wrote:
A security update for the OpenJDK 6 source base will require more than
60 hours of armel build time, and more than two weeks[1] on sparc for
openjdk-6 alone (don't know cocoa-oj6 yet).
The fastjar
found 496123 2.5.2-6
notfound 496123 2.5.2-11
thanks
no, 2.5.2-11 doesn't have libgpmg1 as a build dependency.
there is is still an unanswered question why this package is not moved
to testing. asked Neil at Debconf about Nico's comment on my request,
but apparently he never said anything like
Unfortunately there is a lot of packages with build dependencies on
openjdk-6-jdk directly, which is a bit unfortunate. Most likely all
packages build depending on openjdk-6-jdk should have RC bug reports
because they may contain 1.6 bytecode. The following should be checked
for the release:
-
proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a
copy of the openjdk-6 package with the cacao sources
included. Compared to openjdk-6 on architectures without the Hotspot
JIT support, cacao-oj6 (including a JIT) is a much faster JVM on the
architectures where it does build
please unblock python2.5; the last code update was made in 2.5.2-9,
uploaded before the freeze. -10 and -11 fix four CVE's.
please consider unblocking
python-defaults (2.5.2-2) unstable; urgency=low
* python: Provide python-plistlib.
* python-minimal: Provide python (suggested by Neil
please consider unblocking
sun-java6 (6-07-4) unstable; urgency=low
* Ignore errors when registering the jar binfmt. The alternative may
already be registered by another JVM (openjdk-6, cacao-oj6).
* Ignore errors when generating the java shared archive. Closes: #493085.
LP:
Please consider unblocking openjdk-6 6b11-6 for testing.
openjdk-6 (6b11-6) unstable; urgency=low
* Set minimum heap size independent of available memory (not only) for cacao
builds.
* Link the wrapper tools with -rdynamic for cacao builds.
* Update cacao based builds:
- Update cacao
rhino (1.7R1-2) unstable; urgency=low
* Build-depend on default-jdk instead of java-gcj-compat-dev.
* Depend on default-jre-headless | java*-runtime-headless as the
preferred alternative.
This lets openjdk-6-jre-headless and cacao-oj6-jre-headless be
installed without installing
The recent gcc-4.3_4.3.1-9 uploaded to testing should be a candidate
for testing (together with gcj-4.3_4.3.1-9). The testsuite doesn't
show regressions on the architectures where it is already built
(compared to the gcc-4.3_4.3.1-2 as found in testing). Lucas Nussbaum
did a rebuild of testing
Proposing a freeze exception for 2:0.95-2; adding a feature and fixing
a bug such that fastjar can be used to build openjdk-6/cacao-oj6,
reducing the openjdk build time (after an openjdk update) on alpha and
armel by about 25 cpu hours (less on other archs).
fastjar (2:0.95-2) unstable;
currently the -headless packages are not installable without having
the complete -jre packages installed on the system. the reason for
this is a dependency on the complete -jre packages in packages which
are dependencies of the -headless packages. The fix is to include an
alternative dependency on
Marc 'HE' Brockschmidt writes:
Piotr =?utf-8?Q?O=C5=BCarowski?= [EMAIL PROTECTED] writes:
I agree with Mikhail that all changes from 0.4.2 should appear in Lenny.
I'm attaching complete debdiff and a debdiff without documentation/tests
changes - the second one is not really that big and
So, we are late with OpenJDK for lenny. I still think lenny would
benefit from having OpenJDK. I'm proposing the following steps,
realizing that not all of them probably can be realized.
- The current 6b11-2 package is not yet ready for migration. We will
need a -3 upload which properly will
Please unblock:
build-essential, adding armel support
gcc-defaults, fixing a dangling symlink
gcc-3.3, re-adding libstdc++5 for powerpc
gdc-4.2, once it is built on all archs, fixing a RC report
I intend to ask for a unblock of gcc-4.3, once it is built on all
architectures. I would like
Philipp Kern writes:
On Sat, Jul 12, 2008 at 01:17:51PM +0200, Matthias Klose wrote:
This package builds binary-indep package(s), which place file in the
location
/usr/share/pycentral/package name. python-central now puts these files
into a package independent dirctory /usr/share
please migrate binutils 2.18.1~cvs20080103-7 to testing, fixing an
m68k bug, a bug for the cross build, and a build failure with gcc-4.3
on hppa.
thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
clone 482902 -1
reassign -1 general
severity -1 serious
thanks
Aurelien Jarno writes:
severity 482902 wishlist
tag 482902 + upstream
tag 482902 + wontfix
thanks
Matthias Klose a écrit :
Package: glibc
Version: 2.7-11
Severity: important
Please build libc6-hppa64 and libc6-hppa64
Please delay the xulrunner transition until the current gcj-4.2 and
gcj-4.3 are in testing, or else you couple the move of those packages
to testing to the xulrunner transition. At the same time please get
rid of the uninstallability issues of xul/iceape with every
subsubminor version upgrade as
Raphael Hertzog writes:
On Sat, 26 Apr 2008, Luk Claes wrote:
Here's what I would like to suggest as acceptable for lenny (and thus
1.14.19):
Freeze guidelines are not really up to discussion and I don't like that
maintainers of key packages send the signal that they don't care about
Goswin von Brederlow writes:
Andreas Barth [EMAIL PROTECTED] writes:
* Goswin von Brederlow ([EMAIL PROTECTED]) [080415 20:34]:
Description: The toolchain should be ready to handle libraries and
include files in the multiarch locations.
Bug-Url:
Grant Grundler writes:
On Sun, Apr 13, 2008 at 11:53:54PM +0200, Aurelien Jarno wrote:
...
FYI the glibc testsuite with gcc-4.3 on HPPA now gives the same results
than with gcc-4.2, except on one FPU test, due to a bug in the *glibc*.
So it *seems* HPPA is ready for gcc-4.3 by default.
Raphael Hertzog writes:
On Tue, 15 Apr 2008, Adeodato Sim
Ludovic Brenta writes:
Now that gnat-4.3 is on all architectures, I would like to upload
gcc-defaults 1.70 making it the default on alpha, mips and mipsel as
for all other archs.
As is, gcc-defaults cannot enter testing because on alpha, mips and
mipsel, if depends on gnat-4.2 which is not
David writes:
Hello,
gcc-3.4 has been upgraded in sid from 3.4.6-6 to 3.4.6-7. As a result, these
packages have broken dependencies.
no, these are not built anymore. please rebuild packages still
build-depending on g77 with gfortran.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL
Steve Langasek writes:
On Mon, Mar 24, 2008 at 12:23:34PM +0100, Christian Perrier wrote:
(CC'ing Riku and Matthias for the sake of it. No need to CC me on
replies, I read -release)
I was working on a possible NMU of atlas3 to fix its longstanding
debconf l10n issues.
Raphaël
THe _BEST_ example of that are buildd's that for now run etch (even
some sarge not so long time ago) and have a sid chroot to build. Not
keeping the CLD patch means that we break our own buildd infrastructure.
Yay.
No, this is not an argument. If a buildd is used to build packages for
more
IMO the current opinions Isn't it risky, I second that only look
for the risk of running an unfixed kernel (if at all), not of shipping
a compiler diverting in code generation from upstream.
I'm sure all of this is because of the CLD patch:
1,5M gcc-4.2-4.2.3/debian/patches
there's no
This will last up to the lenny release, and the toolchain is to be
freezed next week. So I don't ...
... think you'll have to support that patch actively for too long.
wrong, once released with the patch you'll get bug reports for the
compiler with the patch applied. For every report
For all ports besides alpha and hppa we plan to make GCC-4.3 the
default compilers for lenny.
- both alpha and hppa show regressions in the glibc testsuite when
built with GCC-4.3
- gcj has a lot of regressions in 4.3 on alpha (but doesn't work in
4.2 either).
- gij/gcj shows bus
Matthias Klose writes:
For all ports besides alpha and hppa we plan to make GCC-4.3 the
default compilers for lenny.
amd64 and i386 side note: the gcc-4.3 4.3.0-2 upload has a patch
reenabling the cld instruction when stringops are used; this patch is
neither in the gcc-4_3-branch
Carlos O'Donell writes:
- gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
Has gij/gcj ever worked on hppa-linux?
at least the gij/gcj before adding support for generics (1.5) did
work. Now that a working runtime is required for the compiler makes
things different. Please try to run
Carlos O'Donell writes:
On Sat, Mar 22, 2008 at 5:10 PM, Matthias Klose [EMAIL PROTECTED] wrote:
Carlos O'Donell writes:
- gij/gcj shows bus errors on hppa (either 4.2 or 4.3).
Has gij/gcj ever worked on hppa-linux?
at least the gij/gcj before adding support for generics
severity 380360 wishlist
thanks
so apparently this is a non-issue.
I do hope that a comment on irc We also need to have a chat at some
point about python-minimal in general is not the general style used
by the release team to start a discussion about the RC severity of bug
reports.
Matthias
Rene Engelhard wrote:
Marc 'HE' Brockschmidt wrote:
Rafael Laboissiere [EMAIL PROTECTED] writes:
The suitesparse transition is involving a quite large number of
packages. I
prepared an igloo URL [1] with the ones I think are involved. Please,
correct me if I am wrong. The
Philipp Kern writes:
On Wed, Mar 19, 2008 at 04:58:51PM +0100, Ondrej Certik wrote:
And python-scipy FTBFSes on mips...
python-scipy FTBFSes everywhere, not just mips. The problem is that
pycentral has moved some files recently. I am about to fix this this
evening.
Do you think that
Marc 'HE' Brockschmidt writes:
Matthias Klose [EMAIL PROTECTED] writes:
Yes. If outstanding issues are solved; people want make you believe
that NMUs are enough to complete the transition. What needs to be
done:
- Look for code which frees memory with PyMem_DEL, which
From: =?utf-8?q?Adri=C3=A1n_Ribao_Mart=C3=ADnez?= [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Debian 4.1 and Python 2.5
Date: Wed, 13 Feb 2008 21:40:26 +0100
Hello, I'd like to know if Python 2.5 will be the default version of python
in Debian 4.1.
Thank you.
Yes. If outstanding
Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.
- on arm, the bytecode compiler (ecj) doesn't produce correct code.
there is currently a workaround to build the package on arm using
byte-compiled code built on another architecture. Aurelian has
Philippe Cloutier writes:
Le January 31, 2008 08:39:52 pm Tom Marble, vous avez écrit :
[...]
Please consider the uploading of 1.5.0_14 as previously mentioned
as a timely reaction from the Java maintenance team.
Please make this fix available to etch users, not just sid users
(a timely
Package: general
Severity: important
There are no i386 and powerpc build daemons which run a 64bit kernel.
This means that packages requiring testsuites to be run for 64bit
won't run and won't be tested on a regular basis. If we do want to be
able to test packages build for a biarch setup we
Hi bgrptfoobar,
there are some propsals on irc, and Sun did become aware of
this. please be constructive.
Matthias
[EMAIL PROTECTED] writes:
Neither security team (doesn't support non-free) nor
package maintainer are fixing security bugs.
grave security-risk exists since 22.10.2007
Lucas Nussbaum writes:
On 24/01/08 at 01:42 +0100, Matthias Klose wrote:
I did upgrade all reports mentioned in [2] to severity `important'. My
current plan is to make gcc-4.3/g++-4.3 the default compiler once the
gcc-4_3-release branch is created, for all architectures where we had
Matthias Klose writes:
Newer GCC versions are more strict and usually cause build failures
for older or untouched code. A list of packages which currently fail
with GCC-4.2 can be found at [1], the same list for GCC-4.3 at [2].
To reduce the amount of build failures early and to ease
Ari Pollak writes:
Hi Release Team,
As far as i can tell, nobody has brought up upgrading the default
Python to 2.5 as a release goal. Joss outlined the steps necessary for
the transition here:
http://people.debian.org/~terpstra/message/20071005.180427.1dddb386.en.html
and the list of bugs
Glibc upstream announced recently that the glibc 2.7 will be tagged
and released very soon (probably on Oct 17[0]).
which toolchain versions are required as build dependencies?
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Hubert (Chan) Chathi writes:
Hi everyone,
I'd like to get the GNUstep transition done soon. Unless anyone
objects, I will upload the new GNUstep libraries into unstable soon.
(GNUstep in unstable is slightly broken already, because I mis-uploaded
gnustep-back...) Please let me know if
The i386 biarch toolchain is built as biarch toolchain; the value of
this is currently doubtful, because you only can use it in an i386
chroot on a machine running a 64bit kernel in the host system. With
newer compiler versions apparently more hacks are needed to even build
the biarch GCC, it
Bastian Blank writes:
On Sun, Sep 02, 2007 at 11:11:37PM +0200, Matthias Klose wrote:
Please could the
kernel team first check the possibility of such an kernel?
| linux-image-2.6.18-5-amd64 | 2.6.18.dfsg.1-13 |stable | amd64, i386
Newer GCC versions are more strict and usually cause build failures
for older or untouched code. A list of packages which currently fail
with GCC-4.2 can be found at [1], the same list for GCC-4.3 at [2].
To reduce the amount of build failures early and to ease transitions
we would like to keep
Joerg Jaspert writes:
Hi
Looks like a newbie who isnt able to manage his uploads in the right
order and unable to wait until a package left NEW.
Its YOUR mistake to upload before all needed packages are available.
no, I don't care anymore about delays in NEW after having to wait
about 12
Rene Engelhard writes:
Hi,
Matthias Klose wrote:
no, I don't care anymore about delays in NEW after having to wait
about 12 or 13 days for a new binary with the last gcj-4.2 upload. If
ftp-masters did make the decision that new binary packages have to
land in NEW, then they should
Package: db
Version: 4.6-1
Severity: important
Some issues with the package renamings:
- Changing the source name to an unversioned name will make it
impossible to build two sets of dbX.Y packages at the same time
(which is required for database updates between two versions). An
Steve Langasek writes:
On Wed, Jul 18, 2007 at 12:00:50PM +0200, Pierre Habouzit wrote:
I know I should provide a full binNMU list for python2.5 related
packages, but at least this one is needed to fix the RC bug #424441.
Probably other will follow.
Actually, the fix for #424441 is to
The plans for the GCC 4.2 transition were described in
http://lists.debian.org/debian-devel-announce/2007/06/msg8.html
Does any port still need to stick with GCC 4.1 for a while? Feedback
from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
objections against the transition.
Steve Langasek writes:
On Fri, Jul 20, 2007 at 12:05:54PM +0200, Bastian Blank wrote:
On Fri, Jul 20, 2007 at 11:51:47AM +0200, Mike Hommey wrote:
I have another objection. I'd like all mozilla security updates to be
built
before gcc 4.2 becomes the default, because they don't build
Mike Hommey writes:
On Wed, Jun 13, 2007 at 09:21:37PM +0200, Matthias Klose [EMAIL PROTECTED]
wrote:
Mike Hommey writes:
On Wed, Jun 13, 2007 at 09:02:45PM +0200, Matthias Klose [EMAIL
PROTECTED] wrote:
Mike Hommey writes:
On Wed, Jun 13, 2007 at 08:46:44PM +0200, Matthias
The current python2.4 and python2.5 package in testing and unstable
are ready for the transition to python 2.5 as the default python
version. However many packages still need updates for python 2.5,
either as a rebuild to build an extension module for 2.5, or to fix a
problem with python2.5. To
Please recheck with the recent gcc-snapshot 20070613 upload. We may
miss another backport from the trunk.
Side note: gcc-snapshot currently cannot be built due to the too
strict dependencies on the binary-indep packages; reported as #385793,
solved by the xulrunner maintainers. Please build the
Mike Hommey writes:
On Wed, Jun 13, 2007 at 08:46:44PM +0200, Matthias Klose [EMAIL PROTECTED]
wrote:
Please recheck with the recent gcc-snapshot 20070613 upload. We may
miss another backport from the trunk.
Side note: gcc-snapshot currently cannot be built due to the too
strict
Mike Hommey writes:
On Wed, Jun 13, 2007 at 09:02:45PM +0200, Matthias Klose [EMAIL PROTECTED]
wrote:
Mike Hommey writes:
On Wed, Jun 13, 2007 at 08:46:44PM +0200, Matthias Klose [EMAIL
PROTECTED] wrote:
Please recheck with the recent gcc-snapshot 20070613 upload. We may
miss
Julien Danjou writes
I'd like to begin a NMU campaign to help to fix this bugs.
Does it seems ok to NMU to delay/7 ?
I wouddn't mind, but please wait until new versions of gcc-4.2 and
gcc-snapshot are in unstable, so that people can easily test.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL
Martin Michlmayr writes:
* Falk Hueffner [EMAIL PROTECTED] [2007-04-13 19:42]:
gcc 4.2.0 will be released Real Soon Now (next few months). Changes
are not very disruptive, I suppose not very many packages will fail
to build. It will probably stabilize within a few months.
we will start
Stephen R Marenka writes:
Does anyone see any other toolchain issues (or other issues) besides
TLS in libc?
the m68k related patches in gcc-4.2 need to be updated, test results
for gcc-snapshot be submitted.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Mike Hommey writes:
On Thu, Mar 08, 2007 at 01:07:53PM -0800, Steve Langasek [EMAIL PROTECTED]
wrote:
tags 413964 sid
thanks
On Thu, Mar 08, 2007 at 01:37:49PM +0100, Mike Hommey wrote:
If the gcj plugin is making use of xpcom, it should require
xulrunner-xpcom
too.
See
Steve Langasek writes:
On Mon, Feb 12, 2007 at 02:02:29AM +0100, Matthias Klose wrote:
please consider ecj-bootstrap_3.2.1-6 for testing; for general usage
it's a no-change update, it refactores the main class and adds another
entry point (GCCMain), which allows bootstrapping of newer gcj
please consider gcc-4.0 (4.0.3ds1-9) for testing, making the
gcc-4.0-locales a binary-arch package which is only built for
hurd-i386. The only packages built from this source for release
architectures are gcc-4.0-base and libgcc2 on hppa.
Matthias
gcc-4.0 (4.0.3ds1-9) unstable; urgency=low
and -Wall not working). Taken from the rhug
repository.
-- Matthias Klose [EMAIL PROTECTED] Sat, 3 Feb 2007 14:16:47 +0100
ecj-bootstrap (3.2.1-5) unstable; urgency=low
* debian/control: Call it a standalone version, not a bootstrap
version. The package is used as the compiler in java
libgnucrypto-java (2.1.0-2) unstable; urgency=low
* Rebuild the database of security providers in the postrm
instead of the prerm.
bouncycastle (1.33-4) unstable; urgency=low
* Rebuild the database of security providers in the postrm,
not in the prerm.
-- Matthias Klose [EMAIL
Luk Claes writes:
Matthias Klose wrote:
please consider twisted and twisted-words for testing:
twisted (2.4.0-3) unstable; urgency=medium
Why was uscan.pl included in the source?
by accident, while debugging #351218 and #377518.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED
please consider twisted and twisted-words for testing:
twisted (2.4.0-3) unstable; urgency=medium
* twisted/python/versions.py: Update to work with subversion 1.4.
Closes: #405141.
* python-twisted-core: Don't suggest python-wxgtk2.4 anymore.
Closes: #391994.
twisted-words (0.4.0-2)
please consider python2.4 and python2.4-doc currently in unstable for
testing:
python2.4 (2.4.4-2) unstable; urgency=medium
* Cleanup build-conflicts. Closes: #394512.
* Match the smtplib documentation with the code and the docstring.
Closes: #333150.
* idle: Honor the Cancel action in
two NMUs, the packages are currently not in testing; no RC reports for
unstable:
dak (1.0-8.2) unstable; urgency=medium
* NMU
* Remove build dependency on versioned python version with an unversioned.
Closes: #403357.
* Convert to updated python policy, using python-central.
please consider numpy-1.0.1, plus depending packages for testing;
testing currently has the numpy-1.0 release candidate 1; between rc1
and rc2 upstream did make some ABI incompatible changes, see [1] and
[2]. The Debian Scipy Team would like to see the packages with the
final 1.0 ABI in testing.
Jerome Warnier writes:
Hope this is the right address to ask for this.
I'm wondering if bug #379288 (lapack3 still depends on libg2c0 while
gfortran is now the default fortran compiler) shouldn't be tagged as
release-critical?
No, we have a standard fortran77 compiler, called g77. gfortran
tags 406583 - sid
thanks
Philippe Cloutier writes:
Without a reply, I assume that #406583 is a serious eclipse bug, so
please un-unblock eclipse 3.2.1-4 until there's a reply.
huh? just untag the existing report.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Filipus Klutiero writes:
Did this hesitation include making sure that #401570/#406583 is not a
serious eclipse bug?
both bugs are reported against swt-gtk and still open; it's fixed in
the pkg-java svn. We (Michael Koch and me) did try several times to
convince the swt-gtk maintainer to build
Steve Langasek writes:
On Tue, Dec 19, 2006 at 02:16:54AM -0800, Peter Ronnquist wrote:
It seems like eclipse will not be part of the etch release. Is this
a mistake?
No, it is not; it's a direct consequence of the eclipse maintainers not
having a releasable package at the appropriate
please consider python-tz 2006p-0.1 for testing, updating the tz data
to the same version as in the tzdata package in testing.
thanks, Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Please consider the following packages for testing:
- gcc-defaults 1.50, fixing a dangling symlink, completing the
copyright file and adding a recommendation for gij.
- gjdoc 0.7.7-7
* Use back gcj-dbtool-4.1 and gij-wrapper-4.1 on arm (closes:
bug#400791). Thanks to Aurelien Jarno.
Thomas Bushnell BSG writes:
On Wed, 2006-12-20 at 19:51 -0800, Steve Langasek wrote:
On Tue, Dec 19, 2006 at 11:17:03AM -0800, Thomas Bushnell BSG wrote:
The python team has apparently decreed that python 2.3 will not be in
etch. This forces every package to use the new version. Surely
Marcus Better writes:
Andrew Haley wrote:
It's a good idea to remove generated javadoc and jar files and classes.
Very much so. Unless you build from source, you have no way to know
that the binaries correspond to that source code. You can't even
guarantee that you're not violating
Marcus Better writes:
Matthias Klose wrote:
Marcus Better writes:
instance we ship a lot of packages that build with Maven, but since we
don't have Maven in Debian, we use the included, pre-generated, Ant build
file instead. What should we do about those?
if these packages
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, testsuite shows
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?
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 build
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 2006-10
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 wondering whether
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 2006-10-24 with -13
and -17, the results can be found at [1]. The failures are detailed
below and supposed to be
Packages still depending on libgcc2, without depending on libg2c0
(can't do anything about libg2c0, built from gcc-3.4).
ale
aqsis
aqsis-libs
basilisk2
boson-base
cbedic
kfolding
ksocrat
libmyspell3c2
libosgcal0
libsimpledb2
netgen
parrot
spectemu-common
stella
[didn't see this email reaching the lists, sending it again]
Please consider moving the following packages to testing:
gcj-4.1
java-gcj-compat
gcc-defaults
ecj-bootstrap
gjdoc
The packages don't show regressions compared to the versions currently
in
With zope2.8 removed, the last package depending on python2.3 is gone,
so we are technically able to drop the support for python2.3. As
currently some packages have reverse dependencies on python2.3,
removing python2.3 without any other action, would open new RC reports
which doesn't seem to be
Please consider the final 2.4.4 release for etch; 2.4.4 is announced
as the last bug fix release for the 2.4 series of releases. changes
compared to the state in testing are attached.
Matthias
NEWS.diff
Description: Binary data
reopen 385793
severity 385793 important
thanks
Removed patches from NMUs by Matthias Klose, because work done on java
build in this release makes them unnecessary.
sorry, no. what you do here is to avoid the uninstallability for one
case (which however still exists), but the original problem
501 - 600 of 711 matches
Mail list logo
