1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
|
# SBo SlackBuilds Repository
SlackBuild scripts maintained by Danilo (danix) and submitted to
[SlackBuilds.org (SBo)](https://slackbuilds.org). This repo holds ONLY the
packages for which danix is the **official SBo maintainer**. Lead and
experimental packages not on SBo under danix live in the separate
`my-slackbuilds` repository.
---
## Repo Structure
Each package lives in its own top-level subfolder:
```
<package-name>/
├── <package-name>.SlackBuild # Main build script
├── <package-name>.info # Metadata (version, checksums, URLs)
├── README # Description and usage notes
├── slack-desc # Package description (11-line format)
├── <package-name>.desktop # (optional) Desktop entry for GUI apps
└── [...] # other optional files
```
Version tracking is handled by a single file:
```
.extras/nvchecker.toml # nvchecker config listing all packages
```
### `.extras/` holds all non-package repo files
Anything that is not a SlackBuild package must live under `.extras/`, never at
the repo root.
---
## Build Strategies
Packages fall into several categories; the SlackBuild style differs
accordingly.
### Source builds (Go)
Packages such as `ffuf`, `gobuster`, `nuclei` are built from upstream source
tarballs using `go build`. Key points:
- Set `GOPATH`, `GOPROXY`, `GOFLAGS` before building
- Use `-buildmode=pie -trimpath -mod=readonly -modcacherw`
- Strip ELF binaries after build
- Clean up `$GOPATH` / Go module cache before packaging
- `REQUIRES="google-go-lang"` in the `.info` file
### Source builds (Rust)
Packages such as `feroxbuster` build from a vendored crates tarball
(`<pkg>-<version>-vendor.tar.gz`) declared as a second source in `.info`,
alongside the upstream tarball. The SlackBuild unpacks it, points cargo at it
via `.cargo/config.toml`, and builds fully offline (`cargo build --offline
--locked`). The vendor tarball is generated once per version with
`cargo-vendor-filterer`, with `SOURCE_DATE_EPOCH` pinned to the release tag's
commit date for a byte-for-byte reproducible archive. The exact command is
recorded in the package's own `README`.
### Binary repacks — Debian `.deb`
Packages such as `metasploit-framework-bin` are repacked from upstream `.deb`
archives (SBo convention: `.deb`/binary repacks take a `-bin` suffix):
- Extract with: `ar p <file>.deb data.tar.gz | tar xzv`
- Set `DOWNLOAD="UNSUPPORTED"` and use `DOWNLOAD_x86_64` / `MD5SUM_x86_64`
(plus the i386 pair when the package is multi-arch)
- Strip ELF binaries after extraction
#### `metasploit-framework-bin`: msfvenom bash-completion
The shipped `msfvenom.bash-completion` is a **pre-generated snapshot**, not a
static file. Upstream (kali) no longer ships it; they generate it at build
time with a ruby script that loads the framework and dumps the live
payload/encoder/arch/platform/format lists. We ship a snapshot instead of
running ruby at build time (hermetic build, no build-time dep).
**Regenerate it on every version bump.** After building and installing the
new package so `/opt/metasploit-framework` is live, pull the current
generator and run it against the installed framework's bundled ruby:
```bash
curl -o /tmp/gen.rb \
https://gitlab.com/kalilinux/packages/metasploit-framework/-/raw/kali/master/debian/generate-msfvenom-bash-completion.rb
/opt/metasploit-framework/embedded/bin/ruby \
-I/opt/metasploit-framework/embedded/framework/lib /tmp/gen.rb \
> metasploit-framework-bin/msfvenom.bash-completion
```
Verify the output is non-empty and the `%s` slots were filled (grep for real
payload names like `windows/meterpreter`), then commit it with the bump.
#### `metasploit-framework-bin`: man pages
The .deb ships **no** metasploit man pages (its `share/man` tree is only for
bundled deps like postgres/ruby). We ship `msfconsole.1` and `msfvenom.1`
from kali, who maintain them by hand (no generator script). The SlackBuild
gzips them into `/usr/man/man1`. **Refresh them on version bumps** in case
kali has updated them:
```bash
for p in msfconsole msfvenom ; do
curl -o metasploit-framework-bin/$p.1 \
https://gitlab.com/kalilinux/packages/metasploit-framework/-/raw/kali/master/debian/extra/$p.1
done
```
For metasploit bumps, `PRGNAM=metasploit-framework-bin` with
`SRCNAM=metasploit-framework` drives the `.deb` glob and `/opt` path; pull
both-arch filenames and MD5s from the apt Packages indexes (`binary-amd64`
and `binary-i386`).
### Data / archive packages
Packages such as `SecLists`, `exploitdb` install data files rather than
compiled binaries. No stripping needed.
---
## SlackBuild Scripting Guidelines
- Follow the [SBo template](https://slackbuilds.org/templates/) as the base for all scripts
- Use `set -e` to abort on errors
- Honor `$TMP`, `$BUILD`, `$TAG`, `$OUTPUT` variables; default values must be set if unset
- Use `$ARCH` detection with proper `SLKCFLAGS` and `LIBDIRSUFFIX`
- Strip binaries and libraries unless upstream explicitly discourages it
- Install docs to `/usr/doc/$PRGNAM-$VERSION/`
- Always include `find -L` + `chown`/`chmod` cleanup block before packaging
- Copy repo files into `$PKG` with `cat src > dest`, never `cp`. `cat` writes
through a fresh destination so the build's umask/root ownership sets the
perms; `cp` bleeds the git working-tree mode/ownership into the package.
Applies to `slack-desc`, `doinst.sh`, and any file staged from `$CWD`
(SlackBuild, README, `.nvchecker`) into `$PKG`.
- Use `makepkg -l y -c n` to create the final package
### `.info` file
Must contain:
```
PRGNAM, VERSION, HOMEPAGE, DOWNLOAD, MD5SUM (or SHA256SUM), REQUIRES, MAINTAINER, EMAIL
```
- Checksums must match the exact source archive
- MAINTAINER/EMAIL are danix's, since this repo is his SBo-official packages
- Use `REQUIRES=""` if no SBo dependencies; list space-separated SBo package names otherwise
### `slack-desc`
- Exactly 11 lines in the `package-name: description` format
- First line: `package-name: package-name (short one-liner)`
- Lines 2–11: description, leave blank lines as `package-name:`
- Handy ruler line must be included (but not shipped)
---
## Version Tracking: nvchecker
A single `.extras/nvchecker.toml` tracks upstream versions for all packages.
To check for new upstream versions:
```bash
nvchecker -c .extras/nvchecker.toml
```
When a new version is detected, update `VERSION` in both `.SlackBuild` and
`.info`, then run `sbofixinfo` to refresh checksums.
**Every package added to this repo must have a corresponding entry in
`.extras/nvchecker.toml`.**
For **nvchecker** github stanzas prefer `use_latest_release` (hits
`releases/latest`, lenient) over `use_max_tag` (hits `git/refs/tags`, tightly
rate-limited and 403s under the shared anon budget); use `use_max_tag` only for
repos that tag but don't cut Releases (a `use_latest_release` probe 404s on
those). Probe ONE stanza with `nvchecker -c <cfg> -e <name>`.
---
## Tooling: sbo-maintainer-tools
Source: https://slackware.uk/~urchlay/repos/sbo-maintainer-tools
| Tool | Purpose |
|------|---------|
| `sbolint` | Lint `.SlackBuild`, `README`, `.info`, `slack-desc` |
| `sbopkglint` | Lint the built package |
| `sbofixinfo` | Auto-fix common `.info` file issues |
| `sbodl` | Download sources and verify `MD5SUM`/`SHA256SUM` from `.info` |
### Git hook setup
Both hooks are tracked in `.extras/hooks/`. Install them after cloning:
```bash
cp .extras/hooks/pre-commit .git/hooks/pre-commit
cp .extras/hooks/post-commit .git/hooks/post-commit
chmod +x .git/hooks/pre-commit .git/hooks/post-commit
```
To bypass the pre-commit lint check in exceptional cases:
```bash
SBOLINT=no git commit -m'Message here'
```
Note: `sbodl` creates symlinks in the package directory pointing to downloaded
sources. Remove them before staging (`find . -type l -delete`); they must never
be committed.
---
## Who builds SlackBuilds
Only the user builds SlackBuilds, on their own infra. Claude authors/edits the
sources (`.SlackBuild`, `.info`, `README`, `slack-desc`, `doinst.sh`, nvchecker
stanzas) and runs only the non-building checks (`sbolint`, `sbodl`,
`sbofixinfo`); the user builds and reports back. Never run or offer
`bash <pkg>.SlackBuild`, `sbopkglint`, or `slackrepo build`.
---
## SBo Submission Guidelines
Before submitting or updating a package on SlackBuilds.org:
1. **Pass all lint checks** — `sbolint` and `sbopkglint` must report no errors
2. **Test the build** on a clean Slackware installation (or VM snapshot)
3. **Verify checksums** via `sbodl` before committing
4. **Check `README`** includes all non-SBo dependencies and any special build notes
5. **Follow the SBo submission guidelines**: https://slackbuilds.org/guidelines/
6. **Bump `VERSION`** in both `.SlackBuild` and `.info` when updating
7. **Run `sbofixinfo`** after every version bump to catch stale checksums/URLs
---
## Commit Conventions
- One commit per package add/update
- Commit message format: `<package-name>: add version X.Y.Z` or `<package-name>: update to X.Y.Z`
- For fixes: `<package-name>: fix <short description>`
---
## Maintainer
danix
|
