[arch-dev-public] Shadowing i686, round 1
In September we discussed upgrading the default -march value for packages to include SSE2 (and possibly more instructions). I think the general consensus was that we don't agree what we should do and we just left the problem intact. Semi-necrobumping that thread, I want to bring back one proposal – let's deprecate i686 architecture. All my machines at home and work are x86_64. Building i686 packages is a chore I'm less and less willing to do, and I boot up a 32-bit virtual machine only if bug has been reported against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.) To back up my idea, our completely unreliable pkgstats data says that 8.53% came from i686 installs, but only a little over 4% is incompatible with amd64. Obviously there is no way to verify this data, but I suspect that these numbers are even lower in the reality. We're just wasting our time. I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause. Let's see where we end up this time. Bartłomiej
On 12/12/16 at 09:51pm, Bartłomiej Piotrowski wrote:
against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
I know for sure that you are not the only one :)
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*). -- Jelle van der Waa
On 2016-12-12 22:02, Jelle van der Waa wrote:
I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*).
Creating a new or adapting existing solutions is time consuming. We struggle to finish and switch to VCS-agnostic dbscripts for a long time and I wouldn't expect that any automated build server will take less time, not to mention security concerns expressed in previous discussions. On the opposite, dropping support is effortless. Bartłomiej
On 13/12/16 19:20, Bartłomiej Piotrowski wrote:
On 2016-12-12 22:02, Jelle van der Waa wrote:
I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*).
Creating a new or adapting existing solutions is time consuming. We struggle to finish and switch to VCS-agnostic dbscripts for a long time and I wouldn't expect that any automated build server will take less time, not to mention security concerns expressed in previous discussions. On the opposite, dropping support is effortless.
Given we can't get databases signed, I can't ever see an autobuild system working. A
+1 here as well. I don't test i686 either and I already have a few packages (emulation related) that are x86_64 only, either because they won't build on i686 without some fixes, or because upstream flat out dropped support for it. Cheers, December 13, 2016 10:31 AM, "Allan McRae" <allan@archlinux.org> wrote:
On 13/12/16 19:20, Bartłomiej Piotrowski wrote:
On 2016-12-12 22:02, Jelle van der Waa wrote:
I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*).
Creating a new or adapting existing solutions is time consuming. We struggle to finish and switch to VCS-agnostic dbscripts for a long time and I wouldn't expect that any automated build server will take less time, not to mention security concerns expressed in previous discussions. On the opposite, dropping support is effortless.
Given we can't get databases signed, I can't ever see an autobuild system working.
A
-- Maxime
On 12/12/2016 10:02 PM, Jelle van der Waa wrote:
On 12/12/16 at 09:51pm, Bartłomiej Piotrowski wrote:
against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
I know for sure that you are not the only one :)
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
I'm in favor of an auto build solution, since this has multiple bonusses. We could extend the auto build solution for reproducible builds (yay!). Auto rebuilds and maybe later when vendors get their act togehter (aarch64 *cough*).
I agree to get rid of i686. However I want to refer to the discussion about stronger hashes in PKGBUILDs. If we use an automatic build solution that builds the packages for 32bit, we need to make sure that we have gpg signed sources or strong hashes. GPG signatures would be best, but if they are not available we must rely on the hash. To ensure that the build server downloads the exact same source as the maintainer (who checked and tested the source) we must use strong hashes. (This already applies for the ALARM project). Now that some packages still need some arch dependent modification I would still add those, if possible. It would mean our PKGBUILD is compatible with 32bit, but does not guarantee it. I personally would also love to do this for ARM, as it is just a really small change sometimes to add support for a specific arch. This way the build server maintainers do not need to patch every PKGBUILD (considering trivial changes). I can see it as volunteer addition of the maintainer in this case. ~Nico
On 2016-12-13 12:05, NicoHood wrote:
I agree to get rid of i686. However I want to refer to the discussion about stronger hashes in PKGBUILDs. If we use an automatic build solution that builds the packages for 32bit, we need to make sure that we have gpg signed sources or strong hashes.
GPG signatures would be best, but if they are not available we must rely on the hash. To ensure that the build server downloads the exact same source as the maintainer (who checked and tested the source) we must use strong hashes. (This already applies for the ALARM project).
Please cut it. The subject is pretty clear: getting rid (or not) of x86. Keep this pointless discussion on hashes outside this thread. Thanks in advance.
Now that some packages still need some arch dependent modification I would still add those, if possible. It would mean our PKGBUILD is compatible with 32bit, but does not guarantee it. I personally would also love to do this for ARM, as it is just a really small change sometimes to add support for a specific arch.
It's not going to happen. I don't have 32bit, I don't run Arch on any ARM board. I have no way to review if such compatibility change makes any sense. If ever, we will just give people responsible for ARM port access to SVN/Git, but just as with my previous comment, this seems unrelated for now. Bartłomiej
[2016-12-12 21:51:31 +0100] Bartłomiej Piotrowski:
In September we discussed upgrading the default -march value for packages to include SSE2 (and possibly more instructions). I think the general consensus was that we don't agree what we should do and we just left the problem intact.
Semi-necrobumping that thread, I want to bring back one proposal – let's deprecate i686 architecture. All my machines at home and work are x86_64. Building i686 packages is a chore I'm less and less willing to do, and I boot up a 32-bit virtual machine only if bug has been reported against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
To back up my idea, our completely unreliable pkgstats data says that 8.53% came from i686 installs, but only a little over 4% is incompatible with amd64. Obviously there is no way to verify this data, but I suspect that these numbers are even lower in the reality. We're just wasting our time.
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
That sounds great to me. How about June 1st, 2017? It's about six months for now, surely that's enough time to see things coming for those who still care about i686. Cheers. -- Gaetan
Hi, I have no i686 around here anymore since more than a year. If there is no real need for it anymore we should stop supporting it. greetings tpowa 2016-12-13 1:51 GMT+01:00 Gaetan Bisson <bisson@archlinux.org>:
[2016-12-12 21:51:31 +0100] Bartłomiej Piotrowski:
In September we discussed upgrading the default -march value for packages to include SSE2 (and possibly more instructions). I think the general consensus was that we don't agree what we should do and we just left the problem intact.
Semi-necrobumping that thread, I want to bring back one proposal – let's deprecate i686 architecture. All my machines at home and work are x86_64. Building i686 packages is a chore I'm less and less willing to do, and I boot up a 32-bit virtual machine only if bug has been reported against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
To back up my idea, our completely unreliable pkgstats data says that 8.53% came from i686 installs, but only a little over 4% is incompatible with amd64. Obviously there is no way to verify this data, but I suspect that these numbers are even lower in the reality. We're just wasting our time.
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
That sounds great to me.
How about June 1st, 2017? It's about six months for now, surely that's enough time to see things coming for those who still care about i686.
Cheers.
-- Gaetan
-- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 12/12/16 21:51, Gaetan Bisson wrote:
[2016-12-12 21:51:31 +0100] Bartłomiej Piotrowski:
In September we discussed upgrading the default -march value for packages to include SSE2 (and possibly more instructions). I think the general consensus was that we don't agree what we should do and we just left the problem intact.
Semi-necrobumping that thread, I want to bring back one proposal – let's deprecate i686 architecture. All my machines at home and work are x86_64. Building i686 packages is a chore I'm less and less willing to do, and I boot up a 32-bit virtual machine only if bug has been reported against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
To back up my idea, our completely unreliable pkgstats data says that 8.53% came from i686 installs, but only a little over 4% is incompatible with amd64. Obviously there is no way to verify this data, but I suspect that these numbers are even lower in the reality. We're just wasting our time.
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
That sounds great to me.
How about June 1st, 2017? It's about six months for now, surely that's enough time to see things coming for those who still care about i686.
Cheers.
If this is going to happens, maybe the ISO of this month should be the last dual, with i686 support.
On Mon, 2016-12-12 at 21:51 +0100, Bartłomiej Piotrowski wrote:
I'd like to set a certain date of dropping i686 completely. +1
What's the round 2? Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 2016-12-13 08:53, Sébastien Luttringer wrote:
On Mon, 2016-12-12 at 21:51 +0100, Bartłomiej Piotrowski wrote:
I'd like to set a certain date of dropping i686 completely. +1
What's the round 2?
Cheers,
Sketching the execution plan and how big time window is reasonable to everyone.I just want to gather more responses first. Bartłomiej
I still have two media players that run i686, but I can switch those to a different distro if necessary although I'd obviously prefer not having to do that. Count that as a -0.25. If we drop it, I'd just like to keep the possibility of us supporting different architectures. I believe there was interest in merging ARM support with our packages, but I don't know the state of that. If there is no second architecture, I fear that the support we currently have (dbscript, devtools, archweb, various build scripts or stuff like sogrep) will die off when software is changed. Florian
On 13/12/16 23:15, Florian Pritz via arch-dev-public wrote:
I still have two media players that run i686, but I can switch those to a different distro if necessary although I'd obviously prefer not having to do that. Count that as a -0.25.
I have one webserver running i686. My vote counts as -1 :) A
On 2016-12-13 14:15, Florian Pritz via arch-dev-public wrote:
If we drop it, I'd just like to keep the possibility of us supporting different architectures. I believe there was interest in merging ARM support with our packages, but I don't know the state of that. If there is no second architecture, I fear that the support we currently have (dbscript, devtools, archweb, various build scripts or stuff like sogrep) will die off when software is changed.
I don't want to touch these part all (except for pushing only x86_64 with {extra,community,core}pkg wrappers). I agree that removal of multiple architecture support from our tooling would be bad. Bartłomiej
Am Mon, 12 Dec 2016 21:51:31 +0100 schrieb Bartłomiej Piotrowski <bpiotrowski@archlinux.org>:
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
Let's see where we end up this time.
Bartłomiej
A big +1 from me. I'd suggest to give community 6 or 12 months to prepare the drop. -Andy
-1 for dropping i686 completely. +1 for introducing automated builds, even if it's less secure. I would like to keep i686 supported, and willing to do anything that is needed to setup and maintain an official automated build server for i686 packages (and possibly for other architectures). -- György Balló Trusted User
On Tue, 13 Dec 2016 19:16:53 +0100 Balló György via arch-dev-public <arch-dev-public@archlinux.org> wrote:
-1 for dropping i686 completely.
+1 for introducing automated builds, even if it's less secure.
I would like to keep i686 supported, and willing to do anything that is needed to setup and maintain an official automated build server for i686 packages (and possibly for other architectures).
-- György Balló Trusted User
I've got to ask, why do you feel so strongly about it? It's been pointed out that i686 really doesn't fit in with the original goals of Arch anymore, is less and less supported upstream, and essentially untested. What is the compelling reason for keeping it around?
2016. 12. 13, kedd keltezéssel 12.29-kor Doug Newgard ezt írta:
On Tue, 13 Dec 2016 19:16:53 +0100 Balló György via arch-dev-public <arch-dev-public@archlinux.org> wrote:
-1 for dropping i686 completely.
+1 for introducing automated builds, even if it's less secure.
I would like to keep i686 supported, and willing to do anything that is needed to setup and maintain an official automated build server for i686 packages (and possibly for other architectures).
I've got to ask, why do you feel so strongly about it? It's been pointed out that i686 really doesn't fit in with the original goals of Arch anymore, is less and less supported upstream, and essentially untested. What is the compelling reason for keeping it around?
Because I still use an i686-only system occasionally, and I prefer to keep old hardware working with my favourite distribution. I agree that building packages manually for a small percentage of users is pointless. But most of the packages can be built for i686 without any modifications. We just need an automated build server, which takes the job. -- György Balló Trusted User
On 12/13/2016 08:04 PM, Balló György via arch-dev-public wrote:
2016. 12. 13, kedd keltezéssel 12.29-kor Doug Newgard ezt írta:
On Tue, 13 Dec 2016 19:16:53 +0100 Balló György via arch-dev-public <arch-dev-public@archlinux.org> wrote:
-1 for dropping i686 completely.
+1 for introducing automated builds, even if it's less secure.
I would like to keep i686 supported, and willing to do anything that is needed to setup and maintain an official automated build server for i686 packages (and possibly for other architectures).
I've got to ask, why do you feel so strongly about it? It's been pointed out that i686 really doesn't fit in with the original goals of Arch anymore, is less and less supported upstream, and essentially untested. What is the compelling reason for keeping it around?
Because I still use an i686-only system occasionally, and I prefer to keep old hardware working with my favourite distribution. I agree that building packages manually for a small percentage of users is pointless. But most of the packages can be built for i686 without any modifications. We just need an automated build server, which takes the job.
-- György Balló Trusted User
If we have reproduceable builds we could also use this buildserver to build the x64 packages. I know that this is a huge task, but then we could automate the package building better in a centralized place. And instead of dropping i686 we could integrate arm as well. Those will not be officially supported, but we could give people access to fix those arch specific problems. Normal maintainers can focus on x64 development while some others have a place to distribute and maintain other architectures of their favorite os.
On 14/12/16 08:05, NicoHood wrote:
On 12/13/2016 08:04 PM, Balló György via arch-dev-public wrote:
2016. 12. 13, kedd keltezéssel 12.29-kor Doug Newgard ezt írta:
On Tue, 13 Dec 2016 19:16:53 +0100 Balló György via arch-dev-public <arch-dev-public@archlinux.org> wrote:
-1 for dropping i686 completely.
+1 for introducing automated builds, even if it's less secure.
I would like to keep i686 supported, and willing to do anything that is needed to setup and maintain an official automated build server for i686 packages (and possibly for other architectures).
I've got to ask, why do you feel so strongly about it? It's been pointed out that i686 really doesn't fit in with the original goals of Arch anymore, is less and less supported upstream, and essentially untested. What is the compelling reason for keeping it around?
Because I still use an i686-only system occasionally, and I prefer to keep old hardware working with my favourite distribution. I agree that building packages manually for a small percentage of users is pointless. But most of the packages can be built for i686 without any modifications. We just need an automated build server, which takes the job.
-- György Balló Trusted User
If we have reproduceable builds we could also use this buildserver to build the x64 packages. I know that this is a huge task, but then we could automate the package building better in a centralized place. And instead of dropping i686 we could integrate arm as well.
Those will not be officially supported, but we could give people access to fix those arch specific problems. Normal maintainers can focus on x64 development while some others have a place to distribute and maintain other architectures of their favorite os.
If we had a build server, I'd prefer we concentrated on Arch's original goals. To provide a more optimised distribution than everyone else. All other distros have caught up to us these days. Some more optimised x86_64 variants would be good... A
On Tue, 13 Dec 2016 20:04:44 +0100 Balló György via arch-dev-public <arch-dev-public@archlinux.org> wrote:
Because I still use an i686-only system occasionally, and I prefer to keep old hardware working with my favourite distribution. I agree that building packages manually for a small percentage of users is pointless. But most of the packages can be built for i686 without any modifications. We just need an automated build server, which takes the job.
-- György Balló Trusted User
I guess I don't see this as a good reason to support it. I use an i686 system occasionally, too, but saying that a distro should support it for those edge cases just makes no sense to me. What we've actually got is a situation where we claim i686 support, but it's actually very poorly supported. Better to let it die and let Arch focus on what it does well.
On Mon, Dec 12, 2016 at 9:51 PM Bartłomiej Piotrowski < bpiotrowski@archlinux.org> wrote:
In September we discussed upgrading the default -march value for packages to include SSE2 (and possibly more instructions). I think the general consensus was that we don't agree what we should do and we just left the problem intact.
Semi-necrobumping that thread, I want to bring back one proposal – let's deprecate i686 architecture. All my machines at home and work are x86_64. Building i686 packages is a chore I'm less and less willing to do, and I boot up a 32-bit virtual machine only if bug has been reported against that architecture. No, I don't do even smoke tests – I assume that i686 works if x86_64 does. (Don't beat me up too hard for that.)
To back up my idea, our completely unreliable pkgstats data says that 8.53% came from i686 installs, but only a little over 4% is incompatible with amd64. Obviously there is no way to verify this data, but I suspect that these numbers are even lower in the reality. We're just wasting our time.
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
Let's see where we end up this time.
Bartłomiej
A bit +1 from me for dropping i686 sooner rather than later. The less I have to care about it the better.
Em dezembro 13, 2016 19:02 Jan Alexander Steffens via arch-dev-public escreveu:
A bit +1 from me for dropping i686 sooner rather than later. The less I have to care about it the better.
+1 about dropping i686 support entirely. Even though you can find working i686 hardware, specially on other countries, I just don't think it is compelling reason for keeping it. Cheers, Giancarlo Razzolini
Giancarlo Razzolini schreef op 2016-12-14 14:47:
Em dezembro 13, 2016 19:02 Jan Alexander Steffens via arch-dev-public escreveu:
A bit +1 from me for dropping i686 sooner rather than later. The less I have to care about it the better.
+1 about dropping i686 support entirely. Even though you can find working i686 hardware, specially on other countries, I just don't think it is compelling reason for keeping it.
Cheers, Giancarlo Razzolini
It's not about the hardware. Anything that can run x86_64 can also run i686. I still use i686 hardware that is incapable of supporting x86_64 (Core Duo), would be sad to see support getting dropped. On the other hand, archlinux should focus on x86_64. At this moment we just build and commit i686 packages, nobody actually runs any tests with i686. At this moment there's a wide community maintaining ARM packages for archlinux, probably i686 should do the same in the near future. Also, if it's about legacy hardware, why i686 and not just i586 instead? i686 is not about performance anyways.
Bartłomiej Piotrowski <bpiotrowski@archlinux.org> schrieb am Mo., 12. Dez. 2016 um 21:51 Uhr:
I'd like to set a certain date of dropping i686 completely. During that time, community and/or interested packagers could come up with either automated build solution, making it "tier 2" architecture. Otherwise it would just die of natural cause.
Let's see where we end up this time.
Bartłomiej
+1 from me. Let's drop i686, I don't have one since years. Can't remember when my last boot of an i686 system was.... Cheers Daniel
On 2016-12-12 21:51, Bartłomiej Piotrowski wrote:
Let's see where we end up this time.
Round 2. It is apparent that majority of packagers participating in discussion are for or not strongly against dropping i686. I guess no time frame will be good enough for some people, but I don't want to rush too much. Although I agree with Gerardo that we should cut out i686 from archiso, maybe starting from January build. About definitive end of i686 support, I think 9 months from now is enough time to migrate existing installations to some different distribution. What parts of our infrastructure will need to be upgraded to reflect that? dbscripts, ABS (which sounds like another candidate for dropping but let's talk about it another time) and devtools? Bartłomiej
On 2016-12-28 20:52, Bartłomiej Piotrowski wrote:
On 2016-12-12 21:51, Bartłomiej Piotrowski wrote:
Let's see where we end up this time.
Round 2. It is apparent that majority of packagers participating in discussion are for or not strongly against dropping i686.
I guess no time frame will be good enough for some people, but I don't want to rush too much. Although I agree with Gerardo that we should cut out i686 from archiso, maybe starting from January build.
About definitive end of i686 support, I think 9 months from now is enough time to migrate existing installations to some different distribution.
What parts of our infrastructure will need to be upgraded to reflect that? dbscripts, ABS (which sounds like another candidate for dropping but let's talk about it another time) and devtools?
Bartłomiej
Friendly reminder what I'm going to push through if nobody opposes. Bartłomiej
On Thu, Jan 05, 2017 at 10:08:31PM +0100, Bartłomiej Piotrowski wrote:
On 2016-12-28 20:52, Bartłomiej Piotrowski wrote:
On 2016-12-12 21:51, Bartłomiej Piotrowski wrote:
Let's see where we end up this time.
Round 2. It is apparent that majority of packagers participating in discussion are for or not strongly against dropping i686.
I guess no time frame will be good enough for some people, but I don't want to rush too much. Although I agree with Gerardo that we should cut out i686 from archiso, maybe starting from January build.
About definitive end of i686 support, I think 9 months from now is enough time to migrate existing installations to some different distribution.
What parts of our infrastructure will need to be upgraded to reflect that? dbscripts, ABS (which sounds like another candidate for dropping but let's talk about it another time) and devtools?
Bartłomiej
Friendly reminder what I'm going to push through if nobody opposes.
Bartłomiej
Let us just choose a i686 EOL date. Hardly anyone is using Arch i686 anymore and even less are testing if something works. -- Ike
On 05/01/17 04:08 PM, Bart?omiej Piotrowski wrote:
On 2016-12-28 20:52, Bart?omiej Piotrowski wrote:
On 2016-12-12 21:51, Bart?omiej Piotrowski wrote:
Let's see where we end up this time. Round 2. It is apparent that majority of packagers participating in discussion are for or not strongly against dropping i686.
I guess no time frame will be good enough for some people, but I don't want to rush too much. Although I agree with Gerardo that we should cut out i686 from archiso, maybe starting from January build.
About definitive end of i686 support, I think 9 months from now is enough time to migrate existing installations to some different distribution.
What parts of our infrastructure will need to be upgraded to reflect that? dbscripts, ABS (which sounds like another candidate for dropping but let's talk about it another time) and devtools?
Bart?omiej
Friendly reminder what I'm going to push through if nobody opposes.
Bart?omiej I'm not thrilled about having to migrate my old box that I use every now and then to another distro but I'll manage.
What I want to verify is that the change you're pushing is the minimal possible change to dbscripts, ABS and devtools per Florian's request, right? For example, it's fine to delete the *-i686-build symlinks. But archbuild should keep the part of its code that determines an arch from $0 so that we are still future proof in supporting multiple architectures.
On 2017-01-07 00:39, Connor Behan via arch-dev-public wrote:
What I want to verify is that the change you're pushing is the minimal possible change to dbscripts, ABS and devtools per Florian's request, right? For example, it's fine to delete the *-i686-build symlinks. But archbuild should keep the part of its code that determines an arch from $0 so that we are still future proof in supporting multiple architectures.
Exactly as you said. We don't have too many people working on these tools anyway, so dropping good features would be a waste of author's and mine team. Bartłomiej
On 06/01/17 07:08, Bartłomiej Piotrowski wrote:
Friendly reminder what I'm going to push through if nobody opposes.
Can we have a detailed discussion what EOL for i686 means? I have seen a couple of proposals being: 1) We just kill i686 (as in stop distributing packages), or 2) Reduce i686 to a secondary architecture. I want to see secondary architectures happen, so this would be a good start in that direction. We start by advertising for a team that is responsible for building and fixing i686 packages. At a certain point, the only change to our tooling is that developers upload x86_64 only, and the other team plays catchup (which should lead to autobuilding...) Allan
On 2017-01-09 04:26, Allan McRae wrote:
On 06/01/17 07:08, Bartłomiej Piotrowski wrote:
Friendly reminder what I'm going to push through if nobody opposes.
Can we have a detailed discussion what EOL for i686 means? I have seen a couple of proposals being:
1) We just kill i686 (as in stop distributing packages), or 2) Reduce i686 to a secondary architecture.
I want to see secondary architectures happen, so this would be a good start in that direction. We start by advertising for a team that is responsible for building and fixing i686 packages. At a certain point, the only change to our tooling is that developers upload x86_64 only, and the other team plays catchup (which should lead to autobuilding...)
Allan
I will write a news post draft proposing the latter this week. Bartłomiej
participants (19)
-
Allan McRae
-
Andreas Radke
-
Balló György
-
Bartłomiej Piotrowski
-
Connor Behan
-
Daniel Isenmann
-
Doug Newgard
-
Florian Pritz
-
Gaetan Bisson
-
Gerardo Exequiel Pozzi
-
Giancarlo Razzolini
-
Ike Devolder
-
Jan Alexander Steffens
-
jan＠jgc.homeip.net
-
Jelle van der Waa
-
Maxime Gauduin
-
NicoHood
-
Sébastien Luttringer
-
Tobias Powalowski