You are not logged in.
Hello,
Years ago I did a mistake, I tried switching to blackarch to avoid compiling many tools from zero , then I got back to default arch because it was too unstable.
The problem is that I installed packages from that repo which are not available on archlinux repos, so I feel pretty confident that some tools have not been updated ever since.
So, here comes the question:
How could I get a list of the installed packages which are not available on upstream mirrors?
Last edited by Foxhole (2021-09-07 12:07:23)
Offline
pacman -QmThis will list all packages not currently in your configured mirrors, including anything you have installed from the AUR.
Offline
I suppose there is no way to distinguish them from AUR packages, cause they are both foreign. Marking this as solved, thank you!
To fix my system, I adapted the "reinstall everything" script with this
for pkg in $(pacman -Qm | cut -d' ' -f1); do
your_aur_helper -S $pkg
doneBy paying attention to unavailable packages on AUR
Last edited by Foxhole (2021-09-07 12:12:52)
Offline
You can just diff it against the list of all packages in the AUR.
https://aur.archlinux.org/packages.gz
pacman -Qm | cut -d' ' -f1
Can be replaced with...
pacman -QmqLast edited by Slithery (2021-09-07 12:13:27)
Offline
This is even better! Thank you!
Offline
Can be replaced with...
pacman -Qmq
I had ended up with
diff --changed-group-format='%<' --unchanged-group-format='' <(sort <(pacman -Qmq)) <(sort aur_pkgs.txt) where aur_pkgs.txt is the extracted content of https://aur.archlinux.org/packages.gz.
I got quite surprised there where not the packages I would have expected, due to the fact that the blackarch repo kept the same AUR packages name. I ended up with
for pkg in $(pacman -Qmq); do
your_aur_helper -S --noconfirm $pkg
doneThank you again for your help
Last edited by Foxhole (2021-09-07 12:51:18)
Offline
If you are using an AUR helper that would install a package that way, I'm pretty sure it would also update them without needing to explicitly list them with another flag (e.g., seveal "full featured" aur helpers would use flags like -Syua).
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
several "full featured" aur helpers would use flags like -Syua
Thank you, I just realized that the proper solution was to use
for pkg in $(pacman -Qgq blackarch); do
trizen -Syua --noconfirm $pkg
doneDue to the fact that those packages had a group (blackarch) and now they have an equivalent on the AUR repo. Sorry abut the fuss and thank you all for the help.
Offline
Ah, no, you missed the point, `trizen -Syua` would have been sufficient.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Ah, no, you missed the point, `trizen -Syua` would have been sufficient.
I had always did that to update AUR packages, and those blackarch packages didn't got updated for years (because they were not recognized as aur packages maybe? I don't know honestly).
After doing the command I wrote before, the packages I had installed when using blackarch repos had been replaced with the aur ones and those packages dropped the blackarch group attribute, now they are recognized by trizen as proper AUR packages.
Last edited by Foxhole (2021-09-07 14:58:07)
Offline
One more thing, currently you're running those commands one-by-one, that's rather slow...
<helper> -Syua --noconfirm foo
<helper> -Syua --noconfirm bar
<helper> -Syua --noconfirm bazBesides Trilby's point that you don't even need to list those AURs packages separately, you also don't need a for loop. Just do:
<helper> -Syua --noconfirm foo bar baz...which for your example would be
<helper> -Syua --noconfirm $(pacman -Qgq blackarch | paste -sd '')The only scenario I can think of where a for loop would be reasonable is if you were running `makepkg` one-by-one.
Offline
...which for your example would be
<helper> -Syua --noconfirm $(pacman -Qgq blackarch | paste -sd '')The only scenario I can think of where a for loop would be reasonable is if you were running `makepkg` one-by-one.
That's a good point, I hadn't thought about it. At least I got lucky that there were a few packages only.
Offline
I had always did that to update AUR packages, and those blackarch packages didn't got updated for years (because they were not recognized as aur packages maybe? I don't know honestly).
They weren't updated by trizen as long as your had the blackackarch repo listed in your pacman.conf. But as soon as that was removed, a trizen update would have (tried to) update them too. Once installed on your system, there is no such thing as an "aur package". What Trizen and other aur helpers do is get the output from pacman -Qm (some directly, some via the equivalent function in libalpm) and then try to update each of these non-repo packages from the AUR.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline