[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 3 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 3 packages missing signoffs * 0 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 (3 total) == * luarocks-2.1.2-1 (any) * python-tornado-3.2.0-1 (i686) * python-tornado-3.2.0-1 (x86_64) == Incomplete signoffs for [community] (3 total) == * luarocks-2.1.2-1 (any) 0/2 signoffs * python-tornado-3.2.0-1 (i686) 0/1 signoffs * python-tornado-3.2.0-1 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. eric - 2 signoffs 2. fyan - 1 signoffs
Re: [aur-general] Bundled applications policy?
Hi, Bump. Maintainer has abandoned the package in the meantime, so please remove the package (link for convenience: https://aur.archlinux.org/packages/manarchy/ ). Cheers, WorMzy On 26 December 2013 16:43, WorMzy Tykashi wrote: > Hi, > > I posted a message on the package, but the maintainer has not > responded yet. Their email is also not a recognised email address (I > have tried to contact them regarding my suggestions) > > I should have clarified in my last mail that this package is not my > own, but one that was brought to my attention on the Arch forums by a > new user seeking assistance with it. > > Since the owner is unreachable, would it be possible to remove the > package now (despite the two week rule). If preferred, I'll write a > PKGBUILD for the beta aircrack-ng package and update the theharvester > PKGBUILD so that the AUR status quo is maintained. I'll immediately > aurphan these packages so that someone else can maintain them, > however, as I have no interest in these tools.. > > Please let me know what your thoughts are, and how we should best proceed. > > Happy holidays, > > > WorMzy > > On 20 December 2013 13:35, Rashif Ray Rahman wrote: >> On 20 December 2013 04:20, WorMzy Tykashi wrote: >>> On 19 December 2013 18:44, Rashif Ray Rahman wrote: Just provide for and conflict with the relevant packages and you don't give anyone any trouble. >>> >>> It's halfway there, it doesn't conflict with or provide theharvester >>> package, though that's something I was going to mention when I comment >>> about some changes they should make to the PKGBUILD (shouldn't be an >>> 'any' package, binaries shouldn't be in /usr/sbin, etc.). I just >>> wanted to check that such packages are allowed before prompting them >>> to fix it up. >>> But if this whole thing is a package of a real software collection (and not just a mash-up by a packager) then I see no problem. >>> >>> It's the latter, the package pulls from two different, unrelated >>> sources and merges them into one package. The only thing is, neither >>> source is otherwise available on the AUR or official repositories (as >>> far as I can tell). >> >> A better way to rephrase what I meant is this: if it's a useful bundle >> that people will use (if some people find the beta dep better), then >> there is no problem. The "Arch way" would be to provide a separate >> package for the beta dep instead, but you can tell if your idea (of >> bundling) is working if nobody says anything about that. >> >> >> -- >> GPG/PGP ID: C0711BF1
[aur-general] Deletion request: wxgtk3.0
Hi there. wxgtk3.0 [1], package created and maintained by me, isn't needed anymore since this version is already in [community]. Please delete it. [1] https://aur.archlinux.org/packages/wxgtk3.0/ Thanks, Rafael Ferreira
Re: [aur-general] Bundled applications policy?
Apologies for top posting.
Re: [aur-general] Deletion request: wxgtk3.0
On Wed, Jan 15, 2014 at 11:35 AM, Rafael Ferreira wrote: > Hi there. > > wxgtk3.0 [1], package created and maintained by me, isn't needed anymore > since this version is already in [community]. Please delete it. > > [1] https://aur.archlinux.org/packages/wxgtk3.0/ > > Thanks, > Rafael Ferreira > Deleted, thx. -- Maxime
Re: [aur-general] Bundled applications policy?
On Wed, Jan 15, 2014 at 11:36 AM, WorMzy Tykashi wrote: > Apologies for top posting. > Gone, thx. -- Maxime
[aur-general] libftdi merge request
Hi, Could mingw-w64-libftdi1 be renamed to mingw-w64-libftdi https://aur.archlinux.org/packages/mingw-w64-libftdi1/ That way it'll be consistent with the renaming in extra repo: https://www.archlinux.org/packages/extra/x86_64/libftdi/ Regards, xan.
[aur-general] tint2 packages cleanup
Hi, Please remove (or merge with [1]) the following packages: tint2-svn-gnome-shell [2] -- using an archaic PKGBUILD template, relies on patches not included in the source array. tint2-graph [3] -- is incorrectly named (uses svn), uses old PKGBUILD template, is orphaned, and is redundant (tint2-svn applies the same patch). Cheers, WorMzy [1] https://aur.archlinux.org/packages/tint2-svn/ [2] https://aur.archlinux.org/packages/tint2-svn-gnome-shell/ [3] https://aur.archlinux.org/packages/tint2-graph/
Re: [aur-general] tint2 packages cleanup
Hi, On 15/01/14 14:18, WorMzy Tykashi wrote: > Please remove (or merge with [1]) the following packages: > > tint2-svn-gnome-shell [2] -- using an archaic PKGBUILD template, > relies on patches not included in the source array. Deleted. > tint2-graph [3] -- is incorrectly named (uses svn), uses old PKGBUILD > template, is orphaned, and is redundant (tint2-svn applies the same > patch). Deleted. Thanks for the request. I deleted 'tint2-svn-gnome-shell' and 'tint2-graph' because they didn't have any useful comments worth merging. -- Regards, Martin.
[aur-general] package review and merge request
Could someone look over my package python2-django-extensions [1]? In particular, I'm curious about a namcap warning. [2] Namcap complains that python should be a dependency, because some scripts call python. However, this is a python 2 package, so that warning seems nonsensical. Thoughts? If all seems well, could someone merge django-extensions [3] into python2-django-extensions [1]? The current maintainer is OK with the merge, as per comments on the AUR. [1] https://aur.archlinux.org/packages/python2-django-extensions/ [2] http://pastebin.com/5VVhHnSQ [3] https://aur.archlinux.org/packages/django-extensions/
Re: [aur-general] libftdi merge request
> From: xantare...@hotmail.com > To: aur-general@archlinux.org > Date: Wed, 15 Jan 2014 14:01:52 + > Subject: [aur-general] libftdi merge request > > > Hi, > > Could mingw-w64-libftdi1 be renamed to mingw-w64-libftdi > https://aur.archlinux.org/packages/mingw-w64-libftdi1/ > > That way it'll be consistent with the renaming in extra repo: > https://www.archlinux.org/packages/extra/x86_64/libftdi/ > > Regards, > xan. You need to upload the new PKGBUILD then request that the old package be merged into the new one.
Re: [aur-general] package review and merge request
> Date: Wed, 15 Jan 2014 10:41:30 -0500 > From: ichimonj...@gmail.com > To: aur-general@archlinux.org > Subject: [aur-general] package review and merge request > > Could someone look over my package python2-django-extensions [1]? In > particular, I'm curious about a namcap warning. [2] Namcap complains that > python should be a dependency, because some scripts call python. However, > this is a python 2 package, so that warning seems nonsensical. Thoughts? > > If all seems well, could someone merge django-extensions [3] into > python2-django-extensions [1]? The current maintainer is OK with the merge, > as per comments on the AUR. > > [1] https://aur.archlinux.org/packages/python2-django-extensions/ > [2] http://pastebin.com/5VVhHnSQ > [3] https://aur.archlinux.org/packages/django-extensions/ Not nonsensical, if the script calls "python", it will run with python3. If they should be python2, you need to change the shebang yourself as part of the PKGBUILD.
Re: [aur-general] package review and merge request
Am 15.01.2014 20:07, schrieb Doug Newgard: > >> Date: Wed, 15 Jan 2014 10:41:30 -0500 >> From: ichimonj...@gmail.com >> To: aur-general@archlinux.org >> Subject: [aur-general] package review and merge request >> >> Could someone look over my package python2-django-extensions [1]? In >> particular, I'm curious about a namcap warning. [2] Namcap complains that >> python should be a dependency, because some scripts call python. However, >> this is a python 2 package, so that warning seems nonsensical. Thoughts? >> >> If all seems well, could someone merge django-extensions [3] into >> python2-django-extensions [1]? The current maintainer is OK with the merge, >> as per comments on the AUR. >> >> [1] https://aur.archlinux.org/packages/python2-django-extensions/ >> [2] http://pastebin.com/5VVhHnSQ >> [3] https://aur.archlinux.org/packages/django-extensions/ > > Not nonsensical, if the script calls "python", it will run with python3. If > they should be python2, you need to change the shebang yourself as part of > the PKGBUILD. As Doug already stated, the scripts have a python3 shebang, so you need to change it. You can add a prepare() function like this: https://paste.xinu.at/FprPT/bash Please make sure the scripts are actually intended for python2, though. Also, I don't think you need to include the LICENSE file directly, as the tarball has the same file and you are actually copying that. best regards, carstene1ns signature.asc Description: OpenPGP digital signature
Re: [aur-general] libftdi merge request
> From: scimmi...@outlook.com > To: aur-general@archlinux.org > Date: Wed, 15 Jan 2014 13:08:09 -0600 > Subject: Re: [aur-general] libftdi merge request > > > > From: xantare...@hotmail.com > > To: aur-general@archlinux.org > > Date: Wed, 15 Jan 2014 14:01:52 + > > Subject: [aur-general] libftdi merge request > > > > > > Hi, > > > > Could mingw-w64-libftdi1 be renamed to mingw-w64-libftdi > > https://aur.archlinux.org/packages/mingw-w64-libftdi1/ > > > > That way it'll be consistent with the renaming in extra repo: > > https://www.archlinux.org/packages/extra/x86_64/libftdi/ > > > > Regards, > > xan. > > You need to upload the new PKGBUILD then request that the old package be > merged into the new one. ok, done.
Re: [aur-general] package review and merge request
> Date: Wed, 15 Jan 2014 20:32:00 +0100
> From: a...@carsten-teibes.de
> To: aur-general@archlinux.org
> Subject: Re: [aur-general] package review and merge request
>
> Am 15.01.2014 20:07, schrieb Doug Newgard:
>>
>>> Date: Wed, 15 Jan 2014 10:41:30 -0500
>>> From: ichimonj...@gmail.com
>>> To: aur-general@archlinux.org
>>> Subject: [aur-general] package review and merge request
>>>
>>> Could someone look over my package python2-django-extensions [1]? In
>>> particular, I'm curious about a namcap warning. [2] Namcap complains that
>>> python should be a dependency, because some scripts call python. However,
>>> this is a python 2 package, so that warning seems nonsensical. Thoughts?
>>>
>>> If all seems well, could someone merge django-extensions [3] into
>>> python2-django-extensions [1]? The current maintainer is OK with the merge,
>>> as per comments on the AUR.
>>>
>>> [1] https://aur.archlinux.org/packages/python2-django-extensions/
>>> [2] http://pastebin.com/5VVhHnSQ
>>> [3] https://aur.archlinux.org/packages/django-extensions/
>>
>> Not nonsensical, if the script calls "python", it will run with python3. If
>> they should be python2, you need to change the shebang yourself as part of
>> the PKGBUILD.
>
> As Doug already stated, the scripts have a python3 shebang, so you need
> to change it. You can add a prepare() function like this:
> https://paste.xinu.at/FprPT/bash
> Please make sure the scripts are actually intended for python2, though.
>
> Also, I don't think you need to include the LICENSE file directly, as
> the tarball has the same file and you are actually copying that.
>
> best regards,
> carstene1ns
>
Very close to the commands I would use, but I would suggest putting a "$" on the
end of the match to make sure that "env python" is the end of the line. That
safeguards against them changing the shebang in the future and you ending up
with
"env python22" if you don't notice the change.
sed -i 's|bin/env python$|&2|' management/commands/{dumpscript,pipchecker}.py
sed -i 's|bin/python$|&2|' utils/dia2django.py
Re: [aur-general] Promoting use of .AURINFO
On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > On Tue, 14 Jan 2014 at 19:59:28, Dave Reisner wrote: > > [...] > > The library includes an output format which I've created based on the > > last discussion from pacman-dev; in particular a post from Allan [1]. > > This can easily be changed if we forsee undesirable shortcomings. I > > should note that the format emphasizes split packages as a first class > > citizen. My hope is that this can be leveraged to introduce proper > > support for split packages in the AUR eventually. I realize that this > > probably means work on the AUR side (which I likely won't contribute to) > > in order to integrate my solution, but I firmly believe it's worthwhile > > if support for split packages is a desirable goal for the AUR (please > > tell me it is). > > > > Along with this code, I've created two other utilities: > > > > - parse_aurinfo.py: A parser implementation for the proposed .AURINFO > > format written in python. > > - mkaurball: A shell script which creates a source tarball and appends > > the generated .AURINFO file to the tarball. > > > > There's also a debugging utility which simply imports the lib and > > dumps an .AURINFO file from a PKGBUILD you point it at. > > Awesome! I will give it a try soon. Split packages are definitely a > desirable goal for the AUR but that feature requires a lot of work on > the AUR side indeed. I won't be able to do much AUR coding until April > or May, so what I suggest is the following strategy: > > * Test your utility. Do some manual tests and automated tests you > described below. Fix common use cases. So this went pretty well. I chose the automated route since I'm a little short on time (traveling tomorrow) and wrote some more python. Basically, it uses my tools to convert PKGBUILD -> .AURINFO -> python, and compares that against the parsed output of 'pacman -Si $repo/$pkg'. PKGBUILDs all come from ABS. As is the nature of ABS, there's bound to be differences between the archived PKGBUILD and the actual PKGBUILD that produced the package currently in the repos. There's bound to be false positives which may vary from day to day. Still, this gives a test bed of ~5000 PKGBUILDs to play with. Out of those, I'm able to fully match the repo 99.1% of the time (including false positives). I can actually boast a 100% strike rate on [extra], as the only differences were caused by out of sync PKGBUILDs which were otherwise correctly parsed. Legitimate problems fell into the expected categories: 1) architecture specifics (examples: core/grub, multilib/dev86) This is obvious, and I knew it would be here. Fixing this requires changes in makepkg. (something like depends_x86_64=(..) or what have you). This cannot reasonably be fixed in any parser. 2) external commands (examples: community/haskell-*, core/perl) I'd suggest that we consider some of these to be false positives or unfixable. The haskell packages all rely on the output of 'pacman -Q ghc' to lock the package to a specific GHC version (I'm not a haskell person). perl just jumps the shark and requires you to be on one of a few Arch servers (it unzips a tarball in a very specific location). 3) core/linux This is an interesting case and gets special mention. The goal of this hackery is to make it easier for folks maintaining custom versions of this PKGBUILD to track and merge changes. I suspect that a legitimate solution to this problem could handled in the PKGBUILD by introducing a new variable, pkgsuffix=, similar to the --with-program-suffix flag that automake offers. The code that I used for all of the above has been pushed, and I'm attaching a tarball of my results from the 4 repos I parsed in case anyone is curious in the gory details. Cheers, Dave parsed_repos.tar.gz Description: Binary data
Re: [aur-general] package review and merge request
> Also, I don't think you need to include the LICENSE file directly, as > the tarball has the same file and you are actually copying that. Whoops. Thank you. I've fixed that. > Please make sure the scripts are actually intended for python2, though. I just posted to the django-extensions google group/mailing list. Hopefully, they can clarify whether the scripts are compatible with Python 2. In the mean time, I've simply made the python2-django-extensions package depend upon Python 3 as well as Python 2. I don't exactly love the solution, but it seems to be the safest route. --Jeremy
[aur-general] Delete/Merge Requests [Jan 15]
Merge: https://aur.archlinux.org/packages/ttf-ptsans into https://aur.archlinux.org/packages/ttf-paratype (duplicate) https://aur.archlinux.org/packages/ttf-ffftusj/ into https://aur.archlinux.org/packages/ttf-fff-tusj/ (duplicate) https://aur.archlinux.org/packages/kupfer-mpris2-plugin/ into https://aur.archlinux.org/packages/kupfer-mpris2-plugin-git/ (no released versions, only git) Delete: https://aur.archlinux.org/packages/processing-beta/ (no prerelease available, processing is in [community] https://aur.archlinux.org/packages/ttf-ironmaiden-fonts/ (sources disappeared, domain is gone)
Re: [aur-general] package review and merge request
User "Trbs" from the mailing list replied [1] promptly. He stated that the shebangs should not exist and suggested I create a patch to remove them entirely. (He also removed the shebangs from the official repo.) Thanks for the sample code, Doug and carstene1ns. I used it as the basis for a prepare() function that removes shebangs. I tested the package [2] on a python 2 django project I have handy. In particular, I made sure to exercise the dumpscript.py and pipchecker.py scripts. No problems. [1] https://groups.google.com/d/msg/django-extensions/KBXVARby3ps/JRfU2kiG0foJ [2] https://aur.archlinux.org/packages/py/python2-django-extensions/PKGBUILD
[aur-general] Looking for adopters.
I maintain a series of rubygems on the AUR. I've know moved to rbenv and do not use them anymore. Please if you want to maintain a package please send me the name and I will disown it. Since they are too many to enlist by hand, here is the list on the AUR[1]. Please note that this is for my ruby-* packages only, I will keep mainating the non ruby packages. Also you can checp my git repository[2] if you want access to the history. Thank you in advance. [1] https://aur.archlinux.org/packages/?SeB=m&K=masterkorp&O=0&PP=50 [2] https://github.com/masterkorp/pkgbuilds -- Regards, Alfredo Palhares
Re: [aur-general] Looking for adopters.
Hi, Alfredo On Wed, Jan 15, 2014 at 7:42 PM, Alfredo Palhares wrote: > I maintain a series of rubygems on the AUR. I've know moved to rbenv > and do not use them anymore. > > Please if you want to maintain a package please send me the name and > I will disown it. > > Since they are too many to enlist by hand, here is the list on the > AUR[1]. > > Please note that this is for my ruby-* packages only, I will keep > mainating the non ruby packages. Also you can checp my git repository[2] > if you want access to the history. I own ~230 ruby packages [1] and can take care of yours as well. If you don't mind I'll spend a few days converting your PKGBUILD files to style I use for gem packages. Once I done with it you can mass disown the packages. Thanks. [1] https://github.com/anatol/archpackages
[aur-general] Deletion request
These packages should be deleted as they were renamed some time ago: https://aur.archlinux.org/packages/python-pyivi-git/ https://aur.archlinux.org/packages/python-pyvxi11-git/ Thanks Alex Forencich
Re: [aur-general] Can we force the maintainer to change package name?
On Wed, Jan 15, 2014 at 7:39 AM, Rashif Ray Rahman wrote: > On 12 January 2014 23:42, Karol Blazewicz wrote: >> On Fri, Dec 20, 2013 at 3:41 PM, Karol Blazewicz >> wrote: >>> On Fri, Dec 20, 2013 at 3:19 PM, Lukas Jirkovsky >>> wrote: On Fri, Dec 20, 2013 at 2:24 PM, Rashif Ray Rahman wrote: > Since there was no 'rstudio' at the time that user uploaded this one, > there is no infringement of any rule or guideline per se. Just tell > them to upload an 'r-studio' to mitigate the confusion that resulted > from it. I don't think there is any need to merge unless there were > relevant comments. It is up to the maintainer to update the PKGBUILD > with the suggested changes. The question is whether the maintainer is still active at all. Hist last action is 2012-08-27 and he has only two packages, both over the year old with one being flagged out of date since February. Lukas >>> >>> e-mail sent. >>> If he doesn't respond in two weeks, maybe a TU can reupload and disown >>> it, or remove it from the AUR altogether, whichever is deemed the >>> correct action. >> >> The maintainer has taken no action and didn't respond to my e-mail. > > Did your e-mail actually get through to that address? It's being > returned here, and if we'd known this before we could've just gone > ahead and done what we wanted. An non-existent e-mail address is close > to meaning a non-existent user. > > > -- > GPG/PGP ID: C0711BF1 It wasn't returned. I e-mailed him and got no response, neither automated nor personal, no error, nothing.
