Hi, @Fons Adriaensen Didn't think of that, here's the current list: dcron espeakup gmerlin-avdecoder i2c-tools iksemel isomaster libmatio libtlen libtxc_dxtn libxml-perl lua-sql-mysql lua-sql-postgres lua-sql-sqlite mget multipath-tools ndisc6 nvclock pam-krb5 perl-text-wrapi18n pidgin-musictracker python2-gasp python2-pypdf ttf-envy-code-r udunits vim-nerdcommenter vim-timestamp winefish I also checked that none of these packages are makedepends of any of the [community] packages. @Gaetan Bisson:

Please send such messages to arch-dev-public in the future: adopting packages are dev's and TU's decision, and not all read arch-general.

I also think non-devs and non-TUs may have valuable insights for why for instance a package should be considered to be too important to not be moved to unsupported. The ibus and lxdm packages were considered to be too important to move to unsupported during the last cleanup. Perhaps someone (the upstream developers?) may have a reason or opinion for why one of the listed packages should not be moved. The decision would still be in the hands of devs and TUs, but there could still be potentially useful information coming from "the outside".

45.8 degrees beg to differ.

Point taken, and suggestions for a better name are welcome. How about "New Year Cleanup"? -- Sincerely, Alexander Rødseth xyproto / TU

[2013-01-21 00:05:32 +0100] Alexander Rødseth:

I also think non-devs and non-TUs may have valuable insights for why for instance a package should be considered to be too important to not be moved to unsupported.

Sure. Users sometimes make insightful points on what is being discussed on arch-dev-public by replying to arch-general. Most users interested in Arch's development should read arch-dev-public anyway. If you are really looking for community feedback, cross-posting to arch-general is fine, but you should post to arch-dev-public in any case. -- Gaetan

On Thu, Jan 24, 2013 at 1:08 PM, Alexander Rødseth wrote:

lua-sql-mysql lua-sql-postgres lua-sql-sqlite This is part of split package luasql, which was maintained by Sergey and was renamed during lua 5.2 upgrade. I believe he does't take it again on archweb.

Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A

On Thursday 24 January 2013 13:08:23 Alexander Rødseth wrote:

A total of 23 [community] packages will be moved to unsupported. 1 package were already moved to unsupported and 4 other packages were adopted.

+1

archlinux-wallpaper

It's a pity. I could take it just to keep it in [extra] (no updates in a long time).

aspell-hu aspell-nl aspell-pt aspell-ru hunspell-hu hyphen-hu hyphen-it hyphen-nl

Those could be moved to [community], but not on AUR IMHO.

If no devs wish to maintain these, perhaps they could be moved to [community].

I agree. If some TU want some package in this list just ping me so I can move it to [community]. Alexander, ping me if you need help with the move. -- Andrea Arch Linux Developer

Hi, 2013/1/24 Allan McRae :

I agree with just dumping vi and moving [vim] to core... But we can not put split packages across repos and gvim and deps are not going there so that is a no...

That is fully understandable. I guess unsplitting vim/gvim is not a viable option either. I see that nano is already in core, but if there's a wish for a vi-compatible editor in [core], there is "e3" in [community] which also provides /usr/bin/e3vi for vi-compatibility. It's really tiny and fast, and only takes up 76 KiB of space after installation. Perhaps that could be an alternative?

...

And perhaps openldap could be moved to [extra] or [community].

Split package with libldap... so no.

These are the packages in [core] that depend on libldap: dirmngr nfsidmap krb5 dirmngr and nfsidmap are maintained by Tobias Powalowski, while krb5 is maintained by Stéphane Gaudreault. Perhaps one of them would like to adopt libldap, since only their packages in [core] depends on it. -- Best regards, Alexander Rødseth xyproto / TU

