[arch-dev-public] Proposal to remove PyGTK

[Balló György via arch-dev-public]

Hi all,

I would propose to remove PyGTK from the official repositories. PyGTK
was used to create GTK2 applications in python2. It's deprecated and
unmaintained since 2011 in favor of PyGObject, and does not receive any
fixes since then. 


The following packages are in progress to be ported from PyGTK to
PyGObject, but not released yet:

- diffuse: a fork with python3 support is in progress: 
https://github.com/MightyCreak/diffuse

- gimp: GTK3/python3 port is very slow, python extensions support can
be disabled with the --disable-python switch

- ibus-sunpinyin: python3 port was merged

- mcomix: a fork with python3 support is available: 
https://github.com/multiSnow/mcomix3

- nmap: python3 port of ndiff is available, zenmap is not ported yet
(can be disabled with --without-ndiff --without-zenmap switches): 
https://github.com/nmap/nmap/pull/1807

- nicotine+: python3 port is in progress: 
https://github.com/Nicotine-Plus/nicotine-plus/pull/106


The following packages were not ported yet and have inactive upstream:

- gutenpy: last released in 2006

- ibus-googlepinyin: last released in 2012

- pyneighborhood: last released in 2011

- wifi-radar: last released in 2015


Any objections?

--
György Balló
Trusted User


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

Re: [arch-dev-public] Spring cleaning (take 2)

[Balló György via arch-dev-public]

Antonio Rojas via arch-dev-public  ezt írta
(időpont: 2019. márc. 27., Sze, 17:19):

> bluefish
>

I would adopt 'bluefish'.

--
György Balló
Trusted User

Re: [arch-dev-public] rename lcms -> lcms1

[Balló György via arch-dev-public]

 ezt írta (időpont: 2018. szept. 17., H, 10:19):

> Christian Hesse schreef op 2018-09-14 21:18:
> > Hello everybody,
> >
> > we have packages lcms (which provides lcms 1.x) and lcms2. The former
> > is
> > flagged out-of-date every now and then for version 2.x... I would like
> > to
> > rename the package to lcms1 with replace and provide for lcms. Any
> > concerns?
>
> I don't think we should rename. Kill the package instead. The software
> is unmaintained upstream and probably several security issues exist.
>
> Most packages that still depend on lcms1 can be changed to lcms2 without
> patches. For packages that need patches, Debian has those and otherwise
> we should just remove the software together with lcms1.
>

