- Aur-general - lists.archlinux.org

[aur-general] Updating MATE Packages
by Sean Fennell <eadrom> 18 Jun '16

18 Jun '16

Hello All, A couple weeks ago I found out that Martin was no longer going to be able to maintain the MATE desktop packages for Arch Linux [1] [2]. I had a chat with Martin on IRC and confirmed that MATE would need a new maintainer. Since then I've been working on updating the relevant MATE PKGBUILD's from 1.12 to 1.14. I've been getting spun up with how Arch maintains packages, learning more about the PKGBUILD creation and updating processes, and getting set up on the various mailing lists and my AUR profile. The question comes now how do I get these updated PKGBUILD's to the community? If the packages are bumped down from [Community] to the AUR, I would be more than happy to maintain them there. If/when I earn TU status, I would then move them back to the official [Community] repository. The drawback there is a major DE would no longer be in an official Arch repository and would require users manually building each updated PKGBUILD or to use an AUR helper. Alternatively, perhaps a current TU could use my updated PKGBUILD's to get MATE 1.14 out to the community while I work on earning TU status and can then maintain the packages directly at a later date. To head off any ideas about my motivations here, I am not trying to leverage this issue to bypass or fasttrack past any TU requirements. I realize I'm pretty much unknown in the Arch community. I would like to change that with good work. To the matter at hand, what is going to be the best way to get the MATE packages updated? What is my next step in that process? I'm eager to get my hands dirty helping out with maintaining MATE (and other packages as well). Thank you, Sean Fennell <eadrom> [1] https://lists.archlinux.org/pipermail/aur-general/2016-May/032306.html [2] https://www.reddit.com/r/archlinux/comments/4kakzk/

5 16

[aur-general] What's the process for changing a package name?
by Forest Crossman 18 Jun '16

18 Jun '16

greenpak-designer-dev has been updated upstream and renamed to "greenpak-designer". I'd like to update the greenpak-designer-dev package to use the new name, but I'm not sure how to proceed. I've thought of a few methods, but I don't know which ones would work best, if at all: - Change $pkgname to the new name, add the old name to $conflicts and $replaces, regenerate .SRCINFO, commit and push to greenpak-designer-dev.git (current remote). - Do the previous steps, but push to greenpak-designer.git (new remote). I'm also not sure if I'd need to merge packages at some point in order to preserve votes and comments, too. Also, if I make a new package, I'm not sure if I should include the old package's git history or initialize a new repo. Thoughts? -- Forest Crossman

2 1

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 18 Jun '16

18 Jun '16

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 1 new package in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 10 packages missing signoffs * 5 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 (1 total) == * salt-2016.3.1-1 (any) == Incomplete signoffs for [community] (10 total) == * avr-libc-2.0.0-2 (any) 0/2 signoffs * salt-2016.3.1-1 (any) 0/2 signoffs * avr-gcc-6.1.1-1 (i686) 0/1 signoffs * avr-gdb-7.11.1-1 (i686) 0/1 signoffs * python-biopython-1.67-1 (i686) 0/1 signoffs * rofi-1.1.0-1 (i686) 0/1 signoffs * avr-gcc-6.1.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.11.1-1 (x86_64) 0/2 signoffs * python-biopython-1.67-1 (x86_64) 0/2 signoffs * rofi-1.1.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (5 total) == * avr-gcc-6.1.1-1 (i686), since 2016-05-09 * avr-gcc-6.1.1-1 (x86_64), since 2016-05-09 * avr-libc-2.0.0-2 (any), since 2016-05-10 * avr-gdb-7.11.1-1 (i686), since 2016-06-01 * avr-gdb-7.11.1-1 (x86_64), since 2016-06-01 == Top five in signoffs in last 24 hours ==

1 0

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 17 Jun '16

17 Jun '16

=== 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 * 10 packages missing signoffs * 5 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] (10 total) == * avr-libc-2.0.0-2 (any) 0/2 signoffs * salt-2016.3.0-1 (any) 0/2 signoffs * avr-gcc-6.1.1-1 (i686) 0/1 signoffs * avr-gdb-7.11.1-1 (i686) 0/1 signoffs * python-biopython-1.67-1 (i686) 0/1 signoffs * rofi-1.1.0-1 (i686) 0/1 signoffs * avr-gcc-6.1.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.11.1-1 (x86_64) 0/2 signoffs * python-biopython-1.67-1 (x86_64) 0/2 signoffs * rofi-1.1.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (5 total) == * avr-gcc-6.1.1-1 (i686), since 2016-05-09 * avr-gcc-6.1.1-1 (x86_64), since 2016-05-09 * avr-libc-2.0.0-2 (any), since 2016-05-10 * avr-gdb-7.11.1-1 (i686), since 2016-06-01 * avr-gdb-7.11.1-1 (x86_64), since 2016-06-01 == Top five in signoffs in last 24 hours == 1. bisson - 5 signoffs

