You are not logged in.
To make it short, pacman really can't find steam.
Options I tried:
pacman -S steam
pacman -Sy steam
pacman -Syyu steam
pacman -Ss steam
And still got nothing.
Here's my last attempt at it:
$ sudo pacman -Syyu steam
:: Synchronizing package databases...
core 112.7 KiB 49.9K/s 00:02 [######################] 100%
extra 1763.0 KiB 30.5K/s 00:58 [######################] 100%
community 2.3 MiB 74.2K/s 00:31 [######################] 100%
error: target not found: steam
Notes: I'm running arch on a VBox. Sorry if I sound cocky or anything but maybe it's my lack of sleep over this particular problem. Yes, I uncommented the multilib repo in pacman.conf.
Anyone got any ideas?
Last edited by Jackoz530 (2014-08-11 14:20:02)
"I find myself strangely drawn to this odd configuration of activity..."
-Puck(and possibly my whole life)
Offline
https://wiki.archlinux.org/index.php/Pa … t_found.22
EDIT: In the future, please use code tags when posting terminal output.
Last edited by ANOKNUSA (2014-08-10 17:36:52)
Offline
Maybe you have failed to uncomment the multilib repo properly, as your output doesn't show its synchronizing.
Offline
Post your pacman.conf.
Offline
Maybe you have failed to uncomment the multilib repo properly, as your output doesn't show its synchronizing.
This worked for me. Found steam in the multilib repo when I properly uncommented the repo.
Though it's weird that steam can't be found in the community repo, only in the multilib repo.
$ pacman -Ss steam
multilib/steam 1.0.0.48-1
Digital distribution client bootstrap packagePacman.conf is as follows:
#
# /etc/pacman.conf
#
# See the pacman.conf(5) manpage for option and repository directives
#
# GENERAL OPTIONS
#
[options]
# The following paths are commented out with their default values listed.
# If you wish to use different paths, uncomment and update the paths.
#RootDir = /
#DBPath = /var/lib/pacman/
#CacheDir = /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
#GPGDir = /etc/pacman.d/gnupg/
HoldPkg = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta = 0.7
Architecture = auto
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
#IgnorePkg =
#IgnoreGroup =
#NoUpgrade =
#NoExtract =
# Misc options
#UseSyslog
#Color
#TotalDownload
CheckSpace
#VerbosePkgLists
# By default, pacman accepts packages signed by keys that its local keyring
# trusts (see pacman-key and its man page), as well as unsigned packages.
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional
#RemoteFileSigLevel = Required
# NOTE: You must run `pacman-key --init` before first using pacman; the local
# keyring can then be populated with the keys of all official Arch Linux
# packagers with `pacman-key --populate archlinux`.
#
# REPOSITORIES
# - can be defined here or included from another file
# - pacman will search repositories in the order defined here
# - local/custom mirrors can be added here or in separate files
# - repositories listed first will take precedence when packages
# have identical names, regardless of version number
# - URLs will have $repo replaced by the name of the current repo
# - URLs will have $arch replaced by the name of the architecture
#
# 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
[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/custompkgsI'm currently grabbing the steam in the multilib repo and gonna test it once I finished grabbing it.
"I find myself strangely drawn to this odd configuration of activity..."
-Puck(and possibly my whole life)
Offline
Though it's weird that steam can't be found in the community repo, only in the multilib repo.
Steam is a 32-bit application.
I'm currently grabbing the steam in the multilib repo and gonna test it once I finished grabbing it.
What are you hoping to test?
Offline
Though it's weird that steam can't be found in the community repo, only in the multilib repo.
Steam is a 32-bit application.
According to this, Steam can be found in the community repo, or I think it should.
Search steam here
I'm currently grabbing the steam in the multilib repo and gonna test it once I finished grabbing it.
What are you hoping to test?
The probabilty of this one not working
Last edited by Jackoz530 (2014-08-11 00:21:04)
"I find myself strangely drawn to this odd configuration of activity..."
-Puck(and possibly my whole life)
Offline
Jackoz530, there are two results for steam in the search page you linked to.
i686 Community steam 1.0.0.48-1 Digital distribution client bootstrap package 2014-08-03
x86_64 Multilib steam 1.0.0.48-1 Digital distribution client bootstrap package 2014-08-03The first one is for i386 i686 systems, if you have x86_64, you need multilib.
(edit: typo)
Last edited by Trilby (2014-08-11 01:31:43)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Jackoz530, there are two results for steam in the search page you linked to.
i686 Community steam 1.0.0.48-1 Digital distribution client bootstrap package 2014-08-03 x86_64 Multilib steam 1.0.0.48-1 Digital distribution client bootstrap package 2014-08-03The first one is for i386 systems, if you have x86_64, you need multilib.
I'm just wondering why pacman cant find steam in my community repo. only in the multilib repo
"I find myself strangely drawn to this odd configuration of activity..."
-Puck(and possibly my whole life)
Offline
I'm just wondering why pacman cant find steam in my community repo. only in the multilib repo
Unless you're running a 32-bit system, you'll find Steam in the repository dedicated to 32-bit applications.
The probabilty of this one not working
What do you mean "this one?" I'm curious about what all this is for because you're installing the Steam gaming client inside a virtual machine, so game performance is gonna be seriously limited (emulated 3D hardware accelleration, slower filesystem, limited CPU cycles and RAM).
Offline
I'm just wondering why pacman cant find steam in my community repo. only in the multilib repo
Check out the directory structure of one of the mirror sites some time. Each repo has a subfolder for i686 and another subfolder for x86_64. There are duplicate packages in each subdirectory except they are compiled for the different architectures. Firefox for example is in <mirror-base>/extra/i686/firefox-ver-rel-i686.pkg.tar.gz and <mirror-base>/extra/x86_64/firefox-ver-rel-x86_64.pkg.tar.gz. Each system will only use on or the other of those. Other packages, like skype and steam, cannot be compiled for x86_64, so there is only a <mirror-base>/community/i686/steam-ver-rel-i686.pkg.tar.gz. There is not steam-ver-rel-x86_64.pkg.tar.gz in the other subdirectory of the community repo - because that package could never be compiled. Instead, for x86_64 users, a 32 bit version of steam that can run on their 64 bit system is placed in <mirror-base>/multilib.
For a clearer example, look up firefox in that search page. You'll see two entries for firefox in the extra repo: one for i686, the other for x86_64. But pacman will not show you both of those - pacman only sees the packages for your systems architecture. You can also see this in pacman.conf and/or your mirrorlist: the urls to the mirrors use the "$arch" variable for architecture.
Last edited by Trilby (2014-08-11 01:38:56)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I wonder why multilib is disabled by default. Anyone who wants a "pure 64-bit system" will know enough to disable it, and anyone who doesn't will need to enable it. What's the point of the extra step for the average user? Why would anyone want a "pure 64-bit system," anyway?
Offline
I wonder why multilib is disabled by default. Anyone who wants a "pure 64-bit system" will know enough to disable it, and anyone who doesn't will need to enable it. What's the point of the extra step for the average user? Why would anyone want a "pure 64-bit system," anyway?
https://wiki.archlinux.org/index.php/The_Arch_Way
Is multilib repository necessary to run the system under a x86_64 architecture? No. That answer should be sufficient.
Why do you think, you know every single application/implementation for/of [arch] linux? That would be the preliminary assumption for your questions. You are limited by your own experience, as is every single one of us, acknowledge that. Would you really go the risk of using additional subsystems by default in a crucial process? Why? Do you know exactly how many people are using a 'pure 64-bit system' in comparison to a 'mixed system'? How? Those are only a few points. Your questions are more suited for one of the discussion subforums.
The average arch user should know what he wants and how to accomplish it. Should that not be the case, he will know where to look for guidance or answers. I doubt that the average arch user does play steam games, and even if that were the case [according to statistical data -- pkgstats and additional sources], any changes to the default system only to accommodate that fact would violate 'the arch way'.
Offline
What do you mean "this one?" I'm curious about what all this is for because you're installing the Steam gaming client inside a virtual machine, so game performance is gonna be seriously limited (emulated 3D hardware accelleration, slower filesystem, limited CPU cycles and RAM).
I'm just regularly installing Steam and just curious on why Steam can't be found when I searched the community repo. In short, I can't find the i686 version.
Check out the directory structure of one of the mirror sites some time. Each repo has a subfolder for i686 and another subfolder for x86_64. There are duplicate packages in each subdirectory except they are compiled for the different architectures. Firefox for example is in <mirror-base>/extra/i686/firefox-ver-rel-i686.pkg.tar.gz and <mirror-base>/extra/x86_64/firefox-ver-rel-x86_64.pkg.tar.gz. Each system will only use on or the other of those. Other packages, like skype and steam, cannot be compiled for x86_64, so there is only a <mirror-base>/community/i686/steam-ver-rel-i686.pkg.tar.gz. There is not steam-ver-rel-x86_64.pkg.tar.gz in the other subdirectory of the community repo - because that package could never be compiled. Instead, for x86_64 users, a 32 bit version of steam that can run on their 64 bit system is placed in <mirror-base>/multilib.
For a clearer example, look up firefox in that search page. You'll see two entries for firefox in the extra repo: one for i686, the other for x86_64. But pacman will not show you both of those - pacman only sees the packages for your systems architecture. You can also see this in pacman.conf and/or your mirrorlist: the urls to the mirrors use the "$arch" variable for architecture.
And this is what answered my question. Marking this solved. Thanks for the info.
"I find myself strangely drawn to this odd configuration of activity..."
-Puck(and possibly my whole life)
Offline
Anyone who wants a "pure 64-bit system" will know enough to disable it, and anyone who doesn't will need to enable it ... Why would anyone want a "pure 64-bit system," anyway?
You've got that backwards. A breakdown of some of what the [multilib] repo contains:
- Steam (games)
- Dwarf Fortress (game)
- PCSX2 (Playstation 2 emulator---games)
- WINE (for running 32-bit Windows applications---like, uh, games)
- A bunch of stuff needed to develop 32-bit applications, such as for Windows or Android
So it's not a matter of "wanting" a purely 64-bit system---most users are likely to simply have one anyway. The [multilib] repo is, for a great many users, simply superfluous. If you want something from that repository, the wiki will tell you how to get it.
I suspect the hang-up here is that users who come from distros like Debian expect to simply be able to search for any package they can imagine and see a list of 500 results. That's just not how the Arch devs do things.
Last edited by ANOKNUSA (2014-08-11 14:18:28)
Offline
https://www.archlinux.org/packages/?name=steam
Look at the architecture of the community and multilib versions. If you're using 64-bit Arch, pacman won't search the 32-bit repos and won't show 32-bit packages and vice versa. I think you can force architecture in pacman.conf by setting it to e.g. 'i686' instead of 'auto'. Doing this will download sync dbs for 32-bit Arch.
Last edited by karol (2014-08-12 00:59:46)
Offline
So it's not a matter of "wanting" a purely 64-bit system---most users are likely to simply have one anyway. The [multilib] repo is, for a great many users, simply superfluous. If you want something from that repository, the wiki will tell you how to get it.
As far as I can tell, only downside to having multilib enabled is it downloads a 122KiB file when you do an upgrade. Why not just have it on by default? It's not like it will install anything from there unless you ask it to.
Offline
ANOKNUSA wrote:So it's not a matter of "wanting" a purely 64-bit system---most users are likely to simply have one anyway. The [multilib] repo is, for a great many users, simply superfluous. If you want something from that repository, the wiki will tell you how to get it.
As far as I can tell, only downside to having multilib enabled is it downloads a 122KiB file when you do an upgrade.
Package searches.
Why not just have it on by default? It's not like it will install anything from there unless you ask it to.
You could say the same for [testing].
Offline