Code Monkey home page Code Monkey logo

common's Introduction

Developer tooling framework for Clear Linux

This repository includes scripts, configuration files, and makefiles that enable Clear Linux developers to manage, maintain, and validate changes to distro packages and projects that are maintained in git repositories. Development workflows are makefile-driven, and there is a particular focus on building Clear Linux packages.

Getting started

First steps

  • Boot a Clear Linux system.
  • As the root user, install the os-clr-on-clr bundle:
# swupd bundle-add os-clr-on-clr

Automated setup

Download the user setup script and run it on your Clear Linux system as an unprivileged user.

$ curl -O https://raw.githubusercontent.com/clearlinux/common/main/user-setup.sh
$ chmod +x user-setup.sh
$ ./user-setup.sh

After the script completes, make sure to logout and login again to complete the setup process.

The script accepts several options, or no options at all. The options are documented in the script's --help output. Note that if you are supplying any of the three Koji cert options (-k, -s, or -c), the other two options must be supplied as well.

If you do not wish to run the user-setup script, see the "Manual setup" section below for hints about how to initialize the tooling workspace.

Example usage

Build RPMs for a package

In every repo cloned to the packages tree, several make commands are available for managing a given package. For example, you can build source, binary, and debuginfo RPMs for a package by running make build.

To build RPMs for the coreutils package, do the following:

$ cd packages/coreutils
$ make build

The results of make build are stored in the results directory within the repo.

Run make help to see other make commands that are available to work with the package.

Keep up-to-date with latest changes

Due to the frequent release cadence, you may wish to keep repos in the workspace up-to-date with the most recent changes. To do so, run make pull in the toplevel directory of the workspace. Assuming your current working directory is a package repo, do:

$ cd ../..
$ make pull

A make pull will display the diffstat for each project and package repo with changes since you last updated the workspace.

If new packages were added to the distro since the last update, clone the new package repos by running make clone.

Run make help to see other make commands available to run at toplevel.

Autogenerate a new package

The toplevel makefile provides a make autospecnew command that can automatically generate an RPM package by using the autospec tool. You must define the URL and NAME variables for the command. URL is a URL to the package's upstream source tarball, and NAME is the name of the package you wish to create.

$ make autospecnew URL="..." NAME="example-pkg"

Whether or not autospec successfully creates the package, a new package directory will be created to continue work on it. In the example below, a missing build dependency is added, and then autospec is re-run.

$ cd packages/example-pkg
$ echo missing-build-req >> buildreq_add
$ make autospec

Please see https://github.com/clearlinux/autospec#common-files for documention on buildreq_add and the other files autospec uses during the build process.

Bump the release number for a package

If you simply need to increment a package's release number and rebuild the package, a make bump command is available for this purpose.

$ make bump
$ make build

Update the release version for a package

If you have an update release version for a package, you can change the url for the new release in the package/example-pkg/Makefile. After modifying the new url, run make autospec again to fetch the new package and rebuild.

$ make autospec

Other topics

Customizing the mock config

In the past, the various make commands that call mock required a mock config installed at /etc/mock/clear.cfg. However, at present, the commands will instead use the mock config within this repo (conf/clear.cfg).

If you wish to use a custom mock config, you must override the MOCK_CONF variable to specify a different value to pass to mock's -r option. The value is either a full path that ends with .cfg, or a config NAME installed at /etc/mock/<NAME>.cfg. You can override the MOCK_CONF config variable by redefining it in Makefile.config.site_local, which must reside at the toplevel directory in this repo.

For example, to retain the old behavior of mock using /etc/mock/clear.cfg, add this line to Makefile.config.site_local:

MOCK_CONF = /etc/mock/clear.cfg

If Makefile.config.site_local doesn't exist already, create it.

Manual setup

See the Manual setup documentation.

common's People

Contributors

ahkok avatar alexjch avatar bryteise avatar busykai avatar bwarden avatar clrbuilder avatar clsulliv avatar djklimes avatar fenrus75 avatar gtkramer avatar gvancuts avatar insilications avatar mdhorn avatar miguelinux avatar phmccarty avatar puneetse avatar rossburton avatar santoshkumarlaxminarayanrai avatar thiagomacieira avatar tmarcu avatar tripzero avatar wayne0811 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

common's Issues

os-clr-on-clr Bundle too large by 10811M

os-clr-on-clr Bundle too large by 10811M

I use Debian and other Linux and FreeBSD but this is too much 10811M of download. Don't follow the steps of Yarn packaging for Npm their. Your bundles or not meaningful what if I only need just one package from your bundle. I need very simple things nginx redis mariadb php nothing else but when I try to install how many more package I installed to the system.

I know clear linux is not for ordinary users why do you make them public

fatal: unable to access 'https://github.com/clearlinux-pkgs/compat-libsigc++-soname20/': The requested URL returned error: 400

After do

$ make clone_linux

From this kernel development guide, got this error:

fatal: unable to access 'https://github.com/clearlinux-pkgs/compat-libsigc++-soname20/': The requested URL returned error: 400

The file clearlinux/projects/common/packages references the wrong name to the package. The correct name is compat-libsigc-plus-plus-soname20.

To fix, locate the line with compat-libsigc++-soname20 in the file and rewrite to the correct name.

Run make inside the clearlinux folder to continue the process of cloning.

mv debuginfo makes build fail if no debuginfo RPMs were generated

INFO: Results and/or logs in: results/
Finish: run
mkdir -p results/logs results/debuginfo
mv results/*.log results/logs
mv results/*-debuginfo*.rpm results/debuginfo/
mv: cannot stat 'results/*-debuginfo*.rpm': No such file or directory
make: *** [../common/Makefile.common:96: build] Error 1

Not all components provide a debuginfo package. Perhaps using -f with mv would be more appropriate so make doesn't fail here.

start_qemu.sh: also allow graphics emulation

Currently the script explicitly disables support for graphics, via:

...
    -vga none -nographic \
...

However, there does not seem to be any particularly good reason not to allow graphics via
something like

    -vga std \

The user/developer should be able to chose the type of emulation via a command line option (something like --enable-graphics). Or there could be two different scripts.

I tested this with an image I mixed:

 "Bundles": [
  "os-core",
  "os-core-update",
  "desktop-autostart",
  "kernel-kvm",
  "sysadmin-basic"
 ],
...

and manged to boot the resulted image (with the modified script) into a desktop environment.

install-local: don't install <package>-dev

"make install-local" is a very useful and convenient way to test built RPMs locally, it installs all built RPMs on the built machine. However, a better granulation would be nice, in particular an additional "make" target that excludes package-dev RPMs.
The reason is that by default .so files/symlinks are installed in -dev RPM packages and not in the -lib RPMs. Unfortunately, there are some apps/utilities that need the .so files at run-time. So these utilities would run just fine with the current "make install-local" on the local machine. But later on, once you build an actual bundle with the RPMs, you may get errors due to missing .so files as generally bundles do not contain -dev RPMs and hence do not contain .so files. Therefore by not installing -dev RPMs we would detect the missing .so files much sooner (and allow user to rebuild the RPMs with .so files in -lib packages instead.)

In principle, the new "make" target could/should exclude all RPMs that don't make it into the bundle.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.