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 strings are equal. Clearly
> 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 the problems quickly.
The underlying upstream issue of this bug in glibc seems to have been
fixed [1], so I
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
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 strings are equal. Clearly
> they are not. :)
Looks like it has been fixed. Anything non-zero means strcmp says the
strings are
On Tue, 2014-04-29 at 19:34 -0400, Kieron Gillespie 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 the problems quickly.
You might find the BTS's
On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
It looks to me as if the problem might be here:
sub rWORD1, r0101, rTMP2
No that's not it. Still haven't figured it out.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
It looks to me as if the problem might be here:
sub rWORD1, r0101, rTMP2
No that's not it. Still haven't figured it out.
Does this actually
On Wed, Apr 30, 2014 at 11:21:14AM -0400, Lennart Sorensen wrote:
On Wed, Apr 30, 2014 at 07:53:30AM -0400, Lennart Sorensen wrote:
On Tue, Apr 29, 2014 at 04:47:26PM -0400, Lennart Sorensen wrote:
It looks to me as if the problem might be here:
sub rWORD1, r0101, rTMP2
Hi,
Sébastien Bernard:
Cheers to team work.
Special cheers to Patrick Baggett !
And thanks to all who cared for this problem. I'd need more
users who don't shrug but complain and tell me that i'm wrong.
The bug fix is now committed as
http://libburnia-project.org/changeset/5324
(We still
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('\','\0001' is -1)
This was built on Debian Wheezy with a T2000 SPARC processor using GCC
I'll rebuild one of my SunBlade 2500 latter with sid and see if I get the
same result. If it doesn't show the symptom I will rebuild my T2000 and see
if it is something specific to the Niagara T1.
-Kieron
On Tue, Apr 29, 2014 at 10:45 AM, Sébastien Bernard sbern...@nerim.netwrote:
Le
Le 29/04/2014 16:34, Kieron Gillespie a écrit :
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('\','\0001' is -1)
This was built on
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
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
ciaran.gilles...@gmail.com wrote:
I am currently investigating this unusual behavior with strcmp, and I am
unable to reproduce the problem using the
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
ciaran.gilles...@gmail.com wrote:
I am currently investigating
Le 29/04/2014 16:50, Kieron Gillespie a écrit :
I'll rebuild one of my SunBlade 2500 latter with sid and see if I get
the same result. If it doesn't show the symptom I will rebuild my
T2000 and see if it is something specific to the Niagara T1.
-Kieron
On Tue, Apr 29, 2014 at 10:45 AM,
On Tue, Apr 29, 2014 at 06:01:00PM +0200, Sébastien Bernard wrote:
Le 29/04/2014 16:50, Kieron Gillespie a écrit :
I'll rebuild one of my SunBlade 2500 latter with sid and see if I
get the same result. If it doesn't show the symptom I will rebuild
my T2000 and see if it is something specific
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 at
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
baggett.patr...@gmail.comwrote:
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 a bug with
On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote:
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
baggett.patr...@gmail.comwrote:
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,
Do we currently have a master list of all the major bugs facing the Sparc
Port right now?
On Tue, Apr 29, 2014 at 3:53 PM, Patrick Baggett
baggett.patr...@gmail.comwrote:
On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett
baggett.patr...@gmail.com wrote:
Yes, that's the one.
Le 30/04/2014 00:12, Kieron Gillespie a écrit :
Do we currently have a master list of all the major bugs facing the
Sparc Port right now?
I don't think so. I haven't been able to get one.
You can start one.
Seb
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
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 the
problems quickly.
One of my major problems with helping debian and the sparc port has been
simply figuring out
I've been looking through this problem.
genisoimage is reporting a problem with . and .. aliased to the same ''
name.
logs of the problem:
-
genisoimage -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B ...
./tmp/miniiso/cd_tree
I: -input-charset not specified, using utf-8
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch sparc in reach.
xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
...
Le 28/04/2014 12:09, Thomas Schmitt a écrit :
Hi,
I tried with the xorriso -as mkisofs command, with no luck.
This command terminates with a SIGBUS no matter of the options I pass on
the command line.
Ouch.
I have no Debian of arch sparc in reach.
I may provide you access to a shell account
Hi,
I may provide you access to a shell account on my machines if needed.
Yes, please.
Plus a directory tree
./tmp/miniiso/cd_tree
which can cause the xorriso crash.
Sparc architecture is extremely picky about alignement. Bad alignement,
yields SIGSEGV whereas intel only do it in the
On Mon, Apr 28, 2014 at 01:20:20PM +0200, Thomas Schmitt wrote:
Hi,
I may provide you access to a shell account on my machines if needed.
Yes, please.
Plus a directory tree
./tmp/miniiso/cd_tree
which can cause the xorriso crash.
Sparc architecture is extremely picky about alignement. Bad
Le 28/04/2014 13:20, Thomas Schmitt a écrit :
[genisoimage]
(gdb) x rpnt
0x1ea7f9:0x
(gdb) x lpnt
0x1e9dc1:0x0100
(gdb) n
659if (strcmp(rpnt, lpnt) == 0) {
Both values match the prescribed names for . and .. in ECMA-119
(aka ISO 9660), 6.8.2.2 Identification of
Hi,
Sébastien Bernard:
result from strcmp('\','\0001' is 0)
result from strcmp('\','\0001' is -1)
Typicaly, an endianness error.
But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under
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(), not in your code or the one of genisoimage.
You compare an empty string with a string
On Mon, Apr 28, 2014 at 8:17 AM, Sébastien Bernard sbern...@nerim.netwrote:
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(), not
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 even if those are not word aligned.
Indeed, the correct fix is using strcmp.
On Mon, Apr 28, 2014 at 11:25 AM, Sébastien Bernard sbern...@nerim.netwrote:
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 even if those are not
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().
So it seems worth to check whether genisoimage resp. strcmp() work
properly if not compiled with -O2.
On Mon, Apr 28, 2014 at 11:39 AM, Thomas Schmitt scdbac...@gmx.net 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
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 provide advice or code samples.
The context was misposted to bug report 731806 as message #87:
Hi,
i wrote:
struct write_opts write;
...
add_worker(Burnworker_type_writE, d,
(WorkerFunc) write_disc_worker_func, o);
Urgh. I copied the wrong struct definition. Line 592 bears of course:
struct write_opts o;
which is used in the call of add_worker().
Have a
On Mon, Apr 28, 2014 at 12:25 PM, Thomas Schmitt scdbac...@gmx.net 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 provide advice or code samples.
The
Hi,
I really need a disassembly and to be able to probe the runtime
stack a bit, so that really means that I need to build the code. :)
The current example would be a bit too opulent, i guess:
-rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso
(wget
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
On Mon, Apr 28, 2014 at 1:20 PM, Thomas Schmitt scdbac...@gmx.net 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
Hi,
No, it's plain wrong. Unions are fine, if used properly. You aren't
using them properly.
Duh. You convinced me. The callers do it wrong, indeed.
They would have to use local union variables instead of their actual
structs. The parameter of add_worker() should be a pointer to the
union, not
Hi,
On 28/04/2014 18:25, Thomas Schmitt wrote:
has a struct on heap (#L102, #L138, #L146):
struct w_list{
...
union w_list_data
{
...
struct write_opts write;
...
} u;
}
...
struct w_list *a;
...
a =
Hi,
Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.
The callers of add_worker() now declare:
union w_list_data o;
rather than
struct union_member o;
The type of the fourth parameter of add_worker has been changed
Le 28/04/2014 22:01, Thomas Schmitt a écrit :
Hi,
Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.
The callers of add_worker() now declare:
union w_list_data o;
rather than
struct union_member o;
The type of the
Le 28/04/2014 22:25, Sébastien Bernard a écrit :
Le 28/04/2014 22:01, Thomas Schmitt a écrit :
Hi,
Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.
The callers of add_worker() now declare:
union w_list_data o;
rather than
Le 28/04/2014 20:21, Patrick Baggett a écrit :
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
Cyril Brulebois k...@debian.org (2014-02-13):
[ TL;DR: d-i FTBFS on sparc, what do we do now? ]
@Kurt: did anything change on the buildd setup side? Both lebrun and spontini
got that FTBFS, while that wasn't the case before:
On Thu, Feb 13, 2014 at 04:38:36PM +0300, Cyril Brulebois wrote:
[ TL;DR: d-i FTBFS on sparc, what do we do now? ]
Thomas Schmitt scdbac...@gmx.net (2013-12-10):
Cyril Brulebois wrote:
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
'./tmp/miniiso/cd_tree/boot/..' have the same
On 2014-02-25 17:56, Cyril Brulebois wrote:
Cyril Brulebois k...@debian.org (2014-02-13):
[...]
Failing a short resolution, I'm tempted to pretend sparc isn't an issue,
and maybe ask for a migration to testing + dak copy-installer.
@debian-release: would that sound reasonable?
Ping?
[ TL;DR: d-i FTBFS on sparc, what do we do now? ]
Thomas Schmitt scdbac...@gmx.net (2013-12-10):
Cyril Brulebois wrote:
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
[...]
Probably some FS-dependent fun? Anyone would
Hi,
I'm not sure we want to continuously give it back until it builds (which
it might on schroeder, since it didn't fail there yet)...
I would assume the problem is deterministic and depends on
the exact tree of file names which is given to genisoimage
as input.
So adding a few names of empty
Source: debian-installer
Version: 20131014
Severity: serious
Justification: FTBFS
Hi people,
(-sparc, -cd, genisoimage maintainers x-d-cc'd)
debian-installer 20131014 FTBFS'd on the buildd with:
| […]
| install -m 644 ./tmp/miniiso/boot_screens/notsupported.txt
./tmp/miniiso/cd_tree/boot
|
Hi,
Cyril Brulebois wrote:
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
[...]
Probably some FS-dependent fun? Anyone would have a clue about it?
Looks like an internal error of genisoimage.
'.' should be mapped to a
55 matches
Mail list logo
