[Qa-jenkins-scm] [Git][qa/jenkins.debian.net][master] Spelling corrections
Holger Levsen (@holger)
gitlab at salsa.debian.org
Sun Jun 20 13:33:25 BST 2021
Holger Levsen pushed to branch master at Debian QA / jenkins.debian.net
Commits:
eb492694 by Roland Clobus at 2021-06-20T14:33:18+02:00
Spelling corrections
Signed-off-by: Holger Levsen <holger at layer-acht.org>
- - - - -
4 changed files:
- CONTRIBUTING
- INSTALL
- README
- TODO
Changes:
=====================================
CONTRIBUTING
=====================================
@@ -1,4 +1,4 @@
-== disclaimer
+== Disclaimer
We are happy to take *untested* patches. Patches are reviewed before merging
but no one has a complete test environment for all jobs, so please publish
@@ -7,7 +7,7 @@ your well meant and untested patches as soon as they are ready!
=== Contributing code to this project
It's helpful to track fixes or new features via wishlist bugs against the
-'jenkins.debian.org' package, eg with the 'reportbug' tool ('devscripts' package).
+'jenkins.debian.org' package, e.g. with the 'reportbug' tool ('devscripts' package).
The BTS will ensure the developers' mailing list
qa-jenkins-dev at lists.debian.org
is notified.
@@ -36,8 +36,8 @@ One possible workflow:
=== Contributing bugs to other projects
-Another very useful type of contributions are filing bug reports based
+Another very useful type of contributions is filing bug reports based
on jenkins job runs. Another useful kind of contribution would be to
-improve the documentation, eg to better describe how to debug stuff.
+improve the documentation, e.g. to better describe how to debug stuff.
// vim: set filetype=asciidoc:
=====================================
INSTALL
=====================================
@@ -78,7 +78,7 @@ cd jenkins.debian.net
The jenkins jobs are configured to send email to 'jenkins+$IRC_CHANNEL' (like 'jenkins+debian-qa'), this is parsed by a script ('/srv/jenkins/bin/email2irc.sh') run through 'procmail' which then in turn notifies 'kgb-client', which notfies 'kgb-server'(s) on the internet, which are the bots notifying the IRC channels.
-The Jenkins EMail notification plugin is used as its state tracking is best (and the Jenkins IRC plugin is way too powerful).
+The Jenkins Email notification plugin is used as its state tracking is best (and the Jenkins IRC plugin is way too powerful).
=== Installing vncdotool
@@ -89,7 +89,7 @@ cd vncdotool/
python setup.py install
----
-=== adding new agents to jenkins
+=== Adding new agents to jenkins
Process to follow to add a new node to jenkins:
=====================================
README
=====================================
@@ -18,11 +18,11 @@ The (virtualized) hardware is sponsored since October 2012 by https://www.ionos.
Some stats are available using link:https://jenkins.debian.net/munin/jenkins-month.html[munin-plugins for jenkins].
-Three persons have shell access (incl. root) to the machine: link:mailto:holger at layer-acht.org[Holger Levsen], link:mailto:helmutg at debian.org[Helmut Grohne] and link:mailto:mattia at debian.org[Mattia Rizzolo]. All of them have also access to the web intereface, where tasks like stopping and scheduling job runs can be done, also they have the rights to edit the jenkins scripts (i.e. what jenkins executes) directly, though this is limited to cases like firefighting (IOW deploying changes via the git repository are the norm). The deploying of changes is still limited to people with root powers.
+Three persons have shell access (incl. root) to the machine: link:mailto:holger at layer-acht.org[Holger Levsen], link:mailto:helmutg at debian.org[Helmut Grohne] and link:mailto:mattia at debian.org[Mattia Rizzolo]. All of them have also access to the web interface, where tasks like stopping and scheduling job runs can be done, also they have the rights to edit the jenkins scripts (i.e. what jenkins executes) directly, though this is limited to cases like firefighting (IOW deploying changes via the git repository are the norm). The deploying of changes is still limited to people with root powers.
== Getting involved
-jenkins.debian.net is a QA resource for the whole Debian project. Please contact us (via #debian-qa on IRC or via the debian-qa mailinglist) If you / your project is interested to run tests in this setup!
+jenkins.debian.net is a QA resource for the whole Debian project. Please contact us (via #debian-qa on IRC or via the debian-qa mailinglist) if you / your project is interested to run tests in this setup!
If you notice some jobs has problems and you want to find out why, read <<debug,debug certain jobs>> to learn how to do debug jobs locally.
@@ -30,7 +30,7 @@ include::CONTRIBUTING[]
== Notifications
-There are two types of notifications being used: email and IRC. At the end of each builds console log it says to where notifications have been sent. An address of the form 'jenkins-foo' means an IRC notification has been sent to the #foo IRC channel.
+There are two types of notifications being used: email and IRC. At the end of the console log of each build it says to where notifications have been sent. An address of the form 'jenkins-foo' means an IRC notification has been sent to the #foo IRC channel.
All job result notifications should be sent to https://lists.alioth.debian.org/mailman/listinfo/qa-jenkins-scm and optionally to other recipients as well.
@@ -72,9 +72,9 @@ Installation tests inside chroot environments.
* $distro-install jobs (and $distro-install+upgrade jobs):
** `debootstrap $distro`, install a *$set_of_packages* (and upgrade to *$2nd_distro*)
-** severeal sets with different packages exist.
+** several sets with different packages exist.
*** install is done with `apt-get install`, except for 'develop' where `apt-get build-dep` is used to install the build dependencies of these packages.
-** Then there are also all the corresponding upgrade jobs, eg 'chroot-installation_buster_install_gnome_upgrade_to_bullseye'
+** Then there are also all the corresponding upgrade jobs, e.g. 'chroot-installation_buster_install_gnome_upgrade_to_bullseye'
=== Debian Edu related jobs
@@ -89,8 +89,8 @@ Installation tests inside chroot environments.
** 'chroot-installation_$(distro)_install_$(education-metapackage)':
*** tests apt installation of a metapackage in a specific distro.
* 'edu-packages_$(distro)_$(src-package)':
-** builds one of the six debian-edu packages ('debian-edu', 'debian-edu-config', 'debian-edu-install', 'debian-edu-doc', 'debian-edu-artwork', 'debian-edu-archive-keyring' on every push to it's git master branch
-** and whenever 'debian-edu-doc' is build, https://jenkins.debian.net/userContent/debian-edu-doc/ gets updated automatically afterwards too.
+** builds one of the six debian-edu packages ('debian-edu', 'debian-edu-config', 'debian-edu-install', 'debian-edu-doc', 'debian-edu-artwork', 'debian-edu-archive-keyring' on every push to its git master branch
+** and whenever 'debian-edu-doc' is built, https://jenkins.debian.net/userContent/debian-edu-doc/ gets updated automatically afterwards too.
=== qa.debian.org related jobs
=====================================
TODO
=====================================
@@ -10,17 +10,17 @@ ToDo for jenkins.debian.net
== About jenkins.debian.net
-See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian.net"] for a general description of the setup. Below is the current TODO list, which is long and probably incomplete too. The links:https://jenkins.debian.net/userContent/contributing.html[the preferred form of contributions] are patches via pull requests.
+See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian.net"] for a general description of the setup. Below is the current TODO list, which is long and probably incomplete too. The link:https://jenkins.debian.net/userContent/contributing.html[the preferred form of contributions] is patches via pull requests.
== Fix user submitted bugs
-* There are link:https://bugs.debian.org/jenkins.debian.org[bugs filed against the pseudopackage 'jenkins.debian.org'] in the BTS which would be nice to be fixed rather sooner than later, as some people actually care to file bugs.
+* There are link:https://bugs.debian.org/jenkins.debian.org[bugs filed against the pseudopackage 'jenkins.debian.org'] in the BTS which would be nice to be fixed rather sooner than later, as some people actually cared to file bugs.
== General ToDo
* replace amd64 in scripts with $HOSTARCH
* extend /etc/rc.local to do cleanup of lockfiles
-* explain in README how to write jobs, eg which pathes are on tmpfs
+* explain in README how to write jobs, e.g. which paths are on tmpfs
** EXECUTOR_NUMBER for X
* run all bash scripts with set -u and set -o pipefail: http://redsymbol.net/articles/unofficial-bash-strict-mode/
* teach bin/chroot-*.sh and bin/d-i_build.sh how to nicely deal with network problems… (as both reproducible_build.sh and schroot-create.sh do)
@@ -35,7 +35,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
* blog post when done
* setup netconsoles:
----
-<guerby> | Ramereth, h01ger netconsole is about the ony way to diagnose this kind of issue in my experience
+<guerby> | Ramereth, h01ger netconsole is about the only way to diagnose this kind of issue in my experience
<guerby> | h01ger, setup rsyslogd on one of the gccserver then it's just one modprobe netconsole
<guerby> | h01ger, since the machine are on the same LAN
<guerby> (if not on the same LAN, modprobe netconsole netconsole=+@${IPSRC}/eth0,514@${IPRSYSLOG}/${GWMACADDR} )
@@ -77,9 +77,9 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
*** new result: NBIFA - no .buildinfo file available
* another job to import data on jenkins (into postgresql)
* schedule/trigger rebuilds on osuosl173, using data in postgresql|sqlite on ionos7
-** scheduler unclear, we'll first try to rebuild everthing in current sid (and bullseye and buster eventually) once, and then, once we've done this, we want to do this X times again. (and there will be ftbfs etc, not causing rebuilds immediatly.)
+** scheduler unclear, we'll first try to rebuild everything in current sid (and bullseye and buster eventually) once, and then, once we've done this, we want to do this X times again. (and there will be ftbfs etc, not causing rebuilds immediately.)
** rebuild amd64 only at first (but arm soon after), but .buildinfo files for all Debian architectures should be tracked in the db
-** also treat the base suite archive and its security, update and backports archives seperatly
+** also treat the base suite archive and its security, update and backports archives separately
*** store hash of processed Packages file and only process a Packages file if it has an unknown hash -> good for suites which are not updated often
*** ignore security archive as those .buildinfo files are not published yet (#862538)
** good examples: piuparts (arch and any), d-e-i (udeb), d-e-c (all only), emacs (epoch) libunibreak (binNMU)
@@ -142,9 +142,9 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
** link pkg sets and issues, that is: at least show packages without issues on pkg set pages, maybe also some issues which need actions (like uninvestigated test failures)
** notes related:
*** #786396: classify issue by "toolchain" or "package" fix needed: show bugs which block a bug
-*** new page with annoted packages without categorized issues (and probably without bugs as only note content too, else there are too many)
+*** new page with annotated packages without categorized issues (and probably without bugs as only note content too, else there are too many)
*** new page with packages that have notes with comments (which are often useful / contain solutions / low-hanging fruits for newcomers)
-*** new page with notes that doesnt make sense: a.) packages which are reproducible but should not, packages that build but shouldn't, etc.
+*** new page with notes that doesn't make sense: a.) packages which are reproducible but should not, packages that build but shouldn't, etc.
*** new page with packages which are reproducible on one arch and unreproducible on another arch (in the same suite, so unstable only atm)
*** new page with packages which ftbfs on one arch and build fine on another arch (in the same suite, so unstable only atm)
*** new page with packages which ftbfs in testing but build fine on sid
@@ -161,7 +161,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
** pkg sets related:
*** add new pkg set: torbrowser-build-depends
*** fix essential set: currently it only has the ones explicitly marked Essential:yes; they and their dependencies make up the full "essential closure set" (sometimes also called pseudo-essential)
-*** replace bin/reproducible_installed_on_debian.org with a proper data provider from DSA, eg https://salsa.debian.org/dsa-team/mirror/debian.org/blob/master/debian/control
+*** replace bin/reproducible_installed_on_debian.org with a proper data provider from DSA, e.g. https://salsa.debian.org/dsa-team/mirror/debian.org/blob/master/debian/control
** a reproducible_log_grep_by_sql.(py|sh) would be nice, to only grep in packages with a certain status (build in the last X days)
** database issues
*** stats_build table should have package ids, not just src+suite+arch as primary key
@@ -202,7 +202,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
* make systems send mail, use port 465
* rename all the nodes from $HOSTNAME to $HOSTNAME-armhf-rb ?
** we could get rid of the links in jenkins.d.n.git/hosts/
-** we could simplefy .../hosts/*/etc/munin/munin-node.conf
+** we could simplify .../hosts/*/etc/munin/munin-node.conf
==== reproducible Debian arm64
@@ -228,7 +228,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
* add more variations: domain+hostname, uid+gid, USER, UTS namespace
* build the docs?
-* also build with payloads. x86 use seabios as default, arm boards dont have a default. grub is another payload. and these: bayou coreinfo external filo libpayload nvramcui - and:
+* also build with payloads. x86 use seabios as default, arm boards don't have a default. grub is another payload. and these: bayou coreinfo external filo libpayload nvramcui - and:
** CONFIG_PAYLOAD_NONE=y
** CONFIG_PAYLOAD_ELF is not set
** CONFIG_PAYLOAD_LINUX is not set
@@ -265,7 +265,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
** find a way to be informed about updates and keep it updated - see 'freebsd-update cron' and 'pkg audit'. The latter is run periodic(8) as part of the nightly root@ emails.
** modify PATH, uid, gid and USER too and host+domainname as well. The VM is only used for this, so we could change the host+domainname temporaily between builds too.
** add freebsd vm as node to jenkins and run the script directly there, saves lot of ssh hassle
-** run diffoscope nativly
+** run diffoscope natively
* TODO: random notes, to be moved to README
** we build the freebsd master branch
@@ -335,7 +335,7 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
** needs to be made idempotent (currently it removes the schroot at the beginning of the job, instead of creating it elsewhere and replacing it on success at the job end…)
** use schroot tarballs (gzipped), moves are atomic then
* only disable cert checking on the node running in the future
-* compare the just built pkg.tar.zst with the one available on the arch mirrors. *then* one can truely say "X% of the Arch Linux packages are reproducible and could bit by bit be reproduced in the real world."
+* compare the just built pkg.tar.zst with the one available on the arch mirrors. *then* one can truly say "X% of the Arch Linux packages are reproducible and could bit by bit be reproduced in the real world."
* maintenance job:
** check for archlinux schroot sessions which should not be there and delete them. complain if that fails.
@@ -364,8 +364,8 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
** we'll keep building against repo+trunk as we do now (so that archlinux can also benefit from the QA effects)
* fix build.sh:
-** build2.log doesnt get deleted if build1 fails
-** -> rename build2.log to $version_build2.log (dont include package name...)
+** build2.log doesn't get deleted if build1 fails
+** -> rename build2.log to $version_build2.log (don't include package name...)
* things to be done before enabling more builders:
** build in /srv/workspace instead of /tmp (once this has been done reduce /tmp size back to 15G)
@@ -386,9 +386,9 @@ See link:https://jenkins.debian.net/userContent/about.html["about jenkins.debian
* reproducible_build_fdroid_apk.sh
** 1st run ./fdroid build some.app:vercode --server
** 2nd run ./fdroid build some.app:vercode --server
-*** eg: org.fdroid.fdroid:98006
+*** e.g.: org.fdroid.fdroid:98006
*** or: "fdroid build -l org.fdroid.fdroid" to build the latest
-** run diffopscope on the results
+** run diffoscope on the results
* also see https://f-droid.org/wiki/page/Build_Server_Setup
View it on GitLab: https://salsa.debian.org/qa/jenkins.debian.net/-/commit/eb492694a7d9dea3ba619500170661d37e1f4b97
--
View it on GitLab: https://salsa.debian.org/qa/jenkins.debian.net/-/commit/eb492694a7d9dea3ba619500170661d37e1f4b97
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/qa-jenkins-scm/attachments/20210620/84338e73/attachment-0001.htm>
More information about the Qa-jenkins-scm
mailing list