From daniel.isenmann at gmx.de  Thu Mar  2 11:24:30 2006
From: daniel.isenmann at gmx.de (Daniel Isenmann)
Date: Thu, 2 Mar 2006 17:24:30 +0100 (MET)
Subject: [arch-ports] Arch64 - call for a website maintainer
Message-ID: <6567.1141316670@www084.gmx.net>

Hi,

I have follow the discussion since it has began. I have a suggestion, I
would copy the whole design of archlinux.org, if Judd give me a tarball of
the exisiting webpage. So, there is the same design and it would be easy to
merge it in the future...
There is a place where information can be post or new packages will appear,
since it will be merge...

So, what do you think?? I would do the job, if you say yes. So think about
it..

Bye, Daniel

-- 
Echte DSL-Flatrate dauerhaft f?r 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl



From buchuki at gmail.com  Thu Mar  2 11:29:46 2006
From: buchuki at gmail.com (Dusty Phillips)
Date: Thu, 2 Mar 2006 11:29:46 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <6567.1141316670@www084.gmx.net>
References: <6567.1141316670@www084.gmx.net>
Message-ID: <7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>

On 3/2/06, Daniel Isenmann <daniel.isenmann at gmx.de> wrote:
> Hi,
>
> I have follow the discussion since it has began. I have a suggestion, I
> would copy the whole design of archlinux.org, if Judd give me a tarball of
> the exisiting webpage.

I don't think its a good idea. Have you looked at the sources for the
existing page?  Its got crazy spans, tables, hard to read, I don't
know how Judd manages to maintain it. :-D I think its actually time
for the main archlinux.org site to be rewritten in nice clean XHTML
1.0 and CSS... now we're talking a whole new level, but perhaps its
time to think about organizing a new al.org web design that
incorporates arch64 (and possibly other ports) into the new main site.
Would be cool if somebody with a whole pile of time on their hands and
l33t web dev skills could integrate the forum, wiki, art.archlinux,
documentation, planet, dev blog, ports, and main site into one
super-charged new ArchLinux portal.

