- Aur-general - lists.archlinux.org

[aur-general] PKGBUILD for Automatic Arch System Maintenance
by Michael Dobachesky 07 Jul '18

07 Jul '18

Hello everyone, I have been working on a package that automatically does Arch Linux system maintenance tasks like updating, cleaning, error checking, etc. It has really helped me out and I am hoping that it will help out others as well. Development has gotten to the point where I feel comfortable releasing the first official version, so I have prepared a PKGBUILD for it. I have not published any packages to the AUR in the past so, as per the suggestions on the Arch Linux AUR Wiki, I am submitting the PKGBUILD to the AUR mailing list for review. Here is a link to the PKGBUILD: https://gitlab.com/mgdobachesky/ArchSystemMaintenance/raw/master/PKGBUILD Thank you all for your time, Michael Dobachesky

2 2

[aur-general] aurweb 4.7.0 released
by Lukas Fleischer 07 Jul '18

07 Jul '18

Dear aurweb contributors and users, We are pleased to announce that aurweb 4.7.0 has been released! New features are the possibility to search by depends as well as an API rate limit in the RPC interface. Moreover, co-maintainers can now remove themselves from the co-maintainer list. This release also includes several fixes and improvements to the comment and notification features, as well as other bug fixes. For a comprehensive list of changes, please consult the Git log [2]. As usual, bugs should be reported to the aurweb bug tracker [3]. [1] https://aur.archlinux.org/ [2] https://projects.archlinux.org/aurweb.git/log/?id=v4.7.0 [3] https://bugs.archlinux.org/index.php?project=2

1 0

[aur-general] pkgrel - Is it correct that some "fixes" aren't "fixes"?
by Ralf Mardorf 22 Jun '18

22 Jun '18

Hi, see https://aur.archlinux.org/packages/dh-make/ for "The fix of the source url was neither a fix...". Is it correct that some "fixes" aren't considered as being "fixes", so that the pkgrel shouldn't increase? Regards, Ralf

4 5

[aur-general] Delete spam comment/account from aur
by Maxim Andersson 15 Jun '18

15 Jun '18

Regarding this page https://aur.archlinux.org/packages/aur-comment-fetcher-git/ Could the comment from 2018-06-06 (and maybe spammer-account?) please be deleted. Thanks!

4 3

[aur-general] Request deletion of python-django2
by Daniel Moch 06 Jun '18

06 Jun '18

Since python-django has moved to Django 2, I’d like to request that python-django2 be deleted from the AUR. Thanks. Daniel Moch daniel(a)danielmoch.com https://djmo.ch

2 1

[aur-general] upgrade of "conf.d/*.conf"-style packages containing example configs
by J. Konrad Tegtmeier-Rottach 31 May '18

31 May '18

Hi, I've run into a general issue with software packages that use a configuration directory, aggregate configs therein using a glob rule on the filenames, and contain an example config. An example is `community/consul`, which - globs for `/etc/consul.d/*.{hcl,json}` - contains `/etc/consul.d/example.json` When I configure these types of software first I delete the example file, and then place additional configs in that directory, with everything working as expected. Then an upgrade for that package rolls around, and the example config is recreated. This usually means that as soon as the software reloads, the recreated example config gets loaded, too, and the software tends to fail or behave in byzantine ways. After consulting the wiki about this [0], I had assumed that this is the "original = X, current = Y, new = X" case and the example config shouldn't be recreated, but it seems deletion isn't handled the same as modification here. (.pacnew files aren't an issue since the glob rule is in place) What is the proper way to deal with these example configs? Truncate them to force the XYX upgrade case, which seems hacky? Set `NoUpgrade` [1] in the PKGBUILD, assuming this is applicable here? I ask this here because my `aur/nomad-bin` package has this exact problem. Regards, KT [0] https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave#.pacnew [1] https://wiki.archlinux.org/index.php/Pacman#Skip_file_from_being_upgraded

3 2

[aur-general] Packaging all CRAN packages for R
by Alex Branham 31 May '18

31 May '18