I renamed this thread to get it more visibility. Alexander did this list of orphans packages that can be moved to [community]: alacarte archlinux-wallpaper aspell-hu aspell-nl aspell-pt aspell-ru avfs bin86 bluez-hcidump bmp-musepack bmp-wma bochs botan cdargs dcfldd devilspie emelfm2 evilwm evolution-ews festival-english festival-us fltk-docs fltk-games fssos-nsvs gcdmaster gimp-dbp gimp-gap gimp-ufraw gmpc gtkpod hercules herqq hunspell-hu hyphen-hu hyphen-it hyphen-nl kradio kshutdown libmusicbrainz4 libofx-doc mahjong misdnuser monica mythes-hu mythes-it mythes-nl nicotine opendesktop-fonts oprofile orage perl-event perl-file-tail perl-unicode-string pidgin-encryption proftpd pymad python-httplib2 python-isodate python-xdg python-zope-interface qiv ratpoison rox xdelta xdelta3 xdg-user-dirs-gtk xfburn xfce4-artwork xfce4-battery-plugin xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin xfce4-eyes-plugin xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin xfce4-mixer xfce4-mount-plugin xfce4-mpc-plugin xfce4-netload-plugin xfce4-notes-plugin xfce4-quicklauncher-plugin xfce4-sensors-plugin xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-taskmanager xfce4-time-out-plugin xfce4-timer-plugin xfce4-verve-plugin xfce4-wavelan-plugin zile Ronald can keep the *-nl packages. What about the others? Alexander can maintain some of them, then I'll move the orphans to [community] this Saturday/Sunday. -- Andrea Arch Linux Developer

Le 2013-01-24 07:21, Allan McRae a écrit :

...

=== [core] ===

For [core], there are two uneeded orphans, that also aren't make dependencies for any other [core] packages:

openldap vi

If I may be so bold, maybe vim or another editor (still providing the "vi" command) could take over for the vi package? I agree with just dumping vi and moving [vim] to core... But we can not

On 24/01/13 22:08, Alexander Rødseth wrote: put split packages across repos and gvim and deps are not going there so that is a no...

Moving to another thread for clarity. +1 to drop vi. I cannot imagine why someone would want to use this crap ... We already have nano in [core], so I think that vim could stay in [extra] (do we really need 2 text editors in [core] ?). Stéphane

alacarte archlinux-wallpaper aspell-hu aspell-nl aspell-pt aspell-ru avfs bin86 bluez-hcidump bmp-musepack bmp-wma bochs botan cdargs dcfldd devilspie emelfm2 evilwm evolution-ews festival-english festival-us fltk-docs fltk-games fssos-nsvs gcdmaster gimp-dbp gimp-gap gimp-ufraw gmpc gtkpod hercules herqq hunspell-hu hyphen-hu hyphen-it hyphen-nl kradio kshutdown libmusicbrainz4 libofx-doc mahjong misdnuser monica mythes-hu mythes-it mythes-nl nicotine opendesktop-fonts oprofile orage perl-event perl-file-tail perl-unicode-string pidgin-encryption proftpd pymad python-httplib2 python-isodate python-xdg python-zope-interface qiv ratpoison rox xdelta xdelta3 xdg-user-dirs-gtk xfburn xfce4-artwork xfce4-battery-plugin xfce4-clipman-plugin xfce4-cpufreq-plugin xfce4-cpugraph-plugin xfce4-datetime-plugin xfce4-dict xfce4-diskperf-plugin xfce4-eyes-plugin xfce4-fsguard-plugin xfce4-genmon-plugin xfce4-mailwatch-plugin xfce4-mixer xfce4-mount-plugin xfce4-mpc-plugin xfce4-netload-plugin xfce4-notes-plugin xfce4-quicklauncher-plugin xfce4-sensors-plugin xfce4-smartbookmark-plugin xfce4-systemload-plugin xfce4-taskmanager xfce4-time-out-plugin xfce4-timer-plugin xfce4-verve-plugin xfce4-wavelan-plugin zile

Add another one: cx_freeze So someone please take it, or let it drop :) I just orphaned it as I have not enough interest ATM to fix the PKGBUILD (but changes are trivial, a matter of traversing dirs correctly for the new source archive). -- GPG/PGP ID: C0711BF1

On Thu, Jan 24, 2013 at 10:08 AM, Andrea Scarpino wrote:

