Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
[2013-01-19 17:54:51 +0100] Alexander Rødseth:
It's time again for the yearly cleanup of the [community] repository.
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.
Somehow, time passed, and it's now too late for a "Christmas Cleanup" like last year. Instead I'm announcing a Winter Cleanup, which I think is a better name as well.
45.8 degrees beg to differ. -- Gaetan
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
On Mon, Jan 21, 2013 at 12:05 AM, Alexander Rødseth <rodseth@gmail.com> wrote:
ndisc6 I took this one. I use it.
Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
[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
Hi, Several of the uneeded orphans has been adopted, which is great. === [community] === Here is the list for [community], that I'll now move to unsupported: dcron espeakup gmerlin-avdecoder iksemel isomaster libmatio libtlen libxml-perl lua-sql-mysql lua-sql-postgres lua-sql-sqlite mget multipath-tools nvclock pam-krb5 perl-text-wrapi18n pidgin-musictracker python2-gasp python2-pypdf python-simplejson udunits vim-nerdcommenter vim-timestamp The only new addition to the list is python-simplejson (also an uneeded orphan and also not a make dependency of any of the other [community] packages). A total of 23 [community] packages will be moved to unsupported. 1 package were already moved to unsupported and 4 other packages were adopted. === [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? And perhaps openldap could be moved to [extra] or [community]. === [extra] === For [extra], these are the packages that are uneeded orphans and are also not make dependencies for any other package in [extra]: 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 If no devs wish to maintain these, perhaps they could be moved to [community]. -- Best regards, Alexander Rødseth xyproto / TU
On Thu, Jan 24, 2013 at 1:08 PM, Alexander Rødseth <rodseth@gmail.com> 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 24/01/13 22:08, Alexander Rødseth wrote:
=== [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 put split packages across repos and gvim and deps are not going there so that is a no...
And perhaps openldap could be moved to [extra] or [community].
Split package with libldap... so no.
Hi, 2013/1/24 Allan McRae <allan@archlinux.org>:
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
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
On 24.01.2013 17:05, Stéphane Gaudreault wrote:
+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] ?).
On 25 January 2013 00:05, Stéphane Gaudreault <stephane@archlinux.org>wrote:
Le 2013-01-24 07:21, Allan McRae a écrit :
On 24/01/13 22:08, Alexander Rødseth wrote:
=== [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 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
We do need something vi-like besides nano. We need all the text power we can get because our installation is text-based. Most people are satisfied with nano, including myself (I spend very little time mucking around), but there are equally as many users who actually need the couple extra features during system setup and configuration. So we have to provide an alternative if we're gonna drop vi, IMO. -- GPG/PGP ID: C0711BF1
Hi, As far as I can tell from FS#20778, e3 was not evaluated. e3 provides Wordstar, Emacs, Pico, Vi and Nedit-like behavior, by using differently named symbolic links to /usr/bin/e3. It is unclear why the default editor _has to_ be a vi-replacement, as that excludes editors such as joe, jed or various emacs-clones. If ed really is "the golden UNIX standard", perhaps the default editor doesn't have to be a vi-replacement at all? If only fully fledged editors are good enough, why not include both emacs and gvim. (or the "no X" equivalents, like emacs-nox). Is there not room on the image? Is the bandwith cost too high? Are they not useful? I think they are. I know this isn't my decision, but my suggestion is to either go for the most lightweight editor, e3, or go "all in" with both emacs and vim. -- Sincerely, Alexander Rødseth xyproto / TU
There is nothing stopping us dropping vi completely and just putting vim on the install media...
On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae <allan@archlinux.org> 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 Fri, Jan 25, 2013 at 12:14 AM, Tom Gundersen <teg@jklm.no> wrote:
On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae <allan@archlinux.org> 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).
+1. I do this manually for each new installation. -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
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. Stéphane
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
Le 2013-01-25 09:21, Pierre Schmitz a écrit :
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
I will take that as an objection ... I created a new thread exactly because I do not wanted this discussion to be hidden in something related to [community]. The starting point of the discussion (beside the fact that vi is an unsable piece of crap) is that this package is orphan. If it is important for you, you are welcome to adopt it. Stéphane
On Fri, Jan 25, 2013 at 8:40 AM, Stéphane Gaudreault <stephane@archlinux.org> 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
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.
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, 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
On 30/01/13 09:47, Alexander Rødseth wrote:
Hi,
5 days have passed.
There are exactly 8 packages in [core] that falls back on vi.
<snip> Why would we make all those adjustments over just putting a vi symlink in the vim package?
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
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
On Thu, Jan 24, 2013 at 1:49 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
aspell-nl hyphen-nl
I can take these two in [extra] just for the sake of keeping them supported. If anyone else is more interested feel free to take it from me. Ronald
On 24/01/13 13:56, Ronald van Haren wrote:
On Thu, Jan 24, 2013 at 1:49 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
aspell-nl hyphen-nl
I can take these two in [extra] just for the sake of keeping them supported. If anyone else is more interested feel free to take it from me.
Ronald
If they are moved into [community], I could maintain them too for the same reason ;).
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
On Thu, Jan 24, 2013 at 4:08 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
bluez-hcidump
I adopted this. It will go away with the next bluez release. Cheers, Tom
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 <andrea@archlinux.org> 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 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 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.
If no one is willing to maintain it, I'll remove it from the repos.
Angel? -- Andrea Arch Linux Developer
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?
On Thursday 24 January 2013 20:50:50 Alexander Rødseth wrote:
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.
Packages moved. See the following list: Moved to [community]: * avfs * bmp-musepack * bmp-wma * bochs * botan * cdargs * cx_freeze * dcfldd * devilspie * emelfm2 * evilwm * festival-voices * fssos-nsvs * gimp-dbp * gimp-gap * gimp-ufraw * gmpc * gtkpod * hercules * herqq * isodate * kradio * kshutdown * libmusicbrainz4 * mahjong * misdnuser * monica * nicotine * opendesktop-fonts * oprofile * pidgin-encryption * proftpd * pymad * python-httplib2 * qiv * ratpoison * rox * xdelta * xdelta3 * zile Moved to AUR: * perl-event * perl-file-tail * perl-unicode-string Thank you Alexander. -- Andrea Arch Linux Developer
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 Mon, Jan 28, 2013 at 1:18 AM, Andrea Scarpino <andrea@archlinux.org> wrote:
On Thursday 24 January 2013 20:50:50 Alexander Rødseth wrote:
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.
Packages moved. See the following list:
Moved to [community]: ... * xdelta
Looks like one removal slipped through the cracks? https://www.archlinux.org/packages/extra/x86_64/xdelta/ https://www.archlinux.org/packages/community/x86_64/xdelta/ -Dan
I guess that concludes this winter's (for some part of the world) cleanup of [extra]. Thanks everyone. - Alexander
participants (14)
-
Alexander Rødseth
-
Allan McRae
-
Andrea Scarpino
-
Dan McGee
-
Eric Bélanger
-
Florian Pritz
-
Gaetan Bisson
-
Jelle van der Waa
-
Pierre Schmitz
-
Rashif Ray Rahman
-
Ronald van Haren
-
Stéphane Gaudreault
-
Sébastien Luttringer
-
Tom Gundersen