User:Hrauch

Useful Notes And Links

Valid Licenses (Specifically For/Within openSUSE)

Standard RPM Macros (And Their Documentation)

See the section RPM Book: Inside The Spec File (provides links to all common macros) for details.

Non-Standard RPM Macros (And Their Documentation)

Rationale: I've always asked myself: "Where do the non-standard RPM macros come from?"

RPM macros per programming language/build tool/... are available via packages whose name contains the name pattern rpm-macros, of which the packages for Python and systemd are already (pre)installed - at least on my LinuxONE instance.

Each installed rpm-macros package stores the macros (the implementation thereof) in the subdir /usr/lib/rpm/macros.d; the corresponding documentation is stored in /usr/share/doc/packages/<name>-rpm-macros, usually in a README.md file.

Home Project And Repo Setup

Not only the distribution release repo, e.g. Tumbleweed, but also the architecture-specific repo, e.g. zSystems are required (in case you forget to specify the latter, the pubkeys of the architecture-specific repo are missing, leading to no pubkey errors for each downloaded RPM during the build, in case you build your branched package in a (local) chroot.

Sure, one could add --no-verify to the osc build command, but this is definitely not a clean solution.)

Furthermore, at least for official repos, the repo name == project name, EXCEPT that the : are replaced by _

In your personal project's meta info, there should be - at least - TWO repos specified (use osc meta prj from within your personal project's working copy to verify):

one for the release, e.g. Tumbleweed
one for the architecture, e.g. zSystems

And within each repo definition, a path pointing to the corresponding factory project (more precisely, it's standard repo) AND the corresponding (CPU) architecture.

For the release repo definition, the default path definition is the (general) factory project, along with its snapshot repo.

Here's the complete example (XML markup):

<project name="home:<user_name>">
  <title/>
  <description/>
  <person userid="<user_name>" role="maintainer"/>
  <repository name="openSUSE_Tumbleweed">
    <path project="openSUSE:Factory" repository="snapshot"/>
    <arch>x86_64</arch>
    <arch>local</arch>
  </repository>
  <repository name="openSUSE_Factory_zSystems">
    <path project="openSUSE:Factory:zSystems" repository="standard"/>
    <arch>s390x</arch>
  </repository>
</project>

Due to the fact that there is more than one repo specified, one has to specify BOTH the repo name AND the architecture when running osc build, like this for the very first build after a fresh osc checkout:

osc build openSUSE_Factory_zSystems s390x --vm-type kvm

In case one does NOT specify the repo/architecture combo, the first repo is used/taken.

For instance, osc repourls returns the following output:

                                                                                                       
https://download.opensuse.org/repositories/home:/<user_name>/openSUSE_Tumbleweed/home:<user_name>.repo
https://download.opensuse.org/repositories/home:/<user_name>/openSUSE_Factory_zSystems/home:<user_name>.repo

Submit Request Propagation (Quality Assurance)

home (personal) project => "devel project"<ref>IMPORTANT: A "devel project" is not just a <emph>development</emph> project, but rather - and that distinction is important - a development project for the Factory. It's thus a prerequisite project which is necessary for software that's supposed to be considered for the next (rolling) Tumbleweed release.</ref> => factory

where

"devel project" is e.g. devel:languages:D, M17N:Fonts, ...

Thus, in case you decide to branch a package, ALWAYS create branches from the corresponding "devel project".

Branching/Branch Creation Recommendations

It's better to use osc bco in order to create a new branch (as it automatically creates the branch in one's home project, e.g. in my particular case home:hrauch) instead of branching via OBS's web UI, because the aforementioned osc command also takes care of proper branch naming conventions and also removes the branch once a SR (Submit Request) has been accepted.

github Clones/Tarballs

Use

osc service ra obs_scm
osc service ra set_version

(requires a corresponding _service file (e.g. one provided by the gdmd package).

Q & A on the Usage of the OBS/`osc` Combo

Why does OBS (and thus in turn, also osc) implement its own versioning system (whose implementation seems to be very close to SVN - concerning the VCS commands and version numbering)?

Answer: Because at the time OBS was originally conceived/implemented, SVN either didn't exist yet or was in relatively early stages (with regard to implementation). Back then, there was only CVS in the open source world.
When fetching the current master (branch) sources via e.g. either the obs_scm module or the tar_scm module (obs_scm's predecessor), why do I need (additional) extract and recompress steps in the _services file?

Answer: Because neither one of the two aforementioned modules yields a git clone-/svn checkout-like result (i.e. individual source files), but rather causes a tarball to be created (and stored). The extract and recompress steps are needed in oder to obtain particular build and/or packaging files needed by the corresponding build/packaing systems - and then recreate (compress) the sources again - thus (re)creating the original tarball. (Which is an implicit necessity/requirement of the openSUSE build server setup due to intenet access not being available (blocked by firewall rules?).
Why is it a requirement that tarballs be stored as part of a package? Ain't that redundant (considering that tarballs are - usually - centrally available via e.g. Github, Gitlab, Sourceforge, ...)?

Answer: Specifically with regard to openSUSE builds, it's a security requirement that the build server(s) can't access the internet while builds are performed. Thus, tarballs must either be fetched (in case of a master branch) or already be present before the actual build starts. Once the build starts, all required sources have to be available to the build server(s) - i.e. stored locally; "self-contained", so to speak.

Useful Links