Re: [arch-dev-public] Bug tracker migration

[Ike Devolder via arch-dev-public]

On 30/08/2020 01:02, Frederik Schwan via arch-dev-public wrote:
> Hi folks,
> I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab 
> instance.
> 
> TLDR:
> - Bug wrangling day on the 13th of September; see 1)
> - Flyspray will be read-only after we rewrite the Archweb URLs
> - new bug tracker -> Gitlab
> 
> 
> 1) I'd like to hold a bug wrangling day, where our goal is to close as many 
> bugs as possible.
>Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately 
> I can't offer any cookies that day :/
>
>Rules:
>  a) Bug with no reply for at least 6 months which has been submitted for 
> a different version than the current one in 
> the repos shall be closed with a message that a reopen request may be 
> filled if this issue is still present.
>  b) Any infrastructure ticket shall not be touched. This will be handled 
> by $DevOps.
> 
> 2) Afterwards we will point the bug tracker links in the Archweb to the new 
> location and opening new tickets in Flyspray
>will be disabled. The project structure of the future Gitlab bug tracker 
> will be discussed in a seperate mail and
>is not part of this mail(thread).
> 
> 3) When enough tickets are closed or when $DevOps is tired enough of 
> Flyspray, we'll migrate the rest of the tickets to 
>Gitlab. We seek to keep Flyspray as a static homepage to allow the 
> reference in the new bug tracker to old tickets and
>to keep the integrity of search engine results.
> 
> Please make sure you all have a working account at our Gitlab instance.
> 
> Cheers,
> Frederik
> 
> 
> 
I like the idea of moving away from flyspray as a bugtracking system.
Why not first move the packages in gitlab so you can use the bugtracker
per package. That will give a proper corrolation and you even can link
tickets together if they were created for the wrong package. For
infrastructure and even more administrative ticketing you can just setup
a separate gitlab repo to do just that.

I don't think moving from flyspray 'community packages' bugtracker to a
gitlab 'community packages' bugtracker will be much of an improvement.

Greets,
Ike



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] HEADS UP: Qt 5.15 in [testing]

[Ike Devolder via arch-dev-public]

On Thu, May 28, 2020 at 10:05:58AM +0200, Antonio Rojas via arch-dev-public 
wrote:
> El jueves, 28 de mayo de 2020 10:01:23 (CEST), Ike Devolder via
> arch-dev-public escribió:
> > I have segfaults with multiple programs (keepassxc, quasselclient)
> > 
> 
> Please open bug reports and attach backtraces

All my issues were related to QT_QPA_PLATFORMTHEME=gtk2 the issues are
resolved by changing gtk2 to gtk3

FYI

-- 
Ike


signature.asc
Description: PGP signature

Re: [arch-dev-public] HEADS UP: Qt 5.15 in [testing]

[Ike Devolder via arch-dev-public]

On Tue, 2020-05-26 at 21:17 +0200, Antonio Rojas via arch-dev-public
wrote:
> The latest (and last) Qt 5 release is now in [testing]. This is the
> usual 
> reminder that any package compiled against it must stay in [testing]
> until 
> Qt itself moves.

I have segfaults with multiple programs (keepassxc, quasselclient)

Output of keepassxc:

```
keepassxc
QPainter::begin: Paint device returned engine == 0, type: 2
zsh: segmentation fault keepassxc
```

--Ike


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Killing Python 2 (v2)

[Ike Devolder via arch-dev-public]

On 2/01/2020 17:24, Eli Schwartz via arch-dev-public wrote:
> On 1/2/20 11:12 AM, Jelle van der Waa wrote:
> 
>> # Remove python2 support
>>
>> * pycharm-community-edition - remove python2 support
> 
> Seems reasonable to not encourage people to use python2 in an IDE these
> days.
> 
>> * vim - remove python2 support
> 
> Are there any stats on vim ecosystem plugins which use the python2
> binding? Including non-packaged plugins?
> 

You can safely remove python2 support from vim. The python2 support is
only needed for vim plugins using python2, python2 can be perfectly
linted by vim without python2-plugin support. *Most* plugins got forced
to support both python2 and 3 when ubuntu default vim came without
python2. So it should be fine and you can still install python2 from AUR
or whatever to do the proper linting.




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] bringing vivaldi browser to community

[Ike Devolder via arch-dev-public]

On Sat, 2019-06-01 at 12:12 +0200, Ike Devolder wrote:
> 3 years have passed since I first proposed to bring vivaldi into
> community. Now there is a clear differentiation between what vivaldi
> offers out-of-the box compared to other browsers.
> 
> Vivaldi offers a ton of customisation features out of the box, and is
> also able to just use the chrome/ium addons from the chrome webstore.
> 
> Personally I'm using vivaldi as my main browser since somewhere in
> 2015
> (shortly after the first beta was released) and the key features no
> other browser currently offers are:
> - webpanels
> - quick commands
> - tabtiling
> - tabstacking
> - tabbar positioning
> 
> I'll bring it in the same way as with opera, where you have the
> webbrowser + separate packge with libffmpeg.so to allow the playback
> of
> proprietary formats like mp4.

As stated by some on IRC I could just have dropped in the repos and be
done with it. No one would have complained I guess. But to be fair, I
personally think you have the right to know I want to maintain a
package for proprietary software. And if there is a consensus against
it I will definatly not package the proprietary stoftware in our repos.

And thanks to the constructive input I will make sure it is obvious we
have the rights for redistribution. That was also mostly my goal, get
input if I'm missing something or overlooked something before bringing
it in.


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] bringing vivaldi browser to community

[Ike Devolder via arch-dev-public]

On Sat, 2019-06-01 at 22:11 -0400, Eli Schwartz via arch-dev-public
wrote:
> On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
> > On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
> > > On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
> > > > You don't seem to
> > > > explain why you need to ask in your email.
> > > 
> > > Because it is proprietary and I explain that now there is a valid
> > > reason compared to 3 years ago where there was practically no
> > > difference between vivaldi, chromium and opera.
> > > 
> > 
> > Does the license allow us to have it in the repos?  After a quick
> > look,
> > I'd say no.
> 
> The license for the AUR package appears to be somehow extracted using
> /usr/bin/strings from one of the binary files in the software
> download.
> 
> Assuming it's the same as the one here:
> https://vivaldi.com/privacy/vivaldi-end-user-license-agreement/
> 
> It's absolutely illegal to redistribute it. As per the pinned comment
> on
> the AUR package, it is also available and illegally redistributed as
> a
> repackaged pacman package here: https://repo.herecura.eu/
> This should probably be removed too.
> 
> Note: there are other proprietary packages shipped in the Arch repos,
> but on the unusual occasion where we deem it fitting to provide such
> software, we have written authorization from the rights-holders to do
> so.
> As far as I can tell, that is not the case here. If and when it is
> the
> case here, that permission can be added to the
> /usr/share/licenses/${pkgname}/ directory of the vivaldi package in
> the
> AUR, to signify that the prebuilt packages are legally
> redistributable,
> either in personally hosted repos or [community].
> 
> See the teamspeak3 package for an example implementation.
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION.eml?h=packages/teamspeak3
> 
> ...
> 
> Just because we are not an FSDG distribution which prays at the altar
> of
> Richard Stallman doesn't mean licensing is some sort of silly joke
> that
> no one cares about.
> 
> And I don't think it makes sense to say this matters less, if it's
> being
> distributed from someone's personal repo instead of from a multi-
> member
> organization.
> 

If that's what it requires, I can get a written consent we can re-
distribute vivaldi. I asked them before putting it in my personal repo,
if I was allowed to do that.


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] bringing vivaldi browser to community

[Ike Devolder via arch-dev-public]

