I was trying to run the latest version on my debian 12, KDE laptop.

first, there was no config file in the dir. of the AppImage, which crashed the app.

./AgentPilot-0.1.5.AppImage 
…
FileNotFoundError: [Errno 2] No such file or directory: '/home/guenter/tmp/AgentPilot.weg/configuration.yaml'
[3699489] Failed to execute script '__main__' due to unhandled exception!

since on linux, binarys and configurations have their "common places", I suggest following the XDG Base Directory Specifications

$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.

i.e. $HOME/.config/AgentPilot/configuration.yaml

$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

that is for additional files of the APP, if neccessary. (i.e downloaded plugins)

for the local installed AppImages. they can go systemwide into /usr/local/bin or on userlevel into $HOME/.local/bin.
the latter is, where a AppImage like yours should be placed normally.

After having given the AppImage an own folder with cloned configuration file, the App starts for a short moment and exits silently.

I have attached a strace log, in case that helps.

strace.log

using open-interpreter:
"Write a hello world program in python"
print("hello world")

Agent pilot spawns new windows forever. and runs the code multiple times.

Is there a feature to add a custom endpoint for the API? If not, are you considering adding it?

Title:

AgentPilot AppImage Fails to Launch on Ubuntu 22.04 due to GLIBC_2.36 Dependency

Issue Description:

I am trying to run the AgentPilot AppImage on Ubuntu 22.04, but it fails to launch. The main issue seems to be related to a missing GLIBC_2.36 library, which is required by the AppImage.

Steps to Reproduce:

1. Download the AgentPilot AppImage (AgentPilot-0.0.9_Portable_Linux_x86_64.AppImage) from the GitHub releases page.
2. Make the AppImage executable:

   chmod +x AgentPilot.AppImage

3. Run the AppImage:

   ./AgentPilot.AppImage

Expected Behavior:

The AppImage should launch and run the AgentPilot application.

Actual Behavior:

The AppImage fails to launch, and the terminal displays the following error:

(process:716806): GLib-CRITICAL **: 14:03:53.309: g_file_test: assertion 'filename != NULL' failed
PySide6/__init__.py: Unable to import Shiboken from /tmp/_MEIHinep7/base_library.zip, /tmp/_MEIHinep7/lib-dynload, /tmp/_MEIHinep7
Traceback (most recent call last):
  File "agentpilot/__main__.py", line 254, in <module>
  ...
ImportError: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by /tmp/_MEIHinep7/libstdc++.so.6)
[716925] Failed to execute script '__main__' due to unhandled exception!

System Information:

• Operating System: Ubuntu 22.04
• Kernel Version: 6.2.0-35-generic
• GLIBC Version: ldd (Ubuntu GLIBC 2.35-0ubuntu3.4) 2.35

Troubleshooting Steps Taken:

1. Checked the GLIBC version installed on the system.
2. Attempted to set the LD_LIBRARY_PATH environment variable.
3. Updated system packages.
4. Considered upgrading system-wide GLIBC_2.36 but would prefer if they were self contained with portable executable.

None of these steps resolved the issue.

The error output I received is as follows:

╭─only@only in ~/AgentPilot-0.0.9_Portable_Linux_x64 as 🧙 took 1s
[🔴] × /home/only/AgentPilot-0.0.9_Portable_Linux_x64/main

None
sys.executable: /home/only/AgentPilot-0.0.9_Portable_Linux_x64/main
dirname of os.path.abspath(sys.executable): /home/only/AgentPilot-0.0.9_Portable_Linux_x64
dirname of os.path.abspath(__file__): /tmp/_MEIoLX1Yq/agentpilot/utils
dirname of os.path.abspath(os.path.dirname(__file__)): /tmp/_MEIoLX1Yq/agentpilot
None
sys.executable: /home/only/AgentPilot-0.0.9_Portable_Linux_x64/main
dirname of os.path.abspath(sys.executable): /home/only/AgentPilot-0.0.9_Portable_Linux_x64
dirname of os.path.abspath(__file__): /tmp/_MEIoLX1Yq/agentpilot/utils
dirname of os.path.abspath(os.path.dirname(__file__)): /tmp/_MEIoLX1Yq/agentpilot
None
sys.executable: /home/only/AgentPilot-0.0.9_Portable_Linux_x64/main
dirname of os.path.abspath(sys.executable): /home/only/AgentPilot-0.0.9_Portable_Linux_x64
dirname of os.path.abspath(__file__): /tmp/_MEIoLX1Yq/agentpilot/utils
dirname of os.path.abspath(os.path.dirname(__file__)): /tmp/_MEIoLX1Yq/agentpilot
None
sys.executable: /home/only/AgentPilot-0.0.9_Portable_Linux_x64/main
dirname of os.path.abspath(sys.executable): /home/only/AgentPilot-0.0.9_Portable_Linux_x64
dirname of os.path.abspath(__file__): /tmp/_MEIoLX1Yq/agentpilot/utils
dirname of os.path.abspath(os.path.dirname(__file__)): /tmp/_MEIoLX1Yq/agentpilot
Traceback (most recent call last):
File "agentpilot/__main__.py", line 270, in <module>
File "agentpilot/__main__.py", line 266, in main
File "agentpilot/gui.py", line 3816, in run
File "agentpilot/gui.py", line 3608, in __init__
File "agentpilot/gui.py", line 3254, in __init__
File "agentpilot/gui.py", line 3286, in __init__
AttributeError: PySide6.QtWidgets.QPushButton.__init__(): 'icon' is not a Qt property or a signal
[273433] Failed to execute script '__main__' due to unhandled exception!

For upcoming release of binaries, any chance for .AppImage or .Deb ?
Thank you for developing project (and especially MemGPT plugin in particular).

hey @jbexta,
thanks very much for the new release.

AP: 1.5.7
litellm(proxy): 1.17.5
ollama: 0.1.20

I'm still stocked at the model-setup.

I'm testing with

1. direct connection to together.ai: nok
   in the API-menu: select together.ai (provider are not alphabetical orderd)

• added key in privat key
• tried to find a model which is impossible in the API/Model-list due to no readability. (long model names)
• only a very old subset of the models are offered. missing i.e mixtral,

then setting the model in System
trying to chat: pop-up error: no OPENAI_API_KEY is set

2. using ollama (on my ext. server)

• choose ollama provider
• only a fraction of the latest modellist is shown.
• the local modified models(files) are not shown.
• where can I set the API_BASE_URL for all my ollama-models at once?
  or do I have to set that for every model seperat, instead of provider-wide?
• adding my own model-file-name to the list.
  • setting URL
  • need to restart to see in 'System'-Menu
  • choose the new model

trying to chat:
-> same OPENAI_API_KEY_error,
even if I set a dummy one in ollama: private-key

4. what are the client-key and privat-key fields for?
   • guess: private-key is the api-key?
   • client-key: ?

when exporting a OPENAI_API_KEY in the env, before starting, the error changes:

litellm.exceptions.AuthenticationError: OpenAIException - Error code: 401 - {'error': {'message': 'Incorrect API key provided: sk-nobro. You can find your API key at https://platform.openai.com/account/api-keys.', 'type': 'invalid_request_error', 'param': None, 'code': 'invalid_api_key'}

the call get routed to openai.com, instead of using either the together-api-endpoint, ollama, or custom-proxy ones.

Suggestion: create a hirachical Settings structure:

1. BASE-Settings
2. PROVIDER-Settings
   query litellm for default model list & params, cost, etc.: see token_usage
3. MODEL-Settings,
   fill in the queried params as default
   overwrite as necessary

workflow 1:
Use a LiteLLM provided services:

1. fill in all BASE-Settings with all neccessary params, then
2. PROVIDER-Settings: choose a provider
3. fill in all neccessary: i.e.

• API-KEY if necessary
• BASE_URL for all provider's models.
• then, query the provider for available modules <API_BASE_URL>/v1/models
• then show the recieved model-list in a wide-enough window, so one even can read replicate's and together.ai`s very long model-names. since we already choose the provider, the first field of the litellm-modelanme schema could be dropped for readability.

3. MODEL-Settings:

• then only offer model-spec overwrites, like, temp, top_?, c_ntx, etc.

workflow 2:
in case of a proxy-use *), we need to set:

1. BASE-settings
2. PROVIDER-settings: create/choose: custom/proxy

• custom API_BASE_URL
• provider: API to use, like openai (for litellm-proxy)
  but without asking for an API_KEY or use dummy, if empty and (API_BASE_URL != api.openai.com)
• query the proxy for avail. model-(aliases)

3. set MODEL-setting overwrites

*) litellm as proxy/router/cache can hold all neccessary info like KEY, URL, provider, model-params

Caveat:

with all the remote queries, this would need to have an airplane-mode.
b/c in case we run the API local (i.e. ollama & running tiny Models), we would loose usability, if we depend on online checks.
therefore an online/offline switch, or maybe don't query by default and implement an update-button could be a solution. the later one would IMHO be preferable, since we can control how often we need to update the list, while tinkering away ;)
the online/offline availability could also go into the provider settings?

what do you think?

I'm sorry to say, but with all these errors since 0.1.5 I still get it not to work.

testing the new 0.1.7:

1. the display needs a dark/light toggle & adapt to the system.
   i.e. I'm an expat in asia and love to sit outside. Apps without light-mode are just not readable during the day.
2. the display-settings tab needs a reset button.
3. startup error on missing configuration.yaml

Preface:

This bug report is an experiment. I used open interpreter to generate a summary of our session trying to fool around with the AppImage trying to get it to work. Below is the output of my request to generate a helpful reproducible bug report.

The caveat is that I'm not technical enough to assess meaningfully how helpful or informative any of the diagnostics or potential problem solving.

I'm curious as to your feedback, as a developer, whether something like this is useful (in this strange year of 2024 where this is even possible). Additionally, if there is anything I could as a standard procedure ask OI to capture in generating bug reports (that would make the report more useful) please let me know as well.

If this isn't helpful at all, I apologize for any inconvenience. Thank you for your development efforts as always.

Open Interpreter Summary:

The AppImage for AgentPilot 0.1.5 on Ubuntu 22.04 fails with a libGL error related to the bundled libstdc++.so.6 library.

Steps to Reproduce:

1. Download the AppImage for AgentPilot 0.1.5.
2. Make it executable and try to run:

chmod a+x ./AgentPilot-0.1.5_88131536057e4e2ddbb84f9520a16a9e.AppImage
./AgentPilot-0.1.5_88131536057e4e2ddbb84f9520a16a9e.AppImage --verbose

3. Observe the error.

Expected Behavior:

The AppImage should start the AgentPilot software without any errors related to OpenGL drivers or the C++ standard library.

Actual Behavior:

Running the AppImage results in the following error:

libGL error: failed to open iris: /tmp/_MEIlb4Bq8/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/x86_64-linux-gnu/dri/iris_dri.so)
libGL error: failed to load driver: iris
libGL error: failed to open swrast: /tmp/_MEIlb4Bq8/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
libGL error: failed to load driver: swrast

The AppImage does not run successfully.

Environment:

• OS: Ubuntu 22.04
• AppImage: AgentPilot 0.1.5

Investigation:

The libstdc++.so.6 within the AppImage seems to lack GLIBCXX_3.4.29, which is required by iris_dri.so and swrast_dri.so OpenGL drivers. However, the system's libstdc++.so.6 does provide GLIBCXX_3.4.29.

Even trying to set the LIBGL_DRIVERS_PATH before running the AppImage does not help, making it seem as though the bundled libstdc++.so.6 might be causing the problem.

LIBGL_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri ./AgentPilot-0.1.5_88131536057e4e2ddbb84f9520a16a9e.AppImage --verbose

Proposed Solution (from OpenInterpreter):

The AppImage should either avoid bundling libstdc++.so.6 (to rely on the system's version) or include a newer version of libstdc++.so.6 that provides GLIBCXX_3.4.29. Given that the system libraries are capable of providing the necessary versions, it may be best for the AppImage not to bundle libstdc++.so.6 and instead utilize the versions available on the user's system. This should allow the AppImage to coexist with the system's OpenGL drivers.