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.
Thi
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
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
http://li
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 bu
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:
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 rel
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 libsigc
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
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 b
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
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 fi
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
>> 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
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 i
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?
Reg
>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
i
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
ha
17 matches
Mail list logo
