I have no sound and have added the alias material in modules.conf
When is a zero always equal to a one?
]]>Whether to reinstate the remaining packages for future upgrade? Having them in the IgnorePkg line only omits them from a general (pacman -Syu) upgrade - you can always upgrade them individually by specifically telling pacman to do so (eg: pacman -S kernel) Before reinstating them, it would make sense to see if they can be upgraded in this way.
But is it worth trying to upgrade them? Lilo: I would suggest not, in view of all the problems you have had with it. If it's doing its job, why risk trouble by upgrading it? Kernel: I think there is a minor discrepancy about what version you are running, but again I'd say leave well alone. When the dust has settled you'll probably want to move to the 2.6 kernel anyway, which is a quite separate package. That leaves koffice. If you use it and you want the latest version, I would suggest you remove it with pacman -R koffice and then reinstall it with pacman -S koffice. If it installs cleanly, you could then remove it from the IgnorePkg list so it gets included in future pacman -Syu's.
]]>I assume that I should go back into /etc/pacman.conf and install the (#) again on ...ignore?
I am hoping I have no more problems but don't bet on it. Thanks for the buggy ride!
Query: When is a zero always equal to a one?
]]>I'm not going to predict what will happen when you resolve those conflicts because the entire behaviour you are experiencing appears anomalous and is outwith my experience. Normally if there are conflicts, pacman will present them all at once.
I would be inclined to exclude kernel - it's just a complication you can do without and it would be easy to do it separately afterwards. I would definitely exclude lilo too, given your history of problems with lilo!
Yes, all on one line; that's a quote from mine that I posted: if you look in the existing pacman.conf file it's practically done for you - I assume you have read man pacman?
]]>Dauphin;
The arts pkg was the first one entered during the ugly upgrade but I had not entered it with the ..pacman -Sy kde listings because, like koffice, it wasn't a kde pkg by name!!!! I was surprised that it appeared!!!!! The instructions generalized(only the kde pkgs!!!)..
I suspect the following: when I finish with the present /optkde/share/mimelink/application/mathml+xml.desktop.... and the following additional conflict listings of the same category;/application...
calc
draw
impree
writer
kudesigner
magicpoint
kexi
kde plato
kde kugar
photoshop
picture ; I will then be presented with additional conflicts for the Kernel 2.4.24-1 and for any other pkg which is older than the installed pkg.
I shudder to think of what would occur if I loaded a pkg from another distro and had a conflict with arch on an upgrade!!!!
Should I include the kernel in the change to pacman.conf? On the same line?
Perhaps you know whether the apps listed above are koffice items?
If koffice is the pkg in conflict, why isn't it identified as the conflict? The message is specific to particular files whereas the purpose of the activity is to load pkgs. A package in conflict should therefore be identified.(IMHO)
Ugly is ugly!!!
IgnorePkg = lilo kernel koffice
How about arts - that is also part of kde although it doesn't start with kde...?
Alternative approach: look more closely at the 14 conflicts listed; if they are minor items like icons you could just delete them (or to be safer, rename them) manually before doing the upgrade as the upgrade will probably replace them anyway. If they appear more significant, it might be risky to delete them (although you could still rename them, provided you know how to get back into the system to change the names back if it fails to boot) but you might get some ideas as to the packages which are giving rise to the conflicts.
]]> The only pkg I can find in the listing under pacman -Su is koffice-1.2-1....all other k-type packages were loaded under the ugly update procedure and are present in the system pacman -Q listing. Koffice was not included because it wasn't seen as an update (3.2.x pkg).
Perhaps that is the cause of the difficulty...not knowing everything is a handicap when reading generalities(only the kde packages not their dependencies) instead of accurate specifics.
If koffice is the culprit what action is needed to delete it from -Su?
Koffice in pacman -Q is version 1.2-2.
The situation seems to indicate that the ugly problem persists because specifics have been lacking. Exact instructions prevent misapplication.
Longevity=longlevity!!!
]]>If it's KDE which is holding back the system upgrade, why don't you edit /etc/pacman.conf to ignore all the KDE packages? That might let the rest go through. If that works, you would remove the KDE packages from the ignore listing and focus on how to deal with the KDE upgrade in isolation.
]]> There are 14 conflicts in kde of the form:
/opt/kde/share/.......et cet..........exists in file system.
There are at least 100 files from abiword-2.0.3-4 to zlib-1.2.1-1
The kernel listed is 2.4.24-1 and the kernel in the system is 2.4.24-2.
:!: :?:
]]>I have kde working now with access to linux forum.
I entered pacman -Su and it resulted in a large listing..attempted to install all but received a dozen conflicts so none of the pkgs were installed.
Needless to say, there is no sound and no cd .
]]>Get scrollkeeper up to date if it is not already.
Then please try what I suggested and try upgrading some individual packages. I am not suggesting you upgrade each package in the system individually, but merely that you test the functionality of pacman on your system by doing a few before you commit to an -Syu which you have had so much trouble with previously. It would also be easier for you to see what might be going wrong if you were only working on one or a few packages at a time.
Hence my advice that you try some "easy" packages for upgrade - libogg may be as good a place to start as any, progress to any you feel have been problematic in the past, and then finish off the rest with -Su.
If pacman still appears from this to be broken, then I venture to suggest that it will be easier to start over yet again, but if you decide to take that route I would advise that - as the installer suggests, you start by just installing the base packages from the cd, instead of putting on a lot of other packages that are immediately going to have to be upgraded anyway.
If you decide to reinstall, surely there is some way you can copy the contents of the cache to another partition or to CD-R so that you don't have to download everything again?
It's getting late here now, so I will catch up with developments in the morning. I wish you good luck.
]]>Inspection of pacman -Syu listed 80 pkgs on the display which started at libogg-1.1-1. I don't know how to bring up the packages previous to these but I cannot load these separately and not the others which aren't on display and it would take a lifetime to do it!!!
I am again in the same quandry I encountered before in using pacman -Syu. I do not know the sequences which must be encountered when using it.
It is supposed to be automatic, lol, but seriously.....when I get a root prompt I assume the procedure is finished...not that it gave up!!!! I do not think any packages were loaded in pacman-Syu due to scrollkeeper. If there were any error messages stating that the upgrade was aborted, they did not appear on my screen.
Perhaps I need to know how to back up the screen listings in the presence of root prompt. Do I use dmesg?
After pacman -Sf scrollkeeper activity I received a root prompt. What should then be done? Re-enter pacman-Syu? I did not do that but I wish I had!!
When the word upgrade is used along with the word "install pkg" does this mean "download the pkgs and install them in cache"? That seems to be the way it runs!
I do not mind performing pacman -Syu if it goes through its paces ending up with "install the packages into the system".
Can I do pacman -Sf scrollkeeper before download with pacman -Syu?
No... because the new scrollkeeper isn't there until I download!! So I go round and round in the loop!!
Still puzzled about the kernel, but optimistically hoping any inconsistencies get ironed out during the process outlined above.
]]>