I renamed this thread to get it more visibility.

Alexander did this list of orphans packages that can be moved to [community]:

We should only move packages to [community] if a TU is interested in adopting them. Otherwise, we should move them to AUR (or keep them in [extra]) as it will won't solve the problem of orphaned packages in repo. So if a TU is interested in some of these packages, they should let us know which one they wants.

aspell-hu aspell-nl aspell-pt aspell-ru

i18n packages. Low maintenance. Should remain in repo [extra] or [community] either as adopted or orphaned.

fltk-docs fltk-games

Split package for fltk. Should remain in [extra].

hunspell-hu hyphen-hu hyphen-it hyphen-nl

i18n packages. Low maintenance. Should remain in repo ([extra] or [community]) either as adopted or orphaned.

libofx-doc

Split package for libofx. Only required by [community] packages. Should be moved to [community]

mythes-hu mythes-it mythes-nl

i18n packages. Low maintenance. Should remain in repo [extra] or [community] either as adopted or orphaned.

xfce4-*

I beleive many users use xfce4 so we might want to keep the plugins in the repos

Ronald can keep the *-nl packages. What about the others?

Alexander can maintain some of them, then I'll move the orphans to [community] this Saturday/Sunday.

-- Andrea Arch Linux Developer

Hi, I'm willing to adopt the unneeded orphans from [extra] if they are moved to [community], except the perl-* packages. For the i18n and spelling packages it's probably best if someone using the respective languages adopts them, but I'm willing to adopt those as well. - Alexander

On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae wrote:

There is nothing stopping us dropping vi completely and just putting vim on the install media...

I'd favor that (as a vim user who always gets confused by vi on the install media). -t

On 24/01/13 20:50, Alexander Rødseth wrote:

Hi,

I'm willing to adopt the unneeded orphans from [extra] if they are moved to [community], except the perl-* packages. For the i18n and spelling packages it's probably best if someone using the respective languages adopts them, but I'm willing to adopt those as well.

- Alexander

I orphaned tagpy, I don't know if anyone wants to maintain it? ( It's an optdep of sonata ). I can't make the current release work with either repos version of boost or staging's version of boost. If no one is willing to maintain it, I'll remove it from the repos.

On 25/01/13 12:08, Andrea Scarpino wrote:

On Friday 25 January 2013 11:58:05 Jelle van der Waa wrote:

...

I orphaned tagpy, I don't know if anyone wants to maintain it? ( It's an optdep of sonata ).

I renamed tagpy as python2-tagpy few hours ago since tagpy switched to python 3.

...

I can't make the current release work with either repos version of boost or staging's version of boost.

It was incompatible with taglib 1.8 and I already rebuilt it in community- staging. Thanks, I didn't notice that.

...

If no one is willing to maintain it, I'll remove it from the repos.

Angel?

Am 25.01.2013 14:03, schrieb Stéphane Gaudreault:

Le 2013-01-24 17:45, Allan McRae a écrit :

...

There is nothing stopping us dropping vi completely and just putting vim on the install media...

+1, vim could stay in [extra] and be included in the install media. Let's wait a little 24 hours and if nobody object we will execute the condemned.

I am glad you give us 24 hours to change a default we had for years in Arch and might potentially break a lot. Especially considering this discussion was hidden in an unrelated thread about the [community] cleanup. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com

On Fri, Jan 25, 2013 at 8:40 AM, Stéphane Gaudreault wrote:

Le 2013-01-25 09:21, Pierre Schmitz a écrit :

...

Am 25.01.2013 14:03, schrieb Stéphane Gaudreault:

...

Let's wait a little 24 hours and if nobody object we will execute the condemned.

I am glad you give us 24 hours to change a default we had for years in Arch and might potentially break a lot. Especially considering this discussion was hidden in an unrelated thread about the [community] cleanup.

I will take that as an objection ...

I think Pierre's objection at the 24 hour ultimatum is quite reasonable. None of us are full-time employees here of Arch, so expecting every developer to acknowledge and respond to an email within 24 hours is a bit crazy. These type of things are in no rush to be decided on as far as I can tell, so any time before the next release would be fine. It is nice to give people at least a few days if not a week around here to respond. -Dan