1 0

Re: [aur-general] Hi all
by Yousof Zahra 16 Jun '16

16 Jun '16

Hi all ! now I am in mailing list ! how I can send My PKGBUILD to AUR-Repusitory ?😀

3 3

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 16 Jun '16

16 Jun '16

=== 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 * 10 packages missing signoffs * 5 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] (10 total) == * avr-libc-2.0.0-2 (any) 0/2 signoffs * salt-2016.3.0-1 (any) 0/2 signoffs * avr-gcc-6.1.1-1 (i686) 0/1 signoffs * avr-gdb-7.11.1-1 (i686) 0/1 signoffs * python-biopython-1.67-1 (i686) 0/1 signoffs * rofi-1.1.0-1 (i686) 0/1 signoffs * avr-gcc-6.1.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.11.1-1 (x86_64) 0/2 signoffs * python-biopython-1.67-1 (x86_64) 0/2 signoffs * rofi-1.1.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (5 total) == * avr-gcc-6.1.1-1 (i686), since 2016-05-09 * avr-gcc-6.1.1-1 (x86_64), since 2016-05-09 * avr-libc-2.0.0-2 (any), since 2016-05-10 * avr-gdb-7.11.1-1 (i686), since 2016-06-01 * avr-gdb-7.11.1-1 (x86_64), since 2016-06-01 == Top five in signoffs in last 24 hours ==

1 0

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

15 Jun '16

=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 10 packages missing signoffs * 3 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 (2 total) == * rofi-1.1.0-1 (i686) * rofi-1.1.0-1 (x86_64) == Incomplete signoffs for [community] (10 total) == * avr-libc-2.0.0-2 (any) 0/2 signoffs * salt-2016.3.0-1 (any) 0/2 signoffs * avr-gcc-6.1.1-1 (i686) 0/1 signoffs * avr-gdb-7.11.1-1 (i686) 0/1 signoffs * python-biopython-1.67-1 (i686) 0/1 signoffs * rofi-1.1.0-1 (i686) 0/1 signoffs * avr-gcc-6.1.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.11.1-1 (x86_64) 0/2 signoffs * python-biopython-1.67-1 (x86_64) 0/2 signoffs * rofi-1.1.0-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (3 total) == * avr-gcc-6.1.1-1 (i686), since 2016-05-09 * avr-gcc-6.1.1-1 (x86_64), since 2016-05-09 * avr-libc-2.0.0-2 (any), since 2016-05-10 == Top five in signoffs in last 24 hours ==

1 0

[aur-general] PKGBUILD review request: understand-bin
by Alex Sarum 14 Jun '16

14 Jun '16

Hello, This is my first PKGBUILD. If someone has time, I would like to get some reviews from other archers. https://gitlab.com/saruman9/pkgbuilds/tree/master/understand-bin -- Alex

3 3

[aur-general] Signoff report for [community-testing]
by Arch Website Notification 14 Jun '16

14 Jun '16

=== 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 * 10 packages missing signoffs * 3 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] (10 total) == * avr-libc-2.0.0-2 (any) 0/2 signoffs * salt-2016.3.0-1 (any) 0/2 signoffs * avr-gcc-6.1.1-1 (i686) 0/1 signoffs * avr-gdb-7.11.1-1 (i686) 0/1 signoffs * fcitx-qt5-1.0.5-3 (i686) 0/1 signoffs * python-biopython-1.67-1 (i686) 0/1 signoffs * avr-gcc-6.1.1-1 (x86_64) 0/2 signoffs * avr-gdb-7.11.1-1 (x86_64) 0/2 signoffs * fcitx-qt5-1.0.5-3 (x86_64) 0/2 signoffs * python-biopython-1.67-1 (x86_64) 0/2 signoffs == All packages in [community-testing] for more than 14 days (3 total) == * avr-gcc-6.1.1-1 (i686), since 2016-05-09 * avr-gcc-6.1.1-1 (x86_64), since 2016-05-09 * avr-libc-2.0.0-2 (any), since 2016-05-10 == Top five in signoffs in last 24 hours == 1. bisson - 3 signoffs

1 0

[aur-general] Thoughts on managing spurious deletion requests...
by Patrick Burroughs (Celti) 14 Jun '16

14 Jun '16

It seems like not a day goes by where I don't see someone asking for help building, installing, or using a package in the comments of a deletion or orphan request. I know that several methods have been tried to reduce this, but they haven't helped — so has anyone considered bowing to the inevitable and adding an "Assistance" request type to the "Submit Request" dropdown, and of course making it the default? It could simply post a comment on the package page, perhaps with a special flag, or perhaps have it email the package maintainer. ~Celti

2 1