You are not logged in.
Hi,
After installing Kicad I've got this output, every time I use pacman:
error: file owned by 'kicad' and 'kicad-docs-bzr': 'usr/share/kicad/internat/ca/kicad.mo'
error: file owned by 'kicad' and 'kicad-docs-bzr': 'usr/share/kicad/internat/cs/kicad.mo'
error: file owned by 'kicad' and 'kicad-docs-bzr': 'usr/share/kicad/internat/de/kicad.mo'
...
This particular case is probably harmless, but I should much prefer to sweep it away somewhere.
Last edited by Llama (2018-03-11 07:02:31)
Offline
This is what using --force will get you. Don't do that.
You obviously have a conflict. The obvious answer is to get rid of the foreign -bzr package, but you'll have to reinstall kicad afterwards because of the previous use of --force.
Offline
I didn't use --force. The conflicting package does not look foreign. In all probability is comes with the kicad itself. I've got a strong suspicion that removing it is going to ruin my kicad installation.
Offline
It's not in the repos, so it's foreign.
The only way a file can be owned by two packages is with the use of --force.
Edit: And this is not the first time you've done this. https://bbs.archlinux.org/viewtopic.php?id=231245 Figure out what in your process is screwing things up so badly.
Last edited by Scimmia (2018-03-11 06:45:43)
Offline
$ yaourt -R kicad-docs-bzr
checking dependencies...
Packages (1) kicad-docs-bzr-352-2
Total Removed Size: 57.04 MiB
...
$ yaourt -S kicad
warning: kicad-4.0.7-4 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (1) kicad-4.0.7-4
Total Installed Size: 68.84 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] y
(1/1) checking keys in keyring [#######################################################] 100%
(1/1) checking package integrity [#######################################################] 100%
(1/1) loading package files [#######################################################] 100%
(1/1) checking for file conflicts [#######################################################] 100%
(1/1) checking available disk space [#######################################################] 100%
warning: could not get file information for usr/share/kicad/internat/ca/kicad.mo
warning: could not get file information for usr/share/kicad/internat/cs/kicad.mo
warning: could not get file information for usr/share/kicad/internat/de/kicad.mo
warning: could not get file information for usr/share/kicad/internat/es/kicad.mo
warning: could not get file information for usr/share/kicad/internat/fi/kicad.mo
...
Is it better?
Offline
Not a Pacman issue, moving to AUR Issues...
Offline
Again: I don't use --force.
Offline
$ yaourt -Rscn kicad
...
$ sudo rm -rf /usr/share/kicad/
...
$ yaourt -S kicad
No errors/warnings now. The trouble is probably a leftover of an attempt at kicad years ago when it resided in AUR.
Offline
As a start don't use aur helpers, they do all kinds of nonsense and seem to cause more trouble than they help.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
There's a lot of unavoidable things better left alone, this side of eternity.
Offline
--force is entirely avoidable.
Don't bother saying you don't use it. The evidence says that you do.
Offline
Why are you so concerned about it? It's entirely possible that I used --force once or twice years ago following some troubleshooting procedure, that's all. Besides, the nature of my present trouble is pretty clear by now; there are ways to catch it without the use of --force .
Offline
Besides, the nature of my present trouble is pretty clear by now; there are ways to catch it without the use of --force .
That's something we all would like to see you prove.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Why are you so concerned about it?
I can assure you, no one here would mind in the slightest if you used --force for every pacman transaction, or did any other silly thing your heart desired, so long as you didn't keep coming back here for help.
But as long as you want help from this community, you are going to need to follow the best practices set out by this community. It's really a simple equation: don't ask for advice from those from whom you will not accept advice.
Last edited by Trilby (2018-03-11 23:20:23)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Why are you so concerned about it? It's entirely possible that I used --force once or twice years ago following some troubleshooting procedure, that's all. Besides, the nature of my present trouble is pretty clear by now; there are ways to catch it without the use of --force .
If you can actually demonstrate a way that pacman can have two installed packages which own the same file, without using --force to install one of those packages (and without doing surgery on the package database with a text editor, because that is cheating), please report a pacman bug, because this is supposed to be impossible.
(If you cannot demonstrate a way, which I think is the more likely outcome, then please stop abusing the good faith of the forum moderators. Or keep on the way you are going, which is in the direction of the legions of the banned.)
Last edited by eschwartz (2018-03-11 23:58:22)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
That's easy enough:
pacman -S pkg1
rm /conflicting/file
pacman -S pkg2
Offline
Huh, I thought pacman checked the database for that, seriously?
(Granted the spirit of the objection remains, manipulating the filesystem outside pacman is not something you should be doing...)
Last edited by eschwartz (2018-03-12 00:13:36)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
If you don't like the rm, use NoExtract to prevent the initial extraction, same effect.
Offline
Granted manually deleting files can lead to the problem described, but manually deleting files tracked by pacman is a bad idea to say the least, don't mess with the filesystem if you don't know what you are doing.
If you do mess with the filesystem then accept the consequences and deal with the ensuing breakage yourself.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
(If you cannot demonstrate a way, which I think is the more likely outcome, then please stop abusing the good faith of the forum moderators. Or keep on the way you are going, which is in the direction of the legions of the banned.)
I never dreamed of starting the abuse thing, honestly. As to the case in hand. I am not pacman expert enough to file a bug report, if there is a bug. The sequence of events which led to this post, as perceived by my humble self:
1. error: file owned by 'kicad' and 'kicad-docs-bzr': 'usr/share/kicad/internat/ca/kicad.mo', immediately after kicad installation;
2. Discovery that kicad-docs-bzr package does not exist any longer; assuming that the kicad-docs-bzr package is a leftower of kicad installation back when kicad existed in the AUR, I uninstalled kicad-docs-bzr and reinstalled kicad; got some warnings like this: warning: could not get file information for usr/share/kicad/internat/ca/kicad.mo.
3. Uninstalled everything (kicad, that is), rm -rf /usr/share/kicad; reinstalled kicad.
4. That's all. I am not good enough to tell whether this is a bug, or just a highly unlikely unfortunate coincidence. This is no every day routine, that's all I can tell.
UPD:
Prior to (1), I was totally unaware of ever trying kicad some time in the past; can't remember anything.
Last edited by Llama (2018-03-12 20:32:15)
Offline
warning: could not get file information for usr/share/kicad/internat/ca/kicad.mo
How do you get this? Your system is missing files that the package manager thinks is installed, did you delete them by hand or use NoExtract which is rather advanced usage? Are these files that were provided by kicad-docs-bzr? This still doesn't explain how you got the two packages installed at the same time anyways -- if you were using NoExtract or removing files by hand, then that should only have been done once you understood the consequences.
(I still do not think this is valid usage of pacman in order to end up in this situation, but I'm not positive pacman should be responsible to check for this though.)
...
Did you use something like Bleachbit or localepurge? If that docs package only conflicted over locale data this might cause the issue I guess.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
No. No NoExtract, no Bleachbit, no localepurge. Just yaourt -S kicad. Nothing else whatever.
Offline
warning: could not get file information for usr/share/kicad/internat/ca/kicad.mo
How do you get this?
Maybe rm -rf /usr/share/kicad after uninstall of thoroughly orphaned kicad-docs-bzr. Then reinstall kicad.
Offline
rm -rf /usr/share/kicad
That's what broke things, you should let pacman handle this by uninstalling the package.
Offline
I'm pretty sure Llama did the rm -rf command only during the course of this thread. So regardless of whether or not it was wise, it did not cause the problems that led to this thread. I'm less optimistic though about the use of yaourt. I'd say god only knows what yaourt does - except that if he exists, I'm pretty sure he has enough sense to stay far clear of yaourt.
Whatever actually caused the problems that led to this thread may have been equally foolish, but it happened in the past. Short of inventing time travel, we are not going to identify what exactly the cause was regardless of how much we try to brow-beat Llama for suspected indescretions. So there's little point.
That said, Llama, you've been using arch for quite a while and you've come to these forums with several problems that suggest you've never really absorbed how to use your package manager or maintain your system following the general best practices advised by this community. It's time you step up and learn more about your OS and take better care of it.
Last edited by Trilby (2018-03-12 21:29:49)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline