- Aur-general - lists.archlinux.org

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 27 Feb '15

27 Feb '15

=== Signoff report for [community-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 * 0 fully signed off packages * 30 packages missing signoffs * 13 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 [community-testing] in last 24 hours (8 total) == * fcitx-qt5-1.0.0-3 (i686) * kadu-2.0-1 (i686) * lightdm-gtk-greeter-1:2.0.0-1 (i686) * mongodb-2.6.8-1 (i686) * fcitx-qt5-1.0.0-3 (x86_64) * kadu-2.0-1 (x86_64) * lightdm-gtk-greeter-1:2.0.0-1 (x86_64) * mongodb-2.6.8-1 (x86_64) == Incomplete signoffs for [community] (30 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * mantisbt-1.2.19-2 (any) 0/2 signoffs * acpi_call-1.1.0-24 (i686) 0/1 signoffs * bbswitch-0.8-26 (i686) 0/1 signoffs * dropbear-2015.67-1 (i686) 0/1 signoffs * fcitx-qt5-1.0.0-3 (i686) 0/1 signoffs * kadu-2.0-1 (i686) 0/1 signoffs * libopenshot-audio-0.0.4-1 (i686) 0/1 signoffs * lightdm-gtk-greeter-1:2.0.0-1 (i686) 0/1 signoffs * mongodb-2.6.8-1 (i686) 0/1 signoffs * r8168-8.039.00-10 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-20 (i686) 0/1 signoffs * tp_smapi-0.41-63 (i686) 0/1 signoffs * vhba-module-20140928-6 (i686) 0/1 signoffs * virtualbox-modules-4.3.22-2 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.22-2 (i686) 0/1 signoffs * acpi_call-1.1.0-24 (x86_64) 0/2 signoffs * bbswitch-0.8-26 (x86_64) 0/2 signoffs * dropbear-2015.67-1 (x86_64) 0/2 signoffs * fcitx-qt5-1.0.0-3 (x86_64) 0/2 signoffs * kadu-2.0-1 (x86_64) 0/2 signoffs * libopenshot-audio-0.0.4-1 (x86_64) 0/2 signoffs * lightdm-gtk-greeter-1:2.0.0-1 (x86_64) 0/2 signoffs * mongodb-2.6.8-1 (x86_64) 0/2 signoffs * r8168-8.039.00-10 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-20 (x86_64) 0/2 signoffs * tp_smapi-0.41-63 (x86_64) 0/2 signoffs * vhba-module-20140928-6 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.22-2 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.22-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (13 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * r8168-8.039.00-10 (i686), since 2015-02-09 * r8168-8.039.00-10 (x86_64), since 2015-02-09 * tp_smapi-0.41-63 (i686), since 2015-02-09 * tp_smapi-0.41-63 (x86_64), since 2015-02-09 * vhba-module-20140928-6 (i686), since 2015-02-09 * vhba-module-20140928-6 (x86_64), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (i686), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (x86_64), since 2015-02-09 * bbswitch-0.8-26 (i686), since 2015-02-09 * bbswitch-0.8-26 (x86_64), since 2015-02-09 * acpi_call-1.1.0-24 (i686), since 2015-02-12 * acpi_call-1.1.0-24 (x86_64), since 2015-02-12 == Top five in signoffs in last 24 hours == 1. eworm - 2 signoffs

1 0

[aur-general] Move vidalia to AUR
by Timothy M. Redaelli 26 Feb '15

26 Feb '15

Hi, since Vidalia is no more maintained nor supported upstream (https://lists.torproject.org/pipermail/tor-talk/2015-February/036833.html) and FS#43802 I'll move it to AUR tommorow. Any objections? -- Timothy M. Redaelli Arch Linux Trusted User

2 1

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 26 Feb '15

26 Feb '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 24 packages missing signoffs * 11 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.) == Incomplete signoffs for [community] (24 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * mantisbt-1.2.19-2 (any) 0/2 signoffs * acpi_call-1.1.0-24 (i686) 0/1 signoffs * bbswitch-0.8-26 (i686) 0/1 signoffs * dropbear-2015.67-1 (i686) 0/1 signoffs * libopenshot-audio-0.0.4-1 (i686) 0/1 signoffs * phantomjs-2.0.0-1 (i686) 0/1 signoffs * r8168-8.039.00-10 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-20 (i686) 0/1 signoffs * tp_smapi-0.41-63 (i686) 0/1 signoffs * vhba-module-20140928-6 (i686) 0/1 signoffs * virtualbox-modules-4.3.22-2 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.22-2 (i686) 0/1 signoffs * acpi_call-1.1.0-24 (x86_64) 0/2 signoffs * bbswitch-0.8-26 (x86_64) 0/2 signoffs * dropbear-2015.67-1 (x86_64) 0/2 signoffs * libopenshot-audio-0.0.4-1 (x86_64) 0/2 signoffs * phantomjs-2.0.0-1 (x86_64) 0/2 signoffs * r8168-8.039.00-10 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-20 (x86_64) 0/2 signoffs * tp_smapi-0.41-63 (x86_64) 0/2 signoffs * vhba-module-20140928-6 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.22-2 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.22-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (11 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * r8168-8.039.00-10 (i686), since 2015-02-09 * r8168-8.039.00-10 (x86_64), since 2015-02-09 * tp_smapi-0.41-63 (i686), since 2015-02-09 * tp_smapi-0.41-63 (x86_64), since 2015-02-09 * vhba-module-20140928-6 (i686), since 2015-02-09 * vhba-module-20140928-6 (x86_64), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (i686), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (x86_64), since 2015-02-09 * bbswitch-0.8-26 (i686), since 2015-02-09 * bbswitch-0.8-26 (x86_64), since 2015-02-09 == Top five in signoffs in last 24 hours == 1. lcarlier - 5 signoffs

1 0

[aur-general] Fwd: New category: Security
by Ľubomír Kučera 25 Feb '15

25 Feb '15

Hello. I hoped you would add a new category to AUR called "Security". I thought it would be more suitable for those packages which target computer security. For example, some of my packages which would fit better to Security category are bully <https://aur.archlinux.org/packages/bully/> or oclhashcat <https://aur.archlinux.org/packages/oclhashcat/>. Kuci

6 6

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 25 Feb '15

25 Feb '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 4 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 24 packages missing signoffs * 11 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 [community-testing] in last 24 hours (4 total) == * dropbear-2015.67-1 (i686) * phantomjs-2.0.0-1 (i686) * dropbear-2015.67-1 (x86_64) * phantomjs-2.0.0-1 (x86_64) == Incomplete signoffs for [community] (24 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * mantisbt-1.2.19-2 (any) 0/2 signoffs * acpi_call-1.1.0-24 (i686) 0/1 signoffs * bbswitch-0.8-26 (i686) 0/1 signoffs * dropbear-2015.67-1 (i686) 0/1 signoffs * libopenshot-audio-0.0.4-1 (i686) 0/1 signoffs * phantomjs-2.0.0-1 (i686) 0/1 signoffs * r8168-8.039.00-10 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-20 (i686) 0/1 signoffs * tp_smapi-0.41-63 (i686) 0/1 signoffs * vhba-module-20140928-6 (i686) 0/1 signoffs * virtualbox-modules-4.3.22-2 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.22-2 (i686) 0/1 signoffs * acpi_call-1.1.0-24 (x86_64) 0/2 signoffs * bbswitch-0.8-26 (x86_64) 0/2 signoffs * dropbear-2015.67-1 (x86_64) 0/2 signoffs * libopenshot-audio-0.0.4-1 (x86_64) 0/2 signoffs * phantomjs-2.0.0-1 (x86_64) 0/2 signoffs * r8168-8.039.00-10 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-20 (x86_64) 0/2 signoffs * tp_smapi-0.41-63 (x86_64) 0/2 signoffs * vhba-module-20140928-6 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.22-2 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.22-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (11 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * r8168-8.039.00-10 (i686), since 2015-02-09 * r8168-8.039.00-10 (x86_64), since 2015-02-09 * tp_smapi-0.41-63 (i686), since 2015-02-09 * tp_smapi-0.41-63 (x86_64), since 2015-02-09 * vhba-module-20140928-6 (i686), since 2015-02-09 * vhba-module-20140928-6 (x86_64), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (i686), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (x86_64), since 2015-02-09 * bbswitch-0.8-26 (i686), since 2015-02-09 * bbswitch-0.8-26 (x86_64), since 2015-02-09 == Top five in signoffs in last 24 hours == 1. anatolik - 1 signoffs

1 0

Re: [aur-general] How should I handle VCS packages right?
by Jan Alexander Steffens 25 Feb '15

25 Feb '15

On Tue, Feb 24, 2015 at 11:35 PM, Christopher Reimer <mail(a)creimer.net> wrote: > Hi list, > > I'm maintainer of a project called VDR4Arch. > https://github.com/VDR4Arch/vdr4arch > > I recently started taking over a bunch of packages in AUR. My main goal is > to follow the best practices from the Developer Wiki as good as possible. > > A lot of plugins for vdr are more or less orphaned upstream. There are no > regular releases and the last one is usually a year back. However there are > still commit in the GIt repository. And around the vdr community it's common > practice to use these Git revisions and consider them stable. The community > even keeps these plugins alive with compatibility patches. > > Usually I would say that these are VCS packages and need to be suffixed by > -git. But to distribute the version everyone in the community expects I > started using the VCS feature with fixed commit ids, which are tested by me > or somebody trusted. I create these packages without the -git suffix. > > I'd like to know how a Trusted User or even an Arch Developer would handle > this. Is this approach acceptable? -git packages are expected to track the latest development (usually the master branch), generating a dynamically versioned package from the head commit. If you lock your releases to certain commits or tags, it's not fundamentally different from a package using tarballs. If you grep ABS for '#\(tag\|commit\|revision\)=' you'll find a lot of packages grabbing sources from bzr, git or svn.

1 0

[aur-general] Dependency on plugin API version
by Christopher Reimer 24 Feb '15

24 Feb '15

Hi list, I'm maintainer of the vdr package in AUR. https://aur.archlinux.org/packages/vdr/ All vdr plugin packages depend on vdr-api with a fixed version. As you can see right now the version of vdr-api and vdr itself are the same. Since version 2.0.0 it's common practice to bump the plugin version to e.g. 2.0.1 but keep the plugin API version at 2.0.0. Which means plugins don't have to be rebuild and therefore no pkgrel bump is necessary. AUR Web doesn't detect the dependency between the vdr package which provides vdr-api and a plugin which depends on vdr-api. At a later version, I think it was 2.0.3 the API version was bumped, too. So just checking on major and first minor version as it's done with the kernel package doesn't work here. I conclude from this that I did something wrong and I should handle this different. But I don't really know how. Thanks Christopher

1 0

[aur-general] How should I handle VCS packages right?
by Christopher Reimer 24 Feb '15

24 Feb '15

Hi list, I'm maintainer of a project called VDR4Arch. https://github.com/VDR4Arch/vdr4arch I recently started taking over a bunch of packages in AUR. My main goal is to follow the best practices from the Developer Wiki as good as possible. A lot of plugins for vdr are more or less orphaned upstream. There are no regular releases and the last one is usually a year back. However there are still commit in the GIt repository. And around the vdr community it's common practice to use these Git revisions and consider them stable. The community even keeps these plugins alive with compatibility patches. Usually I would say that these are VCS packages and need to be suffixed by -git. But to distribute the version everyone in the community expects I started using the VCS feature with fixed commit ids, which are tested by me or somebody trusted. I create these packages without the -git suffix. I'd like to know how a Trusted User or even an Arch Developer would handle this. Is this approach acceptable? Thanks Christopher

1 0

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 24 Feb '15

24 Feb '15

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 0 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 22 packages missing signoffs * 11 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.) == Incomplete signoffs for [community] (22 total) == * freevo-1.9.0-14 (any) 0/2 signoffs * mantisbt-1.2.19-2 (any) 0/2 signoffs * acpi_call-1.1.0-24 (i686) 0/1 signoffs * bbswitch-0.8-26 (i686) 0/1 signoffs * kphotoalbum-4.6-2 (i686) 0/1 signoffs * libopenshot-audio-0.0.4-1 (i686) 0/1 signoffs * r8168-8.039.00-10 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-20 (i686) 0/1 signoffs * tp_smapi-0.41-63 (i686) 0/1 signoffs * vhba-module-20140928-6 (i686) 0/1 signoffs * virtualbox-modules-4.3.22-2 (i686) 0/1 signoffs * virtualbox-modules-lts-4.3.22-2 (i686) 0/1 signoffs * acpi_call-1.1.0-24 (x86_64) 0/2 signoffs * bbswitch-0.8-26 (x86_64) 0/2 signoffs * kphotoalbum-4.6-2 (x86_64) 0/2 signoffs * libopenshot-audio-0.0.4-1 (x86_64) 0/2 signoffs * r8168-8.039.00-10 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-20 (x86_64) 0/2 signoffs * tp_smapi-0.41-63 (x86_64) 0/2 signoffs * vhba-module-20140928-6 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.22-2 (x86_64) 0/2 signoffs * virtualbox-modules-lts-4.3.22-2 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (11 total) == * freevo-1.9.0-14 (any), since 2014-08-27 * r8168-8.039.00-10 (i686), since 2015-02-09 * r8168-8.039.00-10 (x86_64), since 2015-02-09 * tp_smapi-0.41-63 (i686), since 2015-02-09 * tp_smapi-0.41-63 (x86_64), since 2015-02-09 * vhba-module-20140928-6 (i686), since 2015-02-09 * vhba-module-20140928-6 (x86_64), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (i686), since 2015-02-09 * rt3562sta-2.4.1.1_r1-20 (x86_64), since 2015-02-09 * bbswitch-0.8-26 (i686), since 2015-02-09 * bbswitch-0.8-26 (x86_64), since 2015-02-09 == Top five in signoffs in last 24 hours == 1. djgera - 3 signoffs

1 0

[aur-general] How to replace in AUR a PKGBUILD providing split packages ?
by Rafael Ferreira 24 Feb '15

24 Feb '15

Hi there. I maintain the package-base lib32-smbclient [1], which provides packages lib32-smbclient [2] and lib32-libwbclient [3]. I'd like to simply rename this package-base to "lib32-samba". Since these packages already exist in AUR, I cannot simply upload and replace them. How can provide the renamed package base, replacing the old lib32-smbclient package-base? [1] https://aur.archlinux.org/pkgbase/lib32-smbclient/ [2] https://aur.archlinux.org/packages/lib32-smbclient [3] https://aur.archlinux.org/packages/lib32-libwbclient/ Thanks, Rafael

2 1