[arch-general] problem compiling for i586 with new makepkg

older
[arch-general] xkeyboard-config...

Karolina Lindqvist

14 Dec 2007 14 Dec '07

11:33 p.m.

There is a problem with compiling with CHOST="i586" with the new pacman/makepkg. It simply refuses with the message: pkgname is not available for the 'i586' architecture. Note that many packages may need a line added to their PKGBUILD such as arch=('i586'). To edit each and every PKGBUILD for each and every package and every update appears like quite a big work. And since I could not find any option to turn that "feature" off, or any hook to SED it in, I just commented it out in makepkg. What was the thought with this? The -w option is also taken away from makepkg. Why? (I found the alternate solution, but still) Karolina

Show replies by date

Aaron Griffin

14 Dec 14 Dec

11:42 p.m.

On Dec 14, 2007 5:33 PM, Karolina Lindqvist wrote:

...

There is a problem with compiling with CHOST="i586" with the new pacman/makepkg.

It simply refuses with the message:

pkgname is not available for the 'i586' architecture. Note that many packages may need a line added to their PKGBUILD such as arch=('i586').

To edit each and every PKGBUILD for each and every package and every update appears like quite a big work. And since I could not find any option to turn that "feature" off, or any hook to SED it in, I just commented it out in makepkg. What was the thought with this?

The official packages are not tested for i586. This means that they will not directly compile without intercession by a user. Why would we put sed hooks in to fix it when you can...just...run...sed yourself? Arch _does_ have the whole "helper scripts are dumb" type philosophy... Why would we provide one command (makepkg) to replace one command (sed)?

...

The -w option is also taken away from makepkg. Why? (I found the alternate solution, but still)

I can't recall what -w did. Regardless, it was removed because Dan and I wanted to remove it. These things are usually covered for a while on the pacman-dev list, and parties with a vested interest in certain things would benefit from joining the discussion there. Perhaps, given valid reasons, we would have kept the option (again, I have no idea what it did).

Karolina Lindqvist

15 Dec 15 Dec

7 a.m.

lördag 15 december 2007 skrev Aaron Griffin:

...

Why would we put sed hooks in to fix it when you can...just...run...sed yourself? Arch _does_ have the whole "helper scripts are dumb" type philosophy... Why would we provide one command (makepkg) to replace one command (sed)?

Well, because I do a "makeworld". I can of course patch, which is simple with archlinux. The problem is just upgrades, when I need to apply the same patches manually again, or the patches disappear. Then of course, I could do a script that goes through the whole abs tree, and inserts "i586" if it is not there. But that makes me wonder what purpose the arch= tag have at all?

...

I can't recall what -w did. Regardless, it was removed because Dan and I wanted to remove it. These things are usually covered for a while on the pacman-dev list, and parties with a vested interest in certain things would benefit from joining the discussion there. Perhaps, given valid reasons, we would have kept the option (again, I have no idea what it did).

-w redirects output to somewhere else than the standard place, i.e. overrides PKGDEST. Now instead I have to comment out PKGDEST=/home/packages in makepkg.conf and remember to always set it before makepkg instead. It also works, but I thought -w was very convenient and used it a lot. I guess I am going to maintain this, for my own usage, for quite a while now, since I have a machine that is going to run it. It appears that a few others also quietly maintain archi586 the same way. Karolina

R. Dale Thomas

7:59 a.m.

Karolina Lindqvist wrote: [snip]

...

-w redirects output to somewhere else than the standard place, i.e. overrides PKGDEST. Now instead I have to comment out PKGDEST=/home/packages in makepkg.conf and remember to always set it before makepkg instead. It also works, but I thought -w was very convenient and used it a lot.

I guess I am going to maintain this, for my own usage, for quite a while now, since I have a machine that is going to run it. It appears that a few others also quietly maintain archi586 the same way.

Karolina

I'm with you Karolina, I need to support some VIA machines, too.

Karolina Lindqvist

8:32 a.m.

lördag 15 december 2007 skrev R. Dale Thomas:

...

I'm with you Karolina, I need to support some VIA machines, too.

When I am ready, I will put up a repository of archlinux for VIA i586/C3 that I use, so that others can have it too. My VIA machine is my internet server. I call it i586, although it is not exactly that. i686 is assumed to include the optional instruction cmov, which the VIA C3 does not have. So I will build i586 assuming that it includes the optional mmx and 3dnow, since the VIA has it. Is there anyone who runs a real i586 at all? Karolina

