You are not logged in.
Hi Archers,
I recently upgraded pacman to 4.2 and since then makepkg process fails when building an AUR package towards the end of the building stage with the following error.
make[2]: Leaving directory '/usr/lib/modules/3.17.6-1-ARCH/build'
./scripts/rmmod.pl check
found 612 modules
make[1]: Leaving directory '/home/mythtv/AUR/ff-tbs-alves/src/media_build/v4l'
fatal: No upstream configured for branch 'makepkg'
fatal: No upstream configured for branch 'makepkg'
./configure: line 192: [: babe1712139e364b2a46cb6b509e68b8a1a69831: unary operator expected
./configure: line 194: [: babe1712139e364b2a46cb6b509e68b8a1a69831: unary operator expected
#####################################
Your local clone cannot be synced
with remote repo due to local changes
Aborting...
######################################For the record:
1) The same error occurs on 3 different previously functioning AUR packages using GIT
2) I have wiped all GIT and src directories etc clean but error still comes
Any ideas?
Last edited by wdirksen (2015-01-01 22:17:53)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
Works fine here. I guess you are using an AUR wrapper...
Not a Pacman issue, moving to AUR.
Offline
Am I missing something in the initial post that says what package this is? Can you give us examples we could try?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It seems that the build system is trying to pull from the git server. Is there any way to disable that?
Online
Thanks for chiming in.
I got the same error in a non-GIT situation. Here's a AUR that fails that does work with pacman 4.1
https://aur.archlinux.org/packages/ffde … r-git-tbs/
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
I got the same error in a non-GIT situation. Here's a AUR that fails that does work with pacman 4.1
https://aur.archlinux.org/packages/ffde … r-git-tbs/
Again; works fine here...
How are you trying to build these packages?
# edit: and please fix your PKGBUILD: tbs-linux-drivers is a depends
Offline
The plot thickens. Same failure without any VCS used anywhere in PKGBUILD. https://aur.archlinux.org/packages/tbs-dvb-drivers/
As in the above AUR package, the downloaded file from TBS gets the same error:
LD [M] /home/mythtv/AUR/ff-tbs/src/linux-tbs-drivers/v4l/zr36067.ko
LD [M] /home/mythtv/AUR/ff-tbs/src/linux-tbs-drivers/v4l/zr364xx.ko
LD [M] /home/mythtv/AUR/ff-tbs/src/linux-tbs-drivers/v4l/zr36060.ko
make[2]: Leaving directory '/usr/lib/modules/3.17.6-1-ARCH/build'
./scripts/rmmod.pl check
found 522 modules
make[1]: Leaving directory '/home/mythtv/AUR/ff-tbs/src/linux-tbs-drivers/v4l'
fatal: No upstream configured for branch 'makepkg'
fatal: No upstream configured for branch 'makepkg'
./configure: line 192: [: babe1712139e364b2a46cb6b509e68b8a1a69831: unary operator expected
./configure: line 194: [: babe1712139e364b2a46cb6b509e68b8a1a69831: unary operator expected
#####################################
Your local clone cannot be synced
with remote repo due to local changes
Aborting...
######################################I just rechecked on another machine which has not yet been upgraded to pacman 4.2. Works fine.
Interesting that on https://aur.archlinux.org/packages/ffde … r-git-tbs/
the GIT VCS for ffdecsawrapper has no issues. It is the V4l related lib's that get this error.
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
I'm going to close this thread unless you tell us how you are building these packages.
Offline
... How are you trying to build these packages?
Just a simple makepkg. I can reproduce using:
yaourt tbs-dvb-drivers... and please fix your PKGBUILD: tbs-linux-drivers is a depends
Actually tbs-linux-drivers is an old orphaned AUR package that conflicts with my package. Could be omitted by now I guess as no-one uses it anymore
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
The depend is in the previous package you linked to (ffdecsawwrapper): the one I built that pulled in tbs-linux-drivers even though it is supposed to be an optdepend...
Offline
I just replicated the error. Apparently the configure script tries to do a git pull. I've never heard of that in a configure script - that seems like a horrible idea.
EDIT: reading the usage data for that custom configure script gave it away pretty quick though. Use `configure --update=no`. (edit2: I just confirmed this fixes it).
Last edited by Trilby (2015-01-01 21:36:41)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
The depend is in the previous package you linked to (ffdecsawwrapper): the one I built that pulled in tbs-linux-drivers even though it is supposed to be an optdepend...
@jasonwryan
First thanks for your involvement here.
tbs-dvb-drivers and ffdecsawrapper-git-tbs are very similar. Both install the TBS drivers. The ffdecsawrapper package builds one extra module and one binary but the module needs to built with special make arguments against the actual DVB drivers being used in the system. Therefore all previously installed out of kernel DVB drivers directly conflict with the ffdecsawrapper-git-tbs package. The tbs-linux-drivers package really needs to be removed from AUR as no-one uses it and it will always conflict with any of other packages we are discussing. I have noticed that all AUR's include themselves in the conflicts. I guess this is standard.
Under my AUR handle (p-we) I maintain a few DVB related packages with alot of dedication and there are alot of users out there. The AUR's I have are sound and have worked well until I upgraded to pacman 4.2. I would be glad to learn more but I know for a fact that this is not a matter of just a bad PKGBUILD. I don't know if PKGBUILD parameters have changed with pacman 4.2.
Have you tried to build tbs-dvb-drivers? https://aur.archlinux.org/packages/tbs-dvb-drivers/
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
I just replicated the error. Apparently the configure script tries to do a git pull. I've never heard of that in a configure script - that seems like a horrible idea.
EDIT: reading the usage data for that custom configure script gave it away pretty quick though. Use `configure --update=no`. (edit2: I just confirmed this fixes it).
Thanks Trilby. I will augment my AUR packages if needed. The big question though...
Why does it work fine with previous versions of pacman? Is this an issue with my TBS sources or is this an issue with pacman 4.2?
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
It's the sources, you can check the configure scripts and see for yourself, they run their own git clone unless you pass that flag not to.
You can see the relevant commit here
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It's the sources, you can check the configure scripts and see for yourself, they run their own git clone unless you pass that flag not to.
You can see the relevant commit here
Yeah, I'm seeing that all V4L GIT related branches etc. use similar build methods. If this reflects a permanent a issue with pacman 4.2 and above then I will patch my packages accordingly. Thanks All!
Last edited by wdirksen (2015-01-01 22:26:03)
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline
I'm pretty sure this has nothing to do with pacman or makepkg - this was a change in the upstream source.
Have you tried downgrading pacman and building the current upstream packages?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I'm pretty sure this has nothing to do with pacman or makepkg - this was a change in the upstream source.
Have you tried downgrading pacman and building the current upstream packages?
It works on pacman 4.1 on a PC I haven't upgraded yet. With previous pacman 4.1 it does try to sync with GIT, gives a warning and moves on building the package. I originally discovered this on the ffdecsawrapper-git-tbs-unofficial package and assumed it was related to one of the V4L GIT mirrors not the ffdecsawrapper GIT resources.
Thanks for your input as this was easily fixed when you discovered where the issue was.
Research | Trial | Make Mistakes | Ask questions | Learn | Repeat
Offline