[arch-ports] [archlinux ppc] Scripts

older
[arch-ports] x86_64 kde 3.5.5 in...

N4

6 Nov 2006 6 Nov '06

6:03 p.m.

Hi everyone, I decided to try archlinux on ppc even if it's still on his early stages 'cos I really like the x86 flavour of this distro :) The installation went _almost_ smooth: there are still a few typos in the installation guide wiki and I had to build my own kernel to have it running. Still don't understand why, more on this later if it's of general interest. I'm trying to set up a full gnome desktop development environment and there are a few quirks I stumbled upon I'd like to ask you about: 1) why isn't abs the same script as in x86 archlinux ? 2) why isn't /etc/rc.d/fam the script as in the x86 archlinux ? 3) is there any particular reason for changing the scripts ? I copied abs from my x86 archlinux machine, ran it and it went smooth. Most of the PKGBUILDS work out of the box (e.g. glade-3), a few don't but that's no surprise, due to the different architecture, right ? I copied /etc/rc.d/fam from the x86 box and it replaced perfectly the wrong script from current/fam-2.7.0-8. bash-3.1$ !diff diff fam fam.old 9,10d8 < #Check for running portmap, start when not running < ck_daemon portmap && /etc/rc.d/portmap start 12,15c10,13 < if [ ! -f /var/run/daemons/portmap ]; then < stat_fail < echo "ERROR: PORTMAP is not running" < exit 1 ---

...

if [ ! -f /var/run/daemons/fam ]; then stat_fail echo "ERROR: fam is not running" exit 1

see? It looks for a running fam before starting fam, that makes no sense to me ;) Keep up the good work everybody, I really love this distro :) N4

Show replies by date

Alexander Baldeck

7 Nov 7 Nov

3:20 p.m.

N4 wrote:

...

1) why isn't abs the same script as in x86 archlinux ?

It's simply not implemented, cvsup doesn't work on non-x86 because of the fact that it's written in an obscure language that requires a compiler we haven't yet got to work. Then again, using CVS solves the problem and obsoletes caring about the problem. We'll be removing ABS completely at some time or make it use anonymous CVS. No plans yet though, minor issue.

...

2) why isn't /etc/rc.d/fam the script as in the x86 archlinux ?

It's not up to date. i686 -9 ppc -8 As above, seems minor. ;)

...

3) is there any particular reason for changing the scripts ?

At the time we built the package the files were those pulled from i686. It's always like that, we don't modify unless necessary. So you can assume that at some point in time, the i686 scripts had similar issues. Cheers, -G

Pierre Schmitz

3:33 p.m.

Am Dienstag, 7. November 2006 16:20 schrieb Alexander Baldeck:

...

It's simply not implemented, cvsup doesn't work on non-x86 because of the fact that it's written in an obscure language that requires a compiler we haven't yet got to work. Then again, using CVS solves the problem and obsoletes caring about the problem. We'll be removing ABS completely at some time or make it use anonymous CVS. No plans yet though, minor issue.

But abs can run with csup instead of cvsup. This works for x86_64; so chances are that it might work for ppc, too. -- http://www.archlinux.de

Marco Pensallorto

3:58 p.m.

2006/11/7, Pierre Schmitz :

...

Am Dienstag, 7. November 2006 16:20 schrieb Alexander Baldeck:

...
It's simply not implemented, cvsup doesn't work on non-x86 because of

[CUT] But abs can run with csup instead of cvsup. This works for x86_64; so

...

chances are that it might work for ppc, too.

In fact it does. A simple symlink has solved the problem. I use abs from the x86 archlinux and already had a lot of packages compile smoothly out-of-the-box from the x86 abs tree (i.e. the _entire_ gnome tree plus any conceivable extras :) Others compile and work with minor modifications of PKGBUILD. That is why I don't really see the reason to diverge significantly from the i686 distro. Hope to get a working binary repo of all these packages in the next few days. About the fam script, please take a closer look at it and you'll easily realize that is plainly wrong. And that package is in current, so I guess nobody noticed the error. I'm pretty sure the i686 version never had that bug :) Still don't have any clue about the kernel issue. I was forced to include static xfs support in order to have root mounted properly and boot the system. I did the mkinitcpio myself at least five times and I'm pretty sure xfs support was included but still... kernel panic'ed. That could be a minor issue but I'd like to get it work just right :) bye, N4

