Use architecture setting to provide x86-64-v3

ptr1337 commented

2021-07-08 16:56:10 +02:00

Since you can edit PKGBUILD and add following:

arch=('x86_64' 'x86_64_v3')

Edit your makepkg.conf to following when building _v3 packages:

CARCH="x86_64_v3"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64-v3  -mtune=generic -O3 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"

Then build your packages with this config.

Change Architecture from the user in pacman.conf to:

Architecture = x86_64 x86_64_v3

until a fix is out for pacman.

Since you can edit PKGBUILD and add following: `arch=('x86_64' 'x86_64_v3')` Edit your makepkg.conf to following when building _v3 packages: ``` CARCH="x86_64_v3" CHOST="x86_64-pc-linux-gnu" #-- Compiler and Linker Flags #CPPFLAGS="" CFLAGS="-march=x86-64-v3 -mtune=generic -O3 -pipe -fno-plt -fexceptions \ -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \ -fstack-clash-protection -fcf-protection" CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS" ``` Then build your packages with this config. Change Architecture from the user in pacman.conf to: ``` Architecture = x86_64 x86_64_v3 ``` until a fix is out for pacman.

anonfunc commented

2021-07-08 17:04:39 +02:00

Owner

I know what you mean, and there was a discussion about how to add such an 'arch' as x86-64-v3 to pacman ecosystems. What you propose was discussed and probably is the better way to do it, but comes with its own drawbacks (besides pacman needing support for it).

I decided to go with separate repos because that requires less PKGBUILD editing and less user action. You also have to remember I started this project when support for arch as it is now had not even been considered.

Official Archlinux may go for the arch = x86_64_v3 approach, but that may not be very suited to this project in this stage.

I know what you mean, and there was a discussion about how to add such an 'arch' as x86-64-v3 to pacman ecosystems. What you propose was discussed and probably is the better way to do it, but comes with its own drawbacks (besides pacman needing support for it). I decided to go with separate repos because that requires less PKGBUILD editing and less user action. You also have to remember I started this project when support for `arch` as it is now had not even been considered. Official Archlinux may go for the `arch = x86_64_v3` approach, but that may not be very suited to this project in this stage.

👍 1

anonfunc added the

question

label 2021-07-08 17:04:54 +02:00

ptr1337 commented

2021-07-08 17:07:13 +02:00

Author

Im running right now two repos and its working perfectly so far.

but yeah, editing every PKGBUILD is for real much work.

Im running right now two repos and its working perfectly so far. but yeah, editing every PKGBUILD is for real much work.

anonfunc changed title from ~~I think this is not the "correct" solution.~~ to Use architecture setting to provide x86-64-v3

2021-07-27 16:42:46 +02:00

Neko-san referenced this issue from ALHP/alhp-mirrorlist

2021-12-10 03:35:09 +01:00

Can't Refresh Any Databases After Installing `alhp-keyring` and `alhp-mirrorlist` #1

HLFH commented

2022-12-28 09:13:46 +01:00

My CPU is compatible with x86_64_v2.
Offtopic: I see some critical issues with openssl and linux.

Official Archlinux may go for the arch = x86_64_v3 approach, but that may not be very suited to this project in this stage.

I'd love to see this project to follow an arch = x86_64_v2 / arch = x86_64_v3 approach. Any easy way to modify this project and follow this modern approach? :)