Le 2013-01-25 11:58, Florian Pritz a écrit :

On 25.01.2013 16:40, Stéphane Gaudreault wrote:

...

I created a new thread exactly because I do not wanted this discussion to be hidden in something related to [community]. FWIW you didn't create a new thread, but you changed the subject in an existing one. Clients that use in-reply-to and references headers will still count that as one thread.

ok, I was completely wrong and I apologize. The question remain unanswered : what do we do with this orphan/unmaintaned package ?It is a bit strange for me thata bleeding edge distribution as Arch present to his users a text editor from 1976during the installation.

Hi, Thanks for moving them, Andrea. I adopted all of them. (If someone else should be interested in maintaining one of these, I'd be happy to give them away for re-adoption). - Alexander

On Monday 28 January 2013 08:30:37 Dan McGee wrote:

...

* xdelta

Looks like one removal slipped through the cracks?

Yes, we had some trouble yesterday. Fixed, thanks. -- Andrea Arch Linux Developer

Hi, 5 days have passed. There are exactly 8 packages in [core] that falls back on vi. === visudo === People can either run visudo like this: # EDITOR=vim visudo Or this could be added to /etc/sudoers (possibly by default): Defaults editor=/usr/bin/vim This can be configured by the user, or changed in the sudo package. Both methods work, and vi is not needed in either case. === cronie and glibc === The same goes for crontab. This works fine: EDITOR=vim crontab -e In order to set the default editor for crontab at compile time, _PATH_VI has to be set correctly in glibc. Here's the relevant code from src/pathnames.h in cronie: #if defined(_PATH_VI) # define EDITOR _PATH_VI #else # define EDITOR "/usr/ucb/vi" #endif For changing the default editor (_PATH_VI) to vim in glibc, just add this line to the build() function: sed -i 's:/vi:/vim:' sysdeps/generic/paths.h sysdeps/unix/sysv/linux/paths.h === less and util-linux === These tries to start an editor when the "v" key is pressed. They both respect EDITOR and VISUAL but falls back on vi. (Is less really needed in [core], when more is supplied by util-linux? It seems a bit redundant). The fallback editor for less can be changed at compile time by adding the --with-editor flag: ./configure --with-editor=vim For the more utility in the util-linux package, set the fallback editor to vim by adding this line to the build() function: sed -i 's/"vi"\t/"vim"\t/' text-utils/more.c === bash === bashbug that comes with bash falls back on vi. Add this line to the build() function to change this to vim: sed -i 's/\([^a-zA-Z]\)vi/\1vim/' support/bashbug.sh For all of the changes for all of the above packages, I've rebuilt the packages and tested the functionality by unsetting EDITOR and VISUAL and removing /usr/bin/vi. === hairloom-mailx === In the build() function in the PKGBUILD, add: sed -i 's:"vi":"vim:' edit.c === shadow === Set the define DEFAULT_EDITOR to "vim" when compiling. I know that patching files with sed isn't really "The Arch Way" (even though a large numbers of packages do this), so if the remaining argument is that the switch from vi to vim has to come from upstream, I'm willing to submit patches/bug reports for all of the above that needs changes in the sourcecode (preferably without "vi" being hardcoded). === In summary === * All packages should respect the EDITOR or VISUAL environment variables (or at least _PATH_VI), so users can select whichever editor they like. * It's fully possible to change the fallback editor for all [core] packages to be vim instead of vi. * Switching from vi to vim should be unproblematic. +1 for dropping vi from [core] and including vim on the install medium instead. -- Sincerely, Alexander Rødseth xyproto / TU

It's not a given that a vi clone is the most desirable replacement. If an editor that is not a vi clone should be preferred, now or in the future, a symlink named vi looks funny. But mainly, the motivation for a thorough examination of where vi is actually used in [core] was to bring some peace of mind to those who were afraid of breakage. Hopefully someone appreciated the effort. - Alexander