Dan McGee

8:15 a.m.

On Dec 15, 2007 1:00 AM, Karolina Lindqvist wrote:

...

lördag 15 december 2007 skrev Aaron Griffin:

...
Why would we put sed hooks in to fix it when you can...just...run...sed yourself? Arch _does_ have the whole "helper scripts are dumb" type philosophy... Why would we provide one command (makepkg) to replace one command (sed)?

Well, because I do a "makeworld". I can of course patch, which is simple with archlinux. The problem is just upgrades, when I need to apply the same patches manually again, or the patches disappear.

Then of course, I could do a script that goes through the whole abs tree, and inserts "i586" if it is not there. But that makes me wonder what purpose the arch= tag have at all?

The arch= tag indicates that we, as the Arch Linux developers, have successfully built a certain package on the given architecture. Since we do not build for i586, we cannot make this claim and so do not add this architecture to the arch= line. -Dan

Karolina Lindqvist

8:43 a.m.

lördag 15 december 2007 skrev Dan McGee:

...

The arch= tag indicates that we, as the Arch Linux developers, have successfully built a certain package on the given architecture. Since we do not build for i586, we cannot make this claim and so do not add this architecture to the arch= line.

That is allright, but why abort "makepkg" on non-authorized architectures? Better to give a warning that this build is unauthorized, unsupported, or whatever, instead of aborting. To insert the i586 tag, to make the package build, just defeats the purpose as you describe it. Sharing that package might make others believe that it it is authorized by the archlinux developers. Karolina

Massimiliano Brocchini

10:18 a.m.

I agree with Karolina. Karolina I would like to encourage you to put a repository up for VIA C3, I was interested in lowarch http://www.lowarch.org/ and I tested it, but it seems dead/dormant. I would like to have an archlinux version installable on a C3 so If you need help (cpu power for compiling, testing, help with scripting, etc) ask me and I'll see what I can do for you. Massimiliano On 12/15/07, Karolina Lindqvist wrote:

...

lördag 15 december 2007 skrev Dan McGee:

...
The arch= tag indicates that we, as the Arch Linux developers, have successfully built a certain package on the given architecture. Since we do not build for i586, we cannot make this claim and so do not add this architecture to the arch= line.

That is allright, but why abort "makepkg" on non-authorized architectures? Better to give a warning that this build is unauthorized, unsupported, or whatever, instead of aborting. To insert the i586 tag, to make the package build, just defeats the purpose as you describe it. Sharing that package might make others believe that it it is authorized by the archlinux developers.

Karolina

Karolina Lindqvist

2:09 p.m.

lördag 15 december 2007 skrev Massimiliano Brocchini:

...

I agree with Karolina. Karolina I would like to encourage you to put a repository up for VIA C3, I was interested in lowarch http://www.lowarch.org/ and I tested it, but it seems dead/dormant. I would like to have an archlinux version installable on a C3 so If you need help (cpu power for compiling, testing, help with scripting, etc) ask me and I'll see what I can do for you.

Massimiliano

It is coming. Maybe I have it all up and running in a week or two. I am cross-compiling on a faster machine, through nfs and chroot, otherwise it would take ages to compile native. I am not sure everything will work like that, but it ought to. When plain archlinux is working, it is time to decide if something special for the C3 is needed? It is a low-end processor, after all, and some things you just don't want to run on it. I will probably exclude a lot from "extra" unless I get a good reason not to do it. Karolina

Travis Willard

2:43 p.m.

Just a hint, since you were looking to add i586 - find and sed are your friends. :D find -name PKGBUILD -exec sed -i '/^arch=/ { /i586/ !{ s/^arch=(/arch=(i586 / } }' {} \; That will find every PKGBUILD and add i586 to the packages that don't already have it. Yay!

Karolina Lindqvist

2:59 p.m.

lördag 15 december 2007 skrev Travis Willard:

...

Just a hint, since you were looking to add i586 - find and sed are your friends. :D

find -name PKGBUILD -exec sed -i '/^arch=/ { /i586/ !{ s/^arch=(/arch=(i586 / } }' {} \;

That will find every PKGBUILD and add i586 to the packages that don't already have it. Yay!

Thank you for that one. I am not as good to make such things, and it takes me considerable time for me to make something like that work properly. Karolina

