[arch-dev-public] Signoff report for [testing]
=== Signoff report for [testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 8 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 10 fully signed off packages * 30 packages missing signoffs * 6 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [testing] in last 24 hours (8 total) == * cracklib-2.8.22-1 (i686) * cracklib-2.8.22-1 (x86_64) * efilinux-efi-1.0-4 (any) * gummiboot-efi-15-2 (any) * cairo-1.12.10-3 (i686) * gnu-efi-libs-3.0s-3 (i686) * cairo-1.12.10-3 (x86_64) * gnu-efi-libs-3.0s-3 (x86_64) == Incomplete signoffs for [core] (19 total) == * acl-2.2.51-3 (i686) 0/2 signoffs * bash-4.2.042-2 (i686) 1/2 signoffs * cracklib-2.8.22-1 (i686) 0/2 signoffs * filesystem-2013.01-1 (i686) 1/2 signoffs * gcc-4.7.2-4 (i686) 1/2 signoffs * glibc-2.17-2 (i686) 1/2 signoffs * iw-3.8-1 (i686) 0/2 signoffs * linux-api-headers-3.7.4-1 (i686) 1/2 signoffs * openvpn-2.3.0-1 (i686) 0/2 signoffs * reiserfsprogs-3.6.22-1 (i686) 1/2 signoffs * wpa_supplicant-2.0-1 (i686) 0/2 signoffs * acl-2.2.51-3 (x86_64) 0/2 signoffs * cracklib-2.8.22-1 (x86_64) 0/2 signoffs * gcc-4.7.2-4 (x86_64) 1/2 signoffs * iw-3.8-1 (x86_64) 1/2 signoffs * linux-api-headers-3.7.4-1 (x86_64) 1/2 signoffs * openvpn-2.3.0-1 (x86_64) 1/2 signoffs * reiserfsprogs-3.6.22-1 (x86_64) 1/2 signoffs * wpa_supplicant-2.0-1 (x86_64) 1/2 signoffs == Incomplete signoffs for [extra] (11 total) == * efilinux-efi-1.0-4 (any) 0/2 signoffs * gummiboot-efi-15-2 (any) 0/2 signoffs * cairo-1.12.10-3 (i686) 0/2 signoffs * gnu-efi-libs-3.0s-3 (i686) 0/2 signoffs * libao-1.1.0-3 (i686) 0/2 signoffs * qemu-1.3.0-1 (i686) 0/2 signoffs * wpa_supplicant_gui-2.0-1 (i686) 0/2 signoffs * cairo-1.12.10-3 (x86_64) 0/2 signoffs * gnu-efi-libs-3.0s-3 (x86_64) 0/2 signoffs * libao-1.1.0-3 (x86_64) 0/2 signoffs * wpa_supplicant_gui-2.0-1 (x86_64) 0/2 signoffs == Completed signoffs (10 total) == * gnupg-2.0.19-4 (i686) * gpgme-1.3.1-5 (i686) * lvm2-2.02.98-3 (i686) * bash-4.2.042-2 (x86_64) * filesystem-2013.01-1 (x86_64) * glibc-2.17-2 (x86_64) * gnupg-2.0.19-4 (x86_64) * gpgme-1.3.1-5 (x86_64) * lvm2-2.02.98-3 (x86_64) * qemu-1.3.0-1 (x86_64) == All packages in [testing] for more than 14 days (6 total) == * lvm2-2.02.98-3 (i686), since 2012-11-03 * lvm2-2.02.98-3 (x86_64), since 2012-11-03 * qemu-1.3.0-1 (i686), since 2012-12-20 * qemu-1.3.0-1 (x86_64), since 2012-12-20 * reiserfsprogs-3.6.22-1 (i686), since 2013-01-09 * reiserfsprogs-3.6.22-1 (x86_64), since 2013-01-09 == Top five in signoffs in last 24 hours ==
Re: [arch-dev-public] Toolchain changes
On 24 January 2013 01:57, Allan McRae al...@archlinux.org wrote: I think I need to write a news announcement for this, even though everything should go smoothly, it never does. ---DRAFT--- Update filesystem-2013.01-1 and glibc-2.17-2 together Due to moving of the /lib symlink from the glibc package to the more appropriate filesystem package, it is required to update glibc-2.12-2 and filesystem-2013.01-1 together. This will happen automatically when you run pacman -Syu. Remember, partial updates are not supported... A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib. ---END DRAFT--- The other option is to add a filesystem=2013.01 dependency to glibc, but that would result in some nasty circular dependencies due to deps in the filesystem package. Allan I'd go with the news item instead of the versioned dependency. It's worth reiterating that partial updates are not supported and the second paragraph contains useful information for people who run into any problems.
Re: [arch-dev-public] Clarity about initscripts and systemd status
Am 23.01.2013 20:15, schrieb Sébastien Luttringer: Hello, I've cleaned all packages where I maintain rc scripts. Lukas J. has moved the legacy to a community[1] package[2]. FYI for Lukas: I removed initscripts support from openvpn, the scripts are still in SVN. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Toolchain changes
Am 24.01.2013 00:57, schrieb Allan McRae: ---DRAFT--- Update filesystem-2013.01-1 and glibc-2.17-2 together Due to moving of the /lib symlink from the glibc package to the more appropriate filesystem package, it is required to update glibc-2.12-2 and filesystem-2013.01-1 together. This will happen automatically when you run pacman -Syu. Remember, partial updates are not supported... A potential issue with the upgrade on x86_64 is finding conflicting files in /usr/lib64. All Arch Linux packages that had files in this directory have been updated, so update these individually first. Any AUR packages with files in this directory should be updated to install them in /usr/lib. ---END DRAFT--- The usual under no circumstances, use the --force option warning would be helpful. The other option is to add a filesystem=2013.01 dependency to glibc, but that would result in some nasty circular dependencies due to deps in the filesystem package. You can use versioned conflicts on both packages to achieve this without creating dependency cycles. signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Nymeria Migration Guide for extra
On 20 January 2013 20:37, Florian Pritz bluew...@xinu.at wrote: Just for you to know we do not have read rights on /mnt/old_home/gerolde Fixed Hello ! We should update the wiki page [0]. Could anybody give me write access to these pages or do it please? Thanks [0] https://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager
Re: [arch-dev-public] Nymeria Migration Guide for extra
On Thursday 24 January 2013 11:48:12 Guillaume Alaux wrote: We should update the wiki page [0]. Could anybody give me write access to these pages or do it please? Done -- Andrea Arch Linux Developer
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
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
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
On Thu, Jan 24, 2013 at 1:08 PM, Alexander Rødseth rods...@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
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
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.
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
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
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
On Thu, Jan 24, 2013 at 1:49 PM, Andrea Scarpino and...@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
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
Hi, 2013/1/24 Allan McRae al...@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
Re: [arch-dev-public] [arch-general] Winter Cleanup of [community]
On 24/01/13 13:56, Ronald van Haren wrote: On Thu, Jan 24, 2013 at 1:49 PM, Andrea Scarpino and...@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 ;). signature.asc Description: OpenPGP digital signature
[arch-dev-public] Winter Cleanup of [extra]
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
Re: [arch-dev-public] Winter Cleanup of [extra]
On Thu, Jan 24, 2013 at 4:08 PM, Andrea Scarpino and...@archlinux.org wrote: bluez-hcidump I adopted this. It will go away with the next bluez release. Cheers, Tom
[arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
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
Re: [arch-dev-public] [arch-general] Drop VI from [core] (was Re: Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:27 AM, Paul Gideon Dann pdgid...@gmail.comwrote: On Thursday 24 Jan 2013 11:05:22 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] ?). Vi is the standard UNIX text-editor. Many admins rely on the fact that vi is available everywhere. It really should be in core. Also, I know you might be referring to plain vi, which is a completely different beast to Vim, but the latter (which provides vi too) has a *huge* userbase. Calling it crap is just bizarre... Paul Incorrect -- ed is the standard unix editor. http://www.gnu.org/fun/jokes/ed-msg.html More seriously, POSIX says vi is optional for us: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html Please remember that dropping it from [core] makes it in no way any less available. I've no problems with moving vi as long as it doesn't disappear from the install media. It's useful to have around long enough until you can pacman -S vim.
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
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] ?). Related: https://bugs.archlinux.org/task/20778 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Winter Cleanup of [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 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
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
On 25 January 2013 00:05, Stéphane Gaudreault steph...@archlinux.orgwrote: 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
Re: [arch-dev-public] Winter Cleanup of [extra]
On Thu, Jan 24, 2013 at 10:08 AM, Andrea Scarpino and...@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
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
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
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
There is nothing stopping us dropping vi completely and just putting vim on the install media...
Re: [arch-dev-public] Drop VI from [core] (was Re: [arch-general] Winter Cleanup of [community])
On Thu, Jan 24, 2013 at 11:45 PM, Allan McRae al...@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
