Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On 06/27/2018 10:03 PM, Niels Thykier wrote: > Hi, > > > As part of the interim architecture qualification for buster, we request > that DSA, the security team and the toolchain maintainers review and > update their list of known concerns for buster release architectures. > Everyone, please avoid followups to debian-po...@lists.debian.org. Unless something is relevant to *all* architectures (hint: discussion of riscv or arm issues don't qualify), keep replies to the appropriate port-specific mailing list. Thanks, Julien
Re: libx11: Issues with Data32/_XData32
On Tue, Jan 24, 2017 at 01:12:23 +, James Clarke wrote: > Hi, > I've been debugging an issue in gtk2-perl causing it to SIGBUS on > sparc64, and traced it back to what seems to be dodgy code inside > libx11. One of the tests calls gdk_window_set_opacity, which calls > XChangeProperty with a pointer to a guint32, cast to char*, with the > length set to 32 bits as expected. However, this data pointer then gets > cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed, > the definition of Data32 specifies that data is a (long *) on sparc64, > since LONG64 is defined. This feels very wrong, but in and of itself is > not too bad (I believe it violates strict aliasing). > As discussed on irc this sounds like a gtk bug, fixed by https://git.gnome.org/browse/gtk+/commit/?id=0e1a424829937abc27780da97a8bf60e81233d6c for gtk 3. Cheers, Julien
Re: Sparc status ?
On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote: Le 18/04/2014 06:56, Joost van Baal-Ilić a écrit : I'd guess skilled hacker time is more needed than hardware. Reading https://release.debian.org/jessie/arch_qualify.html , it seems major blocking issues are: Using gcc-4.6 as default compiler and Have to run oldstable kernels. Related to this: only 1 porter, only partial upstream support. Bye, Joost - who'd _love_ to have a fully supported Debian on sparc So, if I have understood correctly, the main problem is that 32bit compilation is not supported in the current releases of gcc ? No, that is not accurate. The main reason is that there are a number of issues with the sparc port currently that are not being addressed because apparently nobody is interested enough in the sparc port to fix the issues. Going to 64bit userland is a huge leap forward. For the second one, I wonder. I've been able to run 3.13 kernel on my V240 hardware and I thing it's recent enough. I have no clue why is it marked oldkernel something related to the buildd ? The debian.org sparc machines do not work reliably with recent kernels. That is not sustainable. Cheers, Julien signature.asc Description: Digital signature
Re: maintainer communication
On Mon, Dec 23, 2013 at 22:14:00 +, Thorsten Glaser wrote: My intent in _this_ thread was to get a discussion among debian-ports.org users started for best practices of how to communicate with package maintainers in Debian. Sorry for being unclear there. I had hoped for hints ☺ since I know my communication skills lack somewhat. debian-po...@lists.debian.org is an alias for *all* debian-$arch lists for debian architectures. It has nothing to do with debian-ports.org. If you want a list for debian-ports.org users go create one, but please don't abuse this one. Thanks, Julien signature.asc Description: Digital signature
Re: -Werror=cast-align setted by default?
On Tue, Dec 24, 2013 at 10:44:51 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! I'm one of Qt maintainers and I'm contacting you because of the FTBFS of qtsvg-opensource-src [0] [0] https://buildd.debian.org/status/logs.php?pkg=qtsvg-opensource-srcarch=sparc As it can be seen in the above web page qtsvg started to FTBFS in version 5.1.1-3, but succeeded to build on previous versions. Comparing the build logs it seems that -Werror=cast-align was somehow added to the build, but definitely not by us. You enabled tests. The failure happens in tests/auto/headersclean. That definitely sounds like something you changed in that revision. That particular file is built with -Werror (on all architectures), nothing else in this builds seems to be. Cheers, Julien signature.asc Description: Digital signature
Re: m4 FTBFS
On Mon, Dec 2, 2013 at 11:31:58 +0100, Santiago Vila wrote:
Hello.
m4 FTBFS on sparc. I need help to diagnose this.
https://buildd.debian.org/status/fetch.php?pkg=m4arch=sparcver=1.4.17-2stamp=1385908483
Looks like an issue between the kernel and libsigsegv. As far as I can
tell from looking a this on smetana, sigsegv_handler gets called with
this siginfo_t structure:
(gdb) p *sip
$1 = {si_signo = 11, si_errno = 0, si_code = 1, _sifields = {_pad = {
0 repeats 29 times}, _kill = {si_pid = 0, si_uid = 0}, _timer = {
si_tid = 0, si_overrun = 0, si_sigval = {sival_int = 0,
sival_ptr = 0x0}}, _rt = {si_pid = 0, si_uid = 0, si_sigval = {
sival_int = 0, sival_ptr = 0x0}}, _sigchld = {si_pid = 0, si_uid = 0,
si_status = 0, si_utime = 0, si_stime = 0}, _sigfault = {si_addr = 0x0,
si_trapno = 0}, _sigpoll = {si_band = 0, si_fd = 0}, _sigsys = {
_call_addr = 0x0, _syscall = 0, _arch = 0}}}
I'm not sure the NULL value for si_addr is expected. In any case the
is this near the top of the stack check fails, and the overflow
handler is never called.
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
On Wed, Oct 2, 2013 at 11:44:44 +0200, Axel Beckert wrote: Yesterday I tried to setup a sparc64 chroot on a second disc in one of my Sparcs, but the currently documented way[1] to do so failed[2] due to outdated packages. On a first glance it looks like missing BinNMUs for the Perl 5.14 to Perl 5.18 transition. Part of the porter's job is to take care of that kind of things. If that's not happening for sparc64 because nobody's actually taking care of the port, I don't see it as a viable candidate for the archive... Cheers, Julien signature.asc Description: Digital signature
Re: DSA concerns for jessie architectures
On Sun, Jul 21, 2013 at 21:06:31 +0200, Bernd Zeimetz wrote: I think all machines except stadler and sompek are US IIIi machines. The problem with US IIIi is, that sun never published the cpu specs - they would have done it if somebody would have paid for the lawyers to look trough them before publishing. US IIi support was implemented by a student working at SUN under NDA and US IV and later was published. So I think if dropping (official) support for US IIIi CPUs would keep the port alive, we should do that. Running Debian on the more recent machines makes more sense anyway imho. The older ones are nice, but they consume a lt of power. IIRC stadler and sompek are less stable than the others. And keep triggering unreproducible gcc ICEs. Seems to me the sparc port no longer has anybody working on it, and is on its last legs. I'm not sure it makes much sense to keep it in jessie. Cheers, Julien signature.asc Description: Digital signature
Re: Current and upcoming toolchain changes for jessie
On Thu, Jun 13, 2013 at 14:51:43 +0200, Matthias Klose wrote: Am 07.05.2013 15:25, schrieb Matthias Klose: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. [...] Information on porting to GCC 4.8 from previous versions of GCC can be found in the porting guide http://gcc.gnu.org/gcc-4.8/porting_to.html It is planned to only keep GCC 4.8 and the upcoming GCC 4.9, and to remove 4.4, 4.6 and 4.7 from jessie. GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). I did not get any feedback from other port maintainers, so unless this does change and port maintainers get involved with toolchain maintenance, the architectures staying at 4.6 or 4.7 shouldn't be considered for a successful release (re-)qualification. FWIW, it looks like current glib2.0 is miscompiled on sparc with gcc-4.6, and the issue goes away with 4.8. Cheers, Julien signature.asc Description: Digital signature
Re: VIO on sparc / udev support
Michael, On Mon, May 13, 2013 at 02:51:51 +0200, Michael Biebl wrote: Since no-one in the systemd/udev team is using SPARC hardware, I was wondering, if vio_type would have a better home in e.g. the sparc-utils [2] package, where it would be maintained and tested by people with knowledge of that architecture. I don't think that would make much sense, and this belongs with the related utils in udev IMO. Seeing a bug report like [3], it's not actually clear to me, if vio_type is still functional with newer kernel releases and for which type of hardware this is actually required. I poked Marco about this, but he doesn't remember the details anymore. Your [3] points at an udev packaging bug. How does it relate to newer kernel releases? The hardware for which this is required was described in #526621, so I don't really get that question either... Puzzled, Julien signature.asc Description: Digital signature
Re: [Pkg-systemd-maintainers] VIO on sparc / udev support
On Mon, May 13, 2013 at 16:26:05 +0200, Marco d'Itri wrote: On May 13, Julien Cristau jcris...@debian.org wrote: I don't think that would make much sense, and this belongs with the related utils in udev IMO. Actually the root issue is that the helper is (was?) needed only because the kernel does not provide the data needed to allow autoloading these drivers. So if we are talking about correctness then the correct solution would be to fix the kernel. So from a quick look at smetana (sparc), wheezy 3.2.x kernel: sunvnet has alias: vio:Tvnet-portS* and sunvdc has alias: vio:Tvdc-portS* Seems like the device tables have been there since a week or so after adding the drivers (in 2007), so not really new. Does udev know to load that nowadays? On partch (powerpc), squeeze 2.6.32 kernel: hvc_console is not built hvcs has alias: vio:Tserial-serverShvterm2* ibmveth has alias: vio:TnetworkSIBM,l-lan* ibmvscsic has alias: vio:TvscsiSIBM,v-scsi* iseries_veth is not present viodasd and viocd were removed in 2012 (ba7a4822b48fbc7afd6b567c18e316a03f46684d), and don't seem to be enabled in the Debian kernels. As to whether that's sufficient, your guess is as good as mine. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#593141: Bug#653582: ruby-hpricot: FTBFS on ia64: ruby crashes while running tests
Control: tag 653582 wheezy-ignore Control: tag 593141 wheezy-ignore On Sat, Dec 8, 2012 at 11:11:56 -0300, Antonio Terceiro wrote: On Fri, Dec 07, 2012 at 10:21:57PM +0100, Stephan Schreiber wrote: For now I'd prefer the 'wheezy-ignore' rather than removing the ia64 ruby package. Looks like this should be the way to go. Agreed. Cheers, Julien signature.asc Description: Digital signature
Bug#685245: [PATCH] silo: Don't touch %tick_cmpr on sun4v cpus.
Package: silo
Severity: grave
X-Debbugs-Cc: David Miller da...@davemloft.net, debian-sparc@lists.debian.org
Tags: upstream patch fixed-upstream
Filing this as a bug so it doesn't get lost. Thanks for the heads-up,
David.
On Wed, Aug 15, 2012 at 01:14:16 -0700, David Miller wrote:
This generates an illegal instruction exception.
This has a long history. For the first sun4v port of SILO in commit
494770a17eea7192d3242051e76f4da6d838e3a1 (SILO Niagara/SUN4V
support) this code was removed entirely.
But later this was found to regress older UltraSPARC boxes, so we put
it back in commit bd708e35bdcd8e92cb7c65368f2a356982df7cd8 (Fix
Ultra10 SILO timer). But that was wrong too.
The OBP still owns the trap table when SILO runs and it uses the
%tick_cmpr generated interrupt. This has a bad interraction with how
we use the %tick register in SILO.
SILO first reads the %tick register and remembers this value as the
time base.
Later, we read %tick again, compute the difference, and use this to
calcualte the amount of time elapsed.
OBP's %tick_cmpr interrupt handler is doing something funky, such as
resetting %tick, which makes our timeouts never actually expire.
This issue doesn't exist on sun4v machines, and we absolutely cannot
try to touch the %tick_cmpr register as that generates an illegal
instruction trap on such cpus.
Signed-off-by: David S. Miller da...@davemloft.net
---
I just committed this into the SILO git repo.
Debian folks, you really want this propagated into your installer as
soon as possible. All the install ISOs will crash in SILO on all
sun4v (Niagara) machines unless an explicit SILO boot target is given
on the boot command line. I used boot cdrom install to get around
this.
It triggers any time the timer mechanism is enabled (timeout=foo is
specified in silo.conf)
include/silo.h | 1 +
second/main.c | 1 +
second/misc.c | 4 +++-
second/timer.c | 2 +-
4 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/silo.h b/include/silo.h
index fe5adcb..94d6e31 100644
--- a/include/silo.h
+++ b/include/silo.h
@@ -125,6 +125,7 @@ int strtol (const char *, char **, int);
int decompress (char *, char *, unsigned char (*)(void), void (*)(void));
/* main.c */
extern enum arch architecture;
+extern int sun4v_cpu;
/* timer.c */
int init_timer ();
void close_timer ();
diff --git a/second/main.c b/second/main.c
index 182b263..a45807d 100644
--- a/second/main.c
+++ b/second/main.c
@@ -64,6 +64,7 @@ enum {
CMD_LS
} load_cmd;
enum arch architecture;
+int sun4v_cpu;
static int timer_status = 0;
static char *initrd_start;
static int initrd_size;
diff --git a/second/misc.c b/second/misc.c
index 163738e..d6bcdb1 100644
--- a/second/misc.c
+++ b/second/misc.c
@@ -517,8 +517,10 @@ enum arch silo_get_architecture(void)
return sun4d;
case 'e':
return sun4e;
-case 'u':
case 'v':
+ sun4v_cpu = 1;
+ /* FALLTHRU */
+case 'u':
return sun4u;
default:
for(i = 0; i NUM_SUN_MACHINES; i++)
diff --git a/second/timer.c b/second/timer.c
index 51e928e..7f03996 100644
--- a/second/timer.c
+++ b/second/timer.c
@@ -156,7 +156,7 @@ static inline int sun4u_init_timer ()
}
if (!foundcpu || !clock_frequency)
clock_frequency = prom_getint(prom_root_node, clock-frequency) /
100;
-if (notimer) {
+if (notimer !sun4v_cpu) {
sun4u_notimer = 1;
__asm__ __volatile__ (\t
rd %%tick_cmpr, %%g1\n\t
--
1.7.11.2
On Wed, Aug 15, 2012 at 16:43:31 -0700, David Miller wrote:
From: David Miller da...@davemloft.net
Date: Wed, 15 Aug 2012 01:14:16 -0700 (PDT)
This generates an illegal instruction exception.
Unfortunately, after some more testing, this needs a follow-on fix,
included below and also committed to SILO git.
Sorry for the confusion.
silo: Don't assume P1275 OBP means sun4u.
It could also mean 'sun4v'.
Code this defensively, so that if (for whatever reason)
we can't get at the 'compatible' property in the root
OBP device node we'll still default to sun4u as previous.
Signed-off-by: David S. Miller da...@davemloft.net
---
second/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/second/misc.c b/second/misc.c
index d6bcdb1..d789723 100644
--- a/second/misc.c
+++ b/second/misc.c
@@ -501,7 +501,7 @@ enum arch silo_get_architecture(void)
if ((i = prom_searchsiblings(i, MicroSPARC-IIep)) != 0) {
return sun4p;
}
-return sun4u;
+ buffer[4] = 'u';
}
i = prom_getproperty (prom_root_node, compatability, buffer, 8);
--
1.7.11.2
Cheers,
Julien
signature.asc
Description: Digital signature
Re: gcc 4.6.3-5 internal compiler error on sparc/stadler for package guitarix
On Fri, Jun 15, 2012 at 22:24:16 +0200, Roland Stigge wrote: Hi, for the guitarix package, we noticed various internal compiler error from g++. See also log, e.g. https://buildd.debian.org/status/fetch.php?pkg=guitarixarch=sparcver=0.22.4-1stamp=133963 Since there are g++ internal compiler errors, maybe this is specific to the installation on stadler, or is it specific to sparc? How can I help here? See https://lists.debian.org/debian-sparc/2012/04/msg8.html I don't know about any progress there. guitarix given back for now. Cheers, Julien signature.asc Description: Digital signature
Re: DM needs access to porterbox to port yorick-av to sparc and s390(x)
On Fri, May 11, 2012 at 10:25:40 +0200, Thibaut Paumard wrote: Would it be possible to have access to a porterbox on sparc, s390 and/or s390x with yorick-av's build dependencies installed? http://dsa.debian.org/doc/guest-account/ Cheers, Julien signature.asc Description: Digital signature
Re: Rebuild request: gnat-gps on sparc
On Mon, Apr 16, 2012 at 11:03:51 +0200, Ludovic Brenta wrote: Could someone please schedule a rebuild of gnat-gps on spontini or on a sompek configured with more paging space? Thanks! This list is the wrong place, you want sp...@buildd.debian.org. Cheers, Julien signature.asc Description: Digital signature
Re: Help debugging bug #667504
On Wed, Apr 4, 2012 at 19:56:36 -0400, Jack Hill wrote: Ahoy hoy, Hi, How should I go about collecting more information for bug #667504 (libav-tools: bus error on sparc encoding vp8)? I replied directly to the bug. Thanks for your report. Cheers, Julien signature.asc Description: Digital signature
Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
On Sat, Mar 3, 2012 at 09:55:51 -0600, Patrick Baggett wrote:
Where can I read the source for nbd-tester-client.c? I just did a quick
scan of ghash.c but I didn't see anything really silly going on, so I'd
like to check this file. All copies I can find of nbd-tester-client.c
seem to be short (600 lines) and not use glib at all.
It does this:
/*
* This is the reply packet that nbd-server sends back to the client after
* it has completed an I/O request (or an error occurs).
*/
struct nbd_reply {
__be32 magic;
__be32 error; /* 0 = ok, else error */
char handle[8]; /* handle you got from request */
};
[...]
GHashTable *handlehash = g_hash_table_new(g_int64_hash, g_int64_equal);
struct nbd_reply rep;
READ_ALL_ERRCHK(sock,
rep,
sizeof(struct nbd_reply),
err_open,
Could not read from server socket: %s,
strerror(errno));
[...]
prc = g_hash_table_lookup(handlehash, rep.handle);
So alignof(struct nbd_reply) is 4, and rep.handle is not always 8-byte
aligned. Either the handle should be made a uint64_t, or the test
should do
uint64_t handle;
memcpy(handle, rep.handle, 8);
prc = g_hash_table_lookup(handlehash, handle);
Cheers,
Julien
signature.asc
Description: Digital signature
Re: Bug#653653: nbd: FTBFS on sparc: Bus error (core dumped) - FAIL: integrity
cc+=debian-sparc@ On Wed, Feb 29, 2012 at 14:14:46 +0100, Wouter Verhelst wrote: tags 653653 + help thanks On Fri, Dec 30, 2011 at 12:40:09AM +0100, Jakub Wilk wrote: Source: nbd Version: 1:2.9.25-2 Severity: serious Justification: fails to build from source User: debian-sparc@lists.debian.org Usertags: sparc nbd FTBFS on sparc: | ./integrity | 28870: Seq 0002 Queued: 0001 Inflight: Done: | Bus error (core dumped) | FAIL: integrity Full build log: https://buildd.debian.org/status/fetch.php?pkg=nbdarch=sparcver=1%3A2.9.25-2stamp=1325194394 So, I had a look at this on the porter machines a while back, and I have to say I'm a bit stumped as to what's wrong. There's some stack corruption going on inside nbd-tester-client (the test suite client that tests whether nbd-server runs correctly), which makes things a bit harder; but I can't see why there should be any such stack corruption. Running this inside valgrind (on amd64) also doesn't flag anything suspicious. Help from anyone familiar with SPARC would be appreciated. signature.asc Description: Digital signature
Re: [GLE-general] GLE 4.2.4 Released
On Sat, Jan 14, 2012 at 20:47:25 +0100, Christian T. Steigies wrote: Hi, one of my packages fails to build on sparc. Is it possible to give upstream an account on one of the porter boxes, and install the build-depends? On sperger, these packages are missing for gle-graphics in the sid dchroot: libtiff-dev libqt4-opengl-dev hardening-wrapper See http://dsa.debian.org/doc/guest-account/ and http://dsa.debian.org/doc/install-req/ Cheers, Julien signature.asc Description: Digital signature
Re: Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Thu, Jan 12, 2012 at 09:50:11 +, Jurij Smakov wrote: Thanks, build completed successfully: https://buildd.debian.org/status/fetch.php?pkg=ruby1.8arch=sparcver=1.8.7.352-2stamp=1326336427 Closing the bug. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120112203134.gi9...@radis.cristau.org
Re: Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Tue, Jan 10, 2012 at 22:55:16 +, Jurij Smakov wrote: It probably makes sense to ask someone with buildd super-powers to trigger another build on sparc to see if the problem is somehow buildd-specific. It was already tried 3 times on 2 different buildds: https://buildd.debian.org/status/logs.php?pkg=ruby1.8arch=sparcver=1.8.7.352-2 I can give it back once more, but... Cheers, Julien signature.asc Description: Digital signature
Re: Bug#652115: ruby1.8: FTBFS on sparc: ./sample/test.rb:1848: [BUG] Bus Error
On Wed, Jan 11, 2012 at 21:21:07 +, Jurij Smakov wrote: The test fails at sample/test.rb:1848, which is ary2 = $x.unpack($format) We had a gcc-4.6 bug (http://bugs.debian.org/635126) which manifested itself as a miscompilation of pack/unpack function in Ruby. The bug got fixed in gcc-4.6 4.6.2-6 and the latest build attempt was done with 4.6.2-4, so it did not contain this fix. I'd say giving it back is pretty pointless unless we can bump gcc-4.6 version to 4.6.2-6 or later (which is a very good idea anyway, because we currently build packages with known bad compiler version). jcristau@grieg:~$ wb gb ruby1.8 . sparc . -o --extra-depends 'gcc-4.6 (= 4.6.2-6)' Cheers, Julien signature.asc Description: Digital signature
Re: Sparc 6.0.3: multiple Nautilus file manager process after few minutes from fresh install
On Sat, Dec 17, 2011 at 11:37:08 +, Mark Morgan Lloyd wrote: Certainly. For sure. No problem. And how long did it take Debian to sort out the known issue that screwed local X on a U1 etc? My I believe it was broken in squeeze r0, and fixed in r1. I don't have access to sparc hw, and nobody told me it was still broken after r1, so… Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217162924.gb24...@radis.cristau.org
Re: Sparc 6.0.3: multiple Nautilus file manager process after few minutes from fresh install
On Sat, Dec 17, 2011 at 17:29:24 +0100, Julien Cristau wrote: On Sat, Dec 17, 2011 at 11:37:08 +, Mark Morgan Lloyd wrote: Certainly. For sure. No problem. And how long did it take Debian to sort out the known issue that screwed local X on a U1 etc? My I believe it was broken in squeeze r0, and fixed in r1. I don't have access to sparc hw, and nobody told me it was still broken after r1, so… Meh, I meant lenny, not squeeze. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111217172610.gd24...@radis.cristau.org
Re: gcc ICE
On Fri, Nov 4, 2011 at 10:05:49 +0100, Mathieu Malaterre wrote: Hi all, I am reporting an ICE for one of my project. Because I am not a DD, I cannot fill a proper bug report upstream (gcc). This makes no sense, what does being a DD have to do with upstream gcc... Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2004204949.gf3...@radis.liafa.jussieu.fr
Re: ruby1.9.1 migration to testing
On Sun, Oct 23, 2011 at 14:11:26 +0200, Lucas Nussbaum wrote: At this point, I'm confident that we can reach a (at least partially) working Ruby on kfreebsd, sparc and armel at some point. I'm less confident about ia64. Question: what should we do in the meantime? Options are: (1) keep 1.9.3~rc1-1 in unstable until all the issues are fixed. (2) build it with nocheck on ia64, sparc, kfreebsd, so that it can migrate. (3) disable test suite on ia64, sparc, kfreebsd until issues are fixed, so that it can migrate. (4) remove ruby1.9.1 binary packages on ia64, sparc, kfreebsd for now (not really an option due to the large number of reverse dependencies). The version in testing is also affected by most of those issues, and was uploaded by porters after a nocheck build on some architectures. My preference is 3,2,4,1 but I wanted to check with you before going forward. I don't think knowingly shipping a broken package is ok, which means 1 and 4 have my preference. I'm assuming the testsuite failures really mean ruby is broken on those archs; if the failures were for fringe features then my answer would probably be different. I'm also assuming the current version in testing works better; if not then there's no point keeping the newer one out because of this. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003202748.ge3...@radis.liafa.jussieu.fr
Re: mpfr4 FTBFS on sparc
On Tue, Oct 4, 2011 at 21:57:50 +0200, Laurent Fousse wrote: - trying to build upstream source directly (http://www.mpfr.org/mpfr-current/#download) with ./configure make GMP_CHECK_RANDOMIZE=1 make check You'll need libgmp-dev installed. - if it fails, let me know and please send me the config.log file. - if it succeeds, let me know as well :-) Tested on smetana's sid chroot (from sid's source package rather than the upstream url above, let me know if it matters): == 19 of 160 tests failed (1 test was not run) == config.log follows. Cheers, Julien This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by MPFR configure 3.1.0, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure ## - ## ## Platform. ## ## - ## hostname = smetana uname -m = sparc64 uname -r = 2.6.32-5-sparc64-smp uname -s = Linux uname -v = #1 SMP Fri Sep 9 22:15:35 UTC 2011 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/games ## --- ## ## Core tests. ## ## --- ## configure:2534: checking for a BSD-compatible install configure:2602: result: /usr/bin/install -c configure:2613: checking whether build environment is sane configure:2663: result: yes configure:2804: checking for a thread-safe mkdir -p configure:2843: result: /bin/mkdir -p configure:2856: checking for gawk configure:2872: found /usr/bin/gawk configure:2883: result: gawk configure:2894: checking whether make sets $(MAKE) configure:2916: result: yes configure:2988: checking whether to disable maintainer-specific portions of Makefiles configure:2997: result: yes configure:3020: checking build system type configure:3034: result: sparc64-unknown-linux-gnu configure:3054: checking host system type configure:3067: result: sparc64-unknown-linux-gnu configure:3088: checking for grep that handles long lines and -e configure:3146: result: /bin/grep configure:3151: checking for egrep configure:3213: result: /bin/grep -E configure:3218: checking for a sed that does not truncate output configure:3282: result: /bin/sed configure:3452: checking for CC and CFLAGS in gmp.h configure:3481: result: yes CC=sparc-linux-gnu-gcc -std=gnu99 CFLAGS=-Wall -g -O3 configure:3487: checking for CC=sparc-linux-gnu-gcc -std=gnu99 and CFLAGS=-Wall -g -O3 configure:3491: result: yes configure:3553: checking for gcc configure:3580: result: sparc-linux-gnu-gcc -std=gnu99 configure:3809: checking for C compiler version configure:3818: sparc-linux-gnu-gcc -std=gnu99 --version 5 sparc-linux-gnu-gcc (Debian 4.6.1-13) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3829: $? = 0 configure:3818: sparc-linux-gnu-gcc -std=gnu99 -v 5 Using built-in specs. COLLECT_GCC=sparc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6.1/lto-wrapper Target: sparc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-13' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-13) configure:3829: $? = 0 configure:3818: sparc-linux-gnu-gcc -std=gnu99 -V 5 sparc-linux-gnu-gcc: error: unrecognized option '-V' sparc-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:3829: $? = 4 configure:3818: sparc-linux-gnu-gcc -std=gnu99 -qversion 5 sparc-linux-gnu-gcc: error: unrecognized option '-qversion' sparc-linux-gnu-gcc: fatal error: no input files compilation terminated. configure:3829: $? = 4 configure:3849: checking whether the C compiler works configure:3871: sparc-linux-gnu-gcc -std=gnu99 -Wall -g -O3 conftest.c 5 configure:3875: $? = 0 configure:3923: result: yes configure:3926: checking for C compiler default output file name configure:3928: result: a.out configure:3934: checking for suffix of executables configure:3941: sparc-linux-gnu-gcc -std=gnu99 -o conftest -Wall
Re: [sparc64] sudo command causes a bus error
On Thu, Sep 8, 2011 at 11:41:54 +0200, Frans van Berckel wrote: root@deblnxsrv254:~# gdb /usr/bin/sudo GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as sparc64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/sudo...(no debugging symbols found)...done. (gdb) r Starting program: /usr/bin/sudo Program received signal SIGBUS, Bus error. 0xf801008e0220 in ?? () from /usr/lib/sudo/sudoers.so Why is sudoers.so going true it knies? Do I need to build the package my selfs and run some tests? Or do you know what goes on? You need to build the package with debug symbols (usually setting DEB_BUILD_OPTIONS=nostrip in the build environment works), then run gdb on that binary to get more useful information. Bus error most likely means unaligned access, so you'll have to figure out where that comes from. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110908182415.ga5...@radis.liafa.jussieu.fr
Re: libedit.so.2: cannot open shared object file
On Thu, Sep 1, 2011 at 18:27:37 +0200, Frans van Berckel wrote:
On Thu, 2011-09-01 at 15:59 +0200, Josip Rodin wrote:
On Thu, Sep 01, 2011 at 10:15:23AM +0200, Frans van Berckel wrote:
So I found the installed libedit2_2.11-20080614-3_sparc64 package is
only symbolic linking, but does not holds the libedit.so.2.11 it selfs.
Well, try find the build log for the package on sparc64 and see how it
managed to build a package without error but also without a proper result?
:)
Okay comparing the sparc64 and s390x log files. The source of both are
the same. The first diff I have found.
*This is what sparc64 does.*
building standard edit library
ranlib libedit.a
all === readline
touch build-stamp
Looks like a bug in pmake:
NOPIC Do not build PIC versions of system libraries, and
do not build shared libraries. [set if ${MACHINE_ARCH}
is sparc64, unset otherwise.]
That might make sense on NetBSD, it certainly doesn't on Debian.
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110901183648.ga2...@radis.liafa.jussieu.fr
Bug#626054: postgresql-9.0: FTBFS on sparc (testsuite failure)
Package: postgresql-9.0 Version: 9.0.4-1 Severity: serious See https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.0arch=sparcver=9.0.4-1%2Bb1stamp=1304474226 The build of postgresql-8.4 got the exact same error on sparc afaict (https://buildd.debian.org/postgresql-8.4). set -e; \ patch --no-backup-if-mismatch -p1 debian/disable-root-check.patch; \ make -C src/test/regress bigcheck || fail=1; \ patch --no-backup-if-mismatch -Rp1 debian/disable-root-check.patch; \ if [ -n $fail ]; then \ for l in regression.diffs log/initdb.log log/postmaster.log; do \ if [ -e src/test/regress/$l ]; then \ echo * $l ***; \ cat src/test/regress/$l; \ fi; \ done; \ exit 1; \ fi patching file src/backend/main/main.c patching file src/bin/initdb/initdb.c patching file src/bin/pg_ctl/pg_ctl.c Hunk #1 succeeded at 1767 (offset 17 lines). make[1]: Entering directory `/build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress' make -C ../../../src/port all make[2]: Entering directory `/build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/port' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/port' rm -rf ./testtablespace mkdir ./testtablespace ./pg_regress --inputdir=. --dlpath=. --multibyte=SQL_ASCII --temp-install=./tmp_check --top-builddir=../../.. --schedule=./parallel_schedule numeric_big == creating temporary installation== == initializing database system == pg_regress: initdb failed Examine /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/log/initdb.log for the reason. Command was: /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/./tmp_check/install//usr/lib/postgresql/9.0/bin/initdb -D /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/./tmp_check/data -L /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/./tmp_check/install//usr/share/postgresql/9.0 --noclean /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/log/initdb.log 21 make[1]: *** [bigcheck] Error 2 make[1]: Leaving directory `/build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress' patching file src/backend/main/main.c patching file src/bin/initdb/initdb.c patching file src/bin/pg_ctl/pg_ctl.c Hunk #1 succeeded at 1767 (offset 17 lines). * regression.diffs *** * log/initdb.log *** Running in noclean mode. Mistakes will not be cleaned up. fgets failure: Cannot allocate memory The program postgres is needed by initdb but was not found in the same directory as /build/buildd-postgresql-9.0_9.0.4-1+b1-sparc-NUzSQw/postgresql-9.0-9.0.4/src/test/regress/tmp_check/install/usr/lib/postgresql/9.0/bin/initdb. Check your installation. make: *** [binary-predeb/postgresql-9.0] Error 1 Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110508103912.ga29...@radis.liafa.jussieu.fr
Re: bus error in ps2pdf
On Thu, Feb 17, 2011 at 18:12:25 +, c...@spamcop.net wrote: I now have access to a Debian Sparc box, and I can reproduce the problem. The crash happens in the pthreads library, and I find it confusing that this should happen on Linux/Sparc, but no other platforms (that I'm aware of). Looking at the code, there's nothing immediately obvious, unless there is a bug packing unions into structs, causing a pointer alignment problem. Actually, that does seem to be the problem: the second union does not sit on a 64 bit aligned boundary. Yes, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613642#17 Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110217182028.gz12...@radis.liafa.jussieu.fr
Re: cmd64x driver missing from Squeeze initrd
On Sun, Jan 23, 2011 at 18:05:25 +0100, Thomas Zimmermann wrote: Hi ML, I failed to install the Squeeze preview DVD on my Ultra 10 because the driver for the CMD646 IDE chipset is missing from the initrd. This problem has already been reported back in November [1]. Is there any incentive to fix this? Please file a bug against the kernel-wedge package. With a patch would be even better. Cheers, Julien signature.asc Description: Digital signature
Re: SPARC daily d-i builds
On Wed, Jan 12, 2011 at 07:23:29 +, Jurij Smakov wrote: That got me thinking... We had this T2K box (zee) donated a while ago (http://lists.debian.org/debian-sparc/2009/08/msg9.html, for example), and it shows up as a buildd on a machine page, however I don't really remember ever seeing a package built on it. Can you please check what's its state and whether it can be used for these builds? Last I knew, zee was being used as a buildd for the prospective sparc64 port. http://buildd.debian-ports.org/fetch.php?pkg=scidver=1%3A4.2.2.cvs20110111-1arch=sparc64stamp=1294809847file=logas=raw suggests that's still true. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 21:29:07 -0500, Matt Turner wrote: On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault sthiba...@debian.org wrote: Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh rle...@codelibre.net wrote: What's the actual problem --as-needed is trying to solve? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! Using --as-needed is merely papering over the actual root problem. It fixes the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. That should be fixed by removing -lglitz from cairo's .pc file, not by passing --as-needed to the linker. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Tue, Nov 16, 2010 at 01:14:09 +0100, Matthias Klose wrote: On 14.11.2010 13:19, Julien Cristau wrote: On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. I think it is. Besides fixing potential bugs, else you'll never be able to use gold as the linker. See the already filed bug reports. Exactly, see the already filed reports. You don't need to turn them into build failures before you can file reports and send patches. Cheers, Julien signature.asc Description: Digital signature
Re: 64-bit sparc64
On Sun, Nov 14, 2010 at 17:50:09 -0500, David Campbell wrote: Greetings everyone, I have been trying to get a working 64-bit sparc64 system and having a lot of trouble. Today someone in #debian-sparc on oftc gave me a link[1]. I copied and pasted the Apt-lines into my sources.list file and ran sudo apt-get update, but got the errors below. Can anyone tell me where I can get the packages from, or how I can help with this effort? I am very intereted in getting a 64-bit system running to use for HPC doing computational neuroscience research. These apt lines are for the sparc64 arch, not sparc, so you can't directly point apt at them on a sparc install. Either debootstrap with --arch=sparc64, or browse the mirror tree manually. Cheers, Julien signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. --no-add-needed sounds like it'll cause a *lot* of build failures for no particular gain. I don't think it's a good idea. Cheers, Julien signature.asc Description: Digital signature
Re: DM access to sparc porter boxes for bug fixing
On Mon, Oct 11, 2010 at 14:12:19 -0400, Scott Howard wrote: Hello all, Would it be possible to give me access to a sparc porter box? I'm a DM and a current NM applicant that has signed the DMUP and DSC [1]. I'm working on a bug [2] which upstream has submitted a patch for, but neither they nor I have access to a sparc machine to test it. See http://dsa.debian.org/doc/guest-account/ for the debian.org guest account docs. Cheers, Julien signature.asc Description: Digital signature
Re: sparc64 porterbox
On Thu, Sep 23, 2010 at 07:41:50 +0300, Damyan Ivanov wrote: (replying to list; please cc) -=| Alexander Zangerl, Thu, Sep 23, 2010 at 10:41:56AM +1000 |=- On Wed, 22 Sep 2010 18:11:38 +0300, Damyan Ivanov writes: However, there doesn't seem to be a sparc64 porter box available. sparc64 = sparc: the sparc port is interesting insofar as the kernel is 64-bit while userland is 32-bit. ( debian hasn't supported any of the old 32-bit sparc hardware for a few years...) I understand. So what does the sparc64 buildd do differently than the plain sparc one? The sparc port has 64bit kernel and 32bit userspace. The sparc64 port has 64bit kernel and userspace. Cheers, Julien signature.asc Description: Digital signature
Re: sparc64 porterbox
On Thu, Sep 23, 2010 at 13:39:24 +0300, Damyan Ivanov wrote: Right. So I rephrase my initial question: Is there a box (or perhaps a chroot?) that uses 64bit userspace available? Supposedly similar to the one used by the sparc64 buildd? Not AFAIK. Cheers, Julien signature.asc Description: Digital signature
Re: Build of atlas under sparc
On Thu, Sep 9, 2010 at 11:28:46 +0200, Sylvestre Ledru wrote: Hello guys, I would like to know if you could restart the build of the atlas package in unstable. You're asking the wrong people. The buildd admin for each arch is $a...@buildd.d.o. This fails under sparc probably because the machine is too slow: https://buildd.debian.org/fetch.cgi?pkg=atlas;ver=3.8.3-27;arch=sparc;stamp=1283872527 Atlas is doing a lot of computations at build time. Cheers, Julien signature.asc Description: Digital signature
Re: Failed bird/1.2.3-1 build
On Wed, Jul 14, 2010 at 14:23:52 +0200, Ondřej Surý wrote: Hi, could somebody from sparc team take a look at: https://buildd.debian.org/build.php?arch=sparcpkg=birdver=1.2.3-1 It looks like a bug in the toolchain, but I am unable to test it, since I don't have a sparc around me. You can use sperger or smetana. Maybe try passing -Wl,--no-relax in addition to -Wl,-r? Cheers, Julien signature.asc Description: Digital signature
Re: RFH: strace FTBFS
On Wed, May 5, 2010 at 15:31:37 +0200, Frederik Schüler wrote: Hello, currently, the 32bit binary build of strace fails on sparc (the 64bit one succeeds): https://buildd.debian.org/fetch.cgi?amp;pkg=straceamp;ver=4.5.20-2amp;arch=sparcamp;stamp=1273064636amp;file=log gcc -DHAVE_CONFIG_H -I. -I.. -I../linux/sparc -I../linux -Wall -Wall -g -O2 -MT file.o -MD -MP -MF .deps/file.Tpo -c -o file.o ../file.c In file included from ../file.c:88: /usr/include/asm/stat.h:56: error: expected specifier-qualifier-list before 'uid16_t' Looks like a kernel bug, as uid16_t is not available in userspace. Should be fixed by: commit 7469a9acf919d36836f6c635099d8edc9be4528a Author: Rob Landley r...@landley.net Date: Sat Mar 27 08:36:18 2010 -0700 sparc: Fix use of uid16_t and gid16_t in asm/stat.h Signed-off-by: Rob Landley r...@landley.net Signed-off-by: David S. Miller da...@davemloft.net Cheers, Julien signature.asc Description: Digital signature
[SRM] xorg and xorg-server update for lenny
Hi,
the workaround put in xorg-server for 5.0.1 didn't fix the problem on
sparc with pci drivers, and actually made things worse for some people,
so I'd like to revert it in 5.0.2, and try to fix it some other way
instead.
The xorg-server update would:
- remove the patch added in r1
- cherry-pick a patch to fix the idletime xsync timer (see
http://packages.qa.debian.org/g/gnome-session/news/20090521T093223Z.html
and
http://cgit.freedesktop.org/xorg/xserver/commit?id=1f4fb0225b278d1cf4145aebeb0bdd23dc8f62d5)
I'm not attaching the patch here, it's in git, branch debian-lenny, for
those who care.
The sparc workaround is moved to xserver-xorg, which will attempt to
default to the fbdev driver on sparc if no specific fb driver is found,
and regenerate xorg.conf with that.
Lightly tested patch for that follows. I'd appreciate review
(xserver-xorg.postinst makes my head hurt) and testing. (It seems that
the window for 5.0.2 will close soon, so the sooner the better.)
Thanks,
Julien
diff --git a/debian/changelog b/debian/changelog
index 9875bbf..312e98f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xorg (1:7.3+19) UNRELEASED; urgency=low
+
+ * xserver-xorg.postinst: default to the fbdev driver on sparc, even when we
+find PCI devices, to work around #488669.
+
+ -- Julien Cristau jcris...@debian.org Mon, 25 May 2009 14:58:42 +0200
+
xorg (1:7.3+18) unstable; urgency=low
[ Debconf translations ]
diff --git a/debian/xserver-xorg.postinst.in b/debian/xserver-xorg.postinst.in
index db18f53..5beb891 100644
--- a/debian/xserver-xorg.postinst.in
+++ b/debian/xserver-xorg.postinst.in
@@ -175,10 +175,10 @@ discover_sparc_video () {
card='Sun TCX framebuffer'
driver='suntcx'
;;
- 'SUNW,m64B' )
-card='ATI Technologies 3D Rage Pro or similar'
-driver='ati'
-;;
+# 'SUNW,m64B' )
+#card='ATI Technologies 3D Rage Pro or similar'
+#driver='ati'
+#;;
'SUNW,ffb' )
card='Sun Creator3D framebuffer or similar'
driver='sunffb'
@@ -187,10 +187,10 @@ discover_sparc_video () {
card='Sun Elite3D framebuffer or similar'
driver='sunffb'
;;
- 'TSI,gfxp' )
-card='PGX32 framebuffer or similar'
-driver='glint'
-;;
+# 'TSI,gfxp' )
+#card='PGX32 framebuffer or similar'
+#driver='glint'
+#;;
* )
card='Unknown'
server='unknown'
@@ -537,6 +537,9 @@ if [ $ARCH = sparc ]; then
if [ -n $DRIVERS ]; then
NDRIVERS=$(echo $DRIVERS | wc -l)
DRIVERS_LIST=$(echo $DRIVERS | awk 'BEGIN {ORS=;FS=\t} {if(NR
1){print last ,};last=$0} END {print last}')
+ else
+DRIVERS=fbdev
+DRIVERS_LIST=fbdev
fi
if [ $MULTIHEAD -gt 1 ]; then
MULTIHEAD=yes
@@ -928,7 +931,8 @@ fi
# Don't touch the config on upgrades except to deal with known issues with old
# configs.
-if [ -z $UPGRADE ] || dpkg --compare-versions $2 le 1:7.0.14; then
+if [ -z $UPGRADE ] || dpkg --compare-versions $2 le 1:7.0.14 || \
+ [ $ARCHITECTURE = sparc ] dpkg --compare-versions $2 lt-nl 1:7.3+19;
then
# compare the current and stored checksums; if they do not match, assume
# that's the way the user wants it. if we're reconfiguring, overwrite
# it regardless and back it up.
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [FIX]: ultra45 boot failing...
On Wed, Feb 25, 2009 at 13:41:08 +0100, Julien Cristau wrote: On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote: On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote: No, I would have said that if time is tight at least we can use fbdev as the Xorg driver for PCI devices on sparc until we have a better fix for Xorg. We can probably do that for r1. OK so here is a tentative patch to fall back to the fbdev driver on sparc. I'd appreciate if people could test it against lenny's xorg-server, and/or suggest better ways to do this. That patch doesn't work, because X craps itself if both a pci and a fb driver are loaded. I plan to revert it for lenny r2, and if time permits I'll try to make the xserver-xorg package generate an xorg.conf with Driver set to fbdev instead.. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Rebuild attempt of python-nifti
On Tue, May 19, 2009 at 20:46:30 +0200, Michael Hanke wrote: Hi, could you please trigger a rebuild attempt of the python-nifti package. Its last attempt failed due to an uninstallable tex-common package: https://buildd.debian.org/fetch.cgi?pkg=pyniftiver=0.20090303.1-1arch=sparcstamp=1237624043file=log which has been (potentially) fixed with version 1.18 of tex-common. You want sp...@buildd.d.o, or debian-wb-t...@lists.d.o, to reach the buildd people. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian unusable on niagara
On Sun, May 3, 2009 at 13:09:23 -0700, David Miller wrote: The issue is one of communication. If the debian sparc folks don't communicate with me, things break. This has been proven over and over again, and the distributions with people who communicate actively with me over Sparc issues are the ones that get this stuff fixed promptly before it sneaks into a real release. As far as I can tell, the main issue is that nobody's actively working on the debian sparc port in the first place. And without active maintainers, that port is actually a disservice to users and the sparc linux community. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian unusable on niagara
On Mon, May 4, 2009 at 11:12:38 +0200, Josip Rodin wrote: On Mon, May 04, 2009 at 09:40:26AM +0200, Julien Cristau wrote: As far as I can tell, the main issue is that nobody's actively working on the debian sparc port in the first place. And without active maintainers, that port is actually a disservice to users and the sparc linux community. Even if nobody is currently volunteering to explicitly state that they are working on the port as a whole (which has always been a fairly vague concept anyway), the software is generally working fine (yes, even if it has bugs), the buildds are happily churning (and are actually actively maintained), new users do actually regularly come through, so I fail to see how it's a disservice to everyone. And yet sid's kernel has been broken for some time without anyone noticing. And yet nobody replies when a package maintainer needs a patch tested and asks on the port mailing list (which means X is broken in lenny right now). What is that statement supposed to mean, anyway? Would you prefer if the port didn't exist at all? Than continue to exist without anyone volunteering to maintain it? Yes. But hey, you can still change that... Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS on sparc: __sync_test_and_add_4
On Wed, Apr 29, 2009 at 14:11:11 +1000, Felipe Sateler wrote: Hi sparc porters. I'm writing to ask for your assistance on a FTBFS on my package csound on sparc. The build log is here[1]. The failure is the following: libCsoundAC.so.5.2: undefined reference to `__sync_fetch_and_add_4' Csound uses __sync_lock_test_and_set for spinlocks, and tests for their existence at build time to use them. Sparc's gcc apparently provides said function, since the test succeeds, but I'm getting the above failure (note that __sync_fetch_and_add_4 is nowhere mentioned in the csound sources). Hi, any reason you're not using libatomic-ops? Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS on sparc: __sync_test_and_add_4
On Thu, Apr 30, 2009 at 00:40:32 +1000, Felipe Sateler wrote: El 29/04/09 23:02 Julien Cristau escribió: any reason you're not using libatomic-ops? This is the first time I heard about libatomic-ops. Is it cross-platform? I mean cross-platform as in OS, not arch, which it clearly is. Its homepage at http://www.hpl.hp.com/research/linux/atomic_ops/ suggests that it is. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: X/GDM fails on Ultra 10 w/ Creator 3D under Lenny
On Mon, Apr 20, 2009 at 22:53:47 -0500, Jon Pruente wrote: Build Operating System: Linux Debian (xorg-server 2:1.4.2-10.lenny1) Looks like this got broken by the xorg-server patch in lenny r1. You should be able to install the version of the xserver-xorg-core package released with lenny r0 and use that. I'd appreciate a patch to fix this mess though, as I can't fix this myself, not having any sparc hardware. Otherwise I guess sparc X users will be SOL on lenny... Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny Sunblade 150 xserver issue
On Mon, 2009-04-13 at 13:32 +0530, निशांत / Nishant wrote:
Hi,
I had successfully upgraded to Debian Lenny from Etch on my
SunBlade150 15 days back.
Everything was working fine until today morning when I did aptitude
safe-upgrade and it upgraded xserver-xorg-core package. After upgrade,
xserver does not start and I see a black screen with a non-blinking
cursor on the top left corner. Keyboard is alive as I can see
Num/Caps/Scroll lock keypresses lighting up respective LEDs, but
pressing CTRL-ALT-F{1..6} does not have any effect.
I had to hard reboot the machine in single user mode and disable GDM
from starting up.
Doing
dpkg-reconfigure -plow xserver-xorg xserver-xorg-core
generated a new xorg.conf file but again no luck. Replacing driver
ati with vesa is not helping anyhow.
Any pointers?
See bug#488669. I asked for testers a few times on this list, but to no
avail... Can you send your xorg.conf, the X log from the failure, and
the contents of /proc/fb?
Thanks,
Julien
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny Sunblade 150 xserver issue
On Mon, 2009-04-13 at 16:47 +0530, निशांत / Nishant wrote: Also, Xorg.0.log file is not updated at every failure. The log pasted here is of the last but one X start attempt. Can you add the following to xorg.conf: Section ServerFlags Option Log sync EndSection so there's a better chance to get a complete log? Thanks, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: x-www-browser for ultra5 ultra60
On Mon, 2009-04-13 at 12:17 -0400, Howard Eisenberger wrote: On 2009-03-26, Howard Eisenberger wrote: On 2009-03-25, Julien Cristau wrote: It'd be nice if someone could try the attached patch on sparc and see if they can reproduce the browser crash. It works! With the new libnssd3.so.1d, iceweasel 3.0.7 does not crash on the problem sites on my Ultra 5. Has anyone else tried this patch? I have been using it now for almost three weeks without a single crash. The bug was fixed using a different patch in nss 3.12.2.with.ckbi.1.73-2. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: x-www-browser for ultra5 ultra60
On Wed, 2009-03-25 at 21:20 +0100, Mike Hommey wrote: On Wed, Mar 25, 2009 at 09:14:56AM +0100, Julien Cristau wrote: On Wed, 2009-03-25 at 07:47 +0100, Julien Cristau wrote: I've spent some time looking at this, and I'm a bit worried about PKIX_PL_Object_Alloc. Specifically, sizeof(PKIX_PL_Object) seems to be 28 on 32bit, and __alignof__(PKIX_PL_Object) is 4. PKIX_PL_Object_Alloc goes to allocate some space for one PKIX_PL_Object + the size it was asked for, and then goes and returns object + 1. Thus, if PKIX_PL_Malloc gives it a 8 byte aligned pointer, PKIX_PL_Object_Alloc will return an unaligned address to its caller. PKIX_PL_OcspResponse's size is 56, and it has to be 8 byte aligned on sparc, so it's possible this is the problem here. It'd be nice if someone could try the attached patch on sparc and see if they can reproduce the browser crash. Wouldn't it be simpler to make PKIX_PL_Object 32 bytes ? That would work too (hopefully not increasing its 40 bytes on 64bit). Not sure which one is simpler. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: x-www-browser for ultra5 ultra60
On Wed, 2009-03-25 at 04:58 +, Howard Eisenberger wrote: On 2009-03-25, Julien Cristau wrote: Core was generated by `/usr/lib/iceweasel/firefox-bin -a iceweasel https://signin.ebay.ca/ws/eBayISAPI'. Program terminated with signal 10, Bus error. #0 0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=value optimized out, generalized=2) at dertime.c:311 #1 0xf69bf780 in DER_GeneralizedTimeToTime_Util (dst=0x115f574, time=value optimized out) at dertime.c:239 dertime.c:311 seems to be: *dst = PR_ImplodeTime(genTime); PR_ImplodeTime returns an int64. Here dst is 0x115f574, which is not aligned on a double-word boundary. So that'd explain the SIGBUS. The backtrace you get doesn't go further? It'd be nice to know what the DER_GeneralizedTimeToTime_Util caller is... I saved it this time. Not sure how much you need, but here is a bit more. #0 0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=value optimized out, generalized=2) at dertime.c:311 #1 0xf69bf780 in DER_GeneralizedTimeToTime_Util (dst=0x115f574, time=value optimized out) at dertime.c:239 #2 0xf6aa4f54 in pkix_pl_OcspResponse_VerifySignature (response=0x115f554, cert=0x1159b74, procParams=0x11437e4, pPassed=0xf2cea084, #pNBIOContext=0xf2cea078, plContext=0x1143150) at pkix_pl_ocspresponse.c:883 #3 0xf6a5b610 in pkix_OcspChecker_Check (checkerObject=0x1148e8c, #cert=0x1159b74, procParams=0x11437e4, pNBIOContext=0xf2cea19c, #pResultCode=0xf2cea190, plContext=0x1143150) at pkix_ocspchecker.c:266 #4 0xf6a72bb4 in pkix_CheckChain (certs=0x115ad44, numCerts=2, #checkers=0x115ad0c, revCheckers=0x115f0e4, removeCheckedExtOIDs=0x115e8b4, #procParams=0x11437e4, pCertCheckedIndex=0x11588f4, pCheckerIndex=0x11588f8, pRevChecking=0x115891c, pReasonCode=0x1158908, #pNBIOContext=0xf2cea284, pFinalSubjPubKey=0xf2cea290, pPolicyTree=0xf2cea28c, pVerifyTree=0x0, plContext=0x1143150) at pkix_validate.c:354 #5 0xf6a76284 in pkix_Build_ValidateEntireChain (state=0x11588d4, anchor=0x11432ec, pNBIOContext=0xf2cea45c, pValResult=0xf2cea488, #verifyNode=0x1159184, plContext=0x1143150) at pkix_build.c:1619 #6 0xf6a7a734 in pkix_BuildForwardDepthFirstSearch #(pNBIOContext=0xf2cea654, state=0x11588d4, pValResult=0xf2cea64c, #plContext=0x1143150) at pkix_build.c:3052 I've spent some time looking at this, and I'm a bit worried about PKIX_PL_Object_Alloc. Specifically, sizeof(PKIX_PL_Object) seems to be 28 on 32bit, and __alignof__(PKIX_PL_Object) is 4. PKIX_PL_Object_Alloc goes to allocate some space for one PKIX_PL_Object + the size it was asked for, and then goes and returns object + 1. Thus, if PKIX_PL_Malloc gives it a 8 byte aligned pointer, PKIX_PL_Object_Alloc will return an unaligned address to its caller. PKIX_PL_OcspResponse's size is 56, and it has to be 8 byte aligned on sparc, so it's possible this is the problem here. Mike, any idea? Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: x-www-browser for ultra5 ultra60
On Wed, 2009-03-25 at 07:47 +0100, Julien Cristau wrote:
I've spent some time looking at this, and I'm a bit worried about
PKIX_PL_Object_Alloc. Specifically, sizeof(PKIX_PL_Object) seems to be
28 on 32bit, and __alignof__(PKIX_PL_Object) is 4. PKIX_PL_Object_Alloc
goes to allocate some space for one PKIX_PL_Object + the size it was
asked for, and then goes and returns object + 1. Thus, if
PKIX_PL_Malloc gives it a 8 byte aligned pointer, PKIX_PL_Object_Alloc
will return an unaligned address to its caller. PKIX_PL_OcspResponse's
size is 56, and it has to be 8 byte aligned on sparc, so it's possible
this is the problem here.
It'd be nice if someone could try the attached patch on sparc and see if
they can reproduce the browser crash.
Cheers,
Julien
diff -u nss-3.12.2.with.ckbi.1.73/debian/changelog nss-3.12.2.with.ckbi.1.73/debian/changelog
--- nss-3.12.2.with.ckbi.1.73/debian/changelog
+++ nss-3.12.2.with.ckbi.1.73/debian/changelog
@@ -1,3 +1,9 @@
+nss (3.12.2.with.ckbi.1.73-2) UNRELEASED; urgency=low
+
+ * Make sure PKIX_PL_Object_Alloc returns an aligned pointer.
+
+ -- Julien Cristau jcris...@debian.org Wed, 25 Mar 2009 08:38:37 +0100
+
nss (3.12.2.with.ckbi.1.73-1) unstable; urgency=low
* debian/patches/38_kbsd.dpatch: Brown paper bag fix for regression
only in patch2:
unchanged:
--- nss-3.12.2.with.ckbi.1.73.orig/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.c
+++ nss-3.12.2.with.ckbi.1.73/mozilla/security/nss/lib/libpkix/pkix_pl_nss/system/pkix_pl_object.c
@@ -561,6 +561,7 @@
{
PKIX_PL_Object *object = NULL;
pkix_ClassTable_Entry *ctEntry = NULL;
+PKIX_UInt32 alloc_size;
PKIX_ENTER(OBJECT, PKIX_PL_Object_Alloc);
PKIX_NULLCHECK_ONE(pObject);
@@ -605,17 +606,20 @@
PORT_Assert(size == ctEntry-typeObjectSize);
-/* Allocate space for the object header and the requested size */
+/* Allocate space for the object header and the requested size,
+ * and make sure that we return an aligned pointer */
+alloc_size = ((sizeof(PKIX_PL_Object) + 7) ~7) + size;
+
#ifdef PKIX_OBJECT_LEAK_TEST
PKIX_CHECK(PKIX_PL_Calloc
(1,
-((PKIX_UInt32)sizeof (PKIX_PL_Object))+size,
+alloc_size,
(void **)object,
plContext),
PKIX_MALLOCFAILED);
#else
PKIX_CHECK(PKIX_PL_Malloc
-(((PKIX_UInt32)sizeof (PKIX_PL_Object))+size,
+(alloc_size,
(void **)object,
plContext),
PKIX_MALLOCFAILED);
@@ -641,7 +645,7 @@
/* Return a pointer to the user data. Need to offset by object size */
-*pObject = object + 1;
+*pObject = (PKIX_PL_Object *)char*)object) + alloc_size - size));
object = NULL;
/* Atomically increment object counter */
Re: x-www-browser for ultra5 ultra60
On Wed, 2009-03-25 at 01:44 +, Howard Eisenberger wrote: #0 0xf69776bc in ?? () from /usr/lib/libnssutil3.so.1d (gdb) bt #0 0xf69776bc in ?? () from /usr/lib/libnssutil3.so.1d #1 0xf69776bc in ?? () from /usr/lib/libnssutil3.so.1d Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) quit You'll want to install libnss3-1d-dbg to get something meaningful here. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: x-www-browser for ultra5 ultra60
On Wed, 2009-03-25 at 03:55 +, Howard Eisenberger wrote: Core was generated by `/usr/lib/iceweasel/firefox-bin -a iceweasel https://signin.ebay.ca/ws/eBayISAPI'. Program terminated with signal 10, Bus error. [New process 2771] #0 0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=value optimized out, generalized=2) at dertime.c:311 311 dertime.c: No such file or directory. in dertime.c (gdb) bt #0 0xf69bf6bc in der_TimeStringToTime (dst=0x115f574, string=value optimized out, generalized=2) at dertime.c:311 #1 0xf69bf780 in DER_GeneralizedTimeToTime_Util (dst=0x115f574, time=value optimized out) at dertime.c:239 dertime.c:311 seems to be: *dst = PR_ImplodeTime(genTime); PR_ImplodeTime returns an int64. Here dst is 0x115f574, which is not aligned on a double-word boundary. So that'd explain the SIGBUS. The backtrace you get doesn't go further? It'd be nice to know what the DER_GeneralizedTimeToTime_Util caller is... Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [FIX]: ultra45 boot failing...
On Wed, 2009-02-25 at 13:41 +0100, Julien Cristau wrote: On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote: On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote: No, I would have said that if time is tight at least we can use fbdev as the Xorg driver for PCI devices on sparc until we have a better fix for Xorg. We can probably do that for r1. OK so here is a tentative patch to fall back to the fbdev driver on sparc. I'd appreciate if people could test it against lenny's xorg-server, and/or suggest better ways to do this. I uploaded this to stable-proposed-updates, sparc binaries should appear after the next mirror push. There's still time to tweak things before the point release, so testing reports from sparc X users to 488...@bugs.debian.org are welcome (whether things work or not). Make sure you have xserver-xorg-video-fbdev installed. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [FIX]: ultra45 boot failing...
On Mon, 2009-02-09 at 12:49 +0100, Julien Cristau wrote: On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote: No, I would have said that if time is tight at least we can use fbdev as the Xorg driver for PCI devices on sparc until we have a better fix for Xorg. We can probably do that for r1. OK so here is a tentative patch to fall back to the fbdev driver on sparc. I'd appreciate if people could test it against lenny's xorg-server, and/or suggest better ways to do this. Cheers, Julien 0001-Add-an-fbdev-screen-as-a-fallback-on-sparc.patch Description: application/mbox
Re: [FIX]: ultra45 boot failing...
On Mon, 2009-02-09 at 01:21 -0800, David Miller wrote: No, I would have said that if time is tight at least we can use fbdev as the Xorg driver for PCI devices on sparc until we have a better fix for Xorg. We can probably do that for r1. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian+KDE for SPARC
On Tue, 2009-01-20 at 08:53 +, Mark Morgan Lloyd wrote: xorg.conf does get rewritten by an apt-get upgrade on x86 Lenny, and If so that's a pretty serious bug. But I can't see how that could happen in an etch-lenny upgrade, so any details (preferrably in a bug report against xserver-xorg) would be appreciated. I've certainly seen that happen on SPARC with older versions. I know that DefaultDepth is what I want, but what I don't know is why the installer is setting it to the default 24 for hardware that doesn't have that capability. We've stopped setting the depth in xorg.conf about a year ago. Which makes the driver responsible for picking the depth. Unfortunately the suncg6 driver doesn't seem to do that quite right; we have a fix sitting in git since November 2007, but it looks like that was never uploaded. *sigh*. I'll try to get that fixed, thanks for pointing it out. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
freeze exception for xserver-xorg-video-suncg6
On Tue, 2009-01-20 at 10:35 +, Julien Cristau wrote: On Tue, 2009-01-20 at 08:53 +, Mark Morgan Lloyd wrote: I know that DefaultDepth is what I want, but what I don't know is why the installer is setting it to the default 24 for hardware that doesn't have that capability. We've stopped setting the depth in xorg.conf about a year ago. Which makes the driver responsible for picking the depth. Unfortunately the suncg6 driver doesn't seem to do that quite right; we have a fix sitting in git since November 2007, but it looks like that was never uploaded. *sigh*. I'll try to get that fixed, thanks for pointing it out. Fixed in xserver-xorg-video-suncg6/1:1.1.0-5, just uploaded thanks to Bernd Zeimetz. -release, can I get a freeze exception for this? Thanks, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian+KDE for SPARC
On Mon, 2009-01-19 at 23:24 +, Mark Morgan Lloyd wrote: Also, if installing on a machine with cg6 is it possible to lock xorg.conf down to 8 bits (the hardware won't do the default 24) such that it doesn't revert on upgrades? Nothing should mess with xorg.conf on upgrades, so any modification you make will be respected. The DefaultDepth directive in the Screen section is probably what you want. Cheers, Julien -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#490999: gcc-4.3 / qt3 misalignment
On Sun, 2008-12-07 at 20:16 +0100, Baurzhan Ismagulov wrote: Now that #506713 is closed, I have a couple of questions regarding the process: * The closing message mentions experimental; will the package be available in lenny? If yes, will this happen automatically, or does someone need to do something? Not automatically. The package will be available in lenny if 1) the maintainer uploads it to unstable, and 2) the release managers then let it migrate to testing. * When a newer compiler package is available for a distribution, is everything rebuilt with it? No. * Are the package versions of everything bumped? Their sources have not been changed, but the binaries built with the (now fixed) compiler have. How is it ensured that users get the new binaries? Rebuilt binaries get their version number bumped. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500358: Fix found
On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote: The first patch is fine. The revert is not. Even if the revert is the only way to get X to work on those machines in lenny? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500358: Fix found
On Tue, Nov 11, 2008 at 22:10:03 +0100, Bastian Blank wrote: On Tue, Nov 11, 2008 at 08:20:01PM +0100, Julien Cristau wrote: On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote: The first patch is fine. The revert is not. Even if the revert is the only way to get X to work on those machines in lenny? I fail to see the _kernel_ bug it fixes. I now know that this change triggers a bug in the old (considered broken by design[1]) PCI code in _X.org_. The revert doesn't fix a kernel bug. It works around an X bug. I thought that was clear all along, sorry if it wasn't. Even if the revert breaks other things, it wouldn't be a regression from previous releases, though. We're not going to ship a newer Xorg in lenny, so with that revert we'd be fixing a known important regression by reopening a long-standing bug. I agree it's not ideal, but it doesn't seem like we can make everyone happy here, and that seems to be the least bad solution for this bug as far as lenny is concerned. Thanks for considering it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: XVR-500 support in Lenny
On Mon, Oct 20, 2008 at 22:55:18 -0400, Dave Barnett wrote: [I was expecting to find information that tells me where the config file details are contained on a running system (under /proc, I thought), but I haven't found that, yet Perhaps that functionality isn't available / compiled into the sparc kernels...] The Debian kernels install the config in /boot/config-$(uname -r). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#501825: libjson-xs-perl_2.23-1(sparc/unstable): FTBFS on sparc, fails in tests
On Wed, Oct 15, 2008 at 23:39:52 +0300, Niko Tyni wrote: This is reproducible on sperger.d.o. It's an alignment problem that only shows up with an optimization level of at least -O2. Program received signal SIGBUS, Bus error. 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443 1443 SvGROW (string, SvCUR (string) + 1); // should basically be a NOP (gdb) bt #0 0xf7ec1134 in decode_json (string=0x192280, json=0x39f18, offset_return=0xff85b96c) at XS.xs:1443 #1 0xf7ec2444 in XS_JSON__XS_incr_parse (my_perl=0x22008, cv=0x126d58) at XS.xs:1828 #2 0xf7dfab48 in Perl_pp_entersub () from /usr/lib/libperl.so.5.10 #3 0xf7df8f9c in Perl_runops_standard () from /usr/lib/libperl.so.5.10 #4 0xf7df4298 in perl_run () from /usr/lib/libperl.so.5.10 #5 0x00010b88 in main () The instruction that causes the bus error is a double-word load (ldd): 0xf7ec1130 decode_json+132: ld [ %l1 ], %g1 0xf7ec1134 decode_json+136: ldd [ %g1 + 8 ], %g2 0xf7ec1138 decode_json+140: inc %g2 0xf7ec113c decode_json+144: cmp %g3, %g2 The preprocessor output for the above SvGROW() macro invocation is (((XPV*) (string)-sv_any)-xpv_len (((XPV*) (string)-sv_any)-xpv_cur + 1) ? Perl_sv_grow(((PerlInterpreter *)pthread_getspecific((*Perl_Gthr_key_ptr(((void *)0), string,((XPV*) (string)-sv_any)-xpv_cur + 1) : ((string)-sv_u.svu_pv)); and the above assembly is the compiled form of the first comparison at -O2. The compiler is using a double-word instruction to load both xpv_cur and xpv_len in one go. Now, this apparently requires that ((XPV*) (string)-sv_any)-xpv_cur is aligned on a double-word (64-bit) boundary, which fails here: [...] This suggests to me that gcc is being too aggressive on optimizing here. I don't see how it can consider the double word instruction safe. __alignof__(XPV) is 8, so gcc is allowed to assume that any XPV is 64-bit aligned, as far as I can tell. xpv_cur's offset is 8, so it should also be 64-bit aligned. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xorg with ATI driver and Linux 2.6.25 (on Ultra 5)
On Sat, Sep 27, 2008 at 15:22:49 +0200, Josip Rodin wrote: On Sat, Sep 27, 2008 at 02:53:46PM +0200, Julien Cristau wrote: On Sat, Sep 27, 2008 at 14:48:42 +0200, Josip Rodin wrote: Oh, and we already have one in 488669, but it's filed against the core X server package. I'll leave it to the X guys to decide where to merge. In any case it's a clear regression from etch. :( Feel free to provide a patch, or revert the kernel changes that broke X. The X guys are not sparc porters, don't have access to sparc hardware, and the affected code is very much arch-specific. All of them? Nobody upstream? Sparc patches that I've seen go upstream lately came mostly from davem. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xorg with ATI driver and Linux 2.6.25 (on Ultra 5)
On Sat, Sep 27, 2008 at 14:48:42 +0200, Josip Rodin wrote: Oh, and we already have one in 488669, but it's filed against the core X server package. I'll leave it to the X guys to decide where to merge. In any case it's a clear regression from etch. :( Feel free to provide a patch, or revert the kernel changes that broke X. The X guys are not sparc porters, don't have access to sparc hardware, and the affected code is very much arch-specific. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xorg not working on 2.6.24-1 (smp and single)
On Tue, Jul 15, 2008 at 09:07:05 +0200, Frans Pop wrote: Howard Eisenberger wrote: I just came across this message and didn't see a response. Did you find a fix? X.Org X Server 1.4.0.90 Are you running Debian? 1.4.0 is not a current version in either testing or unstable. The log had this line just below: Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20080517-1) :) Current Operating System: Linux ULTRA5 2.6.24-1-sparc64-smp #1 SMP Thu This is quite likely in some way related to: http://lkml.org/lkml/2008/6/3/147 I don't think you will get any real help with this unless you first try with at least kernel 2.6.26 (which includes the change referenced in that thread) and xserver 1.4.2. AIUI that change was made after 2.6.25, so the problem with 2.6.24 is probably different? If I understand correctly, the change mentioned in that thread will break X server versions 1.5 on kernels 2.6.25 (which sounds like it would be a problem for lenny if we go for .26, but anyway). The problem with 2.6.24 (xf86MapDomainMem() failure) looks like the one that's been reported as bug #488669, for which help would be appreciated. Knowing what kernel broke it would be a good start, I guess. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Newer kernels not seen by apt
On Fri, Feb 29, 2008 at 23:31:16 +, Jurij Smakov wrote: Hi, I've noticed something strange: even though the newer versions of the kernel (like linux-image-2.6.24) for sparc have been uploaded to the archive [0], they are not showing up in 'apt-cache search' and cannot be installed using apt-get. The last kernel I see with 'apt-cache search' is linux-image-2.6.22-3-sparc64. Is it just some misconfiguraiton on my end, or other are experiencing that as well? APT seems to find it just fine here: $ apt-cache policy linux-image-2.6.24-1-sparc64 linux-image-2.6.24-1-sparc64: Installed: (none) Candidate: 2.6.24-4 Version table: 2.6.24-4 0 500 ftp://mirror.ens-lyon.fr sid/main Packages 2.6.22 is in lenny though, so either your mirror is outdated or you have no 'sid' sources in sources.list? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: zdotu_ problem on libblas3gf on sparc and alpha
Hi, I ran your test programs on sparc, with the following results: On Sat, Feb 16, 2008 at 23:17:09 +0530, Kumar Appaiah wrote: 1. Please build and run the following programs g++ progfile.cpp -lblas should do. Program 1 - $ make blastest1 CXXFLAGS='-Wall -g' LDFLAGS=-lblas g++ -Wall -g -lblas blastest1.cpp -o blastest1 $ ./blastest1 Illegal instruction Program 2 - $ make blastest2 CXXFLAGS='-Wall -g' LDFLAGS=-lblas g++ -Wall -g -lblas blastest2.cpp -o blastest2 $ ./blastest2 $ echo $? 1 Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ultra Sparc 45 Workstation
On Fri, Jan 18, 2008 at 17:07:30 +0100, Jachym Cepicky wrote: when I try to run lspci and/or Xorg -scanpci to find out, which PCI number to use, I'm confused lspci gives me [1] [...] 0001:00:00.0 Host bridge [0600]: 3DLabs Unknown device [3d3d:0032] (rev 01) 0001:02:00.0 VGA compatible controller [0300]: 3DLabs Unknown device [3d3d:0032] (rev 01) (prog-if 00 [VGA]) where Xorg -scanpci returns [2] (2:0:0) PLX Technology, Inc. PEX 8532 Versatile PCI Express Switch (3:1:0) PLX Technology, Inc. PEX 8532 Versatile PCI Express Switch (3:2:0) PLX Technology, Inc. PEX 8532 Versatile PCI Express Switch (3:3:0) PLX Technology, Inc. PEX 8532 Versatile PCI Express Switch [snip] hmm, so your graphics card is on a different PCI domain. Multiple PCI domain support in X is not very good (it's a hack), and I'm not quite sure it all works right now. This should all be fixed in Xorg 1.5, which will include a complete rework of the PCI access code, but that's not out yet. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Any progress?
On Mon, Oct 8, 2007 at 16:15:48 +0200, Mario Iseli wrote: So, who wants to help us? (I CCed [EMAIL PROTECTED], maybe there are some other people who are interested in rescuing the sparc32 arch) I'm not sure what the point of using a different list for the 1 or 2 people interested in sparc32 is going to help you. It's not like debian-sparc is overcrowded. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Any progress?
On Mon, Oct 8, 2007 at 19:26:49 +0100, Chris Andrew wrote: Hi, Julien. People have mentioned sparc (32) becoming a separate port on Debian, so that we can rally the troops and make a concerted effort. This idea seems not to be of any interest, so I think that it is good that this list has been created. We need to get a greater readership, though. Not sure how. Right, and I'm saying that using a new list with no subscribers isn't the greatest idea if you want to get a broader readership. IMHO, YMMV, etc. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sparc32 systems and power consumption
On Fri, Jul 27, 2007 at 17:22:48 +0200, Ludovic Courtès wrote: Maybe it's time to somehow re-spawn Debian GNU/kNetBSD since NetBSD is apparently paying more attention to avoiding regressions than Linux (that's a euphemism---but I don't want this to sound too harsh, though, being myself a humble luser). Are you going to port glibc to netbsd/sparc? Cheers, Julien
Re: Sun Ultra-10 and debian-sparc
On Tue, Jul 24, 2007 at 12:44:50 -0400, ISHWAR RATTAN wrote: I may the above box available, the dept is retiring it. Does debian-sparc install/work on it? I assume that it is a 32-bit processor machine. An ultra sparc is 64-bit, so it should be fine. Cheers, Julien signature.asc Description: Digital signature
Re: Sparcstation20 (32 bit) user needs good /etc/apt/sources.list
On Mon, Jul 23, 2007 at 00:22:52 +0100, Chris Andrew wrote: Ludovic, Thank you for your reply. As mentioned, I did a dist-upgrade from Sarge. I can confirm that I am now running Debian 4.0 (Etch). Unfortunately, when I try to check for updates, I have problems with the following packages: apt apt-utils aptitude The problem I have with all three is that I get an error message that says a public key is not available, therefore the packages can't be identified. That should not happen with official packages after you've run aptitude (or apt-get) update. i am asked whether I should install anyway, to which I answer yes. I get script errors when these packages try to configure, and a complaint that apt-utils is not installed prevents me from configuing many packages. That's not an error, AFAIK. I am unable to do a straight install from CD of Etch, because I am told that the ESP module that supports my CDROM, is broken, and it is not fixed until 2.6.22, which Debian isn't using, yet. In summary, I need to work out how to overcome the key problem. It has been suggested that I upgrade my debian-archive-keyring (I think), but I am told this is the newest version, already. I would appreciate any help. It'd help if you said exactly which error messages you get, and what your sources.list looks like. Any unofficial sources there would cause that warning about a missing key. Cheers, Julien signature.asc Description: Digital signature
Re: linking SPARC applications
On Sat, Jul 21, 2007 at 22:38:05 +1000, Jim Watson wrote: Yes, but I like them to run on sparc (32) systems too. Previously they always linked to /lib/blah. Now something has changed so they now link to /lib/v9/blah But I didn't change my build system so I guess it is something changed in debian. Thats the bit I don't understand - what has changed? You have installed libc6-sparcv9. ld.so uses the optimized libraries if available and if the hardware supports it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linking SPARC applications
On Sat, Jul 21, 2007 at 23:56:41 +1000, Jim Watson wrote: Thank you Julien, that was it. I removed that package and the linking is fixed. The linking was just fine, and removing the package just means you lose the optimizations. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: please re-try geomview
On Wed, Jun 20, 2007 at 18:51:58 -0500, Steve M. Robbins wrote: Hi, Would the maintainer of the sparc buildd please have it re-try geomview? The last attempt failed with an apparently transient error: The contact address for the buildd maintainer is [EMAIL PROTECTED] HTH, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build sparc32 kernel deb on sparc64
On Sun, Jun 3, 2007 at 17:30:15 -0400, Robert Reif wrote: This doesn't work for me: netra:/usr/src/linux-2.6# sparc32 bash -bash: sparc32: command not found What package do I need to do this? I just installed the standard (minimum) packages. sparc-utils Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude asks for installation CD
On Fri, Apr 20, 2007 at 13:07:54 -0400, Desmond Rivet wrote: Hi all, Hi Desmond I just installed Debian 4.0 SPARC on my Ultra 10 and it seems to work fine so far. The only glitch I have (so far) is that aptitude keeps asking me for the Network installation CD every time I want to install a piece of software. Things work fine once I put the CD in the drive. I have installed Debian 3.1 on another (Intel) machine and this doesn't happen. Any thoughts on how I could stop this? Thanks in advance. Delete the line referring to the CD from /etc/apt/sources.list keeping only network sources, that should do it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dropping sparc32 for lenny
On Sun, Apr 15, 2007 at 17:22:09 -0400, Robert Reif wrote: Jurij Smakov wrote: Hi, Now that we have released, we need to set our goals for the future. As you probably guessed from the subject, I am strongly in favor of dropping sparc32 support for lenny. There are multiple reasons for it, including * Nearly complete lack of upstream support. David Miller, current upstream maintainer of sparc64 has expressed his thoughts on the topic in [0], triggering the discussion about dropping sparc32 support in Aurora Linux. [1] * Several serious problems, like lack of SMP support and driver failures (CD-ROMs do not work for some reason). * Shrinking userbase, flaky hardware. [snip] Why can't you have official sparc32 and sparc64 ports? That way you can optimize sparc64 and still have sparc32 support. Did you read what Jurij wrote? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test the new kernel (2.6.18.dfsg.1-9)
On Thu, Jan 25, 2007 at 22:28:12 -0800, Jurij Smakov wrote: Hi, A set of new kernel images has been uploaded to unstable a couple of days ago, including linux-image-2.6.18-4-sparc64_2.6.18.dfsg.1-9_sparc.deb Seems to work fine on my ultra 5. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: missinglib: ftbfs [sparc] *** [test] Bus error
forwarded 344615 http://caml.inria.fr/mantis/view.php?id=3944 kthxbye On Mon, Jan 2, 2006 at 12:26:14 +, Jurij Smakov wrote: ldd is a double-word load, so the first argument (the memory location) must be double-word aligned. I bet it's not (what's the value of %i1?) and that's what causes the bus error. %i1 contains 0xa3f74, which is indeed not double-word aligned. The ocaml float allocation function doesn't take care of alignment, so we've reported this problem upstream. Thanks a lot, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: missinglib: ftbfs [sparc] *** [test] Bus error
On Fri, Dec 23, 2005 at 19:43:50 -0800, Blars Blarson wrote: Package: missinglib Version: 0.4.10.debian-2 Severity: serious Justification: no longer builds from source missinglib failed to build on a sparc buildd, duplicated on my sparc pbuilder. Please note that some buggy code that casts structures used to work no longer works due to changes in gcc. ./runtests Ran: 56 tests in: 0.02 seconds. OK ./runtests.opt make[2]: *** [test] Bus error make[2]: Leaving directory `/build/buildd/missinglib-0.4.10.debian/test' make[1]: *** [test] Error 2 make[1]: Leaving directory `/build/buildd/missinglib-0.4.10.debian' make: *** [build-stamp] Error 2 Hi, I reproduced this and tried to debug with gdb, but I didn't find any obvious bug, so I'll cc: debian-sparc for their help. The bus error seems to happen in caml_format_float (from byterun/floats.c in the ocaml source); gdb gives the following: (gdb) run Starting program: /tmp/missinglib-0.4.10.debian/test/runtests.opt Program received signal SIGBUS, Bus error. 0x0005f698 in caml_format_float () (gdb) where #0 0x0005f698 in caml_format_float () #1 0x0006a3ec in caml_c_call () 0x0005f680 caml_format_float+240: call 0x5d110 caml_stat_alloc 0x0005f684 caml_format_float+244: nop 0x0005f688 caml_format_float+248: mov %o0, %l0 0x0005f68c caml_format_float+252: mov %l0, %o0 0x0005f690 caml_format_float+256: mov %i0, %o1 0x0005f694 caml_format_float+260: call 0x7d814 sprintf 0x0005f698 caml_format_float+264: ldd [ %i1 ], %o2 0x0005f69c caml_format_float+268: call 0x5d3d4 caml_copy_string (gdb) p (char*)$o0 $1 = 0xefa8f70e (gdb) p (char*)$o1 $2 = 0xa35b0 %.2f (gdb) p *(double*)$i1 $3 = 0.013319015502929688 Any hint would be appreciated. Cheers, Julien Cristau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