On Sat, 2019-06-01 at 18:06 +0200, Andreas Radke via arch-dev-public
wrote:
> Am Sat, 01 Jun 2019 17:53:58 +0200
> schrieb Ike Devolder via arch-dev-public
> :
> 
> > On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
> > > You don't seem to
> > > explain why you need to ask in your email.  
> > 
> > Because it is proprietary and I explain that now there is a valid
> > reason compared to 3 years ago where there was practically no
> > difference between vivaldi, chromium and opera.
> 
> Crap. There's no reason to support any closed browser at all. We are
> still an Open Source Linux distribution. Sure we have a relaxed
> policy
> adding closed source packages and blobs wherever needed to support
> hardware.
> 
> But there's no reason to support spying tools like closed source
> browsers!
> 
> -Andy

I understand your sentiment, but just being harsh does not contribute
to a solution.

To be honest, our beloved "open source" browsers are far from holy in
terms of data collection. I don't think we should try to be holier than
the pope here.

And also note there is genuine requests from users to add it to the
official repos.

Also, I'm just trying to be nice here about adding something
proprietary. Instead of just dropping it in the repo's an be done with
it.

And I'm still convinced that Vivaldi offers more unique features that
are very usefull compared to what we ship now in terms of web browsers.

But if most of the Arch Linux group is against adding it, I will honor
that.


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] bringing vivaldi browser to community

[Ike Devolder via arch-dev-public]

On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
> You don't seem to
> explain why you need to ask in your email.

Because it is proprietary and I explain that now there is a valid
reason compared to 3 years ago where there was practically no
difference between vivaldi, chromium and opera.


signature.asc
Description: This is a digitally signed message part

[arch-dev-public] bringing vivaldi browser to community

[Ike Devolder via arch-dev-public]

3 years have passed since I first proposed to bring vivaldi into
community. Now there is a clear differentiation between what vivaldi
offers out-of-the box compared to other browsers.

Vivaldi offers a ton of customisation features out of the box, and is
also able to just use the chrome/ium addons from the chrome webstore.

Personally I'm using vivaldi as my main browser since somewhere in 2015
(shortly after the first beta was released) and the key features no
other browser currently offers are:
- webpanels
- quick commands
- tabtiling
- tabstacking
- tabbar positioning

I'll bring it in the same way as with opera, where you have the
webbrowser + separate packge with libffmpeg.so to allow the playback of
proprietary formats like mp4.


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] Mkinitcpio replacement with Dracut

[Ike Devolder via arch-dev-public]

On 21/05/2019 04:41, Giancarlo Razzolini via arch-dev-public wrote:
> Hi All,
> 
> Recently, Dave announced his intention to step down as mkinitcpio
> maintainer. I have been
> handling a few things on it, made some small changes to our
> mkinitcpio-busybox [0], closed a few old
> bugs, while also made sure some of the other bug reports are still
> valid. [1]
> 
> I have been testing a few patches to mkinitcpio for a while to fix those
> bugs, but last week Dave
> and I had a discussion on IRC and we agreed that we could spend better
> time contributing somewhere
> else than keeping working with mkinitcpio.
> 
> Currently mkinitcpio cannot boot from NFS properly, mknitcpio-nfs-utils
> [2] uses very old code. Even
> though ipconfig works, it has several drawbacks compared to using more
> modern tools. Not to mention that
> we have two use cases for mkinitcpio, which are base and systemd enabled
> initramfs. Even though we use
> by default our base enabled initramfs, we have to support systemd
> related issues and we have to keep
> developing our systemd hooks.
> 
> I have been looking into dracut for some time now, I copied some stuff
> from them on a few of my own
> scripts and they also have an actual test suite, that we currently can't
> use on Arch, but I plan to
> change that.
> 
> With this in mind, I have packaged dracut for Arch and put it on Extra
> [3]. I have been using a dracut
> initramfs for a while now to boot my encrypted partition. Surprisingly,
> I only had to create a small patch
> to one of the dm-crypt module scripts [4]
> 
> In this initial phase I want to ask as many of you to test this as a
> replacement to mkinitcpio in your setups,
> as many as possible, and in as many scenarios as possible. We will
> probably have to keep both packages on
> our repos for a long time, but once we are confident it's a good fit, we
> can replace mkinitcpio on our iso and base,
> so new installs get dracut by default.
> 
> Please, drop in your comments as well.
> 
> Regards,
> Giancarlo Razzolini
> 
> [0]
> https://git.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/mkinitcpio-busybox=489fbd6f2ed1defd1c7f1b57e7d6edd25185e6d8
> 
> [1] https://bugs.archlinux.org/index.php?string=mkinitcpio=0
> [2] https://git.archlinux.org/mkinitcpio-nfs-utils.git/
> [3] https://www.archlinux.org/packages/extra/x86_64/dracut/
> [4]
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/0001-90crypt-Change-the-module-setup.sh-to-use-uname-r-in.patch?h=packages/dracut
> 

