Are we still able to move on with Debian Sparc64 @ debian-ports.org?
Creating a bootable minimal ISO would help?
https://wiki.debian.org/Sparc64
Thanks,
Frans van Berckel
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listma
First of all -- thanks everyone who previously helped to maintain SPARC
Debian. IMHO your work was very useful!
FWIW -- I have got acquainted with sparc originally solely due to
the need to troubleshoot FTBFS of some packages I maintain on this
"alien" to me platform... But probably in a somewhat
Hello,
This is my first post hope I do a silly question.
I'm installing Debian on Sun workstation SunBlade150 CDROM does not work as
me, I'm trying to install with netboot.
The OS is Debian 7.
First of all turn off the DHCP of the Router.
The gateway is 192.168.1.1 my touter
The IP 192.168.1.103 D
On Mon, Apr 28, 2014 at 3:40 PM, Sébastien Bernard wrote:
> Well, folks,
> I think this is one step closer to the end.
> The sparc has been removed from the jessie archive.
> That's a shame cause the problem with the generation of the
> debian-installer is about to be fixed.
> There was no final n
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
Well, folks,
I think this is one step closer to the end.
The sparc has been removed from the jessie archive.
That's a shame cause the problem with the generation of the
debian-installer is about to be fixed.
There was no final notice, or maybe I missed it.
I don't think they will reconsider.
May
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
Hi,
Sébastien Bernard wrote:
> >>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.
Not only them. All my Sparcs run Squeeze kernels, too, because neither
Wheezy (3
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
Le 28/04/2014 16:12, Patrick Baggett a écrit :
The main problem is that the 2 new buildd are Niagara machines
which are not really stable. It left only 2 buildd which seems to
be quit old and slow.
On my V240, the 3.13 kernel seems to be rock solid (I've been
rebuilding the
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.
>
>
> 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.
>
>
OK, what are the major issues and the bug # assigned to them
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
>
>
>> The main problem is that the 2 new buildd are Niagara machines which are
> not really stable. It left only 2 buildd which seems to be quit old and
> slow.
>
> On my V240, the 3.13 kernel seems to be rock solid (I've been rebuilding
> the gcc package 3 times - 8hours build - without any issu
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
Le 26/04/2014 22:59, Julien Cristau a écrit :
On Fri, Apr 18, 2014 at 10:44:16 +0200, Sébastien Bernard wrote:
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 enoug
34 matches
Mail list logo
