On Saturday, June 4, 2016, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> On 06/03/2016 11:49 PM, John Paul Adrian Glaubitz wrote:
> > So, maybe we're lucky and just the above patch will be enough :).
> >
> > Will build gegl now to verify this.
>
> And, indeed, gegl now builds
On Wed, Feb 3, 2016 at 4:55 PM, John Paul Adrian Glaubitz
wrote:
> On 02/03/2016 11:48 PM, John Paul Adrian Glaubitz wrote:
>> cd /«PKGBUILDDIR»/obj-sparc64-linux-gnu/libemos-dp && /usr/bin/cc
>> -DBUFR_TABLES_PATH=\"/usr/share/emos/bufrtables\" -DFOPEN64 -DINTEGER_IS_INT
>> -DINTERPOL_TABLES_P
On Wed, Jan 27, 2016 at 5:23 PM, Ben Hutchings wrote:
> Control: tag -1 moreinfo
>
> On Wed, 2016-01-27 at 23:54 +0100, Marco d'Itri wrote:
>> Control: reassign -1 src:linux
>> Control: found -1 4.3.0-1
>> Control: retitle -1 getauxval(AT_RANDOM) broken on sparc64
>>
>> On Jan 27, Anatoly Pugachev
On Thu, Nov 12, 2015 at 4:35 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> On 11/12/2015 11:28 PM, Patrick Baggett wrote:
> > If the output is -1, the bug has been fixed. If the output is 0, then
> > the bug is still present. 0 indicates the two strin
On Thu, Nov 12, 2015 at 4:20 PM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> > https://wiki.debian.org/PortsSparc
> >
> > Started a catagory of major bugs. Please place links and titles to
> > the bug report in this list so we can better track the status and
> > reference th
iar with the Debian
> build process and to find major bugs report and fix them.
>
> I haven't checked but I think that SILO is currently a version or two
> ahead of what debian is using for it's installs. That might be the issue.
>
> Wish I had more time to invest in th
BTW, the sparc buildd looks like gcc 4-8.2-21 is successful and so is
gcc-4.9.0-1. I've installed them from sid. Crisis averted?
Patrick
On Wed, Apr 30, 2014 at 4:04 PM, Sébastien Bernard wrote:
> Le 30/04/2014 20:36, Patrick Baggett a écrit :
>
>
>
>
> On Wed, Apr 30,
On Wed, Apr 30, 2014 at 1:13 PM, Ivo De Decker wrote:
> Hi,
>
> On Wed, Apr 30, 2014 at 03:42:39PM +0200, Sébastien Bernard wrote:
> > Indeed, the last good build seems to be gcc-4.8-4.8.2-19.
> > Look at the changelog for the -20 they seems to have done something on
> the sparc
> > that blocks th
On Wed, Apr 30, 2014 at 8:42 AM, Sébastien Bernard wrote:
> Le 30/04/2014 15:39, Patrick Baggett a écrit :
>
>
>>> I tried to build the gcc-4.8-4.8.2-20 and the build is broken.
>> libstdc++ and lib64stdc++ are not build, neither are build libgcc1.
>> The las
>
>
>> I tried to build the gcc-4.8-4.8.2-20 and the build is broken. libstdc++
> and lib64stdc++ are not build, neither are build libgcc1.
> The last good build (with the missing libraries) is 4.8.2-16.
> Something broken on -20 and -21.
>
>
Oh, I see what you're saying. I get lib64stdc++-dev / l
I kicked off a gcc build (gcc-4.8_4.8.2-21) last night. It didn't have an
errors for me. I now have a bunch of *.deb files:
figgles@ghost:~/src$ ls -1 *.deb
cpp-4.8_4.8.2-21_sparc.deb
g++-4.8-multilib_4.8.2-21_sparc.deb
g++-4.8_4.8.2-21_sparc.deb
gcc-4.8-base_4.8.2-21_sparc.deb
gcc-4.8-locales_4.8
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
wrote:
> Yes, that's the one. Interestingly, in glibc-2.19, this change is
> reverted. It is present in glibc-2.17 & glibc-2.18 as released by GNU.
> Oddly, in glibc git, the buggy version appears.
>
>
>
I've filed
Yes, that's the one. Interestingly, in glibc-2.19, this change is reverted.
It is present in glibc-2.17 & glibc-2.18 as released by GNU. Oddly, in
glibc git, the buggy version appears.
On Tue, Apr 29, 2014 at 2:25 PM, Lennart Sorensen <
lsore...@csclub.uwaterloo.ca> wrote:
> On Tue, Apr 29, 2014
On Tue, Apr 29, 2014 at 1:29 PM, Steven Chamberlain wrote:
> On Tue, 29 Apr 2014 13:36:31 +0200, Joël BERTRAND wrote:
> > sun4u : kernel is stable until 2.6.32. [...]
> >
> > sun4v : I have several T1000 for a long time. I haven't seen any
> stable
> > kernel on these servers.
>
> Mayb
er wrote:
> [Taking a few lists of the CC, no need to spam everyone.]
>
> Dear Patrick,
>
> Am Dienstag, den 29.04.2014, 09:41 -0500 schrieb Patrick Baggett:
>
> > I'd like to look into the TLS failures. Bus errors usually mean
> > "misaligned data" which aren
On Tue, Apr 29, 2014 at 10:01 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:
>
> On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>>
>>
>> On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
>
OK, thanks, I'll look into it.
Patrick
On Tue, Apr 29, 2014 at 10:08 AM, Joachim Breitner wrote:
> [Taking a few lists of the CC, no need to spam everyone.]
>
> Dear Patrick,
>
> Am Dienstag, den 29.04.2014, 09:41 -0500 schrieb Patrick Baggett:
>
> > I'd like
On Tue, Apr 29, 2014 at 9:34 AM, Kieron Gillespie <
ciaran.gilles...@gmail.com> wrote:
> I am currently investigating this unusual behavior with strcmp, and I am
> unable to reproduce the problem using the test_strcmp example provided.
>
> It returns the correct output of,
>
>
> result from strcmp
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt wrote:
> Hi,
>
> > I really need a disassembly and to be able to probe the runtime
> It's the job of a C union to provide a common hull around objects
> of different size. One may dispute whether using union is a good
> idea (like overloading in the
Seb,
Yes, I can reproduce this issue.
{ 1, 0 }
{ 1, 1 }
returns 0, when it should return -1.
Interestingly, if you use:
{ 1, 1, 1, 1, 0 } //i.e. 5 bytes
{ 1, 1, 1, 1, 1 } //i.e. 5 bytes
as the strings, it returns -1. So it clearly has a problem if the string is
exceptionally short. That got
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt wrote:
> Hi,
>
> Patrick Baggett:
> > Could you explain the context around this code? Perhaps the source is
> > not really "alignment safe" and could use some patching upstream? I'd
> > be happy to provi
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt wrote:
> Hi,
>
> sorry for mis-posting the first reply for bug 746254 to this bug 731806.
>
> Meanwhile it turned out that the SIGBUS vanishes if i do not
> compile with -O2 or if i replace "a->u =" by memcpy().
>
> Could you explain the context ar
On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard wrote:
> Le 28/04/2014 16:05, Patrick Baggett a écrit :
>
> strcmp() may well be implemented by word comparisons. But then it
>
>> is the duty of the implementation to properly handle the ends of
>>> the strings
On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard wrote:
> Le 28/04/2014 14:15, Thomas Schmitt a écrit :
>
> Hi,
>>
>> Sébastien Bernard:
>>
>>> result from strcmp('\','\0001' is 0)
>>> result from strcmp('\','\0001' is -1)
>>> Typicaly, an endianness error.
>>>
>> But one in strcmp(), n
I still run Debian on three SPARC machines, so I am definitely interested.
Patrick
On Sat, Apr 26, 2014 at 12:16 PM, Ansgar Burchardt wrote:
> Hi,
>
> Philipp Kern writes:
> > now that sparc has been dropped from testing, please decide on the fate
> > of sparc in unstable.
>
> Are there still
The log shows 7 failed tests, but I only see this one as actually failing:
../test-driver: line 95: 4705 Bus error "$@" > $log_file 2>&1
I'm sure I'm not reading this properly -- where are the other 6 failing tests?
A bus error on sparc isn't uncommon, but usually it affects many
I kind of wonder if it has anything to do with compiler code generation; I
don't remember if you checked whether -O[0,1,2,3] on the kernel changed
anything. The appearance is so random, but when it does appear, it's stuck
for that version (i.e. not just a race issue that is hard to repro).
Patrick
Nice job!
On Jun 15, 2013 9:44 AM, "Stephan Schreiber" wrote:
> tags 711107 - help
> tags 711107 + patch
> thanks
>
>
> Emilio Pozuelo Monfort wrote:
>
> What happens if you do `make check' or `fakeroot make check' again? make
>> check
>> will set Xvfb differently than xvfb-run.
>>
>
> I didn't
re building gtk+3.0 is ok, but
running it afterwards fails, I'd love to know. I can say that whatever the
original problem (assertion failure in children.c) was, I didn't seem to
run into it.
Patrick
On Wed, Jun 12, 2013 at 10:17 AM, Emilio Pozuelo Monfort
wrote:
> On 12/06/13
Hi Emilio,
I have an ia64 box with local graphics adapter and working X server. Pardon
the newbie question -- do I use apt-get to pull the source and then build
it using "make test" or some other procedure?
Patrick
On Wed, Jun 12, 2013 at 6:45 AM, Emilio Pozuelo Monfort wrote:
> tags 711107 +
What is broken about it? Has anyone estimated how much effort it would take
to fix? Are we talking needing assembly language bindings or just some dumb
SIGBUS error?
Patrick Baggett
On Thu, Dec 6, 2012 at 11:37 AM, Gunnar Wolf wrote:
> Michael Stapelberg dijo [Thu, Dec 06, 2012 at 10:22:0
Luca,
This crashes for me in the same way on GCC-4.6.3(-12), but using
GCC-4.7.2(-2) works fine. Whatever the issue is, it is definitely fixed in
GCC 4.7.2 at least. Unfortunately, I think ia64 will be using gcc 4.6.x for
a while and I think it's still the default for wheezy. After I get gdb
worki
OK sorry for the long delay. I've found more time to spend on debian ia64
now!
This still fails on GCC-4.7.2(-4) and GCC-4.6.3(-12) with the native ia64
compiler. I'm having an issue with gdb currently. After that gets resolved,
I'm going to dig into this and see if I can't get a patch or conversa
Jakub,
Are you running a native ia64->ia64 compiler or a cross-compiler? Do you
happen to know if this occurs when using a cross-compiler to ia64?
Patrick
opriate as
well since it seems to be called in that context.
Patrick
On Sat, Mar 3, 2012 at 10:11 AM, Julien Cristau wrote:
> 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
> &
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.
Patrick
On Sat, Mar 3,
> According to g_int64_equal documentation, it expects its arguments to
> be pointers to gint64 values, which on sparc must be aligned on an
> 8-byte boundary. Looks like this is intentional, because
> nbd-tester-client.c creates its hash table like that:
>
>
That's odd that it would be 4-byte alig
37 matches
Mail list logo