Alexander Baldeck

4:06 p.m.

Marco Pensallorto wrote:

...

2006/11/7, Pierre Schmitz mailto:pierre@archlinux.de>:

Am Dienstag, 7. November 2006 16:20 schrieb Alexander Baldeck: > It's simply not implemented, cvsup doesn't work on non-x86 because of

[CUT]

But abs can run with csup instead of cvsup. This works for x86_64; so chances are that it might work for ppc, too.

In fact it does. A simple symlink has solved the problem. I use abs from the x86 archlinux and already had

You could just have used CVS. But yeah, need to put that on the site. :)

...

a lot of packages compile smoothly out-of-the-box from the x86 abs tree (i.e. the _entire_ gnome tree plus any conceivable extras :) Others compile and work with minor modifications of PKGBUILD. That is why I don't really see the reason to diverge significantly from the i686 distro.

Hope to get a working binary repo of all these packages in the next few days.

Err, that's nothing to do with the abs script not working right? Since we have Gnome 2.14 in extra and 2.16.1 in testing you shouldn't have had to compile those. Yes, we hardly modify stuff. In 90% of all cases it just plain works. Some things are handcrafted though, such as the kernels (of course heh) and CPU dependent things like mplayer are not compiled in the same way necessarily cos since we orient on G3 and not G4 have to disable Altivec and put on some special G3+ flags.

...

About the fam script, please take a closer look at it and you'll easily realize that is plainly wrong. And that package is in current, so I guess nobody noticed the error. I'm pretty sure the i686 version never had that bug :)

Still don't have any clue about the kernel issue. I was forced to include static xfs support in order to have root mounted properly and boot the system. I did the mkinitcpio myself at least five times and I'm pretty sure xfs support was included but still... kernel panic'ed. That could be a minor issue but I'd like to get it work just right :)

In fact it had: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/daemons/fam/fam.diff?r1=text&tr1=1.6&r2=text&tr2=1.8&diff_format=h Cheers, -O

Alexander Baldeck

4:11 p.m.

Alexander Baldeck wrote:

...

Marco Pensallorto wrote:

...
2006/11/7, Pierre Schmitz mailto:pierre@archlinux.de>:

Am Dienstag, 7. November 2006 16:20 schrieb Alexander Baldeck: > It's simply not implemented, cvsup doesn't work on non-x86 because of

[CUT]

But abs can run with csup instead of cvsup. This works for x86_64; so chances are that it might work for ppc, too.

In fact it does. A simple symlink has solved the problem. I use abs from the x86 archlinux and already had

You could just have used CVS. But yeah, need to put that on the site. :)

To reply to myself: In addition, I should have pointed out that we DO NOT use the official CVS repo on PPC, and thus need to configure it differently. So being able to pull the official CVS by ABS is by no means the preferred method of fixing the problem. ;p If you have a working patch for pacman that uses: CVS_ROOT=:pserver:anonymous@cvs.archlinuxppc.org:/home/cvs-{arch,current,extra} instead, please forward it to us. Thanks, -T

Armin Luntzer

5:47 p.m.

Am Dienstag, den 07.11.2006, 16:58 +0100 schrieb Marco Pensallorto:

...

2006/11/7, Pierre Schmitz :

...

Still don't have any clue about the kernel issue. I was forced to include static xfs support in order to have root mounted properly and boot the system. I did the mkinitcpio myself at least five times and I'm pretty sure xfs support was included but still... kernel panic'ed. That could be a minor issue but I'd like to get it work just right :)

I had the same problem, hooking usbinput solved the problem for me. - Armin

Alexander Baldeck

5:50 p.m.

Armin Luntzer wrote:

...

Am Dienstag, den 07.11.2006, 16:58 +0100 schrieb Marco Pensallorto:

...
2006/11/7, Pierre Schmitz :

