@mobara If you decide to install yay from AUR (a good choice), then I’d suggest to install not yay but yay-bin package.
Both install exactly the same yay program, currently at version 9.2.0-1.
But yay package needs also go language compiler to compile yay program on your computer. So the compiler is also downloaded and kept in the system. It’s more than 200 M is size. If you aren’t a go programmer, you’ll hardly ever need it.
yay-bin package installs already compiled yay program. go compiler is not needed and is not installed. To install yay-bin package:
yaourt -S yay-bin
@just can you give us step by step guide of how to do that?..
It’s impossible to give detailed step-by-step instructions, suitable for all possible cases.
Main steps in gradual Antergos to Arch transition are simple. Attention and some skills are needed only when we’re about to take a decision about each single package to replace or remove.
- Remove Antergos meta-package from the DE
It acts as a glue, making all DE as a completely monolithic, non-editable in any way piece of software. Remove it without dependencies, otherwise pacman will remove all DE, Xorg, Wayland and whatsever. It means, use the -R command without any additional switch.
sudo pacman -R antergos-mate-meta sudo pacman -R antergos-cinnamon-meta sudo pacman -R antergos-gnome-meta sudo pacman -R antergos-kde-meta
- Move [antergos] repo to the lowest priority
It means, move it below all other repos in the /etc/pacman.conf file.
To take a look at your current repos order, run the command
sudo pacman -Syy
The command will update databases only, without upgrading anything. We’re interested in the collateral command’s effect - it lists repos in the order pacman “sees” them. Higher the repo in the list, higher its priority. Lower repo, lower priority. [antergos] repo has the highset priority below. It’s default Antergos setup.
You’ll probably see smth like this:
┌──[just]@[alexarc]:~$ └─> sudo pacman -Syy :: Synchronizing package databases... antergos 134.1 KiB 2002K/s 00:00 [------] 100% core 134.1 KiB 4.85M/s 00:00 [------] 100% extra 1661.2 KiB 6.76M/s 00:00 [------] 100% community 4.8 MiB 8.17M/s 00:01 [------] 100% multilib 173.0 KiB 9.94M/s 00:00 [------] 100% ┌──[just]@[alexarc]:~$ └─>
Edit /etc/pacman.conf, and move [antergos] below [multilib]. Save the file, and look at repos order again:
┌──[just]@[alexarc]:~$ └─> sudo pacman -Syy :: Synchronizing package databases... core 134.1 KiB 4.85M/s 00:00 [-------] 100% extra 1661.2 KiB 6.76M/s 00:00 [-------] 100% community 4.8 MiB 8.17M/s 00:01 [-------] 100% multilib 173.0 KiB 9.94M/s 00:00 [-------] 100% antergos 134.1 KiB 2002K/s 00:00 [-------] 100% ┌──[just]@[alexarc]:~$ └─>
[antergos] is at the lowest priority now.
Pacman reads the repos in that order. From highest priority to lowest.
- Upgade and downgrade packages
If a package with the same name is present in more than one repo, then pacman considers only the first one it finds - i.e., a package from a repo with the higher priority.
Pacman doesn’t consider the version of a package. It installs the first one found. If a package ABC is present in [antergos] with version 3.2.1, in [community] repo with version 1.2.3, and [community] has higher priority than [antergos], then pacman installs ABC from [community]: ABC-1.2.3.
Following this rule, pacman will replace all packages with the same name, originally installed from [antergos] repo, with their homonyms from [core], [extra], [community], [multilib] repos, in this order.
Some [antergos] pkgs may be upgrarded. Upgrades are safe. Do them.
But pacman may want to downgrade other packages. Pacman never downgrades anything without user’s permission. Look closely at all packages pacman wants to downgrade and, if it’s OK for you, allow downgrades with -uu switch:
Upgrades enabled, downgrades disabled:
sudo pacman -Syu
Both upgrades and downgrades are enabled:
sudo pacman -Syuu
- Uninstall Antergos-specific packages
These are packages, installed from the [antergos] repo.
Now that meta-package(s) are already removed, it is relatively simple to remove [antergos] packages one by one.
Why relatively? Because Arch is made by dependencies, not by packages. It’s extremely important to make a full, clean uninstall, removing all unneeded dependencies and at the same time preserving and not breaking those needed.
Two rules of thumb are:
a. The best cleanup (uninstall, removal) is done with the commnd:
sudo pacman -Rcnssu package-name
It removes a package, all package dependencies, configuartion files, everything somehow related to a package. It removes a whole lot of staff. The system remains clean after the removal.
b. The worst uninstall is done with the commnd:
sudo pacman -R package-name
It removes a package only but leaves intact its dependencies and configs. The system remains full of uneeded packages, files and broken dependencies after it.
This is not always true. Sometime it is needed to remove a package, and leave intact other packages, depending on it. An example is removal of meta-packages.
There’s no universal advice for all possible cases which may be encountered.
Start removing a package with -Rcnssu, but never confirm un-installation blindly. Never reply with yes. Take your hands off the keyboard. Read with much attention what pacman goes to do. Force yourself to always reply with no in these cases.
If it looks like pacman wants to remove too much staff, use a bit less rigid removal command:
sudo pacman -Rcnsu package-name
Pacman will probably want to remove less staff,
Neverthelss, don’t reply immediately with yes. Reply with no. Read what pacman says.
Gradually use less and less rigid commands:
sudo pacman -Rcnsu package-name sudo pacman -Rcns package-name sudo pacman -Rcn package-name sudo pacman -Rc package-name
Try various combinations of c, n, s, u switches. They are all explained in the pacman’s -R removal command help:
A final advice - never use graphical package managers, like octopi or pamac, for doing this job. Use pacman only in terminal. Read very carefully what it says before allowing it to proceed. In case of minimal doubt reply with no. It’s always safe.
If you ask me there is no need for any action to be taken right now,…
Excellent, totally agree.
As a precaution, the [antergos] repo may be moved to the lowest priority first. This way, native Arch packages will start to replace their Antergos counterparts, if any.
Once Arch packages have replaced Antergos ones, and Antergos-specific packages, without Arch counterparts, have been uninstalled by hand, it will be safe to completely remove [antergos] repo.
I did it this way. [antergos] repo is at the bottom of the list. Antergos continues to work perfectly. Though it’s more Arch than Antergos now.
Everything is explained in the pacman’s -R command help:
- c = cascading removal, removes a package along with all pkgs which depend on it, if any
- n = nosave, removes also all pkg configuration files, if any
- ss = enforced removal, removes unnecessary dependencies, including even dependencies installed by hand (explicitly installed), if any
- u = removes unneeded packages as well (garbage), if any
It takes about one or two hours to rebuild qt4.
qt4 became obsoleted a year or two ago. It has been even moved to AUR at that time. It is safe to uninstall it completely from all DEs:
sudo pacman -Rcnssu qt4
If none of installed packages depend on qt4, then the command will remove qt4 package only.
Otherwise, remove depending packages one by one, prior to removing qt4.
@Jeannie____ Hi Jeannie,
I had exactly the same issue you describe, in 13 independent Arch installations here. The sequence of commands below fixed the issue everywhere. Essentially, it repeats what was already suggested by @joekamprad.
systemctl status systemd-timesyncd systemctl stop systemd-timesyncd systemctl disable systemd-timesyncd sudo rm -rf '/var/lib/systemd/timesync' systemctl enable systemd-timesyncd systemctl start systemd-timesyncd systemctl status systemd-timesyncd
I don’t speak Spanish, so surely misunderstood the original question. I thought it was related to setting Numlock ON in Cinnamon session only, and not earlier, before an Xorg session startup.
There are two good ways to set Numlock ON before display manager or Xorkg start. Both are clearly described in ArchWiki (see above). They are:
- by creating a new systemd service
- by extending an existing or creating a new [email protected]
Both methods use setleds utility (installed by deffault) to control and set a desired keyboard modifiers state.
Etremely simplyfying, a startup sequence may be seen as:
- Multu-user.target (runlevel 3) is reached
- After that a display manager may be started
- After that DM starts an Xorg session
Both methods work when a system reaches multi-user.target. It means that Numlock (and other modifiers) will be set to desired state even before display manager or Xorg session start.
Both are easy to implement, though require some skills.
The easiest one to set it ON in Cinnamon is to add numlockx to startup applications:
Menu --> System Settings --> Startup Applications --> Add… Custom Command
and fill in the fields like follows:
You’ll see the newly added command among Cinnamon startup apps:
It will be automatically executedd on each Cinnamon session startup.