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
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 not
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
> 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 as
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, r010
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 ac
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 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
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 what
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 s
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
wrote:
>
>
>
> On Tue, Apr 29, 2014 at 2:35 PM, Patrick Baggett <
> baggett.patr...@gmail.com> wrote:
>
>> Yes, that's the one. Interestingly, in glibc-2.19
On Tue, Apr 29, 2014 at 02:53:32PM -0500, Patrick Baggett wrote:
> 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, t
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 a bug with glibc [1] and let the a
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 spec
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
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, Sébas
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 curre
On Tue, Apr 29, 2014 at 10:47 AM, Patrick Baggett 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 test_strcmp example pr
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
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 Debian
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 wrote:
> Le 29/04/2014 16:34, Kieron G
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
4.6.
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 d
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 probl
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 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 f
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
fro
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 = ca
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, no
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
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 http://www.gnu.org/softw
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 provide advice or code samples.
>
> The context wa
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().
Ha
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:
https://bugs.debian.o
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
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: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 even if those are not word alig
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. Meanwhil
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
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 that
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 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
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 al
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 l
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 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
> ... ./t
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 (dete
On 2014-02-25 17:56, Cyril Brulebois wrote:
> Cyril Brulebois (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?
>
> [..
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 (2013-12-10):
> > Cyril Brulebois wrote:
> > > genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
> > > './tmp/miniiso/cd_tree/boot/..' have the same ISO9660
Cyril Brulebois (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:
> https://buildd.debian.org/status/logs.php?pkg=debian-installer&arch=sparc
P
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
[ TL;DR: d-i FTBFS on sparc, what do we do now? ]
Thomas Schmitt (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 have a c
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
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
| inst
55 matches
Mail list logo
