debian etch sh3 and sh4
hi all.
please let me introduce my archives.
this is debian etch sh3 and sh4
http://www.si-linux.co.jp/pub/debian-sh/
base tar balls.
http://www.si-linux.co.jp/pub/debian-sh/base/etch/
you can use following apt line in your sh-box.
landy2:~# cat /etc/apt/sources.list deb http://www.si-linux.co.jp/pub/debian-sh etch main contrib non-free deb-src http://ftp.debian.org/debian/ etch main contrib non-free
you can see the number of packeges here.
http://www.si-linux.co.jp/wiki/silinux/index.php?DebianSH_%A5%D3%A5%EB%A5%C9%A5%DE%A5%B7%A5%F3%BE%D2%B2%F0
(sorry japanese)
all packages are build with gcc-4.1.1.
landy2:~# gcc -v Using built-in specs. Target: sh4-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran, objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib - -disable-multilib --libexecdir=/usr/lib --without-included-gettext -- enable-threads=posix --enable-nls --program-suffix=-4.1 --enable- __cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release sh4-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Quoted 4 lines · Yutaro Ebihara
please let me introduce my archives.
this is debian etch sh3 and sh4
http://www.si-linux.co.jp/pub/debian-sh/
Quoted 9 lines
base tar balls.
http://www.si-linux.co.jp/pub/debian-sh/base/etch/you can use following apt line in your sh-box.
landy2:~# cat /etc/apt/sources.list deb http://www.si-linux.co.jp/pub/debian-sh etch main contrib non-free deb-src http://ftp.debian.org/debian/ etch main contrib non-free
These sorts of efforts seem to pop up almost every other year, and then quickly fall in to disarray. The same can be said for the Fedora Core ports. Is there a plan to have this work merged back in to Debian proper, and to keep it updated?
Currently Gentoo is the only viable option for a reasonably maintained port, and the only one supported upstream. Seeing Debian or Fedora Core in the same state would be nice, but the porters need to get serious about what their goals are. A one-shot build is obsolete before it hits the mailing list.
Quoted 19 lines · Paul Mundt
Quoted 4 lines · Yutaro Ebihara
please let me introduce my archives.
this is debian etch sh3 and sh4
http://www.si-linux.co.jp/pub/debian-sh/Quoted 9 lines
base tar balls.
http://www.si-linux.co.jp/pub/debian-sh/base/etch/you can use following apt line in your sh-box.
landy2:~# cat /etc/apt/sources.list deb http://www.si-linux.co.jp/pub/debian-sh etch main contrib non-free deb-src http://ftp.debian.org/debian/ etch main contrib non-freeThese sorts of efforts seem to pop up almost every other year, and then quickly fall in to disarray. The same can be said for the Fedora Core ports. Is there a plan to have this work merged back in to Debian proper, and to keep it updated?
Quoted 5 lines
Currently Gentoo is the only viable option for a reasonably maintained port, and the only one supported upstream. Seeing Debian or Fedora Core in the same state would be nice, but the porters need to get serious about what their goals are. A one-shot build is obsolete before it hits the mailing list.
Whilst I obviously accept a lot of what Paul says is true, I wanted to record my appreciation of the effort and let you know that the core at least runs on the Dreamcast (though I need to fix it up properly to get the filesystem to work).
If this was going to be a supported project in the longer term I'd be willing to consider providing space and bandwidth for a European mirror.
On gentoo - the link on the wiki points to sources that are 18 months old... is there something more up to date?
Quoted 12 lines · Adrian McMenamin
Quoted 10 lines · Paul Mundt
These sorts of efforts seem to pop up almost every other year, and then quickly fall in to disarray. The same can be said for the Fedora Core ports. Is there a plan to have this work merged back in to Debian proper, and to keep it updated?
Currently Gentoo is the only viable option for a reasonably maintained port, and the only one supported upstream. Seeing Debian or Fedora Core in the same state would be nice, but the porters need to get serious about what their goals are. A one-shot build is obsolete before it hits the mailing list.
Quoted 8 lines
Whilst I obviously accept a lot of what Paul says is true, I wanted to record my appreciation of the effort and let you know that the core at least runs on the Dreamcast (though I need to fix it up properly to get the filesystem to work).
If this was going to be a supported project in the longer term I'd be willing to consider providing space and bandwidth for a European mirror.
The problem is that this is still just a stop-gap solution. Debian already has all of the mirror infrastructure in place, so the only thing that needs to happen is effort to get this work integrated. If that's not going to happen, this simply isn't going to go anywhere. We've seen this with both the Debian and the Fedora Core ports in the past, and there's no reason to imagine things will be any different this time. It's nice to see that people are putting effort in to this, but without a push to get it supported upstream, it will simply bitrot like all of the other ports. This is the reality of things, good intentions aside.
Quoted 2 lines
On gentoo - the link on the wiki points to sources that are 18 months old... is there something more up to date?
It points to stage tarballs that are still usable. You of course need to update once you have it set up on your platform, but the stage tarballs are a starting point only. There are updates every day, and this continues to be the only maintained port.
Quoted 2 lines · Adrian McMenamin
On gentoo - the link on the wiki points to sources that are 18 months old... is there something more up to date?
err, 18 months ? which stages are you looking at ?
i see glibc/2007.0 which is ~8 months ... 2007.0 is actually the last release Gentoo has made (the 2007.1 slipped too much). i need to update the kernel on my second lantank to make sure the dcache issue is fixed, and then i can see how stable gcc-4.1.2 is for the upcoming 2008.0 ...
while not widely advertised, binary packages are posted to
http://tinderbox.dev.gentoo.org/ for stable glibc/sh ... -mike
Quoted 4 lines · Mike Frysinger
err, 18 months ? which stages are you looking at ?
Quoted 1 line
I was looking at the uclibc stuff, which I admit is not a strictly fair comparison (as the Debian stuff is linked with glibc)
Quoted 5 lines · Adrian McMenamin
Quoted 1 line · Mike Frysinger
err, 18 months ? which stages are you looking at ?
I was looking at the uclibc stuff, which I admit is not a strictly fair comparison (as the Debian stuff is linked with glibc)
i can look at refreshing the uClibc stages this time around ... when i was doing 2007.0, i didnt have enough time to bounce glibc and uclibc at the sametime
-mike
Quoted 10 lines · Mike Frysinger
Quoted 5 lines · Adrian McMenamin
Quoted 1 line · Mike Frysinger
err, 18 months ? which stages are you looking at ?
I was looking at the uclibc stuff, which I admit is not a strictly fair comparison (as the Debian stuff is linked with glibc)
i can look at refreshing the uClibc stages this time around ... when i was doing 2007.0, i didnt have enough time to bounce glibc and uclibc at the sametime
How good is emerge when memory is in short supply in the glibc versions? apt/dpkg is a pig - takes forever and then OOMs :(
(But I am still trying to get the alsa stuff installed that way so I can finally see if it is my driver or my setup that is at fault)
The alternative might be to try the dreaded swap-over-nfs but that didn't work last time I tried it (a few years ago now)
Quoted 8 lines · Adrian McMenamin
Quoted 7 lines · Mike Frysinger
Quoted 5 lines · Adrian McMenamin
Quoted 1 line · Mike Frysinger
err, 18 months ? which stages are you looking at ?
I was looking at the uclibc stuff, which I admit is not a strictly fair comparison (as the Debian stuff is linked with glibc)
Quoted 7 lines
Quoted 3 lines
i can look at refreshing the uClibc stages this time around ... when i was doing 2007.0, i didnt have enough time to bounce glibc and uclibc at the sametime
How good is emerge when memory is in short supply in the glibc versions? apt/dpkg is a pig - takes forever and then OOMs :(
All you need is a bit of swap (CF cards, ..) and distcc. This way I was able to emerge current XFCE and qt-4.3.3 with 64MB RAM. Patience is a virtue in this case ;-)
Manuel Lauss
Quoted 14 lines · Manuel Lauss
Quoted 13 lines · Adrian McMenamin
Quoted 10 lines · Mike Frysinger
Quoted 5 lines · Adrian McMenamin
Quoted 1 line · Mike Frysinger
err, 18 months ? which stages are you looking at ?
I was looking at the uclibc stuff, which I admit is not a strictly fair comparison (as the Debian stuff is linked with glibc)
i can look at refreshing the uClibc stages this time around ... when i was doing 2007.0, i didnt have enough time to bounce glibc and uclibc at the sametime
Quoted 7 lines
Quoted 2 lines
How good is emerge when memory is in short supply in the glibc versions? apt/dpkg is a pig - takes forever and then OOMs :(
All you need is a bit of swap (CF cards, ..) and distcc. This way I was able to emerge current XFCE and qt-4.3.3 with 64MB RAM. Patience is a virtue in this case ;-)
In 16MB you will always be bordering on thrashing just trying to do _any_ basic tasks. Your options are realistically limited to busybox or throwing the damn thing out (the recommended option). Doing anything more involved than that was pretty questionable back when the kernel used a lot less memory, and trying to do builds in that environment is well past absurdity these days. 64MB is painful, but at least workable.
Quoted 7 lines · Paul Mundt
In 16MB you will always be bordering on thrashing just trying to do _any_ basic tasks. Your options are realistically limited to busybox or throwing the damn thing out (the recommended option). Doing anything more involved than that was pretty questionable back when the kernel used a lot less memory, and trying to do builds in that environment is well past absurdity these days. 64MB is painful, but at least workable.
You really are like the Kerryman who, when asked how to get to Dublin said "well, I wouldn't start from here." :)
I don't mind the thrashing if it gets me something that works and which can later be used as the basis of a "distro" - which is my aim here.
Anyone know how stable swap over nfs is these days? Speed is a secondary consideration.
NB: CF or similar isn't an option. In theory you could put a very small swap partition on the Dreamcast's VMUs but access to that is likely to be much slower even than NFS - as it would be rationed to 60 times per second.
Quoted 14 lines · Adrian McMenamin
Quoted 6 lines · Paul Mundt
In 16MB you will always be bordering on thrashing just trying to do _any_ basic tasks. Your options are realistically limited to busybox or throwing the damn thing out (the recommended option). Doing anything more involved than that was pretty questionable back when the kernel used a lot less memory, and trying to do builds in that environment is well past absurdity these days. 64MB is painful, but at least workable.
You really are like the Kerryman who, when asked how to get to Dublin said "well, I wouldn't start from here." :)
I don't mind the thrashing if it gets me something that works and which can later be used as the basis of a "distro" - which is my aim here.
Quoted 7 lines
Anyone know how stable swap over nfs is these days? Speed is a secondary consideration.
NB: CF or similar isn't an option. In theory you could put a very small swap partition on the Dreamcast's VMUs but access to that is likely to be much slower even than NFS - as it would be rationed to 60 times per second.
i used to build on the dreamcast, but the swapping was terrible so i gave up and just bought a lantank as it has 64megs ;)
-mike
Quoted 18 lines · On Wed, 23 Jan 2008 07:16:43 -0500 Mike Frysinger <[email protected]> wrote:
Quoted 17 lines · Adrian McMenamin
Quoted 6 lines · Paul Mundt
In 16MB you will always be bordering on thrashing just trying to do _any_ basic tasks. Your options are realistically limited to busybox or throwing the damn thing out (the recommended option). Doing anything more involved than that was pretty questionable back when the kernel used a lot less memory, and trying to do builds in that environment is well past absurdity these days. 64MB is painful, but at least workable.
You really are like the Kerryman who, when asked how to get to Dublin said "well, I wouldn't start from here." :)
I don't mind the thrashing if it gets me something that works and which can later be used as the basis of a "distro" - which is my aim here.
Anyone know how stable swap over nfs is these days? Speed is a secondary consideration.
Quoted 9 lines
Quoted 4 lines
NB: CF or similar isn't an option. In theory you could put a very small swap partition on the Dreamcast's VMUs but access to that is likely to be much slower even than NFS - as it would be rationed to 60 times per second.
i used to build on the dreamcast, but the swapping was terrible so i gave up and just bought a lantank as it has 64megs ;)
-mike
We've used ipkg for jlime, which basicly is a minimal version of apt. One would expect great speed, but unfortunantly that isn't the case. It seems to have a hard time handling the database which is why we've split it up into smaller pieces.
ipkg is borderline usable on an jornada with 16mb/133mhz so I doubt apt will be any better.
Personally I believe that slackware + some minimal packagemanager is the way to go. Doesn't simplify much for the user but will be easy to access packages and also maintain diffs against the main sources. Archlinux might also be an option since I have greater faith in pacman as a package manager, but currently there's no superH port.
I agree with paul that we need to see some commitment to getting stuff into the true release instead of providing "unsupported"/"unofficial" branches which pop up every year or so.