text:
Thank you. You should be receiving a reset link at the email address you provided shortly.
You can only add one course to your cart at a time! By adding this course, you will replace the existing course from your cart. How would you like to proceed?
Enter your first name.
Enter your last name.
Enter your email.
Enter your phone number.
Boot Camp Session Dates:
The following dates are available for this boot camp. Once you register, our enrollment team will contact you to confirm your session dates.
Prepare for the American College of Sports Medicine (ACSM) Certified Personal Trainer (CPT) certification exam with this online course.
phone Call Us:
This online instructor-led course prepares you for the American College of Sports Medicine (ACSM) Certified Personal Trainer (CPT) certification exam. Additional supplemental documents are provided complimentary to you for use in preparing for the ACSM-CPT exam.
The course was developed under the guidance of outstanding faculty drawn from colleges/universities, the allied health/medical field, and the personal fitness training profession. The course includes presentations and outlines, specialized exam preparation materials, and 145+ practice test questions. ACSM-CPTs work with healthy individuals and those with health challenges who can exercise independently to enhance their quality of life, improve health-related physical fitness and performance, manage health risks, and promote lasting, healthy behavior changes.
Upon completing the course and passing the ACSM-CPT certification exam, you will be prepared to work in one of the fastest-growing segments of the service industries, according to the U.S. Labor Department of Occupational Statistics and Employment Projections. Upon completing the course, you will be prepared to address that demand to work in fitness facilities, gyms, health clubs, YMCAs, and other health/fitness settings working as a personal trainer and fitness professional.
The American College of Sports Medicine's Professional Education Committee certifies that "Educational Fitness Solutions" meets the criteria for official ACSM Approved Provider status from 2022 – December 2023. Providership # 672784.
Continuing Education Credits/Units
This course qualifies for CECs/CEUs for the following organizations.
What you will learn
How you will benefit
Hardware Requirements:
Software Requirements:
Instructional Material Requirements:
The instructional materials required for this course are included in enrollment. The following textbooks will be shipped to you approximately 7-10 business days after enrollment:
Please note: You will receive a digital book if the physical book is on backorder.
There are no prerequisites to take this course. However, there are prerequisites to complete the ACSM Accredited Certification Exam.
Exam Eligibility Requirements:
Our highly knowledgeable Enrollment Specialists will answer any questions you might have about the course and payment options.
Ken Baldwin
Ken Baldwin, M.ED., ACSM-H/FI has been involved in the fitness, wellness, and education profession for over 10 years. He is the senior editor, content expert, and lead author for ACSM's Resources for the Personal Trainer Textbook, Second Edition." He was chair of IDEA's National Personal Trainer Committee and chair of the Senior Fitness Subcommittee for the Massachusetts Governor's Committee on Physical Fitness and Sports. He serves on national committees for the American College of Sports Medicine (ACSM), AAHPERD, and the Medical Fitness Association. His background includes operating and managing a personal training company, consulting at corporations, and lecturing at international conferences, public events, national conventions.
Does this course prepare for a certification?
Yes, you will be prepared for the ACSM Certified Personal Trainer (CPT) certification offered by the American College of Sports Medicine (ACSM). Exam eligibility requirements:
When can I start this course?
This course is open enrollment, so you can register and start the course whenever you are ready. Access to your course can take 24-48 business hours.
How long does it take to complete this course?
After you register, you will receive 6 months to complete the course. The time allotted for completion has been calculated based on the number of course hours.
What if I don't have enough time to complete the course within the time frame provided?
If you are unable to complete the course, contact your Student Advisor to help you work out a suitable completion date. Please note that an extension fee will be charged. If you are funded through a third-party organization, approval may also be required.
What kind of support will I receive?
Our courses are designed to accommodate various learning preferences. Depending on the course structure, you may get different forms of support. Self-paced courses are designed to be user-friendly and independent, minimizing the need for external support. In courses with instructors, our direct platform support feature includes opportunities for questions, discussions, and remediation, with email and phone support available for select courses. Our student advising team is available to guide you on program requirements and administrative requests, but they do not provide assistance with course content. Our goal is to provide you with the necessary support for success, whether it's through self-paced exploration, direct communication, or guidance from our advising team.
What happens when I complete the course?
Upon successfully passing the final exam, you will be awarded a certificate of completion from the school or organization that you registered through.
Am I guaranteed a job?
ed2go courses will help you gain the skills you need to obtain an entry-level position in most cases. However, you should always research the job market in your area before enrolling.
Can I get financial assistance?
ed2go courses are non-credit, so they do not qualify for federal aid, FAFSA, and Pell Grant. In some states, vocational rehab or workforce development boards may provide funding to take our courses. Additionally, you may qualify for financial assistance if you meet certain requirements. To learn more about financial assistance.
How can I get more information about this course?
If you have questions that are not answered on our website, representatives are available via LIVE chat. You can also call us at 1-877-221-5151 during regular business hours to have your questions promptly answered. If you are visiting us during non-business hours, please send us a question using the "Contact Us."
A password reset link has been sent to the email address you provided.


text:
Como criar pacotes
Esta página descreve com algum detalhe a mecânica básica de como criar um pacote RPM para Fedora (em particular, como criar um ficheiro .spec). Serão também dados avisos práticos sobre o que irá ou não funcionar, o que lhe poderá poupar horas mais tarde.
Esta página não aprofunda algumas questões, mas aponta para outros documentos que o fazem. Ao contrário de muitos documentos RPM Howto, este documento explica as especificidades para o Fedora (com imensos links para guias específicos Fedora) e tenderá a ser mais actual (porque é mantido através do Fedora Wiki).
Por exemplo, ele avisa sobre os impactos de mudanças que ocorreram no RPM versão 4.4.2.x. Apesar da sua focalização no Fedora, a maior parte deste documento aplica-se a outras distribuições de base RPM. Se é impaciente, pode começar por ver How_to_create_a_GNU_Hello_RPM_package, que é um tutorial sumário sobre a criação de pacotes RPM (mas não tem tanto detalhe como o desta página).
Se planeia criar um pacote RPM para o repositório Fedora, siga o processo em Como juntar-se ao Fedora Package Collection Maintainers, incluindo seguindo a variada orientação Fedora.
Configurar o seu sistema e conta
Antes de criar pacotes no Fedora, necessita instalar algumas ferramentas nucleares e configurar a(s) conta(s) que vai usar.
# yum install @development-tools # yum install fedora-packager
Pode criar um "utilizador dummy" especificamente para criar pacotes rpm. Desta forma, se alguma coisa correr terrivelmente mal, o programa ou processo de construção não estragará o sistema de ficheiros ou não publicará para o mundo as suas chaves/ficheiros privados.
Pode criar rapidamente um novo utilizador chamado "makerpm" fazendo:
# /usr/sbin/useradd makerpm
Depois faça log in com o utilizador dummy (makerpm).
Assim que tenha entrado com o utilizador que cria pacotes, crie uma estrutura de diretórios no diretório home executando
$ rpmdev-setuptree
O programa "rpmdev-setuptree" vai criar o diretório ~/rpmbuild. Por baixo de "rpmbuild" existem vários diretórios (como SPECS e BUILD), que vai usar para criar os seus pacotes. O "rpmdev-setuptree" também cria o ficheiro ~/.rpmmacros que vai fazer com que os programas rpm e rpmbuild o usem quando apropriado.
The packaging guidelines recommend using commands that preserve file timestamps; you can make this automatic if you use wget or curl to get the source files. If you use wget to get source files, consider adding to ~/.wgetrc the command "timestamping = on". Similarly, if you use curl, consider adding to ~/.curlrc the text "-R".
Assim que tenha configurado a conta de utilizador, noemalmente, não precisará de seguir estes passos novamente.
Bases para criar pacotes RPM
Para criar um pacote RPM, você precisará criar um arquivo de texto ".spec" que contenha as informações sobre o software que será empacotado. Então, execute o comando "rpmbuild" com o arquivo spec como parâmetro, que passará por uma série de passos para produzir seu pacote.
Normalmente, você precisa colocar seus arquivos-fonte originais (primitivos), como arquivos .tar.gz dos desenvolvedores originais, em "~/rpmbuild/SOURCES". Você precisa colocar seu arquivo .spec em "~/rpmbuild/SPECS" e nomeá-lo como "NOME.spec", onde NOME é o nome-base do pacote. Para criar todos os pacotes (pacotes binário e fonte), você precisa ir até o diretório "~/rpmbuild/SPECS" e executar:
rpmbuild -ba NAME.spec
Quando invocado desta maneira, o rpmbuild lerá o arquivo spec e tentará passar através dos seguintes estágios (nessa ordem; nomes iniciados com % são macros pré-definidas descritas abaixo, e os diretórios que cada estágio normalmente lê e escreve estão listados):
Stage | Reads | Writes | Action |
%prep | %_sourcedir | %_builddir | Lê os sources e patches(correções) no diretório %_sourcedir (geralmente ~/rpmbuild/SOURCES). Desempacota os sources para um subdiretório abaixo do diretório de build %_builddir (geralmente ~/rpmbuild/BUILD/) e aplica os patches. |
%build | %_builddir | %_builddir | Compila os arquivos abaixo dodiretório de build %_builddir (geralmente ~/rpmbuild/BUILD/). Isto é frequentemente implementado pela execução de alguma variação de "./configure ; make". |
%check | %_builddir | %_builddir | Verifica se o software funciona corretamente. Isto é frequentemente implementado pela execução de alguma variação de "make test". Muitos pacotes não implementam esse estágio. |
%install | %_builddir | %_buildrootdir | Lê os arquivos abaixo do diretório de build %_builddir (geralmente ~/rpmbuild/BUILD/) e escreve em um diretório abaixo do diretório de build %_buildrootdir (geralmente ~/rpmbuild/BUILDROOT). Os arquivos que são escritos são aqueles que supostamente serão instalados quando o pacote binário é instalado pelo usuário final. Cuidado com a terminologia estranha: O diretório de build raiz não é o mesmo que diretório de build. Isto frequentemente é implementado executando-se "make install". |
bin | %_buildrootdir | %_rpmdir | Lê os arquivos abaixo do diretório de build raiz %_buildrootdir (geralmente ~/rpmbuild/BUILDROOT/) para criar o pacote RPM binário abaixo do diretório RPM %_rpmdir (geralmente ~/rpmbuild/RPMS/). Dentro do diretório RPM, há um diretório para cada arquitetura, e um diretório "noarch" para pacotes aplicáveis a qualquer arquitetura. Estes arquivos RPM são os pacotes para o usuário instalar. |
src | %_sourcedir | %_srcrpmdir | Cria um pacote source RPM (.src.rpm) dentro do diretório source RPM %_srcrpmdir (geralmente ~/rpmbuild/SRPMS). Esses arquivos são necessários para revisão e atualização de pacotes. |
Como você pode ver, certos diretórios tem propósitos específicos no diretório rpmbuild. São esses:
Nome Macro | Nome | Geralmente em | Propósito |
%_specdir | Diretório de Especificação | ~/rpmbuild/SPECS | Arquivos de especificação RPM (.spec) |
%_sourcedir | Diretório de fontes | ~/rpmbuild/SOURCES | Pacote fonte primitivo (e.g., tarballs) de patches(correções) |
%_builddir | Directory de builds | ~/rpmbuild/BUILD | Arquivos-fonte são desempacotados e compilados em um diretório logo abaixo deste. |
%_buildrootdir | Diretório de build raiz | ~/rpmbuild/BUILDROOT | Arquivos são instalados abaixo deste diretório durante o estágio Files %install. |
%_rpmdir | Diretório de RPM binário | ~/rpmbuild/RPMS | RPM binários são criados e armazenados aqui. |
%_srcrpmdir | Diretório de RPM fonte | ~/rpmbuild/SRPMS | Source RPMs são criados e armazenados aqui. |
No caso de falha de algum estágio, você deverá verificar a saída para ver por que o estágio falhou, e modificar o arquivo .spec (ou outra entrada), conforme necessário.
Preparar-se para empacotar um programa em particular
If there are special programs that are required to build or run the program you are packaging, install those other programs and write down what they were (you'll need that information).
To package a program for the Fedora repository, you must package pristine (original) sources, along with the patches and build instructions; it's not okay to start with pre-compiled code. Install the file with the original source (usually a .tar.gz file) in the "~/rpmbuild/SOURCES" directory (of the rpm building user account).
Read through the manual installation instructions for your program; you're going to be automating this by editing a ".spec" file, so you have to understand what you're supposed to do first. It's probably best if you try a "dry run", going through its build and installation procedure without trying to do it via RPM first (that's especially true if you're not familiar with RPM). With a few exceptions, all program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package.
Dividir o programa
Application source code is often released with the source code of other external libraries "bundled" into them. Do not bundle external libraries and the application that uses them into a single package. Instead, split them up into separate packages.
Only package software that's legal for you to package.
As noted in the packaging guidelines' legal section, if you intend for it to be in the Fedora repository, be sure to follow the Licensing:Main and Packaging:LicensingGuidelines guidelines. In general, you need to only package software that is released as open source software (OSS) using an approved OSS license (such as the GNU GPL, GNU LGPL, BSD-new, MIT/X, or Apache 2.0 licenses). Check to make sure that the software really is licensed this way (e.g., spot-check source code headers, README files, and so on). If there are bundled libraries, make sure they are also OSS.
Reutilizar informação existente no pacote
Try to reuse what you can. Obviously, make sure you aren't packaging something that is already packaged; you can find a list of existing packages in Fedora Package Collection in the Fedora Package Database. Also check the In Progress Review Requests (for packages that are currently being reviewed) and the Retired Packages list. Failing that, see if someone has already started to package it for Fedora. Google for "PROGRAMNAME Fedora rpm" or similar... maybe you can pick up where they started. You can use http://pkgs.fedoraproject.org/gitweb/ directly to view .spec files (and patches) of any similar packages already in Fedora. You can download the source RPMs using a program from the yum-utils package, by:
$ yumdownloader --source sourcepackage-name
Alternatively, an existing source rpm can be retrieved manually by browsing to the Fedora mirror's http or ftp page, select releases/11/Everything/source/SRPMS (replace "11" with the Fedora release you want), and downloading the source RPMs you want (they end in .src.rpm).
Once you have the source RPM, running the following command installs the src.rpm
$ rpm -ivh sourcepackage-name*.src.rpm
which places the package's .spec file into ~/rpmbuild/SPECS and other source and patch files in ~/rpmbuild/SOURCES).
You can also unpack the .src.rpm in a directory using rpm2cpio:
$ mkdir PROGRAMNAME_src_rpm $ cd PROGRAMNAME_src_rpm $ rpm2cpio ../PROGRAMNAME-*.src.rpm | cpio -i
Sometimes it's easiest to start with an existing package, and then clean it up for Fedora. RPM Find may help you find rpm's for non-Fedora systems. (You can install source RPMs for other systems the same way as for Fedora). Failing that, you might look at the source package files (not the .deb binary package files) for Ubuntu or Debian (source package files are standard tarballs with a "debian/" subdirectory, possibly associated with patch files). If the FreeBSD ports collection has it, you could download the FreeBSD ports tarball and see if their packaging information helps as a starting point. However, this is sometimes not helpful at all. Different distributions have different rules, and what they do may be quite inappropriate for Fedora.
Criar um ficheiro spec
You now need to create a ".spec" file in the "~/rpmbuild/SPECS" directory. You should name it after the program name, e.g., "program.spec". Use the archive name or the name advocated by the software author where you can, but be sure to follow the Package Naming Guidelines.
Criar um ficheiro spec em branco
When you're creating a spec file for the first time, you can create its initial version using emacs or vim (as of 7.1.270-1), they will automatically create a template for you. E.G.:
$ cd ~/rpmbuild/SPECS $ vi program.spec
Here's an example of what that template will look like:
Name: Version: Release: 1%{?dist} Summary: Group: License: URL: Source0: BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildRequires: Requires: %description %prep %setup -q %build %configure make %{?_smp_mflags} %install rm -rf %{buildroot} make install DESTDIR=%{buildroot} %clean rm -rf %{buildroot} %files %defattr(-,root,root,-) %doc %changelog
You may have $RPM_BUILD_ROOT instead of %{buildroot}; just be consistent.
You may also use the rpmdev-newspec
command to create a spec file for you. rpmdev-newspec NAME-OF-NEW-PACKAGE
can create an initial spec file for a new package, tailored to various types of packages. It will guess what kind of template to use based on the package name, or you can specify a particular template; see /etc/rpmdevtools/spectemplate-*.spec
for available templates. See rpmdev-newspec --help
for more information. For example, to create a new spec file for a python module:
cd ~/rpmbuild/SPECS rpmdev-newspec python-antigravity vi python-antigravity.spec
Um exemplo: eject
Aqui temos um pequeno exemplo, um pacote Fedora 9 para o programa "eject":
Summary: Um programa que ejecta mídia utilizando controlo por software Name: eject Version: 2.1.5 Release: 11%{dist} License: GPL Group: System Environment/Base Source: http://metalab.unc.edu/pub/Linux/utils/disk-management/%{name}-%{version}.tar.gz Source1: eject.pam Patch1: eject-2.1.1-verbose.patch Patch2: eject-timeout.patch Patch3: eject-2.1.5-opendevice.patch Patch4: eject-2.1.5-spaces.patch Patch5: eject-2.1.5-lock.patch Patch6: eject-2.1.5-umount.patch BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root URL: http://www.pobox.com/~tranter ExcludeArch: s390 s390x BuildRequires: gettext BuildRequires: automake BuildRequires: autoconf BuildRequires: libtool %description O programa eject permite ao utilizador ejetar mídia (tipicamente CD-ROMs, discos floppy ou discos Iomega Jaz ou Zip) utilizando control por software. Eject pode também controlar alguns CD changers de multi-discos e alguns dispositivos com caracteristicas auto-eject. Instale o eject se quiser ejectar mídia por controlo de software. %prep %setup -q -n %{name} %patch1 -p1 -b .versbose %patch2 -p1 -b .timeout %patch3 -p0 -b .opendevice %patch4 -p0 -b .spaces %patch5 -p0 -b .lock %patch6 -p1 -b .umount %build %configure make %install rm -rf %{buildroot} make DESTDIR=%{buildroot} install # pam stuff install -m 755 -d %{buildroot}/%{_sysconfdir}/pam.d install -m 644 %{SOURCE1} %{buildroot}/%{_sysconfdir}/pam.d/%{name} install -m 755 -d %{buildroot}/%{_sysconfdir}/security/console.apps/ echo "FALLBACK=true" > %{buildroot}/%{_sysconfdir}/security/console.apps/%{name} install -m 755 -d %{buildroot}/%{_sbindir} pushd %{buildroot}/%{_bindir} mv eject ../sbin ln -s consolehelper eject popd %find_lang %{name} %clean rm -rf %{buildroot} %files -f %{name}.lang %defattr(-,root,root) %doc README TODO COPYING ChangeLog %attr(644,root,root) %{_sysconfdir}/security/console.apps/* %attr(644,root,root) %{_sysconfdir}/pam.d/* %{_bindir}/* %{_sbindir}/* %{_mandir}/man1/* %changelog * Wed Apr 02 2008 Zdenek Prikryl <zprikryl at, redhat.com> 2.1.5-11 - Added check if device is hotpluggable - Resolves #438610
Ficheiro Spec às partes, explicado
The RPM Guide, section on creating RPMs, describes the details of how to fill in a spec file. The developerWorks series "Packaging software with RPM" Part 1, Part 2, and Part 3 is also handy. Maximum RPM has the most complete information, but is dated.
You will need to follow the Fedora guidelines, such as the Package Naming Guidelines, Packaging Guidelines, and Package review guidelines.
You can insert comments with a leading "#" character, but don't insert potentially-multiline-macros (words beginning with "%") in a comment (macros are expanded first); if you're commenting out a line, double the percent signs ("%%"). Also, don't use inline comments ("#") on the same line after a script command.
Here are the major fields/areas that you will need to fill in:
- Name: The (base) name of the package. It must follow the Package Naming Guidelines. In many cases, this will be in all lower case. Elsewhere in the spec file, you can refer to the name using the macro %{name} - that way, if the name changes, the new name will be used by those other locations. This name should match the spec file name.
- Version: The upstream version number. See Packaging/Naming guidelines - package version for more information. If the version is non-numeric (contains tags that are not numbers or digits), you may need to include the additional non-numeric characters in the release field. If upstream uses full dates to distinguish versions, consider using version numbers of the form yy.mm[dd] (so a 2008-05-01 release becomes 8.05). Elsewhere in the spec file, refer to this value as %{version}.
- Release: The initial value of the release should normally be "1%{?dist}". Then, increment the number every time you release a new package for the same version of software. If a new version of the software being packaged is released, the version number should be changed to reflect the new software version, and the release number should be reset to 1. See Name Guidelines - package release for more. Packaging/DistTag describes the "dist" tag, which isn't required but can be useful. Use %{release} to reuse this value.
- Summary: A brief, one-line summary of the package. Use American English, and do not end in a period.
- Group: This needs to be a pre-existing group, like "Applications/Engineering"; run "less /usr/share/doc/rpm-*/GROUPS" to see the complete list. If you create a sub-package "...-doc" with documentation, use the group "Documentation".
- License: Its license; for software, this must be an open source software license. Use a standard abbreviation, e.g., "GPLv2+". Try to be specific, e.g., use "GPLv2+" (GPL version 2 or greater) instead of just "GPL" or "GPLv2" where it's true. See Licensing and the Licensing Guidelines for more information. You can list multiple licenses by combining them with "and" and "or", e.g., "GPLv2 and BSD". Call this tag "License"; don't use the older, inaccurately named tag "Copyright".
- URL: The URL for more information about the program, e.g., the project website. Note: This is NOT where the original source code came from, see "Source" (next!).
- Source0: The URL for the compressed archive containing (original) pristine source code, as upstream released it. "Source" is synonymous with "Source0". If you give a full URL (and you should), its basename will be used when looking in the SOURCES directory. If possible, embed %{name} and %{version}, so that changes to either will go to the right place. Warning: Source0: and URL: are different - normally they are both URLs, but the "URL:" entry points to the project website, while the "Source0:" entry points to the actual file containing the source code (and is typically a .tar.gz file). As noted in the guidelines, "When downloading sources, patches etc, consider using a client that preserves the upstream timestamps. For example wget -N or curl -R. To make the change global for wget, add this to your ~/.wgetrc: timestamping = on, and for curl, add to your ~/.curlrc: -R." If there is more than one source, name them Source1, Source2, and so on. If you're adding whole new files in addition to the pristine sources, you can list each of them as sources as well, but list them after the pristine sources. A copy of each of these sources will be included in any source package you create (unless you specially direct otherwise). See Packaging/SourceURL for more information on special cases (using revision control, when upstream uses prohibited code, etc.).
- Patch0: The name of the first patch that you will apply to the source code. If you need to patch the files after they've been uncompressed, you should edit the files, save their differences as a "patch" file in your ~/rpmbuild/SOURCES directory. Patches should make only one logical change, so it's quite possible to have multiple patch files.
- BuildArch: If you're packaging files that are architecture-independent (e.g., shell scripts, data files, etc.), then add "BuildArch: noarch". The architecture for the binary RPM will then be "noarch".
- BuildRoot: This is where files will be "installed" during the "%install" process (which happens after the %build compilation process). Normally you should just leave this line alone; under the usual Fedora setup, this will be a macro that will create a new special directory under /var/tmp. Newer versions of RPM will ignore this value, and instead place the build root in "%{_topdir}/BUILDROOT/".
- BuildRequires: A comma-separated list of packages required for building (compiling) the program. These are not automatically determined, so you need to include everything needed to build the program. There are a few packages that are so common in builds that you don't need to mention them, such as "gcc"; see the Packaging Guidelines for the complete list of the packages you may omit. You can also specify minimum versions, if necessary, like this: "ocaml >= 3.08". You can have more than one line of BuildRequires (in which case they are all required for building). If you need file /EGGS, you can get its package by running "rpm -qf /EGGS"; if EGGS is a program, you determine its package quickly by running "rpm -qf
which EGGS
". Try to specify only the minimal set of packages necessary to properly build the package, since each one will slow down a "mock"-based build (e.g., try to use sed instead of perl if you don't really need perl's abilities). Watch out: Some applications permanently disable functions if their package isn't detected during the build; in those cases you may need to include those additional packages. If you have trouble figuring out this list, the "auto-br-rpmbuild" command (from the auto-buildrequires package) may be helpful. - Requires: A comma-separate list of packages that are required when the program is installed. Note that the list of packages for Requires (what's required when installing/running) and BuildRequires (what's required to build the binary RPM) are independent; a package may be in one list but not the other, or it could be in both. The dependencies of binary packages are in many cases automatically detected by rpmbuild, so it is often the case that you don't need to specify the Requires tag at all. But if you want to highlight some specific packages as being required, or require a package that rpm can't detect should be required, then add it here.
- %description - A longer, multi-line description of the program. Use American English. All lines must be 80 characters or less. "Blank lines are assumed to separate paragraphs. Some graphical user interface installation programs will reformat paragraphs... (lines that) start with whitespace, such as a space or tab, will be treated as preformatted text and displayed as is, normally with a fixed-width font." (per the RPM Guide).
- %prep - Script commands to "prepare" the program, that is, to uncompress it so that it will be ready for building (compiling). Typically this is just "%setup -q" or some variation of it; a common variation is "%setup -q -n NAME" if the source file unpacks into NAME. See the "%prep" section below for more.
- %build - Script commands to "build" the program, that is, to compile it and get it ready for installing. The program should come with instructions on how to do this. See the "%build" section below for more.
- %check - Script commands to self-test the program. This is run after %build and before %install, so you should place it there if you have this section. Often it simply contains "make test" or "make check". This is separated from %build so that people can skip the self-test if they desire. This isn't documented in many places.
- %install - Script commands to "install" the program. The commands should copy the files from the "build directory" %{_builddir} (which would be under ~/rpmbuild/BUILD) into the buildroot directory, %{buildroot} (which would normally be under /var/tmp). See the "%install" section below for more.
- %clean - instructions to clean out the build root. Typically:
rm -rf %{buildroot}
- %files - the list of files that will be installed. See the "%files" section below for more.
- %changelog - Changes in the package. Use the format example above.
- ExcludeArch: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in an ExcludeArch tag.
- You can add sections so that code will run when packages are installed or removed on the real system (as opposed to just running the %install script, which only does a pseudo-install to the build root). These are called "scriptlets", and they are usually used to update the running system with information from the package. See the "Scriptlets" section below for more.
Don't use the tags "Packager" or "Vendor". Don't use "Copyright" - use "License" instead. Don't create a "relocatable" package - they don't add value in Fedora yet they make things more complicated.
RPM supports subpackages, that is, a single spec file can generate many binary packages. For example, if the documentation is very large, you might generate a separate "-doc" subpackage. See below for more.
%prep section
The "%prep" section describes how to unpack the compressed packages so that they can be built. Typically, this is a set of "%setup" and/or %patch commands, which reference the Source0:, Source1:, etc. lines above. See the Maximum RPM section on %setup and %patch for more details.
Warning: In spec files, don't use in-line comments (a "#" comment on the same line after a command), and don't put macros (words beginning with "%") in a comment unless you quote the "%" as "%%". Macros can cause failures if they are in a comment, because they are always expanded (even when in a comment) and they can expand to multiple lines. This is true for %prep, %build, and so on.
The new RPM 4.4.2.x series adds two new macros, %{patches} and %{sources}, so you can do things like:
for p in %{patches}; do ... done
These new macros can be very useful if you have a large list of patches or sources. However, keep in mind that using these will make your spec incompatible with the rpm used in Fedora 9 and earlier, RHEL, and many other RPM-based distros.
%prep section: %setup command
The "%setup" command unpacks a source package, and takes several switches. Normally you should use "-q" (quiet) to prevent setup from babbling about every file it unpacks. Here are a few switches besides -q:
- -n name: If the name of the rpm is something other than what the Source unpacks to, use this switch to state the name it unpacks to. E.G., if the tarball unpacks into a directory MYNAME, use %setup -q -n MYNAME
- -c name: If the tarball doesn't unpack into a single directory, this creates a directory named name and then unpacks into it. Useful if you have one of those annoying tarballs that doesn't have a single common subdirectory embedded in it.
There are more %spec options if you are unpacking multiple files, which is primarily useful if you are creating subpackages (see below). The key ones are:
-a number | Only unpack the source directive of the given number, such as –a 0 for source0:, after changing to the directory. |
-b number | Only unpack the source directive of the given number, such as –b 0 for source0:, before changing to the directory. |
-D | Do not delete the directory before unpacking. |
-T | Disable the automatic unpacking of the archives. |
%prep section: %patch commands
The "%patch0" command applies patch 0 (similar for 1, 2, etc.). Patches are the normal way to change to the source code if necessary to package it. The normal "-pNUMBER" option applies, which simply passes that argument on to patch.
Patch file names often look like "telnet-0.17-env.patch", that is, %{name}-%{version}-patch_purpose.patch (some people omit -%{version}). Patch files are typically the result of a "diff -u"; if you do this from the subdirectory of ~/rpmbuild/BUILD, you won't have to specify a -p level later. You can use all the normal ways of creating a patch file.
If you're creating a patch file a single file FILENAME, a common way is to copy it to FILENAME.orig, modify it, and then save the results of "diff -u FILENAME.orig FILENAME". If you change directory to "~/rpmbuild/BUILD/NAME", you could create a patch file to change a single file by doing:
cp X/Y.Z X/Y.Z.orig vim X/Y.Z diff -u X/Y.Z.orig X/Y.Z > ~/rpmbuild/SOURCES/PKGNAME.REASON.patch
If you're going to edit many files, one easy method is to copy the whole subdirectory underneath BUILD, and then do subdirectory diffs; once you change directory to "~rpmbuild/BUILD/NAME", you can:
cp -pr ./ ../PACKAGENAME.orig/ ... many edits ... diff -u ../PACKAGENAME.orig . > ~/rpmbuild/SOURCES/NAME.REASON.patch
If you edit many files in one patch, you can also copy the original files using some consistent ending such as ".orig" before editing them. Then, you can use "gendiff" (in the rpm package) to create a patch with the differences. Do "man gendiff" for more information.
Try to ensure that in your patch the "context" matches exactly. In old versions of Fedora, the default "fuzz" value was 2, which meant that imprecise matches were acceptable. However, the version of RPM used by Fedora 10 and later have a default fuzz to 0, requiring that matches be exact. You can work around this by adding "%global _default_patch_fuzz 2", but it's better to not have the problem by making the patch match the context exactly.
As explained in Packaging/PatchUpstreamStatus, all patches in Fedora spec files SHOULD have a comment above them about their upstream status. This should document the upstream bug/email that includes it (including the date), or if it's Fedora-unique, why it is unique. The Fedora Project focuses, as much as possible, on not deviating from upstream in the software it includes in the repository - see Staying close to upstream projects for more about why it's important to do this.
%prep section: Unmodified files
Sometimes, you'll package just a straight file that doesn't need to be uncompressed, e.g., a "Source1:" that is just a simple PDF file. These might not be from external sources, e.g., perhaps you've had to create a few additional files that weren't in the original sources so that the package cleanly installs in Fedora. You can "prep" those into the build directory by doing this (replace "1" with whatever number it is):
cp -p %SOURCE1 .
%build section
The "%build" section is sometimes complicated; here you configure and compile/build the files to be installed.
Many programs follow the GNU configure approach (or some variation). By default, they will install to a prefix of "/usr/local" (/usr/local/bin, /usr/local/lib, etc.), which is a reasonable default for unpackaged files. However, since you are packaging it, you will want to change the prefix to "/usr", since this is now a package maintained by the system itself. If there are any libraries, they'll need to be installed in the right directory, which is either /usr/lib or /usr/lib64 depending on the architecture (the actual value is in %{_libdir}).
Since the GNU "configure" system is so common, rpm pre-defines a macro named "%configure", which invokes GNU configure with the right options (e.g., it changes --prefix to /usr). This means that some variation of this will often work as a build command:
%configure make %{?_smp_mflags}
Sometimes you'll want to override the variables of a makefile; you can easily do that by passing them as parameters to make, like this:
make %{?_smp_mflags} CFLAGS="%{optflags}" BINDIR=%{_bindir}
If you need to do something complicated with GNU-generated configure, take a look at "GNU autoconf, automake, and libtool". A good presentation on these as well as "make" is "Open Source Development Tools: An Introduction to Make, Configure, Automake, Autoconf" by Stefan Hundhammer.
Some programs use Cmake. See Packaging/cmake for some suggestions.
If you include some self-tests (and that's a good idea), put them in a separate "%check" section that immediately follows the "%build" area, instead of including them in %build. That way, it will be easy for the system to skip unnecessary self-tests.
%check section
The "%check" section does testing, often it's "make test". This is not documented in many other sources of RPM info.
%install section
The "%install" section is a set of script commands to "install" the program. The commands in this section should copy the files from a directory inside the "build directory" %{_builddir} (normally ~/rpmbuild/BUILD/something) into the build root directory, %{buildroot} (normally /var/tmp/something), creating the directories inside %{buildroot} as necessary.
Watch out: Some of the terminology is very misleading:
- The build directory (under which compilations occur during %build) and the build root (where files are copied into during the %install process) are different. The point of the %install process is to copy files, such as those under the build directory, to the right place in the build root. Perhaps "buildroot" should be called "installroot", but it's too late now, the terminology is entrenched.
- The build directory is normally ~/rpmbuild/BUILD, while the build root (where files get installed to during %install) is normally ~/rpmbuild/BUILDROOT. The %prep stage will normally create a subdirectory underneath the build directory as part of %setup, and populate the build directory with files (based on the source information in %_sourcedir, which is typically in ~/rpmbuild/SOURCES). During %build, the current directory will actually start at %{buildsubdir}, that newly-created subdirectory under the build directory. Typically %{buildsubdir} is something like ~/rpmbuild/BUILD/%{name}-%{version}.
- The "%install" script is not used when the binary rpm package is installed by the end-user!! The term "%install" is misleading, in fact, the script must not install the programs in the REAL final locations (e.g., in /usr/bin), but under the buildroot %{buildroot}.
Normally, the install script would first erase the %{buildroot} directory, and then do some variation of "make install" (ideally using DESTDIR=%{buildroot}, if the program supports it). Here's an example of an %install section:
%install rm -rf %{buildroot} make DESTDIR=%{buildroot} INSTALL="install -p" CP="cp -p" install
Ideally, every program would have a "make install" command that supported the DESTDIR convention. If the program includes a "make install" that supports DESTDIR, where possible, use it. The DESTDIR convention supports redirecting file installations to descend from a specific directory, which is exactly what we want during %install.
Installing a program that does not support DESTDIR can be much harder, and no option is as good as native DESTDIR support. Consider these alternatives:
- Patch the makefile so that it does support DESTDIR. Create directories inside DESTDIR where necessary (feel free to use "mkdir -p", the "-p" option of mkdir is now standard and widely supported). Be sure to submit the patch upstream.
- Use "%makeinstall". Many older RPM documents suggest using "%makeinstall", which might work if "make install" doesn't support DESTDIR. However, as noted in the Fedora guidelines, the %makeinstall macro "must NOT be used when make install DESTDIR=%{buildroot} works. %makeinstall is (merely) a kludge that can work with Makefiles that don't make use of the DESTDIR variable...". Unfortunately, this sometimes has subtle failures, which is why %makeinstall should not be used if DESTDIR works. The reason is based on how %makeinstall works. The "%makeinstall" macro expands to something like "make prefix=%{buildroot}%{_prefix} bindir=%{buildroot}%{_bindir} ... install". Many programs will quietly recompile or change parts of the program when values like prefix are changed, resulting in an incorrect installation. See the Fedora guidelines if you want the details on why this approach can fail. You will probably need to create appropriate directories inside %buildroot before calling %makeinstall (e.g., mkdir -p %{buildroot}%{_bindir}/).
- Consider using the auto-destdir package. This requires "BuildRequires: auto-destdir", and changing "make install" to "make-redir DESTDIR=%{buildroot} install". This only works well if the installation uses only certain common commands to install files, like cp and install; see "man make-redir" for details.
- Do the installation "by hand", that is, instead of invoking a build system, copy the files to the correct locations. Basically, this would be a sequence that would create directories that weren't already created by the "BuildRequires" packages (typically using install -d or mkdir -p), followed by copying of files from the current directory (inside the build directory) into the buildroot directory (typically using "cp -p" and/or "install -p"). Running "make -n install" may make it easy to determine what this sequence should be. Be sure to create directories inside %buildroot where necessary. One serious problem with this approach is that it's easy to fail to install new or renamed files during an update—so if there's a better approach, use it instead. If you do perform the installation "by hand", be especially careful with updates when using this approach. For example:
%install rm -rf %{buildroot} mkdir -p %{buildroot}%{_bindir}/ cp -p mycommand %{buildroot}%{_bindir}/
As noted in the packaging guidelines' timestamp section, "when adding file copying commands in the spec file, consider using a command that preserves the files' timestamps, eg. cp -p or install -p". So, if the makefile lets you override the install command (typically named INSTALL), you might want something like INSTALL="install -p" CP="cp -p" as make parameters, like this:
make INSTALL="install -p" CP="cp -p" DESTDIR=%{buildroot} install
Seção %files
A seção de arquivos% identifica quais arquivos e diretórios foram adicionadas pelo pacote e, assim, que arquivos e diretórios são de propriedade do pacote. A propriedade é importante - quando você digita "rpm -qif blah", você verá que é dono blah. Esta seção é usada quando se realiza o estágio bin, para determinar quais arquivos são colocados em cada arquivo RPM binário.
%files Basics
The %files section normally begins with a %defattr line which sets the default file permissions. The format of this is %defattr(<file permissions>, <user>, <group>, <directory permissions>), that is, one can specify the permissions to apply to files and directories in the %files section. The fourth parameter is often omitted. Usually one uses %defattr(-,root,root,-), where "-" means "use the default permissions".
This is followed by names or patterns of the directories or files to be installed and owned by this package. You should use macros for directory names, e.g., use %{_bindir}/myfile instead of /usr/bin/myfile, and %{_sbindir}/killaccount instead of /usr/sbin/killaccount. If a name or pattern begins with "/" when expanded, then it is presumed to have been copied into the %{buildroot} followed by that pattern; when installed on the final system, it will be copied into that name without the buildroot prefix. If you don't precede the pattern with "/", then it is presumed to be in the current directory (e.g., inside the build directory) - this is used for "documentation" files. So if your package just installs /usr/sbin/mycommand, then your %files section could simply say:
%files %defattr(-,root,root,-) %{_sbindir}/mycommand
Any file or directory identified in the %files section is owned by the defining package. You should make sure that you declare ownership of every new file or directory the package creates. You can use wildcards (*) which match a set of files - this makes the package less sensitive to changes. For example, you can declare that all the files that were copied into %{buildroot}/usr/bin are owned by this package by declaring:
Note that "%{_bindir}/*" does not claim that this package owns the /usr/bin directory - it claims that all the files that were installed inside the build root 's /usr/bin are owned by the package. If you list a directory in the %files section, then you are claiming that this package owns that subdirectory and all files and directories in it, recursively (all the way down) if they are present in the build root. Do not list the "/usr/bin" or "%{_bindir}" directories directly in your %files list, because that would claim ownership of /usr/bin and everything inside it. Claiming ownership of "%{_bindir}/*" is fine, though; that just claims ownership of the subdirectories and files you placed under %{buildroot}/%{_bindir}. If you create a subdirectory such as %{_datadir}/%{name}, (/usr/share/NAME), you should include that directory in the %files list:
It's usually easier to use wildcards for filenames, and that's also better at coping with changes in upstream. Older RPM documentation typically shows long lists under %files with individual names, such as /usr/bin/program1 followed by /usr/bin/program2. Because of the way Fedora now uses buildroots, that is no longer necessary.
It's an error if no file matches the wildcard of a line, so only note the directories that actually matter. Also, you can't identify the same file or directory more than once. Finally, it's an error to have something in the buildroot and not listed under %files; the whole point of copying something into the buildroot is because you intend to have it installed in the final system. If you don't intend that, remove those files during the %install process.
It is also possible to exclude files from a previous match by using a %exclude glob. This can be useful for including "almost all" of the files that match a different glob. However, note that, like any other file glob, even a %exclude glob will fail if it matches nothing. (This might be considered counterintuitive, as the whole point is essentially to ensure that a certain file ISN'T there, so this rule is especially important to remember.)
%files prefixes
You may need to add one or more prefixes to a %files entry (if more than one, use a space to separate them).
Typically there is a "%doc" entry with a list of documentation files that didn't get copied into the buildroot; usually there is at least a README and LICENSE file. You must include the license file, if there is one. You may prefix some of these with %attr(mode, user, group) to set the file permission mode, user, or group. You don't need to claim ownership of the /usr/share/doc/%{name} directory, that's automatic if there's a %doc entry. Any %doc entry must not affect the runtime of the application (if it is in %doc, the program must run properly if it is not present).
There is a potential 'gotcha' with %doc entries: if you have a %doc entry, then you can't use commands during %install to copy files into the documentation directory descending from %_defaultdocdir. That's because if there's a %doc entry, rpmbuild will automatically remove the docdir files created by %install before installing the files listed with %doc. This can hit you if, for example, you want an "examples" subdirectory in the documentation directory. In this case, don't use "%doc" to mark documentation. Instead, create the directories and copy the files into %{buildroot}%{_defaultdocdir}/%{name}-%{version}/ during %install, and make sure that %files includes an entry for "%{_defaultdocdir}/%{name}-%{version}/". They will still be correctly marked as documentation.
If you save configuration files (under /etc - don't put them under /usr), you should normally prefix them with %config(noreplace) unless this program version uses a non-backwards-compatible configuration format (in which case, prefix them with %config).
Prefixing a %files entry with "%attr(mode, user, group)" lets you set the permissions for particular file(s), e.g., "%attr(0644, root, root)". A "-" means "use the default".
If a file is in particular natural language, use %lang to note that. E.G.:
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
Programs using Locale files should follow the recommended method of handling the i18n files:
- find the filenames in the
step:%find_lang ${name}
- add the required build dependencies:
BuildRequires: gettext
- use the found filenames:
%files -f ${name}.lang
Some documentation claims that %license and %readme are valid prefixes; they are not valid in Fedora. Use %doc instead.
%files and Filesystem Hierarchy Standard (FHS)
You should follow the Filesystem Hierarchy Standard (FHS), i.e., ordinary application executables go into /usr/bin, global configuration files go into /etc, ordinary libraries go into /usr/lib, and so on, with one exception: executables that should not normally be executed directly by users or administrators should go into a subdirectory of /usr/libexec; usually you'd refer to the necessary directory as "%{_libexecdir}/%{name}".
You shouldn't be installing files under /usr/local; that is where unpackaged files go. Typically there will be a "prefix" attribute that lets you set the prefix to be "/usr" instead of "/usr/local".
Unfortunately, many programs' "normal" installation routines do not follow the FHS. In particular, many programs normally place architecture-independent libraries under /usr/lib, instead of under /usr/share as the FHS requires. The FHS /usr/lib section says that /usr/lib is for architecture-dependent data (e.g., ELF files like .so files), while /usr/share is for architecture-independent data. That way, systems with different CPUs can share /usr/share. There are many exceptions to this rule in Fedora (e.g., Python and Perl), but Fedora applies this rule more strictly than some distributions. Note, for example, that rpmlint will complain if you put just about anything other than ELF files into /usr/lib.
%files example
Here's a simple example of a %files section:
%files %defattr(-,root,root,-) %doc README LICENSE %{_bindir}/* %{_sbindir}/* %{_datadir}/%{name}/
Finding duplicates
The Fedora guidelines require that "A Fedora package must not list a file more than once in the spec file's %files listings."
You can list any duplicates of two binary packages by doing:
cd ~/rpmbuild/RPMS/ARCH # Substitute "ARCH" for your architecture rpm -qlp PACKAGE1.*.rpm | sort > ,1 rpm -qlp PACKAGE2.*.rpm | sort > ,2 comm -12 ,1 ,2
You can add sections so that code will run when packages are installed or removed on the real system (as opposed to just running the %install script, which only does a pseudo-install to the build root). These are called "scriptlets", and they are usually used to update the running system with information from the package.
The scriptlets in %pre and %post are run before and after a package is installed (respectively). The scriptlets %preun and %postun are run before and after a package is uninstalled. The scriptlets %pretrans and %posttrans are run at start and end of a transaction. See Packaging/ScriptletSnippets for more examples and details. For example, every binary RPM package which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun (post-install and post-uninstall). If the package has multiple subpackages with libraries, each subpackage should also have a %post/%postun section that calls /sbin/ldconfig. For example:
%post -p /sbin/ldconfig %postun -p /sbin/ldconfig
Beware: The "-p" option specifies what command processor to use for the commands on the following lines. If there are no following lines, then using /sbin/ldconfig as the "command processor" is a minor efficiency improvement compared to putting "/sbin/ldconfig" on the next line, and letting the shell invoke it. That's because by using "-p", the shell isn't invoked simply to invoke a single program. But if you have multiple shell commands, don't use "-p" or /sbin/ldconfig after it! Instead, leave it blank, and include the shell commands under it.
If you are going to run programs in scriptlets, they must be installed before you run them. You have to use special variants of the "Requires:" tag, so that the program will be installed before you try to use it. These are of the form "Requires(CONTEXT):", e.g., "Requires(post)".
Most scriptlets (%pre, %post, %preun, and %postun) provide an argument you can use, accessed via $1, which is the number of packages of this name which will be left on the system when the action completes. Don't compare for equality with 2; check if they are greater than or equal than 2, since users can arrange to have multiple versions of a package installed simultaneously. For %pretrans and %posttrans, $1 is always 0.
For example, after adding an info manual to the system the dir file which indexes the info manuals should be updated. Basically, after you install the info manual, you need to run the program install-info. That's fine, except that install-info is part of package info, and there's no guarantee that info is installed unless we require it. Also, if "install-info" fails, we don't want to fail all processing. Here's one way to do that:
Requires(post): info Requires(preun): info ... %post /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : %preun if [ $1 = 0 ] ; then /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || : fi
There is another glitch related to installing info files. The install-info
command will update
the info directory, but we have to prevent the install of a useless, empty directory file from the
RPM_BUILD_ROOT environment, by deleting it in the %install
rm -f $RPM_BUILD_ROOT%{_infodir}/dir
Another scriptlet-like abilility are triggers. You can define triggers for when other packages are installed or uninstalled. See Maximum RPM for more information about triggers.
Spec files may contain "macro" references (text beginning with "%"), which are replaced with other values. You can follow % by a word, e.g., "%name", but just like shell variables you must bracket the name with {...} if letters or digits immediately follow, e.g., "%{name}".
As noted in the Packaging Guidelines, There are two styles for referring some values such as the rpm Build Root and Optimization Flags:
- "macro style": %{buildroot}, %{optflags}
- "variable style": $RPM_BUILD_ROOT, $RPM_OPT_FLAGS
Pick a style and use it consistently throughout your packaging; this document uses "macro style".
Here are some typical macros:
Macro | Typical Expansion | Meaning |
%{_bindir} | /usr/bin | Binary directory (where executables are usually stored) |
%{_builddir} | ~/rpmbuild/BUILD | Build directory; files are compiled a subdirectory of the build directory. See %buildsubdir. |
%{buildroot} | ~/rpmbuild/BUILDROOT | Build root, where files are "installed" during %install. The %install stage copies files from a subdirectory of %{_builddir} to a subdirectory of %{buildroot}. Historically %{buildroot} was in "/var/tmp/". |
%{buildsubdir} | %{_builddir}/%{name} | Build subdirectory, where files are compiled during %build. It's under %{_builddir}, set after %setup. |
%{_datadir} | /usr/share | Share directory. |
%{_defaultdocdir} | /usr/share/doc | Default documentation directory. |
%{dist} | .fcNUMBER | Distribution+version short name (e.g., ".fc9") |
%{fedora} | NUMBER | Number of fedora release (e.g., 9) |
%{_includedir} | /usr/include | |
%{_infodir} | /usr/share/info | |
%{_initrddir} | /etc/rc.d/init.d | |
%{_libdir} | /usr/lib | |
%{_libexecdir} | /usr/libexec | |
%{_localstatedir} | /var | |
%{_mandir} | /usr/share/man | |
%{name} | Name of package, set by Name: tag | |
%{_sbindir} | /usr/sbin | |
%{_sharedstatedir} | /var/lib | |
%{_sysconfdir} | /etc | |
%{version} | Version of package, set by Version: tag |
To see more about macros you can look in /etc/rpm/* and the "macros" files under "/usr/lib/rpm/", especially /usr/lib/rpm/macros. You can also use "rpm --showrc" to show the values rpm will use for all of the options currently set in rpmrc and macro configuration files.
You can set your own macro values using %global; be sure to define them before you use them. Macro definitions can refer to other macros. For example:
%global myvalue 50
You can use rpmbuild to find the value of some macro, using its "-E" (--eval) option. For example, to find the current expansion of %{_bindir} in myfile.spec, you can run:
rpmbuild -E '%{_bindir}' myfile.spec
Packaging/RPMMacros has more information on macros, as does RPM Guide chapter 9.
Other tags
We noted the "Requires" and "BuildRequires" tags earlier. There are a few other tags for controlling dependencies: Provides, Obsoletes, Conflicts, and BuildConflicts.
- "Provides:" lets you list virtual package names that this package provides. Sometimes there are several different packages that can provide a function, and using packages won't care which one. In that case, each of the packages that provide the function should "provide" a virtual package, and then using packages can list the virtual package name under "Requires:". For example, several different packages might provide "latex"; if you depend on the virtual package "tex(latex)", then users can choose which package to get "latex" from. If you provide virtual packages, you might also want to use the "alternatives" system, but be careful: "alternatives" settings are system-wide, so if multiple users on the same system might want different defaults, don't use the alternatives system. You can find out what a given package provides (both virtual and non-virtual names) by querying "rpm -q --provides PACKAGENAME". Some virtual packages in Fedora are:
- MTA : Used for mail transport agents, such as sendmail.
- tex(latex) : Used for latex
- "Obsoletes:" lets you state that installing this package should (normally) cause the removal of the other named package(s). This is useful when a package's name changes, or when a package wholly replaces a different package.
- "Conflicts:" lets you state what packages cannot be installed simultaneously this one. Obviously, try to avoid this if you can; see Packaging/Conflicts if you think you need to use it.
- "BuildConflicts:" lets you state what packages cannot be installed when building this package. Obviously, try to avoid this if you can.
You can control which architectures a package builds (or doesn't build). For example, if your package can't compile on ppc, you can do this:
ExcludeArch: ppc
There's also an "ExclusiveArch" tag. The valid architectures one can specify in these tags are listed in the Architectures section.
A spec file can define more than one binary package, e.g., client and server, or runtime and developer packages. If there's a large amount of documentation, it may be split into a NAME-doc subpackage. You will always have one spec file and one source RPM (SRPM), even if there are multiple binary RPMs that they generate. A spec file that produces multiple binary packages still has only one creation process, so there is only one %prep, %build, %check, and %install section that creates all the files for all the packages.
In a spec file, use the %package directive to start defining a subpackage:
%package sub_package_name
By default, the subpackage name is PACKAGE_NAME, "-", SUBPACKAGE_NAME; you can use "-n" to override this and make a new name:
%package -n new_sub_package_name
After the %package directive, list the tags for the subpackage. This should include at least the "Summary:" and "Group:" tags and directives "%description SUBPACKAGE_NAME" and "%files SUBPACKAGE_NAME". Anything not specified by the subpackage will be inherited from its parent. For the directives, if you used "-n" with %package, you'll need it again for these directives. You need to specify the name for the other directives, e.g., %pre and %post, if you use them in the subpackage.
See the RPM Guide section on subpackages for more information.
You can insert conditional statements. E.G., you can test if you are creating a binary for a certain architecture with:
%ifarch ARCHITECTURE_NAME
the negated version with:
%ifnarch ARCHITECTURE_NAME
or the more general conditional:
%if TRUE_OR_FALSE
There is an optional "%else" section; all of these are closed with "%endif".
Application Specific Guidelines
There are many application-specific guidelines that can help you (e.g., for specific programming languages, applications, libraries, and build systems). Many of them are listed as part of the Application Specific Guidelines of Packaging/Guidelines. Examples of application-specific guidelines are those for:
Failing that, some other ways of finding application-specific help are:
- The 'SEARCH' command on Fedoraproject.org.
- PackagingDrafts
- A Special Interest Group (SIG)
- Wiki pages prefixed with 'Packaging'
Miscellaneous hints
Try to write your scripts so that when upstream makes changes, the packaging is likely to work when you change the version number and reload the source file(s). For example, if it contains *.txt files with execute bits, instead of doing:
chmod a-x Filename1.txt Filename2.txt Filename3.txt
consider doing this, which will handle new filenames that use the same file naming convention:
chmod a-x *.txt
If you want to see lots of examples of scriptlets, you can show all the scriptlets on installed programs using:
rpm -qa --queryformat "\n\nPACKAGE: %{name}\n" --scripts | less
Packaging/FrequentlyMadeMistakes has information on frequently-made mistakes.
Don't try to interact with the user; RPM is designed to support batch installs. If an application needs to show a EULA, that needs to be part of its initial execution, not its installation.
You might not want to start services, because in a big install that could slow things down. If you install an init script, consider using chkconfig to arrange for the service to be started and stopped on the next reboot. Before uninstalling you should normally try to stop its services if it's running.
Uninstall should reverse most changes made during installation, but don't remove any user-created files.
Normally, if there are binary executables, a separate "debug" package is created with the symbols, and the symbols are stripped from the normal binary packages. If this shouldn't happen, you can disable the package-creation and stripping with:
%global _enable_debug_package 0 %global debug_package %{nil} %global __os_install_post /usr/lib/rpm/brp-compress %{nil}
To prevent stripping you may also need to do this in the %install section:
export DONT_STRIP=1
A way to check for the version of Fedora in a spec file for conditional builds is:
%if 0%{?fedora} <= <version>
(The ? causes the macro to evaluate to blank if %fedora is not defined, and this causes the end result to be "0", which is a number and thus ok, while not interfering with the result if there is actually a value for %fedora.)
Note that the previous trick DOES NOT work in Koji "scratch" builds - %fedora is set during the creation of a source RPM. (Thus, this trick does work in actual Koji builds as the system extracts sources from the source RPM and rebuilds the source RPM with the appropriate %fedora value.)
There are also some recommendations and controversial tricks on PackageMaintainers/Packaging Tricks.
GUI programs must have a desktop entry (so that people can invoke it from a graphical menu). The Fedora packaging guidelines discuss desktop files. See also the desktop entry spec (for .desktop files) and icon theme spec (for icon-related materials such as those in /usr/share/icon).
Older RPM documents
Some older documents about RPM have the most information, but some older documents make claims that are no longer true:
- rpm files are no longer placed in a shared /usr/src/redhat directory. This is an obsolete way of using rpm and not recommended; modern systems set a %{_topdir} instead like ~/rpmbuild.
- the %install process does not install files in their final location. Instead, it "installs" files to the buildroot.
- The "rpm" command no longer creates packages (e.g., "rpm -ba" was once legal). Use the separate "rpmbuild" program instead.
- Many historical specs use the "%define" command to define macros. However, "%define" creates a locally defined submacro within other macro definitions; this is very rarely needed, and using %define incorrectly can cause subtle bugs. For nearly all uses, use "%global" instead. (See PackagingDrafts/global_preferred_over_define.)
- The "BuildRoot:" value is now ignored.
Quick test with rpmlint
Before trying to build anything from it, you should run rpmlint on the spec file:
rpmlint program.spec
This will catch many errors early. If the reported error doesn't make sense, run it again with the "-i" option (this gives longer messages).
Generally, you should not have errors from rpmlint, but sometimes rpmlint is excessively noisy. The Fedora packaging guidelines explain which ones to ignore, e.g., ignore "no-packager-tag" and "no-signature" errors.
Creating RPMs from the spec file
Once you've create a spec file, say "program.spec", you can create source and binary RPMs by simply running this:
$ rpmbuild -ba program.spec
If this works, then your binary RPM files will be created underneath ~/rpmbuild/RPMS/ and the source RPM will be in ~/rpmbuild/SRPMS.
When things go wrong, you can "cd" into the appropriate directory and see what's left over. If you want to skip earlier stages, use the "--short-circuit" option; this is handy if you had a successful build, but have an error in the %install section. For example, to restart at the %install stage (skipping earlier stages), do this:
$ rpmbuild -bi --short-circuit program.spec
If you just want to create a source RPM (.src.rpm), do this in the SPECS directory:
rpmbuild -bs program.spec
This will create the source RPM in ~/rpmbuild/SRPMS. Creating only a source rpm (.src.rpm) is quite quick, because rpm simply needs to copy the .spec file and associated SOURCES files into a .src.rpm file. Creating a binary rpm typically takes much longer, because this requires running the %prep, %build, and %install scripts.
Testing RPMs you've built (including rpmlint)
Run rpmlint on the .spec files, generated binary RPM, and generated source RPM. Rpmlint works on .spec files, binary RPMs, and source RPMs, finding different things in each. You need to eliminate or justify rpmlint warnings before posting a package. If you are in the SPECS directory, do this:
$ rpmlint NAME.spec ../RPMS/*/NAME*.rpm ../SRPMS/NAME*.rpm
Normally rpmbuild will build a binary RPM with debugging information - this will handle that.
If you "cd" to the "~/rpmbuild/RPMS" directory, and then cd to the architecture subdirectory, you'll find some binary rpms. You can quickly see their files and their permissions by using rpmls (check to see that they are what you expect):
$ rpmls *.rpm
If those look okay, you can become root and try to install them:
# rpm -ivp XYZ1.rpm XYZ2.rpm XYZ3.rpm ...
Then, you can test them out. Use it a few different ways and see if it works correctly. If it's a GUI tool, make sure it shows up in the menu (if it doesn't, something is wrong with your .desktop entry).
You can uninstall packages later using:
# rpm -e XYZ1 XYZ2 XYZ3
If that works, you can use Mock to do a more rigorous test that you have accurate build dependencies. Basically, mock will create a nearly-empty environment and try to rebuild the package; if it fails, then you forgot to list something in a "BuildRequires:" statement. See Using Mock to test package builds for more information about how to use Mock; once your account is a member of the "mock" group, you can run commands like this to do local testing:
$ mock -r fedora-9-i386 rebuild path_to_source_RPM
If a mock build fails, or the resulting program doesn't work correctly, then you almost certainly have one or more missing BuildRequires packages.
Once Mock works on your system, you can use Koji (which uses Mock) to do builds on many different systems, some of which you may not have. PackageMaintainers/Join and PackageMaintainers/UsingKoji have more information about Koji. Once it's set up, you can test your source RPM on a variety of platforms by running commands like:
$ koji build --scratch dist-f9 path_to_source_RPM
You can replace dist-f9 with dist-f8, dist-f10, etc., to try other releases. Don't use "dist-rawhide", that's not really rawhide. Remember, the values of %fedora, %fc9, etc., will not be correct for a scratch build, so this won't work if your spec file does something different based on those values.
Your koji builds can only depend on packages that are actually in the TARGET distribution repository. Thus, you can't use koji to build for released distributions if your package depends on other new packages that Bodhi hasn't released yet. You can use koji to build for rawhide (the next unreleased version), even if it depends on other new packages, as long as the other packages were built in the CVS "devel" section as described below. If you need to build against a package that is not yet a stable released update, you can file a ticket with rel-eng at: https://fedorahosted.org/rel-eng/newticket and request that that package be added as a buildroot override.
Helpful tools
The "rpmdevtools" package has a number of helpful tools; "rpm -qil rpmdevtools" will show you what it installs. One particularly useful tool is rpmdev-bumpspec, which has this form:
rpmdev-bumpspec --comment=COMMENT --userstring=NAME+EMAIL_STRING SPECFILES
rpmdev-bumpspec will bump the release tag in the spec file(s), and add a changelog comment with the right datetime and version format. COMMENT should typically start with "- ".
Similarly, "yum-utils" has a number of yum-specific tools. "yumdownloader" is especially helpful; you can download the source RPM of a package by simply running "yumdownloader --source PACKAGENAME". You can then use "rpm -U SOURCEPACKAGENAME" to install the source files. E.G., "yumdownloader --source glib; rpm -Uvh glib*.src.rpm".
The auto-buildrequires package has a pair of nice tools for helping to figure out the proper BuildRequires entries. After installing this package, replace "rpmbuild" with "auto-br-rpmbuild" and you'll see an automatically-generated buildrequires list.
You might find RUST useful (GPL). It is "a drag & drop RPM creation GUI and a 'sandboxing' toolkit that allows you to do software installations within a chrooted environment and automatically generate RPMs from arbitrary source code, without ever seeing a spec file." If you're creating spec files, it can help you determine the %files. Note, however, that it does not create .spec files, nor does it create packages of adequate quality for the Fedora repository; it is primarily a tool for making quick-and-dirty binary RPM packages. (Note: it is no longer at "rusthq.com".)
Alien converts between package formats. It won't produce clean source RPMs, but converting an existing package might provide helpful information.
Guidelines and rules
When you create your packages, you'll need to follow the following rules and guidelines:
- How to join the Fedora Package Collection Maintainers - describes the process for becoming a Fedora package maintainer
- Packaging Guidelines
- Package Naming Guidelines
- Dist Tag Guidelines
- Package Review Guidelines
There are many official guidelines that will help you with specific circumstances (Java programs, OCaml programs, GNOME programs, etc.); the Packaging Guidelines include cross-references to those guidelines. You can also learn more from the SIGs and Package Maintainers sections. You can also see the list of all Wiki pages about Packaging to see if any apply.
Failing that, you might find some useful recommendations in the unofficial Packaging Drafts and Packaging Drafts To Do. These are unofficial, obviously. You might find ideas from SuSE, Debian, but distributions differ in their rules, so do not presume they can be used directly.
The .spec files that you create must be open source software, as noted in the CLA.
Maintaining the package
Once your package is accepted, you (or your co-maintainers) need to maintain it. See the Package update HOWTO and Package update guidelines for more information. If you update the version in multiple releases of Fedora, do it "backwards" in time, e.g., release for Fedora N, then once that's accepted, Fedora N-1 (the system presumes that later versions of Fedora have the same or later versions of programs).
Encourage the upstream developers to use standard source code release conventions. Using standard conventions makes packaging much easier. For more information, see:
- Releasing Free/Libre/Open Source Software (FLOSS) for Source Installation (a quick summary)
- GNU Coding Standards release process
- Software Release Practice HOWTO
- Filesystem Hierarchy Standard (FHS)
- Packaging Unix software
For more information
The Package Maintainers page links to many other useful pages, and the Package update HOWTO describes how to update an existing package you already maintain in Fedora.
For more information, outside of the Fedora Wiki, see:
- How to build RPM packages on Fedora - very brief run-through
- Packaging software with RPM (developerWorks) Part 1, Part 2, and Part 3
- Fedora Classroom had a IRC session on packaging and you can refer to the logs at https://fedoraproject.org/wiki/Building_RPM_packages_%2820090405%29
- Fedora Packager's Handbook
- When Sally met Eddie - a simple tale, but little detail
- Maximum RPM Book - most complete information, but in some cases old/obsolete
- RPM Guide, section on creating RPMs - this has lots of good information, and is slightly more up-to-date, but is a draft
- Developer's guide, section on building RPMs
- Creating RPMS slides from Guru Labs
- The fight, my first attempt to make a readable rpm package building introduction.
- RPM Tutorial (Fullhart)
- Cambridge RPM tutorial is a presentation on creating basic RPMs
- RPM HOWTO: RPM at Idle by Donnie Barnes
- RPM HowTo by Dawson
- SuSE build tutorial - but about SuSE, not Fedora. Cross-distribution package HOWTO has hints if you're building one RPM for many distributions.
- Mandriva Rpm HowTo (en) (alt) is an RPM tutorial, though for Mandriva (nee Mandrake). Note: In Fedora, do not recompress original tarballs, as Mandriva suggests, because that would change their cryptographic hashes.
- Creating Your Own Linux RPM's - The Initial Software Build is another brief intro, but it makes the point that "The process of building RPM's is much simpler than creating packages for Solaris... Fewer steps, and the ability to add all of your software information into one specification file, makes for a much tighter (and easier to modify or reproduce) software packaging system."
- All you need to know about RPM (more about installing packages than creating them)
- The rpm.org Wiki has some useful information, such as the list of known RPM problems
Note: The rpm5.org site has some documentation, but do not depend on it; that is the home of a fork of RPM maintained by Jeff Johnson. The RPM used by Fedora (and Novell/SuSE) is instead based at rpm.org. lwn.net has a brief article about this.
Traduzido por --Miguel Sousa 01:06, 22 December 2011 (UTC)

subset: commoncrawl


text:
Our tropical wood birds are hand carved from Hawaiian Albesia wood. Albesia wood is naturally light in color and ideal for painting detailed designs. This rapid-growing tree is termite and drought resistant, making it a smart alternative to traditional wood that takes years to regrow.
Bird is 15″ long, 19″ from tail to top of hanger
Sales tax
Except for deliveries within California, which are charged a 8.0% state sales tax, we do not collect sales tax on items purchased at TropicalShade.net. Any tax will be calculated at time of checkout.
For your convenience, when you pay by Visa, Discover, or Mastercard (we do not accept AMEX at this time), your order will be processed immediately for shipping within the normal lead times stated. If you wish to pay by personal check please call our Sales Staff at (858) 272-1598 for assistance. Orders placed by personal check will be processed after the check has cleared.Our Charge Policy
Because the majority of our products are special order, your credit card will be charged at the time that you place your order. If you have any questions or concerns regarding this policy, please call us at (858) 272-1598.Pricing & Availability
TropicalShade.net makes every effort to get your order to you as soon as possible. In-stock items are generally shipped within 24 to 72 hours. If there is a problem with your order you will receive an email stating more details. Most items are shipped UPS and generally take from 2 to 7 days to arrive, depending upon your location. Most products are in stock and ready to ship. Palapa and Tiki Hut kits are special order and may take up to 2 weeks to process for shipping.
We do stock the 6 ½', 8-Ft and 9-Ft diameter palapa umbrella kits and these sizes usually ship out within 24 to 72 hours.
Due to events beyond our control as well as glitches in the "web world" pricing and availability is subject to change without notice.Determining Lead Times
At TropicalShade.net, we understand that you want the right products, at the right price, at the right time.Keeping that in mind, we will respond to your inquiries about lead-time as soon as possible, usually within 48 hours.
Product Price, Description and Color Accuracy
While we take measures to ensure that our web site reflects accurate product information and pricing, sometimes an error can appear on the site. We are not responsible for misrepresentations or errors found on the site.Slight variance in wood hue, thatch and other related products is common. These materials are not synthetic and their variances add to the desired effect - a beautiful, authentic thatched structure and naturally tropical appearance. Throughout the lifespan of woven thatch, is a gradual change in color, beginning with a greenish/golden hue then to gold and finally to a subtle brown. Palm thatch is from Mexico and reed thatch is made in Africa.
Where applicable products are covered by the manufacturer's warranty. Regarding palapas, we cannot extend a guarantee to kits due to the fact that we have no control over the ground conditions, climatic changes, nor the abilities of the person who is building the palapa. Our experience in California coastal as well as desert areas of California, Nevada, and Arizona, is that properly assembled, the wooden frames last for many years. Our experience in the West Coast, indicates that the general life span of the woven palm (Baja) thatch is from 3 to 5 years and Fiji thatch generally lasts from 8 to 12 years or more. Palapa structural workmanship is guaranteed for 3 years if the palapa has been installed by our company; likewise Fiji thatch is guaranteed for 3 years and Traditional woven (Baja) palm thatch for 1 year. If needed, repairs or a new layer of thatch is dependent upon Tropical Shade Imports' discretion. Self installed products cannot carry our guarantees as there are too many uncontrollable factors that could affect the thatch in any given location (ie - method of installation, proper support to thatch, leaves falling on thatch, weather conditions, etc., etc.). We do, however, offer only the best products available and having been in business since 1986 has given us experience and the business wisdom to understand our customer needs.Most of our products are handmade, with an intended tropical or rustic appearance, they are nearly, but not exactly alike. Products, such as bamboo, matting, thatch, bar stools, tabletops, tikis, carved poles, fishnets and some others, are not guaranteed. We do, however, take care to only carry a quality product line and we maintain strict quality control on all products.
As we have no control over independent shipper schedules and occasional delays, we cannot guarantee an arrival date for your order.Order Status
If you have other questions regarding your order you can call us at (858) 272-1598 or email us at email@example.com. Otherwise, we will send you an update, with an invoice, as soon as we have received and processed your order. We will send a tracking code ASAP, as well.Tracking an Order
You will receive an email notification with shipper and tracking information once your order is shipped.Change or Cancel an Order
If your order has not been shipped yet, you may change or cancel your order at anytime. Once it has been shipped, you will be subject to our restocking fee and any shipping charges for any items that are not defective or damaged during shipping. Special or custom orders may only be cancelled within the first 24 hours of placing the order. No returns or exchanges are allowed on special or custom orders beyond the first 24 hours of placing your order.


text:
If get to learn the best and mechanics of online lottery games a lot more to win them, then read the article. This provide you tips to win a virtual instant lottery jackpot.
With the arrival of technology, many all is being done over the net. Many people are also now hooked up and very willing songs how to win Online lottery. Brace yourself and ready a concern . possibilities of holding the mega million dollars in your own hands.
Some stuff you to be able to be associated with as you thought about joining a lottery consortium. You want to aware of all costs and fees if any that 're a part of the pool. 2 questions an individual want must are simply how much and accomplish that " ?. Pengeluaran Macau will in order to know the amount you wish to be paying in and whether done on the weekly basis, biweekly basis or a monthly groundwork.
If you found a normal ticket, whose result date has passed a quite a while ago, sole way plus it really can get to search out about benefits is at the lottery results checkers. Congratulations, you don't require panic for having missed the dates when the Online lottery was drawn. Is actually always very common that the prize money of the lotteries without a doubt held up for a visit to come and claim, for years into the future.
Go along with rest in the steps shown on the website. This will hold a verification step wherein a code is shown to finally key through. Your next step is to see the processing and signals that tell you that you happen to be included globe drawing. Get the dates for the drawings, and the number of winners techniques and what their prizes are. You able to compare and contrast your ticket information on the webpage.
But, in my own experience,not only will most people NEVER win any significant money playing the lottery, most will pay out far more than they ever win, (or can afford) chasing the dream.
Before I purchase any product or join any site, the very first thing that I now in order to use look for a review or scam directory of that product or site. I don't read just one associated with these and and then make my decision-making. I read all of them accessible. Write out a connected with your questions before begin reading. An individual do your reading, make sure that each of your questions gets helped with. Check off the question as soon as locate the fix. Don't stop reading until each question has been answered. Demonstration gotten every one of the answers, you'll be in a significantly better position to discover the lottery pool that will be the best for.


text:
Welcome to Phlox WP Theme – Free Demos. This is your first post. Edit or delete it, then start blogging!
One Response
A WordPress Commenter Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.


text:
The personal information you submit to us will never be shared, sold, or disclosed to third parties.Your sales history will never be disclosed to third parties for any purposes.
We use the latest security and encryption technology to protect your credit card details and other information. All orders placed through the shopping cart are made using secure server software (SSL). All credit card details are truncated and only recorded by our financial institution. We hold no full credit card details.


text:
- Original, one of a kind AI generated artwork.
- Fine and durable wooden floating frame.
- Made in the USA.
- Free shipping.
- Verisart Certificate of Authenticity.
- High-resolution digital file of the artwork.
We sell each artwork just once. After completing your order, we will create the artwork in the size and framing option you chose and ship it to you. The artwork will be marked as "Sold", and no one else will be able to order it.
If your artwork(s) arrive damaged or are different to what you ordered, you may submit a request for a refund within the following 90 days. Send your request to firstname.lastname@example.com along with your order # and a photo of the issue.
We sell one of a kind artworks made to your specification, therefore, subject to applicable law, ART AI will not provide a refund if your dissatisfaction with the order is due to a mistake on your part or because you have changed your mind.
We start working producing the artworks as soon as we receive your order, so unfortunately we are unable to take cancellation requests.
Own not just your original print, but the artwork itself! If choosing to include the image file, you will receive a high resolution digital file of your artwork to use as you wish, as long as it's for personal use (contact us for commercial use).
Contact us for commercial use e.g. album/book covers.


text:
Tutoring that your child will love
(but not as much as you will!)
Save time
We do everything for you. Book your first lesson in 3 minutes and we'll have the perfect tutor lined up for you within 48 hours.
Love your tutor (or it's free)
Your first lesson has our 100% happiness guarantee; so if you aren't convinced the tutor we select is the one for you it's free.
Get complete flexibility
Lessons in your home when they suit you or online anytime – 7 days a week, 7am to 8pm. No contracts or minimum commitments.
Regular progress updates
We keep you in the loop at all times. We'll send you feedback after each lesson and a detailed progress report every 10.
Access to the best tutors in Dharruk
Our tutors are the kinds of tutors we would want working with our own kids. All screened, reference-checked and holding WWCCs.
Undivided one on one attention
Individualised learning that is tailored to your child. No boring software or workbooks – each lesson is customised for them.
Or request a callback from one of our education experts!
We've helped hundreds of happy families in Dharruk completely transform their child's academic journey
(These are all legitimate verified reviews from Google and Facebook.)
At Alchemy we care about so much more than just marks
Your child will grow in confidence, do better at school and love the learning experience
We've been providing in-home and online tutoring in Dharruk since 2005, working to help students perform at their very best. Whilst our families continue to witness amazing academic results what really sets us apart is our focus on bringing out the best in the students we work with and showing them what they are truly capable of.
Alchemy is the medieval science of turning base metals into Gold. It is taking the ordinary and making it extraordinary; something our tutors do with our students every single day.
This is at the heart of what we do: mentoring and challenging students to perform at a higher level than they ever thought possible.
Experience the Alchemy difference for yourself by getting started with an accredited Alchemy tutor in Dharruk today.
K-12 English Tutoring
Expert English tutors in Dharruk to help your child perform at their very best. Reading, writing and expressing ideas effectively form the basis of all school subjects; so having an English tutor will make a huge difference to their confidence and attitude towards learning.
K-12 Maths Tutoring
Maths is all about foundations; so ensuring the correct foundations are in place is crucial for any successful student. From Kindergarten through to year 12, we have the best maths tutors in Dharruk ready to support both struggling and high performing students.
K-12 Exam Preparation
We specialise in HSC, Selective School and NAPLAN preparation for students of all grades and abilities. Your tutor will work carefully with your child, teaching in their unique learning style and showing them how to best prepare for and approach upcoming exams and assessments.
All other subjects
We have incredible tutors in all subjects from K-12, including Sciences, Histories, Humanities and most electives. We also offer general support tutoring – for students that don't need specific help with a subject but would instead benefit from an experienced mentor in general.
Or request a callback from one of our education experts!
The best hand-selected tutors in Dharruk
Our tutors are chosen not just for academic excellence but for being role models and mentors that have the ability to inspire the young people they work with.
Every tutor is hand selected, interviewed one-on-one and double reference checked before joining our team.
Our tutors come from a diverse background, from high performing University students to retired teachers – and all go through our comprehensive training and mentorship program to ensure they adhere to our high standards.
We channel more than a decade of experience into equipping our tutors to be the best in Dharruk , giving them all the support and resources they need to bring out the gold in every student they work with.
All Alchemy tutors hold Working with children checks that we manually verify ahead of their first session. Meet some of them here.
Lessons when and where they suit you
Lessons in your home
No need to fight for parking in Dharruk or battle to find a sparking spot.
We offer the best private tutoring in Dharruk right in your home at a time that works for you.
We offer one-on-one tutoring 7 days a week, before or after school and on weekends. Your tutor will come at the most convenient time for your child.
We make things as easy as possible for you by pairing you with an accredited local tutor that knows Dharruk just as well as you do!
Lessons online
Your child can connect with their tutor online in our custom built online classroom.
Any device – no app download required. They'll use video chat, a shared whiteboard and interactive features to make the experience as immersive as possible.
Online lessons can happen at any time, from anywhere. You'll also get access to a far greater network of Alchemy tutors offering a broad range of experience and knowledge.
Or request a callback from one of our education experts!
Affordable one-on-one tutoring for Dharruk families
Anywhere, AnytimeIn Your Home
In-Person Lessons✓ First lesson covered by our 100% happiness guarantee – if you aren't happy after the first lesson it's on us
✓ No contracts. prepayments or hidden fees – the price you see above is what you will pay
✓ The world's easiest payment system – your payment information is stored securely and charged 24 hours after each lesson
✓ No charge for missed lessons – just give your online tutor at least 24 hours notice before a scheduled lesson
Book today and get started with the perfect tutor in Dharruk
Experience the Alchemy difference for yourself!
Check out how we supported students through Covid on SBS News
Or request a callback from one of our education experts!


text:
Squids and Stingrays Stitch Markers
Squids and Stingrays Stitch Markers
This listing is for one set of stitch markers. Each set comes with 6 markers.
Each marker is handmade by me one at a time using snag free soldered sterling silver plated jump rings and sterling silver plated head and/or eye pins.
There are several types of ring available. Small ring markers will fit up to a US size 8 (5mm) needle comfortably, and the thin rings will help mark your place without creating ladders in even the finest work. Large rings have an interior diameter of 8mm, and will fit up to a US 11. Lobster claws are perfect for progress keepers, to mark rows, or to use as removable markers in crochet. Leverbacks are perfect for progress keepers, to mark rows, or to use as removable markers in crochet. They can also be used as a standard stitch marker, it's thin profile lending itself perfectly to marking your place without causing laddering.
Bead materials in this set:
Charms: Lead free Zinc
Glass Seed Beads


text:
Date and Time:
11:00 am - 3:00 pm on 06 May 2024
Obubu Tea Farm and Factory
Here at Obubu Tea you have a rare opportunity to experience Japanese tea culture and take a look behind the scenes of a local tea farm in Wazuka, Kyoto – the region, known for premium Japanese tea. By joining our Japanese Tea Tour both tea lovers and tea professionals will be able to witness long-lived Japanese tea traditions and enhance their understanding of Japanese teas.
The tour will involve a visit to some beautiful tea fields in the surrounding mountains to learn about tea farming as well as a visit to a real tea factory to learn about Japanese tea processing followed by an interactive tea tasting session of a wide palette of our teas: from everyday Houjicha and Genmaicha to premium Sencha and Matcha.
We are looking forward to welcoming you on an unforgettable adventure to tea sites and flavours!
Bookings are closed for this event.


text:
Hair Color | #33B Color |
Hair Length |
Texture | Straight |
Type | No |
Hair Weight | 95-100g/pc |
Hair Weft | Machine Double Weft |
Quality | High Quality 100% Virgin Hair, Tangle Free, No Shedding |
Items /Package: | 4 bundle/Pack |
Can Be Bleached/Dyed | Yes |
Shipment | USPS Orvernight 2-3 Business Days; USPS 3-7 Business Days; DHL/UPS 5-10 Business Days. |
Our survey found that Body wave and straight hair is the most popular hairstyle. Body wave is one kind of loose curl hairs that result in wave pattern. The section of hair is wrapped around a big roller to create a soft and natural-looking wave, that is how body wave be made of. The rollers could be in different size to make different curls. Straight hair reflects the most sheen. It is also the most resilient hair of all of the hair types. It is hard to damage and next to impossible to curl this hair texture. Because the sebum (natural oil produced in the sebaceous glands of the scalp) gently works its way from the scalp to the ends without the interference of curls or kinks, it is the most oily hair texture of all.
A small amount of hair loss during wearing is norma, it is not a quality problem. Some reasons in details, just like, combing the wig in a rude way after clean it. Or, you just forget to dry the wig before comb it. Sometimes, customers are not willing to spend an extra on a special care for their wigs, however, they need to know applying extremely oily or greasy hair care products to the hair and washing the wig with a not appropriate hot water will cause wig shedding. Your behaviors may bring wig shedding to yourself.
Yes, the hair can be dyed/bleached to any color you want, except #613. As a general rule, it is easier to darken the hair than to lighter the hair. Highly recommend to let the Professional hair dresser do the color things, improper dying will ruin the hair. DON'T dye or bleach hair too frequently, because that will damage the hair badly.
What is a Pre-plucked Hairline? A pre-plucked hairline is a natural hairline with right amount of hair along the hairline area which looks like the human hair wig is growing from the scalp. Usually a human hair wig without plucked hairline is always dense and thick at the hairline area. There is a lot of work to be done if you want to get a more natural look after you receive the human hair wig. But with the pre-plucked hairline. The hair along the hairline area are already plucked before shipping which gives it a more natural look.
Subscribe Today
2805 Peterson Place, Norcross, Georgia (GA) 30071 United States
© 2023-2025 Beautyforever Mall All Rights Reserved.