* Switch to Poetry for dependency management in setup
* Added curl dependency and removed python-pip and python3-pip
---------
Co-authored-by: B1N4RY-P4R45173 <kopakaajay123@gmail.com>
- remove submodules from all files
- bump flake.lock
- add gdb-pt-dump as dependency
- fix building Dockerfile
- fix gdb-pt-dump was broken on portable packages
* Use /bin/sh instead of /bin/bash
* Install the required freebsd packages and remove some bashisms
* Reuse bash
* Attempt to fix the linter
* Fix the linter
* Fix coverage combine toml issue
This commit should fix this issue:
```
Run coverage combine
coverage combine
coverage xml
shell: /usr/bin/bash -e {0}
Can't read 'pyproject.toml' without TOML support. Install with [toml] extra
Error: Process completed with exit code 1.
```
* setup.sh: cleanup the --user flag since we use venv now
Cleans up the --user flag from setup.sh since it is unused after we changed setup.sh to install Python dependencies in a virtual environment
* Remove --user flag from CI workflows
* Fix codecov problem
We need to run the python `coverage` library to collect coverage.
However, gdb was failing to find it.
Recently, pwndbg moved to using venvs. When pwndbg is initialized
it setups the venv "manually", that is, no "source .venv/bin/activate"
is needed. When we run gdb tests, we pass the `gdbinit.py` of pwndbg as a
command to gdb to be executed like this:
`gdb --silent --nx --nh -ex 'py import coverage;coverage.process_startup()' --command PATH_TO_gdbinit.py`
The problem is that *order* matters. This means that *first* coverage
is imported (by `-ex py ...`) and only *then* the init script is executed.
When `coverage` is first imported, it's library search path only looks
in system libraries of python, and not the venv that gdbinit.py would load.
So we would try to import an old version of coverage and fail.
One solution would be to move around the commands, but this would be an
ugly hack IMHO. **Instead**, we should just tell gdb that this is an **init**
command that has to be executed before other commands.
Previously, the order did not matter. All of pwndbg's dependencies were
installed directly as system libraries to python. So the library search path
was the same before and after loading `gdbinit.py`.
---------
Co-authored-by: disconnect3d <dominik.b.czarnota@gmail.com>
Co-authored-by: intrigus <abc123zeus@live.de>
* Change setup.sh to create & use Python virtualenv
The `setup.sh` script now creates a `.venv` directory during execution and installs all dependencies into that directory. Then, `gdbinit.py` will adds the proper `site-packages` directory as the first item of `sys.path`.
Fixes#1634.
Technically Arch Linux ARM is a separate distro from the x86_64 Arch Linux, but it uses pcaman and the same package names. So it installs just fine, just needs to be detected properly.
Now the installation process contains the following steps:
1. Check for any line with source <gdbinit.py> before installation
2. If any, ask the user if they want to proceed
3. After the installation, comment out old source <gdbinit.py> lines if any and add a new source <gdbinit.py> line.
A check for presence of the line set debuginfod enabled on is also added to avoid being appended repeatedly.
when the linux distro is not supported or is arch based, the setup.sh exits after giving install instructions and before sourcing the gdbinit. by moving this block to before any ``exit 1``'s are called, making it so that the source line is always there no matter what.
Package glibc-debuginfo, which is a requirement,
requires repo-debug to be enabled, which is not enabled
by default.
This commit enables this repo when installing if it is
not already enabled.
Containers created with Podman (https://podman.io/) don't have a
.dockerenv file in the root directory, so setup.sh tries to invoke sudo.
This doesn't work because podman containers can't use sudo (the
processes inside the container run as an unprivileged user).
This removes the check for .dockerenv. The other checks should already
be sufficient to detect that it's running in a container without sudo.
There was a quoting bug as `INSTALLFLAGS` contains both the option key and value.
This causes the subsequent commands to look something like `python ... '--target foo'...`, causing
the command to treat the entire string `--target foo` as an option key rather than a key-value pair.
xtex
Xeonacid