d173f61502
This regenerates the sip bindings for wxwidgets as part of the build
process, fixing a segfault when using kikit from py3-kikit for
panelization:
0 0x00007ff4a9d551e0 in _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:133
1 get_state () at Objects/obmalloc.c:866
2 _PyObject_Free (ctx=<optimized out>, p=0x7ff40fd0e160) at Objects/obmalloc.c:1850
3 0x00007ff40fd2416f in ??? () at /usr/lib/python3.12/site-packages/wx/siplib.cpython-312-x86_64-linux-musl.so
4 0x00007ff4a9cb195b in call_ll_exitfuncs (runtime=0x7ff4aa159ac0 <_PyRuntime>) at Python/pylifecycle.c:2999
5 Py_FinalizeEx () at Python/pylifecycle.c:2005
6 0x00007ff4a9e36488 in Py_Exit (sts=0) at Python/pylifecycle.c:3011
7 0x00007ff4a9e2b759 in handle_system_exit () at Python/pythonrun.c:756
8 0x00007ff4a9e2b5b5 in _PyErr_PrintEx (tstate=0x7ff4aa1c9e38 <_PyRuntime+459640>, set_sys_last_vars=1)
at Python/pythonrun.c:765
9 0x00007ff4a9cbc8ea in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:845
10 PyErr_Print () at Python/pythonrun.c:851
11 _PyRun_SimpleFileObject (fp=<optimized out>, filename=<optimized out>, closeit=<optimized out>, flags=0x7ffcdf91b890)
at Python/pythonrun.c:439
12 0x00007ff4a9e29ee4 in _PyRun_AnyFileObject (fp=0x7ff4a9b2e020, filename=0x7ff4aa2e14f0, closeit=1, flags=0x7ffcdf91b890)
at Python/pythonrun.c:78
13 0x00007ff4a9e23681 in pymain_run_file_obj (program_name=0x7ff4aa2e14b0, filename=0x7ff4aa2e14f0, skip_source_first_line=0)
at Modules/main.c:360
14 pymain_run_file (config=0x7ff4aa16ca18 <_PyRuntime+77656>) at Modules/main.c:379
15 pymain_run_python (exitcode=0x7ffcdf91b864) at Modules/main.c:633
16 Py_RunMain () at Modules/main.c:713
17 0x00007ff4a9ddabd7 in Py_BytesMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:767
18 0x00007ff4aa32c496 in libc_start_main_stage2 (main=0x55a284c2f180 <main>, argc=7, argv=0x7ffcdf91ba18)
at src/env/__libc_start_main.c:95
19 0x000055a284c2f046 in _start ()
|
||
|---|---|---|
| .githooks | ||
| .github | ||
| .gitlab | ||
| community | ||
| main | ||
| scripts | ||
| testing | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .mailmap | ||
| CODINGSTYLE.md | ||
| COMMITSTYLE.md | ||
| README.md | ||
Alpine Linux aports repository
This repository contains the APKBUILD files for each and every Alpine Linux package, along with the required patches and scripts, if any.
It also contains some extra files and directories related to testing (and therefore, building) those packages on GitLab (via GitLab CI).
If you want to contribute, please read the contributor guide and feel free to either submit a merge request on GitLab, or to submit a git patch on the Alpine aports mailing list (~alpine/aports@lists.alpinelinux.org). (note: this mailing list is presently not functional)
Repositories
The Alpine Linux aports tree consists of 3 repositories (directories). Each of these 3 repositories have its own set of policies, use cases and workflows. Below is a definition of the basic policies your package should apply to. Additional policies could apply, please refer to our developer guidelines.
main
Packages in the main repository should be supported following our official
release cycle documentation as defined on our
website. In case of doubt a package should
be moved to our community repository instead. The policy for a package in the
main repository is if this package is reasonable to be expected in a basic
system and has a developer assigned to it who can maintain it as documented on
our release page. A package in main is also expected to include proper
documentation if shipped with the source code and have test suites enabled if
provided. New packages are rarely introduced directly into the main repository
and should follow the workflow: testing => main.
community
Packages in the community repository should be supported following our official
release cycle documentation as defined on our
website. Packages in community are those
that do not belong in our main repository and have finished testing in our
testing repository. A package should have a maintainer and have test suites
enabled if provided and is preferred to ship documentation if the source code
provides it. New packages are rarely introduced directly into the community
repository and should follow the workflow: testing => community
testing
Packages in the testing repositories do not follow our official release cycle documentation as defined on our website and are not included in our official releases and are only shipped in our edge branch. This repository is specifically designed to introduce and test packages and as a staging area for our other repositories. The packages do not follow any of the previously mentioned policies and only need to be able to be build correctly. After the package is verified to be working it should be moved to one of the other repositories as soon as possible following the policies set for that repository. If the package is not moved within a 6 month period we will notify the maintainer and remove it after 9 months.
Git Hooks
You can find some useful git hooks in the .githooks directory.
To use them, run the following command after cloning this repository:
git config --local core.hooksPath .githooks
Guidelines
- Coding style - Guidelines for writing APKBUILDs.
- Commit style - Guidelines for git commit messages.