...
Still don't have any clue about the kernel issue. I was forced to include static xfs support in order to have root mounted properly and boot the system. I did the mkinitcpio myself at least five times and I'm pretty sure xfs support was included but still... kernel panic'ed. That could be a minor issue but I'd like to get it work just right :)

I had the same problem, hooking usbinput solved the problem for me.

- Armin

Now that's weird. How's it going with testing/kernel26-pmac (2.6.19-4) ? -P

Armin Luntzer

6:31 p.m.

Am Dienstag, den 07.11.2006, 18:50 +0100 schrieb Alexander Baldeck:

...

Armin Luntzer wrote:

...
Am Dienstag, den 07.11.2006, 16:58 +0100 schrieb Marco Pensallorto:

...
2006/11/7, Pierre Schmitz :

...
Still don't have any clue about the kernel issue. I was forced to include static xfs support in order to have root mounted properly and boot the system. I did the mkinitcpio myself at least five times and I'm pretty sure xfs support was included but still... kernel panic'ed. That could be a minor issue but I'd like to get it work just right :)

I had the same problem, hooking usbinput solved the problem for me.

- Armin

Now that's weird. How's it going with testing/kernel26-pmac (2.6.19-4) ?

just updated from 2.6.19-3: usbinput is still required, the kernel panics otherwise - Armin

N4

7:08 p.m.

Il giorno mar, 07/11/2006 alle 19.31 +0100, Armin Luntzer ha scritto:

...

Am Dienstag, den 07.11.2006, 18:50 +0100 schrieb Alexander Baldeck:

...
Armin Luntzer wrote:

...
Am Dienstag, den 07.11.2006, 16:58 +0100 schrieb Marco Pensallorto:

...
2006/11/7, Pierre Schmitz :

...
Still don't have any clue about the kernel issue. I was forced to [CUT]

...

...
...
I had the same problem, hooking usbinput solved the problem for me.

- Armin

Now that's weird. How's it going with testing/kernel26-pmac (2.6.19-4) ?

just updated from 2.6.19-3: usbinput is still required, the kernel panics otherwise

- Armin

Oh man it worked ! Thank you Armin ;) HOOKS="base udev autodetect usbinput ide scsi sata filesystems" Kernel 2.6.19-4 booted regularly my XFS root on /dev/hda4 Cheers, N4

Benoit Chesneau

8 Nov 8 Nov

6:43 a.m.

On Nov 7, 2006, at 7:31 PM, Armin Luntzer wrote:

...

usbinput is still required, the kernel panics otherwise

- Armin

on which model ? - b

Marco Pensallorto

7:36 a.m.

2006/11/8, Benoit Chesneau :

...

On Nov 7, 2006, at 7:31 PM, Armin Luntzer wrote:

usbinput is still required, the kernel panics otherwise

- Armin

on which model ?

- b

Apple iBook 12" 1.3Ghz G4 w/ 1Gb Ram bash-3.1$ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 666.666000MHz revision : 0.5 (pvr 8003 0105) bogomips : 36.73 timebase : 18432000 platform : PowerMac machine : PowerBook6,7 motherboard : PowerBook6,7 MacRISC3 Power Macintosh detected as : 287 (iBook G4) pmac flags : 0000001b L2 cache : 512K unified pmac-generation : NewWorld cheers, N4

Armin Luntzer

8:18 a.m.

Am Mittwoch, den 08.11.2006, 08:36 +0100 schrieb Marco Pensallorto:

...

2006/11/8, Benoit Chesneau :

On Nov 7, 2006, at 7:31 PM, Armin Luntzer wrote:

> > usbinput is still required, the kernel panics otherwise > > > > - Armin > >

on which model ?

- b

Apple iBook 12" 1.3Ghz G4 w/ 1Gb Ram

<snip> I've got the same model. - Armin

6379

Age (days ago)

6381

Last active (days ago)

List overview

Download

12 comments

6 participants

participants (6)

Alexander Baldeck
Armin Luntzer
Benoit Chesneau
Marco Pensallorto
N4
Pierre Schmitz