block 730157 by 718047
thanks
This is likely bug#718047. Removing the --as-needed switch from the ld
invoke is the tentative workaround for that.
Regards
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Quoting Niko Tyni nt...@debian.org:
Thanks for trying. Do you have a chance to test the theory that this
somehow depends on the kernel? A squeeze system with a sid chroot
should work for that.
I tested building of the libapache2-mod-perl2 package on a sid chroot
on a Debian squeeze (ia64,
Quoting Niko Tyni nt...@debian.org:
Cc'ing the debian-ia64 list. Can anybody reproduce the sid build failure
of libapache2-mod-perl2 2.0.8+httpd24-r1449661-4 ? What's in
t/logs/error_log?
I'm using Debian unstable on ia64.
I could not reproduce the problem; I was able to build the
tags 711107 - help
tags 711107 + patch
thanks
Emilio Pozuelo Monfortpo...@debian.org wrote:
What happens if you do `make check' or `fakeroot make check' again?
make check
will set Xvfb differently than xvfb-run.
I didn't check that out. I assume the test will always fail with 'make
I'm using Debian unstable on ia64.
I built the gtk+3.0 package twice; the test always fails as on the
ia64 buildd:
/usr/bin/make check-local
make[4]: Entering directory
`/home/stephan/gtkplus2/gtk+3.0-3.8.2/debian/build/shared/tests/a11y'
TEST: accessibility-dump... (pid=3867)
PASS:
Why you don't migrate iceweasel 10.0.12esr-1+nmu1 to testing ;-) ?
It would also please some mipsel users (Bug#680704).
Kind regards
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
notfound 642750 src:linux/3.5.5-1~experimental.1
notfixed 642750 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 642750 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 642750 3.2.35-2
thanks
The problem with GDB does no longer occur with Kernel 3.2.35-2. I
don't have a clue why.
I'm sorry. Wrong bug number.
Please, ignore my message.
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
notfound 691576 src:linux/3.5.5-1~experimental.1
notfixed 691576 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 691576 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 691576 3.2.35-2
thanks
The problem with GDB does no longer occur with Kernel 3.2.35-2. I
don't have a clue why.
Package: xserver-xorg-video-ati
Version: 1:6.14.4-6
Severity: serious
Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
Graphics: build-in ATI Rage XL
01:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI Rage XL [1002:4752] (rev 27)
Package: xserver-xorg-video-all
Version: 1:7.7+1
Severity: serious
The xserver-xorg-video-all package doesn't install the following xorg
video drivers on ia64:
xserver-xorg-video-apm
xserver-xorg-video-ark
xserver-xorg-video-chips
xserver-xorg-video-cirrus
xserver-xorg-video-i128
Package: libwebkitgtk-3.0-0
Version: 1.8.1-3.3
Severity: serious
Tags: patch
Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
I realized this bug while working on bug#642750.
Some assertions fail on the debug build of webkit:
at
Package: epiphany-browser
Version: 3.4.2-2
Severity: serious
Tags: patch
Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
While working on bug#642750, I realized a failing assertion in the
epiphany browser:
at lib/history/ephy-history-service.c:363
Package: epiphany-browser
Version: 3.4.2-2
Severity: serious
Please could you enable seed again on ia64 when seed does no longer
FTBFS and works (bug#582774) due to the fixes for webkitgtk package on
ia64 (bug#642750, bug#694971, bug#697172).
Please remember that the epiphany-browser
I filed bug#697172 for yet another bug of webkit.
Furthermore, bug#697173 for a bug in the epiphany-browser package.
Furthermore, bug#697174 in order to enable seed on ia64.
I also realized that gnash seems to crash epiphany sometimes. I
browsed through the Debian bug reports and found ones
I can provide the built debs for ia64 (150MB) after making some room
for it on my webspace:
http://fs-driver.org/debian-ia64/iceweasel-10.0.11esr-debs.tar
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Gustavo Noronha Silva wrote:
Thanks for the patches! I will include them in my next upload, do you
mind proposing them upstream, though? I don't feel like I know enough of
this bit of the code to propose them myself.
Yes, I do - any assistance of you is appreciated.
I think, webkit 1.8.1 is
Émeric Maschino wrote:
I used your patched packages the passed week for my homeworks.
Stability is far better than the first patchset. With the notable
exception of the Google homepage. I don't know what's going wrong and
if other URLs are also affected. Let me explain.
Opening Epiphany with a
Package: src:gcc-4.6
Version: 4.6.3-11
Severity: serious
The gcc/g++-compiler has a bug that prevents a precompiled header
(pch) from being used. It occurred on all ia64 Debian buildds while
building the qt4-x11 package. Bug#696096 is already filed for that.
The log reads:
g++ -c
Package: iceweasel
Version: 10.0.11esr-1
Severity: serious
Tags: patch
Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
The Mozilla JS engine needs pointers have their high 17 bits cleared
because it would break a variant data type which the engine uses.
Émeric Maschino wrote:
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report
I looked for anything that is different on a release build and on a
debug build. It turned out that a lot of code related to the memory
heap is different
I took a look at this a few weeks ago.
The problem is the code in the cont.c file which implements continuations.
A thread saves its own stack and its thread context itself while it is
running. The ruby programmers believe that that the saved info can be
used by another thread to switch
Peter Green wrote:
The proposed patch defines a third option
USE(JSVALUE64W)
which we use *only* on ia64.
It uses an encapsulated union without any trick for the variant
data type. This is portable but
- the data type is 128-bits wide,
- Enabling JIT compiler isn't possible - that's
Émeric Maschino wrote:
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report
Hmm, the webkit thing seems to have at least yet another bug :-(. The
bug doesn't occur on my most recent debug build of libwebkitgtk-3.0-0.
But I could
Package: libwebkitgtk-3.0-0
Version: 1.8.1-3.3
Severity: grave
Tags: patch
Machine: Dell PowerEdge 3250
Processor: 2x Itanium Madison 1.5GHz 6M
Memory: 16G
I realized this bug while working on bug#642750.
The Epiphany browser crashed with a SIGSEGV in
JSC::JSArray::increaseVectorLength()
I tried some older Kernel versions in order to get more information
about the regression.
Udeb and libudeb0 have been downgraded to version 161 in order to run
older Kernels.
Kernel 3.0.0-2 (linux-image-3.0.0-2-mckinley_3.0.0-5_ia64.deb)
GDB 7.4.1 works
Kernel 3.1.0-rc7
Package: gdb
Version: 7.4.1
Severity: serious
Dell PowerEdge 3250
2x Itanium Madison 1.5GHz 6M
4GB RAM
I realized that GDB doesn't work as it should.
When GDB should run *any* target application, it always stops with
SIGTRAP 0x.
Example:
stephan@itanic:~$ gdb man
GNU gdb
.
Kind regards
Stephan Schreiber
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
): RGB weight 888
[32.185] (==) MACH64(0): Default visual is TrueColor
It includes successful submodule unloads now:
[32.185] (II) UnloadSubModule: vbe
[32.185] (II) Unloading vbe
[32.185] (II) UnloadSubModule: int10
[32.185] (II) Unloading int10
Kind regards
Stephan
UnloadSubModule(mod);
#endif
}
Conclusion: UnloadSubModule() was and is still buggy.
I commented out UnloadSubModule(mod) tentative in 1.12.3, the X server
started successful after that.
So the solution would be either comment out UnloadSubModule() or fix it...
Kind regards
Stephan Schreiber
UnloadSubModule(mod);
#endif
}
Conclusion: UnloadSubModule() was and is still buggy.
I commented out UnloadSubModule(mod) tentative in 1.12.3, the X server
started successful after that.
So the solution would be either comment out UnloadSubModule() or fix it...
Kind regards
Stephan Schreiber
31 matches
Mail list logo
