You are not logged in.
I'm trying to build NVIDIA-304.22...
makepkg nvidia results in:
==> Missing Dependencies:
-> nvidia-utils=304.22
Why should it requiring nvidia-utils at build time - it just builds a kernel module!
Building nvidia-utils succeed - but installing results in:
:: nvidia: requires nvidia-utils=302.17
I think it's a circular reference problem... isn't it?
Last edited by rtfreedman (2012-07-20 20:25:59)
Offline
Build and Install nvidia-utils first , then build and install nvidia module. That's it!
Offline
It's not really clear what you're getting at. Taking your post literally, it says you're trying to build two packages that depend on each other which claim to depend on older versions (nvidia-utils 302.17, nvidia 304.22), and I'm not finding Nvidia 304.22 in the AUR anywhere. So the questions are:
Where did you get this driver?
If there is a genuine dependency conflict, are you trying to install two different patched versions of two different packages (which may thus be incompatible with each other)?
Remember that circular dependencies are only such if they are two packages which are supposed to be compatible/installed as a set, but are not/can not be. It's also not clear why a package you try to install would claim it depends on an older version of itself to install itself; your bit about nvidia requiring nvidia-utils seems like an opt-depends output. Posting your makepkg/pacman output might be helpful.
Last edited by ANOKNUSA (2012-07-16 21:55:52)
Offline
Build and Install nvidia-utils first , then build and install nvidia module. That's it!
That's what I've tried already - quote from my first post:
Building nvidia-utils succeeded - but installing results in:
:: nvidia: requires nvidia-utils=302.17
@
Where did you get this driver?
From nvidia - it's the latest release.
I've taken the latest PKGBUILD from abs, adapted version & md5sum and tried to no avail
- either it can't build (nvidia) or can't install (nvidia-utils) - see my first post.
Last edited by rtfreedman (2012-07-16 22:50:43)
Offline
@rtfreedmon
1. you first need to remove your current (old 302.17) nvidia driver
2. then after that you need to install/update to nvidia-utils-beta (which AFAIK is 304.22, currently && is available in AUR).
3. Once you have done that you can install the nvidia driver...
I am not sure why you need to modify the pkgbuild (if you only want the latest driver) as 304.22 is available in the AUR via 2 pkgbuilds; nvidia-beta or nvidia-beta-all (-all will install the driver for all kernels that you have installed, while nvidia-beta will just install to the kernel you are using at time of installation.)
essentially, you always have to remove the old driver in order to install the new nvidia-utils version. you are only having an issue because you haven't removed the driver, and until you do that you won't be able to update to nvidia-utils(-beta)... and you won't be able to upgrade the driver until you are using the matching pkgver for nvidia-utils. clear enough?
@ANOKUSA - you must have not looked very hard being as 304.22 has been available in the AUR since the very day it was released.
cheerz and i hope that helps
EDIT: i should point something that might be important here; if your system is not fully up-to-date - you won't be able to use the nvidia-beta/nvidia-beta-all from AUR - they both rely on the latest kmod + glibc updates (modules are no longer found in /lib, but instead are in /usr/lib/modules). so if you were to install the driver it would be in the wrong place and thus not work.
so i would recommend if you haven't already, go to Archlinux.org and follow the instructions for that update in the announcements section.
Last edited by triplesquarednine (2012-07-16 23:45:10)
Offline
@ANOKUSA - you must have not looked very hard being as 304.22 has been available in the AUR since the very day it was released.
I asked because the OP doesn't refer to them as nvidia-beta and nvidia-utils-beta, as the AUR packages are named, which means...
[I got it] From nvidia - it's the latest release.
I've taken the latest PKGBUILD from abs, adapted version & md5sum and tried to no avail
- either it can't build (nvidia) or can't install (nvidia-utils) - see my first post.
...and therefore PEBKAC was a real possibility; it would certainly explain why one package calls for an outdated version of a dependency.
EDIT: I cut out my last sentence, since it was needlessly snarky and not at all constructive. ![]()
Last edited by ANOKNUSA (2012-07-18 00:07:51)
Offline
I asked because the OP doesn't refer to them as nvidia-beta and nvidia-utils-beta, as the AUR packages are named, ...cont'd
I wasn't concerned about your line of questioning, nor did i have any bad intentions. I was pointing out that the 304.22 has been available in the AUR, since it's release because you said this;
I'm not finding Nvidia 304.22 in the AUR *anywhere*
...when in reality, there are 2 different packages in AUR.
which means... <---- are you sure about that??
rtfreedman wrote:[I got it] From nvidia - it's the latest release.
I've taken the latest PKGBUILD from abs, adapted version & md5sum and tried to no avail
- either it can't build (nvidia) or can't install (nvidia-utils) - see my first post....and therefore PEBKAC was a real possibility; it would certainly explain why one package calls for an outdated version of a dependency.
I agree human error, but in this particular case ~ the human error is assuming he could update the driver (before updating nvidia-utils), when nvidia (driver) requires nvidia-utils (with a matching pkgver). then the second error was assuming he could update nvidia-utils (bumping it's pkgver) and still satisfy pacman without first removing the (old) driver. I don't think it was a question of editing the PKGBUILDS wrong, because you would run into this anyway - simply using pacman/yaourt, if you weren't aware of how these packages relate and you were trying to upgrade them. ie: i did the exact same thing once...lol ![]()
EDIT: I cut out my last sentence, since it was needlessly snarky and not at all constructive.
yeah, probably a good idea - since i wasn't trying to be offensive or nasty ![]()
cheerz
Last edited by triplesquarednine (2012-07-18 01:35:42)
Offline
Thanks for all the replies - and there was a lot to read ![]()
When I downloaded the new release, there wasn't any sign of it in the aur.
I've some screen update issues with kaffeine ever since xorg was updated to the latest driver.
That's to my motivation...
Looks like I misunderstood/misinterept' 'depends' and 'makedepends':
Any dependency in 'depends' obviously will be checked on makepkg also.
My line of thoughts were other way round: 'depends' is for installing, 'makedepends' is for building
As to the recommended procedure - I think it's unnecessary complicated.
I'm used to build nvidia for slackware just as every other package - there's nothing referencing the old package while building the new one.
Last edited by rtfreedman (2012-07-18 17:06:39)
Offline
which means... <---- are you sure about that??
Nah, not really. It was a strong hunch, but I had no way of really knowing. ![]()
yeah, probably a good idea - since i wasn't trying to be offensive or nasty
cheerz
Yeah, I wasn't trying to seem defensive or hostile either, which is why I cut out my last little comment; you're just looking to help the OP out. The heat around here is driving me crazy, and I'm kinda turning into a jerk.
@rtfreedman: Are things working well for you then? If so, please mark your thread as [Solved].
Last edited by ANOKNUSA (2012-07-18 23:01:03)
Offline
@ANOKNUSA
Yeah, i had no way of really knowing, but when i read his first post i was about 99.8% sure he was having the issue that i thought he was ![]()
as for the heat ~ In particular, Sunday and Monday were brutally hot - so i definitely feel you on the heat driving you crazy...lol
thankfully, it has cooled down in the last couple of days where i am (In Toronto).
@rtfreedman
Glad to see you got the problem solved! ![]()
Offline
One final comment:
I've modified the PKGBUILD from the 302.17 release, removed "nvidia-utils=${pkgver}" from 'depends',
build all needed packages (nvidia, nvidia-utils & opencl) and upgraded them with
sudo pacman -U nvidia-utils-304.22-1-i686.pkg.tar.xz opencl-nvidia-304.22-1-i686.pkg.tar.xz ../nvidia/nvidia-304.22-1-i686.pkg.tar.xz - everything went well ![]()
While the additional 'depends' might be foolproof while updating... it's annoying (*) while building
- nvidia works very well without nvidia-utils; it's just a convenient tool.
As for the AUR release, it sounds a bit scary with the -beta appended and (outdated) warning for enabling [testing] to get it working!
Isn't 302.17 much like 304.22 - a beta release?
And why isn't it updated in extra?
(*) There's no dependency on nvidia-utils while building nvidia
but installing nvidia-utils should pull in nvidia.
Last edited by rtfreedman (2012-07-20 21:36:29)
Offline
One final comment:
I've modified the PKGBUILD from the 302.17 release, removed "nvidia-utils=${pkgver}" from 'depends',
build all needed packages (nvidia, nvidia-utils & opencl) and upgraded them withsudo pacman -U nvidia-utils-304.22-1-i686.pkg.tar.xz opencl-nvidia-304.22-1-i686.pkg.tar.xz ../nvidia/nvidia-304.22-1-i686.pkg.tar.xz- everything went well
While the additional 'depends' might be foolproof while updating... it's annoying (*) while building
- nvidia works very well without nvidia-utils; it's just a convenient tool.
thanks for the clarification. whatever works, i suppose
I personally see no problem with it, but to each their own.. i just have a custom repo and update the pkgver as i like. - i don't find it annoying at all.
As for the AUR release, it sounds a bit scary with the -beta appended and (outdated) warning for enabling [testing] to get it working!
Isn't 302.17 much like 304.22 - a beta release?
And why isn't it updated in extra?
I already touched on this, when i warned you you couldn't install -beta without having an up-to-date system. he was simply letting users know that the pkgbuild was no longer compatible with systems using /lib && the old kmod, as his pkgbuild had been updated just before kmod came through as an update. He says in that message, not to update unless you are using the new kmod from [testing]. ~ I'm not sure why you think that is scary, exactly (?) no one was telling you to enable [testing], but instead that unless you were using testing, you would need to wait to upgrade nvidia-beta, as the new kmod was a requirement at the time.
[extra] usually doesn't have a beta driver (to my knowledge), i am not sure why 302.17 is in there. I'm pretty sure nvidia would consider 295.59 to be the stable driver.
(*) There's no dependency on nvidia-utils while building nvidia
but installing nvidia-utils should pull in nvidia.
good to know, although i don't imagine i will be modifying my current nvidia pkgbuilds, since they work as expected.
Offline
(*) There's no dependency on nvidia-utils while building nvidia
but installing nvidia-utils should pull in nvidia.
Sounds like you have discovered a missing option in PKGBUILDs.
There appear to be 3 types of dependencies :
builttime dependencies (makedepends= only needed during build))
runtime (only needed AFTER installing)
build & runtime (depends=, needed at both buildtime and runtime)
Atm PKGBUILDs don't have an array for runtime dependencies, only solution for now is to put runtime dependencies in depends.
Maybe you can create a feature request for makepkg ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
This could be over quite painless, if you posted both your PKGBUILD's.
Offline
This could be over quite painless, if you posted both your PKGBUILD's.
I'm not sure what you mean by "this could be over quite painless, ...", or why i would need to post a pkgbuild. For one, the OP's problem has been [SOLVED], and I personally have zero issues with the way the nvidia pkgbuilds currently work.
rtfreedman is just discussing how nvidia-utils isn't actually required to compile the driver, and by removing it from depends - he personally finds it easier to work with on upgrades - I don't need to see his pkgbuild to understand what he has done, since he has already explained it and it wasn't anything difficult to understand to begin with.
If Lone_Wolf is correct in that there may be some missing functionality that could be added to makepkg - that is another issue - that may have been exposed in this thread - but regardless of whether or not that is the case - it really would still need to be addressed in another post, as a feature request.
maybe rtfreedman should be contacting to the nvidia packagers for Arch - to see why things are done the way they are and also discuss whether or not makepkg is missing functionality that nvidia packaging maybe exposes. (This i don't know and am not really concerned about either - since i have no issue with how the pkgbuilds currently work).
cheerz
Last edited by triplesquarednine (2012-07-23 12:46:16)
Offline
Oh, that sounded too harsh, my apologies. I should pay more attention, I was a little preoccupied it seems.
Offline
by removing it from depends - he personally finds it easier to work with on upgrades
'annoying' doesn't tell the real problem as I see it:
Removing a (used & working) package from system just to (test) build a new package left the system (potentially) in a broken state.
Until the new package is ready any lock up or power fail results to a possible broken system on restart
and a need to reinstall the removed package.
What if the new package is intended to be installed on an embedded/minimal system without base-devel installed?
Cross-compiling comes to mind (didn't really checked this on arch) or I fucked up PKGBUILD and went frustrated to bed.... ?
Offline
'annoying' doesn't tell the real problem as I see it:
Removing a (used & working) package from system just to (test) build a new package left the system (potentially) in a broken state.
Until the new package is ready any lock up or power fail results to a possible broken system on restart
and a need to reinstall the removed package.
I would like to point out a serious problem with your logic here - if you are using custom pkgbuilds, wouldn't it be much smarter to not uninstall a package your are planning to replace *until* you have actually built it's replacement? makepkg does give you the option of whether or not to install it, you know this right?
I for one would never go about things the way you describe above and if i did and hosed something on my system - it would essentially be my own fault for not taking better precautions- ie: human error... however, you can't hose your system by nvidia failing to install, the worst that will happen is you will reboot and be greeted by a console, then you issue one simple command to install the driver, load the nvidia module and startx.
What if the new package is intended to be installed on an embedded/minimal system without base-devel installed?
Care to go into detail here?
Cross-compiling comes to mind (didn't really checked this on arch) or I fucked up PKGBUILD and went frustrated to bed.... ?
read my first response - why would you uninstall the package first, and then modify (screw up) the PKGBUILD - then go to bed fully knowing you could (theoretically) hose your system??? (but again, nvidia won't hose your system). This really seems like a bad way to do things, which is completely (and easily) avoidable, with just a little forethought.
regardless, if you see this as a real problem, you should certainly open a new thread / feature request and gets some of the devs input on it.
Offline
quote from your first post .s.a
1. you first need to remove your current (old 302.17) nvidia driver
Or more general: Removing a (used & working) package from system just to (test) build a new package.
I think this is bad for several reason, s.a.
if you are using custom pkgbuilds
no custom, just updated ver & md5sum in orig PKGBUILD
wouldn't it be much smarter to not uninstall a package your are planning to replace *until* you have actually built it's replacement?
Yep! I tried, it started this thread.
Last edited by rtfreedman (2012-07-25 08:04:35)
Offline
Or more general: Removing a (used & working) package from system just to (test) build a new package.
Which can be easily reinstalled and will NOT cause any problems in the running session until and unless you decide to reboot.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Which can be easily reinstalled ...
You missed the point.
At first there is dependency hell for no good reason, see my first post.
This gets solved by a kludge - removing a package which doesn't interfere with the build process
only to silent makepkg.
This isn't logical - you have to know it somehow.
From the man page for PKGBUILD
depends (array)
An array of packages this package depends on to run...
There is no word about build time dependency.
Why is makepkg checking a run time dependency?
Offline