Do you think the requirement for psutil could at least be relaxed to 5.0.1, the version that ships with Debian Stable?
For my segfault - turns out it's due to the psycopg2/libpq/libssl issue in psycopg2 ticket #543. So, nothing related to pgadmin4.
(resending to cc the mailing list) On Thu, Nov 8, 2018 at 6:19 AM Murtuza Zabuawala <murtuza.zabuawala@enterprisedb.com> wrote: > > Hi, > > We need psutil to handle backend process management, ie allow the user to terminate long-running backup or restore job. I don't see any alternative to psutil at a moment which supports cross-platform process management like psutil do. > > I think the reason why there is no binary wheel is that it is hard to maintain platform specific binary wheels. > > -- > Regards, > Murtuza Zabuawala > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > > On Thu, Nov 8, 2018 at 6:02 AM David Gilman <davidgilman1@gmail.com> wrote: >> >> It looks like the most recent release of pgadmin4, 3.5, added a dependency on >> psutil==5.4.7 . This dependency is a bit painful, especially for me, >> for a few reasons. >> >> First, it needs a C compiler to build. Second, upstream is not >> providing a Linux binary wheel, manylinux or not, to help us out here. >> Third, Debian stable ships with psutil 5.0.1 but you have a hard >> requirement on 5.4.7. Finally, I tried building my own wheel on what I >> thought was a similar system but my pgadmin4/apache is segfaulting >> (although this may not be the fault of pgadmin4, I am unable to rule >> this out). >> >> So I'd appreciate some feedback here, if you happen to know what the >> best way to troubleshoot this segfault in pgadmin4 that would be >> great. But for sure I would also ask you to consider relaxing the >> dependency on psutil given that virtually all users of your package >> now have to maintain a compiler and wheel compilation toolchain >> somewhere if they want to run pgadmin4 on Linux. >>