Re: [aur-general] Misuse of AUR (yaourt) comments
On 12/02/16 12:05, William Di Luigi wrote: Hi, On Fri, Feb 12, 2016 at 11:35 AM, Dave Blair wrote: Det harassed me with out-of-date notifications too. He seems like a hustler. Not quite sure why anyone would want to hustle AUR packages, doesn't really make sense to me. Just to clarify, I don't think that Det is the one who flagged the package (in fact he/she commented *against* the package being flagged, so there would be no reason for him/her to want the package flagged). If Det has harassed you in the past, you could probably start a new thread about it. However, consider that if a package is *really* out-of-date, then it's expected to get flagged. If a maintainer can't or doesn't want to keep up with updating it, he/she can just click the "Disown Package" button. The package was up to date. It's a long (and boring) story. The harassment and threats came via e-mail. It seems like Det's MO.
Re: [aur-general] Misuse of AUR (yaourt) comments
On 12/02/16 16:20, Pedro A. López-Valencia wrote: No Ralf, you did not misunderstand Det. The guy is a Finnish sociopath hiding behind pseudonyms, that harasses people to grab their popular packages in AUR. I gave him the vuze package to shut him up. If you don't believe me check how many packages he maintains. In AUR3 he used to have more than 600. I'm glad it's not just me then. But why would anyone want to hustle AUR packages? I don't get it. There are loads of orphans around, and maintaining a package can be a pain. It's not like you can make a living off it.
Re: [aur-general] Misuse of AUR (yaourt) comments
Det harassed me with out-of-date notifications too. He seems like a hustler. Not quite sure why anyone would want to hustle AUR packages, doesn't really make sense to me. On 10/02/16 16:15, William Di Luigi wrote: Yeah, I get that. But I don't think Skunnyk is unflagging every day, that's why I asked why it's been flagged for a week straight (9 days, as of today). I would not have asked that at all, had the flag been there for, like, 1 or 2 days :) On Wed, Feb 10, 2016 at 4:12 PM Ralf Mardorf wrote: Reading Det's comments again, it's possible that I misunderstood those comments. However, maybe Skunnyk is sick of unflagging the package two times a day. I doubt that Skunnyk is "inactive", my guess is, that it makes no sense to unflag the package again and again.
Re: [aur-general] Linux packaging
On Tue, Mar 24, 2015 at 07:25:51PM +0100, Javier Domingo Cansino wrote: > Hi, > > I am looking to package rtai, which was already packaged some years ago. I > want to make it easily updatable, and I have a problem. > > RTAI is a kernel patch and some other stuff. > I am now trying to obtain the linux config for an specific arch kernel. > > I was trying to extract it from packages.git, but it's a monstrous repo > and not a good way to obtain the needed object without downloading it all > . > > The svn version is also quite > hacky > , but more affordable, I would svn log, search for the most close version > bump commit and extract that config file (along with the patch). > > Is there any recommended method to build a linux kernel of X version > without having to package the config files? > > Or maybe a git tree that is smaller and reasonable to clone. You can use asp[0] to do a piecemeal checkout. 'asp checkout linux' will give you a tidy git repo with full history of the package. dR [0] https://aur.archlinux.org/packages/asp-git/
Re: [aur-general] AUR password reset
On Sun, Mar 22, 2015 at 06:39:11PM +, Diego Nieto Cid wrote: > Oh I'm sorry. I have some emails from aur-not...@archlinux.org dating back > to 2011 and 2009. So I thought this email was linked to my account. > > I haven't logged in for a long time so unfortunately I can't remember the > username either. But in one email from aur-notify, someone's comment > referred to me as 'mnieto'. So that probably was my username. > > I once was the owner of package > perl-html-formattextwithlinksandtables[1]. However, > in the page for that package my comments now appear under the name of > "Anonymous". Your account was identified as stale and deleted about a month and a half ago: https://lists.archlinux.org/pipermail/aur-general/2015-February/030231.html > Did my account expired? Should I create a new one? Please do. > Thanks! > > -- > [1] > https://aur.archlinux.org/packages/perl-html-formattextwithlinksandtables/ > > > El dom., 22 de marzo de 2015 a las 15:18, Dave Reisner () > escribió: > > > On Sun, Mar 22, 2015 at 05:51:24PM +, Diego Nieto Cid wrote: > > > Hi > > > > > > I'm trying to reset my AUR password but I'm not getting the email with > > the > > > confirmation link. > > > > > > Can somebody reset my account? > > > > No, we can't. You've not provided anything useful in your request. > > There's no account associated with your email address or real name, and > > no user named 'dnietoc'. > > > > dR > >
Re: [aur-general] AUR password reset
On Sun, Mar 22, 2015 at 05:51:24PM +, Diego Nieto Cid wrote: > Hi > > I'm trying to reset my AUR password but I'm not getting the email with the > confirmation link. > > Can somebody reset my account? No, we can't. You've not provided anything useful in your request. There's no account associated with your email address or real name, and no user named 'dnietoc'. dR
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, Dec 29, 2014 at 10:21:17PM -0500, Dave Reisner wrote: > On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: > > Is there currently a script to just create a .SRCINFO from a PKGBUILD? > > I don't want any side effects like downloading src packages (i.e. I > > don't want to run makepkg or mkaurball), etc. since this is for use in > > git filter-branch --tree-filter. > > There exists a tool in the pkgbuild-introspection git repo[1] which will > write a .SRCINFO to standard output when given a PKGBUILD. Pull requests > welcome to give it a better name (mksrcinfo?) and some UI. > > dR > > [1] > https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect Nevermind, this (mksrcinfo) now exists in pkgbuild-introspection-git. Bug reports welcome. dR
Re: [aur-general] AUR 4.0.0 pre-alpha
On Mon, Dec 29, 2014 at 09:49:24PM -0500, Ido Rosen wrote: > Is there currently a script to just create a .SRCINFO from a PKGBUILD? > I don't want any side effects like downloading src packages (i.e. I > don't want to run makepkg or mkaurball), etc. since this is for use in > git filter-branch --tree-filter. There exists a tool in the pkgbuild-introspection git repo[1] which will write a .SRCINFO to standard output when given a PKGBUILD. Pull requests welcome to give it a better name (mksrcinfo?) and some UI. dR [1] https://github.com/falconindy/pkgbuild-introspection/blob/master/introspect
Re: [aur-general] [solved] How to FIX YAOURT after current PACMAN upgrade
On Dec 29, 2014 9:19 AM, "Eugenio M. Vigo" wrote: > > El 29/12/2014 11:48, "Ralf Mardorf" escribió: > > > Hi, > > > > I followed ArthurBorsboom's comment from 2014-12-29 09:31 at > > https://aur.archlinux.org/packages/package-query/. > > > > $ sudo pacman -Rdd package-query > > or > > $ sudo pacman -Rdd package-query-git > > then > > $ wget > > https://aur.archlinux.org/packages/pa/package-query/package-query.tar.gz > > $ tar -xzf package-query.tar.gz ; cd package-query ; makepkg -s > > $ sudo pacman -U package-query-1.5-1-x86_64.pkg.tar.xz > > resp. > > $ wget > > https://aur.archlinux.org/packages/pa/package-query-git/package-query-git.tar.gz > > $ tar -xzf package-query-git.tar.gz ; cd package-query-git ; makepkg -sf > > $ sudo pacman -U package-query-git-1.5-1-x86_64.pkg.tar.xz > > > > IOW recompiling with the new lib is needed. > > > > Hth, > > Ralf > > > > Hi, > I only had to run pacman-db-upgrade, as suggested by yaourt itself, and > everything works fine on my system. > > Cheers, > Eugenio Please don't prolong this thread. libalpm.so changed sonames with pacman 4.2. package-query links to libalpm.so. A rebuild is needed to link to the new libalpm.so.9. Your system is far from fine if package-query still links to libalpm.so.8 and continues to work.
Re: [aur-general] Package promotion process
On Fri, Nov 28, 2014 at 11:29:45AM -0600, Troy Engel wrote: > When a package has hundreds of votes, what keeps it from getting > promoted into Community? I'm talking specifically about cower: > > https://aur.archlinux.org/packages/cower/ > > Bootstrapping AUR on fresh installs is manual, what's the reason cower > hasn't been promoted to Community so it's easy to install with pacman > and have AUR usable out-of-the-box? (apologies if this has been > discussed before and I'm opening some sort of hornet's nest) > > -te Fun fact, cower *was* in [community] for a very short period of time: https://lists.archlinux.org/pipermail/arch-dev-public/2010-December/018893.html It shall never return.
Re: [aur-general] [aur-dev] AUR 3.5.0 released
On Sun, Nov 23, 2014 at 12:07:07AM +0100, Lukas Fleischer wrote: > Hello, > > I am pleased to announce that AUR 3.5.0 has been released. The official > AUR setup [1] has already been updated. > > This release adds support for architecture-specific sources (resp. > provides, conflicts, replaces) and for .SRCINFO, both of which will be > included in the next pacman release. Apart from that, the package list > and package base list are now official and available at [2, 3]. There > have also been a couple of internal changes and bug fixes. > > For a comprehensive list of changes, please consult the Git log [4]. As > usual, bugs should be reported to the AUR bug tracker [5]. > > [1] https://aur.archlinux.org/ > [2] https://aur.archlinux.org/packages.gz > [3] https://aur.archlinux.org/pkgbase.gz > [4] https://projects.archlinux.org/aur.git/log/?id=v3.5.0 > [5] https://bugs.archlinux.org/index.php?project=2 Hi, In addition to this, I'll be releasing a new version of mkaurball today which ceases generation of AURINFO and creates SRCINFO instead. If you're using a recent enough pacman-git[0], mkaurball will just forward on makepkg, offering very little of its own logic. Consider this is the beginning of my efforts to deprecate mkaurball. Of of the pacman 4.2.0, mkaurball will be obsolete and will likely be replaced with a script which just yells at you to use makepkg instead. Cheers, dR [0] https://projects.archlinux.org/pacman.git/commit/?id=6029a77ac
Re: [aur-general] mediawiki skin
On Nov 18, 2014 10:53 AM, "arnaud gaboury" wrote: > > > > > It is not my work, > When I said "your" I was thinking to our arch community > > > but since it's published under GPL2 republish any > > changes should be enough. Additionally you could write something in the > > footer or on an dedicated page and link that in the footer. > > I will be pleased to mention somewhere then Why is any of this relevant to aur-general?
Re: [aur-general] Java name guideliness
On Wed, Sep 24, 2014 at 01:29:44AM +0200, Marcel Korpel wrote: > On Tue, Sep 23, 2014 at 10:39 PM, Dave Reisner wrote: > > All the other arch packages? Really? > > > > $ pacman -Ssq | grep -Ec '[^-][0-9]+$' > > 322 > > This is not a *completely* fair search, as this resultset also > includes bin86, libx264, xf86-video-i740 and v8, where the number > parts are not indicating version numbers. ;-) > > Kind regards, > Marcel Unfortunately, this also holds true of the other search. spring-1944 isn't version 1944, but an open source RTS called "Spring: 1944". Similarly, 'gl-177' is a flight simulator called "GL-177". This inflates the number of packages by 60%. Unfair! d
Re: [aur-general] Java name guideliness
On Tue, Sep 23, 2014 at 05:22:52PM -0300, Pablo Lezaeta Reyes wrote: > 2014-09-23 13:13 GMT-03:00 Marcel Korpel : > > > On Wed, Sep 10, 2014 at 4:22 AM, Det wrote: > > > Enough of that already. Why I chose the "java-8-jdk" naming comes from > > the > > > fact that "java-8-openjdk" sounds like we're trying to do "java- > > version>-". The project name of JDK is not "Oracle JDK", > > and > > > that's why I chose it. Now, OpenJDK apparently still calls these > > projects by > > > their "base name"[3], but _I_ would still prefer (read: I don't > > "refuse"; I > > > prefer) having packages called "jdk8-openjdk" and "jdk" that install in > > > "/usr/lib/jvm/java-8-openjdk/" and "/usr/lib/jvm/java-8-jdk/", > > respectively. > > > > > > This also means we can currently do: > > > > > > $ man java-openjdk8 > > > $ man java-jdk8 > > > > > > To access the man pages. > > > > For what it's worth, I support this naming scheme. > > > > Kind regards, > > Marcel > > > > I preffer ad a hyphen after the version as all the other arch packages do > when is needed. > so my vote is for : > * java-openjdk-8 > * java-jdk-8 > > -- > *Pablo Lezaeta* All the other arch packages? Really? $ pacman -Ssq | grep -Ec '[^-][0-9]+$' 322 $ pacman -Ssq | grep -Ec -- '-[0-9]+$' 5
Re: [aur-general] Revised rbspeex PKGBUILD
On Wed, Sep 17, 2014 at 04:39:25PM -0400, Storm Dragon wrote: > Hi, > Attached is the new rbspeex PKGBUILD. This is the version that was unjustly > deleted, without warning or explination. > Thanks > Storm Your package is a clear duplicate[1], which explains why it was deleted. [1] https://aur.archlinux.org/packages/rbspeex-git
Re: [aur-general] Java name guideliness
On Fri, Sep 12, 2014 at 08:13:11AM +1000, Justin Dray wrote: > ... Perhaps you could read over this before you post again: https://mailman.archlinux.org/pipermail/aur-general/2014-August/029294.html Cheers, d
Re: [aur-general] Discussion about AUR packages signing
On Thu, Aug 07, 2014 at 09:57:24PM +0200, Fabien Dubosson wrote: > Hi, > > I want to start a discussion about AUR packages signing. If this debate > already happened, it means that I'm not really good with Google or > unfortunate in the keywords I used in my searches: in these cases > forgive me and just give me some pointers. > > TL;DR I personally "trust" some AUR users who have several good-quality > packages, and an optional way to sign AUR packages would permit me > to know that I can build and update their packages without > worrying too much. I did read your proposal, but my comment can be framed in the context of your tl;dr: You don't really seem to want GPG signatures, just a whitelist of package maintainers by name. Any AUR helper could implement support for this today, with no changes to the AUR. d
Re: [aur-general] Lost Password
On Fri, Jul 25, 2014 at 04:59:01PM -0300, yermandu wrote: > I lost my password in aur the passreset doesnt send email with link Not sure what email address you're expecting to receive mail at, but the email in your signature is not associated with any AUR account. You've also neglected to mention what username you're attempting to login as. d
Re: [aur-general] AUR 3.3.0 released
On Wed, Jul 09, 2014 at 06:28:21PM +0100, Steven Honeyman wrote: > 1. The man pages are installed in /usr/share/man1 instead of > /usr/share/man/man1 (etc) in the current PKGBUILD. Don't guess based > on something you haven't tried or tested. I'm going by the comments. If there's (still) a problem, you haven't brought it up in the past 4 days since the maintainer updated the package. Orphaning the package in this case isn't reasonable. > 2. I couldn't care less about clang right now. I've never used it. I > aim to support as many configurations as possible though. If it was a > "dick move" then it should have been rejected. You clearly do care, otherwise you wouldn't have: a) tried to hijack the package b) brought it up here Please don't top post.
Re: [aur-general] AUR 3.3.0 released
On Jul 9, 2014 8:59 AM, "Evert Vorster" wrote: > > > I don't see the relevance to the point this seemed to be a response to. > > That package may be hard/impossible to maintain, true - but separate > > flags for 'out of date', 'broken', 'wont compile' wouldn't aid that > > situation any. In fact they might make it worse. > Agreed > > > > If one flag just signifies that something is wrong that requires the > > maintainer's attention, it should be easier for users and for > > maintainers. > Yes, don't get hung up on a name. That button could just as easily > have said: "Needs attention" and then it would cover all the bases. Naming is important. Here's an idea: lets call them "comments". They can be freeform text so that you can explain why the package needs attention, rather than just pressing some weirdly labeled button and hoping the maintainer figures it out. > > -- > Evert Vorster > Chief Observer > WG Cook
[aur-general] AUR package deletion request – Google Music Manager
Hi, I screwed up yesterday and submitted a package to the AUR only to discover that the package was already there, No clue how this happened, I can only guess that I was using the wrong search terms to look for the package before I created nine and couldn't find it (using google play instead of google music in the search string), or maybe just misspelled something in the search. The original package is here: https://aur.archlinux.org/packages/google-musicmanager Mine is here: https://aur.archlinux.org/packages/google-musicmanager-beta Sorry for all the bother! Best, Dave
Re: [aur-general] Stumped on python split package
On Mon, Jun 30, 2014 at 03:11:54PM -0400, Storm Dragon wrote:
> Hi,
> I must be missing something. When I install python-pypump-git or
> python2-pypump-git, I get the same package. I have other split packages
> installed and they install correctly. Can someone look at this PKGBUILD and
> let me know what I did wrong?
> Thanks
> Storm
> --
>
> --
> Registered Linux user number 508465: https://linuxcounter.net/user/508465.html
> My blog, Thoughts of a Dragon: http://www.stormdragon.us/
> get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193
> How many Internet mail list subscribers does it take to change a lightbulb?
> http://goo.gl/eO4PJ
> "Serpent's kin, born of sin. Dark within, father of the wolf!"
> Amon Amarth - Father of the Wolf
> # Maintainer: Storm Dragon
>
> pkgbase=python-pypump-git
> pkgname=("python-pypump-git" "python2-pypump-git")
> pkgver=v0.5.r76.gc73e093
> pkgrel=2
> pkgdesc="An interface to the pump.io API's."
> arch=('any')
> url="https://github.com/xray7224/pypump";
> license=('GPL3')
> source=("git+https://github.com/xray7224/pypump.git";)
> md5sums=('SKIP')
>
> pkgver()
> {
> cd "${srcdir}/pypump"
> git describe --long --tags | sed -r 's/([^-]*-g)/r\1/;s/-/./g'
> }
>
> package_python-pypump-git()
> {
> depends=('python' 'python-requests' 'python-requests-oauthlib' 'python-six'
> 'python-dateutil')
> makedepends=('python-setuptools')
makedepends in a package function will never be read. This array belongs
in the global section.
> cd "${srcdir}/pypump"
> python setup.py install --root="${pkgdir}/" --optimize=1
> }
>
> package_python2-pypump-git()
> {
> depends=('python2' 'python2-requests' 'python2-requests-oauthlib'
> 'python2-six' 'python2-dateutil')
> makedepends=('python2-setuptools')
Same. Merge this into a global makedepends.
> cd "${srcdir}/pypump"
> python2 setup.py install --root="${pkgdir}/" --optimize=1
So, does the following work?
makepkg -i --pkg python2-pypump-git
makepkg -i --pkg python-pypump-git
If it does, you need to make a prepare function that makes a copy of the
source tarball so that you aren't reusing the same build directories for
2 different builds.
> }
Re: [aur-general] Git version
On Mon, Jun 30, 2014 at 06:57:05PM +, c...@free.fr wrote: > Hi > My PKGBUILD is available at > https://aur.archlinux.org/packages/xf/xfreq-2.0-git/PKGBUILD > where source code comes from git > Whenever I update a piece of code, I would like the version be reflected in > pkgver also, so AUR tools like yaourt can inform the user. Any suggestion ? Simply put, you can't do this. PKGBUILDs uploaded to the AUR are immutable. Nothing is going to magically change the pkgver short of you uploading a new PKGBUILD. Users of VCS packages should be following (via RSS or whatever) the upstream repository so that they know when to update. d
Re: [aur-general] package blacklist?
On Mon, Jun 30, 2014 at 12:15:40PM -0500, Mike Hobbs wrote: > Yeah, but AFAIK that's necessary, though, in order to replace xorg-server > with a patched version. At least that's the convention that seen elsewhere > with other AUR packages that contain bug fixes. > > Thanks, > - Mike > No, it isn't necessary. You could specify pkgbase=fooforall and pkgname=xorg-server-ipollutetheaur, and this would be fine to create a single package called xorg-server-ipollutetheaur. The pkgbase is merely an identifier which uniquely identifies a PKGBUILD.
Re: [aur-general] AUR 3.0.0 released
On Sun, Jun 01, 2014 at 10:10:35AM -0500, Doug Newgard wrote: > On 2014-06-01 10:09, Johannes Löthberg wrote: > >On 01/06, Doug Newgard wrote: > >>In the AUR, you specifically build packages to install them. When > >>building for binary repos, you build them to upload them for others to > >>install them. HUGE difference. > > > >The AUR is a repository for hosting PKGBUILDs for packages not in the > >repos. Do not conflate the purpose of the AUR with your use of it. > > For my use? Or for how nearly everyone uses it? Come on now, do you really > believe that they main use of the AUR is to run unofficial repos? Consider the idea that the current use of the AUR is the way it is due to the long time lack of support for split packages. I tend to agree with Johannes here.
Re: [aur-general] ttf-droid-sans duplicate of community/ttf-droid?
On May 28, 2014 5:23 PM, "Pedro Alejandro López-Valencia" < palop...@gmail.com> wrote: > > El may 28, 2014 6:50 PM, "Justin Dray" escribió: > > > > I thought he was being sarcastic, and was implying that we should delete > > it, because what is the point of saving a couple MB on removing a small > > portion of a font at the expense of more packages to maintain. > > I am dead serious; that's what split packages are for. We split packages to do things like: - avoid large documentation dumps in otherwise small packages - provide intercompatability with other packages - avoid recursive dependencies Splitting a font package to only provide specific weights or styles when they all come from the same source is really just a waste of time. > > And don't think for a second I missed the obvious sarcasm.
[aur-general] [aur-dev] testing burp and AUR 3.0.0
Hi all, If you don't care about beta-testing the new AUR or burp, you can stop reading. I've rewritten burp over the weekend and included support for some minor changes that went into the uploader "interface" with AUR 3.0.0. I'm very interested in beta testers and bug reports before I tag a release. If you'd like to help out, please install burp-git[1], and send bug reports to me at github. If you'd like to test burp against the new AUR, you'll need to use the undocumented --domain flag with a value of aur-dev.archlinux.org. Note that packages uploaded to aur-dev will require that they're made with mkaurball[2]. Cheers, Dave [1] https://aur.archlinux.org/packages/burp-git/ [2] https://aur.archlinux.org/packages/pkgbuild-introspection-git
Re: [aur-general] Change email address on AUR
On Sat, May 03, 2014 at 05:21:44PM +0200, Tristelune wrote: > On Sat, May 03, 2014 at 12:11:00AM -0400, Daniel Micay wrote: > > On 02/05/14 07:24 PM, Tristelune wrote: > > > Nobody can tell me, where I have to change my email address or what is > > > wrong ? If I asked at the wrong place, can somebody tells me where I > > > can ask ? > > > > On aur.archlinux.org you can go to the My Account page and edit the > > email address. > > It's what I did and I think it didn't work. To be sure: could somebody > write a comment for the package gscan2pdf ? I will check if I still have > the problem. > > Thanks! > If you changed your email address, then there's nothing more to do on that end. If you aren't receiving emails for that specific package, then make sure you've opted into receiving notifications in the "Package Actions" sidebar of the package page.
Re: [aur-general] AUR 3.0.0-rc1 released
On Thu, May 01, 2014 at 02:04:42PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 13:29, Dave Reisner wrote:
> > On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> >> On 1 May 2014 02:30, Doug Newgard wrote:
> >> >
> >> >
> >> > Yep, that was the concern exactly. Nothing insurmountable, just wanting
> >> > to
> >> > clarify how it works upfront.
> >>
> >> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
> >>
> >> pkgbase=slim-git
> >> pkgname=('slim-git' 'slimlock-git')
> >>
> >> If I now wanted to change the pkgbase to something more encompassing, e.g.
> >>
> >> pkgbase=slim-git_slimlock-git
> >>
> >
> > I don't get it. pkgbase is intended to be no different from what it is
> > in the binary repositories, e.g.:
> >
> > linux -> linux linux-headers linux-docs
> > pacman -> pacman pacman-contrib
> >
> > What you're proposing here makes no sense.
> >
>
> Of course not, I'm an end user. ;)
SSDD. I fully recognize that we're extending the "attack surface" for
users to do really stupid things. I think the benefits will far outweigh
the negatives, and maybe there will be opportunities to automate more,
reducing the reliance on human intervention for day to day operation.
> This is just an example of something someone may try to do for
> whatever reason. It fails, and quite rightly so, you can't have two
> different pkgbases providing the same packages as each other. The
> question remains whether people should be able to alter the pkgbase of
> a split package. If not, that's fine. But if they are, how are they
> supposed to do so? Does it/should it require TU intervention?
Ask for your pkgbase to be deleted, then upload the new one. Or, play
games with the package naming in the new package you upload beforehand,
and have it merged. Afterwards, upload the real PKGBUILD.
> >> I get the following error when I try to upload the aurball
> >>
> >> "You are not allowed to overwrite the slim-git package."
> >>
> >> I assume this is because my updated PKGBUILD provides slim-git (and
> >> slimlock-git), but is in essence a completely different package,
> >> because of the different pkgbase value. In this situation, I cannot
> >> upload the PKGBUILD and have the old one merged into it, due to the
> >> conflict.
> >
> > And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
> > provide 'libfoo', then what does the URI fragment '/packages/libfoo'
> > point to? The basic unit of upload and download has essentially changed
> > to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
> > constraint between package names.
> >
>
> I understand this, and aren't trying to argue against it.
>
Right, this was just an extrapolation.
> >> As I understand it, my options are to either upload the new PKGBUILD
> >> with different/temporary pkgnames, request to have the packages
> >> merged, then undo the rename and upload the updated PKGBUILD again,
> >> with the original pkgnames.
> >>
> >> The other option, as Dave has suggested, is to submit the updated
> >> PKGBUILD along with the merge request. Is this ideal, or would a patch
> >> that can be applied directly onto the existing PKGBUILD be a better
> >> idea? (or in this case, where a patch would be overkill, is it
> >> preferable to just ask a TU to make the changes directly to the
> >> PKGBUILD?)
> >
> > Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
> > a matter of procedure should never happen. This isn't secure at all.
> >
>
> I must have misinterpreted what you said earlier about sending the
> PKGBUILD with the merger request. I assumed TUs had this capability. I
> agree that it's not secure.
>
> >> Or alternatively, should pkgbase changes be disallowed completely,
> >> except where it's really necessary?
> >
> > Not sure what this accomplishes. If there's no pkgbase, it's just
> > assumed to be whatever ${pkgname[0]} expands to. This is a carryover
> > from makepkg.
> >
>
> I know this. I'm meaning in regards to split packages specifically.
>
Still doesn't make sense. The same rule applies, regardless of whether
or not you split the package.
d
Re: [aur-general] AUR 3.0.0-rc1 released
On Thu, May 01, 2014 at 01:04:07PM +0100, WorMzy Tykashi wrote:
> On 1 May 2014 02:30, Doug Newgard wrote:
> >
> >
> > Yep, that was the concern exactly. Nothing insurmountable, just wanting to
> > clarify how it works upfront.
>
> I share this concern. I've just uploaded slim-git [1] to the aur-dev:
>
> pkgbase=slim-git
> pkgname=('slim-git' 'slimlock-git')
>
> If I now wanted to change the pkgbase to something more encompassing, e.g.
>
> pkgbase=slim-git_slimlock-git
>
I don't get it. pkgbase is intended to be no different from what it is
in the binary repositories, e.g.:
linux -> linux linux-headers linux-docs
pacman -> pacman pacman-contrib
What you're proposing here makes no sense.
> I get the following error when I try to upload the aurball
>
> "You are not allowed to overwrite the slim-git package."
>
> I assume this is because my updated PKGBUILD provides slim-git (and
> slimlock-git), but is in essence a completely different package,
> because of the different pkgbase value. In this situation, I cannot
> upload the PKGBUILD and have the old one merged into it, due to the
> conflict.
And if you think about it, this makes sense. If pkgbase 'a' and 'b' both
provide 'libfoo', then what does the URI fragment '/packages/libfoo'
point to? The basic unit of upload and download has essentially changed
to 'pkgbase' rather than 'pkgname', but there's still a uniqueness
constraint between package names.
> As I understand it, my options are to either upload the new PKGBUILD
> with different/temporary pkgnames, request to have the packages
> merged, then undo the rename and upload the updated PKGBUILD again,
> with the original pkgnames.
>
> The other option, as Dave has suggested, is to submit the updated
> PKGBUILD along with the merge request. Is this ideal, or would a patch
> that can be applied directly onto the existing PKGBUILD be a better
> idea? (or in this case, where a patch would be overkill, is it
> preferable to just ask a TU to make the changes directly to the
> PKGBUILD?)
Allowing anyone to edit PKGBUILDs and tarballs on the webserving side as
a matter of procedure should never happen. This isn't secure at all.
> Or alternatively, should pkgbase changes be disallowed completely,
> except where it's really necessary?
Not sure what this accomplishes. If there's no pkgbase, it's just
assumed to be whatever ${pkgname[0]} expands to. This is a carryover
from makepkg.
> Cheers,
>
>
> WorMzy
>
> [1] https://aur-dev.archlinux.org/pkgbase/slim-git/
Re: [aur-general] AUR 3.0.0-rc1 released
On Wed, Apr 30, 2014 at 08:45:16PM -0400, Yichao Yu wrote:
> Hi,
>
> On Wed, Apr 30, 2014 at 8:37 PM, Dave Reisner wrote:
> > On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
> >> On 2014-04-30 17:20, Lukas Fleischer wrote:
> >> >A first release candidate of the AUR 3.0.0 has been released! You can
> >> >give it a try at [1]. Note that due to internal changes, the setup at
> >> >aur-dev.archlinux.org uses a different database than aur.archlinux.org.
> >> >You should be able login using your regular AUR account, though.
> >> >
> >> >The most important changes are:
> >> >
> >> >* Full split package support.
> >> >* Support for {make,check,opt}depends, conflicts, provides, ...
> >> >* Full support for the new fields in the RPC interface.
> >> >* Metadata support. Use mkaurball instead of `makepkg --source` to
> >> > generate source tarballs for the AUR`. You can get it from [2] -- it
> >> > will eventually be moved to [community].
> >> >
> >> >Note that in order to obtain the new fields, you need to request
> >> >the new
> >> >version of the RPC API explicitly, like this:
> >> >
> >> >https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
> >> >
> >> >Otherwise, the replies default to the old format for compatibility
> >> >reasons.
> >> >
> >> >Please report any bugs to the AUR bug tracker [3].
> >> >
> >> >[1] https://aur-dev.archlinux.org/
> >> >[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
> >> >[3] https://bugs.archlinux.org/index.php?project=2
> >>
> >> It appears that pkgbase is now the important part of a PKGBUILD,
> >
> > But note that it doesn't need to be included. Same as makepkg, it
> > defaults to pkgname[0] if it isn't defined.
> >
> >> that's what people would be requesting deletion or merging on? Makes
> >> merges a bit tough, since you can't upload a PKGBUILD with a
> >> different pkgbase but an overlapping pkgname.
> >
> > You'd be referring to the package by its pkgbase, since that's the
> > unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo',
> > you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This
> > doesn't make sense -- you'd just upload a new source tarball with the
> > modification.
> >
> > I don't understand your concern over overlapping pkgnames. If you want
> > to take ownership of existing packages, you should be asking for the
> > package to be disowned, not merged, same as today.
>
> I'm not sure if this is the original concern but one of my concern
> that might be related is that for example there are two packages
> python-foo and python2-foo which provide the python3 and python2
> versions respectively. What should I do if I want to merge the two
> packages into a split package that provide both. Asking for merge and
> update the package later? AUR won't let me to upload a new version of
> python-foo that provide python2-foo otherwise.
Then you update the package after the merge happens, rather than before
(and perhaps attach your PKGBUILD to the merge request).
Re: [aur-general] AUR 3.0.0-rc1 released
On Wed, Apr 30, 2014 at 06:57:33PM -0500, Doug Newgard wrote:
> On 2014-04-30 17:20, Lukas Fleischer wrote:
> >A first release candidate of the AUR 3.0.0 has been released! You can
> >give it a try at [1]. Note that due to internal changes, the setup at
> >aur-dev.archlinux.org uses a different database than aur.archlinux.org.
> >You should be able login using your regular AUR account, though.
> >
> >The most important changes are:
> >
> >* Full split package support.
> >* Support for {make,check,opt}depends, conflicts, provides, ...
> >* Full support for the new fields in the RPC interface.
> >* Metadata support. Use mkaurball instead of `makepkg --source` to
> > generate source tarballs for the AUR`. You can get it from [2] -- it
> > will eventually be moved to [community].
> >
> >Note that in order to obtain the new fields, you need to request
> >the new
> >version of the RPC API explicitly, like this:
> >
> >https://aur-dev.archlinux.org/rpc.php?type=info&arg=pass&v=2
> >
> >Otherwise, the replies default to the old format for compatibility
> >reasons.
> >
> >Please report any bugs to the AUR bug tracker [3].
> >
> >[1] https://aur-dev.archlinux.org/
> >[2] https://aur.archlinux.org/packages/pkgbuild-introspection-git/
> >[3] https://bugs.archlinux.org/index.php?project=2
>
> It appears that pkgbase is now the important part of a PKGBUILD,
But note that it doesn't need to be included. Same as makepkg, it
defaults to pkgname[0] if it isn't defined.
> that's what people would be requesting deletion or merging on? Makes
> merges a bit tough, since you can't upload a PKGBUILD with a
> different pkgbase but an overlapping pkgname.
You'd be referring to the package by its pkgbase, since that's the
unifying factor. If 'foo' is split into 'python-foo' and 'python2-foo',
you wouldn't ask to merge/delete 'python-foo' or 'python2-foo'. This
doesn't make sense -- you'd just upload a new source tarball with the
modification.
I don't understand your concern over overlapping pkgnames. If you want
to take ownership of existing packages, you should be asking for the
package to be disowned, not merged, same as today.
Re: [aur-general] Please remove these packages from AUR
On Apr 20, 2014 4:13 PM, "Jesus Alvarez" wrote: > > Please remove the following packages: > > zfs > zfs-utils > spl > spl-utils > > Thanks! > Jesus A. Without any explanation, you want popular, actively maintained packages removed from the AUR? Sounds fishy, care to explain?
Re: [aur-general] Out of date: clasp, gringo
On Wed, Mar 26, 2014 at 12:12:41PM -0400, Zack Buhman wrote:
> On Wed, Mar 26, 2014 at 11:00:46AM -0400, Dave Reisner wrote:
> > On Wed, Mar 26, 2014 at 10:48:19AM -0400, Zack Buhman wrote:
> > > On Wed, Mar 26, 2014 at 09:52:17AM -0400, Anatol Pomozov wrote:
> > > > On Wed, Mar 26, 2014 at 9:45 AM, Vincent B. wrote:
> > > > > Hi,
> > > > >
> > > > > I am the packager of aspcud and aspcud-svn, an important dependency
> > > > > solver for the OPAM OCaml package manager.
> > > > >
> > > > > Two dependencies, clasp and gringo, have been already packaged in AUR,
> > > >
> > > > Disowned. Adopt and keep improving it!
> > >
> > > This is what package-hijacking looks like.
> >
> > Is it? The previous maintainer has never voted, and their last action on
> > the AUR, as far as I can tell, was June of last year. The only remaining
> > package they have is out of date as of a month ago, in addition to clasp
> > and gringo. I don't think there's any unwarranted "hijacking" happening
> > here.
>
> Unless I'm completely insane, you're talking about the submitter, not
> the previous maintainer (me, though again I could be delusional)--as
> far as I can tell, there is no (public) mechanism that reveals
> intermediate {orphan,adopt} history.
No, you're not insane. I shouldn't try to sleuth around these things
before I've had coffee. Regardless, Vincent provided evidence that he
contacted the current maintainer (thank you!) some time ago.
Re: [aur-general] Out of date: clasp, gringo
On Wed, Mar 26, 2014 at 10:48:19AM -0400, Zack Buhman wrote: > On Wed, Mar 26, 2014 at 09:52:17AM -0400, Anatol Pomozov wrote: > > On Wed, Mar 26, 2014 at 9:45 AM, Vincent B. wrote: > > > Hi, > > > > > > I am the packager of aspcud and aspcud-svn, an important dependency > > > solver for the OPAM OCaml package manager. > > > > > > Two dependencies, clasp and gringo, have been already packaged in AUR, > > > > Disowned. Adopt and keep improving it! > > This is what package-hijacking looks like. Is it? The previous maintainer has never voted, and their last action on the AUR, as far as I can tell, was June of last year. The only remaining package they have is out of date as of a month ago, in addition to clasp and gringo. I don't think there's any unwarranted "hijacking" happening here. Tangentially related, I think it would make sense to forward the unanswered email (with bounceback, if appropraite) from the current maintainer with any disown request. I think this is a simple measure to try and keep people honest in their requests. Maybe I'm just overly wary of people... d
Re: [aur-general] Voting results
On Sun, Feb 16, 2014 at 04:29:12PM -0800, Anatol Pomozov wrote: > Hi > > On 2/16/14, 5:37 AM, Sébastien Luttringer wrote: > > On 16/02/2014 00:54, Lukas Fleischer wrote: > >> On Sat, 08 Feb 2014 at 18:14:21, Lukas Fleischer wrote: > >>> On Mon, 03 Feb 2014 at 20:26:22, Anatol Pomozov wrote: > Hi everyone > > I would like to apply for a Arch Trusted User position. It is > sponsored by my co-worker and bright engineer David Reisner. > [...] > >>> > >>> You can now cast your votes [1]. The voting period ends on 2014-02-15. > >>> Note that intermediate voting results are no longer visible due to a > >>> recent AUR patch. > > > > Welcome. > > Thanks. > > I was following the AUR TODO list [1] and found that it is slightly > out-of-date. Per [2] PGP key signing requires filing a bug to "Keyring" > but I do not see such project at http://bugs.archlinux.org . I believe I > need a special status at bugs website but there is no information in > TODO how I suppose to change the status. > > So my question is who/how to update my status at http://bugs.archlinux.org? I'll take care of filing the bug. It's only visible to current devs and TUs. > > [1] > https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users > [2] > https://mailman.archlinux.org/pipermail/arch-dev-public/2013-September/025456.html > > pgpdHyg2j84nq.pgp Description: PGP signature
Re: [aur-general] Removing stale accounts from the AUR
On Wed, Feb 05, 2014 at 07:57:32PM +0100, carstene1ns wrote: > Am 31.01.2014 14:42, schrieb Dave Reisner: > > On Jan 31, 2014 7:17 AM, "Lukas Fleischer" wrote: > [...] > >> Side effects: > >> > >> * The ~2000 packages maintained by these users will be orphaned. > > > > Can we get a list of these packages?[...] > > As nobody with the power to do sql-fu on the AUR server created a list > yet, an ordinary mortal has to step in. > This is the list of packages in alphabetical order: > http://arch.carsten-teibes.de/aur-stuff/aur-cleanup-02-2014/packages_to_orphan.html > > This lists them by Maintainer: > http://arch.carsten-teibes.de/aur-stuff/aur-cleanup-02-2014/packages_to_orphan_by_maintainer.html > > I have queried the AUR RPC interface (yay, 35k requests!) for this list, > ignored all maintainers without packages and give no warranty that it is > correct or complete. I hope that it is useful for someone. > > Btw. I also provide plaintext (s/html/txt/) and Markdown (s/html/md/) > versions of both lists. > > best regards, > carstene1ns > > Actually, I got this list from Lukas a few hours after I mentioned it. But, thanks!
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 02:49:48PM -0500, Daniel Micay wrote: > On Mon, Feb 3, 2014 at 2:46 PM, Dave Reisner wrote: > > On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: > >> Hi everyone > >> > >> I would like to apply for a Arch Trusted User position. It is > >> sponsored by my co-worker and bright engineer David Reisner. > > > > My name is Dave and I approve this message. > > Nice try, David. My GPG signature says you're wrong. pgpiGg0H55Ccv.pgp Description: PGP signature
Re: [aur-general] TU application sponsored by David Reisner
On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote: > Hi everyone > > I would like to apply for a Arch Trusted User position. It is > sponsored by my co-worker and bright engineer David Reisner. My name is Dave and I approve this message.
Re: [aur-general] Removing stale accounts from the AUR
On Jan 31, 2014 9:18 AM, "Joakim Hernberg" wrote: > > On Fri, 31 Jan 2014 13:17:25 +0100 > Lukas Fleischer wrote: > > > * All ~2 comments written by any of the users will be removed. > > Removing comments might lead to disconnected discussions in the > comments... Can you find an example of a 2 year old comment which is still relevant? > > -- > >Joakim
Re: [aur-general] Removing stale accounts from the AUR
On Jan 31, 2014 7:17 AM, "Lukas Fleischer" wrote: > > Hi, > > I plan to remove all AUR accounts that have not been used for at least > 500 days (according to the last login time stamp). This affects ~35000 > users, see [1] for a complete list. If your account is on that list and > you think it shouldn't be there, please let me know. > > Side effects: > > * The ~2000 packages maintained by these users will be orphaned. Can we get a list of these packages? If for no other reason than exposure to active people on this list who may want to adopt, but I also suspect that we can probably just purge a bunch of these anyways. > * All ~2 comments written by any of the users will be removed. > * Votes will be retained. > > Regards, > Lukas > > [1] http://sprunge.us/LBSe
Re: [aur-general] Remove a few packages
On Mon, Jan 20, 2014 at 09:30:01PM +0100, Maxime Gauduin wrote: > On Mon, Jan 20, 2014 at 9:22 PM, Maxime Gauduin wrote: > > Except I don't remember ever seeing a python-python-pyfoo in our repos... We would, if python-pyfoo was the name of an upstream project. > > -- > > Maxime > > > > Also we add python in all cases to differentiate python 2 and python 3, > there is no such problem with ruby... No, we add a python- prefix because that's our packaging guidelines for language specific packages. The fact that ruby has no divergent branch which requires separate packaging is irrelevant. The upstream project is called ruby/sdl. The gem is called rubysdl. It seems to me that ruby-rubysdl is the correct name, even if it seems to be redundant. I've merged ruby-sdl into ruby-rubysdl.
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 06:31:40PM -0500, Dave Reisner wrote: > On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > > 3) duplicate a lot of stuff in the pkgname section, even if it's > >identical to what is listed in the pkgbase section. > > That shouldn't be the case. What package were you looking at that shows > this in the .AURINFO? The goal is that pkgbase section provides the > bulk of the metadata -- the individual pkgname sections are only > overrides and supplements. The GetMergedPackage def in the python parser > illustrates how the base and "overlay" create each output package. Nevermind this -- I found cases where this happens. Fixed locally, just need to write some regression tests.
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 11:46:12PM +, Jerome Leclanche wrote: > On Thu, Jan 16, 2014 at 11:31 PM, Dave Reisner wrote: > > On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > >> On Tue, 14 Jan 2014 at 23:54:28, Dave Reisner wrote: > >> > On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > >> > [...] > >> > > * Test your utility. Do some manual tests and automated tests you > >> > > described below. Fix common use cases. > >> > > > >> > > * Create a package that contains mkaurball and put that in [extra] or > >> > > [community]. Update all Wiki articles etc., replacing `makepkg > >> > > --source` with `mkaurball`. > >> > > >> > I think you're missing a few steps here. For starters, I don't believe > >> > the current .AURINFO parser is capable of consuming the format I'm > >> > advertising. Including it without changing the AUR's parser means... > >> > Refused uploads? Bad data displayed? > >> > >> I didn't read code or test your tool before I wrote the mail, so I > >> didn't know that you > > > > Fair enough... I assumed when I mentioned split packages and referenced > > Allan's post that it was understood I was going outside of the current > > .AURINFO format (which is far too simplistic to be of value in the long > > term). > > Do you have some example .AURINFO files you can post to the list? I've been > dealing with domain-specific packaging a lot the past month and I'm > very interested in a potential solution to all this. Clone my repo and run './reflect /path/to/PKGBUILD'. If you have an ABS tree cloned into /var/abs, you can just run './reflect $repo/$pkg'.
Re: [aur-general] Promoting use of .AURINFO
On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote: > On Tue, 14 Jan 2014 at 23:54:28, Dave Reisner wrote: > > On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote: > > [...] > > > * Test your utility. Do some manual tests and automated tests you > > > described below. Fix common use cases. > > > > > > * Create a package that contains mkaurball and put that in [extra] or > > > [community]. Update all Wiki articles etc., replacing `makepkg > > > --source` with `mkaurball`. > > > > I think you're missing a few steps here. For starters, I don't believe > > the current .AURINFO parser is capable of consuming the format I'm > > advertising. Including it without changing the AUR's parser means... > > Refused uploads? Bad data displayed? > > I didn't read code or test your tool before I wrote the mail, so I > didn't know that you Fair enough... I assumed when I mentioned split packages and referenced Allan's post that it was understood I was going outside of the current .AURINFO format (which is far too simplistic to be of value in the long term). > 1) always add a "pkgbase" section (even to non-split packages), Intentional. > 2) indent some lines using tabs and > > 3) duplicate a lot of stuff in the pkgname section, even if it's >identical to what is listed in the pkgbase section. That shouldn't be the case. What package were you looking at that shows this in the .AURINFO? The goal is that pkgbase section provides the bulk of the metadata -- the individual pkgname sections are only overrides and supplements. The GetMergedPackage def in the python parser illustrates how the base and "overlay" create each output package. > I assumed that the .AURINFO looks as usual for non-split packages and > the pkgbase stuff is just added for split packages. Is there any reason > for having this pkgbase overhead in non-split packages? Because, IMNSHO, this is old fashioned thinking. Everything should be treated as a split package these days, even if the PKGBUILD only produces a single package as output. makepkg's code is moving in this direction as well. It's totally valid to write a PKGBUILD that produces one package, but has a package_$pkgname() function instead of package(). Since we're going to allow human-massaged .AURINFO files, the AUR's parser should probably allow pkgname without pkgbase. This should be simple to handle if you can handle pkgbase + pkgname, as you're essentially just merging your overrides into the empty set. > > > > It's been suggested a few times in a cousin thread that currently > > .AURINFO is not widely used. I cloned the AUR to find out how much truth > > there was to that: 75 out of 56k packages have .AURINFO files (.0001%). > > So, I think any changes in the AUR to consume a new format should be > > bothering an inconsequential number of people. > > Existing packages won't be affected by any .AURINFO change anyway (at > least not on the AUR side). That file is only parsed once when > uploading. > > > > > > * Add a deprecation warning to the AUR in the upcoming release that is > > > displayed whenever a source tarball without meta data is submitted. > > > > > > * Fix any remaining bugs that are revealed in production use. > > > > With the understanding that not *all* bugs will be fixed in the parser > > itself. Some PKGBUILDs will simply not be supported. > > Of course. The good thing is that people can still adjust the meta data > manually if they want, without adding hacks to the PKGBUILD. > > > [...] > > I just did some tests and the results look pretty good indeed. Do you > plan on creating an Arch package for that (as soon as the controversial > points are addressed)? Yep -- sounds good to me. Cheers, Dave
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] 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: Naturally. Having the metadata available is only the first step. > * Test your utility. Do some manual tests and automated tests you > described below. Fix common use cases. > > * Create a package that contains mkaurball and put that in [extra] or > [community]. Update all Wiki articles etc., replacing `makepkg > --source` with `mkaurball`. I think you're missing a few steps here. For starters, I don't believe the current .AURINFO parser is capable of consuming the format I'm advertising. Including it without changing the AUR's parser means... Refused uploads? Bad data displayed? It's been suggested a few times in a cousin thread that currently .AURINFO is not widely used. I cloned the AUR to find out how much truth there was to that: 75 out of 56k packages have .AURINFO files (.0001%). So, I think any changes in the AUR to consume a new format should be bothering an inconsequential number of people. > * Add a deprecation warning to the AUR in the upcoming release that is > displayed whenever a source tarball without meta data is submitted. > > * Fix any remaining bugs that are revealed in production use. With the understanding that not *all* bugs will be fixed in the parser itself. Some PKGBUILDs will simply not be supported. I start to wonder if we really shouldn't just bite the bullet and implement PKGBUILDv2 in pacman. I guess that's a much different conversation, though, and we can already make improvements to data richness in the AUR with this approach. Where the data is sourced from should be a simple implementation detail if it changes in the future. > * Add support for split packages in the next major release. At the same > time, try to integrate .SRCINFO support into makepkg (and support both > .AURINFO and .SRCINFO in the AUR, deprecating .AURINFO). > > That way, the format and the meta data generator gets a lot of testing. > The only downside of this approach is that users temporarily need to > switch to `mkaurball` and (probably) switch back to `makepkg --source` > later. This is just herding cats. mkaurball could eventually become a utility that nags you before running 'makepkg --source' on your behalf. At some point, maybe it goes away. > > > > A nice thing to do next might be to create a test harness which compares > > my extracted data to the pacman DBs and look at the precise failure > > modes. I know some of the failure modes, but I won't claim to know them > > all. > > > > Cheers, > > Dave > > > > [1] https://www.github.com/falconindy/pkgbuild_reflection > > [2] > > https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015910.html
Re: [aur-general] Promoting use of .AURINFO
On Sun, Jan 12, 2014 at 02:35:33PM +0100, Lukas Fleischer wrote: > Hi, > > I think we should promote the use of .AURINFO files. Currently, only a > very small fraction of packages use it. A basic description of its > format can be found in the commit message of AUR commit 5a11373 [1]. > Regardless of whether we keep that format or use something entirely > different for metadata later, it is good to have this information stored > somewhere and the format is simple enough to migrate to another format > later. > > I think we should at least come up with a tiny tool to generate this > kind of metadata post-makepkg and put it into the source tarball, then > add some information to the submission section in the official AUR wiki > article [2]. Does anyone have plans to write such a tool? Did anyone > already integrate this functionality into an existing AUR uploader? If > no one steps up, I might attempt to write one on my own in a couple of > days. > > I might also add a deprecation warning for source tarballs without > .AURINFO files in one of the upcoming AUR releases. > > Regards, > Lukas > > [1] > https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff > [2] > https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages This prompted me to resurrect some old code I had written to do data extraction from PKGBUILDs. Sadly, I didn't understand my own code and it quickly proved to be buggy, so I rewrote it from scratch. I think I mostly understand it now ;). It's well structured, but it's still bash with a hefty dose of black magic (I don't believe I'm relying on any undocumented behaviors). What I have now [1] is some generic shell functions which can extract metadata from PKGBUILDs. I suspect that it will handle most of what exists in the official repos. I'm very sure it fails on architecture- specific overrides, and other bizzare corner cases (e.g. see core/linux). Since it *does* execute code, it's success rate is rather high. Of course, you're likely never going to see a 100% solution. 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. A nice thing to do next might be to create a test harness which compares my extracted data to the pacman DBs and look at the precise failure modes. I know some of the failure modes, but I won't claim to know them all. Cheers, Dave [1] https://www.github.com/falconindy/pkgbuild_reflection [2] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015910.html
Re: [aur-general] JOYOAUTO spam
On Fri, Jan 03, 2014 at 05:00:17PM +0100, Florian Dejonckheere wrote: > On 3 January 2014 16:41, SanskritFritz wrote: > > > Please delete the spam comment by JOYOAUTO here: > > https://aur.archlinux.org/packages/autoaur/ > > > > I don't know of any other occurences in the AUR. > > > > This isn't the first occurrence of spam by the JOYOAUTO account. Isn't it > possible to block/ban the user/IP? The user's account is already suspended. Of course, this doesn't prevent them from creating another account...
Re: [aur-general] 'provides' info in AUR
On Thu, Dec 12, 2013 at 08:47:49AM +1000, Justin Dray wrote: > What is to stop us using both? I don't think anyone has said we should stop > parsing the PKGBUILD for the AUR and exclusively parse a .PKGINFO instead. We should stop parsing the PKGBUILD for the AUR and exclusively parse a .SRCINFO instead.
Re: [aur-general] 'provides' info in AUR
On Wed, Dec 11, 2013 at 08:21:44PM +, Jerome Leclanche wrote: > On Wed, Dec 11, 2013 at 6:42 PM, Dave Reisner wrote: > > On Wed, Dec 11, 2013 at 06:12:59PM +, Jerome Leclanche wrote: > >> On Wed, Dec 11, 2013 at 5:52 PM, Sam S. wrote: > >> > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche > >> > wrote: > >> > > >> >> I don't understand why makepkg -S > >> >> doesn't include the .PKGINFO file from makepkg (and subsequently the > >> >> AUR would use that if present instead of the grep system which fails > >> >> as soon as variables/expansions are involved which is every other > >> >> package). All the implementation is there. > >> >> > >> > > >> > It would probably be better then what we have now, but a perfect solution > >> > would also account for PKGBUILDs that use Bash conditionals to set > >> > different variables on i386 systems than on x86_64 systems (which is > >> > pretty > >> > common among AUR packages that package upstream binaries rather than > >> > compiling from source). > >> > > >> > Reading values from .PKGINFO would populate the AUR with the values for > >> > whichever architecture the package uploader happened to use. (So if the > >> > maintainer changes, or the same maintainer works on different computers, > >> > a > >> > simple re-upload of an AUR package could suddenly change the package's > >> > meta-info, i.e. the AUR would become more "fragile".) > >> > > >> > Of course, the "perfect solution" would be pretty difficult to implement. > >> > Gentoo had a GSoC project last year [1], to implement an efficient and > >> > safe > >> > (side-effect free) limited Bash parser / pseudo-interpreter in C++, > >> > sufficient to extract all necessary values from Genoo's equivalent of > >> > PKGBUILDs. Surely, this could have been useful for the AUR as well. But I > >> > can find no evidence of continued project activity after the GSoC period > >> > ended, so it appears they have given up... :( > >> > > >> > --- > >> > [1] http://dev.gentoo.org/~qiaomuf/libbash.html > >> > >> I love the fact someone could be working on a bash parser but that > >> solution is *insane*. > > > > It's designed to be incomplete, and the project appears very dead. > > > >> This is a solved problem: use a metafile compiled by whatever tools > >> you use in your distro/domain that can be parsed safely and easily. > >> For Arch, those are PKGINFOs. > > > > No, go see historical conversations about a mythical .SRCINFO -- this is > > what .AURINFO is based on. .SRCINFO is vaporware right now, and I again > > refer you to unresolved discussions about how it would handle split > > packages and package-specific overrides. > > > >> Good point on the differences per arch. I guess the obvious solution > >> that comes to mind here is to have makepkg -S generate the source > >> files for each arch value (eg. PKGINFO.x86_64, etc) but that's not > >> necessarily good and is the subject of another discussion imo. > > > > To be clear, .PKGINFO is not the solution here. This file describes a > > built package (something the AUR explicitly does not support). > > > > d > > Care to explain the reasoning? I'm looking at a few example PKGINFOs > and they contain nothing that can exclusively be generated at > package() or build() time (other than pkgver but that's already the > case currently). > > J. Leclanche Here's a few reasons that come to mind: 1) As you've already discovered, you'd need a .PKGINFO file for every potential architecture, rather than just a .SRCINFO which might describe what architectures are known available. A .SRCINFO could express all package and architecture specific overrides. The fact that an override exists might be a useful bit of information to convey. 2) .PKGINFO doesn't contain things that are useful for source packages, like, say... the source URL? checksums? 3) You can't possibly express split packages well. Having pkgname fields in a .SRCINFO would mean you could describe all packages created by a PKGBUILD rather than having some loose association between a PKGBUILD and some possible .PKGINFO files which it might have generated. This is about *source* packages. The metadata needs for source packages are not the same as the needs for binary packages.
Re: [aur-general] 'provides' info in AUR
On Wed, Dec 11, 2013 at 06:12:59PM +, Jerome Leclanche wrote: > On Wed, Dec 11, 2013 at 5:52 PM, Sam S. wrote: > > On Tue, Dec 10, 2013 at 4:21 PM, Jerome Leclanche wrote: > > > >> I don't understand why makepkg -S > >> doesn't include the .PKGINFO file from makepkg (and subsequently the > >> AUR would use that if present instead of the grep system which fails > >> as soon as variables/expansions are involved which is every other > >> package). All the implementation is there. > >> > > > > It would probably be better then what we have now, but a perfect solution > > would also account for PKGBUILDs that use Bash conditionals to set > > different variables on i386 systems than on x86_64 systems (which is pretty > > common among AUR packages that package upstream binaries rather than > > compiling from source). > > > > Reading values from .PKGINFO would populate the AUR with the values for > > whichever architecture the package uploader happened to use. (So if the > > maintainer changes, or the same maintainer works on different computers, a > > simple re-upload of an AUR package could suddenly change the package's > > meta-info, i.e. the AUR would become more "fragile".) > > > > Of course, the "perfect solution" would be pretty difficult to implement. > > Gentoo had a GSoC project last year [1], to implement an efficient and safe > > (side-effect free) limited Bash parser / pseudo-interpreter in C++, > > sufficient to extract all necessary values from Genoo's equivalent of > > PKGBUILDs. Surely, this could have been useful for the AUR as well. But I > > can find no evidence of continued project activity after the GSoC period > > ended, so it appears they have given up... :( > > > > --- > > [1] http://dev.gentoo.org/~qiaomuf/libbash.html > > I love the fact someone could be working on a bash parser but that > solution is *insane*. It's designed to be incomplete, and the project appears very dead. > This is a solved problem: use a metafile compiled by whatever tools > you use in your distro/domain that can be parsed safely and easily. > For Arch, those are PKGINFOs. No, go see historical conversations about a mythical .SRCINFO -- this is what .AURINFO is based on. .SRCINFO is vaporware right now, and I again refer you to unresolved discussions about how it would handle split packages and package-specific overrides. > Good point on the differences per arch. I guess the obvious solution > that comes to mind here is to have makepkg -S generate the source > files for each arch value (eg. PKGINFO.x86_64, etc) but that's not > necessarily good and is the subject of another discussion imo. To be clear, .PKGINFO is not the solution here. This file describes a built package (something the AUR explicitly does not support). d
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: > 2013/12/10 Dave Reisner : > > On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: > >> 2013/12/10 Karol Blazewicz : > >> > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) > >> > wrote: > >> >> Hey, I wonder if it is possible to query the `provides` of a package in > >> >> AUR? > >> > > >> > Is e.g. 'cower -ii wine-git' good enough? > >> > >> Acctually, I want to know if it is possible to query the AUR through > >> API to know what packages provide the desired package. e.g. I query > >> for packages provived 'wine', and get I get 'wine-git' and others. > >> Does cower do that? > > > > No, cower doesn't do this because the AUR's RPC interface doesn't do this. > > > Okay, understand, so that's a todo, I guess. Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to: 1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful. The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this would leave you with a useless "feature" as only a fraction of applicable packages would have the data. d
Re: [aur-general] 'provides' info in AUR
On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: > 2013/12/10 Karol Blazewicz : > > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) > > wrote: > >> Hey, I wonder if it is possible to query the `provides` of a package in > >> AUR? > > > > Is e.g. 'cower -ii wine-git' good enough? > > Acctually, I want to know if it is possible to query the AUR through > API to know what packages provide the desired package. e.g. I query > for packages provived 'wine', and get I get 'wine-git' and others. > Does cower do that? No, cower doesn't do this because the AUR's RPC interface doesn't do this.
Re: [aur-general] espeakup's service file yet again lol
On Thu, Nov 14, 2013 at 04:25:04PM -0500, Storm Dragon wrote: > Hi, > I created the file /etc/systemd/system/espeakup.service.d and added: > ExecStart=/usr/bin/espeakup --default-voice=en-us+m3 > After reloading espeakup.service, it still uses the default voice. Do I have > the syntax wrong? > I am using the plain espeakup.service file, not espeakup@.service. > Thanks > Storm If you do nothing else today, please convince yourself that top posting is the root of all evil, the destroyer of biblical cities, and the kicker of pets everywhere. 'systemctl status' and 'systemctl show' will both show you the command line systemd used to start the service. If running that yourself from the commandline yields different results, then there's something weird going on.
Re: [aur-general] espeakup's service file yet again lol
On Thu, Nov 14, 2013 at 07:27:39AM -0500, Storm Dragon wrote: > Hi, > > The service works as expected, e.g. systemctl start espeakup@en-us.service > starts the US english voice. The problem is, varients do not work. systemctl > start espeakup@en-us+m2.service just uses the default voice, British english, > instead of the selected en-us and varient m2. I have read through the man > page, and from what I gather, it should work. So, am I missing something, or > have I found a bug? > Attached is the service file. > Thanks > Storm > -- Instanced unit files only really make sense when you expect that the service can be spawned multiple times. This isn't the case here. If users want to override the default language, then they can create an entry in /etc/systemd/system/espeakup.service.d to fixup the ExecStart line.
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 04:51:38PM -0400, Ido Rosen wrote: > On Thu, Oct 31, 2013 at 4:45 PM, Dave Reisner wrote: > > > On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: > > > What about reusing the "filename" feature; if it sees multiple times > > > the same files it treats it as a mirror, eg. > > > "file.tar.gz::http://example.com/file.tar.gz"; > > > "file.tar.gz::http://mirror.example.com/file.tar.gz"; > > > > > > J. Leclanche > > > > This can't work. If the first source fails to download, makepkg will > > abort. > > > > What about just detecting if source is an array/list (keep current > behavior), or a dictionary/lookup table (new fancy mirror behavior)? If > it's a dictionary/lookup table, then try all mirrors before failing a > source download. > > For examples of how to create lookup tables in bash, see > http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash... bash4's associative arrays define a 1:1 mapping of string to string. You cannot have multiple elements in the "value." Not to mention that we won't be changing the format of the 'source' variable any time soon.
Re: [aur-general] Support for source mirror lists in PKGBUILD
On Thu, Oct 31, 2013 at 08:32:49PM +, Jerome Leclanche wrote: > What about reusing the "filename" feature; if it sees multiple times > the same files it treats it as a mirror, eg. > "file.tar.gz::http://example.com/file.tar.gz"; > "file.tar.gz::http://mirror.example.com/file.tar.gz"; > > J. Leclanche This can't work. If the first source fails to download, makepkg will abort.
Re: [aur-general] architecture question
On Thu, Oct 24, 2013 at 03:40:50PM +0200, pon...@creshal.de wrote: > On 10/24/2013 12:27 PM, 徐林 wrote: > > I think you perhaps not to do so. > > https://wiki.archlinux.org/index.php/Pkgbuild#arch ArchLinux ARM > > Edition seems not to use AUR?Or actually ArchLinux ARM also use the > > same AUR as i686/x86_64 ? > > They also use the aur packages afaik. > > 2013/10/24 Kuba Serafinowski > > I recently got several requests to include armv7h in arch() of my > > PKGBUILDs, is it okay to do it even though it's not officially > > supported? > > If you feel uncomfortable with including an unoffical architecture, > you could talk to upstream if they do anything platform specific and > if not just use "any" in the arch() array. Compiling is platform specific. Do not use 'any' for packages which include compiled code. > But I agree with wormzy tykashi and would just include armv*.
Re: [aur-general] Delete package gromacs-4.5.6-complete
On Oct 13, 2013 12:12 PM, "Hector Martinez-Seara" wrote: > > Hi, > I'm the maintainer of gromacs-4.5.6-complete. This package was suppose to > be the last gromacs release for the gromacs 4.5.x family required by some > applications. Another release has appeared gromacs 4.5.7. I have > incorporated these package to AUR. Therefore please delete the previous > package. > > > https://aur.archlinux.org/packages/gromacs-4.5.6-complete/ Why wouldn't you just name it gromacs-4.5-complete? Repeating the full version in the pkgname is rather redundant. > > Thanks in advance, > Hector > > -- > Hector Martínez-Seara Monné > mail: hse...@gmail.com > Tel: +34656271145 > Tel: +358442709253
Re: [aur-general] RFC: freecad-git
On Sat, Sep 21, 2013 at 10:33:47AM +, Xyne wrote: > Hi, > > Would anyone care to comment on this PKGBUILD? > > AUR: https://aur.archlinux.org/packages/fr/freecad-git/PKGBUILD > Pastebin copy: http://pastebin.com/q3ARNgJ6 > > Is this an acceptable clever workaround or an abomination that should be > purged > with fire? > > Regards, > Xyne > > > p.s. OR statements and other boolean operatores really would be nice sometimes But not needed here. If oce and oce-git provide=(opencascade), freecad-git could simply depends=(opencascade).
Re: [aur-general] Merge request: python2-pyside -> python-pyside
On Mon, Sep 16, 2013 at 04:59:03PM +, Xyne wrote:
> Dave Reisner wrote:
>
> >And you'd need to do all this work at a level lower than the parser
> >itself to avoid subversion via aliases, functions, and scripts which
> >mask the actual operation's nature...
> >
> >I think I've mentioned this a few times, but I think there's 2 options
> >if you want better parsing on the AUR:
> >
> >1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date,
> >I think there's been a number of issues which no one has been willing to
> >address to make this a reality.
>
> Wouldn't that need to actually build everything to access the data nested in
> the package functions? That wouldn't necessarily be a bad thing as it would
> require packages to check that the package builds, but in that case you may as
> well just extract the data from .PKGINFO.
>
makepkg doesn't need to build everything to extract this metadata. It's
hacky, but it can do it. Some of the code in makepkg looks like:
for i in pkgver pkgrel epoch; do
local indirect="${i}_override"
eval $(declare -f package_$1 | sed -n
"s/\(^[[:space:]]*$i=\)/${i}_override=/p")
[[ -z ${!indirect} ]] && eval ${indirect}=\"${!i}\"
done
There's other similar stuff for the arch overrides. You can also look at
run_split_packaging() for other magic.
> >2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to
> >evalulate the code. This would require something very similar to the
> >guts of makepkg which understands per-package overrides. The output
> >would be something similar to #1, so really... interested parties should
> >just work on that.
>
> I honestly think the best approach would be to replace Bash PKGBUILDs with a
> versatile metadata language that can be easily and safely parsed, e.g. JSON
> with
> support for variables and maybe a limited set of custom macros. Build and
> package functions could be moved to external scriptlets, e.g.
> '{"build" : "/path/to/build.sh", ...}'.
>
> Yet another item on my todo list. :P
>
Let's call this PKGBUILD 2.0. We'll throw it in the same camp as AUR
2.0.
>
> >You'd probably be interested in shellcheck:
> >
> >http://www.shellcheck.net/
> >
> >It's written in Haskell, and while it doesn't execute anything, it does
> >understand a large amount of bash syntax. I found an obscure bug in it
> >recently which was quickly fixed by the author (he's a denizen of #bash
> >on freenode).
>
> That is indeed interesting.
Re: [aur-general] Merge request: python2-pyside -> python-pyside
On Mon, Sep 16, 2013 at 03:07:19PM +, Xyne wrote: > Chris “Kwpolska” Warrick wrote: > > >Why not adapt the actual Bash parser (in C) to only read and do stuff > >safely? In most cases, this would be enough. In the others, we > >already have mess in those fields in the AUR. (my C skills are not > >appropriate for this) > That is basically what needs to be done but it is a difficult task. Even if > you > can adapt the Bash source code to return the AST, you would still need to > create an extensive whitelist of executables (both internal and external) that > may be run in order interpolate all of the variables. The code must be able to > detect variable settings nested in the package functions, skip commands that > do > not affect variables (which may require it to work backwards), count loop > cycles to prevent infinite loops, track time to prevent timeouts, etc. And you'd need to do all this work at a level lower than the parser itself to avoid subversion via aliases, functions, and scripts which mask the actual operation's nature... I think I've mentioned this a few times, but I think there's 2 options if you want better parsing on the AUR: 1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date, I think there's been a number of issues which no one has been willing to address to make this a reality. 2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to evalulate the code. This would require something very similar to the guts of makepkg which understands per-package overrides. The output would be something similar to #1, so really... interested parties should just work on that. > I have thought about this before when I wrote the Bauerbill PKGBUILD parser, > but I gave up trying to find a way to extract the AST using the Bash code. In > the end my code would simply wrap the PKGBUILD in a function, source the file, > spit it out with "set" to homogenize the syntax, and then parse it with > regexes. > > I started writing a Bash parser in Haskell with Parsec but my free time ran > out > and I had to move on to other things. I think that approach would work quite > well if the Bash sources are too tangled to extract the parser, but it is a > huge task for one person (word expansion, string manipulation, all of the > built-ins, etc.). I would be willing to collaborate on that as well, if there > is any interest. You'd probably be interested in shellcheck: http://www.shellcheck.net/ It's written in Haskell, and while it doesn't execute anything, it does understand a large amount of bash syntax. I found an obscure bug in it recently which was quickly fixed by the author (he's a denizen of #bash on freenode).
Re: [aur-general] Source packages in the AUR
On Sat, Sep 14, 2013 at 11:30:28AM +0200, Mort wrote: > This package is useful when one wants to write C/C++ extensions to gawk. > > There's a bunch of header files available only in the source (while there > is one gawkapi.h in the official gawk package, it is not sufficient for > developers who want to build their own extensions). > http://www.gnu.org/software/gawk/manual/html_node/Internal-File-Ops.html > > It works exactly the same way as linux-headers and > https://aur.archlinux.org/packages/ruby-source/ (Correct me if I'm wrong). > They exist mainly not for general users, but for developers who want to > build their own modules from scratch. Even though it is relatively > unpopular to build extensions in gawk, you can't assume the source package > is "useless" in any case. Just let you know what this is intended for. > I think the point is that this package doesn't provide anything that can't already be just as easily obtained via ABS and 'makepkg -o'
Re: [aur-general] Problem with checksum verification of coreutils-8.21
On Mon, Sep 09, 2013 at 04:31:29PM +0200, Adrien RAFFIN wrote:
> Hi everyone,
>
> I'm currently updating my package ('advcp') and when i use 'makepkg -g'
> the list of checksums is the following:
>
> md5sums=('065ba41828644eca5dd8163446de5d64'
> 'SKIP'
> '5154b45b0e7230e17da802a3db0fd5d5')
>
> How can i get rid of 'SKIP' value and make the original package verified ?
>
> Thank you in advance
>
What's the real problem here? The value of SKIP is intentional and
applied to any source which refers to a VCS resource or gpg signature.
In this case, you're running into the latter. There's no point in
keeping a checksum for the .sig file since it's merely used as an
instrument to further assert the validity of the source tarball.
tl;dr: working as intended.
Re: [aur-general] Proofreading request
On Tue, Aug 27, 2013 at 10:34:56AM -0500, Doug Newgard wrote: > > > Date: Tue, 27 Aug 2013 10:04:37 +0200 > > From: cju.a...@gmail.com > > To: aur-general@archlinux.org > > Subject: Re: [aur-general] Proofreading request > > > > 2013/8/27 Taylor Lookabaugh > > > >> On 08/27/13 00:35, Clément Junca wrote: > >>> Yes, you're right. Sorry. Here is the good one. > >> You haven't attached anything to this mail. > >> > >> PS: make sure you reply below the quotes in a mailing list, easier to > >> read top to bottom. > >> > > > > That's strange, I see the tar.gz file in my sent mail. Here are the files > > from the archive. > > My notes: > > 1. Get rid of all of the empty variables (groups, provides, etc) > 2. Definitely add the license file to the source array. > 3. The cd .. at the end of the pkgver function is useless. > 4. Applying the patch should be done in a prepare() function, you don't need > a build() function at all in this case. > 5. You don't need || exit 1. The functions are called in a way so it will > already exit if there are errors. > 6. install -D will make the dirs it needs, you don't need to make them > yourself with mkdir -p. > 7. The comment in the pkgver function doesn't match what it's doing, it's not > using a tag. > 8. If you do install the default config file, you should add it to the backup > array so that pacman doesn't overwrite it every time you upgrade. > > I will disagree with the previous posters on a couple of things. > > 1. There's nothing wrong with using ../../LICENSE as long as you know what > dir you're in. Yes. There is. You don't, and you can't know what directories are above you in this case. This PKGBUILD will fail when [[ -n $BUILDDIR ]] is true. More pertinent, not adding the LICENSE file to the source array means that 'makepkg -S' doesn't include this file. That the file is still included is a sign of a manually crafted source tarball and a huge red flag. > 2. There is nothing wrong with cd-ing directly to $_gitname, although I > prefer $srcdir/$_gitname myself
Re: [aur-general] [tu-bylaws] [PATCH 2/2] Add details on patch submissions
On Wed, Aug 21, 2013 at 05:45:50PM +0200, Lukas Fleischer wrote: > On Wed, Aug 21, 2013 at 12:07:47PM +, Xyne wrote: > > On 2013-08-20 18:14 +0200 > > Lukas Fleischer wrote: > > > > >+SVP is commenced at the time of the motion, with a discussion period of 5 > > >days, > > >+a quorum of 75%, and a voting period of 7 days. > > > > > > Use the same formulation as the "Removal of a TU" section: > > >Following the motion, standard voting procedure commences with a discussion > > >period of 5 days, a quorum of 75%, and a voting period of 7 days. > > > > You can also replace "standard voting procedure" with "SVP" throughout the > > document after its definition. > > Note that I did not touch this sentence apart from formatting changes. > > > > > >+be sent "inline" (i.e. using `git send-email`) so that other TUs can > > >easily > > > > I would change "i.e." to "e.g." as I see no reason to mandate that users > > actually send the message with git directly (as this requires sendmail > > configuration, and some users may only have access to webmail). The > > formatting > > of the message itself is what matters. > > Git does not require sendmail. It requires an MTA but something simple > and lightweight like msmtp(1) does the job. It takes about 5 minutes to > setup. It doesn't even require an MTA. git is able to send directly to an SMTP server via the perl script that manages mail. See the --smtp-* options in 'git-send-email(1)'. Specifically, the --smtp-server option defaults to 'localhost' which means that it defaults to using a locally found MTA. > Around 90% of all patches that are sent by Git rookie without using `git > send-email` are broken in some way. Most common errors are: > > * Wrong patch format. Patches created with diff(1) or something else. > > * Patch is not sent inline. This makes it damn hard to comment on > specific parts. > > * Broken indentation and line wraps. This often happens when patches are > sent using webmail. Webmail should never be used to send patches > unless you know exactly what you are doing. > > When applying your patch, I had to export your proposal mail to an mbox > file, edit that mbox file and remove the parts that do not belong to the > patch, save the resulting file and apply it using `git am`. This is why > I came up with this... If there is a generally accepted format which is > very convenient, why not use it? > > Also, the document says "should be sent" -- not "must be sent". Everyone > who knows what he/she is doing can send the patch using another tool and > hardly anyone will notice. > > > > > To be honest, I don't see the problem with accepting the resulting document > > either. Copying over a single document is no more work than applying a > > patch. > > 1. Most people want to see a diff. Hardly anyone wants to read the whole >document over and over again and scan for minor wording changes every >time. Sending a document means that every TU has to clone the >tu-bylaws Git repository, save the attachment, copy it to the working >directory of the clone and invoke `git diff`. Why? > > 2. Attaching a document makes it a lot harder to comment on specific >parts by using the "quote" function of the mail client, like you did >when replying to my patch :) > > 3. The committer will have to write a commit message and adjust the >author's e-mail address (and maybe also change the author date). > > > > > Perhaps we could also add an additional minor change to this patchset to say > > that the SVP voting period ends either after the designated time OR after > > all > > TUs have voted. With the upcoming changes to the AUR this will be apparent, > > and > > the AUR can stop the vote itself an possibly send an email to the list. > > Ok, I can add this. But I doubt that there will ever be such a > situation. Did we ever have a voting with a participation of 100%? :) > > > > >
Re: [aur-general] [Delete] - clean_chroot_manager
On Sun, Aug 18, 2013 at 12:55:20PM -0400, member graysky wrote: > I have renamed the project and updated a new PKGBUILD under the new name. > Please delete the old one: > https://aur.archlinux.org/packages/clean_chroot_manager > > Thanks! I'm more curious what the devtools wrappers like x86_64-extra-build don't offer that caused you to write this.
Re: [aur-general] aur upload problems
On Sat, Aug 17, 2013 at 05:37:30PM +0200, Rob Til Freedmen wrote: > Hi, > I've tried uploading to the aur (via web) but got an error: > Error - source tarball may not contain nested subdirectories. > > aurploader just returns with an unspecified error. > > I've looked at the source package and everything looks ok. > I've tried an older source package uploaded long time ago > and got the same error. If you create your tarballs using 'makepkg -S', you shouldn't run into such problems.
Re: [aur-general] Remove maven-3.1.0 package
On Mon, Aug 12, 2013 at 01:40:56PM +0100, Leonidas Spyropoulos wrote: > Hello Dave, > > On Mon, Aug 12, 2013 at 1:22 PM, Dave Reisner wrote: > > In the future, please do not upload packages like this. > Could you please explain me where I actioned wrongly so in the future > I act accordingly? > Guideline #1 from the wiki: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Submitting_packages_to_the_AUR Please do not undermine the official repos. No one's stopping you from building the newer version locally, but submitting it to the AUR can and will cause problems. Thanks
Re: [aur-general] Remove maven-3.1.0 package
In the future, please do not upload packages like this.
On Aug 12, 2013 8:19 AM, "Leonidas Spyropoulos" wrote:
> Please remove the maven-3.1.0 package [1] as the official maven
> package [2] is now updated to 3.1.0 version.
>
> [1]: https://aur.archlinux.org/packages/maven-3.1.0/
> [2]: https://www.archlinux.org/packages/community/any/maven/
>
> Thanks
>
> --
> Caution: breathing may be hazardous to your health.
>
> #include
> int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
>
Re: [aur-general] Removal request for [linux-xen]
Does it? Doesn't Xen require PAE on i686? We aren't enabling that on the repo kernel. Ever. On Aug 9, 2013 5:05 PM, "Evan Teitelman" wrote: > Please remove linux-xen[1]. > > The current version of Linux kernel has full Xen support. > > [1] https://aur.archlinux.org/packages/linux-xen/ >
Re: [aur-general] TUs and their following of the Bylaws
On Wed, Aug 07, 2013 at 02:23:54PM +, Xyne wrote: > On 2013-08-07 14:30 +0200 > Florian Pritz wrote: > > >On 07.08.2013 13:33, Xyne wrote: > >> I find this annoying. I have heard on several occasions that a lot of > >> relevant > >> discussion as well as shit-talking takes place on that channel. Sometimes > >> even > >> important decisions are made there. > > > >I like IRC because it allows you to decide on a basic direction. Of > >course everything should still be sent to the mailing list for the real > >discussion, but eliminating pointless stuff first seems like a good idea > >to me. > > > >Please point out when something has only been discussed on IRC and then > >presented here as a final decision. This really shouldn't happen. > > I didn't mean to imply that IRC is altogether bad. I'm sure that discussing > things in real-time can be much more productive, especially in the initial > stages of something. As long as the important stuff ends up on this list then > it's fine. My point is simply it should not act as a channel for an inner > circle. > > I didn't say that final decisions were presented here based on IRC discussion, > nor can I definitely point to any such case. I do, however, seem to recall > that > one of the AUR cleanup bots was launched after an IRC decision and I think > that > decision was later rebuked, but that's beside my point and I don't feel like > scouring the archives for the thread, if it even exists. Keenerd launched his bot before he was even a TU. His decision to do so made him reconsider his application for the cooldown period before re-applying. If he spoke to anyone about it on IRC it was with me over private messages. There was zero involvement from any Arch associated channel. I'm not aware of any other cleanup bots, but please correct me if I'm wrong here.
Re: [aur-general] pdftk - I added my vote...
On Mon, Aug 05, 2013 at 03:55:43AM +0200, oliver wrote: > On Sun, Aug 04, 2013 at 09:50:06PM -0400, Dave Reisner wrote: > > On Mon, Aug 05, 2013 at 03:33:19AM +0200, oliver wrote: > > > ...and it has now 376 votes. > > > > > > Would be nice to have it as part of the official Arch packages. > > > > > > Ciao, > > >oliver > > > > If anything, you should learn from this that votes don't have any > > meaning. Without an interested TU, packages simply do not move from the > > AUR to the repos. > > > But this is an interesting tool... maybe somoen would be interested, > after pointing to this tool? > > It allows splitting and rearranging pdf-files in an easy way... > > Ciao, >Oliver So does stapler.
Re: [aur-general] pdftk - I added my vote...
On Mon, Aug 05, 2013 at 03:33:19AM +0200, oliver wrote: > ...and it has now 376 votes. > > Would be nice to have it as part of the official Arch packages. > > Ciao, >oliver If anything, you should learn from this that votes don't have any meaning. Without an interested TU, packages simply do not move from the AUR to the repos.
Re: [aur-general] packages without category
On Tue, Jul 30, 2013 at 08:51:59PM +0200, Rob Til Freedmen wrote: > On Tue, Jul 30, 2013 at 8:23 PM, Dave Reisner wrote: > > > On Tue, Jul 30, 2013 at 08:15:06PM +0200, Lukas Jirkovsky wrote: > > > On 30 July 2013 19:56, Rob Til Freedmen > > wrote: > > > > There are still >1000 packages without 'Category' > > > > - apparently not a hot topic. > > > > > > I think most of these packages are created by uploading the PKGBUILD > > > using burp or a similar AUR uploader. If the categories were to stay > > > [1], it would be good if these uploaders or AUR rejected packages > > > without a category. > > > > > > > This would become a royal pain in the ass for updating packages, since > > > > You just do it once - what's so difficult about it? > > Singling out this sentence and replying to it outside of the context of the rest of my post is plain silly. Please don't do this. Regardless, you cannot convince me that it's the job of AUR uploader to impose artificial restrictions on uploads. If you want to mandate that packages have a category, then make that mandate on the server-side. > > you rarely (if ever) update a package and include a category. I suppose > > > > You could do it in a few lines of code when uploading. > > > > one could parallelize an existence check with the login, but I don't > > really see myself doing this any time soon. > > > > The current search interface might be insufficient and not optimal > regarding categories, > but should be consistent and predictably - which it isn't now. I tend to agree with the consensus that categories are meaningless, unmaintainable crap. d
Re: [aur-general] packages without category
On Tue, Jul 30, 2013 at 08:15:06PM +0200, Lukas Jirkovsky wrote: > On 30 July 2013 19:56, Rob Til Freedmen wrote: > > There are still >1000 packages without 'Category' > > - apparently not a hot topic. > > I think most of these packages are created by uploading the PKGBUILD > using burp or a similar AUR uploader. If the categories were to stay > [1], it would be good if these uploaders or AUR rejected packages > without a category. This would become a royal pain in the ass for updating packages, since you rarely (if ever) update a package and include a category. I suppose one could parallelize an existence check with the login, but I don't really see myself doing this any time soon.
Re: [aur-general] Original vlock sources
On Sun, Jul 28, 2013 at 03:28:48PM -0400, Allen Li wrote: > Hello fellow Archers, > > Does anyone by any chance have the original vlock source code? > > A while back, community/vlock was taken in by core/kbd because vlock > upstream was dead. This should have been a good thing, but it is not a > good thing because the kbd version of vlock is missing important > features. And now when I try to find the original, surprise, the > sources are gone. > > Thanks, > Allen What features are missing? Why not contact the Altlinux folks who maintain kbd and discuss how they can be re-added?
Re: [aur-general] Removal notifier?
On Wed, Jul 17, 2013 at 11:34:39AM -0400, Jonathan Arnold wrote: > Speaking of removing packages, is there a tool that would tell me if a > package I have installed has been removed? As someone who installs far > too many packages, I will end up with a package installed because > something depends on it, but then that something goes away and I > never find out. > > -- > Jonathan ArnoldWebstream: http://hieronymus.soup.io > > Talent wins games, but team work and intelligence wins championships. > Michael Jordan > Not really. The below will give you a list of packages which are not in the repositories and not in the AUR: $ pacman -Qmq | grep -xvFf <(cower -i --format %n $(pacman -Qmq)) ...but there's no distinction between "not in the AUR anymore" and "never was in the AUR to begin with".
Re: [aur-general] google-earth - Integrity checks (md5) fail
On Tue, Jul 16, 2013 at 03:09:34PM +0200, Ralf Mardorf wrote: > Hi :) > > On Tue, 2013-07-16 at 15:48 +0300, Jesse Juhani Jaara wrote: > > You should post this as a comment on the google-earth AUR pkg site > > insted of sending it here. It will probably go unnoticed. > > Thank you, I didn't know that, however, it already is reported by > others. > > On Tue, 2013-07-16 at 07:50 -0500, Doug Newgard wrote: > > And we care, why? The maintainer has been notified, what's the point > > of sending an email here? > > Arch Linux might be the only purpose in life for you, but it isn't for > me, so I have overlooked it, when I run the update and since this list > is described as "This list is for [snip] the general public to discuss > issues surrounding [snip] the Arch User Repository (AUR)." - > https://mailman.archlinux.org/mailman/listinfo/aur-general , I send this > mail here. And yet your original post was merely output from your shell. You aren't discussing anything at all, just being redundant in an inappropriate forum with nothing of value to add. > Is this a serious issue for you? What does "general public to discuss" > mean? It means *discussing* things like: - removal/merging/orphan requests - general operating procedures, best practices - peer reviews on PKGBUILDs Rarely, if ever, do people simply dump command output on aur-general and expect anything to come of it. You're the minority.
Re: [aur-general] Delete request - cacheclean
On Jul 5, 2013 2:57 PM, "Rob Til Freedmen" wrote: > > On Fri, Jul 5, 2013 at 10:50 AM, member graysky wrote: > > > https://aur.archlinux.org/packages/cacheclean/ > > > > Now that paccache is out, I have deleted the upstream code from my > > github and my http server. Recommend removing the PKGBUILD from the > > AUR since I am upstream. > > > > I can't find ' paccache' anywhere in the repos... It's included with pacman. Seems like a good time to mention pkgfile as well, which could answer a question like this.
Re: [aur-general] Python debug symbols
On Jun 18, 2013 4:08 AM, "Mo0O mo0ofier" wrote: > > hello, > > I have made a PKGBUILD which enable Python debug symbols - > http://sprunge.us/gDLL - to enable python debuging with gdb > > I have two question: > > - as I only add !strip and debug options in the original PKGBUILD, is it > realy relevant to push it on AUR? -I know some python dev who's thinking it > could be useful to have python packaged like this, but I want your opinion- This isn't a useful addition to the AUR. Anyone can simply grab the PKGBUILD from the repos and make the modification on their own if they need debug symbols. > > - I have named it python2-gdb, is it a good choice ? or maybe you prefer > something like: python2-symbols, python2-debug, python2-debug-symbols or > python2-debug-gdb? > > Thanks > > Mo0O > > PS: I could make one for Python3 too, if you fell the first one necessary
Re: [aur-general] Massive orphan request
On Sun, May 05, 2013 at 09:07:12AM -0700, Kevin Vesga wrote: > I have contacted the maintainers for the following package list and they > have not responded in two weeks. I humbly ask that they be orphaned. > > http://pastebin.com/xXprCz6f > > P.S. Theres a LOT of packages. There aren't so many that they should be posted to a pastebin which potentially expires, effectively deleting the record of your request. Here's the extracted list: https://aur.archlinux.org/packages/afrodite/ https://aur.archlinux.org/packages/alexandria/ https://aur.archlinux.org/packages/amnesia-demo/ https://aur.archlinux.org/packages/andromeda/ https://aur.archlinux.org/packages/asterisk-voicechanger/ https://aur.archlinux.org/packages/asterisk/ https://aur.archlinux.org/packages/awesome-wm-themes-collection/ https://aur.archlinux.org/packages/bamf/ https://aur.archlinux.org/packages/banshee-community-extensions/ https://aur.archlinux.org/packages/banshee-youtube-unstable/ https://aur.archlinux.org/packages/banshee-youtube/ https://aur.archlinux.org/packages/basic256/ https://aur.archlinux.org/packages/bcwipe/ https://aur.archlinux.org/packages/bin32-jdk-java5/ https://aur.archlinux.org/packages/bin32-skype-oss/ https://aur.archlinux.org/packages/bluepad/ https://aur.archlinux.org/packages/breqn/ https://aur.archlinux.org/packages/bsnes-phoenix/ https://aur.archlinux.org/packages/btg-svn/ https://aur.archlinux.org/packages/btg/ https://aur.archlinux.org/packages/btnx/ https://aur.archlinux.org/packages/bzr-grep/ https://aur.archlinux.org/packages/cadabra/ https://aur.archlinux.org/packages/cairo-git/ https://aur.archlinux.org/packages/carrier-svn/ https://aur.archlinux.org/packages/cartaodecidadao/ https://aur.archlinux.org/packages/chuck-extra/ https://aur.archlinux.org/packages/compiz-decorator-gtk-no-gnome/ https://aur.archlinux.org/packages/compiz-devel/ https://aur.archlinux.org/packages/conkygui/ https://aur.archlinux.org/packages/conlie/ https://aur.archlinux.org/packages/csound-doc/ https://aur.archlinux.org/packages/csound/ https://aur.archlinux.org/packages/cutecom/ https://aur.archlinux.org/packages/cwdaemon/ https://aur.archlinux.org/packages/dbus-java/ https://aur.archlinux.org/packages/dmenfm/ https://aur.archlinux.org/packages/dmenu-tok-patch/ https://aur.archlinux.org/packages/dmpc/ https://aur.archlinux.org/packages/dnstop/ https://aur.archlinux.org/packages/droidcam/ https://aur.archlinux.org/packages/dropbox-pyndexer-git/ https://aur.archlinux.org/packages/eclipse-aptana/ https://aur.archlinux.org/packages/eclipse-jee/ https://aur.archlinux.org/packages/ejabberd-mod_admin_extra-svn/ https://aur.archlinux.org/packages/enigmail/ https://aur.archlinux.org/packages/fakenes/ https://aur.archlinux.org/packages/fantom/ https://aur.archlinux.org/packages/fastboot/ https://aur.archlinux.org/packages/faust/ https://aur.archlinux.org/packages/fedora-icon-theme/ https://aur.archlinux.org/packages/fftw2double/ https://aur.archlinux.org/packages/findbugs/ https://aur.archlinux.org/packages/fittstool/ https://aur.archlinux.org/packages/fldigi/ https://aur.archlinux.org/packages/fltk11/ https://aur.archlinux.org/packages/fortune-mod-it/ https://aur.archlinux.org/packages/freediams/ https://aur.archlinux.org/packages/freej/ https://aur.archlinux.org/packages/freemedforms/ https://aur.archlinux.org/packages/friture/ https://aur.archlinux.org/packages/g15stats/ https://aur.archlinux.org/packages/ganttproject/ https://aur.archlinux.org/packages/gedit-classbrowser/ https://aur.archlinux.org/packages/gedit-pkgbuild-highlight/ https://aur.archlinux.org/packages/gimp-plugin-dds/ https://aur.archlinux.org/packages/glade2/ https://aur.archlinux.org/packages/gloobus-preview/ https://aur.archlinux.org/packages/gnapi/ https://aur.archlinux.org/packages/gnome-globalmenu-xfce4/ https://aur.archlinux.org/packages/gnome-shell-extensions-git/ https://aur.archlinux.org/packages/gnome-shell-system-monitor-applet-git/ https://aur.archlinux.org/packages/gnomeradio/ https://aur.archlinux.org/packages/gnuhealth/ https://aur.archlinux.org/packages/gopenvpn-svn/ https://aur.archlinux.org/packages/grinder/ https://aur.archlinux.org/packages/gsnapshot/ https://aur.archlinux.org/packages/gstreamer0.10-good-plugins-ossv4/ https://aur.archlinux.org/packages/gtk-elegant-arch-theme/ https://aur.archlinux.org/packages/gtkparasite/ https://aur.archlinux.org/packages/gtkqq-git/ https://aur.archlinux.org/packages/guitarix/ https://aur.archlinux.org/packages/guitarix2/ https://aur.archlinux.org/packages/gx_head/ https://aur.archlinux.org/packages/harmonyseq-bzr/ https://aur.archlinux.org/packages/harmonyseq/ https://aur.archlinux.org/packages/hotot-kde-git/ https://aur.archlinux.org/packages/hotot-kde/ https://aur.archlinux.org/packages/hotot-qt-git/ https://aur.archlinux.org/packages/hotot-qt/ https://aur.archlinux.org/packages/httping/ https://aur.archlinux.org/packages/httrack/ https://aur.archlinux.org/packages/imageenlarger/ https://aur.archlinux.org/packa
Re: [aur-general] makepkg patch for g...@bitbucket.org urls
On May 3, 2013 5:17 PM, "Myles English" wrote:
>
>
> Hi,
>
> Either I am using makepkg or wrong (how?) or I have a patch that might
> be useful.
>
> I was having trouble using this source line:
>
> sources=(dolfin::git://g...@bitbucket.org:mylese/dolfin.git)
>
> which leads to this git command:
>
> $ git clone --mirror git://g...@bitbucket.org:mylese/dolfin.git
/home/myles/tmp/sources/dolfin
>
> and this error:
>
> "fatal: Unable to look up g...@bitbucket.org (port mylese) (Servname not
> supported for ai_socktype)"
Cloning from a private repo doesn't make a whole lot of sense here.
> Omitting the "git://" protocol, i.e.:
>
> sources=(dolfin::g...@bitbucket.org:mylese/dolfin.git)
>
> leads to the "local" protocol being used and then
>
> "==> ERROR: dolfin was not found in the build directory and is not a URL"
>
> Changing makepkg like this:
>
> diff --git a/makepkg b/makepkg
> index 45a702e..310e5ef 100755
> --- a/makepkg
> +++ b/makepkg
> @@ -269,6 +269,10 @@ get_protocol() {
> # strip leading filename
> local proto="${1##*::}"
> printf "%s\n" "${proto%%://*}"
> + elif [[ $1 = *@bitbucket* ]]; then
> + # strip leading filename
> + local proto="${1##*::}"
> + printf "%s\n" "${proto%%@bitbucket*}"
I really don't think special casing bitbucket is the right "solution" here.
Just clone from a public repo.
> else
> printf "%s\n" local
> fi
>
> allows this sources line to be used:
>
> sources=(dolfin::g...@bitbucket.org:mylese/dolfin.git)
>
> Myles
Re: [aur-general] [aur-dev] Package naming
On Fri, May 03, 2013 at 05:50:28PM +0200, Armin K. wrote: > On 05/03/2013 01:15 PM, Guillaume Friloux wrote: > >Hi, the problem is that youre making multiple packages and AUR doesnt > >supports it properly. > >A possible hack would be to add at begin of second line : > >true && > > > > Well, there are already several packages with split binary packages, > and they appear to be uploaded correctly. This mentions naming > problem - ie only small letters allowed. > > CC-ing aur-dev. > > I can't upload llvm split package named llvm-r600 and it says: > > (translation from Croatian): Wrong name: Only small letters allowed. > > The PKGBUILD is located at > > http://sprunge.us/JFDe > > Is this a bug? I could upload the original package, but I can't update it. bcc aur-dev This isn't a bug, and this isn't new behavior. https://bugs.archlinux.org/task/16394
Re: [aur-general] AURINFO: howto use this file?
On Wed, May 01, 2013 at 08:07:08PM +0200, SpinFlo wrote: > 2013/5/1 SpinFlo > > > Hi > > > > according this thread [1], AUR can handle the file .AURINFO with info to > > better handle info AUR packages > > > > howto add this file in source package? > > > > works with splitted pkgbuilds? > > > > greetings > > > > [1] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002428.html > > > > oks, i make test. makepkg can't handle this file when use makepkg --source, > need create tarball by hand (ark or console) > > greetings But makepkg does read the source array in the PKGBUILD ...
Re: [aur-general] AUR account recovery
On Fri, Apr 26, 2013 at 09:30:55AM -0700, Ryan Delaney wrote: > Hello, > > Somehow I have lost control of my AUR account. The password reset sends an > email with a link to a page to reset the password in case I have forgotten > it. However, the password reset does not give me an opportunity to recover > the *username* I used to register, so I cannot confirm that information. > Please help. > > Ryan Responded off list with the username for this email address.
Re: [aur-general] Fwd: please add -depth 1 to makepkg git clone
On Sat, Apr 6, 2013 at 3:11 PM, Tai-Lin Chu wrote: > ...what are you trying to test? Probably trying to replicate what makepkg does to show you why cp doesn't work. > mkdir -p /tmp/dumb/ > pushd /tmp/dumb/ > echo "==> Cloning into a bare repository..." > git clone --verbose git://github.com/falconindy/cower.git barerepo > echo "==> Creating copy of this repo using cp..." > cp -r -a /tmp/dumb/barerepo /tmp/dumb/barecp > echo "==> Done" > echo "==> Creating copy of this repo using git clone..." > git clone --verbose /tmp/dumb/barerepo barerepocopy > echo "==> Done" > > test this. of course --bare will give you different result... > And this is what makepkg uses so that the base repo takes up less space on disk and the tree doesn't need to be calculated. > ok here is a normal process that i mentioned: > > git clone --depth 1 git://github.com/falconindy/cower.git test > cp -a -r test test2 > // build with test2 > rm -rf test2 Please go back and search the pacman-dev list for why we aren't doing this -- it's clear that you posted the suggestion here before doing any amount of investigation into this. You aren't the first to suggest this, and you unfortunately won't be the last. > On Sat, Apr 6, 2013 at 11:25 AM, William Giokas <1007...@gmail.com> wrote: > > On Sat, Apr 06, 2013 at 11:10:52AM -0700, Tai-Lin Chu wrote: > >> >Doesn't matter. cp does nothing with checksums, whereas git will > >> >preserve every byte, and it literally can't go bad (or if it does on > the > >> >extremely off chance, it will simply stop the build). Maybe rsync, you > >> >say? That still isn't cryptographically secure. Using git, you can > >> >guarantee that the files you are building from are exactly the same as > >> >anyone else, which is what we want with makepkg. > >> > >> cp and git clone are exactly the same. see cp source code, and if the > >> file is corrupted, then you have even bigger problems. > >> In general very not likely. (i mean if this happen, 1. kernel has > >> problem 2. your disk goes bad) > >> stackoverflow confirmed the result. > >> > http://stackoverflow.com/questions/852561/is-it-safe-to-use-a-copied-git-repo > >> > >> >There's minimal point to this. As I've said numerous times, it does not > >> >allow you to clone the shallow bare repo, which is what makepkg gets > >> >when it fetches git sources. > >> > >> aren't we talking about cp? > > > > Here, run this quick script and see what you can do with it: > > > > #!/bin/bash > > mkdir -p /tmp/dumb/ > > pushd /tmp/dumb/ > > echo "==> Cloning into a bare repository..." > > git clone --verbose --bare git://github.com/falconindy/cower.gitbarerepo > > echo "==> Creating copy of this repo using cp..." > > cp -r -a /tmp/dumb/barerepo /tmp/dumb/barecp > > echo "==> Done" > > echo "==> Creating copy of this repo using git clone..." > > git clone --verbose /tmp/dumb/barerepo barerepocopy > > echo "==> Done" > > > > If you look at the one generated by the 'cp' command you will see that > > it is totally missing the actual files, and only contains (duh) the bare > > repository files. This is utterly worthless for building, and also, if > > there is disk failure, makepkg will still try to build. > > > > Looking into the one generated by the git clone, you'll see that it has > > all of the correct files and can actually be built. > > > >> > >> >If they're all doing it at the same time, cloning fresh repositories, > >> >then yes. that may be an issue on some large projects with very > terrible > >> >servers. Also, if you're worried about server load, mirror the > >> >repository yourself so people can gake the load off of the host server. > >> >This is the joy of a DVCS. > >> > >> I dont have a server, and this is not practical. certainly using git > >> pkgbuild with shallow clone is far easier than what you mentioned. > > > > Not at all. See the script above. > > > > !next > > -- > > William Giokas | KaiSforza > > GnuPG Key: 0x73CD09CF > > Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF >
Re: [aur-general] curl download in makepkg doesn't work for contradictory reasons
On Sun, Mar 31, 2013 at 6:59 PM, Uwe Koloska wrote: > Hello Dave, > > thanks for the quick answer! > > Am 31.03.2013 23:11, schrieb Dave Reisner: > > On Sun, Mar 31, 2013 at 5:07 PM, Uwe Koloska wrote: > >> the curl download for package mma fails with the following error > >> curl: (22) The requested URL returned error: 406 Not Acceptable > > > > > > This is because scumbag server admins block requests with the curl user > > agent. It's a server problem, not a makepkg problem. > > Do you know the reason, why curl *with* mozilla user-agent doesn't work > with sourceforge? It looks like there is a second redirection with the > curl user-agent. Seems like more server shenanagins based on user-agent. The page you're redirected to with the Mozilla UA is just advertisements stuffed into iframes with a time delayed download.
Re: [aur-general] curl download in makepkg doesn't work for contradictory reasons
On Sun, Mar 31, 2013 at 5:07 PM, Uwe Koloska wrote: > Hello, > > the curl download for package mma fails with the following error > curl: (22) The requested URL returned error: 406 Not Acceptable This is because scumbag server admins block requests with the curl user agent. It's a server problem, not a makepkg problem. > This error can be removed by adding '--user-agent "Mozilla/4.0"' to the > DLAGENTS from /etc/makepkg.conf. > > But with this additional option, the download from sourceforge fails. > > How can I solve this contradiction? Is it possible to configure package > specific download options in the PKGBUILD? > Sure. You're free to redefine DLAGENTS in a PKGBUILD just as they are in /etc/makepkg.conf. > This are the successful download comands (I have left out the '-C -'): > > # works only with agent > /usr/bin/curl -fL --retry 3 --retry-delay 3 \ > --user-agent "Mozilla/4.0" \ > -O http://www.mellowood.ca/mma/mma-bin-12.10.tar.gz > > # works only without agent > /usr/bin/curl -fL --retry 3 --retry-delay 3 \ > -O http://downloads.sourceforge.net/zdfmediathk/MediathekView_3.2.1.zip > > Best regards > Uwe Koloska >
Re: [aur-general] Strange filesystem conflict behavior
On Mar 26, 2013 5:09 AM, "Hector Martinez-Seara" wrote:
>
> Hi,
> what about adding a "provides" clause to the PKGBUILD?
>
> provides = ('espeak')
You'd want conflicts here, too, it sounds like. Suggesting that one remove
conflicting files which legitimately exist in two packages is no better
than using --force. The files will be the removed when one of the two
packages is removed, breaking the other.
>
> Hector
>
>
> 2013/3/26 Limao Luo
>
> > On 03/25/2013 07:01 PM, Kyle wrote:
> >
> >> According to Allen Li:
> >> # Can't you just uninstall the previous version before installing the
> >> # newer version? No need to manually remove anything.
> >>
> >> This would work, except for the fact that espeakup depends on espeak,
so
> >> if espeakup is installed, manually removing espeak will automatically
> >> remove espeakup, which would then need to be manually reinstalled.
> >> Simply removing /usr/share/espeak-data avoids this extra complexity.
I'm
> >> still confused about why any user intervention would even be necessary
> >> when removing the old version and replacing it with a properly
> >> conflicting/providing version of the same package. Isn't pacman robust
> >> enough to handle changes in the file structure of a conflicting
package,
> >> as long as the fields are properly filled in, and the old package is
> >> being automatically removed?
> >> ~Kyle
> >> http://kyle.tk/
> >>
> > I don't think pacman can take care of that atm; I've had this kind of
> > problem myself in the recent past (2 months or so ago, although I can't
> > remember the name of the package(s))
> >
> > -Limao Luo
> >
>
>
>
> --
> Hector Martínez-Seara Monné
> mail: hse...@gmail.com
> Tel: +34656271145
> Tel: +358442709253
[aur-general] Resigning as TU
Hey all, In the past couple of months I've been less active with Arch due to time limitations, and I feel like it's been even longer since I've really been active as a TU. I don't see this as something that's going to change in the near future. Given that, please consider this my resignation from the TU community. I feel that this will let me focus more on the packaging I do in core and extra, as well as my development efforts with mkinitcpio, pacman, and the other assorted Arch projects I involve myself with. Cheers, Dave
Re: [aur-general] Fighting spam on the AUR
On Fri, Mar 15, 2013 at 11:04:38AM +0100, Timothy Redaelli wrote:
> On Wednesday, March 13, 2013 11:33:18 AM Lukas Fleischer wrote:
> > Status quo:
> >
> > 06:54 < gtmanfred> ok, it really is time for something else
> > 06:54 < gtmanfred> the spammer is now creating a new account for
> > every comment and flag out of date
> >
> > The account suspension feature does not help here.
> >
> > Options:
> >
> > * Allow package maintainers to block the "Flag package out-of-date"
> > feature for a certain amount of time. Note that this might eventually
> > cripple the "out-of-date" function. Also, this does not work for
> > comments.
> >
> > * Use CAPTCHAs during account registration. We could either use MAPTCHAs
> > ("What is 1 + 1?") or something like reCAPTCHA [1].
> >
> > * Moderate new accounts. Might be a lot of work. We need some TUs that
> > review and unlock accounts. Also, it might be hard to distinguish a
> > spam bot from a regular user. If we require a short application text,
> > this might result in less users joining the AUR.
> >
> > * Block IP addresses. Bye-bye, Tor users!
> >
> > Comments and suggestions welcome! We need to find a proper solution as
> > soon as possible!
> >
> > [1] http://www.google.com/recaptcha
>
> Hi,
> I suggest to use http://www.flameeyes.eu/projects/modsec instead (and in wiki
> too, so we can remove the horrible captcha).
> It's an Apache mod_security backlist that reduce the spam (using DNSBL and
> User-Agent validation).
$ curl -I https://aur.archlinux.org |& grep Server
Server: nginx/1.2.6
Re: [aur-general] TU application from graysky
On Mon, Mar 11, 2013 at 04:24:31PM -0400, member graysky wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi All. Inspired by Allan's talk @ SINFO XX, I decided to throw my > hat into the ring and formally apply to be a TU. My linux history > started with RH and SUSE over a decade ago. I discovered Debian and > Ubuntu. I found myself wanting more control and up-to-date repos and > discovered Arch. I find it and its underlying philosophies, and its > community to be to my liking. I have an interest in giving back to > the Arch Community though maintaining some packages in [community]. This is surely me being old and grumpy, but I miss the days when TUs wanted to do more than just maintain a few packages. Could you perhaps expand on what packages these would be? Is there a specific category that interests you, perhaps? Have you discovered the dozens of orphans in extra/community? > Listed below are a few of my contributions for those of you who don't > recognize me from the bbs or from other interactions. I reached out > to Xyne who kindly agreed to sponsor my candidacy for TU. I'm replying to the rest of this with full disclosure: graysky asked me to sponsor him first, and I've declined based on a lack of skill and what I feel isn't necessarily the correct attitude for an Arch TU. I'll reiterate some of my more salient points here. > *Maintains an unofficial repo for >2 years now (http://repo-ck.com) > whose main purpose is hosting linux-ck and related packages. > *Maintains ~50 PKGBUILDs within the AUR; some legacy others of my own > creation. > *Wiki contributions, both original content, and standardizing many > popular pages; member of Wiki Maintenance Team. > *Contributed several open-source utils back to the community. > https://github.com/graysky2/modprobed_db > https://github.com/graysky2/profile-sync-daemon I have strong feelings against even the concept of profile-sync-daemon, and transitively (although moreso), anything-sync-daemon. 1) You, as a user, cannot possibly manage memory more effectively than the kernel. Do not intentionally thwart the page cache. 2) To claim that you're saving your precious SSD "unnecessary writes" is advanced silliness. Recent controllers don't have nearly the same problems early SSDs had. 3) The only conceivable "benefit" is to move the startup time to bootup, rather than to when you first run the program. 4) Shell is inherently dangerous. If you're bent on writing something dangerous, you'd better know all the pitfalls of shell and what will eventually go wrong in your script. To wit, reading the bbs threads about these daemons will show at least 1 user who has suffered data loss simply by upgrading the profile-sync-daemon package. ...and in some cases, the program you're running this on top of is simply misconfigured for your needs. Firefox, for example, can be forced to use more RAM before switching to disk cache. > https://github.com/graysky2/profile-cleaner > https://github.com/graysky2/backdrop-randomizer > *Active contributor to Arch bugs. I find that your bug reports routinely lack effort on your part in deciphering the root of the problem leading to the bugs eventually being discarded. I'd expect a lot more effort from someone interested in being more than just an end user. Examples: https://bugs.archlinux.org/task/24850 https://bugs.archlinux.org/task/26394 https://bugs.archlinux.org/task/29182 https://bugs.archlinux.org/task/30131 https://bugs.archlinux.org/task/34080 And some your feature requests are fairly misguided, often going against Arch's patching policy: https://bugs.archlinux.org/task/31187 https://bugs.archlinux.org/task/32204 https://bugs.archlinux.org/task/33688 https://bugs.archlinux.org/task/33974 In short, this isn't the kind of attitude or skill level I'd expect from a trusted user. Sorry, Dave > *Closely related to several upstream projects including: monitorix and > the ck patchset > *Active member on the bbs; usually helpful ;p > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.19 (GNU/Linux) > > iQEcBAEBAgAGBQJRPjyfAAoJEIigMoZe5GxMdZAH/i+5wOv8jnYwZUkD/pQrIWPB > NV1+eh6+Bvfta8MLL0rSMobHSVefhD1dHpwkiyTmIHs9W2tXfWak9DsLuQaG1Tgu > 4rRc0F0o3LTtcD47hsGaatIWDr0NAq2lpGo+H24o9BhNlhH5+Pyd635JUuMeiQl6 > FQjeGheg82D9aSNsDJrRZONU1agI63+u2WTRcINW5iP2UkB9Nc0SsVdi/TDwDYPO > m9u4v93S12CdCwT9ICCmS/UIa6UmWlbTT77Q3dOXDypumE2vaiSQ7799A8bH4Mlp > PPDhoyj1uJE1KhSii8J1JAhEU3jt3w0B0QwoU2TmMRrM2KHy2lGKYC9+OuGzlmI= > =mQsI > -END PGP SIGNATURE-
Re: [aur-general] Easy way to find out package dependencies
On Sat, Mar 02, 2013 at 11:50:57PM +0100, Johannes Löthberg wrote:
> On 02/03/2013 23:46, Dave Reisner wrote:
> >On Sat, Mar 02, 2013 at 11:35:40PM +0100, oliver wrote:
> >>Hello,
> >>
> >>is there an easy way to find out, which package dependencies
> >>a package has?
> >>
> >>Say, i want to write the PKGBUILD for a package,
> >>and the compilation on my system (.7configure/cmake and make)
> >>does work without problems.
> >>
> >>Then I don't get a message about missing libraries.
> >>So, it's easy to compile the stuff, but needs some
> >>effort to find out the dependencies.
> >>
> >>Possibly with ldd the linked stuff can be found out,
> >>but the library names not necessarily are the same as
> >>the names of the package that provide these libraries.
> >>
> >>So, it may need some effort to find out the packages.
> >>
> >>Is there an easy way to find out the package names?
> >>
> >>Maybe someone already has written a script that
> >>reverse-lookups the package names from ldd-output?
> >>
> >>Any ideas on that?
> >>
> >>
> >>Ciao,
> >> Oliver
> >
> >This is probably what you're looking for:
> >
> >https://github.com/falconindy/bin-scripts/blob/master/elf2pkgs
> >
> >You can get a concise list by running this over the pkg/ directory
> >after
> >building:
> >
> > find pkg/ -type f -executable -exec elf2pkgs {} + 2>/dev/null
> >
> >d
>
> Wouldn't it be easier to just use namcap, or am I missing something?
Probably. I run pacman from git, so namcap doesn't work for me.
Re: [aur-general] Easy way to find out package dependencies
On Sat, Mar 02, 2013 at 11:35:40PM +0100, oliver wrote:
> Hello,
>
> is there an easy way to find out, which package dependencies
> a package has?
>
> Say, i want to write the PKGBUILD for a package,
> and the compilation on my system (.7configure/cmake and make)
> does work without problems.
>
> Then I don't get a message about missing libraries.
> So, it's easy to compile the stuff, but needs some
> effort to find out the dependencies.
>
> Possibly with ldd the linked stuff can be found out,
> but the library names not necessarily are the same as
> the names of the package that provide these libraries.
>
> So, it may need some effort to find out the packages.
>
> Is there an easy way to find out the package names?
>
> Maybe someone already has written a script that
> reverse-lookups the package names from ldd-output?
>
> Any ideas on that?
>
>
> Ciao,
>Oliver
This is probably what you're looking for:
https://github.com/falconindy/bin-scripts/blob/master/elf2pkgs
You can get a concise list by running this over the pkg/ directory after
building:
find pkg/ -type f -executable -exec elf2pkgs {} + 2>/dev/null
d
Re: [aur-general] Substitute nss_ldap/pam_ldap from [Extra] to nss-pam-ldapd
On Sat, Mar 02, 2013 at 04:13:01PM -0500, Dave Reisner wrote: > On Sat, Mar 02, 2013 at 01:32:48PM -0300, Thiago Kenji Okada wrote: > > nss-pam-ldapd is actively maintained while nss_ldap/pam_ldap are not > > updated in a while. nss-pam-ldapd is more robust too (I had a similar > > problem like https://bugs.archlinux.org/task/33672 that didn't occur with > > nss-pam-ldapd; and according to that bug report actually a > > nss_ldap/pam_ldap setup is simply broken). According to the author ( > > http://arthurdejong.org/nss-pam-ldapd/) nss-pam-ldapd is faster and more > > easily to debug (I didn't measured performance, but indeed nss-pam-ldapd is > > easier to debug, since it's service nslcd have a nice log output). I think > > Fedora and Mageia uses nss-pam-ldapd for default instead nss_ldap/pam_ldap. > > Even our Wiki (https://wiki.archlinux.org/index.php/OpenLDAP_Authentication) > > is recommending nss-pam-ldapd instead of nss_ldap/pam_ldap (actually, if > > you follow our Wiki using nss_ldap/pam_ldap you will have a non-working > > LDAP setup). > > > > So I suggest to drop nss_ldap/pam_ldap to AUR and put nss-pam-ldapd on > > [Extra] repository. > > -- > > Thiago Kenji Okada > > PGP Key: EEC09705 > > Looks like there's already a feature request: > > https://bugs.archlinux.org/task/32911 > > @Tom and Allan, you guys maintain the packages that would be replaced > here -- either of you have an interest in adopting this? > > d Argh. Reading the wrong field... Definitely all Jan.
Re: [aur-general] Substitute nss_ldap/pam_ldap from [Extra] to nss-pam-ldapd
On Sat, Mar 02, 2013 at 01:32:48PM -0300, Thiago Kenji Okada wrote: > nss-pam-ldapd is actively maintained while nss_ldap/pam_ldap are not > updated in a while. nss-pam-ldapd is more robust too (I had a similar > problem like https://bugs.archlinux.org/task/33672 that didn't occur with > nss-pam-ldapd; and according to that bug report actually a > nss_ldap/pam_ldap setup is simply broken). According to the author ( > http://arthurdejong.org/nss-pam-ldapd/) nss-pam-ldapd is faster and more > easily to debug (I didn't measured performance, but indeed nss-pam-ldapd is > easier to debug, since it's service nslcd have a nice log output). I think > Fedora and Mageia uses nss-pam-ldapd for default instead nss_ldap/pam_ldap. > Even our Wiki (https://wiki.archlinux.org/index.php/OpenLDAP_Authentication) > is recommending nss-pam-ldapd instead of nss_ldap/pam_ldap (actually, if > you follow our Wiki using nss_ldap/pam_ldap you will have a non-working > LDAP setup). > > So I suggest to drop nss_ldap/pam_ldap to AUR and put nss-pam-ldapd on > [Extra] repository. > -- > Thiago Kenji Okada > PGP Key: EEC09705 Looks like there's already a feature request: https://bugs.archlinux.org/task/32911 @Tom and Allan, you guys maintain the packages that would be replaced here -- either of you have an interest in adopting this? d
Re: [aur-general] How to see the interest in a package (other than votes)?
On Thu, Feb 28, 2013 at 09:34:11PM +0100, oliver wrote: > On Thu, Feb 28, 2013 at 03:19:09PM -0500, Dave Reisner wrote: > > On Thu, Feb 28, 2013 at 09:09:30PM +0100, oliver wrote: > > > Hello, > > > > > > > > > is it possible to see the number of downloads of packages from AUR, > > > so that it can be detected, how much interest in a package exists? > > > > > > Say, there are some users who do not have a AUR-login, > > > and just would install the packages that are there... which are possibly > > > outdated, but would nevertheless be interested in installing > > > newer package, if possible. > > > > > > If the download number is high enough, even if there > > > are not much votes (because some people may only > > > install stuff but are not interested in package maintaining and so on), > > > then at least interest of a package might be detected this way. > > > > This is an extremely flawed premise. > > > > > I'm asking, because I think I can adopt some more packages, > > > but would of course only pick those that I find interesting. > > > > > > They might be interesting (topic), even if I wil not use > > > them by myself. > > > So, from that standpoint, I would then select by my own > > > interest and that of other people. > > > For packages that I use by myself, of course my interest is clear, > > > and I would pick such packages. > > > > This is really strange (non-)logic. The best maintainer for a package is > > one who is actively interested in the package itself and uses it. How > > else could you possibly support it? > > Of course, as I said, I would NOT adopt packages that are > completely uninteresting for me. > Nevertheless, if I think a topic is interesting, and is somehow related > to something I would like to see spreaded, adopting it can make sense. > > For example, if I want to push the usage of R, and there are GUIs for > R, that many people would like to use, supporting a GUI for R can mek sense, > even I prefer the shell without GUI for myself. > But if it contributes to spreading R - which I think is a wonderful program - > it would make sense. E.g. I could show the GUI to some friends, who are > GUI-addicted, > and in this way introduce them to R. > > So I would not use it, but would like to provide it. > But it makes no sense, if nobody asks for it. > > Do you see what I have in mind? No. I don't. > Do you nevertheless think, this is weak motivation? Yes, I do. Adopt things because you're interested in them, not because they're (potentially?) popular. > About the metrics: download numbers are not perfect, but better than > nothing? What you propose is surfacing raw *data*. I made a counter proposal of adding potential heuristics so that useful *information* could be displayed. I do not believe there is any value in showing the raw data, and, if anything, I believe it would only be misleading. d
Re: [aur-general] How to see the interest in a package (other than votes)?
On Thu, Feb 28, 2013 at 09:09:30PM +0100, oliver wrote: > Hello, > > > is it possible to see the number of downloads of packages from AUR, > so that it can be detected, how much interest in a package exists? > > Say, there are some users who do not have a AUR-login, > and just would install the packages that are there... which are possibly > outdated, but would nevertheless be interested in installing > newer package, if possible. > > If the download number is high enough, even if there > are not much votes (because some people may only > install stuff but are not interested in package maintaining and so on), > then at least interest of a package might be detected this way. This is an extremely flawed premise. > I'm asking, because I think I can adopt some more packages, > but would of course only pick those that I find interesting. > > They might be interesting (topic), even if I wil not use > them by myself. > So, from that standpoint, I would then select by my own > interest and that of other people. > For packages that I use by myself, of course my interest is clear, > and I would pick such packages. This is really strange (non-)logic. The best maintainer for a package is one who is actively interested in the package itself and uses it. How else could you possibly support it? > But say there are 100 orphaned packages and 20 of them look > interesting, but I would not use them by myself, then I would adopt > those, who are wanted by many people. > (And any package that I want to install myself.) > > I hope I could make ckear, why I'm asking. > > Say, there are 5 interesting packages, but 3 of them > will not be used, because that stuff is not used any more > (maybe because better projects are to prefer), then three don't need > support I think. > > So, the tarball download numbers do matter in this respect. I disagree. Downloading a tarball doesn't mean you intend to build, install, and use it. > Is it possible to add them to the AUR-pages of a project? And display this how? A flat "download count" would be of little interest or value. Would it be reset every time there's a new PKGBUILD uploaded? Maybe only for pkgver changes? Would that include pkgrel bumps too? What about historical data? Trending? Unique by IP? Unique by IP within a given date range? If you want to make download count a useful metric, you have to do a lot more than display a raw counter. As you propose it, it's no better (and probably worse) than a vote count.