Mister Dobalina

16 Dec 16 Dec

5:52 a.m.

--- Travis Willard wrote:

...

Just a hint, since you were looking to add i586 - find and sed are your friends. :D

find -name PKGBUILD -exec sed -i '/^arch=/ { /i586/ !{ s/^arch=(/arch=(i586 / } }' {} \;

That will find every PKGBUILD and add i586 to the packages that don't already have it. Yay!

No good, many PKGBUILDs have stuff like if [ "$CARCH" = "i686" ]; then << do something >> fi in the build() section, where the something done is usually something you want done in the i586 case too. Better to straight out replace i686 by i586 in the whole PKGBUILD. find /var/abs -name PKGBUILD -exec sed -i -e 's|i686|i586|g' '{}' \; Might also want to do grep -R i686 /var/abs/* just to be sure there are no i686's hiding in .install files. cheers. Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca

Karolina Lindqvist

7:01 a.m.

söndag 16 december 2007 skrev Mister Dobalina:

...

...
That will find every PKGBUILD and add i586 to the packages that don't already have it. Yay!

No good, many PKGBUILDs have stuff like

if [ "$CARCH" = "i686" ]; then << do something >> fi

in the build() section, where the something done is usually something you want done in the i586 case too.

Better to straight out replace i686 by i586 in the whole PKGBUILD. <<<cut>>> Actually, I added i586 when I did it the last time, one year ago, with the result that it was practically hopeless to diff with the original, when doing an update with "abs". So this time, I just ignore to put in i586, making it easier with upgrades.

I still question the whole purpose of the arch= tag, if it means that it is "certified" by the developers. All files downloaded with abs are certified by the developers, so what is the big deal? And makeworld does not exclude building packages that are not for the architecture. And then, what does it mean for AUR, if everyone are forced to put the tag in, but now not meaning that it is certified by the developers anymore? I think a better usage would be that the package is tried and works and is meaningful on that architecture.

...

Might also want to do

grep -R i686 /var/abs/*

just to be sure there are no i686's hiding in .install files.

I did that, and there is some wierd stuff in some obscure packages in extra and community. Like in one case, a patch for an obsolete version of gcc. I just leave that out for now. kernel26 is a special case, since it has conditionals for architecture. Karolina

Mister Dobalina

3:18 p.m.

--- Karolina Lindqvist wrote:

...

Actually, I added i586 when I did it the last time, one year ago, with the result that it was practically hopeless to diff with the original, when doing an update with "abs". So this time, I just ignore to put in i586, making it easier with upgrades.

Yes, you will have to do this search-and-replace i686->i586 after every time you update abs.

...

I still question the whole purpose of the arch= tag, if it means that it is "certified" by the developers. All files downloaded with abs are certified by the developers, so what is the big deal? And makeworld does not exclude building packages that are not for the architecture.

The point is that the developers don't want to get a bunch of bug reports for things that might be i586-specific problems. They are saying "we've tested the package that is built using this PKGBUILD on i686 and/or x86_64, and if you have a problem with it let us know, but if you use this PKGBUILD to build for some other architecture, you're on your own". Though I agree that makepkg just aborting on i586 is kind of pointless, just a nice big warning would suffice. From previous posts I assume this will change in future versions of makepkg.

...

And then, what does it mean for AUR, if everyone are forced to put the tag in, but now not meaning that it is certified by the developers anymore?

I assume AUR maintainers are free to put whatever they like in the arch tag -- it's up to them what architectures they want to support for their specific package.

...

I think a better usage would be that the package is tried and works and is meaningful on that architecture.

Well, that's exactly what it means now. But the devs don't want to go to the work of doing that on i586, because arch is an i686/x86_64-optimized distribution, and has never claimed to be "tried and working" on i586. Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://mail.yahoo.ca

Karolina Lindqvist

4:48 p.m.

söndag 16 december 2007 skrev Mister Dobalina:

...

The point is that the developers don't want to get a bunch of bug reports for things that might be i586-specific problems. They are saying "we've tested the package that is built using this PKGBUILD on i686 and/or x86_64, and if you have a problem with it let us know, but if you use this PKGBUILD to build for some other architecture, you're on your own".

<<<cut>>>

...

Well, that's exactly what it means now. But the devs don't want to go to the work of doing that on i586, because arch is an i686/x86_64-optimized distribution, and has never claimed to be "tried and working" on i586.

Is that the opinion of all the developers? If it is so, I have to consider forking off my own distribution based on archlinux. It simplifies some things, since I can deviate and don't have to care for policies and so on. But forks can create extra trouble in the future, and it always splits up human resources. Anyway, I already have archi586 running, and currently I am mostly spending time with bugs in archlinux, and not so much with the i586 implementation. Karolina

Travis Willard

5:54 p.m.

On Dec 16, 2007 11:48 AM, Karolina Lindqvist wrote:

...

söndag 16 december 2007 skrev Mister Dobalina:

...
The point is that the developers don't want to get a bunch of bug reports for things that might be i586-specific problems. They are saying "we've tested the package that is built using this PKGBUILD on i686 and/or x86_64, and if you have a problem with it let us know, but if you use this PKGBUILD to build for some other architecture, you're on your own".

Well, that's exactly what it means now. But the devs don't want to go to the work of doing that on i586, because arch is an i686/x86_64-optimized distribution, and has never claimed to be "tried and working" on i586.

Is that the opinion of all the developers?

If it is so, I have to consider forking off my own distribution based on archlinux. It simplifies some things, since I can deviate and don't have to care for policies and so on. But forks can create extra trouble in the future, and it always splits up human resources.

Anyway, I already have archi586 running, and currently I am mostly spending time with bugs in archlinux, and not so much with the i586 implementation.

As far as I know we don't have plans for an i586 port. There's lowarch, which I think was mentioned around this thread already (apologies for not reading the backlogs) - if you're that dedicated about maintaining i586 then you should get in contact with the lowarch people and try to combine efforts, instead of doing it all yourself. We encourage ports - we certainly don't have the manpower to maintain a ton of architectures, and if others are willing to provide Arch for different platforms, we won't stand in the way. As far as the way Arch currently is, we started out with i686 and expanded to include x86_64 when it became a popular choice and we had willing volunteers for it. We don't currently support i586 "officially" and, as far as I know, have no plan to - partly because none of the devs have the need to run Arch on i586 hardware, I imagine, although I might be wrong. So yes, bug reports for problems specifically on i586 (though I doubt there would be many differences) will probably be considered low-priority. Our original target was i686 and greater - that was part of the distro's selling points, due to the added responsiveness and snappiness i686 optimization gave the system. PKGBUILDs list what architectures we've personally built and tested them on. The fact that makepkg errors out when an architecture isn't listed in the arch=(...) array is, IMO, probably not the best behaviour, and in pacman 3.1's makepkg there's the option to ignore that as a warning instead of refusing to build. If you want to grab the development (-git) version of pacman, you can use Dan's devel repo by adding the following to pacman.conf: [pacman-git] Server = http://www.archlinux.org/~dan/pacman-git/ And install it with pacman -Sy pacman-git.

Karolina Lindqvist

17 Dec 17 Dec

9:22 a.m.

söndag 16 december 2007 skrev Travis Willard:

...

As far as I know we don't have plans for an i586 port. There's lowarch, which I think was mentioned around this thread already (apologies for not reading the backlogs) - if you're that dedicated about maintaining i586 then you should get in contact with the lowarch people and try to combine efforts, instead of doing it all yourself. We encourage ports - we certainly don't have the manpower to maintain a ton of architectures, and if others are willing to provide Arch for different platforms, we won't stand in the way.

I looked at lowarch, but it appears to be not maintained anymore and have a different focus than what I have. I instead started out with the partial i586 port of archlinux that I did a year ago, and go on from there. core is now updated to current, and I am proceeding to extra. My repository will go on-line, as soon as I have everything needed to make this machine my online machine. Which means web-server and firewall software. The work to make it run on i586 is easy, the time-consuming problem is to fix bugs in archlinux as I go. Now, as one year ago, I find that many packages just don't build, and a few are so outdated that the source version have been retired and is not available. SUGGESTION 1: Have a central repository for all the source files needed by archlinux, and modify makepkg so that when the source cannot be found on the original place, it is gotten from this backup repository. That way makepkg will always work on a package. SUGGESTION 2: Have a spider that goes through the abs tree, and check if every source file is available. When a source is found missing on its original place, an email is sent to the respective developer for action. Until he fixes the problem, the backup source file repository will provide the source.

...

So yes, bug reports for problems specifically on i586 (though I doubt there would be many differences) will probably be considered low-priority.

Ok, I will avoid sending in bug reports that might be related to i586, and only if I am really, really sure that it applies to i686.

...

PKGBUILDs list what architectures we've personally built and tested them on. The fact that makepkg errors out when an architecture isn't listed in the arch=(...) array is, IMO, probably not the best behaviour, and in pacman 3.1's makepkg there's the option to ignore that as a warning instead of refusing to build.

I understand the policy of archlinux, that it should work on the developers machines, and that there is no big interest of expanding to anything else. About the makepkg erroring out, on second thought I think it is a good idea. Karolina

Travis Willard

11:38 a.m.

On Dec 17, 2007 4:22 AM, Karolina Lindqvist wrote:

...

SUGGESTION 1: Have a central repository for all the source files needed by archlinux, and modify makepkg so that when the source cannot be found on the original place, it is gotten from this backup repository. That way makepkg will always work on a package.

SUGGESTION 2: Have a spider that goes through the abs tree, and check if every source file is available. When a source is found missing on its original place, an email is sent to the respective developer for action. Until he fixes the problem, the backup source file repository will provide the source.

We've actually discussed hosting the sources somewhere on our own servers, but nothing has come of it yet.

...

I understand the policy of archlinux, that it should work on the developers machines, and that there is no big interest of expanding to anything else. About the makepkg erroring out, on second thought I think it is a good idea.

Well, no, that's not Arch's policy at all. The problem is, we're staffed by a handful of volunteer developers. We made the decision to be i686-optimized, and later on the decision to support x86_64, but there's only so much we can do, and so we stand by those decisions. At current, there are no plans to support i586 officially.

David Moore

12:30 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Travis Willard wrote:

...

On Dec 17, 2007 4:22 AM, Karolina Lindqvist wrote:

...
SUGGESTION 1: Have a central repository for all the source files needed by archlinux, and modify makepkg so that when the source cannot be found on the original place, it is gotten from this backup repository. That way makepkg will always work on a package.

SUGGESTION 2: Have a spider that goes through the abs tree, and check if every source file is available. When a source is found missing on its original place, an email is sent to the respective developer for action. Until he fixes the problem, the backup source file repository will provide the source.

We've actually discussed hosting the sources somewhere on our own servers, but nothing has come of it yet.

It's worth plugging a reminder that Arch's failure to do this so far is a violation of the GPL for all GPL-licensed packages. This should be implemented as soon as possible. David Moore -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHZmvaOP+t1LlaoiERAmlIAJ485rS0l/D+jSYm8Qa0K8oV6KqUTwCdGy6L nn+VI0yfHoDnKlYViex9Ff8= =v/1S -----END PGP SIGNATURE-----

Karolina Lindqvist

20 Dec 20 Dec

5:50 p.m.

måndag 17 december 2007 skrev David Moore:

...

It's worth plugging a reminder that Arch's failure to do this so far is a violation of the GPL for all GPL-licensed packages. This should be implemented as soon as possible.

There are quite some packages, mostly in extra, that are not on the source location specified, but that you have to hunt the net for. In some cases the md5sum does not match, so you don't even know if it is the same source. And if something is made for a 5 year old version of linux, I wonder if it still works and is doing the same thing, or that the function maybe is not needed anymore? Suggestion: Kick out the obsolete packages, particularly those that have not seen any upstreams activity for years. They can be moved to AUR and community for those few who still want them. Karolina

K. Piche

3:36 a.m.

On Sun, 2007-12-16 at 12:54 -0500, Travis Willard wrote:

...

On Dec 16, 2007 11:48 AM, Karolina Lindqvist wrote:

...
söndag 16 december 2007 skrev Mister Dobalina:

...

As far as the way Arch currently is, we started out with i686 and expanded to include x86_64 when it became a popular choice and we had willing volunteers for it. We don't currently support i586 "officially" and, as far as I know, have no plan to - partly because none of the devs have the need to run Arch on i586 hardware, I imagine, although I might be wrong.

I have a i586 file/print server. I even have a mini i386 port but it's not much fun to use. :) However I'm not interested in running an official i586 port since the packages are stripped down for file serving/printing - as in no X and no optional libraries. Are you using kernel 2.6 for the VIA port? k -- K. Piche

Karolina Lindqvist

8:37 a.m.

torsdag 20 december 2007 skrev K. Piche:

...

I have a i586 file/print server. I even have a mini i386 port but it's not much fun to use. :) However I'm not interested in running an official i586 port since the packages are stripped down for file serving/printing - as in no X and no optional libraries.

Are you using kernel 2.6 for the VIA port?

k

I am using the latest kernel 2.6 Karolina

Karolina Lindqvist

17 Dec 17 Dec

7:43 p.m.

lördag 15 december 2007 skrev Travis Willard:

...

Just a hint, since you were looking to add i586 - find and sed are your friends. :D

find -name PKGBUILD -exec sed -i '/^arch=/ { /i586/ !{ s/^arch=(/arch=(i586 / } }' {} \;

That will find every PKGBUILD and add i586 to the packages that don't already have it. Yay!

Actually it will not, since 749 PKGBUILDs from abs does not have an "arch=" line. :-) But with my friend emacs I fixed that problem in about a minute. Karolina

Attila

15 Dec 15 Dec

10:54 a.m.

On Samstag, 15. Dezember 2007 09:43 Karolina Lindqvist wrote:

...

That is allright, but why abort "makepkg" on non-authorized architectures?

It seems that makepkg test only right or wrong because a "arch=(aai686 aax86_64" brings the same break. I'm not a dev but from my view this is too strict. On the other side only a warning at the beginning is too simple because it can get overseen very easy but i think a warning at the end will be read in the most cases. Perhaps everybody can lives with this suggestion better than with the actual situation. See you, Attila

Jan de Groot

19 Dec 19 Dec

6:07 p.m.

On Sat, 2007-12-15 at 11:54 +0100, Attila wrote:

...

On Samstag, 15. Dezember 2007 09:43 Karolina Lindqvist wrote:

...
That is allright, but why abort "makepkg" on non-authorized architectures?

It seems that makepkg test only right or wrong because a "arch=(aai686 aax86_64" brings the same break. I'm not a dev but from my view this is too strict. On the other side only a warning at the beginning is too simple because it can get overseen very easy but i think a warning at the end will be read in the most cases. Perhaps everybody can lives with this suggestion better than with the actual situation.

See you, Attila

Why is checking strict wrong? If the official name of an architecture is i686, and we make all packages have the i686 extension, why would aai686 be allowed then? We could decide to use x86 as architecture, when an x86_64-only package doesn't work on 32bit, does that mean that the check should pass because x86 is in the architecture name?

Attila

6:53 p.m.

On Mittwoch, 19. Dezember 2007 19:07 Jan de Groot wrote:

...

Why is checking strict wrong? If the official name of an architecture is i686, and we make all packages have the i686 extension, why would aai686 be allowed then?

Sorry, i want only to show why i586 don't works and i decide to make an example with aa686. This was a bad choice of mine.

...

We could decide to use x86 as architecture, when an x86_64-only package doesn't work on 32bit, does that mean that the check should pass because x86 is in the architecture name?

No, you be right and i only want suggest to have 'yes' and 'no' as now and the new one 'unsupported'. Perhaps this can stand in the makepkg.conf as at example UNSUPPORTED_ARCH="". Than people as Karolina can decide to write there i586 in this array and makepkg prints an warning on the console but don't stop. Again sorry, if my English is too bad for explaining what i want to say. And it is clear that you can't support all possible platforms. See you, Attila

JJDaNiMoTh

15 Dec 15 Dec

8:36 a.m.

On Sat, 15 Dec 2007 08:00:19 +0100 Karolina Lindqvist wrote:

...

I guess I am going to maintain this, for my own usage, for quite a while now, since I have a machine that is going to run it. It appears that a few others also quietly maintain archi586 the same way.

Karolina

Do you want to share these packages? It can be very useful for who have a VIA chipset. Ubuntu has break my patience :) -- JJDaNiMoTh - ArchLinux Trusted User

Karolina Lindqvist

26 Dec 26 Dec

11:48 a.m.

lördag 15 december 2007 skrev JJDaNiMoTh:

...

On Sat, 15 Dec 2007 08:00:19 +0100

Karolina Lindqvist wrote:

...
I guess I am going to maintain this, for my own usage, for quite a while now, since I have a machine that is going to run it. It appears that a few others also quietly maintain archi586 the same way.

Karolina

Do you want to share these packages? It can be very useful for who have a VIA chipset. Ubuntu has break my patience :)

Yes, now I have them unofficially on ftp://archi586.ath.cx/archi586/ The whole thing is not completely ready and polished yet, and a booting ISO USB-stick image will also come a little bit later. But it is working, and the server machine runs archi586 on a VIA ITX. pacman is not there right now, only a slightly bufixed and enhanced pacman-git. Pacman just did not work for it. Karolina

Mark Constable

3:47 p.m.

On Wednesday 26 December 2007 21:48:39 Karolina Lindqvist wrote:

...

Yes, now I have them unofficially on ftp://archi586.ath.cx/archi586/

The whole thing is not completely ready and polished yet, and a booting ISO USB-stick image will also come a little bit later. But it is working, and the server machine runs archi586 on a VIA ITX.

Excellent effort. What about the source packages, are they available ? --markc

Karolina Lindqvist

4:11 p.m.

onsdag 26 december 2007 skrev Mark Constable:

...

What about the source packages, are they available ?

--markc

It will come, I just have to figure out how. Karolina

Mark Constable

7:32 p.m.

On Thursday 27 December 2007 02:11:21 Karolina Lindqvist wrote:

...

...
What about the source packages, are they available ?

It will come, I just have to figure out how.

I find code.google.com is very useful. By pushing the updates into a google group every change is documented, an RSS feed is automatically available, and you can add other members to help keep the source packages up to date. Example... http://code.google.com/p/proaudio/ --markc

bardo

15 Dec 15 Dec

11:48 a.m.

2007/12/15, Karolina Lindqvist :

...

To edit each and every PKGBUILD for each and every package and every update appears like quite a big work.

If you use pacman-git (which a lot of people is using without too much hassle, actually it's really stable) you'll find the -A option: -A, --ignorearch Ignore incomplete arch field in PKGBUILD Here's the PKGBUILD: http://www.archlinux.org/~dan/pacman-git/pacman-git/PKGBUILD Corrado

Karolina Lindqvist

16 Dec 16 Dec

7:10 a.m.

lördag 15 december 2007 skrev bardo:

...

2007/12/15, Karolina Lindqvist :

...
To edit each and every PKGBUILD for each and every package and every update appears like quite a big work.

If you use pacman-git (which a lot of people is using without too much hassle, actually it's really stable) you'll find the -A option:

-A, --ignorearch Ignore incomplete arch field in PKGBUILD

Here's the PKGBUILD: http://www.archlinux.org/~dan/pacman-git/pacman-git/PKGBUILD

Corrado

What is pacman-git, can you tell me more about it? Would it offer some advantages either in speed, or for other architectures than the approved? Is it compatible with normal pacman? pacman is otherwise one of the packages I don't want to mess with, since it is so central to the function of archlinux. Karolina

Karolina Lindqvist

17 Dec 17 Dec

8:49 a.m.

lördag 15 december 2007 skrev bardo:

...

2007/12/15, Karolina Lindqvist :

...
To edit each and every PKGBUILD for each and every package and every update appears like quite a big work.

If you use pacman-git (which a lot of people is using without too much hassle, actually it's really stable) you'll find the -A option:

-A, --ignorearch Ignore incomplete arch field in PKGBUILD

Here's the PKGBUILD: http://www.archlinux.org/~dan/pacman-git/pacman-git/PKGBUILD

Corrado

Actually, this turned out to be a good advice. Thank you! I run into so many problem with ordinary pacman. After fixing some bugs in pacman-git, and implementing some extra features that I needed, it works good for me. And this arch thing, after sleeping on it, I found that it can be made to an advantage. I modified makeworld so that it only builds if it is in a supported arch, unless --ignorearch is specified. That way I can mark all files I need with my arch, and the rest will be ignored in build. I would call that a "good thing", since looking in the PKGBUILD files, all archs are not included in all packages. Now I just include i586 in the packages that are appropriate, and do a "makeworld" to compile only them and ignore the rest. Karolina

5979

Age (days ago)

5991

Last active (days ago)

List overview

Download

33 comments

14 participants

participants (14)

Aaron Griffin
Attila
bardo
Dan McGee
David Moore
Jan de Groot
JJDaNiMoTh
K. Piche
Karolina Lindqvist
Mark Constable
Massimiliano Brocchini
Mister Dobalina
R. Dale Thomas
Travis Willard