Thomas Bushnell BSG wrote:
Please see http://bugs.debian.org/321435.
This bug is that gs-gpl fails to work on s390. I recall just seeing
a principal s390 developers say he was no longer doing the Debian s390
port. I don't know what effect this has on the bug.
This bug is blocking a number of
Gerhard Tonn wrote:
Thomas Bushnell BSG wrote:
Please see http://bugs.debian.org/321435.
This bug is that gs-gpl fails to work on s390. I recall just seeing
a principal s390 developers say he was no longer doing the Debian s390
port. I don't know what effect this has on the bug.
This bug
Due to lack of time I am not able to do the s390 porting work anymore. I
am looking for someone
who is interested to take over the s390 port. This includes the
administration of the buildd servers,
analyzing build failures and requalification of the s390 port for the
etch release, see
On Sunday 25 August 2002 22:00, you wrote:
Gerhard Tonn wrote:
As I have told in another thread, I am currently rebuilding all packages
depending on c++ on s390. All packages have been touched now. The results
are:
406 packages have been built successfully
222 packages depend on other
On Sunday 25 August 2002 22:00, you wrote:
The build logs of the packages can be found at
http://people.debian.org/~gt/gcc-3.2_transition
I hate to say, but the list of failed packages needs to get
investigated a little bit, since not all failures seem to be GCC 3.2
and syntax related:
On Monday 26 August 2002 18:55, you wrote:
On Mon, 26 Aug 2002, Gerhard Tonn wrote:
apt: failed with debian/rules:20: build/environment.mak: No such file
or directory gg: failed with /usr/bin/ld: cannot find -ljpeg
hylafax: failed because textfmt wasn't built[1]
latte: failed
As I have told in another thread, I am currently rebuilding all packages
depending on c++ on s390. All packages have been touched now. The results are:
406 packages have been built successfully
222 packages depend on other packages built with gcc-3.2
90 on qt libraries
12 on
On Saturday 17 August 2002 19:28, you wrote:
I am currently doing this experiment on s390 without uploading of course. I
have grepped the build logs of about 4000 packages that I have access to
for g++|c++ and about 900 packages qualified. I am currently rebuilding
these packages with gcc-3.2
On Friday 16 August 2002 20:26, you wrote:
On Friday 16 August 2002 15:51, Matthew Wilcox wrote:
If it is done by the platform porters a special build server has to be
setup for each platform recompiling all packages depending on c++. A wanna
build feature creating packages for NMUs can be
On Friday 16 August 2002 15:51, Matthew Wilcox wrote:
I got sick of listening to people discuss the gcc 3.2 transition in an
uninformed manner. So I've whipped up a transition plan which will
hopefully get us from A to B without causing too much pain. Haha.
I'm entirely fallible and I don't
Hi,
I have changed my mind and will write semi-automatically a bug report for
each of the packages with severity grave.
I am currently rebuilding the latest version of each of the packages, so that
a build log for s390 will be available at http://buildd.debian.org/ . I will
then check that the
On Saturday 29 December 2001 11:59, you wrote:
* Gerhard Tonn [EMAIL PROTECTED] [20011229 11:23]:
I have changed my mind and will write semi-automatically a bug
report for each of the packages with severity grave.
Don't do this.
That's fine with me. I don't see what it helps though except
Hi,
I had recently a runtime problem on s390 with a package that compiled fine.
After a while I figured out that it was caused by the fact that the package
owner assumes that a char is signed per default. This is _not_ true on
arm
powerpc
s390
Since in some cases this wrong assumption results
A solution is to declare the datatype explicitly as signed char or compile
using the option -fsigned-char.
Compiling with -fsigned-char, though it works, is not the right
solution. It's better to fix the bug in the code.
I agree. As soon as a source is compiled with -fsigned-char and
Which packages are these? It's probably a bug in the package source, in
that it's coded in such a way that bin-nmu's aren't possible. There're
a bunch of packages like that. (ie, a Depends: otherpkg (= myver) line)
In my case it's esound-common, which in turn makes the entire gnome tree not
On Saturday 15 September 2001 07:29, you wrote:
In my case it's esound-common, which in turn makes the entire gnome tree
not installable.
Most of the esound packages have a 'esound-common (= ${Source-Version})'
dependency in debian/control. Is there any generic solution for the problem?
Hi,
I have done some binary NMUs for s390 in order to fix bugs caused by previous
compiler bugs.
I experience now the following problem:
The architecture dependent package created by the NMU have a 0.1 version, the
architecture independent package compiled from the same source package don't
17 matches
Mail list logo
