https://wiki.archlinux.org/api.php?action=feedcontributions&user=Rdahlgren&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:35:41ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Gapless_Audio_CD_Creation_from_MP3s&diff=438469Gapless Audio CD Creation from MP3s2016-06-18T20:02:23Z<p>Rdahlgren: /* Decode the MP3s */ Use idiomatic bash suffix replacement.</p>
<hr />
<div>[[Category:Multimedia]]<br />
[[zh-CN:Gapless Audio CD Creation from MP3s]]<br />
{{Merge|Optical_disc_drive#Burning_an_audio_CD}}<br />
<br />
==Introduction==<br />
Some albums are meant to be played without any silent gap between tracks -- especially live albums. Furthermore, when you copy a regular album that has gaps, the ripped audio files will actually include this gap at the end of each track -- to burn these tracks with a gap will actually increase the length of silence between tracks. Therefore, in almost all cases, you are better off burning all your CD backups gaplessly.<br />
<br />
Here's an easy way to burn a gapless audio CD from the shell using cdrdao.<br />
<br />
==Setup==<br />
[[Install]] the {{pkg|lame}} and {{pkg|cdrdao}} packages.<br />
<br />
Optional: Let's configure cdrdao to use our CD burner. Open up {{Ic|/etc/cdrdao.conf}} (as root), and enter the /dev entry for your burner in this format:<br />
write_device: "/dev/cdrw"<br />
<br />
==Decode the MP3s==<br />
First of all, copy all the songs you want on the CD to a folder. If necessary, rename them to reflect the order you want the tracks to be laid out (such as 01.mp3, 02.mp3, etc). Now we're going to decode all the mp3s into uncompressed wav files. Take note that a full album can take up more than 800MB in wav files alone.<br />
mkdir wav<br />
for file in *.mp3 ; do<br />
lame --decode "$file" "wav/${file%.mp3}.wav" ;<br />
done<br />
<br />
==Create a Table of Contents file==<br />
Once finished, let's make a Table of Contents file that describes the layout of the CD.<br />
cd wav<br />
{<br />
echo "CD_DA"<br />
for file in *.wav ; do<br />
echo "TRACK AUDIO"<br />
echo "FILE \"$file\" 0"<br />
done<br />
} > toc<br />
<br />
Optionally, if you would like to insert a 2-second gap between certain tracks, you can edit the toc file and insert this line between the TRACK AUDIO and FILE lines for that track:<br />
PREGAP 00:02:00<br />
<br />
Of course, you can change the gap length to any time you desire.<br />
<br />
==Burn==<br />
Finally, all we have to do is burn the CD.<br />
cdrdao write toc<br />
<br />
Some people prefer to burn audio CDs at a low speed for higher quality. Here's an example for burning at 8x:<br />
cdrdao write --speed 8 toc</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Snort&diff=387149Snort2015-07-23T00:39:26Z<p>Rdahlgren: Update variable declarations to use 'ipvar' and 'portvar' as is used in the latest snort.conf and also documented in the included README.variables file</p>
<hr />
<div>[[Category:Security]]<br />
{{poor writing}}<br />
{{accuracy}}<br />
From the project [http://www.snort.org/ home page]:<br />
: ''Snort® is an open source network intrusion prevention and detection system ([[Wikipedia:Intrusion detection system|IDS]]/IPS) developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions of downloads and nearly 400,000 registered users, Snort has become the de facto standard for IPS.''<br />
<br />
== Installation ==<br />
<br />
Install {{AUR|snort}} from the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
The main configuration file is {{ic|/etc/snort/snort.conf}}.<br />
<br />
Read it carefully, as usual it is very well documented.<br />
ipvar HOME_NET 10.0.0.0/28 # Change to the subnet of your LAN.<br />
ipvar EXTERNAL_NET !$HOME_NET<br />
ipvar DNS_SERVERS $HOME_NET<br />
ipvar SMTP_SERVERS $HOME_NET <br />
ipvar HTTP_SERVERS $HOME_NET<br />
ipvar SQL_SERVERS $HOME_NET<br />
ipvar TELNET_SERVERS $HOME_NET<br />
portvar HTTP_PORTS 80<br />
portvar SHELLCODE_PORTS !80<br />
portvar ORACLE_PORTS 1521<br />
ipvar AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/<br />
24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]<br />
ipvar RULE_PATH /etc/snort/rules<br />
ipvar HTTP_PORTS 80:5000 # For HTTPd's running on port 80 and 5000. Change appropriately<br />
# to the ports you are using on your LAN.<br />
config detection: search-method lowmem # If you're using a machine "with very limited resources".<br />
<br />
At the bottom of the file, there is a list of includes. These define which rules you want to enforce. (Un)comment as you please. You should check that the corresponding file exists, as for me, none of the rules files were present.<br />
groupadd snort<br />
mkdir -p /var/log/snort<br />
useradd -g snort -d /var/log/snort snort<br />
chown -R snort:snort /var/log/snort<br />
<br />
{{Accuracy|Under review -- I am not sure about this yet.}}<br />
<br />
Edit {{ic|/etc/conf.d/snort}}:<br />
SNORT_ARGS="-u snort -g snort -l /var/log/snort -K ascii -c /etc/snort/snort.conf -D -h 10.0.0.0/28 -A full<br />
<br />
Replace 10.0.0.0/28 with the CIDR of your LAN.<br />
<br />
Now Snort will run as user snort in group snort. Should improve security. The other options make it log to {{ic|/var/log/snort}} in ASCII mode. Run ''snort -h'' to see other available options.<br />
<br />
I have been running my router for 12 days now, and using the above snort options, I had around 120MB of logs! So I changed the -A switch to "-A none". This only logs alerts. I did not know what to do with all the logs anyway.<br />
<br />
== Update the rules: Oinkmaster ==<br />
<br />
If you want to be able to download Snort's latest rules, you will need a subscription. This costs money. If you are happy enough with 5 days old rules, you just need to register for free. If you do not, the only updates you will get are the new rules distributed with a new Snort release. <br />
Go ahead and register at [https://www.snort.org/signup Snort]. If you really do not want to register, you can use the rules from [http://www.bleedingsnort.com/ BleedingSnort.com]. They are bleeding edge, meaning they have not been tested thoroughly.<br />
<br />
{{AUR|oinkmaster}} is available as [[AUR]] package.<br />
<br />
=== Oinkmaster setup ===<br />
<br />
Edit {{ic|/etc/oinkmaster.conf}} and look for the URL section and uncomment the 2.4 line. Make sure to replace ''<oinkcode>'' by the Oink code you generated after logging into your Snort account. For Bleeding Snort rules, uncomment the appropriate line.<br />
<br />
When you log into your new account, create an "Oink code".<br />
Another thing to change is<br />
use_external_bins=1 # 1 uses wget, tar, gzip instead of Perl modules<br />
<br />
The rest of the configuration file is fine.<br />
<br />
=== Oinkmaster usage ===<br />
<br />
oinkmaster.pl -o /etc/snort/rules<br />
<br />
Create an executable script with the exact command and place it in /etc/cron.daily to update the rules daily automatically.<br />
<br />
== See also ==<br />
<br />
* [[Simple stateful firewall]]<br />
* [[Router]]</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Snort&diff=387148Snort2015-07-23T00:37:45Z<p>Rdahlgren: Remove hint to "comment out" lists that aren't used. These must be present and non-empty for snort to start up.</p>
<hr />
<div>[[Category:Security]]<br />
{{poor writing}}<br />
{{accuracy}}<br />
From the project [http://www.snort.org/ home page]:<br />
: ''Snort® is an open source network intrusion prevention and detection system ([[Wikipedia:Intrusion detection system|IDS]]/IPS) developed by Sourcefire. Combining the benefits of signature, protocol, and anomaly-based inspection, Snort is the most widely deployed IDS/IPS technology worldwide. With millions of downloads and nearly 400,000 registered users, Snort has become the de facto standard for IPS.''<br />
<br />
== Installation ==<br />
<br />
Install {{AUR|snort}} from the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
The main configuration file is {{ic|/etc/snort/snort.conf}}.<br />
<br />
Read it carefully, as usual it is very well documented.<br />
var HOME_NET 10.0.0.0/28 # Change to the subnet of your LAN.<br />
var EXTERNAL_NET !$HOME_NET<br />
var DNS_SERVERS $HOME_NET<br />
var SMTP_SERVERS $HOME_NET <br />
var HTTP_SERVERS $HOME_NET<br />
var SQL_SERVERS $HOME_NET<br />
var TELNET_SERVERS $HOME_NET<br />
var HTTP_PORTS 80<br />
var SHELLCODE_PORTS !80<br />
var ORACLE_PORTS 1521<br />
var AIM_SERVERS [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/24,64.12.161.0/<br />
24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]<br />
var RULE_PATH /etc/snort/rules<br />
var HTTP_PORTS 80:5000 # For HTTPd's running on port 80 and 5000. Change appropriately<br />
# to the ports you are using on your LAN.<br />
config detection: search-method lowmem # If you're using a machine "with very limited resources".<br />
<br />
At the bottom of the file, there is a list of includes. These define which rules you want to enforce. (Un)comment as you please. You should check that the corresponding file exists, as for me, none of the rules files were present.<br />
groupadd snort<br />
mkdir -p /var/log/snort<br />
useradd -g snort -d /var/log/snort snort<br />
chown -R snort:snort /var/log/snort<br />
<br />
{{Accuracy|Under review -- I am not sure about this yet.}}<br />
<br />
Edit {{ic|/etc/conf.d/snort}}:<br />
SNORT_ARGS="-u snort -g snort -l /var/log/snort -K ascii -c /etc/snort/snort.conf -D -h 10.0.0.0/28 -A full<br />
<br />
Replace 10.0.0.0/28 with the CIDR of your LAN.<br />
<br />
Now Snort will run as user snort in group snort. Should improve security. The other options make it log to {{ic|/var/log/snort}} in ASCII mode. Run ''snort -h'' to see other available options.<br />
<br />
I have been running my router for 12 days now, and using the above snort options, I had around 120MB of logs! So I changed the -A switch to "-A none". This only logs alerts. I did not know what to do with all the logs anyway.<br />
<br />
== Update the rules: Oinkmaster ==<br />
<br />
If you want to be able to download Snort's latest rules, you will need a subscription. This costs money. If you are happy enough with 5 days old rules, you just need to register for free. If you do not, the only updates you will get are the new rules distributed with a new Snort release. <br />
Go ahead and register at [https://www.snort.org/signup Snort]. If you really do not want to register, you can use the rules from [http://www.bleedingsnort.com/ BleedingSnort.com]. They are bleeding edge, meaning they have not been tested thoroughly.<br />
<br />
{{AUR|oinkmaster}} is available as [[AUR]] package.<br />
<br />
=== Oinkmaster setup ===<br />
<br />
Edit {{ic|/etc/oinkmaster.conf}} and look for the URL section and uncomment the 2.4 line. Make sure to replace ''<oinkcode>'' by the Oink code you generated after logging into your Snort account. For Bleeding Snort rules, uncomment the appropriate line.<br />
<br />
When you log into your new account, create an "Oink code".<br />
Another thing to change is<br />
use_external_bins=1 # 1 uses wget, tar, gzip instead of Perl modules<br />
<br />
The rest of the configuration file is fine.<br />
<br />
=== Oinkmaster usage ===<br />
<br />
oinkmaster.pl -o /etc/snort/rules<br />
<br />
Create an executable script with the exact command and place it in /etc/cron.daily to update the rules daily automatically.<br />
<br />
== See also ==<br />
<br />
* [[Simple stateful firewall]]<br />
* [[Router]]</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=PKGBUILD&diff=299444PKGBUILD2014-02-21T21:22:24Z<p>Rdahlgren: Updated outdated 'updpkgsums' to show 'makepkg -g'</p>
<hr />
<div>[[Category:Package development]]<br />
[[cs:PKGBUILD]]<br />
[[da:PKGBUILD]]<br />
[[el:PKGBUILD]]<br />
[[es:PKGBUILD]]<br />
[[fa:PKGBUILD]]<br />
[[fr:PKGBUILD]]<br />
[[it:PKGBUILD]]<br />
[[ja:PKGBUILD]]<br />
[[pl:PKGBUILD]]<br />
[[pt:PKGBUILD]]<br />
[[ru:PKGBUILD]]<br />
[[sr:PKGBUILD]]<br />
[[zh-CN:PKGBUILD]]<br />
[[zh-TW:PKGBUILD]]<br />
{{Related articles start}}<br />
{{Related|Arch Packaging Standards}}<br />
{{Related|Arch Build System}}<br />
{{Related|Creating Packages}}<br />
{{Related|:Category:Package development}}<br />
{{Related|Custom local repository}}<br />
{{Related|pacman Tips}}<br />
{{Related|PKGBUILD Templates}}<br />
{{Related|Arch User Repository}}<br />
{{Related|makepkg}}<br />
{{Related|pacman}}<br />
{{Related articles end}}<br />
<br />
A '''PKGBUILD''' is an [[Arch Linux]] package build description file (actually it is a shell script) used when [[Creating Packages|creating packages]].<br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and information stored in PKGBUILDs. When '''makepkg''' is run, it searches for a {{Ic|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package file ({{ic|''pkgname''.pkg.tar.xz}}). The resulting package contains binary files and installation instructions, readily installed with [[pacman]].<br />
<br />
This article discusses the variables used in PKGBUILDs. For information on the PKGBUILD functions, refer to [[Creating_Packages#PKGBUILD_Functions]].<br />
<br />
== Variables ==<br />
The following are variables that can be filled out in the PKGBUILD file. {{ic|pkgname}}, {{ic|pkgver}}, {{ic|pkgrel}}, and {{ic|arch}} are all mandatory. {{ic|license}} is not strictly necessary to build a package, but it is recommended for any PKGBUILDS you might want to share with others. {{ic|makepkg}} produces warnings if it isn't present.<br />
<br />
It is common practice to define the variables in the PKGBUILD in same order as given here. However, this is not mandatory, as long as correct [[Bash]] syntax is used.<br />
<br />
=== pkgname ===<br />
The name of the package. It should consist of ''alphanumeric and any of the following characters @ . _ + - (at symbol, dot, underscore, plus, hyphen)''. All letters should be ''lowercase'' and ''names are not allowed to start with hyphens''. For the sake of consistency, {{ic|pkgname}} should match the name of the source tarball of the software you are packaging. For instance, if the software is in {{ic|foobar-2.5.tar.gz}}, the {{ic|pkgname}} value should be {{Ic|foobar}}. The present working directory the PKGBUILD file is in should also match the {{ic|pkgname}}.<br />
<br />
=== pkgver ===<br />
The version of the package. The value should be the same as the version released by the author of the package. It can contain letters, numbers, periods and underscore but CANNOT contain a hyphen. If the author of the package uses a hyphen in their version numbering scheme, replace it with an underscore. For instance, if the version is ''0.99-10'', it should be changed to ''0.99_10''. If the {{ic|pkgver}} variable is used later in the PKGBUILD then the underscore can easily be substituted for a dash on usage e.g.:<br />
source=("$pkgname-${pkgver//_/-}.tar.gz")<br />
<br />
=== pkgrel ===<br />
The release number of the package specific to Arch Linux. This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the '''release number starts at 1'''. As fixes and optimizations are made to the {{ic|PKGBUILD}} file, the package will be '''re-released''' and the '''release number''' will increment by 1. When a new version of the package comes out, the release number resets to 1.<br />
<br />
=== pkgdir ===<br />
This variable reflects the root directory of what will be put into the package. It is commonly used in {{ic|1=make DESTDIR="$pkgdir" install}}.<br />
<br />
=== epoch ===<br />
Used to force the package to be seen as newer than any previous versions with a lower epoch, even if the version number would normally not trigger such an upgrade. This value is required to be a positive integer; the default value if left unspecified is 0. This is useful when the version numbering scheme of a package changes (or is alphanumeric), breaking normal version comparison logic. See pacman(8) for more information on version comparisons.<br />
{{Warning|Do not use epoch unless fully aware of the implications of doing so.}}<br />
<br />
=== pkgbase ===<br />
An optional global directive is available when building a split package, pkgbase is used to refer to the group of packages in the output of makepkg and in the naming of source-only tarballs. If not specified, the first element in the pkgname array is used. All options and directives for the split packages default to the global values given in the PKGBUILD. Nevertheless, the following ones can be overridden within each split package's packaging function: pkgver, pkgrel, epoch, pkgdesc, arch, url, license, groups, depends, optdepends, provides, conflicts, replaces, backup, options, install and changelog. The variable is not allowed to begin with a hyphen.<br />
<br />
=== pkgdesc ===<br />
The description of the package. The description should be about 80 characters or less and should not include the package name in a self-referencing way. For instance, "Nedit is a text editor for X11" should be written as "A text editor for X11."<br />
<br />
{{Note|Do not follow this rule thoughtlessly when submitting packages to [[AUR]]. If package name differs from application name for some reason, inclusion of full name into description can be the only way to ensure that package can be found during search.}}<br />
<br />
=== arch ===<br />
An array of architectures that the {{ic|PKGBUILD}} file is known to build and work on. Currently, it should contain {{ic|i686}} and/or {{ic|x86_64}}, {{ic|1=arch=('i686' 'x86_64')}}. The value {{ic|any}} can also be used for architecture-independent packages.<br />
<br />
You can access the target architecture with the variable {{ic|$CARCH}} during a build, and even when defining variables. See also {{bug|16352}}. Example:<br />
<br />
depends=('foobar')<br />
if test "$CARCH" == x86_64; then<br />
depends+=('lib32-glibc')<br />
fi<br />
<br />
=== url ===<br />
The URL of the official site of the software being packaged.<br />
<br />
=== license ===<br />
The license under which the software is distributed. A {{pkg|licenses}} package has been created in {{ic|[core]}} that stores common licenses in {{ic|/usr/share/licenses/common}}, e.g. {{ic|/usr/share/licenses/common/GPL}}. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. {{ic|1=license=('GPL')}}. If the appropriate license is not included in the official {{Pkg|licenses}} package, several things must be done:<br />
<br />
# The license file(s) should be included in: {{ic|/usr/share/licenses/''pkgname''/}}, e.g. {{ic|/usr/share/licenses/foobar/LICENSE}}.<br />
# If the source tarball does NOT contain the license details and the license is only displayed elsewhere, e.g. a website, then you need to copy the license to a file and include it.<br />
# Add {{ic|custom}} to the {{ic|license}} array. Optionally, you can replace {{ic|custom}} with {{ic|custom:name of license}}. Once a license is used in two or more packages in an official repository (including {{ic|[community]}}), it becomes a part of the {{Pkg|licenses}} package.<br />
* The [[Wikipedia:BSD License|BSD]], [[Wikipedia:MIT License|MIT]], [[Wikipedia:ZLIB license|zlib/png]] and [[Wikipedia:Python License|Python]] licenses are special cases and could not be included in the {{pkg|licenses}} package. For the sake of the {{ic|license}} array, it is treated as a common license ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}} and {{ic|1=license=('Python')}}) but technically each one is a custom license because each one has its own copyright line. Any packages licensed under these four should have its own unique license stored in {{ic|/usr/share/licenses/''pkgname''}}. Some packages may not be covered by a single license. In these cases, multiple entries may be made in the license array, e.g. {{ic|1=license=('GPL' 'custom:name of license')}}.<br />
* Additionally, the (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:<br />
** (L)GPL - (L)GPLv2 or any later version<br />
** (L)GPL2 - (L)GPL2 only<br />
** (L)GPL3 - (L)GPL3 or any later version<br />
* If after researching the issue no license can be determined, {{ic|PKGBUILD.proto}} suggests using {{ic|unknown}}. However, upstream should be contacted about the conditions under which the software is (and is not) available.<br />
<br />
{{Tip|Some software authors do not provide separate license file and describe distribution rules in section of common ReadMe.txt. This information can be extracted in separate file during {{Ic|build}} phase with something like this: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}}.}}<br />
<br />
=== groups ===<br />
The group the package belongs in. For instance, when you install the {{Grp|kdebase}} package, it installs all packages that belong in the {{Grp|kde}} group.<br />
<br />
=== depends ===<br />
An array of package names that must be installed before this software can be run. Version restrictions can be specified with comparison operators, e.g. {{ic|1=depends=('foobar>=1.8.0')}}; if multiple restrictions are needed, the dependency can be repeated for each of them [https://mailman.archlinux.org/pipermail/arch-general/2012-July/029022.html], e.g. {{ic|1=depends=('foobar>=1.8.0' 'foobar<2.0.0')}}. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency. For instance, {{pkg|gtk2}} depends on {{pkg|glib2}} and {{pkg|glibc}}. However, {{pkg|glibc}} does not need to be listed as a dependency for {{pkg|gtk2}} because it is a dependency for {{pkg|glib2}}.<br />
{{Warning|The group {{Grp|base-devel}} is assumed to be already installed when building with makepkg. Members of "base-devel" '''should not''' be included in {{ic|depends}} arrays.}}<br />
<br />
=== optdepends ===<br />
An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted. An {{ic|optdepends}} may look like this:<br />
optdepends=(<br />
'cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support'<br />
)<br />
{{Warning|The group {{Grp|base-devel}} is assumed to be already installed when building with makepkg. Members of "base-devel" '''should not''' be included in {{ic|optdepends}} arrays.}}<br />
<br />
===makedepends===<br />
An array of package names that must be installed to build the software but unnecessary for using the software after installation. You can specify the minimum version dependency of the packages in the same format as the {{ic|depends}} array.<br />
<br />
{{Note|Specifying packages that are already in {{ic|depends}} is not necessary.}}<br />
{{Warning|The group {{Grp|base-devel}} is assumed to be already installed when building with makepkg. Members of "base-devel" '''should not''' be included in {{ic|makedepends}} arrays.}}<br />
<br />
=== checkdepends ===<br />
An array of packages this package depends on to run its test suite but are not needed at runtime. Packages in this list follow the same format as depends. These dependencies are only considered when the [[Creating Packages#The check() function|check()]] function is present and is to be run by makepkg.<br />
{{Warning|The group {{Grp|base-devel}} is assumed to be already installed when building with makepkg. Members of "base-devel" '''should not''' be included in {{ic|checkdepends}} arrays.}}<br />
<br />
=== provides ===<br />
An array of package names that this package provides the features of (or a virtual package such as {{Ic|cron}} or {{Ic|sh}}). Packages that provide the same things can be installed at the same time unless conflict with each other (see below). If you use this variable, you should add the version ({{ic|pkgver}} and perhaps the {{ic|pkgrel}}) that this package will provide if dependencies may be affected by it. For instance, if you are providing a modified ''qt'' package named ''qt-foobar'' version 3.3.8 which provides ''qt'' then the {{ic|provides}} array should look like {{ic|1=provides=('qt=3.3.8')}}. Putting {{ic|1=provides=('qt')}} will cause to fail those dependencies that require a specific version of ''qt''. Do not add {{ic|pkgname}} to your provides array; this is done automatically.<br />
<br />
=== conflicts ===<br />
An array of package names that may cause problems with this package if installed. A package with this name and all packages which {{Ic|provides}} virtual packages with this name will be removed. You can also specify the version properties of the conflicting packages in the same format as the {{ic|depends}} array.<br />
<br />
=== replaces ===<br />
An array of obsolete package names that are replaced by this package, e.g. {{ic|1=replaces=('ethereal')}} for the {{pkg|wireshark}} package. After syncing with {{ic|pacman -Sy}}, it will immediately replace an installed package upon encountering another package with the matching {{ic|replaces}} in the repositories. If you are providing an alternate version of an already existing package, use the {{ic|conflicts}} variable which is only evaluated when actually installing the conflicting package.<br />
<br />
=== backup ===<br />
An array of files that can contain user-made changes and should be preserved during upgrade or removal of a package, primarily intended for configuration files in {{ic|/etc}}.<br />
<br />
When updating, new version may be saved as {{ic|file.pacnew}} to avoid overwriting a file which already exists and was previously modified by the user. Similarly, when the package is removed, user-modified file will be preserved as {{ic|file.pacsave}} unless the package was removed with {{ic|pacman -Rn}} command. <br />
<br />
The file paths in this array should be relative paths (e.g. {{ic|etc/pacman.conf}}) not absolute paths (e.g. {{ic|/etc/pacman.conf}}). See also [[Pacnew and Pacsave Files]].<br />
<br />
=== options ===<br />
This array allows you to override some of the default behavior of {{ic|makepkg}}, defined in {{Ic|/etc/makepkg.conf}}. To set an option, include the option name in the array. To reverse the default behavior, place an '''{{ic|!}}''' at the front of the option. The following options may be placed in the array:<br />
<br />
* '''''strip''''' - Strips symbols from binaries and libraries. If you frequently use a debugger on programs or libraries, it may be helpful to disable this option.<br />
* '''''docs''''' - Save {{ic|/doc}} directories.<br />
* '''''libtool''''' - Leave ''libtool'' ({{ic|.la}}) files in packages.<br />
* '''''staticlibs''''' - Leave static library (.a) files in packages<br />
* '''''emptydirs''''' - Leave empty directories in packages.<br />
* '''''zipman''''' - Compress ''man'' and ''info'' pages with ''gzip''.<br />
* '''''purge''''' - Remove files specified by the {{ic|PURGE_TARGETS}} variable from the package.<br />
* '''''upx''''' - Compress binary executable files using UPX. Additional options can be passed to UPX by specifying the {{ic|UPXFLAGS}} variable.<br />
* '''''ccache''''' - Allow the use of {{ic|ccache}} during build. More useful in its negative form {{ic|!ccache}} with select packages that have problems building with {{ic|ccache}}.<br />
* '''''distcc''''' - Allow the use of {{ic|distcc}} during build. More useful in its negative form {{ic|!distcc}} with select packages that have problems building with {{ic|distcc}}.<br />
* '''''buildflags''''' - Allow the use of user-specific {{ic|buildflags}} (CFLAGS, CXXFLAGS, LDFLAGS) during build. More useful in its negative form {{ic|!buildflags}} with select packages that have problems building with custom {{ic|buildflags}}.<br />
* '''''makeflags''''' - Allow the use of user-specific {{ic|makeflags}} during build. More useful in its negative form {{ic|!makeflags}} with select packages that have problems building with custom {{ic|makeflags}}.<br />
<br />
=== install ===<br />
The name of the {{ic|.install}} script to be included in the package. pacman has the ability to store and execute a package-specific script when it installs, removes or upgrades a package. The script contains the following functions which run at different times:<br />
<br />
* '''''pre_install''''' - The script is run right before files are extracted. One argument is passed: new package version.<br />
* '''''post_install''''' - The script is run right after files are extracted. One argument is passed: new package version.<br />
* '''''pre_upgrade''''' - The script is run right before files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''post_upgrade''''' - The script is run right after files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''pre_remove''''' - The script is run right before files are removed. One argument is passed: old package version.<br />
* '''''post_remove''''' - The script is run right after files are removed. One argument is passed: old package version.<br />
<br />
Each function is run chrooted inside the pacman install directory. See [https://bbs.archlinux.org/viewtopic.php?pid=913891 this thread].<br />
<br />
{{Tip|A prototype {{ic|.install}} is provided at {{ic|/usr/share/pacman/proto.install}}. For a web-based prototype, refer to [https://projects.archlinux.org/pacman.git/plain/proto/proto.install pacman's gitweb page].}}<br />
<br />
=== changelog ===<br />
The name of the package changelog. To view changelogs for installed packages (that have this file):<br />
pacman -Qc ''pkgname''<br />
<br />
{{Tip|A prototype changelog file is provided at {{ic|/usr/share/pacman/ChangeLog.proto}}.}}<br />
<br />
=== source ===<br />
An array of files which are needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables {{ic|pkgname}} and {{ic|pkgver}} can be used effectively here (e.g. {{ic|<nowiki>source=("https://example.com/$pkgname-$pkgver.tar.gz")</nowiki>}})<br />
<br />
{{Note|If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your {{ic|PKGBUILD}} file is in and add the file name to this array. Any paths you add here are resolved relative to the directory where the {{ic|PKGBUILD}} lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and {{ic|makepkg}} will not proceed if any are missing.}}<br />
<br />
{{Tip|You can specify a different name for the downloaded file — if the downloaded file has a different name for some reason, like the URL had a GET parameter — using the following syntax: {{Ic|''filename''::''fileuri''}}<br />
For example:<br />
{{bc|1=source=("${pkgname}::<nowiki>hg+https://googlefontdirectory.googlecode.com/hg/</nowiki>")}}}}<br />
<br />
=== noextract ===<br />
An array of files listed under the {{ic|source}} array which should not be extracted from their archive format by {{ic|makepkg}}. This most commonly applies to archives which cannot be handled by {{ic|/usr/bin/bsdtar}} because {{Pkg|libarchive}} processes all files as streams rather than random access as {{Pkg|unzip}} does. In these situations, the alternative unarchiving tool (e.g., {{ic|unzip}}, {{ic|p7zip}}, etc.) should be added in the {{ic|makedepends}} array and the first line of the [[Creating Packages#The prepare() function|prepare()]] function should extract the source archive manually; for example:<br />
<br />
unzip [source].zip<br />
<br />
Note that while the {{ic|source}} array accepts URLs, {{ic|noextract}} is '''just''' the file name portion. So, for example, you would do something like this (simplified from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/grub grub2's PKGBUILD]):<br />
<br />
source=(<nowiki>"http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz"</nowiki>)<br />
noextract=('grub2_extras_lua_r20.tar.xz')<br />
<br />
To extract ''nothing'', you can do something fancy like this (taken from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n#n123 firefox-i18n]):<br />
<br />
noextract=("${source[@]%%::*}")<br />
<br />
{{Note|More conservative Bash substitution would possibly include a loop that calls {{ic|basename}}. If you have read this far, you should get the idea.}}<br />
<br />
=== md5sums ===<br />
An array of MD5 checksums of the files listed in the {{ic|source}} array. Once all files in the {{ic|source}} array are available, an MD5 hash of each file will be automatically generated and compared with the values of this array in the same order they appear in the {{ic|source}} array. While the order of the source files itself does not matter, it is important that it matches the order of this array because {{ic|makepkg}} cannot guess which checksum belongs to what source file. You can generate this array quickly and easily using the command {{ic|makepkg -g}} in the directory that contains the {{ic|PKGBUILD}} file.<br />
{{Note|The MD5 algorithm is known to have weaknesses; you should consider using a stronger alternative from the SHA-2 family of hash algorithms, such as SHA-256.}}<br />
<br />
=== sha1sums ===<br />
An array of 160-bit SHA-1 checksums. This is an alternative to {{ic|md5sums}} described above. To enable use and generation of these checksums, set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
{{Note|The SHA-1 algorithm is known to have weaknesses; you should consider using a stronger alternative from the SHA-2 family of hash algorithms, such as SHA-256.}}<br />
<br />
=== sha256sums, sha384sums, sha512sums ===<br />
An array of SHA-2 checksums with digest sizes 256, 384, and 512 bits, respectively. These are alternatives to {{ic|md5sums}} and {{ic|sha1sums}} described above and have fewer known weaknesses. To enable use and generation of these checksums, set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
<br />
== See also ==<br />
*[https://www.archlinux.org/pacman/PKGBUILD.5.html PKGBUILD(5) Manual Page]<br />
*[http://ix.io/66p Example PKGBUILD file]</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Traditional_compilation&diff=298883Talk:Kernel/Traditional compilation2014-02-19T06:05:43Z<p>Rdahlgren: We need to mention `make bzImage` as well</p>
<hr />
<div><br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)<br />
<br />
== Missing 'make bzImage' command ==<br />
This step is also required, otherwise there will be no bzImage to copy<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 06:05, 19 February 2014 (UTC)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Traditional_compilation&diff=298881Talk:Kernel/Traditional compilation2014-02-19T05:49:45Z<p>Rdahlgren: Added call for 'make modules' to be included</p>
<hr />
<div><br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Arch_build_system&diff=298880Talk:Kernel/Arch build system2014-02-19T05:49:21Z<p>Rdahlgren: Removed comment. This is the wrong page. It's been a long day, sorry</p>
<hr />
<div>*I am doing this now and 2 dependencies have shown up that are not documented, bc and xmlto. Or maybe these used to be installed with base-devel but no longer are.<br />
[[User:SanjeevKSharma|SanjeevKSharma]] ([[User talk:SanjeevKSharma|talk]]) 15:31, 27 October 2013 (UTC) <br />
<br />
<br />
* If somebody want to keep stock kernel beside custom one, shouldn't be the "provides" array uncommented, and changed to<br />
<nowiki>provides=('kernel26' 'linux')</nowiki><br />
?<br />
--[[User:4javier|4javier]] 05:27, 10 January 2012 (EST)<br />
: should I also uncomment these parts in package_linux-headers() and not only in package_linux()? --[[User:Onny|Onny]] 11:08, 8 March 2012 (EST)<br />
* this page does not mention that every changed .config-file has a new md5sum which should be added into the PKGBUILD --[[User:Onny|Onny]] 11:24, 8 March 2012 (EST)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel/Arch_build_system&diff=298879Talk:Kernel/Arch build system2014-02-19T05:48:39Z<p>Rdahlgren: Added call for 'make modules' to be included</p>
<hr />
<div>*I am doing this now and 2 dependencies have shown up that are not documented, bc and xmlto. Or maybe these used to be installed with base-devel but no longer are.<br />
[[User:SanjeevKSharma|SanjeevKSharma]] ([[User talk:SanjeevKSharma|talk]]) 15:31, 27 October 2013 (UTC) <br />
<br />
<br />
* If somebody want to keep stock kernel beside custom one, shouldn't be the "provides" array uncommented, and changed to<br />
<nowiki>provides=('kernel26' 'linux')</nowiki><br />
?<br />
--[[User:4javier|4javier]] 05:27, 10 January 2012 (EST)<br />
: should I also uncomment these parts in package_linux-headers() and not only in package_linux()? --[[User:Onny|Onny]] 11:08, 8 March 2012 (EST)<br />
* this page does not mention that every changed .config-file has a new md5sum which should be added into the PKGBUILD --[[User:Onny|Onny]] 11:24, 8 March 2012 (EST)<br />
<br />
<br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel&diff=298878Talk:Kernel2014-02-19T05:48:01Z<p>Rdahlgren: Posted feedback to the wrong page</p>
<hr />
<div>== Style of Address ==<br />
Who is the "I" mentioned in [[Kernels#Patches and Patchsets]]? First-person address doesn't fit the style of this wiki. The form of address should be changed to pose a more neutral style. [[User:Qguv|Qguv]] ([[User talk:Qguv|talk]]) 15:37, 14 August 2013 (UTC)<br />
: Agreed, feel free to make changes. Be sure to follow [https://wiki.archlinux.org/index.php/Help:Style#Edit_summary this]. Thank you for your diligence. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 02:36, 20 August 2013 (UTC)<br />
<br />
== Regression Testing ==<br />
Would it be valuable to add a section or article on doing kernel regression testing using git? Ideally, such an article would cover everything from git clone to the bug-report itself.<br />
<br />
Given that we are a highly up to date release, we do live on the edge of new commits. It seems likely that we are some of the first in the "general" public that encounter regressions and I'd like to encourage people to track down these issues in a decent manner.--[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 08:31, 3 October 2012 (UTC)<br />
<br />
:This sounds like a good idea, please go on and try to interlink the new article with the others it's related with. In general, keep [[Help:Style#Hypertext metaphor]] in mind ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:56, 3 October 2012 (UTC)<br />
<br />
== Relevence? ==<br />
Whatever [[Kernels#Gensplash.2Ffbsplash|Gensplash]] was, it appears now not to be a patchset, but rather a set of utilities for init. [[http://fbsplash.alanhaggai.org/ Reference page]] Why is it mentioned here? [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 18:39, 23 May 2013 (UTC)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:Kernel&diff=298877Talk:Kernel2014-02-19T05:46:44Z<p>Rdahlgren: Added call for 'make modules'</p>
<hr />
<div>== Style of Address ==<br />
Who is the "I" mentioned in [[Kernels#Patches and Patchsets]]? First-person address doesn't fit the style of this wiki. The form of address should be changed to pose a more neutral style. [[User:Qguv|Qguv]] ([[User talk:Qguv|talk]]) 15:37, 14 August 2013 (UTC)<br />
: Agreed, feel free to make changes. Be sure to follow [https://wiki.archlinux.org/index.php/Help:Style#Edit_summary this]. Thank you for your diligence. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 02:36, 20 August 2013 (UTC)<br />
<br />
== Regression Testing ==<br />
Would it be valuable to add a section or article on doing kernel regression testing using git? Ideally, such an article would cover everything from git clone to the bug-report itself.<br />
<br />
Given that we are a highly up to date release, we do live on the edge of new commits. It seems likely that we are some of the first in the "general" public that encounter regressions and I'd like to encourage people to track down these issues in a decent manner.--[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 08:31, 3 October 2012 (UTC)<br />
<br />
:This sounds like a good idea, please go on and try to interlink the new article with the others it's related with. In general, keep [[Help:Style#Hypertext metaphor]] in mind ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:56, 3 October 2012 (UTC)<br />
<br />
== Relevence? ==<br />
Whatever [[Kernels#Gensplash.2Ffbsplash|Gensplash]] was, it appears now not to be a patchset, but rather a set of utilities for init. [[http://fbsplash.alanhaggai.org/ Reference page]] Why is it mentioned here? [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 18:39, 23 May 2013 (UTC)<br />
<br />
== Missing 'make modules' command ==<br />
The article mentions 'make module_install' without explicitly calling for 'make modules' - this will result in a lot of `cp` errors.<br />
[[User:Rdahlgren|Rdahlgren]] ([[User talk:Rdahlgren|talk]]) 05:46, 19 February 2014 (UTC)</div>Rdahlgrenhttps://wiki.archlinux.org/index.php?title=Talk:NVIDIA&diff=298863Talk:NVIDIA2014-02-19T00:55:07Z<p>Rdahlgren: Added personal experience using nvidia package with a 304xx recommended card</p>
<hr />
<div>== XRandR support ==<br />
As far as i understand it the recent drivers support XRANDR, which is probably much better than Xinerama/Twinview. Should we remove the Xinerame/Twinview instructions alltogether and just mention to use the standard XRandR methods for multiscreen setups?<br />
<br />
== NVoption Online ==<br />
<br />
NVoption Online Version - great tool to make tv-out easy and fast <br />
<br />
[I'm using gmplayer with gl and twinview]<br />
[http://www.sorgonet.com/linux/nv-online/]http://www.sorgonet.com/linux/nv-online/<br />
<br />
== Reword ==<br />
Maybe someone can put this in better words:<br />
Logging out, or switching to a different terminal using ctrl+alt+F<2-9> consistently resulted in a black screen, and killing Xorg with ctrl-alt-backspace resulted in a terminal screen with only the top line visible. It turned out that a 'vga=773' added to kernel line was the cause of this. After removing that the problem was solved. Probably something to do with KMS? B.t.w. I have only used x with 'startx', so possibly specific for that way of starting X.<br />
[[User:rwd|rwd]]<br />
<br />
:Was it with this driver or nouveau? The proprietary drivers don't have KMS. [[User:Thestinger|thestinger]] 17:42, 13 December 2010 (EST)<br />
<br />
This was with the proprietary driver. I originally had put vga=.. because it made gave the bootup screen a higher resolution, and because the beginners guide mentions it (https://wiki.archlinux.org/index.php/Beginners%27_Guide#GRUB). Apart from leaving out the vga option, I discovered that setting it to the native resolution as explained on https://wiki.archlinux.org/index.php/GRUB#Framebuffer_resolution fixes the black screens as well. Maybe a warning for using vga= option with with proprietary drivers would be useful.[[User:rwd|rwd]]<br />
<br />
Well the thing is that vga= is meant for the proprietary drivers only - open source drivers already set the native resolution without a vga command. It can be removed from the beginners' guide though, since it breaks open source drivers, and if the card doesn't support the vga command, it breaks the closed source ones too. [[User:Thestinger|thestinger]] 20:13, 13 December 2010 (EST)<br />
<br />
== custom kernel ==<br />
<br />
The package changed for kernel 3.0 and the instructions no longer work. Please fix this. [[User:Z.T.|Z.T.]] 09:14, 23 November 2011 (EST)<br />
<br />
== '/dev/nvidia0' Input/Output error... suggested fixes ==<br />
<br />
Can anyone verify that the BIOS related suggestions work and are not coincidentally set (either automatically when changing the IRQ or turning off ACPI) while troubleshooting? I have found little information that confirms any of the suggestions would work. The file permissions thing seems to be completely unfounded and never works (as noted in the article) that I could find. It would probably be a good idea if we cleaned out items that have not been verified to work. For my setup I was having this error and none of the items in the wiki nor the many file permission search results worked. -- [[User:Clickthem|click, them so hard]] 19:16, 4 March 2012 (EST)<br />
:I've added an Accuracy template, please next time add it yourself so that discussions like this are more visible. -- [[User:Kynikos|Kynikos]] 05:40, 6 March 2012 (EST)<br />
<br />
== Rewrite ==<br />
I think the "Installing" section is a little ambiguous and could use a bit of rewording. Because the steps are numbered, and little indication is given otherwise, it is implied that you need both the packages named like nvidia-173xx, ''and'' the regular nvidia packages. I don't actually have my nvidia drivers working properly, so maybe I'm misinterpreting this, but if I'm right in assuming that you need ''either'' the specifically named drivers like nvidia-173xx ''or'' the plain ol' nvidia drivers, step 2 needs to be reworded. I would suggest displaying two separate [code] blocks, one with # pacman -S nvidia-173xx nvidia-173xx-utils, and the one that's there now. Then make it explicitly clear that you need to do one or the other, not both. --[[User:Sotanaht|Sotanaht]] 18:45, 17 May 2012 (EDT)<br />
<br />
Oh, I forgot that the nvidia-173xx drivers were not in the official repos. Scratch the part about including the command for installing that. I still think it's important to make clear that people using the nvidia-173xx drivers ''do not need'' the regular nvidia drivers. Also make it clear that people using the regular nvidia drivers do not need any nvidia-XXXxx drivers. --[[User:Sotanaht|Sotanaht]] 18:49, 17 May 2012 (EDT)<br />
<br />
:Well, I've never had to use the old Nvidia drivers, but the note says that the old modules don't support Xorg 1.11 (Arch provides 1.12 now). Unless the situation has changed, those drivers are useless unless you also write instructions on how to safely downgrade Xorg. Please correct me if I'm wrong. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:27, 19 May 2012 (UTC)<br />
<br />
== Bad performance, e.g. slow repaints when switching tabs in Chrome suggestion broke emerald/compiz ==<br />
Firefox performs quite poorly for me, so I tried this suggestion and it ended up breaking my WM. All new window borders changed to solid white and would not move around. Can someone else confirm? If so there should probably be a note or amendment to the suggestion. [[User:Biltong|Biltong]] ([[User talk:Biltong|talk]])<br />
<br />
== Run a test ==<br />
<br />
There is confusing paragraph saying ''You can run a test to see if the Xorg server will function correctly without a configuration file.''. IMHO, it should be clarified what kind of test the author has in mind, an exact command would be helpful. Currently, this suggestion is simply confusing, especially to less experienced users. --[[User:Mloskot|Mloskot]] ([[User talk:Mloskot|talk]]) 19:52, 26 November 2012 (UTC)<br />
<br />
== nvidia-xconfig ==<br />
<br />
Several of the commands which are suggested to be run with nvidia-xconfig (such as nvidia-xconfig --twinview) don't work with the current nvidia packages in the repository. I just went through setting mine up so I intend to clean up the ones that I can from my experience. Some don't seem to have a 1:1 replacement (there is a --dynamic-twinview argument now; is that the same as --twinview was?). [[User:Techprophet|Teh]] ([[User talk:Techprophet|talk]]) 13:10, 20 June 2013 (UTC)<br />
<br />
== Why the Different Package Versions? ==<br />
<br />
Despite having a 5 series card, I ignored the wiki and installed the normal nvidia driver rather than the one from AUR. Everything has been working fine so far and I get fine framerates in games. What is the reason for recommending different drivers for different cards? If installing the regular driver is a viable option for non-8-series cards, it should be mentioned as well. [[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 02:37, 24 January 2014 (UTC)<br />
: What graphics card do you have exactly? Which package did you install? Which AUR package do you think you should have installed? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:45, 24 January 2014 (UTC)<br />
:: These driver are proprietary which means users must count on NVIDIA. The latest code branch will not be tested on old cards that End of life. So the basic function may still work but no one could guarantee the quality. This is the main reason why open source driver is prefered.--[[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:18, 5 February 2014 (UTC)<br />
<br />
I can also vouch for using the nvidia package rather than nvidia-304xx - I gave a GeForce 650 ti, which is listed as a 304xx card. The 304xx packages, however, do not work with the latest CUDA toolkit. I upgraded to the nvidia package and it works perfectly - 3d acceleration, CUDA, etc. I think that since nvidia changed how they package their Linux drivers, users no longer need to worry about grabbing specific package versions. I'd be all for updating this, as it initially misled me. [[User:Rdahlgren|rdahlgren]] ([[User talk:Rdahlgren|talk]]) 00:54, 19 February 2014 (UTC)</div>Rdahlgren