Without looking at dracut yet, I have a few questions:
- Is there a description how to move from mkinitcpio to dracut?
- Does dracut support what mkinitcpio has? all the hooks and stuff
- did you already add pacman hooks for dracut as we need for mkinitcpio,
or is that not needed?

When I have some time to spare I certainly will try it out.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] FOSDEM 2019

[Ike Devolder via arch-dev-public]

On Sun, 2019-01-06 at 13:09 +0100, Morten Linderud via arch-dev-public
wrote:
> Yo!
> 
> Last year at FOSDEM we where quite a few members from the Arch team
> present, and
> I though it would be nice to have a dinner together! My suggestion is
> to do it
> Friday around 18:00 then head for the beer event at delirium
> afterwards.
> 
> To make it managable I'll cap the attendees to 15 people. Priority
> for members
> of the Arch team (developers, trusted users and support staff) and
> any free spots
> after this can be taken by anyone interested :) Please send an email
> so I have
> some ability to keep track.
> 
> If Friday does not fit for some people in the team, please write if
> saturday or
> sunday fits better. If multiple people arrive super late we could
> move things
> around, or have multiple dinners!
> 
> Restaurant suggestions are also welcome!
> 
> 
> (I have CC'ed arch-dev-public since I don't actually know how many
> people watch
> arch-events. Sorry for the noise!)
> 

I'll only be at FOSDEM at saturday. I can't make it on friday.
Saturday I'm speaking in the PHP and Friends room, so if there is a
meet on saturday I could make it there.


signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] libnfs 3.0.0

[Ike Devolder via arch-dev-public]

On Tue, 2018-07-03 at 18:42 +0200, Ike Devolder wrote:
> I've created a todo list for libnfs.
> 
> I'll post a followup when libnfs and kodi are in staging. I had them
> rebuild against community/extra but will rebuild with staging to be
> sure.
> 
> --Ike

https://www.archlinux.org/todo/libnfs-rebuilds/

libnfs 3.0.0 is in community staging. When all rebuilds are done it
would be cool if someone with [extra] powers could move all of them to
testing :)

-- Ike

signature.asc
Description: This is a digitally signed message part

[arch-dev-public] libnfs 3.0.0

[Ike Devolder via arch-dev-public]

I've created a todo list for libnfs.

I'll post a followup when libnfs and kodi are in staging. I had them
rebuild against community/extra but will rebuild with staging to be
sure.

--Ike

Re: [arch-dev-public] 2017 repository cleanup

[Ike Devolder via arch-dev-public]

