Hi,
Please have a look at upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
I was asked to test GCC 4.8 and found this issue go away with
locally-recompiled GCC 4.8.2 (upstream source, as ia64 is no more
supported by Debian).
Whether this was expected or not, I don't know.
This has nothing to do with kernel version, but with gcc version, as
alluded to nearly two years ago by Stephan Schreiber [1]...
Upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
Émeric
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#10
--
To
-19 20:55 GMT+01:00 Kurt Roeckx k...@roeckx.be:
On Sun, Jan 19, 2014 at 08:40:27PM +0100, Émeric MASCHINO wrote:
[1] https://lists.debian.org/debian-68k/2013/05/msg00065.html ===
BTW, why is it archived on debian-68k?
Because it was send to debian-ports@lists and not
debian-ia64@lists like
Package: iceweasel
Version: 24.2.0esr-1
Severity: important
With today's Jessie updates, iceweasel was upgraded from 17 to 24.
Firefox 17 never worked on ia64 because of upstream bug #910845 [1].
Despite of Stephan Schreiber's hard work, his patches failed to be
merged in time for Firefox 17
2014/1/12 Ben Hutchings b...@decadent.org.uk:
If you have space to install wheezy on a separate partition, please can
you try that.
(Of course, that crash ought to be fixed in 3.2.y. But I don't know
that anyone will have the time and knowledge to do so. And it's not
part of this bug.)
2014/1/7 Ben Hutchings b...@decadent.org.uk:
On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote:
I don't understand that - I still have 3.2 installed on this unstable
(i386) system and can still boot it. How does it go wrong?
It seems to crash with something wrong with systemd.
You're
2014/1/12 Ben Hutchings b...@decadent.org.uk:
So this is a crash, not an incompatibility with the newer systemd.
[...]
Can you test the 3.2 kernel with sysvinit, in case this is a bug that's
specifically provoked by systemd?
That's why I was saying too old for my current Debian install on
2014/1/12 Ben Hutchings b...@decadent.org.uk:
You can have sysvinit and systemd installed in parallel and then use the
'init' kernel parameter to switch between them. Only systemd-sysv
conflicts/replaces sysvinit.
So, I've reinstalled sysvinit and sysvinit-core that purged
systemd-sysv. I
2014/1/12 Ben Hutchings b...@decadent.org.uk:
Sorry, I'm being silly. udev is built as part of systemd now, so this
is independent of whether you use systemd as init. And systemd doesn't
currently run as init in the initramfs.
Uh, OK.
How can I help further?
Emeric
--
To
Hi,
And happy new year!
2013/12/20 Ben Hutchings b...@decadent.org.uk:
I actually tried building the kernel like that, so you could try the
packages in:
http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/
Was your O1-compiled kernel working fine?
I have no idea as no-one
2013/12/12 Ben Hutchings b...@decadent.org.uk:
So far as I know, there is no longer any commercial development of
Linux on Itanium. Some old 'enterprise' distributions might
continue to be supported for a few years but mainline isn't
supported.
It seems that Intel must provide hp with
[1] http://marc.info/?l=linux-ia64m=134858659916369w=2
[2] http://marc.info/?l=linux-ia64m=133124040906499w=2
[3] http://lists.debian.org/debian-ia64/2013/09/msg00024.html
2013/12/11 Ben Hutchings b...@decadent.org.uk:
On Tue, Dec 10, 2013 at 11:36:37PM +0100, Émeric MASCHINO wrote:
FYI, linux
FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates
didn't change anything w.r.t. gdb problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI, linux-image-3.11-2-mckinley 3.11.8-1 in today's Jessie updates
breaks gdb again.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello,
Latest GNOME 3.8 packages hit Testing today and I'm now experiencing
the same issue than you on an ia64 workstation (FireGL1 X1 AGP
graphics adapter with 256MB VRAM, r300g driver). I'm however less
lucky than you as I'm not able to set a wallpaper bigger than
2560x1440 pixels (always get
FYI, linux-image-3.10-3-mckinley 3.10.11-1 in today's Jessie updates
brought back gdb to life.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Thanks Stephan, I'll test your patches.
And I bet that the same will have to be done for Firefox ESR 21?
BTW, I don't understand how upstream code is versioned. Shouldn't your
original patches have been ported to the new JS engine by upstream
when they released Firefox ESR 10 versions?
Hi,
With the switch from WebKit 1.8.1 to 2.0.4, instability is back on
IA-64: Epiphany simply can't open any URL without crashing (cf. the
attached gdb output when trying to go to http://www.gnome.org).
Émeric
Starting program: /usr/bin/epiphany-browser
warning: Could not load shared
Package: iceweasel
Version: 17.0.8esr-2
Today's Jessie Testing updates upgraded Iceweasel ESR from 10 to 17.
Unfortunately, Iceweasel 17 simply fails to start. Please find in
attached the gdb output.
If helpful, I'm getting the following error if Iceweasel is started
from a terminal, just
Hi and happy new year,
I've tested latest patchset from Stephan.
Epiphany runs as great as with the v2 patchset.
I'm however still getting the curious Google homepage crash I was
talking about previously.
Uninstalling gnash didn't help.
But overall, Stephan work is a _huge_ improvement w.r.t.
Hi,
I've applied Stephan patches and recompiled Iceweasel. I used it for
one week now without any problem. I even ran WebGL conformance test
suite successfully whereas vanilla Iceweasel isn't able to complete it
after a few tests. Notice however that, when I say successfully, I
mean the process
i...@fs-driver.org:
É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
Thanks Stephan for your hard work.
I just tested Epiphany with the updated packages that you provided in
[1]. Are they self-contained or is yet another updated package
missing?
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report,
forwarded 659186 https://bugzilla.mozilla.org/show_bug.cgi?id=808512
thanks
Hi,
2012/10/25 Michael Biebl bi...@debian.org:
TBH, I don't know who maintains the mozjs185 branch/fork and where the
upstream bug tracker for that is.
Unfortunately, mozjs185 looks pretty much unmaintained :-/
Package: iceweasel
Version: 10.0~b2-1
Severity: important
Hello,
As reported in the debian-ia64 list back in March [1], Iceweasel 10.0
randomly stops responding, eating 100% CPU. There's no really a simple
scenario to reproduce this issue: normal web browsing activity
eventually ends up with
Nice :-)
Will this be forwarded upstream too? I think that generic (i.e. not
Debian-packaged) mozjs185 is affected. This is at least also the
case with Gentoo ia64.
Best regards,
Emeric
2012/10/25 Michael Biebl bi...@debian.org:
Thanks a lot Stefan for the patches and thanks Emeric for
tags 642750 - moreinfo
thanks
Hi,
Please find attached an updated gdb stacktrace for libwebkitgtk-3.0.0
1.8.1-3.3 and epiphany-browser 3.4.2-2 currently in Debian Wheezy
Testing when following steps described in Message #5
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#5).
Stacktrace
Hi,
Bill MacCoskley, author of commit 3c429287dfbe [1] is not convinced
that this commit is responsible for the present ia64 JS engine
problems, even if Mike thinks so [2] ;-)
I too mistakenly thought this was the case [3]. Indeed, when Stephan
noticed that the pages_map() function in
Hi,
JS engine is once again completely broken on ia64 since, at least,
commit 3c429287dfbe [1] that reverted changes allowing to turn off
static strings allocation [2]. Mike Hommey already pointed out this
issue for more than a year [3], but nobody seems to care about ia64
since then. That's for
Sorry for the late answer, I completely missed this request!
Patched libmozjs185 [1] didn't solve the issue, though GNOME Shell
crashes in a slightly different way. As I no more have my Debian
development HDD available (currently evaluating Gentoo on it), I can't
give an updated stacktrace at the
Hello,
To pass parameters to kernel, add an append= line in your elilo.conf
file, just below the initrd= line. In the present case:
append=debug=vc
Please find attached the log that I've just recorded on a serial
console passing debug=vc to kernel.
Well, I don't see anything useful or
Hi,
Tony Luck proposed a patch to fix this issue in
https://bugzilla.kernel.org/show_bug.cgi?id=42757.
Current Debian Testing kernel 3.2-14 locally rebuilt including this
patch works as expected :-)
Many thanks,
Emeric
--
To UNSUBSCRIBE, email to
Package: linux-image-3.2.0-1-mckinley
Version: 3.2.4-1
Severity: important
As reported first in
http://lists.debian.org/debian-ia64/2012/01/msg00016.html, I'm getting
stability issues with kernel 2.6.38.
I've bisected the problem to commit
37a9d912b24f96a0591773e6e6c3642991ae5a70 (futex:
a écrit :
On 09.02.2012 00:10, Émeric Maschino wrote:
Package: gnome-shell
Version: 3.2.2.1-1
Severity: important
Hello,
Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium)
platform. It instantly crashes at startup, receiving SIGSGEV from
/usr/lib/libmozjs185.so.1.0. Gnome
OK.
BTW, was Mike on IRC referring to this issue?
https://bugzilla.mozilla.org/show_bug.cgi?id=589735
Emeric
Le 9 février 2012 10:16, Michael Biebl bi...@debian.org a écrit :
On 09.02.2012 10:03, Émeric Maschino wrote:
Thank you for pointing this out.
Just a question: how
Package: gnome-shell
Version: 3.2.2.1-1
Severity: important
Hello,
Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium)
platform. It instantly crashes at startup, receiving SIGSGEV from
/usr/lib/libmozjs185.so.1.0. Gnome Classic starts up fine.
Please find in attached the gdb
Hi,
Just to let you know that Qt 4.7.4-2 in today's Debian Testing
Wheezy updates didn't solve the problem.
Émeric
Le 20 septembre 2011 02:28, Adam Majer ad...@zombino.com a écrit :
On Tue, Sep 20, 2011 at 12:17:00AM +0200, Émeric Maschino wrote:
Thanks to snapshot.debian.org, I can
Hi,
Unfortunately, still the same issue. Please have a look at the attached gdb.txt.
This is with epiphany 3.2.1-2 and webkit 1.6.1-5+b1 currently in Debian Testing.
Hope this helps and let me know if you need more information.
Émeric
Le 17 janvier 2012 01:46, Michael Gilbert
Hi,
I've identified the root cause of this issue: busybox hook is called
_before_ klibc one. This ends up with /bin/sh binary in the generated
initrd.img being a copy of (or a symlink to) system
/usr/lib/klibc/bin/sh binary whereas it is expected to be a copy of
(or a symlink to) system
Le 15 janvier 2012 19:08, maximilian attems m...@stro.at a écrit :
Nice detective work. So the next question is: why does klibc-utils on
ia64 provide /usr/lib/klibc/bin/sh instead of sh.shared like other
architectures?
#439181 ia64 works only static
Thanks for pointing this out.
I'd also
Le 14 novembre 2011 23:51, Jonathan Nieder jrnie...@gmail.com a écrit :
So, to summarize, only libgconf.so and libsmartcard.so didn't need to
be replaced by recompiled versions without -z defs flag. I don't know
if it'll help further, but they can even be removed from
Package: metacity
Version: 2.34.1-2
Severity: important
Hello,
With the delivery of GNOME 3 into Testing, Metacity was upgraded from
version 2.30.1-3 to version 2.34.1-2.
Since then, I'm experiencing stability issue when running
OpenGL-intensive applications (e.g. ioQuake3-based applications or
2011/11/13 Josselin Mouette j...@debian.org:
I find this dubious. The point of keeping metacity for the fallback mode
is that it still does everything in software, or only with RENDER
acceleration; it does not use OpenGL.
Could it thus be possible that RENDER acceleration globally
struggles
2011/11/13 Émeric Maschino emeric.masch...@gmail.com:
I'm not sure if the lock up during the WebGL tests still appears on
the same test. If yes, I imagine it will help understand what's going
on. I'll try to have a reproduceable error.
Unfortunately, WebGL test suite not always locks up
2011/11/11 Ben Hutchings b...@decadent.org.uk:
On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote:
2011/11/11 Ben Hutchings b...@decadent.org.uk:
Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4()?
That is a little difficult when the system call is not even
From: Émeric Maschino emeric.masch...@gmail.com
Subject: ia64: Add accept4() syscall
While debugging udev 170 failure on Debian Wheezy
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
that the issue was in fact due to missing accept4() in ia64.
This patch simply adds
Patrice,
The Loading please wait... issue you're experiencing isn't due to
udev, but to initramfs-tools 0.99.
See my bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068) and feel
free to add comment.
Hi,
I have got the same trouble after restarting a IA64 server running a
2011/11/11 Ben Hutchings b...@decadent.org.uk:
--- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.0 +0100
+++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.0 +0100
@@ -315,11 +315,12 @@
#define __NR_fanotify_init 1323
#define __NR_fanotify_mark
2011/11/11 Ben Hutchings b...@decadent.org.uk:
That version just calls the libc implementation of accept4(), which
won't work until libc is rebuilt. You need to define __NR_accept4 and
call syscall(__NR_accept4, ...) in the test program instead.
Isn't Wheezy eglibc 2.13-21 supposed to already
2011/11/10 Jonathan Nieder jrnie...@gmail.com:
Thanks. What would be really useful is a linker command line and the
collection of object files (.o, .a, and .so, including relevant system
libraries from /usr/lib/) that it refers to, as described in
/usr/share/bug/binutils/presubj. Feel free
2011/11/10 Ben Hutchings b...@decadent.org.uk:
But I do not understand why nobody else noticed this, unless you are the
first person to install wheezy on ia64.
That seems entirely plausible.
Definitely since:
- netinst Wheezy CD-ROM is unbootable on ia64 (although Squeeze was fine)
-
implemented,
right?
Is it thus a kernel-related issued rather than an udev one?
Émeric
2011/11/7 Marco d'Itri m...@linux.it:
On Nov 07, Émeric Maschino emeric.masch...@gmail.com wrote:
It seems that SOCK_CLOEXEC is thus correctly defined, don't you think so?
Yes, but this does not mean
Hello Marco,
2011/11/6 Marco d'Itri m...@linux.it:
On Nov 06, Émeric Maschino emeric.masch...@gmail.com wrote:
Starting with udev 170 (well, IIRC!), console is flooded at startup with:
udevd[XXX]: unable to receive ctrl connection: Function not implemented
Your lacks support
Package: udev
Version: 172-1
Severity: important
Hello,
Starting with udev 170 (well, IIRC!), console is flooded at startup with:
udevd[XXX]: unable to receive ctrl connection: Function not implemented
where XXX is a number (PID?).
And system takes ~3 min. to get login prompt.
Last udev
Hi,
Any progress on this? How can I help further?
It's still impossible to either install Wheezy on ia64 from Debian
netinst CD or upgrade from a running Lenny system as kernel 2.6.38
need initramfs-tools 0.99 that produces unbootable initrd images.
Best regards,
Émeric
--
To
Hello Mike,
2011/10/6 Mike Hommey m...@glandium.org:
That would waste a 64-bits word. The usual way to do it is to use
unions:
union {
PRUint64 dummy;
struct {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
};
};
Mike
nsID 64-bit alignment issue was already tracked down:
2011/10/6 Mike Hommey m...@glandium.org:
On Thu, Oct 06, 2011 at 12:21:29AM +0200,
That would waste a 64-bits word. The usual way to do it is to use
unions:
union {
PRUint64 dummy;
struct {
PRUint32 m0;
PRUint16 m1;
PRUint16 m2;
};
};
Thanks for pointing this out. I've
2011/10/4 Mike Hommey m...@glandium.org:
On Tue, Oct 04, 2011 at 10:20:16PM +0200,
m0 is a 32-bit value, it needs 32-bits alignment. m1 is 16-bits, 16-bits
alignment, etc. Overall, the struct only requires 32-bits alignment.
Reading http://en.wikipedia.org/wiki/Data_structure_alignment, I
2011/10/5 Mike Hommey m...@glandium.org:
On Wed, Oct 05, 2011 at 10:50:56AM +0200,
The problem is not the alignment of m2, the problem is the alignment of
the whole struct, which has a requirement of 32-bits. Which means a
struct nsID can end up at 0x0, 0x4, 0x8, or 0xc. When it's at 0x4 or
OK, reading http://www.osronline.com/ddkx/kmarch/64bitamd_20iv.htm
helped me understand structure alignment (well, I think!): The
alignment of the beginning of a structure or a union is the maximum
alignment of any individual member.
2011/10/5 Mike Hommey m...@glandium.org:
On Wed, Oct 05, 2011
Sorry for the late reply.
2011/9/28 Mike Hommey m...@glandium.org:
On Tue, Sep 27, 2011 at 10:32:17PM +0200, Émeric Maschino wrote:
Thanks so in fact the error is on the next line, and is due to this
code:
inline PRBool Equals(const nsID other) const {
return
((PRUint64*) m0)[0
I don't understand. What prevent nsID from being 64-bit aligned? Don't
m0, m1 and m2 fit in a 64-bit word and m3 in yet another one?
Émeric
2011/10/4 Mike Hommey m...@glandium.org:
On Tue, Oct 04, 2011 at 08:11:17PM +0200, Émeric Maschino wrote:
struct nsID {
PRUint32 m0;
PRUint16
2011/9/27 Mike Hommey m...@glandium.org:
Could you add the output for disassemble and info registers ?
Mike
Sure! Please find the attached gdb.txt.
Émeric
(gdb) run
Starting program: /usr/lib/iceweasel/firefox-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x700088cb1e0
Mike,
2011/9/25 Mike Hommey m...@glandium.org:
nsISupportsImpl.cpp:44 is:
while (entries-iid) {
entries is 0x70004008fb8, and its type is a pointer to:
struct QITableEntry
{
const nsIID *iid;
PROffset32 offset;
};
I fail to see how this can be unaligned...
What is the
Mike,
2011/9/25 Mike Hommey m...@glandium.org:
nsISupportsImpl.cpp:44 is:
while (entries-iid) {
entries is 0x70004008fb8, and its type is a pointer to:
struct QITableEntry
{
const nsIID *iid;
PROffset32 offset;
};
I fail to see how this can be unaligned...
What is the
Package: epiphany-browser
Version: 3.0.4-1
Severity: important
Epiphany is barely usable on ia64 platform (crashes *VERY* frequently).
Steps to reproduce:
- start up Epiphany; default page is http://www.debian.org
- go to http://www.google.fr and search for Debian
- click on the second Google
Package: xulrunner-6.0
Version: 6.0.2-1
Severity: normal
As Iceweasel 6.0 (more precisely the JS engine as I understand it
correctly) is currently being (actively?) debugged on ia64 (and
probably other platforms too), I think it may be useful to report the
various unaligned access messages
Is this related to build problem with gcc 4.6:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635153 (g++-4.6: ICE
on ia64 when building iceweasel 5.0-4)?
Is it worth reporting further issues against Iceweasel 5.0-6 or is it
better to play and report bugs against Iceweasel 6.0-2 right now?
2011/9/20 Mike Hommey m...@glandium.org:
Not at all, it's the js engine that doesn't work on ia64, and the
patches to make it moslty work have been applied to 6.0.2-1
https://bugzilla.mozilla.org/show_bug.cgi?id=589735 seems a good candidate.
Is it worth reporting further issues against
Package: qtcreator
Version: 1.3.1-3
Severity: important
Qt Creator crashes at startup with a bus error. I can briefly see the
main window being drawn (completely empty, just the Qt Creator title
window, with Qt Creator icon and system buttons are shown).
I don't know if it will help, but console
Thanks to snapshot.debian.org, I can confirm that qtcreator 1.3.1-3
currently in Debian Wheezy Testing can be run successfully with Qt
packages up to 4.7.1-2. Starting with Qt packages 4.7.2-1, Qt Creator
crashes with a bus error.
--
To UNSUBSCRIBE, email to
Hi,
FWIW amid the reports merged with this one, there is one person using
i386 and another using mipsel.
I don't know for i386 and mipsel, but here are my investigations for ia64.
From the point of view of fixing this in binutils, it would be _very_
helpful to have a collection of object
Hi,
I've looked at the source package: the debian/build script still
passes -z defs flags to ld, thus producing a broken binary, as
expected :-(
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi,
does initramfs-tools boot with BUSYBOX=no in initramfs.conf?
Well, I don't know! Indeed, with BUSYBOX=no in initramfs.conf,
initrd.img generation fails:
root@longspeak:/# dpkg-reconfigure linux-image-3.0.0-1-mckinley
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing
Package: initramfs-tools
Version: 0.99
Severity: grave
As stated in this thread
http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian
Wheezy Testing cannot be booted at all on IA-64 (current
linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools
0.99, so initramfs-tools
Hi,
I've looked at the source package: the debian/build script still
passes -z defs flags to ld, thus producing a broken binary, as
expected :-(
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Sorry for the delay,
Anyway, it would be great if you could report this upstream at
http://bugs.freedesktop.org/enter_bug.cgi?product=Mesa , component
Drivers/Gallium/r300. The main upstream r300g developer (Marek Olšák) is
usually quite responsive to bug reports.
Done. See
Hello Michel,
If you pass --with-dri-drivers=r300 to configure, the classic driver
Allright, this time it worked :-)
I probably misunderstood that the How to build mesa page was only
dealing with the Gallium driver.
So, back to your initial question ;-)
Hello Michel,
If you pass --with-dri-drivers=r300 to configure, the classic driver
should end up in lib/r300_dri.so, as opposed to r300g in
lib/gallium/r300_dri.so . You can override libGL's search path with the
LIBGL_DRIVERS_PATH environment variable, and if you also set
Hi,
Just finished recompiling mesa git following this guide
http://pkg-xorg.alioth.debian.org/howto/build-mesa.html. Everything
ran as described, except for the last section (I'm getting no libEGL
debug messages with glxgears).
Still the same issue however :-(
Émeric
--
To UNSUBSCRIBE,
Le 14 avril 2011 10:29, Michel Dänzer daen...@debian.org a écrit :
Does the classic driver still work?
Well, now that I've rebuilt Mesa Git with Gallium support, how do I
switch GL rendering back to Mesa classic?
I tried recompiling the whole thing, removing --enable-gallium-radeon
from
Hi Michel,
The r300g driver shipped in current libgl1-mesa-dri only works with KMS,
so with that disabled, you're probably getting software rendering.
I should have noticed it earlier!
You're right, GL rendering with libgl1-mesa-dri 7.7.1-4 is done
through r300c driver, whereas it's done
Hi,
Version 7.10.2-1 is currently not available for IA-64. However version
7.10.1-1 is, so tested with it (also upgrading related packages). Same
issue unfortunately :-(
Émeric
2011/4/12 Cyril Brulebois k...@debian.org:
severity 622299 important
thanks
Hi,
Émeric Maschino
Hi,
FYI, manually installing apt 0.8.13.1 (dated 2011-04-03) using dpkg -i
made apt happy again.
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: binutils
Version: 2.20.1-16
Severity: critical
As explained in this post
(http://lists.debian.org/debian-ia64/2011/03/msg00017.html),
gnome-settings-daemon is broken on IA-64 (Itanium) since release
2.24.1-1 dated 2008-12-30, not because of a source code change, but
because of a change
Hi,
As explained here
(http://lists.debian.org/debian-ia64/2011/03/msg00017.html), this
issue isn't due to a code change in gnome-settings-daemon, but to a
change in the flags passed to ld by the debian/rules build script of
the gnome-settings-daemon source package.
Simply removing -Wl,-z,defs
Hi,
-z defs means to disallow undefined symbols in object files. Are you
sure that there is not some undefined symbol in an object file and
this is not build system/runtime behavior fallout from that?
I know nothing about gnome-settings-daemon code and related software,
so can't make any
Hello again,
Thanks for your hard work tracking this down, and thanks for bringing
it to our attention. I'm going to merge this with the existing
gnome-settings-daemon bug, so the problem is tracked in one place.
Of course it is possible there is a binutils involved here somewhere.
If that
Hi,
I don't know if the root cause is the same, but here's the stack trace
I'm recording with current epiphany-browser in Debian Squeeze on an
Itanium workstation.
emeric@longspeak:~$ gdb epiphany-browser
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License
FYI,
gnome-settings-daemon 2.30.2-2 available in yesterday's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI,
gnome-settings-daemon 2.30.2-1 available in Debian Squeeze updates
didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI,
gnome-settings-daemon 2.30.1-1 available in yesterday's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi,
Thanks to the new snapshot.debian.org service (great feature!), I've
performed regression testing and have the strong impression that this
issue isn't due to D-BUS or GLib at all, but to gnome-settings-daemon.
Indeed, starting from my current Squeeze installation and downgrading
FYI,
gnome-settings-daemon 2.28.1-3 available in today's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI,
D-BUS 1.2.24-1 available in today's Debian Squeeze updates didn't
solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
2010/2/2 maximilian attems m...@stro.at:
I've bisected this problem to commit
f1a2a9b6189f9f5c27672d4d32fec9492c6486b2 (drm: Preserve SHMLBA bits in
hash key for _DRM_SHM mappings), during kernel 2.6.30 development cycle.
please report upstream on bugzilla.kernel.org and let us know
the bug
2009/11/6 Julien Cristau jcris...@debian.org:
My guess would be the kernel, but the best place to find developers who
might be able to help you is likely to be the dri-de...@lists.sf.net
mailing list (you're probably one of the only people to use graphics on
ia64 though).
(I asked Dave
FYI,
Today's Debian Squeeze gnome-settings-daemon 2.28.1-1+b1 update didn't
solve the problem.
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello,
OK, I'll try the dri-devel list.
Thank you for your time anyway.
Émeric
My guess would be the kernel, but the best place to find developers who
might be able to help you is likely to be the dri-de...@lists.sf.net
mailing list (you're probably one of the only people to use
Hello,
I don't know where exactly this problem resides, but just to let you know
that Debian Squeeze libdrm2 2.4.13-1 update didn't help.
Regards,
Émeric
1 - 100 of 106 matches
Mail list logo
