Hi On Monday, October 10, 2016, Devrim Gündüz <dev...@gunduz.org <javascript:_e(%7B%7D,'cvml','dev...@gunduz.org');>> wrote:
> > Hi Dave, > > On Thu, 2016-10-06 at 13:42 +0100, Dave Page wrote: > > > > The global config file that Qt will read by default seems to be > > "/etc/pgAdmin Development Team/pgAdmin 4.conf". > > > > I may change that for 1.1 to use a less obnoxious path. The contents > > of it seem to need to be: > > > > [General] > > ApplicationPath=../../../../usr/lib/python2.7/site-packages/ > pgadmin4-web/ > > PythonPath="/usr/lib64/python2.7/site-packages/;/usr/lib/python2.7/site- > > packages/" > > > > The ApplicationPath is the directory containing pgAdmin4.py. Due to a > > bugette in the way the runtime works, it needs to be relative to the > > location of the runtime, hence all the back-tracking. The PythonPath > > needs to include both the 32 and 64 bit directories, as it seems that > > some of the Python modules end up in each. > > > > That was enough to get it to start for me. > > Ok, this worked on CentOS 7 box, but not on Fedora 24, which has QT5 and > Python > 3. Can you help me to debug this? The content of the file in Fedora 24 is: > $ cat /etc/pgAdmin\ Development\ Team/pgAdmin\ 4.conf > [General] > ApplicationPath=../../../..//usr/lib/python3.5/site-packages/pgadmin4-web/ > PythonPath="/usr/lib64/python3.5/site-packages; > /usr/lib/python3.5/site-packages" > OK, so I only have command line access to a test machine right now as I'm travelling with my tiny laptop that doesn't have vmware on it. I setup an F24 instance on the OpenStack cluster at work, and installed your package. It looks like pgadmin4-web should work from the command line, but it must be started with "python3 pgAdmin4.py", because the default python interpreter on F24 still seems to be Python 2.7. > > > I'm still getting segfault, and: > > An error occurred initialising the application server: > > Failed to locate pgAdmin4.py, terminating server thread. > Hmm, at that point, it should ask for the paths. I'm not seeing a segfault though - it just seems to exit for me, so I don't get a core dump. Can you get one? If so, can you get a backtrace? > > > > Then, we run into the tricky issues, where you may have to deal with > > conflicts between web and desktop mode. In our other installers, we > > ship a blank config_local.py file, with a simple comment at the top > > telling the user they can customise any settings in that file. For web > > users, we don't want that, as it's used as a security mechanism > > (startup will fail if it's not present, and tell the user they must > > set some security-critical options). Those options don't matter in > > desktop mode, hence why we pre-write the file. > > > > Perhaps the way around that is to have the shortcut on the menu call a > > script that can create config_local.py if needed? Though, I see you > > already have config_distro.py forcing the user into desktop mode, > > which is a potential conflict. > > AFAICS, creating the file above helped to solve this issue, at least I can > say > that both modes work on CentOS 7. > > > The other issue I see is with the docs: > > > > 1) The path in config_distro.py is > > /usr/share/doc/pgadmin4-docs/en_US/html/. That directory doesn't exist > > - if the docs are compiled in-situ, they'll end up in > > /usr/share/doc/pgadmin4-docs/en_US/html/_build/html > > > > 2) The docs aren't built, so there is no _build/html directory. > > Actuallly they are installed via -docs subpackage, but I forgot to add > this as > a dependency. > OK, thanks. > > > 3) The docs are integrated into the application so really should be a > > dependency of the pgadmin4 RPM. > > Ok, fixed. Pushed to 9.6 testing repo: > > yum --enablerepo pgdg96-updates-testing install pgadmin4 pgadmin4-web > :-) > > (Packages will appear in next sync ;) ) > > Can you please test again? > I don't have that VM around at the moment :-( -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
