Richard Braakman writes:
Package: bash (debian/main).
Maintainer: Matthias Klose [EMAIL PROTECTED]
57437 bash: Major readline problem
I've never been able to reproduce this one. On the other hand I don't
see any modifications in the package that could have fixed the bug ...
Simply close
-BEGIN PGP SIGNED MESSAGE-
Hi all,
For etch we will update the toolchain (glibc, binutils,
linux-kernel-headers, gcc) again. Some updates look easy, other will
have a bigger impact on packages. One aspect of the toolchain update
is the change of the C++ ABI from version 1 (102) to
-BEGIN PGP SIGNED MESSAGE-
With today's dinstall run, new gcc/g++ packages are entering the
archives and GCC 4.0 is the default gcc/g++. Starting from now, please
DON'T upload any C++ code, which build-depends on a library written in
C++ that is not yet converted to the new C++ ABI.
Robert Woodcock writes:
My personal opinion on this is that p2c in it's current state should be
removed from hamm.
However, something usable should go in slink. (p2c is still used by the
occasional person, I had someone ask me on #debian where libp2c1 was...).
Please comment.
Although
Maybe the subject is a bit harsh, but currently users trying to
install Debian on a Notebook face more problems than users installing
it on a desktop computer. Compared with other Linux distributions
Debian fails to install on some Notebooks (for example IBM Thinkpad
770) or requires handcrafted
I am looking for an i386 binutils package version 2.9.1.0.16-1 or
earlier. Please let me know if you still have such a package (binary
or source) or send me a location where I can find it. With the new
package I get warnings for every Objective-C program.
/usr/bin/ld: warning: type and size of
Ossama Othman writes:
Hi,
I'm not sure what it is, but below are the contents of
'/usr/lib/gcc-lib/i486-linux/egcs-2.91.60/libgcc.map' on my potato system.
I was also missing this file when I did a new potato installation. I had
to copy it from other potato system to make things work
Is it currently possible to access the unstable non-US section with
apt-get? Or is the reorganisation not finished? Currently neither of
the following lines work:
deb http://non-us.debian.org/debian-non-US unstable non-US
deb http://non-us.debian.org/debian unstable non-US
deb
Michael Alan Dorman writes:
David N. Welton [EMAIL PROTECTED] writes:
Hi, while working on the ARM port, I've begun to become frustrated
with the IMO, not entirely necessary diversity in our rules files.
I agree with this. And I think debhelper is of enourmous value. I
have been
Ben Collins writes:
On Tue, Sep 21, 1999 at 10:19:48AM +, Dale Scheetz wrote:
OK, I have recovered to a slink system, and I'm ready to upgrade it to
potato, which raises the above question. There are two gcc versions
available in the archives. Which one is being used to build the
Dale Scheetz writes:
On 21 Sep 1999, Ruud de Rooij wrote:
Dale Scheetz [EMAIL PROTECTED] writes:
So, what, if anything, is being built with egcs?
Nothing, since egcs does not exist in the distribution anymore.
Well, egcs 1.1.2-2 is still in my source archives, so
Joel Klecker writes:
At 20:00 +0200 1999-09-21, Matthias Klose wrote:
The egcs packages are used to build the libstdc++2.8 and libstdc++2.9
packages and therefore are still in potato. For the release they have
to be modified to build the runtime libraries only (if you want to
step
BugScan reporter writes:
Bug stamp-out list for Sep 24 00:06 (CST)
Total number of release-critical bugs: 263
Number that will disappear after removing packages marked [REMOVE]: 12
Package: libg++272-dev (main)
Maintainer: joost witteveen [EMAIL PROTECTED]
42443 libg++272-dev
Marcel Harkema writes:
Hi,
I am going to rename the poc (portable object compiler) package to objc if
no-one objects. The upstream author requested this. Also, libgc4 (boehm
gc) support is dropped. A new additional package will be introduced with
libgc5 support.
We do
Edward Betts writes:
It is the same for other things like list server. I used berolist to start
with, and it is terrible. Then I tried smartlist, and it was great. The
problem is there are so many to look at.
don't know the two, mailman is another (for the user easy to use) alternative.
Package: blas-dev
Package: lapack-dev
The files /usr/lib/libblas.{a,so} are in both packages. Since
lapack-dev was there first, blas1-dev should not use this name. On the
other hand, I like the separation of blas in a separate package. The
lapack maintainer doesn't care about the lapack packages
Dave Carrigan writes:
I am quite sure that there are Debian *users* out there that have legacy
code that only builds under gcc 2.95 (or more likely g++ 2.95) and they
haven't ported it to a newer C compiler because there is no business
case for it.
Removing a package simply because the
Heiko Müller writes:
We found that gcc-2.95 -Os produces object code of acceptable quality
within reasonable compilation times. gcc =3 is less efficient w.r.t.
please be more precise. Debian currently uses 4.0, and has a 4.1
prerelease in the archives (gcc-snapshot). such regressions are best
Steve M. Robbins writes:
Howdy,
On Mon, Dec 12, 2005 at 02:18:29AM +0100, Matthias Klose wrote:
We will get rid of g++-3.3 for the etch release and remove the
g++-3.3 package.
On Mon, Dec 12, 2005 at 12:54:22AM +0100, Matthias Klose wrote:
We would like to get rid of g++-3.4
Anthony Towns writes:
On Mon, Jan 16, 2006 at 09:45:29PM -0500, Eric Cooper wrote:
I saw today that the python-minimal package in unstable is tagged as
Essential (and currently pulls in python2.3). According to policy,
this is supposed to happen only after discussion on debian-devel and
Joe Wreschnig writes:
On Tue, 2006-01-17 at 09:32 -0800, Matt Zimmerman wrote:
On Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote:
You're underestimating the grave consequences of losing 25MB off every
memory stick and virtual machine.
python-minimal is about two
Joe Wreschnig writes:
On Thu, 2006-01-19 at 12:12 +1000, Anthony Towns wrote:
I don't know what's actually in (or more importantly not in)
python2.4-minimal though.
I'm eyeballing right now. Things that jump out at me:
* No character encoding, translation, or locale handling.
* A
Joey Hess writes:
Colin Watson wrote:
FWIW the relevant design docs from when this was done in Ubuntu are
here:
https://wiki.ubuntu.com/EssentialPython (requirements)
https://wiki.ubuntu.com/PythonInEssential (details)
The rationale for the set of included modules is in the
Joey Hess writes:
Debian GCC Maintainers debian-gcc@lists.debian.org
gcc-snapshot
no. must be a false positive.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Florian Weimer writes:
* Matt Zimmerman:
One of the appealing things about the Python language is their batteries
included philosophy: users can assume that the standard library is
available, documentation and examples are written to the full API, etc.
which batteries do you mean? my
Richard B. Kreckel writes:
Martin Michlmayr wrote:
Your package fails to build with G++ 4.1. I'm filing this bug as
important for now, but when 4.1 will be the default compiler in
unstable (probably in a few weeks) I'll upgrade this to serious.
Jeez, according to my available list,
Branden Robinson writes:
If I'm wrong, fine. Matthias sent me a mail that said this problem should
be fixed with today's dinstall run.
I said, that I uploaded new packages. But with new package names ...
Let's see when they arrive in testing.
Adam Heath writes:
Bdale hates dbs, doesn't know what it is, so I don't trust his assement of
the
issue. I never said glibc nor gcc use dbs. They use a system like dbs, one
I
feel is incorrect(each .dpatch system includes code to apply the patch,
which,
I feel, is code
Package: wnpp
The GNUstep libraires (together with gstep-extensions and
gstep-guile). See http://www.gnustep.org/ for more information.
We now have Build-Depends for source packages. What I do miss are
Source-Dependencies for Source-packages. Problem: gcc takes long to
build and test on some architectures. Adding cross compiler support
would increase the build time for some architectures to some cpu days
and disk requirements up
As David Maslen pointed out in
http://lists.debian.org/debian-python/2001/debian-python-200109/msg0.html
Debian doesn't have yet python-2.1 in it's distro, although released
in June (2.1) and July (2.1.1). Gregor (the python-1.5 and python-2.0
maintainer) has put experimental packages at
Matt Zimmerman writes:
On Wed, Apr 09, 2003 at 01:40:38PM +0100, Wookey wrote:
This will effectively update and move the emdebian packages to be available
was part of Debian proper where they are a lot more useful. I'll be posting
the patch and compile option sets to debian-embedded and
Arnd Bergmann writes:
with the packages I have uploaded to http://www.arndb.de/debian/.
[...]
There is a lot that can be done before the hardware is available,
so if there is enough interest, we should start a coordinated
effort soon.
yes, please submit bug reports to glibc, binutils and gcc
Matthias Urlichs writes:
Maybe it's time to force gcc-3.2 into testing..?
No, it should go in after binutils gets into testing.
Anthony Towns writes:
Yes; you were. I'm focussing on gcc and perl and such things at the
moment, and as of yet no one else is really able to do anything about this
stuff while I'm busy; hopefully both those things will change soon enough.
and maybe python ...
AFAICS there are two issues:
-
Should Debian further support the i386 target, or make (at least i486)
the default for code generation? Asking because I'm unsure how to
provide the libstdc++5 package.
- In gcc-3.2, the libstdc++ atomicity implementation uses ix86 (=4)
specific code. This was reported by two users (#184446,
A fixed libstdc++ package (0pre7) has been uploaded to incoming. You
can get it from
http://ftp-master.debian.org/~doko/gcc-3.3/
for i386 as well. Another workaround is to keep or reinstall the 0pre5
package (it's currently in sarge/testing).
Sorry for messing up unstable, I did the
James Troup writes:
Matthias Klose [EMAIL PROTECTED] writes:
Btw, looking at the reports, I see 30 submitted from i386 architectures,
one from a powerpc machine, none from other architectures, although all
architectures are affected. Conclusions? ;-)
Well, duh, let's see. Several
Hamish Moffatt writes:
On Sun, Apr 27, 2003 at 04:32:37PM -0400, Nathanael Nerode wrote:
This is an attempt to summarize some points.
1. Why do we have a problem, other than performance issues?
* To maintain binary compatibility with other distributions for C++
packages, Debian needs
Neil Roeth writes:
Nice summary.
* Drop i386 support mostly. 'i386' architecture becomes 'i486'.
Start a 'Debian-real-i386' subproject, with a 'real-i386' architecture,
but don't require that any packages build on it in order to go into
testing or to release Debian; it would be a bonus
[CC to debian-devel, did anybody see this behaviour on an update?]
Luke Kenneth Casson Leighton writes:
On Mon, May 19, 2003 at 04:52:51PM +0200, Matthias Klose wrote:
Never seen this upgrade behaviour. Was libgcc1 installed before
libstdc++5? If not, please could you explictely install
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
the C++ ABI transition
Daniel Stone writes:
On Mon, May 26, 2003 at 01:54:57PM -0500, Branden Robinson wrote:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
against, say, libstdc++3 to accidentally sneak in and start regressing
Branden Robinson writes:
On Mon, May 26, 2003 at 10:22:41PM +0200, Matthias Klose wrote:
Branden Robinson writes:
Questions for debian-{x,devel}:
1) Should libstdc++-dev dependencies be made artificially strict in
packages destined for sid so that it's harder for packages built
Package: general
Severity: serious
Tags: sarge, sid
[please don't reassign to any gcc/libstdc++ package]
Nathanel's summary:
http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg02112.html
A list of proposals what to do:
Joshua Kwan writes:
However, python2.3 is not the default yet. If you need profusely
bleeding edge stuff all the time, please don't use Debian, or do the
work yourself and keep an eye on experimental. Debian is about being
moderately stable at all times.
simply install python2.3 and continue
Rene Engelhard writes:
You shouldn't forget that gcc 3.2 is still default on sparc...
s/still/again/ now, s/3.2/3.3/ soon.
Jamin W. Collins writes:
On Tue, Jul 29, 2003 at 06:28:42PM +0100, Andrew Suffield wrote:
I think he just wants them kept open until the old gcc versions get
removed from the archive. That does make a certain amount of sense.
Could tag them with the release name that affected release
Andrew Lau writes:
On Tue, Jul 29, 2003 at 05:52:07PM +0200, Erich Schubert wrote:
This is just a small helper, some real integration of debbugs with
bugzilla would be cool, like debbugs subscribing to the upstream bug
and automatically tagging the bug pending when fixed upstream?
Adam Heath writes:
On Tue, 29 Jul 2003, Matthias Klose wrote:
well, you can still get the version, when the bug was closed from the
changelog. If we do not close the bug, nobody will get a note that the
bug has been fixed (in the new default version). Bugs reported for 3.2
have been
Last weekend, python 2.3 was released. For an overview see
http://python.org/2.3/highlights.html
With the next python2.3 upload, python2.3 becomes the default python
version. Some packages become uninstallable until they are converted
to the new version. In this time you should not update
Steve Lamb writes:
On Wed, 6 Aug 2003 16:22:51 -0400
Matt Zimmerman [EMAIL PROTECTED] wrote:
A more useful question would be, why does gcc-2.95 depend on gcc? The
answer, as usual, you could have found for yourself in the changelog:
gcc-2.95 (2.95.3.ds3-5) testing unstable; urgency=low
Joey Hess writes:
Josip Rodin wrote:
Am I the only one who has a disgusting reminiscence of netscape*.* packages
every time python* is mentioned? :P
Actually I'm more reminded of the perl* packages and the complete mess
that followed. And I keep expecting to see the same set of problems
Fumitoshi UKAI writes:
Hi, ruby package maintainers!
I've upload new ruby-defaults that make ruby 1.8.0 the debault version of
ruby.
I contains some new binary package so it takes time to get into unstable.
You can get the new ruby-defaults from
deb
Björn Stenberg writes:
2) How is meta package versioning handled? The gcc-defaults package, version
1.9, is the only package providing the gcc binary (without -version suffix) of
which many packages require version = 2.95.
gcc-defaults implements it's own version handling. see the source.
I'm totally swamped in work even though I haven't started learning for
the next round of exams yet, so I'd like to give away my packages:
- python-imaging(*)
Simon
(*) Gerhard H=C3=83=E2=82=ACring expressed interest, but I have no definiti=
ve word.
If Gerhard doesn't take it,
Please STOP resetting the forwarded address and revert the changes you
already did. We do loose information in the upstream BTS: it becomes
more tedious to track the reverse direction (upstream - Debian),
unless you add information to the upstream bug report as well.
I.e. you have to search now
about it.
Matthias Klose [EMAIL PROTECTED]
python-netcdf
python-scientific
same thing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reopen 369257
severity 369257 serious
thanks
Don Armstrong writes:
reassign 369257 general
severity 369257 normal
thanks
On Sun, 28 May 2006, Matthias Klose wrote:
this bug is fixed for 4.1; with these changes you invalidate the
information kept in the Debian BTS. Please fix it, or stop
Don Armstrong writes:
On Mon, 29 May 2006, Matthias Klose wrote:
Don Armstrong writes:
On Sun, 28 May 2006, Matthias Klose wrote:
this bug is fixed for 4.1; with these changes you invalidate the
information kept in the Debian BTS. Please fix it, or stop it.
This has nothing
Debian Bug Tracking System writes:
Le Lun 29 Mai 2006 03:40, Matthias Klose a =E9crit :
the only thing that is correct. is the syntax. everything else is
wrong. the messages should have been generated for gcc-snapshot (if
at all), but not for 4.1.
debian bug http://bugs.debian.org/cgi
* python-imaging
(easy pickings)
as former maintainer of this package and having used that as an
example package, I'd like to maintain this one again.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Steve Langasek writes:
On Sun, Jun 04, 2006 at 09:17:30PM +0200, Martin Michlmayr wrote:
I found one serious bug in 4.1.1 though (#370308) which needs to be
fixed before 4.1 can be the default (since it produces a bogus error
on some Perl headers which get included by many packages).
Martin Michlmayr writes:
* Andreas Barth [EMAIL PROTECTED] [2006-06-04 21:01]:
As we are below the 20 packages count if bug #366820 is correct (and
Martin just confirmed the number), it is ok to do the switch now.
Martin, can you please also mark these bugs as serious now (as
they're
martin f krafft writes:
also sprach Matthias Klose [EMAIL PROTECTED] [2006.06.13.0149 +0200]:
- The current pythonX.Y-foo packages having modules in the python
library path are collapsed into one package python-foo. Binary
independent modules are made available for the python
Mike Hommey writes:
Anyways, there would be a problem with python native extensions linked
against libpython. They would get the shlib dependencies on python2.x
packages.
So at least we can find these and fix them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Mike Hommey writes:
On Tue, Jun 13, 2006 at 10:09:15AM +0200, Matthias Klose [EMAIL PROTECTED]
wrote:
Mike Hommey writes:
Anyways, there would be a problem with python native extensions linked
against libpython. They would get the shlib dependencies on python2.x
packages.
So
Mike Hommey writes:
On Tue, Jun 13, 2006 at 10:09:15AM +0200, Matthias Klose [EMAIL PROTECTED]
wrote:
Mike Hommey writes:
Anyways, there would be a problem with python native extensions linked
against libpython. They would get the shlib dependencies on python2.x
packages.
So
python2.3/python2.4 fails to install after today's dinstall run, due
to a brown paper bag bug on my side. Please either set python-central
on hold (0.4.15) or install 0.4.17 from incoming
http://incoming.debian.org/python-central_0.4.17_all.deb Thanks to
Kurt Roeckx for the pointer. Sorry for
well, there's curently only one person spreading lies and fud about
python packaging, so please don't talk about lies as well. I'm still
testing uprades and fixing upgrade issues. experimental has a
python-defaults pointing to 2.4, so you can prepare your package and
upload it to experimental.
Yotam Rubin writes:
Greetings,
The last libsafe upload has been over a year ago. Since then, libsafe
has accumulated a large number of bugs. The current Debian release doesn't
seem to be very effective. I've packaged the latest libsafe and made it
available at:
[CC to debian-devel, asking if report #126567 is reproduceable]
Bill Gribble writes:
I simply cannot reproduce the behaviour you describe.
Well, why don't you describe for me what you have tried to do. Simply
cannot reproduce could mean just about anything, including that you
haven't
Adam Heath writes:
On 27 Dec 2001, Tollef Fog Heen wrote:
* Adam Heath
| dbs(doogie build system, debian build system)
|
| See autofs, apache, x(contains a pre-alpha version of dbs).
|
| Do NOT see glibc, gcc. Those use dpatch, which was around before dbs.
Dbs
| has a
Ben Collins writes:
On Fri, Jan 11, 2002 at 11:15:07PM +0100, Torsten Landschoff wrote:
On Fri, Jan 11, 2002 at 04:05:02PM -0500, Ben Collins wrote:
binary of the newest package of each build dep available in unstable
before building the package. If that is not the case I would have to
Laurence J. Lane writes:
iptables 1.2.6a-3 is being held back because it's out of date
on m68k.
http://ftp-master.debian.org/testing/update_excuses.html.gz#iptables
iptables_1.2.6a-3_m68k was built, according to the buildd log,
but package does not appear to have been uploaded.
Who
King Leo (Martin Oberzalek) writes:
Hello,
it's not possible linking a C++ library compiled with g++-2.9x to a C++
application compiled with g++-3.0.
We all no the reasons...
My question is how I should handle this, on debian distributions that
are based on gcc-2.9x?
use only
Colin Watson writes:
On Sun, Apr 07, 2002 at 11:21:14AM +0200, Karsten Merker wrote:
On Sat, Apr 06, 2002 at 09:56:12PM -0600, Colin Watson wrote:
The build on sparc is due to something else, don't have time to
investigate that right now; mips doesn't seem to have even attempted the
On Aug 14, Laura Creighton wrote:
The new Python Business Forum (www.python-in-business.com) is
what is this? The link is dead. Is this the former PSA?
Guido van Rossum writes:
Now, if 2.3 won't be stable until well into next year (as opposed to
the schedule in PEP 283), then we may want
Steve Langasek writes:
* It is assumed that for the vast majority of C++ libs we ship, upstream
has already transitioned to using the GCC 3.2 ABI, therefore our
current packages are already binary-incompatible with the rest of the
world. (ok)
right. One reason for the 3.2 release was a
I'm planning to make python2.2 the python default version for unstable
next week (uploading the packages on 2002-08-28). Preliminary packages
can be found at
http://ftp-master.debian.org/~doko/python/
Please send packaging problems with the packages to debian-python.
When preparing
Mark Brown writes:
On Sat, Aug 24, 2002 at 12:21:41AM +1000, Donovan Baarda wrote:
I would say yes. We need 2.1 in sarge at least, so that each generation of
Debian still has support for the previous generation's standard python.
Why? If you're upgrading then you can always leave the
Anthony Towns writes:
On Fri, Aug 23, 2002 at 11:33:10PM +1000, Donovan Baarda wrote:
On Fri, Aug 23, 2002 at 01:48:36PM +0200, Matthias Klose wrote:
I'm planning to make python2.2 the python default version for unstable
next week (uploading the packages on 2002-08-28). Preliminary
Package: wnpp
Severity: wishlist
Although not a new package (tix4.1 is in Debian), the 4.1 version is a
bit rotten, so that it doesn't work with newer packages (visual-tcl
and PyTix need 8.1). 8.1 was released 20 months ago and should be
mature. Packages can be found at
Package: wnpp
Severity: wishlist
Installer package for F-Prot Antivirus(tm)
F-Prot(tm) is a tool for scanning individual files or directory trees
for viruses.
The license for F-Prot Linux for Small Business is without charge
for personal users, when used on personal workstations.
The
Maybe an aspirin could help as well ;-) Maybe somebody should make two
NMUs now ...
Ministero della Cultura Popolare writes:
Package: python2.2
Version: 2.2.2-2
Severity: minor
Reading the name of the package followed by the version number confuses
me. As you can see:
Chris Leishman writes:
Hi all,
The recently released version of libxml++ (0.16.0) includes doxygen
documentation produced from the code (to html), so I created a -doc
package for this. However, doxygen wanted to use dot to create some
of the images for the documentation. Problem with that
Brian May writes:
Matthias == Matthias Klose [EMAIL PROTECTED] writes:
Matthias - Rebuild C++ applications, which do not depend on any
Matthias other C++ library besides libstdc++.
Matthias - Rename and rebuild C++ libraries, which do not depend
Matthias on any other C
Loïc Minier writes:
Hi,
On Thu, Jul 07, 2005, Steve Langasek wrote:
A package which I am about to sponsor (plotutils) has CFLAGS += -mieee
for alpha. Does the above mean it is ok to remove that now?
* Apply revised patch to make -mieee the default on alpha-linux,
and
NMU's for all C++ libraries, not depending on any other C++ library
are now allowed.
Matthias
Matthias Klose writes:
For the time until all C++ libraries are converted, we use the
following NMU policy for uploads related to the C++ ABI change:
- - 0-day NMU's allowed for all C++ library
Robert Jordens writes:
Hello!
[Tue, 05 Jul 2005] Matthias Klose wrote:
- - 5-day NMU for all C++ library packages, which can be converted, but
are left alone.
i.e. if libfoo1++ depends on libbar1++, libfoo1++ can be NMU'ed 5 days
after libbar1++ is uploaded.
Since NMUs
Ralf Treinen writes:
I have a (probably very stupid) question:
On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
If one of your packages needs to be transitioned, DO NOT upload it before
the C++ libraries it depends on have successfully made the transition.
Is there an
David Pashley writes:
On Jul 16, 2005 at 14:27, Stephen Gran praised the llamas by saying:
This one time, at band camp, Ralf Treinen said:
I have a (probably very stupid) question:
On Sat, Jul 16, 2005 at 03:09:18AM -0700, Steve Langasek wrote:
If one of your packages needs to
Steve Langasek writes:
librudiments0
already done. bug report filed to remove the source package from
unstable.
maxdb-7.5.00
not critical, no dependent packages. the maintainer works on getting
the package compiled with gcc-4.0
stlport4.6
already done.
Matthias
--
To UNSUBSCRIBE,
Florian Weimer writes:
Something strange has happened to the bash version in sarge:
version inconsistency between source and binary package:
source package: bash, version: 2.05b-2-26
binary package: bash, version: 2.05b-26
If I read policy correctly, the upstream version is 2.05b-2.
Kevin B. McCarty writes:
Gfortran claims not to be completely ready for use as a g77 replacement
yet (and someone who has attempted to compile Cernlib with it reports a
large number of problems yet). But eventually that day will come... we
should have some transition plan in mind by then.
Package: general
override change are not announced to the package maintainers, _after_
a package is uploaded.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Nathanael Nerode writes:
And now, a new gcc-4.0 bumped the shlibdeps for libstdc++ -- and worse,
depends on new binutils and new glibc. This will undoubtedly mean that
either
forced package breakages, significant numbers of package removals, or months
more of waiting will be needed.
the
) [EMAIL PROTECTED]
aiksaurus
enchant
libwpd
zipios++
Matt Flax [EMAIL PROTECTED]
libgig
Matthias Klose [EMAIL PROTECTED]
rapidsvn
Matthias Urlichs [EMAIL PROTECTED]
festival
Mattias Nordstrom [EMAIL PROTECTED]
libnzb
Micha Lenk
The current gcc and egcs objc compilers doesn't translate the gstep-*
packages. However newer snapshot versions of egcs doesn't have the bug
anymore. Is the following proposal a solution for the problem?
- from the egcs package, a new package gobjc, which contains only the
(not working) ObjC
blt8.0-unoff is a blt version compatible with tk8.0 based on
blt2.1.
from the blt README:
There's a story behind these unofficial releases of BLT: shortly after
George released BLT 2.1 back in April '96, he disappeared from the scene,
i.e. he didn't show up in comp.lang.tcl anymore, and he also
1 - 100 of 8080 matches
Mail list logo
