Separating Garuda packages from Chaotic-AUR

Hey everyone!

We recently performed a long planned change to our repository structure - the separation of our Garuda exclusive packages from Chaotic-AUR and the addition of a garuda repo in front of Arch ones. The reasoning behind this is simple:

  • it allows overlaying packages like latte-dock, which means that we are able to eventually fix packages that aren't under our direct control (managed by Arch)
  • Chaotic-AUR becomes less focused on Garuda (which it was before as our packages were contained here) and hopefully becomes more attractive for other Arch based distributions

What does it mean for our fellow users? Apart from having 2 repos available after running garuda-update (yes, you should run this as it adds the repo!), no further changes will be noticable as the existing infrastructure (including mirrors) will be reused. Although, latte-dock will be fixed for KDE users as we provide a version fixed to a specific git commit that contains needed fixes for Plasma 5.25 :wink:

Be well and stay safe :wave:

37 Likes

8 posts were split to a new topic: Misc suggestions

This is an announcement thread. Please keep the posts on the topic of the announcement.

7 Likes

This is a pretty big announcement and I'd like to know more about it, like which will be the main 'movers' in the garuda repo? And most of all what's the ultimate goal of this? Stability, improvements, cutting edge aesthetics and themes, new and unique features...? I'm fairly new around here so I don't really know what's driving people towards Garuda but imho stability is the most important thing.

The goals are pretty clearly stated in the bulleted list of the first post but I will state them a little bit differently in hope that it will be more clear.

First, pacman processes repos in the order they are listed in /etc/pacman.conf. Chaotic-AUR is a huge repo and most people wouldn’t want it to override the packages which are coming from the official Arch repos so it is below the Arch repos on the list. However, on rare occasions, there is need to override a package coming from the Arch repos. Having a small repo which sits at the top of the list allows for this functionality.

In theory this should improve stability and reliability by giving the team an additional option to work around upstream issues.

The second reason is that Chaotic-AUR isn’t a Garuda-only project. Removing the handful of truly Garuda-specific packages from it, potentially opens the doors for it to be used by more distributions.

All the packages with “garuda” in the package name.

15 Likes

Hmm. Could I know what the mirrorlist of the garuda repo should be named?

For some reason, after update (2 days ago and I updated again today after reading this announcement), the list of repos in my /etc/pacman.conf file looks like this (see below). As you can see, both the [garuda] and [chaotic-aur] repos point to /etc/pacman.d/chaotic-mirrorlist.

My /etc/pacman.conf.pacnew file is older (from 10 May 2022) and doesn't contain the garuda repo or chaotic-aur lines. There is no mirrorlist for garuda in /etc/pacman.d/

Looks like I have to edit the pacman.conf file manually. And where can I find a copy of the garuda mirrorlist?

# Repository entries are of the format:
#       [repo-name]
#       Server = ServerName
#       Include = IncludePath
#
# The header [repo-name] is crucial - it must be present and
# uncommented to enable the repo.
#

# The testing repositories are disabled by default. To enable, uncomment the
# repo name header and Include lines. You can add preferred servers immediately
# after the header, and they will be used before the default mirrors.

#[testing]
#Include = /etc/pacman.d/mirrorlist

[garuda]
Include = /etc/pacman.d/chaotic-mirrorlist

[core]
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/mirrorlist

#[community-testing]
#Include = /etc/pacman.d/mirrorlist

[community]
Include = /etc/pacman.d/mirrorlist

# If you want to run 32 bit applications on your x86_64 system,
# enable the multilib repositories as required here.

#[multilib-testing]
#Include = /etc/pacman.d/mirrorlist

[multilib]
Include = /etc/pacman.d/mirrorlist

# An example of a custom package repository.  See the pacman manpage for
# tips on creating your own repositories.
#[custom]
#SigLevel = Optional TrustAll
#Server = file:///home/custompkgs

[chaotic-aur]
#SigLevel = Never
Include = /etc/pacman.d/chaotic-mirrorlist


PS. This is my old KDE-Lite test VM installed from a few years ago, to keep up with Garuda happenings. I don't do much with it, but want to keep it going.

System:
  Kernel: 5.18.7-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen root=UUID=9bdcaf45-9ee7-4db9-bef6-454217ce98c8
    rw rootflags=subvol=@ quiet splash loglevel=3
  Desktop: KDE Plasma v: 5.25.2 tk: Qt v: 5.15.5 wm: kwin_x11 vt: 1 dm: SDDM
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Virtualbox System: innotek GmbH product: VirtualBox v: 1.2 serial: <superuser required>
    Chassis: Oracle Corporation type: 1 serial: <superuser required>
  Mobo: Oracle model: VirtualBox v: 1.2 serial: <superuser required> BIOS: innotek GmbH
    v: VirtualBox date: 12/01/2006
Battery:
  ID-1: BAT0 charge: 50.0 Wh (100.0%) condition: 50.0/50.0 Wh (100.0%) volts: 10.0 min: 10.0
    model: innotek 1 type: Unknown serial: N/A status: full
