Re: [aur-general] AUR request notify mails
On Mon, 2020-08-10 at 19:33 +0200, Morten Linderud via aur-general wrote: > The email has the CC. > > To: aur-reque...@archlinux.org > Cc: not...@aur.archlinux.org, alejandroval...@live.com, > michael.stra...@posteo.de > > Can you verify that the email wasn't caught by any spam filters? > I hadn't noticed it before, but now that Michael mentions it, I've sent two requests over the past weeks myself and I haven't gotten a notification of either. In that time frame, I have received other AUR notifications. I run my own mail server and I'm 100% sure it hasn't been caught by the spam filter by accident as those are filed somewhere and I don't see them there. Best, Bert. signature.asc Description: This is a digitally signed message part
Re: [aur-general] What is pkgrel and why/how should I use it?
On Tue, 2020-03-03 at 13:29 -0600, karx via aur-general wrote: > Hi Georg, thank you for your reply. > If I am understanding correctly, pkgrel is for changes to the > PKGBUILD, and pkgver is for changes to the actual sources. Is this > correct? > > Yash Correct. Although the PKGBUILD doesn't have to have significant changes; it can just be that other packages changed instead. You can look at the history of the shellcheck PKGBUILD [1] to get an idea. Bert. [1]: https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/shellcheck signature.asc Description: This is a digitally signed message part
Re: [aur-general] Upgrade AUR visp package to get ViSP 3.3.0 release
On Tue, 2020-02-25 at 11:02 +0100, Fabien Spindler wrote:
> Hi,
>
> There is the visp package: https://aur.archlinux.org/packages/visp/
> that needs to be updated with 3.3.0 release.
>
> In https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=visp
> changes
> should be
>
> > pkgver=3.3.0 ||md5sums=('||b210fff3c47f362c54238f33759d6e7d') |
>
> I would appreciate if someone can update the package.
>
> Thanks
>
> Fabien
>
Try to contact the maintainer first; his email is in the PKGBUILD. If
that fails, you can submit an orphan request and hope that someone
picks it up, or pick it up yourself.
Cheers,
Bert.
Re: [aur-general] review of getax2019 PKGBUILD
On Sun, 2020-02-23 at 13:17 +0100, Yoan Blanc via aur-general wrote: > Hi folks, > > I've built my first PKGBUILD based on Brunio Renié's vaudtax, > https://aur.archlinux.org/packages/vaudtax/ > > https://gitlab.com/greut/getax > > Do you think I could propose it as is to aur-request? Do you see > anything > that could be improved? > > Cheers, > Some things that stand out: - You prepare shouldn't ever download things; you should use the sources array for that. - The build function isn't mandatory and can be left out if unused. - The included `getax` script checks for java somehow, which is a direct dependency. If this script comes from somewhere else, include it in the sources array. Otherwise, just assume that your dependencies are actualy isntalled. - You should consistently quote $srcdir and $pkgdir since they may contain spaces. - Not sure if there is a rule about it, but a package description in French seems odd to me. - You depend on a specific java package rather than a specific java version, or just java-environment. Why? - Take a look at the java packaging guidelines in [1], it has more general tips wrt to packaging java apps. Cheers, Bert. [1]: https://wiki.archlinux.org/index.php/Java_package_guidelines signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
Hi Jean Lucas, I've been reading your TU application and I wish you the best of luck. However, I can't seem to find the GPG key you're using on any keyservers. Did you happen to forget to submit it somewhere? Best, Bert. signature.asc Description: This is a digitally signed message part
Re: [aur-general] PKGBUILD rfc
On Mon, 2019-08-05 at 12:51 +0500, Vladimir Bauer via aur-general wrote: > Hi! > > I have a PKGBUILD I would like to submit: > https://github.com/vbauerster/getparty-PKGBUILD > > What is further steps? > https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Submitting_packages but before that: https://wiki.archlinux.org/index.php/Go_package_guidelines Your PKGBUILD also doesn't install the license yet, which it really should. You can find out more by browsing the wiki pages on packaging a bit. Cheers, Bert. signature.asc Description: This is a digitally signed message part
[aur-general] Spam account
Hi all, The spam account jha321 just left a comment on ruby-yajl-ruby, and a few others. Could he be deleted? https://aur.archlinux.org/account/jha321/comments signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 16:10: On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight. That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters.
Re: [aur-general] Help with python-magic-wormhole PKGBUILD
On Mon, 2018-12-10 at 11:17 -0500, Eli Schwartz via aur-general wrote: > The package_*() depends override globally listed depends. If pikaur > does > not try to install the global depends together with the makedepends > before the build happens... this is a bug in pikaur and pikaur is > broken. > > This is regardless of whether the PKGBUILD "should" use global > depends. I wasn't insisting that the original package was wrong, I was reproducing the bug that Storm asked about. I wouldn't be surprised if other AUR helpers have this issue too. Thanks for clarifying the correct behaviour; I've created an issue for this. Best, Bert. signature.asc Description: This is a digitally signed message part
Re: [aur-general] Help with python-magic-wormhole PKGBUILD
On Mon, 2018-12-10 at 10:24 -0500, Storm Dragon via aur-general wrote: > Howdy, > > I have had a few people post that they are having trouble with this > since it became a split package. Currently, I am unable to reproduce > the problems. I have installed it both with yay and with makepkg. I > do see one who tried to install it as a group, and since both provide > the same package, that would conflict, but they should be able to > install either python2-magic-wormhole or python-magic-wormhole. > > I Can't find anything wrong with the PKGBUILD. Can someone please > take a look and let me know if there's anything I can do to make it > work better for these people who are having problems? > > https://aur.archlinux.org/pkgbase/magic-wormhole/ > > Thanks, > Storm I can confirm that pikaur does not properly handle the package. The problem appears to be that the PKGBUILD requires both the python- and python2-versions of dependencies, but both of the splits then define their own depends. Pikaur then installs only the depends for the version that I specify (I tried python 3 first) and ignores the python 2 versions. Then when "makepkg -s" is called, it complains that the python2 versions of the AUR packages cannot be found. (repo packages are fine, of course) I don't know if this is a bug, but you can probably work around this by moving all those dependencies to the makedepends if you need them during the build or remove them altogether otherwise. For me, the latter option works. Best, Bert. signature.asc Description: This is a digitally signed message part