Whole pile of time on their hands..... good luck. :(

Dusty

Dusty



From jvinet at zeroflux.org  Thu Mar  2 13:25:35 2006
From: jvinet at zeroflux.org (Judd Vinet)
Date: Thu, 2 Mar 2006 10:25:35 -0800
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
References: <6567.1141316670@www084.gmx.net>
	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
Message-ID: <20060302182535.GF25364@zeroflux.org>

On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
> I don't think its a good idea. Have you looked at the sources for the
> existing page?  Its got crazy spans, tables, hard to read, I don't
> know how Judd manages to maintain it. :-D I think its actually time
> for the main archlinux.org site to be rewritten in nice clean XHTML
> 1.0 and CSS...

That would super duper.  (yea that's right, I said "super duper")

The arch page was originally slapped together for me back in 2002 (or
was it 2003?) by a fellow co-worker who had more free time than I.  If
someone were inclined to re-design the thing, I'd be a happy geek.  The
PHP portions should be re-coded too, perhaps in a proper framework.
They're all pretty adhoc right now, and it's ugly.


- J




From dadexter at gmail.com  Thu Mar  2 13:33:18 2006
From: dadexter at gmail.com (Martin Lefebvre)
Date: Thu, 2 Mar 2006 13:33:18 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <20060302182535.GF25364@zeroflux.org>
References: <6567.1141316670@www084.gmx.net>
	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
	<20060302182535.GF25364@zeroflux.org>
Message-ID: <ed5f04980603021033qac6f5ei589347ed9a68735e@mail.gmail.com>

On 3/2/06, Judd Vinet <jvinet at zeroflux.org> wrote:
>
> That would super duper.  (yea that's right, I said "super duper")
>
> The arch page was originally slapped together for me back in 2002 (or
> was it 2003?) by a fellow co-worker who had more free time than I.  If
> someone were inclined to re-design the thing, I'd be a happy geek.  The
> PHP portions should be re-coded too, perhaps in a proper framework.
> They're all pretty adhoc right now, and it's ugly.
>

would you guys accept help from a debian user? :P

--
Martin Lefebvre
eMail: dadexter at gmail.com

WWW: https://sigterm.homeunix.com
Registered Linux #349269

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s:-- a- C+++ UL++++ P-- L++++ E--- W+++ N++ o-- K- w---
O- M-- V-- PS PE Y PGP-- t+++ 5- X R- tv++ b+ DI-- D+
G-- e h++ r++ y**
------END GEEK CODE BLOCK------



From jvinet at zeroflux.org  Thu Mar  2 13:35:51 2006
From: jvinet at zeroflux.org (Judd Vinet)
Date: Thu, 2 Mar 2006 10:35:51 -0800
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <ed5f04980603021033qac6f5ei589347ed9a68735e@mail.gmail.com>
References: <6567.1141316670@www084.gmx.net>
	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
	<20060302182535.GF25364@zeroflux.org>
	<ed5f04980603021033qac6f5ei589347ed9a68735e@mail.gmail.com>
Message-ID: <20060302183551.GG25364@zeroflux.org>

On Thu, Mar 02, 2006 at 01:33:18PM -0500, Martin Lefebvre wrote:
> On 3/2/06, Judd Vinet <jvinet at zeroflux.org> wrote:
> >
> > That would super duper.  (yea that's right, I said "super duper")
> >
> > The arch page was originally slapped together for me back in 2002 (or
> > was it 2003?) by a fellow co-worker who had more free time than I.  If
> > someone were inclined to re-design the thing, I'd be a happy geek.  The
> > PHP portions should be re-coded too, perhaps in a proper framework.
> > They're all pretty adhoc right now, and it's ugly.
> >
> 
> would you guys accept help from a debian user? :P

*hiss*

Nah, just kidding.  I don't judge.  :)


- J




From dadexter at gmail.com  Thu Mar  2 13:43:19 2006
From: dadexter at gmail.com (Martin Lefebvre)
Date: Thu, 2 Mar 2006 13:43:19 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <20060302183551.GG25364@zeroflux.org>
References: <6567.1141316670@www084.gmx.net>
	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
	<20060302182535.GF25364@zeroflux.org>
	<ed5f04980603021033qac6f5ei589347ed9a68735e@mail.gmail.com>
	<20060302183551.GG25364@zeroflux.org>
Message-ID: <ed5f04980603021043h231e61d1nd998a501b64be83e@mail.gmail.com>

On 3/2/06, Judd Vinet <jvinet at zeroflux.org> wrote:
>
> *hiss*
>
> Nah, just kidding.  I don't judge.  :)
>

Good :P

--
Martin Lefebvre
eMail: dadexter at gmail.com

WWW: https://sigterm.homeunix.com
Registered Linux #349269

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s:-- a- C+++ UL++++ P-- L++++ E--- W+++ N++ o-- K- w---
O- M-- V-- PS PE Y PGP-- t+++ 5- X R- tv++ b+ DI-- D+
G-- e h++ r++ y**
------END GEEK CODE BLOCK------



From moritz.esser at gmx.de  Thu Mar  2 14:15:44 2006
From: moritz.esser at gmx.de (Moritz Alexander Esser)
Date: Thu, 02 Mar 2006 20:15:44 +0100
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <20060302182535.GF25364@zeroflux.org>
References: <6567.1141316670@www084.gmx.net>	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
	<20060302182535.GF25364@zeroflux.org>
Message-ID: <44074460.9060606@gmx.de>

What do you think about the PPC website? I like it's simplicity!
http://www.archlinuxppc.org/joomla/

Regards,
Moritz

Judd Vinet wrote:
> On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
>> I don't think its a good idea. Have you looked at the sources for the
>> existing page?  Its got crazy spans, tables, hard to read, I don't
>> know how Judd manages to maintain it. :-D I think its actually time
>> for the main archlinux.org site to be rewritten in nice clean XHTML
>> 1.0 and CSS...
> 
> That would super duper.  (yea that's right, I said "super duper")
> 
> The arch page was originally slapped together for me back in 2002 (or
> was it 2003?) by a fellow co-worker who had more free time than I.  If
> someone were inclined to re-design the thing, I'd be a happy geek.  The
> PHP portions should be re-coded too, perhaps in a proper framework.
> They're all pretty adhoc right now, and it's ugly.
> 
> 
> - J
> 
> 
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
> 
> 



From syamajala at gamebox.net  Thu Mar  2 14:30:59 2006
From: syamajala at gamebox.net (seshu yamajala)
Date: Thu, 2 Mar 2006 14:30:59 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
References: <6567.1141316670@www084.gmx.net>
	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
Message-ID: <71807035-B629-406D-B28F-6547A7B641B7@gamebox.net>


On Mar 2, 2006, at 11:29 AM, Dusty Phillips wrote:

>
> I don't think its a good idea. Have you looked at the sources for the
> existing page?  Its got crazy spans, tables, hard to read, I don't
> know how Judd manages to maintain it. :-D I think its actually time
> for the main archlinux.org site to be rewritten in nice clean XHTML
> 1.0 and CSS... now we're talking a whole new level, but perhaps its
> time to think about organizing a new al.org web design that
> incorporates arch64 (and possibly other ports) into the new main site.
> Would be cool if somebody with a whole pile of time on their hands and
> l33t web dev skills could integrate the forum, wiki, art.archlinux,
> documentation, planet, dev blog, ports, and main site into one
> super-charged new ArchLinux portal.
>
> Whole pile of time on their hands..... good luck. :(
>
> Dusty

i know this sounds crazy, but i think lisp would be excellent for  
this job.
Everything could probably be integrated and it wouldn't take that  
long to do. Sadly, my lisp skills are still not that great.

- Syamajala




From w9ya at arrl.net  Thu Mar  2 16:09:57 2006
From: w9ya at arrl.net (w9ya at arrl.net)
Date: Thu, 2 Mar 2006 16:09:57 -0500 (EST)
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <44074460.9060606@gmx.de>
References: <6567.1141316670@www084.gmx.net>	<7ecb79cc0603020829g2befe63ckd443ff5b044c135a@mail.gmail.com>
	<20060302182535.GF25364@zeroflux.org> <44074460.9060606@gmx.de>
Message-ID: <43526.65.166.80.196.1141333797.squirrel@w9ya0.pointclark.net>

Perhaps a speeling checkerr would be in order:

<http://www.archlinuxppc.org/joomla/index.php?option=com_content&task=view&id=12&Itemid=28>

(Grin)

("Dowloads")


> What do you think about the PPC website? I like it's simplicity!
> http://www.archlinuxppc.org/joomla/
>
> Regards,
> Moritz
>
> Judd Vinet wrote:
>> On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
>>> I don't think its a good idea. Have you looked at the sources for the
>>> existing page?  Its got crazy spans, tables, hard to read, I don't
>>> know how Judd manages to maintain it. :-D I think its actually time
>>> for the main archlinux.org site to be rewritten in nice clean XHTML
>>> 1.0 and CSS...
>>
>> That would super duper.  (yea that's right, I said "super duper")
>>
>> The arch page was originally slapped together for me back in 2002 (or
>> was it 2003?) by a fellow co-worker who had more free time than I.  If
>> someone were inclined to re-design the thing, I'd be a happy geek.
>> The PHP portions should be re-coded too, perhaps in a proper
>> framework. They're all pretty adhoc right now, and it's ugly.
>>
>>
>> - J
>>
>>
>> _______________________________________________
>> arch-ports mailing list
>> arch-ports at archlinux.org
>> http://www.archlinux.org/mailman/listinfo/arch-ports
>>
>>
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports






From eliott at cactuswax.net  Thu Mar  2 16:10:28 2006
From: eliott at cactuswax.net (eliott)
Date: Thu, 02 Mar 2006 16:10:28 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
Message-ID: <15301514.175791141333828777.JavaMail.servlet@perfora>

I would be more than willing to help with such a project. 
My design skills leave some to be desired as far as layout goes (I have no artistic sense at all), but from a structural and design standpoint, I am probably not the worst out there. ;)


>On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
>> I don't think its a good idea. Have you looked at the sources for the
>> existing page?  Its got crazy spans, tables, hard to read, I don't
>> know how Judd manages to maintain it. :-D I think its actually time
>> for the main archlinux.org site to be rewritten in nice clean XHTML
>> 1.0 and CSS...
>
>That would super duper.  (yea that's right, I said "super duper")
>
>The arch page was originally slapped together for me back in 2002 (or
>was it 2003?) by a fellow co-worker who had more free time than I.  If
>someone were inclined to re-design the thing, I'd be a happy geek.  The
>PHP portions should be re-coded too, perhaps in a proper framework.
>They're all pretty adhoc right now, and it's ugly.
>
>
>- J
>
>
>_______________________________________________
>arch-ports mailing list
>arch-ports at archlinux.org
>http://www.archlinux.org/mailman/listinfo/arch-ports



From msg431 at gmail.com  Thu Mar  2 16:11:36 2006
From: msg431 at gmail.com (Matthew G)
Date: Thu, 2 Mar 2006 16:11:36 -0500
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <15301514.175791141333828777.JavaMail.servlet@perfora>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>
Message-ID: <7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>

I'd help though I don't think I'll have much free time :(

On 3/2/06, eliott <eliott at cactuswax.net> wrote:
> I would be more than willing to help with such a project.
> My design skills leave some to be desired as far as layout goes (I have no artistic sense at all), but from a structural and design standpoint, I am probably not the worst out there. ;)
>
>
> >On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
> >> I don't think its a good idea. Have you looked at the sources for the
> >> existing page?  Its got crazy spans, tables, hard to read, I don't
> >> know how Judd manages to maintain it. :-D I think its actually time
> >> for the main archlinux.org site to be rewritten in nice clean XHTML
> >> 1.0 and CSS...
> >
> >That would super duper.  (yea that's right, I said "super duper")
> >
> >The arch page was originally slapped together for me back in 2002 (or
> >was it 2003?) by a fellow co-worker who had more free time than I.  If
> >someone were inclined to re-design the thing, I'd be a happy geek.  The
> >PHP portions should be re-coded too, perhaps in a proper framework.
> >They're all pretty adhoc right now, and it's ugly.
> >
> >
> >- J
> >
> >
> >_______________________________________________
> >arch-ports mailing list
> >arch-ports at archlinux.org
> >http://www.archlinux.org/mailman/listinfo/arch-ports
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>


--
Matthew | Website http://msg43.net | AIM: MSG431 | MSN + Gmail: MSG431 at gmail.com



From ganja.guru at airtelbroadband.in  Thu Mar  2 22:38:30 2006
From: ganja.guru at airtelbroadband.in (ganja.guru)
Date: Fri, 03 Mar 2006 09:08:30 +0530
Subject: [arch-ports] New pacman package in testing
Message-ID: <4407BA36.8020408@airtelbroadband.in>

The latest pacman in testing has "csup" as a dependency. csup is in the 
community repo. After you "mkdir /var/abs32" you will be able to run abs 
in arch64 (no need to chroot to arch32 to run abs)

ganja_guru



From jason at archlinux.org  Fri Mar  3 00:32:58 2006
From: jason at archlinux.org (Jason Chu)
Date: Fri, 3 Mar 2006 00:32:58 -0500
Subject: [arch-ports] New pacman package in testing
In-Reply-To: <4407BA36.8020408@airtelbroadband.in>
References: <4407BA36.8020408@airtelbroadband.in>
Message-ID: <20060303053258.GA13025@mercury.xentac.net>

On Fri, Mar 03, 2006 at 09:08:30AM +0530, ganja.guru wrote:
> The latest pacman in testing has "csup" as a dependency. csup is in the 
> community repo. After you "mkdir /var/abs32" you will be able to run abs 
> in arch64 (no need to chroot to arch32 to run abs)
> 
> ganja_guru

Just a thought, you probably don't want pacman to depend on anything, just
as the i686 pacman doesn't depend on anything.

I'd suggest instead to modify the /usr/bin/abs script to just tell you you
need csup, right around line 36.

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060303/18e36880/attachment.pgp>

From mrfubar at gmail.com  Fri Mar  3 10:27:09 2006
From: mrfubar at gmail.com (Mr FUBAR)
Date: Fri, 3 Mar 2006 16:27:09 +0100
Subject: [arch-ports] Arch64 - call for a website maintainer
In-Reply-To: <7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>
	<7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>
Message-ID: <12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>

If you're doing the website in clean XHTML, it's easy to split up
layout from design. CSS is the way to go! ;)

On 3/2/06, Matthew G <msg431 at gmail.com> wrote:
> I'd help though I don't think I'll have much free time :(
>
> On 3/2/06, eliott <eliott at cactuswax.net> wrote:
> > I would be more than willing to help with such a project.
> > My design skills leave some to be desired as far as layout goes (I have no artistic sense at all), but from a structural and design standpoint, I am probably not the worst out there. ;)
> >
> >
> > >On Thu, Mar 02, 2006 at 11:29:46AM -0500, Dusty Phillips wrote:
> > >> I don't think its a good idea. Have you looked at the sources for the
> > >> existing page?  Its got crazy spans, tables, hard to read, I don't
> > >> know how Judd manages to maintain it. :-D I think its actually time
> > >> for the main archlinux.org site to be rewritten in nice clean XHTML
> > >> 1.0 and CSS...
> > >
> > >That would super duper.  (yea that's right, I said "super duper")
> > >
> > >The arch page was originally slapped together for me back in 2002 (or
> > >was it 2003?) by a fellow co-worker who had more free time than I.  If
> > >someone were inclined to re-design the thing, I'd be a happy geek.  The
> > >PHP portions should be re-coded too, perhaps in a proper framework.
> > >They're all pretty adhoc right now, and it's ugly.
> > >
> > >
> > >- J
> > >
> > >
> > >_______________________________________________
> > >arch-ports mailing list
> > >arch-ports at archlinux.org
> > >http://www.archlinux.org/mailman/listinfo/arch-ports
> >
> > _______________________________________________
> > arch-ports mailing list
> > arch-ports at archlinux.org
> > http://www.archlinux.org/mailman/listinfo/arch-ports
> >
>
>
> --
> Matthew | Website http://msg43.net | AIM: MSG431 | MSN + Gmail: MSG431 at gmail.com
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>



From driadan at willinux.net  Fri Mar 10 04:44:23 2006
From: driadan at willinux.net (Guillermo Vaya Perez)
Date: Fri, 10 Mar 2006 10:44:23 +0100
Subject: [arch-ports] Arch64 - Iso problems
In-Reply-To: <12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>	<7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>
	<12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>
Message-ID: <44114A77.3090600@willinux.net>

Hi, yesterday I decided to give again a try to arch64 (the first time I 
tried I couldn't get it working)
So I downloaded the iso (beta6) and tried to install it.
The error appears in the install packages section:

    chroot: cannot execute /bin/bash: Exec format error

that one appears in several places along the install log. Also, the last 
line is:

    /mnt/sbin/ldconfig: 1 : Syntax error: "(" unexpected

I have no idea of what can be wrong, it's like bash is corrupted or the 
wrong architecture (I googled it ;)), and I can't boot into this system, 
since no mkinitrd is generated (installing the kernel gives those two 
errors too).

Since my ethernet module (uli526x) is not compiled in the kernel, I 
can't try to install by FTP.

Any hints? How can I get it installed?



From terakuma at imbris.net  Fri Mar 10 10:21:10 2006
From: terakuma at imbris.net (Maluvia)
Date: Fri, 10 Mar 2006 07:21:10 -0800
Subject: [arch-ports] Arch64 - Iso problems
In-Reply-To: <44114A77.3090600@willinux.net>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>
	<7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>
	<12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>
	<44114A77.3090600@willinux.net>
Message-ID: <200603100721100290.005F7EF0@mail.imbris.net>

Hi Guillermo,

I had this problem as well - I think it's been there from the get-go.
(I just download the packages now and use pacman.static to do the install
from another working partition.)

FWIW, I was able to get a working install with the ISO the first time by
booting into the system under the single-user/emergency mode and running
/sbin/ldconfig.
After that I was able to boot-up normally.

I don't really understand what the problem with bash is - (I ended up using
the Gentoo one instead.)

- Maluvia

*********** REPLY SEPARATOR  ***********

On 3/10/06 at 10:44 AM Guillermo Vaya Perez wrote:

>Hi, yesterday I decided to give again a try to arch64 (the first time I 
>tried I couldn't get it working)
>So I downloaded the iso (beta6) and tried to install it.
>The error appears in the install packages section:
>
>    chroot: cannot execute /bin/bash: Exec format error
>
>that one appears in several places along the install log. Also, the last 
>line is:
>
>    /mnt/sbin/ldconfig: 1 : Syntax error: "(" unexpected
>
>I have no idea of what can be wrong, it's like bash is corrupted or the 
>wrong architecture (I googled it ;)), and I can't boot into this system, 
>since no mkinitrd is generated (installing the kernel gives those two 
>errors too).
>
>Since my ethernet module (uli526x) is not compiled in the kernel, I 
>can't try to install by FTP.
>
>Any hints? How can I get it installed?
>
>_______________________________________________
>arch-ports mailing list
>arch-ports at archlinux.org
>http://www.archlinux.org/mailman/listinfo/arch-ports
>
>__________ NOD32 1.1436 (20060309) Information __________
>
>This message was checked by NOD32 antivirus system.
>http://www.eset.com






From a.radke at arcor.de  Fri Mar 10 11:00:32 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Fri, 10 Mar 2006 17:00:32 +0100
Subject: [arch-ports] Arch64 - Iso problems
In-Reply-To: <200603100721100290.005F7EF0@mail.imbris.net>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>	<7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>	<12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>	<44114A77.3090600@willinux.net>
	<200603100721100290.005F7EF0@mail.imbris.net>
Message-ID: <4411A2A0.5030607@arcor.de>

Maluvia schrieb:
> FWIW, I was able to get a working install with the ISO the first time by
> booting into the system under the single-user/emergency mode and running
> /sbin/ldconfig.
> After that I was able to boot-up normally.
>
>   
That is an interesting new information! The ISO is still in an early
development state.
For now it's still recommended to follow the steps described in the wiki.

But everybody could try this way and may report if this is an easier way
than installing
from a 64bit livecd.

Maybe we will see you once again using Arch64.

AndyRTR



From a.radke at arcor.de  Fri Mar 10 11:00:55 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Fri, 10 Mar 2006 17:00:55 +0100
Subject: [arch-ports] Arch64 - Iso problems
In-Reply-To: <200603100721100290.005F7EF0@mail.imbris.net>
References: <15301514.175791141333828777.JavaMail.servlet@perfora>	<7ce67b220603021311n52106b86r59215a6514bcd81@mail.gmail.com>	<12983d900603030727p7be6222ame3a482c9fdd1fd74@mail.gmail.com>	<44114A77.3090600@willinux.net>
	<200603100721100290.005F7EF0@mail.imbris.net>
Message-ID: <4411A2B7.8050705@arcor.de>

Maluvia schrieb:
> FWIW, I was able to get a working install with the ISO the first time by
> booting into the system under the single-user/emergency mode and running
> /sbin/ldconfig.
> After that I was able to boot-up normally.
>
>   
That is an interesting new information! The ISO is still in an early
development state.
For now it's still recommended to follow the steps described in the wiki.

But everybody could try this way and may report if this is an easier way
than installing
from a 64bit livecd.

Maybe we will see you once again using Arch64.

AndyRTR


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/5077319d/attachment.pgp>

From jason at archlinux.org  Fri Mar 10 18:46:54 2006
From: jason at archlinux.org (Jason Chu)
Date: Fri, 10 Mar 2006 18:46:54 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
Message-ID: <20060310234654.GB2402@mercury.xentac.net>

Alright, here's some discussion about PKGBUILDs and multiple architecture
support.

We already talked about adding an arch= array to PKGBUILDs.  The array
would list all the architectures a PKGBUILD is known to build on.  I don't
think makepkg should stop a package from building on an architecture that
isn't listed, but it should at least display a really annoying message
warning the user that the package probably won't build properly.

The second thing I wanted to talk about is pkgrels.  We have a problem in
that some releases will only affect one architecture and we don't want
people using other architectures to have to download packages that haven't
changed.

My proposal goes something like this:

We continue using the pkgrel variable the same way.  Each time an update
(that isn't a version update) happens to a package, its pkgrel is
increased.

We also add support to makepkg for a couple more variables.  Let's call
them pkgrel_i686, pkgrel_amd64, etc.  If one of these variables exists,
makepkg (and gensync, and updatesync...) will us that pkgrel for the
architecture, instead of the pkgrel.

What this lets us do is something like this:

Package foo is at version 1.2.3-1.  A change that only affects i686
happens, so the package maintainer makes the changes (marking them with
[ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2
and leaves all the other variables (pkgrel_amd64, etc) set to 1.

When you build the package on i686, it comes out as 1.2.3-2.  If you build
it on any of the other listed architectures, it comes out as 1.2.3-1.

This does mean that if there's a release for all architectures, it becomes
-3 everywhere and amd64 users see a jump from -1 to -3.  We already have a
similar situation with the testing repo.

Using this method we can target changes for different architectures all
while keeping a single PKGBUILD.  There are very few changes needed in
makepkg and the other tools to cover all the upgrade cases that I can think
of.

Thoughts?

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/c81a3d65/attachment.pgp>

From a.radke at arcor.de  Fri Mar 10 18:05:06 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 11 Mar 2006 00:05:06 +0100
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060310234654.GB2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>
Message-ID: <44120622.2000800@arcor.de>

Jason Chu schrieb:
> We also add support to makepkg for a couple more variables.  Let's call
> them pkgrel_i686, pkgrel_amd64, etc.  If one of these variables exists,
> makepkg (and gensync, and updatesync...) will us that pkgrel for the
> architecture, instead of the pkgrel.
>
> What this lets us do is something like this:
>
> Package foo is at version 1.2.3-1.  A change that only affects i686
> happens, so the package maintainer makes the changes (marking them with
> [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2
> and leaves all the other variables (pkgrel_amd64, etc) set to 1.
>
> When you build the package on i686, it comes out as 1.2.3-2.  If you build
> it on any of the other listed architectures, it comes out as 1.2.3-1.
>
> This does mean that if there's a release for all architectures, it becomes
> -3 everywhere and amd64 users see a jump from -1 to -3.  We already have a
> similar situation with the testing repo.
>   
Do we really need more variables? Why not leave only one pkgrel number
e.g. foo 1.0-1.
If the x86_64 bit package needs a fix we would build only a 1.0-2 on
x86_64 and
let out not affected architectures. Next common release would be 1.0-3 for
all archs.

Is it possible that way?

And maybe you should start in another mail the svn/cvs war again ;-)

AndyRTR



From jason at archlinux.org  Fri Mar 10 19:28:39 2006
From: jason at archlinux.org (Jason Chu)
Date: Fri, 10 Mar 2006 19:28:39 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <44120622.2000800@arcor.de>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
Message-ID: <20060311002839.GC2402@mercury.xentac.net>

On Sat, Mar 11, 2006 at 12:05:06AM +0100, Andreas Radke wrote:
> Jason Chu schrieb:
> > We also add support to makepkg for a couple more variables.  Let's call
> > them pkgrel_i686, pkgrel_amd64, etc.  If one of these variables exists,
> > makepkg (and gensync, and updatesync...) will us that pkgrel for the
> > architecture, instead of the pkgrel.
> >
> > What this lets us do is something like this:
> >
> > Package foo is at version 1.2.3-1.  A change that only affects i686
> > happens, so the package maintainer makes the changes (marking them with
> > [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2
> > and leaves all the other variables (pkgrel_amd64, etc) set to 1.
> >
> > When you build the package on i686, it comes out as 1.2.3-2.  If you build
> > it on any of the other listed architectures, it comes out as 1.2.3-1.
> >
> > This does mean that if there's a release for all architectures, it becomes
> > -3 everywhere and amd64 users see a jump from -1 to -3.  We already have a
> > similar situation with the testing repo.
> >   
> Do we really need more variables? Why not leave only one pkgrel number
> e.g. foo 1.0-1.
> If the x86_64 bit package needs a fix we would build only a 1.0-2 on
> x86_64 and
> let out not affected architectures. Next common release would be 1.0-3 for
> all archs.
> 
> Is it possible that way?
> 
> And maybe you should start in another mail the svn/cvs war again ;-)
> 
> AndyRTR

My problem with that is that you really depend on your version control to
give you the right versions for each architecture and keeping them in sync
becomes difficult again.

It's possible, but with the more-variables method you could take either
PKGBUILD and get the same output on amd64.  With yours, I'd get this amd64
-2 version that never actually existed.

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/130423ab/attachment.pgp>

From terakuma at imbris.net  Fri Mar 10 18:31:39 2006
From: terakuma at imbris.net (Maluvia)
Date: Fri, 10 Mar 2006 15:31:39 -0800
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <44120622.2000800@arcor.de>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
Message-ID: <200603101531390810.0220A070@mail.imbris.net>

>Do we really need more variables? Why not leave only one pkgrel number
>e.g. foo 1.0-1.
>If the x86_64 bit package needs a fix we would build only a 1.0-2 on
>x86_64 and
>let out not affected architectures. Next common release would be 1.0-3 for
>all archs.
>
>Is it possible that way?

In the interest of keeping a single common PKGBUILD it sounds like Jason's
solution would be the best, since it lets gensync/updatesync detect and
pull the needed updates automatically. 
(If I understand correctly.)
I don't even use ABS so I should probably shut-up, but since you asked . .
. . .   :)

Maluvia





From buchuki at gmail.com  Fri Mar 10 18:43:14 2006
From: buchuki at gmail.com (Dusty Phillips)
Date: Fri, 10 Mar 2006 18:43:14 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <200603101531390810.0220A070@mail.imbris.net>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
	<200603101531390810.0220A070@mail.imbris.net>
Message-ID: <7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>

Would it be possible to use an array (or dict ;-)) of architecture
releases instead of multiple variables? This would restrict it to one
line in the PKGBUILD. I guess we could also have convention of
semi-colon separating the arch-pkg-rel variables to conserve space.
Really don't like how long these things are getting... :(

Dusty

On 3/10/06, Maluvia <terakuma at imbris.net> wrote:
> >Do we really need more variables? Why not leave only one pkgrel number
> >e.g. foo 1.0-1.
> >If the x86_64 bit package needs a fix we would build only a 1.0-2 on
> >x86_64 and
> >let out not affected architectures. Next common release would be 1.0-3 for
> >all archs.
> >
> >Is it possible that way?
>
> In the interest of keeping a single common PKGBUILD it sounds like Jason's
> solution would be the best, since it lets gensync/updatesync detect and
> pull the needed updates automatically.
> (If I understand correctly.)
> I don't even use ABS so I should probably shut-up, but since you asked . .
> . . .   :)
>
> Maluvia
>
>
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>



From jason at archlinux.org  Fri Mar 10 19:50:30 2006
From: jason at archlinux.org (Jason Chu)
Date: Fri, 10 Mar 2006 19:50:30 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
	<200603101531390810.0220A070@mail.imbris.net>
	<7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>
Message-ID: <20060311005030.GD2402@mercury.xentac.net>

On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
> Would it be possible to use an array (or dict ;-)) of architecture
> releases instead of multiple variables? This would restrict it to one
> line in the PKGBUILD. I guess we could also have convention of
> semi-colon separating the arch-pkg-rel variables to conserve space.
> Really don't like how long these things are getting... :(
> 
> Dusty

Something like that would require parsing.  Bash doesn't support any sort
of associative arrays, so we'd end up doing something like how depends
version marking works ie.

arch_rels=('i686=3' 'amd64=2')

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/e6e7a215/attachment.pgp>

From eliott at cactuswax.net  Fri Mar 10 19:46:28 2006
From: eliott at cactuswax.net (eliott at cactuswax.net)
Date: Fri, 10 Mar 2006 16:46:28 -0800 (PST)
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060311005030.GD2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
	<200603101531390810.0220A070@mail.imbris.net>
	<7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>
	<20060311005030.GD2402@mercury.xentac.net>
Message-ID: <46745.198.6.46.11.1142037988.squirrel@webmail.cactuswax.net>

I appreciate the goal of joining multiple architectures into a single
pkgbuild, but I haven't heard much (at least that I remember) lately about
how pkgbuilds with different build requirements based on architecture are
going to be handled.

Are there going to be seperate "build" definitions, based upon architecture?
i686_build()
ppc_build()

or is there going to be some type of variable testing inside a single
build defintion...
build() {
 if [ $ARCHx = "i696x" ]; then
    <custom stuff here>
 fi
}

Also, would there be seperate file sections? If one architecture requires
a patch that another one doesn't, are all files fetched for build
regardless?

I suppose I am saying that a little more background into how the overall
structure is going to work, may help make informed opinions about
versioning conventions.

I apologize if I missed the discussion of the above, and this has already
been covered.


> On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
>> Would it be possible to use an array (or dict ;-)) of architecture
>> releases instead of multiple variables? This would restrict it to one
>> line in the PKGBUILD. I guess we could also have convention of
>> semi-colon separating the arch-pkg-rel variables to conserve space.
>> Really don't like how long these things are getting... :(
>>
>> Dusty
>
> Something like that would require parsing.  Bash doesn't support any sort
> of associative arrays, so we'd end up doing something like how depends
> version marking works ie.
>
> arch_rels=('i686=3' 'amd64=2')
>
> Jason
>
> --
> If you understand, things are just as they are.  If you do not understand,
> things are just as they are.
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>





From jason at archlinux.org  Fri Mar 10 21:08:55 2006
From: jason at archlinux.org (Jason Chu)
Date: Fri, 10 Mar 2006 21:08:55 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <46745.198.6.46.11.1142037988.squirrel@webmail.cactuswax.net>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
	<200603101531390810.0220A070@mail.imbris.net>
	<7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>
	<20060311005030.GD2402@mercury.xentac.net>
	<46745.198.6.46.11.1142037988.squirrel@webmail.cactuswax.net>
Message-ID: <20060311020855.GE2402@mercury.xentac.net>

All your questions should be answered here:

http://www.archlinux.org/pipermail/arch-ports/2006-February/000112.html

Both the build() and any source=() changes can happen with [ ] style
testing.  This is bash after all ;)

Jason

On Fri, Mar 10, 2006 at 04:46:28PM -0800, eliott at cactuswax.net wrote:
> I appreciate the goal of joining multiple architectures into a single
> pkgbuild, but I haven't heard much (at least that I remember) lately about
> how pkgbuilds with different build requirements based on architecture are
> going to be handled.
> 
> Are there going to be seperate "build" definitions, based upon architecture?
> i686_build()
> ppc_build()
> 
> or is there going to be some type of variable testing inside a single
> build defintion...
> build() {
>  if [ $ARCHx = "i696x" ]; then
>     <custom stuff here>
>  fi
> }
> 
> Also, would there be seperate file sections? If one architecture requires
> a patch that another one doesn't, are all files fetched for build
> regardless?
> 
> I suppose I am saying that a little more background into how the overall
> structure is going to work, may help make informed opinions about
> versioning conventions.
> 
> I apologize if I missed the discussion of the above, and this has already
> been covered.
> 
> 
> > On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
> >> Would it be possible to use an array (or dict ;-)) of architecture
> >> releases instead of multiple variables? This would restrict it to one
> >> line in the PKGBUILD. I guess we could also have convention of
> >> semi-colon separating the arch-pkg-rel variables to conserve space.
> >> Really don't like how long these things are getting... :(
> >>
> >> Dusty
> >
> > Something like that would require parsing.  Bash doesn't support any sort
> > of associative arrays, so we'd end up doing something like how depends
> > version marking works ie.
> >
> > arch_rels=('i686=3' 'amd64=2')
> >
> > Jason
> >
> > --
> > If you understand, things are just as they are.  If you do not understand,
> > things are just as they are.
> > _______________________________________________
> > arch-ports mailing list
> > arch-ports at archlinux.org
> > http://www.archlinux.org/mailman/listinfo/arch-ports
> >
> 
> 
> 
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
> 

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060310/83ca0238/attachment.pgp>

From ganja.guru at airtelbroadband.in  Fri Mar 10 23:43:59 2006
From: ganja.guru at airtelbroadband.in (ganja.guru)
Date: Sat, 11 Mar 2006 10:13:59 +0530
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060311020855.GE2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>	<44120622.2000800@arc
	or.de>	<200603101531390810.0220A070@mail.imbris.net>	<7ecb79cc0603101543u39
	445f74k6682be40cebe51ae@mail.gmail.com>	<20060311005030.GD2402@mercury.xent
	ac.net>	<46745.198.6.46.11.1142037988.squirrel@webmail.cactuswax.net> 
	<20060311020855.GE2402@mercury.xentac.net>
Message-ID: <4412558F.1020700@airtelbroadband.in>

I think Xentac's suggestion is simple enough..but do we really need to 
have the original "pkgrel" variable when we have the new pkgrel_i686 and 
pkgrel_amd64? What purpose does the original "pkgrel" variable serve 
when the final package release number does not depend on it?

ganja_guru


Jason Chu wrote:
> All your questions should be answered here:
>
> http://www.archlinux.org/pipermail/arch-ports/2006-February/000112.html
>
> Both the build() and any source=() changes can happen with [ ] style
> testing.  This is bash after all ;)
>
> Jason
>
> On Fri, Mar 10, 2006 at 04:46:28PM -0800, eliott at cactuswax.net wrote:
>   
>> I appreciate the goal of joining multiple architectures into a single
>> pkgbuild, but I haven't heard much (at least that I remember) lately about
>> how pkgbuilds with different build requirements based on architecture are
>> going to be handled.
>>
>> Are there going to be seperate "build" definitions, based upon architecture?
>> i686_build()
>> ppc_build()
>>
>> or is there going to be some type of variable testing inside a single
>> build defintion...
>> build() {
>>  if [ $ARCHx = "i696x" ]; then
>>     <custom stuff here>
>>  fi
>> }
>>
>> Also, would there be seperate file sections? If one architecture requires
>> a patch that another one doesn't, are all files fetched for build
>> regardless?
>>
>> I suppose I am saying that a little more background into how the overall
>> structure is going to work, may help make informed opinions about
>> versioning conventions.
>>
>> I apologize if I missed the discussion of the above, and this has already
>> been covered.
>>
>>
>>     




From jason at archlinux.org  Sat Mar 11 03:04:39 2006
From: jason at archlinux.org (Jason Chu)
Date: Sat, 11 Mar 2006 03:04:39 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <4412558F.1020700@airtelbroadband.in>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44120622.2000800@arcor.de>
	<200603101531390810.0220A070@mail.imbris.net>
	<7ecb79cc0603101543u39445f74k6682be40cebe51ae@mail.gmail.com>
	<20060311005030.GD2402@mercury.xentac.net>
	<46745.198.6.46.11.1142037988.squirrel@webmail.cactuswax.net>
	<20060311020855.GE2402@mercury.xentac.net>
	<4412558F.1020700@airtelbroadband.in>
Message-ID: <20060311080439.GF2402@mercury.xentac.net>

On Sat, Mar 11, 2006 at 10:13:59AM +0530, ganja.guru wrote:
> I think Xentac's suggestion is simple enough..but do we really need to 
> have the original "pkgrel" variable when we have the new pkgrel_i686 and 
> pkgrel_amd64? What purpose does the original "pkgrel" variable serve 
> when the final package release number does not depend on it?
> 
> ganja_guru

If an arch isn't listed, it'll use the pkgrel.  Only if a change doesn't
affect something does it get its own pkgrel variable.

It also helps to have a global pkgrel that everything stays in sync with.

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060311/a4a72b82/attachment.pgp>

From a.radke at arcor.de  Sat Mar 11 02:36:23 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 11 Mar 2006 08:36:23 +0100
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060310234654.GB2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>
Message-ID: <44127DF7.90705@arcor.de>

Jason Chu schrieb:
> Alright, here's some discussion about PKGBUILDs and multiple architecture
> support.
What about having different sources?

For the kernels I can imagine a config_x86/config_ppc/config_x86_64
file. But there are packages with huge arch specific  sources like j2re,
jsdk, nvidia and some others.

Can this be done by the bash [ ] or how else?

And how will makepkg decide what sources to download and md5sum are the
correct checksums? Maybe we need source_x64_64 and md5sums_x86_64?

AndyRTR



From jason at archlinux.org  Sat Mar 11 03:42:37 2006
From: jason at archlinux.org (Jason Chu)
Date: Sat, 11 Mar 2006 03:42:37 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <44127DF7.90705@arcor.de>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44127DF7.90705@arcor.de>
Message-ID: <20060311084237.GG2402@mercury.xentac.net>

On Sat, Mar 11, 2006 at 08:36:23AM +0100, Andreas Radke wrote:
> Jason Chu schrieb:
> > Alright, here's some discussion about PKGBUILDs and multiple architecture
> > support.
> What about having different sources?
> 
> For the kernels I can imagine a config_x86/config_ppc/config_x86_64
> file. But there are packages with huge arch specific  sources like j2re,
> jsdk, nvidia and some others.
> 
> Can this be done by the bash [ ] or how else?
> 
> And how will makepkg decide what sources to download and md5sum are the
> correct checksums? Maybe we need source_x64_64 and md5sums_x86_64?
> 
> AndyRTR

If there is that large of a discrepency (like j2re, from what I
understand), it will be a whole different package: j2re-amd64.

If there are just patches and things like that it will look something like
this:
source=('sources' 'that' 'are' 'common')
[ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060311/2d208f94/attachment.pgp>

From dale at archlinux.org  Sat Mar 11 08:56:24 2006
From: dale at archlinux.org (Dale Blount)
Date: Sat, 11 Mar 2006 08:56:24 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060311084237.GG2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44127DF7.90705@arcor.de>  <20060311084237.GG2402@mercury.xentac.net>
Message-ID: <1142085384.7066.1.camel@localhost.localdomain>


> If there is that large of a discrepency (like j2re, from what I
> understand), it will be a whole different package: j2re-amd64.
> 
> Jason


Side note:  Don't we want to call it something besides amd64 since it
*should* probably work on emt64 Intels? x86_64 ?




From a.radke at arcor.de  Sat Mar 11 09:06:28 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 11 Mar 2006 15:06:28 +0100
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <1142085384.7066.1.camel@localhost.localdomain>
References: <20060310234654.GB2402@mercury.xentac.net>	<44127DF7.90705@arcor.de>
	<20060311084237.GG2402@mercury.xentac.net>
	<1142085384.7066.1.camel@localhost.localdomain>
Message-ID: <4412D964.7070608@arcor.de>

Dale Blount schrieb:
>> If there is that large of a discrepency (like j2re, from what I
>> understand), it will be a whole different package: j2re-amd64.
>>
>> Jason
>>     
>
>
> Side note:  Don't we want to call it something besides amd64 since it
> *should* probably work on emt64 Intels? x86_64 ?
>
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>
>   
Sure. The 64bit dev always use x86_64 or x64.

AndyRTR



From a.radke at arcor.de  Sat Mar 11 15:37:09 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 11 Mar 2006 21:37:09 +0100
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060311084237.GG2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>	<44127DF7.90705@arcor.de>
	<20060311084237.GG2402@mercury.xentac.net>
Message-ID: <441334F5.50708@arcor.de>

Jason Chu schrieb:
> If there is that large of a discrepency (like j2re, from what I
> understand), it will be a whole different package: j2re-amd64.
>
> If there are just patches and things like that it will look something like
> this:
> source=('sources' 'that' 'are' 'common')
> [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
>
> Jason
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>   
Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg
downloading the large 32bit source. But only therefor a different package?

# $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $
# Contributed by: Jason Chu <jason at archlinux.org>
# This PKGBUILD was built largely from code in Crux Linux, then modified
a bunch to make it j2re
# Maintainer: Jason Chu <jason at archlinux.org>
# Contributions by Dusty

pkgname=j2re
pkgver=1.5.0_06
pkgrel=3
pkgdesc="Sun's java runtime environment"
url="http://java.sun.com"
depends=('gcc' 'glibc')
install="j2re.install"
#source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04-linux-i586.bin
j2re.profile jre.patch)
#source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin
j2re.profile jre.patch)
[ "$CARCH" == "x86_64" ] &&
source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin
j2re.profile jre.patch)
md5sums=('e0a88dbec9bfe3195794bb652bfc6516'
'87d90b2e075b77c41a7efec7411a4153'\
         '3b589fa777fab553d4f7ce57bc90ce48')
[ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b'
'87d90b2e075b77c41a7efec7411a4153'\
         '91544f3d5d5aa054db7ce2144d17138b')

build() {
    cd $startdir/src
    [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin
<jre.patch
    [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin
<jre.patch
   
  mkdir -p $startdir/pkg/opt/java
  cd $startdir/pkg/opt/java
  [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh
$startdir/src/jre-1_5_0_06-linux-i586.bin
  [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh
$startdir/src/jre-1_5_0_06-linux-amd64.bin
  mv jre${pkgver} jre
  rm -r jre/man/ja*
  for i in jre/*; do
    if [ -f $i ]; then rm -f $i; fi
  done
  install -D -m755 $startdir/src/${pkgname}.profile
$startdir/pkg/etc/profile.d/${pkgname}.sh

  # no plugin for x86_64
  if [ "$CARCH" == "i686" ]; then
    mkdir -p $startdir/pkg/opt/mozilla/lib/plugins
    ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so
$startdir/pkg/opt/mozilla/lib/plugins
    else echo "no plugin for x86_64"
  fi
}


Something to improve?

AndyRTR



From jason at archlinux.org  Sat Mar 11 17:40:05 2006
From: jason at archlinux.org (Jason Chu)
Date: Sat, 11 Mar 2006 17:40:05 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <441334F5.50708@arcor.de>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44127DF7.90705@arcor.de>
	<20060311084237.GG2402@mercury.xentac.net>
	<441334F5.50708@arcor.de>
Message-ID: <20060311224005.GI2402@mercury.xentac.net>

On Sat, Mar 11, 2006 at 09:37:09PM +0100, Andreas Radke wrote:
> Jason Chu schrieb:
> > If there is that large of a discrepency (like j2re, from what I
> > understand), it will be a whole different package: j2re-amd64.
> >
> > If there are just patches and things like that it will look something like
> > this:
> > source=('sources' 'that' 'are' 'common')
> > [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
> >
> > Jason
> >
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > arch-ports mailing list
> > arch-ports at archlinux.org
> > http://www.archlinux.org/mailman/listinfo/arch-ports
> >   
> Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg
> downloading the large 32bit source. But only therefor a different package?
> 
> # $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $
> # Contributed by: Jason Chu <jason at archlinux.org>
> # This PKGBUILD was built largely from code in Crux Linux, then modified
> a bunch to make it j2re
> # Maintainer: Jason Chu <jason at archlinux.org>
> # Contributions by Dusty
> 
> pkgname=j2re
> pkgver=1.5.0_06
> pkgrel=3
> pkgdesc="Sun's java runtime environment"
> url="http://java.sun.com"
> depends=('gcc' 'glibc')
> install="j2re.install"

Rather than these lines,

> #source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04-linux-i586.bin
> j2re.profile jre.patch)
> #source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin
> j2re.profile jre.patch)
> [ "$CARCH" == "x86_64" ] &&
> source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin
> j2re.profile jre.patch)
> md5sums=('e0a88dbec9bfe3195794bb652bfc6516'
> '87d90b2e075b77c41a7efec7411a4153'\
>          '3b589fa777fab553d4f7ce57bc90ce48')
> [ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b'
> '87d90b2e075b77c41a7efec7411a4153'\
>          '91544f3d5d5aa054db7ce2144d17138b')

I would probably do it like this:

source=(j2re.profile jre.patch)
md5sums=('87d90b2e075b77c41a7efec7411a4153' '3b589fa777fab553d4f7ce57bc90ce48')
[ "$CARCH" = "i686" ] && source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04-linux-i586.bin ${source[@]})
[ "$CARCH" = "i686" ] && md5sums=('e0a88dbec9bfe3195794bb652bfc6516' ${md5sums[@]})
[ "$CARCH" = "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin ${source[@]})
[ "$CARCH" = "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' ${md5sums[@]})

And considering below, how you continually repeat
jre-1_5_0_06-linux-i586.bin and jre-1_5_0_06-linux-amd64.bin, I would
suggest a variable at the top called _binname, set like this:

[ "$CARCH" = "i686" ] && _binname='jre-1_5_0_04-linux-i586.bin'
[ "$CARCH" = "x86_64" ] && _binname='jre-1_5_0_06-linux-amd64.bin'

And then every time you have a [ "$CARCH" = "i686" ] && line where the only
difference is the filename, replace it like this:

> build() {
>     cd $startdir/src
>     [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin
> <jre.patch
>     [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin
> <jre.patch

patch -p0 $_binname <jre.patch

>   mkdir -p $startdir/pkg/opt/java
>   cd $startdir/pkg/opt/java
>   [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh
> $startdir/src/jre-1_5_0_06-linux-i586.bin
>   [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh
> $startdir/src/jre-1_5_0_06-linux-amd64.bin

echo -e "q\nyes" | sh $startdir/src/$_binname

>   mv jre${pkgver} jre
>   rm -r jre/man/ja*
>   for i in jre/*; do
>     if [ -f $i ]; then rm -f $i; fi
>   done
>   install -D -m755 $startdir/src/${pkgname}.profile
> $startdir/pkg/etc/profile.d/${pkgname}.sh
> 
>   # no plugin for x86_64
>   if [ "$CARCH" == "i686" ]; then
>     mkdir -p $startdir/pkg/opt/mozilla/lib/plugins
>     ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so
> $startdir/pkg/opt/mozilla/lib/plugins
>     else echo "no plugin for x86_64"

What is this else doing here?  The only person who will see that is the
builder and I don't know that they would care...

>   fi
> }
> 
> 
> Something to improve?
> 
> AndyRTR

You can also replace the filenames in the new source lines I gave with
$_binname, if you wanted to.

How's that for improvement?

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060311/5eaec4c8/attachment.pgp>

From buchuki at gmail.com  Sat Mar 11 17:30:51 2006
From: buchuki at gmail.com (Dusty Phillips)
Date: Sat, 11 Mar 2006 17:30:51 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <20060311224005.GI2402@mercury.xentac.net>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44127DF7.90705@arcor.de> <20060311084237.GG2402@mercury.xentac.net>
	<441334F5.50708@arcor.de> <20060311224005.GI2402@mercury.xentac.net>
Message-ID: <7ecb79cc0603111430x2c99035ex74fa6a6dfcc659b@mail.gmail.com>

These builds are starting to look very un-KISS. Approximately what
percentage of PKGBUILDs are going to require architecture-specific
code like this? Perhaps it would be better to store multiple versions
of the PKGBUILD after all --ie: PKGBUILD-i686 PKGBUILD-x86_64 in the
abs directory. This would be a pain when updating duplicate code in
each PKGBUILD, but the overall look per PKGBUILD would be far more
elegant. It depends how often there is going to be a problem.

Perhaps its just ugly bash syntax and we should think about doing
PKGBUILDs in Python. Yeah, I wish too.

Dusty

On 3/11/06, Jason Chu <jason at archlinux.org> wrote:
> On Sat, Mar 11, 2006 at 09:37:09PM +0100, Andreas Radke wrote:
> > Jason Chu schrieb:
> > > If there is that large of a discrepency (like j2re, from what I
> > > understand), it will be a whole different package: j2re-amd64.
> > >
> > > If there are just patches and things like that it will look something like
> > > this:
> > > source=('sources' 'that' 'are' 'common')
> > > [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
> > >
> > > Jason
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > arch-ports mailing list
> > > arch-ports at archlinux.org
> > > http://www.archlinux.org/mailman/listinfo/arch-ports
> > >
> > Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg
> > downloading the large 32bit source. But only therefor a different package?
> >
> > # $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $
> > # Contributed by: Jason Chu <jason at archlinux.org>
> > # This PKGBUILD was built largely from code in Crux Linux, then modified
> > a bunch to make it j2re
> > # Maintainer: Jason Chu <jason at archlinux.org>
> > # Contributions by Dusty
> >
> > pkgname=j2re
> > pkgver=1.5.0_06
> > pkgrel=3
> > pkgdesc="Sun's java runtime environment"
> > url="http://java.sun.com"
> > depends=('gcc' 'glibc')
> > install="j2re.install"
>
> Rather than these lines,
>
> > #source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04-linux-i586.bin
> > j2re.profile jre.patch)
> > #source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin
> > j2re.profile jre.patch)
> > [ "$CARCH" == "x86_64" ] &&
> > source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin
> > j2re.profile jre.patch)
> > md5sums=('e0a88dbec9bfe3195794bb652bfc6516'
> > '87d90b2e075b77c41a7efec7411a4153'\
> >          '3b589fa777fab553d4f7ce57bc90ce48')
> > [ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b'
> > '87d90b2e075b77c41a7efec7411a4153'\
> >          '91544f3d5d5aa054db7ce2144d17138b')
>
> I would probably do it like this:
>
> source=(j2re.profile jre.patch)
> md5sums=('87d90b2e075b77c41a7efec7411a4153' '3b589fa777fab553d4f7ce57bc90ce48')
> [ "$CARCH" = "i686" ] && source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04-linux-i586.bin ${source[@]})
> [ "$CARCH" = "i686" ] && md5sums=('e0a88dbec9bfe3195794bb652bfc6516' ${md5sums[@]})
> [ "$CARCH" = "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin ${source[@]})
> [ "$CARCH" = "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' ${md5sums[@]})
>
> And considering below, how you continually repeat
> jre-1_5_0_06-linux-i586.bin and jre-1_5_0_06-linux-amd64.bin, I would
> suggest a variable at the top called _binname, set like this:
>
> [ "$CARCH" = "i686" ] && _binname='jre-1_5_0_04-linux-i586.bin'
> [ "$CARCH" = "x86_64" ] && _binname='jre-1_5_0_06-linux-amd64.bin'
>
> And then every time you have a [ "$CARCH" = "i686" ] && line where the only
> difference is the filename, replace it like this:
>
> > build() {
> >     cd $startdir/src
> >     [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin
> > <jre.patch
> >     [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin
> > <jre.patch
>
> patch -p0 $_binname <jre.patch
>
> >   mkdir -p $startdir/pkg/opt/java
> >   cd $startdir/pkg/opt/java
> >   [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh
> > $startdir/src/jre-1_5_0_06-linux-i586.bin
> >   [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh
> > $startdir/src/jre-1_5_0_06-linux-amd64.bin
>
> echo -e "q\nyes" | sh $startdir/src/$_binname
>
> >   mv jre${pkgver} jre
> >   rm -r jre/man/ja*
> >   for i in jre/*; do
> >     if [ -f $i ]; then rm -f $i; fi
> >   done
> >   install -D -m755 $startdir/src/${pkgname}.profile
> > $startdir/pkg/etc/profile.d/${pkgname}.sh
> >
> >   # no plugin for x86_64
> >   if [ "$CARCH" == "i686" ]; then
> >     mkdir -p $startdir/pkg/opt/mozilla/lib/plugins
> >     ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so
> > $startdir/pkg/opt/mozilla/lib/plugins
> >     else echo "no plugin for x86_64"
>
> What is this else doing here?  The only person who will see that is the
> builder and I don't know that they would care...
>
> >   fi
> > }
> >
> >
> > Something to improve?
> >
> > AndyRTR
>
> You can also replace the filenames in the new source lines I gave with
> $_binname, if you wanted to.
>
> How's that for improvement?
>
> Jason
>
> --
> If you understand, things are just as they are.  If you do not understand,
> things are just as they are.
>
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>
>
>
>



From jason at archlinux.org  Sat Mar 11 18:53:41 2006
From: jason at archlinux.org (Jason Chu)
Date: Sat, 11 Mar 2006 18:53:41 -0500
Subject: [arch-ports] PKGBUILD and package release thoughts
In-Reply-To: <7ecb79cc0603111430x2c99035ex74fa6a6dfcc659b@mail.gmail.com>
References: <20060310234654.GB2402@mercury.xentac.net>
	<44127DF7.90705@arcor.de>
	<20060311084237.GG2402@mercury.xentac.net>
	<441334F5.50708@arcor.de>
	<20060311224005.GI2402@mercury.xentac.net>
	<7ecb79cc0603111430x2c99035ex74fa6a6dfcc659b@mail.gmail.com>
Message-ID: <20060311235341.GJ2402@mercury.xentac.net>

On Sat, Mar 11, 2006 at 05:30:51PM -0500, Dusty Phillips wrote:
> These builds are starting to look very un-KISS. Approximately what
> percentage of PKGBUILDs are going to require architecture-specific
> code like this? Perhaps it would be better to store multiple versions
> of the PKGBUILD after all --ie: PKGBUILD-i686 PKGBUILD-x86_64 in the
> abs directory. This would be a pain when updating duplicate code in
> each PKGBUILD, but the overall look per PKGBUILD would be far more
> elegant. It depends how often there is going to be a problem.

No PKGBUILD needs these things.  It's only if you want them to support
multiple architectures.  If we're going to have seperate PKGBUILDs, then
we're really just maintaining multiple distros.  We might as well just keep
Arch i686 and all migrate to Arch64 when i686s become scarce.

> Perhaps its just ugly bash syntax and we should think about doing
> PKGBUILDs in Python. Yeah, I wish too.

I don't know if it'd make them any cleaner.  You would need to describe all
the same commands and check for architecture changes there too.

> Dusty

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060311/37325908/attachment.pgp>

From michael.krauss at gmx.de  Fri Mar 17 15:37:45 2006
From: michael.krauss at gmx.de (Michael Krauss)
Date: Fri, 17 Mar 2006 21:37:45 +0100
Subject: [arch-ports] Arch64 installation and xfce4 icons
Message-ID: <20060317213745.3bb4b599@gandalf.gondor>

Hi to all,

hopefully this is the right mailing list for problems and
annotations on arch64, if not, you can put me into your kill file.


Installation:
-------------

When I have installed Arch64 on my AMD64, I had some prolbems:

1. I tried to install with the arch64 7.1 Beta 6 CD.
   Partitioning worked well and the packages had been installed,
   but I was naot able to boot, because the was no initrd26.img
   just a diag1.img that didn't work.

2. Then I tried the arch64 7.0 CD, but this didn't work either.
   Unfortunately there is no wget at the CD, so one can't use
   it to install by hand.

3. Now I used a gentoo Live CD, which has wget on board, and did
   the installation following:
    	 http://wiki.archlinux.org/index.php/Arch64_Install_page
   Beside of some inconsistent paths the installation worked very
   well, until the pacman.static command.
   I don't know, what is ment with "I've only mentioned base
   packages", but pacman want to install quite many packages.
   Is abiword a base package?
   Some packages like tin and wvstreams have unsolved
   dependencies, while others exclude each other, like

   pcmcia-cs <---> pcmciautils,
   udev <---> hotplug,
   xf86...unicrome <---> xf86...via,
   font...ethiopic <---> font...meltho.

   After deleting the packages on the right side, pacman was able
   to install the rest.

   The rest of the installation worked well and arch boots to
   console login.

   
XFCE4 icons:
------------

After installing xfce4, include /opt/xfce4/bin in $PATH and 
put 'exec startxfce4' into .xinitrc, xfce4 works fine. But
there are no icons in the panel. The buttons are there and work,
but they are grey like the background. The same problem in firefox
and epiphany. At the login console I get the following message 
many times:

GdkPixbuf-WARNING **: cannot open pixbuf loader module file
'/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory

Maybe this is a bug, but I can't write a bug report to flyspray

http://www.arch64.org/bugs/

so I dropped it here. Maybe that's the reason, why it's still empty
;-) I hope, not wasted too much of your time.


<put a closing here, when i find one>
Michael Krauss

   
	



From a.radke at arcor.de  Sat Mar 18 03:10:26 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 18 Mar 2006 09:10:26 +0100
Subject: [arch-ports] Arch64 installation and xfce4 icons
In-Reply-To: <20060317213745.3bb4b599@gandalf.gondor>
References: <20060317213745.3bb4b599@gandalf.gondor>
Message-ID: <441BC072.4040907@arcor.de>

Michael Krauss schrieb:
>  XFCE4 icons:
> ------------
>
> After installing xfce4, include /opt/xfce4/bin in $PATH and 
> put 'exec startxfce4' into .xinitrc, xfce4 works fine. But
> there are no icons in the panel. The buttons are there and work,
> but they are grey like the background. The same problem in firefox
> and epiphany. At the login console I get the following message 
> many times:
>
> GdkPixbuf-WARNING **: cannot open pixbuf loader module file
> '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory
>
> Maybe this is a bug, but I can't write a bug report to flyspray
>
> http://www.arch64.org/bugs/
>
> so I dropped it here. Maybe that's the reason, why it's still empty
> ;-) I hope, not wasted too much of your time.
>
>
> <put a closing here, when i find one>
> Michael Krauss
>
>    
> 	
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>
>   

When I'm right the file is beeing created while installit the gtk2 package.

So try to pacman -Sy gtk2 again and watch the output. On my system the
file has a timestamp from my last update gtk2 2.8.11 -> 2.8.12.

AndyRTR



From michael.krauss at gmx.de  Sat Mar 18 07:26:58 2006
From: michael.krauss at gmx.de (Michael Krauss)
Date: Sat, 18 Mar 2006 13:26:58 +0100
Subject: [arch-ports] Fw:  Arch64 installation and xfce4 icons
Message-ID: <20060318132658.6b786d72@gandalf.gondor>

On Sat, 18 Mar 2006 Andreas Radke <a.radke at arcor.de> wrote:
> Michael Krauss schrieb:
> >  XFCE4 icons:
> > ------------
> >
> > After installing xfce4, include /opt/xfce4/bin in $PATH and 
> > put 'exec startxfce4' into .xinitrc, xfce4 works fine. But
> > there are no icons in the panel. The buttons are there and work,
> > but they are grey like the background. The same problem in firefox
> > and epiphany. At the login console I get the following message 
> > many times:
> >
> > GdkPixbuf-WARNING **: cannot open pixbuf loader module file
> > '/etc/gtk-2.0/gdk-pixbuf.loaders': No such file or directory
> 
> When I'm right the file is beeing created while installit the gtk2 package.
> 
> So try to pacman -Sy gtk2 again and watch the output. On my system the
> file has a timestamp from my last update gtk2 2.8.11 -> 2.8.12.

Happily you are right.

Although pacman says, that the version of gtk2, gtk2-2.8.12-1, is
up to date, the problem disappeared after reinstalling :-)


Michael Krauss




From jason at archlinux.org  Mon Mar 20 18:47:48 2006
From: jason at archlinux.org (Jason Chu)
Date: Mon, 20 Mar 2006 18:47:48 -0500
Subject: [arch-ports] What's needed for an official port
Message-ID: <20060320234748.GB10848@mercury.xentac.net>

I've been asked a couple of times about what the port people can do to make
their ports official.  What I'm trying to do here is list all of the things
that must be done before we can have our first official port.

A few things need to happen on the Arch Linux developer side:
- makepkg needs support for arch=()
- the db-* scripts need to be updated for multiple architectures
- we need more CVS tags*
- the pkgrel-<arch> changes need to be implemented in makepkg and gensync**

A few things need to happen on the port side as well:
- a good number of packages that can be easily integrated into the official
PKGBUILDs (which means changes are marked).  I'd even go so far as to say
that most packages have to be rebuilt against the merged PKGBUILDs.
- a working install cd
- pacbuild nodes***

Is there anything I've missed?

Jason

*: We don't need to make them, just figure out what they will be
**: Should this one be in there?  Strictly speaking, it's not necessary,
but it would really help cut down on unnecessary updates for other arches
***: Also not strictly necessary, but I think it'd help for non-x86_64
developers to try building their changes on x86_64.

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060320/074da635/attachment.pgp>

From a.radke at arcor.de  Mon Mar 20 23:47:13 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Tue, 21 Mar 2006 05:47:13 +0100
Subject: [arch-ports] What's needed for an official port
In-Reply-To: <20060320234748.GB10848@mercury.xentac.net>
References: <20060320234748.GB10848@mercury.xentac.net>
Message-ID: <441F8551.7020902@arcor.de>

Jason Chu schrieb:
> I've been asked a couple of times about what the port people can do to make
> their ports official.  What I'm trying to do here is list all of the things
> that must be done before we can have our first official port.
>
> A few things need to happen on the Arch Linux developer side:
> - makepkg needs support for arch=()
> - the db-* scripts need to be updated for multiple architectures
> - we need more CVS tags*
> - the pkgrel-<arch> changes need to be implemented in makepkg and gensync**
>
> A few things need to happen on the port side as well:
> - a good number of packages that can be easily integrated into the official
> PKGBUILDs (which means changes are marked).  I'd even go so far as to say
> that most packages have to be rebuilt against the merged PKGBUILDs.
> - a working install cd
> - pacbuild nodes***
>
> Is there anything I've missed?
>
> Jason
>
> *: We don't need to make them, just figure out what they will be
> **: Should this one be in there?  Strictly speaking, it's not necessary,
> but it would really help cut down on unnecessary updates for other arches
> ***: Also not strictly necessary, but I think it'd help for non-x86_64
> developers to try building their changes on x86_64.
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>   
What about the cvs/svn/darcs question? Arch64 now uses svn and we only
have the cvs package, not cvsup. But we have csup, a cvsup replacemnt:
http://www.mu.org/~mux/csup.html

Maybe someone can summarize all pros and cons for the various options.

Andy



From jason at archlinux.org  Tue Mar 21 02:15:19 2006
From: jason at archlinux.org (Jason Chu)
Date: Tue, 21 Mar 2006 02:15:19 -0500
Subject: [arch-ports] What's needed for an official port
In-Reply-To: <441F8551.7020902@arcor.de>
References: <20060320234748.GB10848@mercury.xentac.net>
	<441F8551.7020902@arcor.de>
Message-ID: <20060321071519.GC28297@mercury.xentac.net>

On Tue, Mar 21, 2006 at 05:47:13AM +0100, Andreas Radke wrote:
> Jason Chu schrieb:
> > I've been asked a couple of times about what the port people can do to make
> > their ports official.  What I'm trying to do here is list all of the things
> > that must be done before we can have our first official port.
> >
> > A few things need to happen on the Arch Linux developer side:
> > - makepkg needs support for arch=()
> > - the db-* scripts need to be updated for multiple architectures
> > - we need more CVS tags*
> > - the pkgrel-<arch> changes need to be implemented in makepkg and gensync**
> >
> > A few things need to happen on the port side as well:
> > - a good number of packages that can be easily integrated into the official
> > PKGBUILDs (which means changes are marked).  I'd even go so far as to say
> > that most packages have to be rebuilt against the merged PKGBUILDs.
> > - a working install cd
> > - pacbuild nodes***
> >
> > Is there anything I've missed?
> >
> > Jason
> >
> > *: We don't need to make them, just figure out what they will be
> > **: Should this one be in there?  Strictly speaking, it's not necessary,
> > but it would really help cut down on unnecessary updates for other arches
> > ***: Also not strictly necessary, but I think it'd help for non-x86_64
> > developers to try building their changes on x86_64.
> >
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > arch-ports mailing list
> > arch-ports at archlinux.org
> > http://www.archlinux.org/mailman/listinfo/arch-ports
> >   
> What about the cvs/svn/darcs question? Arch64 now uses svn and we only
> have the cvs package, not cvsup. But we have csup, a cvsup replacemnt:
> http://www.mu.org/~mux/csup.html
> 
> Maybe someone can summarize all pros and cons for the various options.
> 
> Andy

At this point, the least number of things changing means not changing
version control.

Csup is (from what I understand) a fine replacement for cvsup.  What will
probably happen then is that i686 will stick with cvsup and x86_64 will use
csup.  The error message will be updated to display the proper name for
each in the abs script.

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060321/260942b9/attachment.pgp>

From moritz.esser at gmx.de  Tue Mar 21 11:38:32 2006
From: moritz.esser at gmx.de (Moritz Alexander Esser)
Date: Tue, 21 Mar 2006 17:38:32 +0100
Subject: [arch-ports] What's needed for an official port
In-Reply-To: <20060320234748.GB10848@mercury.xentac.net>
References: <20060320234748.GB10848@mercury.xentac.net>
Message-ID: <44202C08.6040503@gmx.de>

Jason Chu wrote:
> - a working install cd

I developed a script which creates a complete install cd with just a few 
commands. It's still under heavy development! Andreas built our 0.7.1 
beta7 and rc1 install cd with it and they are working quit good (some 
bugs are left)
I have some thoughts to give the script multi-arch support, so ppc and 
i686 may use it as well!

Regards,
Moritz



From jason at archlinux.org  Tue Mar 21 15:09:57 2006
From: jason at archlinux.org (Jason Chu)
Date: Tue, 21 Mar 2006 15:09:57 -0500
Subject: [arch-ports] What's needed for an official port
In-Reply-To: <44202C08.6040503@gmx.de>
References: <20060320234748.GB10848@mercury.xentac.net>
	<44202C08.6040503@gmx.de>
Message-ID: <20060321200957.GE28297@mercury.xentac.net>

On Tue, Mar 21, 2006 at 05:38:32PM +0100, Moritz Alexander Esser wrote:
> Jason Chu wrote:
> > - a working install cd
> 
> I developed a script which creates a complete install cd with just a few 
> commands. It's still under heavy development! Andreas built our 0.7.1 
> beta7 and rc1 install cd with it and they are working quit good (some 
> bugs are left)
> I have some thoughts to give the script multi-arch support, so ppc and 
> i686 may use it as well!
> 
> Regards,
> Moritz

I'd say make it available.  As you may have sen in the last newsletter,
we're looking into making the archie scripts official and we could use
those to generate x86_64 install cds as well.

Jason

-- 
If you understand, things are just as they are.  If you do not understand,
things are just as they are.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060321/0b5f5e00/attachment.pgp>

From a.radke at arcor.de  Sun Mar 26 14:42:13 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Sun, 26 Mar 2006 21:42:13 +0200
Subject: [arch-ports] What's needed for an official port
In-Reply-To: <20060320234748.GB10848@mercury.xentac.net>
References: <20060320234748.GB10848@mercury.xentac.net>
Message-ID: <4426EE95.1000608@arcor.de>

Jason Chu schrieb:
> A few things need to happen on the port side as well:
> - a good number of packages that can be easily integrated into the official
> PKGBUILDs (which means changes are marked).  I'd even go so far as to say
> that most packages have to be rebuilt against the merged PKGBUILDs.
> - a working install cd
> - pacbuild nodes***
>   

I think we - the arch64 devs- have done what we could do. Our CD is
working and almost in a final state.

We're still waiting for results on the arch32 devs site. My arch64 devs
are bored making updates knowing that a day will come all packages have
to be rebuild. A few have already left the project :(

I've done a few packages using the tags needed for merging "if [
$CARCH..." - no problem with that so far. But as we know we will have to
rebuild every pkg this work is now just a waste of time.

What's is the state with makepkg and cvs? Any concrete time schedule?


AndyRTR



From a.radke at arcor.de  Thu Mar 30 15:36:22 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Thu, 30 Mar 2006 22:36:22 +0200
Subject: [arch-ports] developing the (arch64) port
Message-ID: <442C4146.9060201@arcor.de>

On the port side:

- All arch64 developers should read this:
http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/
"Applying |-fPIC| on all objects will slow down the binaries in a
drastic way."
So I will drop it again from the default CFLAGS. A new pacman package is
needed. I'll do this later when we are sure how the future development
will be.

- So we need to review all packages for sorting out packages that will
build *.so files. That's how I understand the Gentoo rule. Am I right?
We can use a script crawling through /* for *.so | pacman -Qo to get the
packages we need to patch with CFLAGS="$CFLAGS -fPIC" ??? Who can do
this first? Then check the result against Gentoo and Fedora.

- Then a recompile of the whole distro will be needed. makeworld will be
my friend :)

I hope this will solve our last problems with the iso(mkfs.ext3, lilo, grub)



What I expect from the official archlinux developers side:

- Jason, I've come to the conclusion that a common cvs and common
pkgbuilds are not good for getting the ports accepted. It would take us
a long time until i686 developers will accept bloated pkgbuilds and
preparing the "arch" tag would take its time. I still don't know why we
should need the "arch" tag. I think it would be only to declare if the
pkgbuild builds on a certain architecture. But as long as the packages
are build by a packager and not automatically we don't really need it.

- I disagree to your opinion that i686 packagers will ever be able to
build packages for the ports using pacbuild. Every package needs a check
and real installation on the destination architecture before you can
upload it to the repos. So you always will need to have a few packagers
more for each port to check packages and play with bugfixes.

- So I would prefer a separate svn/cvs for each port. Every port should
be free to decide what packages to include into the port. This may not
be as elegant as common cvs+pkgbuild but it's much easier to handle.

- No changes would be need to pacman/makepkg. Less work and less
learning for all - more KISS for everyone. And it will not take more
space on the servers or something like that.


So setup a separate svn for arch64 and create new subrepos for x86_64
and give a few of us access - we could start tomorrow!
I know some arch64 devs dying to do real productiv stuff.

Otherwise as I told you more packagers will leave the port.

AndyRTR



From jason at archlinux.org  Thu Mar 30 16:26:54 2006
From: jason at archlinux.org (Jason Chu)
Date: Thu, 30 Mar 2006 13:26:54 -0800
Subject: [arch-ports] developing the (arch64) port
In-Reply-To: <442C4146.9060201@arcor.de>
References: <442C4146.9060201@arcor.de>
Message-ID: <20060330132654.066aa86b@aries>

> What I expect from the official archlinux developers side:
> 
> - Jason, I've come to the conclusion that a common cvs and common
> pkgbuilds are not good for getting the ports accepted. It would take
> us a long time until i686 developers will accept bloated pkgbuilds and
> preparing the "arch" tag would take its time. I still don't know why
> we should need the "arch" tag. I think it would be only to declare if
> the pkgbuild builds on a certain architecture. But as long as the
> packages are build by a packager and not automatically we don't
> really need it.

How many developers have complained about "bloated" pkgbuilds so far?

> - I disagree to your opinion that i686 packagers will ever be able to
> build packages for the ports using pacbuild. Every package needs a
> check and real installation on the destination architecture before
> you can upload it to the repos. So you always will need to have a few
> packagers more for each port to check packages and play with bugfixes.

Every package does need to be checked, but every package does not need
to be submitted by an x86_64 person.  You will always need packagers for
a specific port, but I think the i686 people can help out as well.

> - So I would prefer a separate svn/cvs for each port. Every port
> should be free to decide what packages to include into the port. This
> may not be as elegant as common cvs+pkgbuild but it's much easier to
> handle.

Easier to handle in the short run, sure.

> - No changes would be need to pacman/makepkg. Less work and less
> learning for all - more KISS for everyone. And it will not take more
> space on the servers or something like that.
> 
> 
> So setup a separate svn for arch64 and create new subrepos for x86_64
> and give a few of us access - we could start tomorrow!
> I know some arch64 devs dying to do real productiv stuff.
> 
> Otherwise as I told you more packagers will leave the port.
> 
> AndyRTR

Other developer's thoughts?

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060330/eeee9a53/attachment.pgp>

From me at camdaniel.com  Fri Mar 31 13:16:07 2006
From: me at camdaniel.com (Cam Daniel)
Date: Fri, 31 Mar 2006 18:16:07 +0000
Subject: [arch-ports] developing the (arch64) port
In-Reply-To: <442C4146.9060201@arcor.de>
References: <442C4146.9060201@arcor.de>
Message-ID: <442D71E7.9050702@camdaniel.com>

Andreas Radke wrote:
> On the port side:
> 
> - All arch64 developers should read this:
> http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/
> "Applying |-fPIC| on all objects will slow down the binaries in a
> drastic way."
> So I will drop it again from the default CFLAGS. A new pacman package is
> needed. I'll do this later when we are sure how the future development
> will be.
> 
> - So we need to review all packages for sorting out packages that will
> build *.so files. That's how I understand the Gentoo rule. Am I right?
> We can use a script crawling through /* for *.so | pacman -Qo to get the
> packages we need to patch with CFLAGS="$CFLAGS -fPIC" ??? Who can do
> this first? Then check the result against Gentoo and Fedora.
> 
> - Then a recompile of the whole distro will be needed. makeworld will be
> my friend :)
> 
> I hope this will solve our last problems with the iso(mkfs.ext3, lilo, grub)

I read that as meaning -fPIC should be applied to shared object _only_. 
This would involve patching the configure scripts and not just simply 
adding -fPIC to the entire package. Someone else want to weigh in with 
an interpretation on this? I took a look at some ebuilds from Gentoo and 
they seem to use patches for apps that require this which we could 
easily use.

> What I expect from the official archlinux developers side:
> 
> - Jason, I've come to the conclusion that a common cvs and common
> pkgbuilds are not good for getting the ports accepted. It would take us
> a long time until i686 developers will accept bloated pkgbuilds and
> preparing the "arch" tag would take its time. I still don't know why we
> should need the "arch" tag. I think it would be only to declare if the
> pkgbuild builds on a certain architecture. But as long as the packages
> are build by a packager and not automatically we don't really need it.
> 
> - I disagree to your opinion that i686 packagers will ever be able to
> build packages for the ports using pacbuild. Every package needs a check
> and real installation on the destination architecture before you can
> upload it to the repos. So you always will need to have a few packagers
> more for each port to check packages and play with bugfixes.
> 
> - So I would prefer a separate svn/cvs for each port. Every port should
> be free to decide what packages to include into the port. This may not
> be as elegant as common cvs+pkgbuild but it's much easier to handle.
> 
> - No changes would be need to pacman/makepkg. Less work and less
> learning for all - more KISS for everyone. And it will not take more
> space on the servers or something like that.

Seperating the CVS/SVN repo is a touchy subject, to keep things globally 
in sync it would be so much easier to keep them together. To be honest 
I've done all my building from the Arch32 ABS tree because that way I 
know I'm building up to date packages. Splitting the repo means we're 
completely seperating the package tree however it allows us the freedom 
to apply fixes at our own pace. It also means that for packages that 
don't require any changes, we still have to update version numbers and 
monitor the Arch32 bug tracker to keep up with releases.

Using a unified CVS repo with arch tags seems to make sense to me at the 
moment but I haven't been following this ML until yesterday so feel free 
to ignore the newbie :-)

- Cameron



From ganja.guru at airtelbroadband.in  Fri Mar 31 05:36:22 2006
From: ganja.guru at airtelbroadband.in (ganja.guru)
Date: Fri, 31 Mar 2006 16:06:22 +0530
Subject: [arch-ports] developing the (arch64) port
In-Reply-To: <20060330132654.066aa86b@aries>
References: <442C4146.9060201@arcor.de> <20060330132654.066aa86b@aries>
Message-ID: <442D0626.4010302@airtelbroadband.in>

>
>> What I expect from the official archlinux developers side:
>>
>> - Jason, I've come to the conclusion that a common cvs and common
>> pkgbuilds are not good for getting the ports accepted. It would take
>> us a long time until i686 developers will accept bloated pkgbuilds and
>> preparing the "arch" tag would take its time. I still don't know why
>> we should need the "arch" tag. I think it would be only to declare if
>> the pkgbuild builds on a certain architecture. But as long as the
>> packages are build by a packager and not automatically we don't
>> really need it.
>>     
>
>   

> I personally don't see a big problem with the so called "bloated" 
> PKGBUILD's. Most PKGBUILDs will be clean cause they compile on arch64 
> without any changes anyway, and a few PKGBUILDS with a few extra lines 
> here and there shouldn't bother anyone, I think.

>> - So I would prefer a separate svn/cvs for each port. Every port
>> should be free to decide what packages to include into the port. This
>> may not be as elegant as common cvs+pkgbuild but it's much easier to
>> handle.
>>     
>
>   
I think having a separate svn/cvs for the ports is too tedious as we 
have to keep going back and forth when checking out PKGBUILD's for those 
difficult packages. Integrating everything into a single cvs should save 
a lot of time.


Varun "ganja_guru" Acharya
> _______________________________________________
> arch-ports mailing list
> arch-ports at archlinux.org
> http://www.archlinux.org/mailman/listinfo/arch-ports
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/arch-ports/attachments/20060331/547d7e0d/attachment.htm>

From a.radke at arcor.de  Fri Mar 31 09:26:45 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Fri, 31 Mar 2006 16:26:45 +0200
Subject: [arch-ports] developing the (arch64) port
In-Reply-To: <20060330132654.066aa86b@aries>
References: <442C4146.9060201@arcor.de> <20060330132654.066aa86b@aries>
Message-ID: <442D3C25.4030809@arcor.de>

I'm not stricly against a common cvs tree although it restricts us to be
"only" a port without any freedom. It's ok.

But then I ask all the involved devs to hurry up setting up all that is
needed so we can start as quickly as possible.

AndyRTR



From a.radke at arcor.de  Fri Mar 31 11:00:25 2006
From: a.radke at arcor.de (Andreas Radke)
Date: Fri, 31 Mar 2006 18:00:25 +0200
Subject: [arch-ports] [arch64] fPIC affected packages
Message-ID: <442D5219.4030504@arcor.de>

Thanks to Notz - this is the list with fPIC affected packages:

PDL-2.4.2.ebuild:2
PerlQt-3.008-r1.ebuild:1
allegro-4.2.0.ebuild:1
alltray-0.60.ebuild:1
arj-3.10.18.ebuild:1
asis-3.44.ebuild:1
asterisk-1.0.8-r2.ebuild:1
asterisk-addons-1.2.0.ebuild:1
attal-0.9.3.ebuild:1
audacity-1.2.4b-r1.ebuild:1
bestcrypt-1.6_p1-r2.ebuild:2
biew-5.6.1.ebuild:1
bitchx-1.1-r1.ebuild:4
blas-19980702-r2.ebuild:1
c-client-2004a-r1.ebuild:2
capi4k-utils-20050718-r1.ebuild:2
ccmath-2.2.1.ebuild:1
cdk-4.9.10.20020809-r1.ebuild:1
charm-5.9.ebuild:1
cinelerra-cvs-20060219.ebuild:1
cl-gd-0.4.7.ebuild:1
cl-imho-1.3.2.ebuild:1
cl-tclink-3.3.1-r1.ebuild:1
clearsilver-0.10.1.ebuild:1
clibpdf-202_p1.ebuild:1
cmigemo-1.2.ebuild:1
cryptlib-3.2.2.ebuild:2
ctrlproxy-2.6.ebuild:1
cyrus-imap-admin-2.2.12.ebuild:1
dcetest-2.0.ebuild:1
dirdiff-1.6.ebuild:1
djbfft-0.76.ebuild:1
drscheme-301-r1.ebuild:1
eclipse-sdk-3.0.0-r3.ebuild:1
em8300-libraries-0.15.0.ebuild:1
evolution-2.4.2.ebuild:1
ffcall-1.9.ebuild:1
filelight-1.0_beta6.ebuild:1
florist-3.15p.ebuild:2
freeradius-1.1.0-r1.ebuild:1
freewrl-1.16.1.ebuild:2
fung-calc-1.3.2b.ebuild:1
gaim-latex-0.3.ebuild:1
gaim-otr-1.0.3.ebuild:1
garlic-3.15p-r1.ebuild:2
gcl-2.6.7.ebuild:1
gcl-cvs-2.7.0.ebuild:1
geoip-1.3.14.ebuild:1
ghc-6.4.1-r3.ebuild:1
ghostscript-esp-8.15.1.ebuild:1
gkrellm-hddtemp-0.1.ebuild:1
gkrelltop-2.2.2.ebuild:1
glib-1.2.10-r5.ebuild:3
gmetadom-0.2.2-r1.ebuild:2
gnat-3.15p-r3.ebuild:2
golem-0.0.5-r1.ebuild:2
gpac-0.4.1_pre20060122.ebuild:1
gplflash-0.4.10-r3.ebuild:1
graphlcd-base-0.1.3.ebuild:3
gst-plugins-0.8.9-r2.ebuild:1
gst-plugins-bad-0.10.0.ebuild:1
gst-plugins-base-0.10.0.ebuild:1
gst-plugins-ffmpeg-0.8.7-r1.ebuild:1
gst-plugins-good-0.10.0.ebuild:1
gst-plugins-ugly-0.10.2.ebuild:1
gtkscintilla2-0.1.0.ebuild:2
hdf-4.2.0-r3.ebuild:1
heimdal-0.7.2.ebuild:1
hugs98-2003.11.ebuild:1
icecream-0.6.20040829.ebuild:2
imaging-1.1.4-r1.ebuild:1
ircservices-5.0.53.ebuild:2
jbigkit-1.4.ebuild:2
jusb-0.4.4.ebuild:1
kbear-2.1.1-r1.ebuild:1
kdevelop-3.1.2.ebuild:1
kemistry-0.7.ebuild:1
kgcc-2.95.3.ebuild:1
kickpim-0.5.3.ebuild:1
knob-1.2-r1.ebuild:1
kth-krb-1.2.2-r2.ebuild:1
ladspa-cmt-1.15.ebuild:1
ladspa-sdk-1.12-r2.ebuild:1
lapack-3.0-r1.ebuild:1
lib3ds-1.2.0.ebuild:2
libapreq2-2.04.03.ebuild:1
libcdaudio-0.99.9.ebuild:2
libebml-0.7.3.ebuild:2
libgeotiff-1.2.1-r1.ebuild:1
libgii-0.9.0.ebuild:1
libhash-1.0.3.ebuild:1
libhttpd-persistent-1.3p-r8.ebuild:2
libident-0.22.ebuild:1
libjsw-1.5.5.ebuild:1
libmatroska-0.7.3-r1.ebuild:2
libmemcache-1.2.4.ebuild:1
libmix-2.05.ebuild:1
libmoe-1.5.8-r1.ebuild:1
libmpeg2-0.4.0b.ebuild:1
libmpeg3-1.5.2-r2.ebuild:3
libpcap-0.8.3-r1.ebuild:2
libpcap-ringbuffer-1.0.20041001.ebuild:2
libpcre-6.1.ebuild:1
libperl-5.8.7.ebuild:1
libsamplerate-0.1.1-r1.ebuild:1
libselinux-1.28-r1.ebuild:1
libtermcap-compat-2.0.8-r1.ebuild:1
libtlen-20040912.ebuild:1
libusb-0.1.8.ebuild:1
libvorbis-1.1.2.ebuild:2
live-2004.07.20.ebuild:4
lives-0.9.1.ebuild:1
lua-5.0.2.ebuild:1
lufs-0.9.7-r3.ebuild:1
matrixssl-1.2.4.ebuild:1
mcl-0.53.00.ebuild:1
mesa-6.4.2-r2.ebuild:1
mesa-progs-6.4.2.ebuild:1
misdnuser-0.1_pre20060203.ebuild:1
mjpegtools-1.6.2-r4.ebuild:3
mod_perl-2.0.1-r2.ebuild:1
mod_python-3.1.4-r1.ebuild:1
mplayer-1.0_pre7-r1.ebuild:1
mupen64-0.5.ebuild:2
mupen64-glN64-0.4.1_rc2-r1.ebuild:1
museseq-0.6.2-r1.ebuild:1
mwcollect-3.0.0.ebuild:1
mysql-4.1.14.ebuild:1
mythtv-0.18.1-r1.ebuild:1
ncurses-5.4-r5.ebuild:3
netpbm-10.26.25.ebuild:1
ode-0.5-r4.ebuild:1
openafs-1.2.13-r2.ebuild:1
openh323-1.13.2-r2.ebuild:1
openldap-2.3.18.ebuild:1
openssl-0.9.7e-r2.ebuild:1
p7zip-4.20.ebuild:1
paklib-0.3.ebuild:1
pam-0.78-r3.ebuild:2
pam_krb5-2.2.6.ebuild:1
pam_pwdfile-0.99.ebuild:1
pam_ssh_agent-0.2.ebuild:1
pari-2.1.6.ebuild:3
pciutils-2.1.11-r5.ebuild:2
pd-cyclone-0.1_alpha54.ebuild:1
perl-5.8.7.ebuild:1
pilot-mailsync-0.8.3.ebuild:1
planeshift-0.3.011.ebuild:1
plib-1.6.0.ebuild:1
ppp-2.4.2-r10.ebuild:2
ptabtools-0.3.1-r2.ebuild:1
pump-0.8.21-r7.ebuild:1
pyparted-1.6.9-r1.ebuild:2
python-2.2.3-r6.ebuild:2
qhull-3.1-r1.ebuild:1
reiserfsprogs-3.6.17.ebuild:1
rpm-4.0.4-r5.ebuild:1
rrdtool-1.0.50.ebuild:2
rss-glx-0.8.0-r2.ebuild:1
ser-0.9.0.ebuild:2
sexypsf-0.4.7.ebuild:1
silc-server-1.0-r1.ebuild:1
skey-1.1.5-r4.ebuild:1
snns-4.2-r7.ebuild:1
soapbox-0.3.1.ebuild:1
sourcenav-5.1.1.ebuild:1
speech-tools-1.2.3-r2.ebuild:1
squeak-3.4.1-r1.ebuild:1
staden-1.5.3-r1.ebuild:4
svgalib-1.9.21-r1.ebuild:1
swh-plugins-0.4.14.ebuild:3
syck-0.55.ebuild:1
systray4j-2.4.ebuild:1
szip-1.1-r1.ebuild:1
tclperl-3.1.ebuild:1
tclpython-3.1.ebuild:1
tclx-8.3-r1.ebuild:2
tvbrowser-2.1.ebuild:1
ucl-1.01-r1.ebuild:1
udunits-1.12.3.ebuild:1
util-linux-2.12i-r1.ebuild:1
uw-imap-2004g-r2.ebuild:3
uw-mailutils-2004g.ebuild:1
valgrind-2.2.0-r2.ebuild:1
vimap-2002c-r3.ebuild:3
vlevel-0.5.ebuild:1
vmd-1.8.3.ebuild:2
vnc-4.0-r1.ebuild:1
wvstreams-4.2.2.ebuild:1
wxhaskell-0.9.4.ebuild:1
xchat-systray-2.4.5-r2.ebuild:1
xchatosd-5.19.ebuild:1
xmms-mp3cue-0.94-r1.ebuild:1
xmms-speex-0.9.1.ebuild:1
xsim-0.3.9.4-r3.ebuild:1
zlib-1.2.3.ebuild:3



As you can see we have made a grep for fPIC in Gentoo's ebuilds. This
list should help where to add a (Gentoo) fPIC fix.

AndyRTR