On Sun, Jan 07, 2018 at 07:16:39PM +0100, Bartłomiej Piotrowski via 
arch-dev-public wrote:
> Hi team,
> 
> I've finished moving unneeded orphans to AUR. The only exceptions that
> were simply removed are nvidia-304xx family (EOL'ed upstream) and
> nautilus-open-terminal (seems to be built into nautilus these days).
> 
> You can find the list of (re)moved packages here[1]. Let's try not to
> make such a mess this time!
> 
> Bartłomiej
> 
> [1] https://paste.xinu.at/VjGQ/

Thanks for the effort!

-- 
Ike

Re: [arch-dev-public] Phasing out cwiid

[Ike Devolder via arch-dev-public]

On 28-12-17 10:34, David Runge wrote:
> 
> Now waiting on Ike Devolder to get back to me on the topic of kodi.
> 
> Best,
> David
> 
> 

It's removed since 17.6-2 in community so you can just remove cwiid if
you want.

Ike




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] 2017 repository cleanup

[Ike Devolder via arch-dev-public]

On 18-12-17 10:54, Bartłomiej Piotrowski via arch-dev-public wrote:
> 
> Please look at both lists and adopt what your packages are using or
> you're personally interested in. I will drop whatever makes sense in
> January.
> 

If you could move the following to community I can keep it there:
- libftdi-compat

others:
- lazarus-gtk2
- lazarus-qt

Those are part of lazarus split package, which are now changed to
- lazarus
- lazarus-gtk2
- lazarus-qt4
- lazarus-qt5

I saw, fpc-src was also orphaned so I picked thatone up since its needed
for lazarus and doublecmd

Adopted:

- atop
- qcad




signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] 2017 repository cleanup

[Ike Devolder via arch-dev-public]

On Mon, Dec 18, 2017 at 10:54:37AM +0100, Bartłomiej Piotrowski via 
arch-dev-public wrote:
> Hi team,
> 
> Recently I've spent a bit of time on the train so I spent that on
> writing a script (of questionable quality) for generating packages
> cleanup list. The main difference from the "unneeded orphans" report is
> that it also includes orphans that require only other orphans and
> additionally generates possible maintainers for required but
> unmaintained packages.
> 
> The script can be found here[1] and I will probably improve it a bit on
> the next journey.
> 
> Note that it doesn't consider optdepends when checking if orphan is
> needed only by other orphans. Max. 3 packages requiring given orphan are
> listed next to possible maintainer. It also ignores repo hierarchy
> because it's just a theater these days.
> 
> Please look at both lists and adopt what your packages are using or
> you're personally interested in. I will drop whatever makes sense in
> January.
> 
> Bartłomiej
> 

Thanks.

I forgot to adopt lazarus. The rest of the list I still have to check.

-- 
Ike


signature.asc
Description: PGP signature

[arch-dev-public] closure-linter, closure-compiler

[Ike Devolder via arch-dev-public]

I just disowned closure-linter and closure-compiler. I no longer use
these and have no more interest to just bump versions for the sake of
bumping the version without proper testing.

If someone is interested feel free to adopt. When no-one adopts within a
few weeks I'll move it to AUR.

-- 
Ike


signature.asc
Description: PGP signature

[arch-dev-public] Anyone interested in mythtv

[Ike Devolder via arch-dev-public]

I'm currently maintaining mythtv, I was going to use mythtv but never got to 
it. If no-one is interested I probably shoul move it to AUR.

-- 
Ike

signature.asc
Description: This is a digitally signed message part.

Re: [arch-dev-public] Kernel 4.11 status

[Ike Devolder via arch-dev-public]

On Wed, May 10, 2017 at 10:04:03PM +0200, Jelle van der Waa wrote:
> On 05/05/17 at 06:58am, Jan Alexander Steffens via arch-dev-public wrote:
> > On Fri, May 5, 2017 at 8:29 AM Tobias Powalowski via arch-dev-public <
> > arch-dev-public@archlinux.org> wrote:
> > 
> > > Problematic with 4.11, license needs to be patched I don't think this is
> > > legal.
> > > http://rglinuxtech.com/?p=1935
> > 
> > 
> > We could patch the kernel to make the needed symbols non-GPL instead. That
> > at least sounds less problematic (IANAL).
> 
> There is a patch for 4.12 to undo the change from GregKH. [1]
> 
> [1] 
> https://github.com/torvalds/linux/commit/d557d1b58b3546bab2c5bc2d624c5709840e6b10.patch
> 
> -- 
> Jelle van der Waa

