On 20 November 2015 at 13:22, <notify(a)aur.archlinux.org> wrote:
> fckinshitag  filed a deletion request for b43-firmware :
> i want this file
>  https://aur.archlinux.org/account/fckinshitag/
>  https://aur.archlinux.org/pkgbase/b43-firmware/
Okay, I see what's going on here. This guy has interpreted the "File
Request" link (i.e. in the "Package Actions" section of each package
's AUR webpage
) as being a way of requesting a file (i.e. the package in this case).
To prevent this kind of mixup in future, I would recommend that
link be renamed to "Lodge Request". I don't think anyone would be dumb
interpret this as
a way of requesting lodging at
Hi all, I discovered this problem back in June with the help of the
guys on IRC. The guy who helped me discover the root of the problem
went on to discuss with one of the TUs about this problem and the
solution for it. IIRC, Lukas was on holiday at the time, so he wasn't
pestered with it at the time :)
Three to four months later and nothing seems to have changed, so I
thought I'd start a paper trail and bring this to the attention of a
few more people.
I committed changes to an already-established AUR package, and
attempted to push these commits. Running `git push` on my slow
connection just hangs. 'Impatient me' killed it after 5 minutes of
hanging. Trying to push from a faster connection, I found it uploaded
almost instantly. Setting GIT_TRACE_PACKET=1 when running `git push`
showed up a (warning: large) log  showing that git is being sent a
bunch of refs (?), presumably for packages which aren't even mine.
On a slow connection, this makes updating AUR packages to impossible.
It takes a solid 20 minutes for the push to complete for me. I won't
maintain AUR packages if this is the way it's going to be. Even though
faster connections solve the time problem, it then becomes an issue of
the amount of data transferred needlessly.
Why is this happening? IIRC, the IRC folk mentioned something about
the underlying structure of the git repository at the AUR end, but I
don't know enough about this stuff to say either way.
Log, xzipped for size reasons. Unpacks to ~82 000 lines.
I like to build my AUR packages within a chroot by using
`extra-x86_64-build` from the `devtools` package for some reasons:
1. I usually build only once my packages and share them between my
machines. For this, the package shouldn't link against libraries
that are found on the machine because they are not always available
on the other ones.
2. It's *a little bit* more safe as the code is executed within a
3. When creating/developing packages, I'm sure that all dependencies
I created a `python-keras-git` package, that is a split package with
both python2 and python3 version of it . Someone pointed me out that
because of my `make-depends`, people has to have both python2 and
python3 installed to build only the desired version of the package, what
But in another way, if I remove this make-depends, then
`extra-x86_64-build` script can no build the package any longer, as it
needs python to build the package (for using `python setup.py …`)
So here are some questions:
- If I choose one of `python` or `python2` to build the package,
people having the other will have to install it also. (and I don't
know if python-setuptools can build also for python2 or vice-versa?)
- If I put both, people will have to install the one they don't have.
- If I don't define a make-depends, the PKGBUILD is not complete.
- It doesn't seem possible to put the make-depends inside the
`pakages_<pkgname>()` function, isn't it?
What is the right/best way of achieving this?