My CPU is compatible with `x86_64_v2`. Offtopic: I see some critical issues with [`openssl`](https://git.harting.dev/ALHP/ALHP.GO/issues/156) and [`linux`](https://git.harting.dev/ALHP/ALHP.GO/issues/68). > Official Archlinux may go for the arch = x86_64_v3 approach, but that may not be very suited to this project in this stage. I'd love to see this project to follow an `arch = x86_64_v2` / `arch = x86_64_v3` approach. Any easy way to modify this project and follow this modern approach? :)

anonfunc commented

2022-12-28 17:24:31 +01:00

Owner

It's much too late for that now, and there are no benefits in switching to it at this moment.

Btw, there are no 'critical' issues, since you should not use this on any production system anyways, and it's not advised to do so anywhere.

It's not more "modern" in any way, just different approach, which would mean restructuring the whole repo and possibly break exiting usage. Since there are no benefits, I see no reason to do this.

It's much too late for that now, and there are no benefits in switching to it at this moment. Btw, there are no 'critical' issues, since you should *not* use this on any production system anyways, and it's not advised to do so anywhere. It's not more "modern" in any way, just different approach, which would mean restructuring the whole repo and possibly break exiting usage. Since there are no benefits, I see no reason to do this.

HLFH commented

2022-12-29 15:34:09 +01:00

@anonfunc Then, close this issue/approach as a won't fix?

Btw, there are no 'critical' issues, since you should not use this on any production system anyways

Well, for me, Arch Linux is bleeding edge that works, not bleeding edge that breaks. I did use ALHP on a production system, I guess because Arch Linux is favouring x86_64_v3, I'll have to drop my current x86_64_v2 server in favour of one that supports x86_64_v3 when they will complete the support/migration and rely solely on their official support.

It's not more "modern" in any way

I suppose with the ALHP setup and the pacman -Qi packagename command, arch is shown as x86_64 and with this other approach, it would be shown correctly as x86_64_v2, no?

@anonfunc Then, close this issue/approach as a `won't fix`? > Btw, there are no 'critical' issues, since you should not use this on any production system anyways Well, for me, Arch Linux is *bleeding edge that works*, not *bleeding edge that breaks*. I did use ALHP on a production system, I guess because Arch Linux is favouring x86_64_v3, I'll have to drop my current x86_64_v2 server in favour of one that supports x86_64_v3 when they will complete the support/migration and rely solely on their official support. > It's not more "modern" in any way I suppose with the ALHP setup and the `pacman -Qi packagename` command, arch is shown as x86_64 and with this other approach, it would be shown correctly as x86_64_v2, no?

anonfunc commented

2022-12-29 16:22:32 +01:00

Owner

@anonfunc Then, close this issue/approach as a won't fix?

Let's do that.

Btw, there are no 'critical' issues, since you should not use this on any production system anyways

Well, for me, Arch Linux is bleeding edge that works, not bleeding edge that breaks. I did use ALHP on a production system, I guess because Arch Linux is favouring x86_64_v3, I'll have to drop my current x86_64_v2 server in favour of one that supports x86_64_v3 when they will complete the support/migration and rely solely on their official support.

I understand, but this is and probably will always be an experimental "port". I'm the sole developer working on this, and I sadly can not (yet) clone myself. With enough polish this port can rival ALARM and other quality ports out there, but the bottleneck here is the time I can invest into this.

It's not more "modern" in any way

I suppose with the ALHP setup and the pacman -Qi packagename command, arch is shown as x86_64 and with this other approach, it would be shown correctly as x86_64_v2, no?

Yep, that would be the only improvement this brings I can think of. Sure, it would make filtering these packages easier, but there are other means to do that.

> @anonfunc Then, close this issue/approach as a `won't fix`? > Let's do that. > > Btw, there are no 'critical' issues, since you should not use this on any production system anyways > > Well, for me, Arch Linux is *bleeding edge that works*, not *bleeding edge that breaks*. I did use ALHP on a production system, I guess because Arch Linux is favouring x86_64_v3, I'll have to drop my current x86_64_v2 server in favour of one that supports x86_64_v3 when they will complete the support/migration and rely solely on their official support. > I understand, but this is and probably will always be an experimental "port". I'm the sole developer working on this, and I sadly can not (yet) clone myself. With enough polish this port can rival ALARM and other quality ports out there, but the bottleneck here is the time I can invest into this. > > It's not more "modern" in any way > > I suppose with the ALHP setup and the `pacman -Qi packagename` command, arch is shown as x86_64 and with this other approach, it would be shown correctly as x86_64_v2, no? Yep, that would be the only improvement this brings I can think of. Sure, it would make filtering these packages easier, but there are other means to do that.

👍 1

anonfunc added

wontfix

and removed

question

labels 2022-12-29 16:23:31 +01:00

anonfunc closed this issue

2023-01-02 13:12:57 +01:00

Use architecture setting to provide x86-64-v3 #9