That patch is in the queue for 4.11.1 too, so once 4.11.1 lands the
nvidia driver should build as expected. I'm going to test later today if
everything builds fine with this patch applied.

-- 
Ike


signature.asc
Description: PGP signature

Re: [arch-dev-public] Shadowing i686, round 1

[Ike Devolder via arch-dev-public]

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


signature.asc
Description: PGP signature

Re: [arch-dev-public] i686 and SSE2

[Ike Devolder via arch-dev-public]

On Mon, Sep 19, 2016 at 07:38:09PM +0200, Ike Devolder wrote:
> > 
> > If we limit our choice based on your CPU, then we need to limit based on
> > the other CPU mentioned in this thread.
> > 
> > That should not be a consideration at all. What we need to do is think
> > about what make our distribution worthy of being a distribution.
> > Original the selling points were rolling release, vanilla packages and
> > optimised binaries.  We have lost the latter.  Do we want to get it back?
> > 
> > Allan
> 
> Yes we want it back. I also have systems without SSE4 and if Arch is no
> longer usable on those I'll use distributions for 'older' hardware on
> those.
> 
> But for our day-to-day workhorses I would love optimized binaries.
> 
> -- 
> Ike

Someone mentioned AVX2, but it seems there is still a patch needed for
glibc. Solus added it very recently https://dev.solus-project.com/T503
and they have taken it from Clear Linux.

-- 
Ike


signature.asc
Description: PGP signature

Re: [arch-dev-public] i686 and SSE2

[Ike Devolder via arch-dev-public]

On Mon, Sep 19, 2016 at 11:34:07PM +1000, Allan McRae wrote:
> On 19/09/16 23:14, Balló György via arch-dev-public wrote:
> > 2016-09-19 7:02 GMT+02:00 Allan McRae :
> > 
> >> This goes beyond just adding SSE2 support.
> >>
> >> Years ago, Arch Linux was "optimised for modern processors".  These were
> >> the days when every other distro was using i386 and we had a blazingly
> >> fast i686 port.  Now every other distro uses i686 while we have sat
> >> still.  Even major software developments are starting to require SSE2.
> >> It is time we moved forward.
> >>
> >> How can we achieve this?  I see several options:
> >>
> >> 1) Do "nothing".  Add a hook to the filesystem package that detects
> >> whether a system has SSE2 support and blocks installation of certain
> >> packages.
> >>
> >> 2) Add SSE2 to our optimisations and require "i686 + SSE2"
> >>
> >> 3) Move our minimum CPU to something less than 20 years old  (even i786
> >> would get us SSE2+3 instructions and is 15 years old)
> >>
> >> 4) We add more modern CPU builds  (and set them automatically building
> >> once the base architecture is updated).
> >>
> >>
> >> I am in favour of #3 for our 32-bit support.  And that would be end of
> >> line as far as 32 bit support in this distribution goes.
> >>
> >>
> >> (We may want to consider #4 for our x86_64, but that is another
> >> conversation).
> >>
> >> Allan
> >>
> > 
> > 
> > I would not be happy with #3, because I still have two 13 years old systems
> > with NetBurst-based CPUs without SSE3 support. But of course I don't use
> > them in everyday use.
> > 
> 
> If we limit our choice based on your CPU, then we need to limit based on
> the other CPU mentioned in this thread.
> 
> That should not be a consideration at all. What we need to do is think
> about what make our distribution worthy of being a distribution.
> Original the selling points were rolling release, vanilla packages and
> optimised binaries.  We have lost the latter.  Do we want to get it back?
> 
> Allan

Yes we want it back. I also have systems without SSE4 and if Arch is no
longer usable on those I'll use distributions for 'older' hardware on
those.

But for our day-to-day workhorses I would love optimized binaries.

-- 
Ike


signature.asc
Description: PGP signature