Hi all - I'd like to use pacman to manage R packages, similar to how you can for other languages (e.g. the python packages are all named python-*). There are some packages available already, but not many (I count about 130 currently). I wrote a script[1] that generates PKGBUILDS for all the packages on the Comprehensive R Archive Network (CRAN). There's 12,593 packages on CRAN as of today. If you evaluate the script, then call write_all_pkgbuilds(), R will put each PKGBUILD into PKGBUILDS/r-cran-<pkgname>/PKGBUILD. Here's an example of the output.[2] It doesn't generate .SRCINFO or setup a git repo (yet). It also doesn't take into account (yet) that there are already 130ish R packages on the AUR. I named them r-cran-* rather than r-* because 1) it's clearer where the packages are coming from and 2) it's a pain to search for r-* Is this something people would like to have in the AUR? I figured I should ask before adding ~12.5k packages. Any and all comments/feedback appreciated! Thanks, Alex Footnotes: [1] https://github.com/jabranham/r-cran-pkgbuilds/blob/master/gen-R-PKGBUILDS.R [2] # Maintainer: Alex Branham <email-address-removed> _cranname=A3 _cranver=1.0.0 pkgname=r-cran-a3 pkgver=1.0.0 pkgrel=1 pkgdesc="Supplies tools for tabulating and analyzing the results of predictive models. The methods employed are applicable to virtually any predictive model and make comparisons between different methodologies straightforward." url="https://cran.r-project.org/web/packages/${_cranname}/index.html" arch=('x86_64') license=('GPL') depends=('r-cran-xtable' 'r-cran-pbapply') optdepends=('r-cran-randomforest' 'r-cran-e1071') source=("https://cran.r-project.org/src/contrib/${_cranname}_${_cranver}.tar.gz") md5sums=('027ebdd8affce8f0effaecfcd5f5ade2') package() { mkdir -p ${pkgdir}/usr/lib/R/library cd ${srcdir} R CMD INSTALL ${_cranname} -l ${pkgdir}/usr/lib/R/library }

7 16

[aur-general] TU resignation
by Pierre Neidhardt 31 May '18

31 May '18

I've stopped using Arch ever since I've switched to GuixSD[1] (a functional-oriented distribution focusing on reproducible builds and completely custimizable in Guile Scheme) and it's now quite clear that there will be no coming back. My involvement in this new project and in others (Emacs, Next Browser[2]) takes a lot more time than what I can afford into maintaining my Arch packages. I have a bunch of out-of-date packages in [community]: - emms - qutebrowser - udiskie - uncrustify Other [community] packages: - catdvi - ccrypt - dtach - fzf - gtypist - mu (A user requested that we built msg2pdf as part of the package) - pdfjs (optional for qutebrowser) - pstotext - python-keyutils (required by udiskie) - python-pypeg2 (require by qutebrowser) - tcc - trash-cli - xcape - xss-lock And on the AUR: https://aur.archlinux.org/packages/?K=Ambrevar&SeB=m I hope the Arch community keeps up with the good work! Cheers! [1] https://www.gnu.org/software/guix/ [2] http://next-browser.com/ -- Pierre Neidhardt

5 4

[aur-general] Basilisk pkgbuild is facing a trademark violation?
by Fabio Loli 22 May '18

22 May '18

Mattatobin, of which you can read here https://github.com/jasperla/openbsd-wip/issues/86 Have made this (edited) comment in the AUR webpage asking for removal https://aur.archlinux.org/packages/basilisk You do realize this package is completely insane. I want you to remove any remaining Basilisk branding and use of the name including in the desktop file and this very package from AUR that you are obviously squatting on.

7 8

[aur-general] [PATCH] upgpkg: qutebrowser 1.3.0-1
by Jay Kamat 22 May '18

22 May '18

Hi, The qutebrowser package in community has been behind for quite a while, and unfortunately it fails to start on qt 5.11, so it would be nice to have it bumped before that happens. I noticed that the install fails when bumping the version, due to adding a PREFIX variable instead of hardcoding /usr: https://github.com/qutebrowser/qutebrowser/pull/3844 Per the packaging standards here, this should be /usr/ instead of /usr/local, so I changed it back, and it seems to work properly again: https://wiki.archlinux.org/index.php/Arch_packaging_standards Here is the finished patch. Let me know if anyone sees any issues, this is my first time working with arch packaging. -Jay I sent this email to the list before subscribing, please don't approve that one, as I resent it here.

6 6