CPU:
  Info: model: Intel Core i7-8550U bits: 64 type: MCP arch: Coffee Lake gen: core 8 built: 2017
    process: Intel 14nm family: 6 model-id: 0x8E (142) stepping: 0xA (10) microcode: N/A
  Topology: cpus: 1x cores: 2 smt: <unsupported> cache: L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB
    L2: 512 KiB desc: 2x256 KiB L3: 16 MiB desc: 2x8 MiB
  Speed (MHz): avg: 1992 min/max: N/A cores: 1: 1992 2: 1992 bogomips: 7968
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX unsupported
  Type: l1tf mitigation: PTE Inversion
  Type: mds mitigation: Clear CPU buffers; SMT Host state unknown
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data mitigation: Clear CPU buffers; SMT Host state unknown
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines, STIBP: disabled, RSB filling
  Type: srbds status: Unknown: Dependent on hypervisor status
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: VMware SVGA II Adapter driver: vmwgfx v: 2.20.0.0 ports: active: Virtual-1
    empty: Virtual-2, Virtual-3, Virtual-4, Virtual-5, Virtual-6, Virtual-7, Virtual-8
    bus-ID: 00:02.0 chip-ID: 15ad:0405 class-ID: 0300
  Display: x11 server: X.Org v: 21.1.3 with: Xwayland v: 22.1.2 compositor: kwin_x11 driver: X:
    loaded: vmware unloaded: modesetting alternate: fbdev,vesa gpu: vmwgfx display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1770x924 s-dpi: 96 s-size: 468x244mm (18.43x9.61") s-diag: 528mm (20.78")
  Monitor-1: Virtual-1 mapped: Virtual1 res: 1770x924 hz: 60 size: N/A modes: max: 1770x924
    min: 640x480
  OpenGL: renderer: SVGA3D; build: RELEASE; LLVM; v: 2.1 Mesa 22.1.2 direct render: Yes
Audio:
  Device-1: Intel 82801AA AC97 Audio vendor: Dell driver: snd_intel8x0 v: kernel bus-ID: 00:05.0
    chip-ID: 8086:2415 class-ID: 0401
  Sound Server-1: ALSA v: k5.18.7-zen1-1-zen running: yes
  Sound Server-2: JACK v: 1.9.21 running: no
  Sound Server-3: PulseAudio v: 16.1 running: yes
  Sound Server-4: PipeWire v: 0.3.52 running: no
Network:
  Device-1: Intel 82540EM Gigabit Ethernet driver: e1000 v: kernel port: d020 bus-ID: 00:03.0
    chip-ID: 8086:100e class-ID: 0200
  IF: enp0s3 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Device-2: Intel 82371AB/EB/MB PIIX4 ACPI type: network bridge driver: piix4_smbus v: N/A
    modules: i2c_piix4 port: N/A bus-ID: 00:07.0 chip-ID: 8086:7113 class-ID: 0680
Drives:
  Local Storage: total: 31.39 GiB used: 21.45 GiB (68.3%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 vendor: VirtualBox model: VBOX HARDDISK size: 31.39 GiB
    block-size: physical: 512 B logical: 512 B speed: 3.0 Gb/s type: N/A serial: <filter> rev: 1.0
    scheme: MBR
Partition:
  ID-1: / raw-size: 31.38 GiB size: 31.38 GiB (100.00%) used: 21.45 GiB (68.4%) fs: btrfs
    dev: /dev/sda1 maj-min: 8:1
  ID-2: /home raw-size: 31.38 GiB size: 31.38 GiB (100.00%) used: 21.45 GiB (68.4%) fs: btrfs
    dev: /dev/sda1 maj-min: 8:1
  ID-3: /var/log raw-size: 31.38 GiB size: 31.38 GiB (100.00%) used: 21.45 GiB (68.4%) fs: btrfs
    dev: /dev/sda1 maj-min: 8:1
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 4.29 GiB used: 1.2 MiB (0.0%) priority: 100 dev: /dev/zram0
Sensors:
  Message: No sensor data found. Is lm-sensors configured?
Info:
  Processes: 189 Uptime: 46m wakeups: 307 Memory: 4.29 GiB used: 1.54 GiB (35.9%) Init: systemd
  v: 251 default: graphical tool: systemctl Compilers: gcc: 12.1.0 Packages: pacman: 1345 lib: 314
  Client: shell wrapper v: 5.1.16-release inxi: 3.3.19
Garuda (2.6.4-2):
  System install date:     2020-10-20
  Last full system update: 2022-07-01 ↻
  Is partially upgraded:   No
  Relevant software:       NetworkManager
  Windows dual boot:       <superuser required>
  Snapshots:               Timeshift
  Failed units:            bluetooth-autoconnect.service 
1 Like

This is correct. See:

4 Likes

Ah so! Thanks.

You have to save this thread for posterity this is a big change that will then be remembered in your time route.
Ever since I saw the Garuda distribution, I was struck because it had its repository for specialized garuda programs, but you are right, the repository is so large that many distributions or users add it to their Arch-based Arch or Distribution.

Garuda is constantly changing and needed its own repository for its preconfigured packages to distribute it

4 Likes

I don’t understand this part. How Garuda packages are supposed to affect other distros? If they want Chaotic AUR, they could do so without installing Garuda packages because they are already not needed for them.

Because not everyone is careful and people have installed garuda packages on other distros without understanding what they do. Some of those packages do fairly intrusive things(If used outside of Garuda) like making the system identify itself as Garuda.

Having those packages in the repo may be limiting other distros willingness to ship it by default.

7 Likes

In fact, we got Chaotic-AUR removed from Arch wiki's custom repository list for that reason. Some guy installed a Garuda package (clearly labeled as such by having the garuda- prefix), it pulled in garuda-hooks and changed his Arch installation to a Garuda one, which eventually led to the removal. Removing all of those packages to make sure something like this happens again (even though one could've assumed such an action by a clearly distribution-specific package) should help with the adoption.

Edit: Unofficial user repositories - ArchWiki :partying_face:

9 Likes