+1 for removing lcms1. I fixed the packages in the [community] repository.
Someone else should fix packages in [extra], because I don't have access to
this repository:
- geeqie (FS#60091)
- gimp (FS#60092)
- xsane (FS#60090)

--
György Balló
Trusted User

[arch-dev-public] Request to orphan Snowman's packages

[Balló György via arch-dev-public]

Eric Bélanger (Snowman) was inactive as package maintainer in the past
two years. [1][2] Is it possible to disown his packages on archweb? I
think it would better to make it visible that his packages are actually
orphan.

https://git.archlinux.org/svntogit/packages.git/log/?qt=author=eric
https://git.archlinux.org/svntogit/community.git/log/?qt=author=eric

--
György Balló
Trusted User


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

[arch-dev-public] Proposal to remove libglade

[Balló György via arch-dev-public]

Hi all,

Similar to my previous mail, I orphaned some of my packages which have
a dependency on libglade. Libglade is deprecated in favor of GtkBuilder
since 2009, [1] and does not receive any fixes since then. I would
propose to remove it from the official repositories.

The following packages were ported from libglade to GtkBuilder, but not
released yet:
- deluge (via pygtk.glade, only the GUI part)
- gespeaker (via pygtk.glade)
- obconf
- ogmrip

The following packages were not ported yet, and most of them have
inactive upstream:
- agave (via libglademm)
- bless (via glade-sharp)
- foxtrotgps
- fyre
- gnome-hearts
- gnome-schedule (via pygtk.glade)
- gsql
- keepnote (via pygtk.glade)
- labyrinth (via pygtk.glade)
- lat (via glade-sharp)
- mono-tools (via glade-sharp)
- muine (via glade-sharp)
- netactview
- obmenu (via pygtk.glade)
- planner
- pympd (via pygtk.glade)
- python2-matplotlib (via pygtk.glade, only the GTKAgg and GTKCairo
backends, which were already removed from git master)
- rox-lib (via pygtk.glade)
- scribes (via pygtk.glade)
- smuxi (via glade-sharp)
- tuna (via pygtk.glade, only the GUI part)
- vmoviedb
- xournal (via libgnomecanvas)
- xscreensaver (only the xscreensaver-demo GUI)

After the above packages were fixed or removed, libglade support can be
disabled in the following packages:
- gtk-sharp-2
- pygtk

After that libglade and related packages can be removed:
- glade-perl
- gnet
- lib32-libglade
- libart-lgpl
- libglade
- libglademm
- libgnomecanvas

Any objections?


[1] 
https://mail.gnome.org/archives/devel-announce-list/2009-May/msg3.html

--
György Balló
Trusted User


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

[arch-dev-public] Proposal to remove GConf

[Balló György via arch-dev-public]

Hi all,

Recently I orphaned some of my packages which have a dependency on
gconf. GConf was used in GNOME 2 as the settings storage daemon. It's
deprecated since 2010 in favor of GSettings, and does not receive any
fixes since 2013. I would propose to remove it from the official
repositories.

The following packages are fully functional without GConf:
- aisleriot (FS#6)
- brasero (FS#59978)
- emacs (FS#59887)
- firefox-developer-edition
- firefox (FS#59992)
- gnome-terminal (FS#59980)
- ibus (requires gsettings-schema-convert during build if the dconf
module is enabled)
- qcef (libcef must be built from sources to disable gconf usage)
- steam-native-runtime (FS#60036)
- thunderbird (FS#59993)

The following packages were ported from GConf to GSettings, but not
released yet:
- ekiga
- ogmrip

The following packages were not ported yet and have inactive upstream:
- alleyoop
- apcupsd (only the GUI part)
- billreminder
- ccgo
- docky
- gnome-alsamixer
- gnome-do
- gnome-schedule
- gsql
- hamster-time-tracker
- muine
- planner
- tomboy
- vmoviedb

After the above packages were fixed or removed, GConf and related
packages can be removed too:
- gconf
- gconf-editor
- gconfmm
- gconf-sharp
- lib32-gconf
- python2-gconf

Any objections?


--
György Balló
Trusted User


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

Re: [arch-dev-public] Package group between repositories

[Balló György via arch-dev-public]

Then if it's okay, I would like to add the following [community] packages
to groups based on upstream sources:
- gnome-boxes (gnome)
- gnome-multi-writer (gnome-extra)
- gnome-recipes (gnome-extra)
- gnome-software (gnome)
- parole (xfce4-goodies)
- simple-scan (gnome)

--
György Balló
Trusted User

[arch-dev-public] Package group between repositories

[Balló György via arch-dev-public]

Currently the 'xfce4-goodies' package group[1] is in split between [extra]
and [community]. Most of its packages are in [extra], but 'ristretto' and
'xfce4-whiskermenu-plugin' are in [community].

My question is: is it okay, or should we avoid it by removing these two
packages from the 'xfce4-goodies' group or moving them to [extra]?

[1] https://www.archlinux.org/groups/x86_64/xfce4-goodies/

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

2018-01-04 12:32 GMT+01:00 Bartłomiej Piotrowski via arch-dev-public <
arch-dev-public@archlinux.org>:

> On 2018-01-04 12:17, Balló György via arch-dev-public wrote:
> > The following packages should be kept too:
> > - dvdauthor
> > arojas: kdenlive
> > fyan: kdenlive
> > heftig: brasero
> > jgc: brasero
>
> The only two packages that really require it are unneeded orphans, so I
> don't see the point.
>

Now I adopted devede, so I need dvdauthor, but it's in [extra], so I can't
adopt it.

> - sofia-sip
> > heftig: empathy
>
> Ditto. There is nothing special about unmaintained optdepends that are
> providing completely optional functionality.
>

In this case the telepathy-rakia optional dependency should be removed from
empathy first, and then the telepathy-rakia and sofia-sip packages can be
dropped. But I think it would better to keep the whole 'telepathy' group in
the official repositories even if some of these packages are orphans.

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

I adopted the packages below. I'm not sure that I want to maintain all of
them for a long time, so if anyone want to take over a package, please let
me know.
- bless
- codeblocks
- converseen
- cpulimit
- cuneiform
- devede
- driconf
- frei0r-plugins
- gmtk
- gnome-icon-theme-extras
- gnome-mplayer
- gnubiff
- gocr
- goocanvas
- gpsbabel
- gramps
- grsync
- gsql
- gst-editing-services
- gst-transcoder
- guvcview
- keybinder2 (libkeybinder2, python2-keybinder2)
- lat
- libgovirt
- lxrandr (lxrandr, lxrandr-gtk3)
- medit
- mypaint
- obconf-qt
- ocrad
- parole
- pavucontrol-qt
- pitivi
- pyrtf (will be renamed to python2-pyrtf)
- python-bsddb (python-bsddb, python2-bsddb)
- python2-lcms
- python2-telepathy
- sk1
- spice-glib
- spice-gtk3
- tvtime
- vmoviedb
- wmctrl
- workrave
- xchm
- xpad

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

The following packages should be kept too:
- dvdauthor
arojas: kdenlive
fyan: kdenlive
heftig: brasero
jgc: brasero
- libhx
arojas: pam_mount
- sofia-sip
heftig: empathy

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

Please move the following packages from [extra] to [community], so I can
adopt them:
- gnome-icon-theme-extras
- libgovirt
- python2-telepathy

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

Please don't remove anything yet. I'll adopt some packages in the next 24
hours.

You missed some optional and indirect dependencies. We should keep the
following packages:

- bbdb
spupykin: wanderlust
- btchip-udev
shibumi: electrum
- bwidget
andyrtr: libisoburn
- emovix
arojas: k3b
eric: k3b
- gavl
arojas: mlt
bluewind: openshot
heftig: gnome-video-effects
- gtk-engine-murrine
alucryd: adapta-gtk-theme, numix-gtk-theme
fyan: deepin-gtk-theme
NicoHood: arc-gtk-theme
- gtk2+extra
anthraxx: gpsim
- id3
schuay: abcde
- libopenshot-audio
bluewind: openshot
- libquicktime
arojas: kdenlive
fyan: kdenlive
bluewind: openshot
- mp3gain
schuay: abcde
stativ: soundkonverter
- normalize
jlichtblau: bashburn
- openocd
anatolik: arm-none-eabi-gdb
- perl-anyevent-i3
anthraxx: i3-wm
Foxboron: i3-gaps
jelle: i3-wm
- poco
svenstaro: ogre
- pstotext
spupykin: recoll
- python-btchip
shibumi: electrum
- python2-flup
fyan: python2-paste, python2-webpy, python-paste
- python2-mysql2pgsql
spupykin: dbmail
- speakup-utils
stativ: klavaro
- tcllib
lfleischer: remind
- telepathy-rakia
heftig: empathy
- tix
remy: asymptote
- uniconvertor
bisson: inkscape
arodseth: python2-rst2pdf
- vice
foutrelis: audacious-plugins
jlichtblau: qmmp
- wpa_supplicant_gui
bpiotrowski: wpa_supplicant

--
György Balló
Trusted User

[arch-dev-public] Drop sqlite2 and webkitgtk{,2}

[Balló György via arch-dev-public]

Hi all,

I think we can drop sqlite2 and webkitgtk{,2} from the official
repositories now.

sqlite2 was replaced by sqlite 3. The last application which still use it
is Freevo, which was last released in 2009, and is currently unmaintained.

webkitgtk{,2} has many CVEs[1][2], and was replaced by webkit2gtk. The last
application which still use it is GNUCash, which is still maintained by
upstream, but unlikely to get ported to gtk3 soon, porting is not started
yet.[3]

Packages to be removed:
- freevo
- gambas3-gb-db-sqlite2
- gnucash
- goffice0.8
- kaa-imlib2
- python2-beautifulsoup3
- python2-pysqlite-legacy
- sqlite2
- webkitgtk
- webkitgtk2

Packages that need to be rebuilt:
- gambas3
- libdbi-drivers
- python-lxml
- wxgtk (already in testing)
- wxpython (already in community-testing)

Is there any objections?

[1] https://security.archlinux.org/AVG-171
[2] https://security.archlinux.org/AVG-234
[3] https://bugzilla.gnome.org/show_bug.cgi?id=751635

--
György Balló
Trusted User

Re: [arch-dev-public] Phasing out gstreamer0.10

[Balló György via arch-dev-public]

Thanks for everyone who participated to eliminate GStreamer 0.10 and old
GNOME libraries! Especially to Jan de Groot, who did a very good job. TODOs
are finished now.

Finally, we had to remove only a small number of applications:
arista
cycle
drivel
flumotion
gcdmaster
gnome-commander
grip
gtetrinet
perlpanel
psimedia
shutter
xfce4-mixer

If anyone needs these applications, I encourage him/her to contribute to
the upstream projects, and help porting them to newer libraries.

--
György Balló

Re: [arch-dev-public] News draft for i686 deprecation

[Balló György via arch-dev-public]

2017-01-23 22:09 GMT+01:00 Bartłomiej Piotrowski 
:

> What I infer from my conversation with Allan is that
> neither of us is interested in leading this personally. Will you take on
> this role?
>

I'm not sure about that, but I would like to keep i686 alive. I have some
ideas and plans about secondary architectures and automated builds, and I
want to work on implementing this, but it needs a team and an
infrastructure.

--
György Balló
Trusted User

Re: [arch-dev-public] News draft for i686 deprecation

[Balló György via arch-dev-public]

2017-01-23 15:58 GMT+01:00 Bartłomiej Piotrowski 
:

> However, as there is still some interest in keeping i686 alive, we would
> like to encourage the community to make it happen with our guidance.
> Depending on the demand, an official channel and mailing list will be
> created for second tier architectures.
>

Please put an e-mail address here, where potential contributors could send
their applications. Or even create a mailing list for that before
publishing this news.

--
György Balló
Trusted User

[arch-dev-public] Dropping udisks 1

[Balló György via arch-dev-public]

Following our series on dropping packages, I think we don't need udisks 1
anymore. Most of the applications are ported to udisks2, and currently
udisks is just an optional dependency for some other packages.

If no one oppose, I'll remove udisks from optional dependencies of the
following packages in the next days:
- calibre
- kodi
- pcmanfm
- pcmanfm-gtk3
- pcmanfm-qt
- sensors-applet
- udiskie
- libfm

--
György Balló
Trusted User

[arch-dev-public] Phasing out gstreamer0.10

[Balló György via arch-dev-public]

Beside to WebkitGTK+, GStreamer 0.10 is unmaintained too. [1] The last
release was in 2012. Most of the applications are already ported to
GStreamer 1. The last major user is wxGTK, but an upstream patch is
available for GStreamer 1 support. [2]

Currently the following packages depending on GStreamer 0.10:

gstreamer0.10
├─gstreamer0.10-base
│ ├─farstream-0.1
│ ├─gstreamer0.10-bad
│ │ └─gstreamer0.10-bad-plugins
│ │   ├─deepin-music
│ │   └─farstream-0.1
│ ├─gstreamer0.10-base-plugins
│ │ ├─flumotion
│ │ ├─gcompris
│ │ ├─morituri
│ │ └─xfce4-mixer
│ ├─gstreamer0.10-ffmpeg
│ │ └─farstream-0.1
│ ├─gstreamer0.10-good
│ │ ├─gstreamer0.10-good-plugins
│ │ │ ├─deepin-music
│ │ │ ├─farstream-0.1
│ │ │ ├─flumotion
│ │ │ ├─psimedia
│ │ │ └─soundconverter
│ │ └─whaawmp
│ ├─gstreamer0.10-mm
│ ├─gstreamer0.10-python
│ │ ├─arista
│ │ ├─deepin-music
│ │ ├─flumotion
│ │ ├─morituri
│ │ ├─soundconverter
│ │ └─whaawmp
│ ├─gstreamer0.10-ugly
│ │ └─gstreamer0.10-ugly-plugins
│ │   ├─deepin-music
│ │   └─soundconverter
│ ├─morituri
│ ├─perl-gstreamer-interfaces
│ ├─psimedia
│ ├─wxgtk
│ │ ├─0ad
│ │ ├─aegisub
│ │ ├─audacity
│ │ ├─boinc
│ │ ├─dolphin-emu
│ │ ├─erlang
│ │ │ ├─couchdb
│ │ │ ├─ejabberd
│ │ │ ├─elixir
│ │ │ ├─erlang-cl
│ │ │ │ └─wings3d
│ │ │ ├─erlang-sdl
│ │ │ │ └─wings3d
│ │ │ ├─erlang-unixodbc
│ │ │ │ └─ejabberd
│ │ │ ├─rabbitmq
│ │ │ ├─rebar
│ │ │ ├─wings3d
│ │ │ └─yaws
│ │ ├─filezilla
│ │ ├─gnuplot
│ │ │ ├─python-gnuplot
│ │ │ └─python2-gnuplot
│ │ ├─hugin
│ │ ├─kicad
│ │ ├─lib32-wxgtk
│ │ │ └─pcsx2
│ │ ├─mediainfo-gui
│ │ ├─megaglest
│ │ ├─moneymanagerex
│ │ ├─poedit
│ │ ├─scummvm-tools
│ │ ├─springlobby
│ │ ├─vbam-wx
│ │ ├─veracrypt
│ │ ├─wxcam
│ │ ├─wxmaxima
│ │ ├─wxpython
│ │ │ ├─displaycal
│ │ │ ├─gnuradio-companion
│ │ │ ├─kicad
│ │ │ ├─playonlinux
│ │ │ ├─sk1
│ │ │ ├─wammu
│ │ │ └─wxpython2.8
│ │ │   ├─cycle
│ │ │   └─mayavi
│ │ └─wxsqlite3
│ └─wxgtk2.8
│   ├─amule
│   ├─codeblocks
│   ├─lib32-wxgtk2.8
│   ├─pgadmin3
│   ├─rapidsvn
│   ├─scorched3d
│   ├─truecrypt
│   ├─wxpython2.8
│   └─xchm
└─perl-gstreamer
  └─perl-gstreamer-interfaces

I think we could try to get rid from gstreamer0.10, so I propose to make a
TODO for these packages, similar to webkitgtk:
   - If it can be updated to GStreamer 1, do so.
   - Otherwise, if GStreamer is an optional dependency, build without it.
   - Otherwise, consider removing the package.

What do you think?

[1]
https://lists.freedesktop.org/archives/gstreamer-announce/2013-March/000273.html
[2] https://github.com/wxWidgets/wxWidgets/pull/225

--
György Balló
Trusted User

Re: [arch-dev-public] Phasing out webkitgtk{,2}

[Balló György via arch-dev-public]

2017-01-18 23:42 GMT+01:00 Jan Alexander Steffens via arch-dev-public <
arch-dev-public@archlinux.org>:

> To protect our users we should try to limit the packages using
> webkitgtk(2)., with the goal of eventually getting rid of it completely. I
> propose making a TODO that covers all these packages, with the following
> policy:
>
>- If it can be updated to webkit2gtk, do so.
>- Otherwise, if WebKit is an optional dependency, build without it.
>- Otherwise, consider removing the package, especially if it's a
> browser.
>
> Thoughts?
>

+1

I think we should drop every applications that use WebkitGTK+ to render
HTML content from insecure sources (e.g. allow to load web pages or open
any local HTML files). If an application loads some internal HTML content
only, and there is no alternative renderer, then it's okay to keep it.

We should consider the same thing for qtwebkit, which is unmaintained too,
but it affects much more packages.

About my packages:

- blam, gnome-web-photo, screenlets, screenlets-pack-basic: these are
unmaintained by upstream a long time ago, therefore I'll drop them.

- sparkleshare, webkitgtk-sharp: git master uses webkit2gtk (trough
webkit2-sharp), so I'll update sparkleshare, and drop webkitgtk-sharp.

- pywebkitgtk: I'll orphan this package, still used by others.

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

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

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

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

[Balló György via arch-dev-public]

-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

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

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

[Balló György via arch-dev-public]

2016-09-19 15:34 GMT+02:00 Allan McRae <al...@archlinux.org>:

> On 19/09/16 23:14, Balló György via arch-dev-public wrote:
> > 2016-09-19 7:02 GMT+02:00 Allan McRae <al...@archlinux.org>:
> >
> >> 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?
>

Another option could be to keep i686 and x86_64 as is, and introduce new
architectures with automatically built optimised packages for i686 + SSE2
or SSE3, and for x86_64 + SSE4.2 or AVX. This is something similar to your
option #4, but keeps the compatibility with all existing systems.

--
György Balló
Trusted User

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

[Balló György via arch-dev-public]

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.

So I'm in favour of #2, requiring SSE and SSE2 would be OK for me.


- model name: Intel(R) Celeron(R) CPU 2.10GHz
- flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts eagerfpu

- model name: Intel(R) Celeron(R) CPU 1.80GHz
- flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pebs bts eagerfpu

--
György Balló
Trusted User

Re: [arch-dev-public] Discussion about optional dependencies

[Balló György via arch-dev-public]

I agree with this, and the same apply for vlc I think, which recently lost
its qt4 dependency:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/vlc=b1a56bb8d107ebb51a6f2e32c67f866e2693517b

--
György Balló
Trusted User

Re: [arch-dev-public] Missing /run/lock/lockdev

[Balló György via arch-dev-public]

Hi,

(Sorry, the previous mail was an accident.)

Two of my packages (gnokii [1] and java-rxtx [2] ) still uses the
/run/lock/lockdev directory, but it was dropped from systemd 229 [3].
Without this directory (and the "lock" group), these applications fail to
create the lock file, and unable to work.

What should I do?

[1] https://www.archlinux.org/packages/community/x86_64/gnokii/
[2] https://www.archlinux.org/packages/community/x86_64/java-rxtx/
[3]
https://github.com/systemd/systemd/commit/61f32bff6130a44d077886d38cff89ad161bf177

--
György Balló
Trusted User

[arch-dev-public] Missing /run/lock/lockdev

[Balló György via arch-dev-public]

https://www.archlinux.org/packages/community/i686/java-rxtx/

https://github.com/systemd/systemd/commit/61f32bff6130a44d077886d38cff89ad161bf177