Arch linux source code

How to download source code with Pacman on Arch Linux? [closed]

I am using Arch Linux. I want to do the same thing like apt-get source coreutils ; is it possible to download sources with Pacman? I didn’t find a solution in the man pages. How can I get the source code of a package?

3 Answers 3

1. pacman -S asp
2. say if you want the source code of the Linux command find
   1. find out which package the command find belongs to: pacman -Qo $(which find) . The result is «/usr/bin/find is owned by findutils 4.4.2-3».

   Now you have your source code.

   If you just want one package, you can do something like abs core/wpa_supplicant , where you prepend the package repository. You can also use ABSROOT=/tmp/ abs core/wpa_supplicant if you don’t want to use sudo .

   Thanks for the tip on not being sudo to download a package (which is possible with apt-get source). By the way in step 5.1 if you are looking for find just type pacman -Qo find . I personnally prefer to use pkgfile find . Just try it.

   You could use makepkg -o to only download and patch the source, instead of building the while package!

   FYI, In my case, I tried to downalod python source, but I got Missing dependencies when makepkg -o . Use makepkg -o -i to skip dependency checking.

   2018 Update:

   The abs tool described below has been deprecated and it along with its rsync endpoint have been dropped since mid 2017.

   The asp tool now provides similar functionality. More information here.

   As already mentioned you can use the ABS (Arch Build System):

   sudo pacman -S base-devel abs 

   First, download the ABS tree:

   Then, get a specific package:

   Then copy the package, whose source you want to have, from the local abs tree (e.g. /var/abs/core/findutils ) to another directory, e.g. /home/blabla/abs

   • if you only want to get the sources and don’t want to build the package you can run makepkg -od
   • otherwise run makepkg -s , which will then handle all the package’s dependencies automatically
   • watch out becaouse makepkg will overwrite your modifications, use makepkg -e to build your local sources instead

   If you want to install the package you’ve built, run

   makepkg -i will install the package as well; it’s also possible to use makepkg -ei to compile whatever is in src and install the ensuing package in one take

   Edit: This answer is outdated due to changes on ABS.

   You get the package sources from the Arch Linux SVN repository, called ABS.

   Then, on the package details page, on the right side use the SVN links, e.g.: http://repos.archlinux.org/wsvn/packages/coreutils/trunk/

   It is a little bit more complicated than apt-get source . But perhaps you find a tool on AUR that does the job for you, for example yaourt supports building from sources and exporting them.

   Источник

   Saved searches

   Use saved searches to filter your results more quickly

   You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

   Official Arch Linux Infrastructure Repository (read-only mirror)

   License

   archlinux/infrastructure

   This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

   Name already in use

   A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

   Sign In Required

   Please sign in to use Codespaces.

   Launching GitHub Desktop

   If nothing happens, download GitHub Desktop and try again.

   Launching GitHub Desktop

   If nothing happens, download GitHub Desktop and try again.

   Launching Xcode

   If nothing happens, download Xcode and try again.

   Launching Visual Studio Code

   Your codespace will open once ready.

   There was a problem preparing your codespace, please try again.

   Latest commit

   The HTTP code must be 2xx for probe_success to indicate that the probe succeeded, if not an alert will be sent. Fixes: 653f801 ("Add GitLab Pages for alpm-types[1]")

   Git stats

   Files

   Failed to load latest commit information.

   README.md

   This repository contains the complete collection of ansible playbooks and roles for the Arch Linux infrastructure.

   • terraform
   • python-click
   • python-jmespath
   • moreutils (for playbooks/tasks/reencrypt-vault-key.yml)

   All systems are set up the same way. For the first time setup in the Hetzner rescue system, run the provisioning script: ansible-playbook playbooks/tasks/install-arch.yml -l $host . The provisioning script configures a sane basic systemd with sshd. By design, it is NOT idempotent. After the provisioning script has run, it is safe to reboot.

   Once in the new system, run the regular playbook: HCLOUD_TOKEN=$(misc/get_key.py misc/vaults/vault_hetzner.yml hetzner_cloud_api_key) ansible-playbook playbooks/$hostname.yml . This playbook is the one regularity used for administrating the server and is entirely idempotent.

   When adding a new machine you should also deploy our SSH known_hosts file and update the SSH hostkeys file in this git repo. For this you can simply run the playbooks/tasks/sync-ssh-hostkeys.yml playbook and commit the changes it makes to this git repository. It will also deploy any new SSH host keys to all our machines.

   The root_access.yml file contains the vault_default_pgpkeys variable which determines the users that have access to the default vault, as well as the borg backup keys. A separate super vault exists for storing highly sensitive secrets like Hetzner credentials; access to the super vault is controlled by the vault_super_pgpkeys variable.

   All the keys should be on the local user gpg keyring and at minimum be locally signed with —lsign-key . This is necessary for running any of the reencrypt-vault-default-key , reencrypt-vault-super-key or fetch-borg-keys tasks.

   We use packer to build snapshots on hcloud to use as server base images. In order to use this, you need to install packer and then run

   packer build -var $(misc/get_key.py misc/vaults/vault_hetzner.yml hetzner_cloud_api_key --format env) packer/archlinux.json 

   This will take some time after which a new snapshot will have been created on the primary hcloud archlinux project.

   We use terraform in two ways:

   1. To provision a part of the infrastructure on hcloud (and possibly other service providers in the future)
   2. To declaratively configure applications

   For both of these, we have set up a separate terraform script. The reason for that is that sadly terraform can’t have providers depend on other providers so we can’t declaratively state that we want to configure software on a server which itself needs to be provisioned first. Therefore, we use a two-stage process. Generally speaking, scenario 1. is configured in tf-stage1 and 2. is in tf-stage2 . Maybe in the future, we can just have a single terraform script for everything but for the time being, this is what we’re stuck with.

   The very first time you run terraform on your system, you’ll have to init it:

   cd tf-stage1 # and also tf-stage2 terraform init -backend-config="conn_str=postgres://terraform:$(../misc/get_key.py ../group_vars/all/vault_terraform.yml vault_terraform_db_password)@state.archlinux.org?sslmode=verify-full" 

   After making changes to the infrastructure in tf-stage1/archlinux.tf , run

   This will show you planned changes between the current infrastructure and the desired infrastructure. You can then run

   to actually apply your changes.

   The same applies to changed application configuration in which case you’d run it inside of tf-stage2 instead of tf-stage1 .

   We store terraform state on a special server that is the only hcloud server NOT managed by terraform so that we do not run into a chicken-egg problem. The state server is assumed to just exist so in an unlikely case where we have to entirely redo this infrastructure, the state server would have to be manually set up.

   All hosts should be relaying email through our primary mx host (currently ‘mail.archlinux.org’). See docs/email.md for full details.

   Putting a service in maintenance mode

   Most web services with a nginx configuration, can be put into a maintenance mode, by running the playbook with a maintenance variable:

   ansible-playbook -e maintenance=true playbooks/

   This also works with a tag:

   ansible-playbook -t -e maintenance=true playbooks/

   As long as you pass the maintenance variable to the playbook run, the web service will stay in maintenance mode. As soon as you stop passing it on the command line and run the playbook again, the regular nginx configuration should resume and the service should accept requests by the end of the run.

   Passing maintenance=false, will also prevent the regular nginx configuration from resuming, but will not put the service into maintenance mode.

   Keep in mind that passing the maintenance variable to the whole playbook, without any tag, will make all the web services that have the maintenance mode in them, to be put in maintenance mode. Use tags to affect only the services you want.

   Documentation on how to add the maintenance mode to a web service is inside docs/maintenance.md.

   Finding servers requiring security updates

   Arch-audit can be used to find servers in need of updates for security issues.

   ansible all -a "arch-audit -u" 

   The following steps should be used to update our managed servers:

   Semi-automated server updates (experimental)

   For updating a lot of servers in a more unattended manner, the following playbook can be used:

   ansible-playbook playbooks/tasks/upgrade-servers.yml [-l SUBSET] 

   It runs pacman -Syu on the targeted hosts in batches and then reboots them. If any server fails to reboot successfully, the rolling update stops and further batches are cancelled. To display the packages updated on each host, you can pass the —diff option to ansible-playbook.

   Using this update method, .pacnew files are left unmerged which is OK for most configuration files that are managed by Ansible. However, care must be taken with updates that require manual intervention (e.g. major PostgreSQL releases).

   This section has been moved to docs/servers.md.

   Fetching the borg keys for local storage

   • Make sure you have all the GPG keys at least locally signed
   • Run the playbooks/tasks/fetch-borg-keys.yml playbook
   • Make sure the playbook runs successfully and check the keys under the borg-keys directory

   Re-encrypting the vaults after adding a new PGP key

   Changing the vault password on encrypted files

   We use BorgBackup for all of our backup needs. We have a primary backup storage as well as an additional offsite backup.

   See docs/backups.md for detailed backup information.

   Our Gitlab installation uses Omnibus to run Gitlab on Docker. Updating Gitlab is as simple as running the ansible gitlab playbook:

   ansible-playbook playbooks/gitlab.archlinux.org.yml --diff -t gitlab 

   To view the current Gitlab version visit this url

   A bunch of once-only admin task scripts can be found in one-shots/ . We try to minimize the amount of manual one-shot admin work we have to do but sometimes for some migrations it might be necessary to have such scripts.

   About

   Official Arch Linux Infrastructure Repository (read-only mirror)

   Источник

   Читайте также:  Пишем свой драйвер linux