Re: v3.0 release on hold

[Dave Page]

On Fri, Mar 23, 2018 at 5:43 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

>
>
> On Thu, Mar 22, 2018 at 3:42 PM, Dave Page  wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:
>>>
 Hi

 On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

> Hi Dave,
>
> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>
>> We've run into a number of unexpected issues with the v3.0 release
>> that I think we need to resolve before moving forwards. For the time 
>> being,
>> only patches critical to fix these issues should be committed.
>>
>> I'll try to look at 1, though I do have another deadline I need to
>> meet.
>> Akshay, can you look at 2 please?
>> Fahar is already looking at 3.
>> Khushboo, can you look at 4 please?
>>
>> Thanks all.
>>
>> 1) There is no longer a system tray in Gnome 3.26 and later, and thus
>> the runtime won't initialise in Fedora 27 and later. We need an 
>> alternative
>> for this, either a tray replacement that the RPM can depend on, or better
>> yet, support whatever it is Gnome expect such apps to use these days.
>>
>> 2) Starting a second instance of the app bundle on Mac doesn't always
>> open a new pgAdmin window as it should. It works fine in the debugger, or
>> if you start the app with a command like: "/Applications/pgAdmin\
>> 4.app/Contents/MacOS/pgAdmin4". It doesn't work if you double-click
>> the appbundle or use a command like "open /Applications/pgAdmin\ 4.app"
>>
>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
>> copy, but apparently his is a fresh installation.
>>
>> 4) On my Windows 7 machine, after running a backup I get no status
>> window, and see the following in the logs:
>>
>>
> We have tried to reproduce this issue on Windows 7 and Windows 8, but
> couldn't reproduce it, It is working fine on both the environments.
> Can you please provide the options which you have selected while
> taking a backup?
>

 They were all the default options - I just selected a database,
 right-clicked to select backup, and entered a filename.


>>> With the default options, it is working fine.
>>>
>>
>> Can you see any  way in which the exception below could conceivably
>> happen? Perhaps if run on a system that has process logs from an older
>> version of pgAdmin?
>>
>>
> Not sure as this issue was fixed by Ashesh 1 year back as per git logs.
>

Well the VM I was testing in did have some process logs from over a year
ago. Removing them, and truncating the process table in the sqlite DB seems
to have resolved the issue.

So, I think that's something to watch for if people have backup issues and
have used older versions of pgAdmin...

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: pgAdmin4 form control error icon position change

[Dave Page]

Thanks Aditya, patch applied.

On Wed, Mar 21, 2018 at 9:34 AM, Aditya Toshniwal <
aditya.toshni...@enterprisedb.com> wrote:

> Created - https://redmine.postgresql.org/issues/3226
>
>
> On Wed, Mar 21, 2018 at 2:51 PM, Murtuza Zabuawala  enterprisedb.com> wrote:
>
>> Hello Aditya,
>>
>> Could you please create new RM
>>  for the issue, so
>> that we can keep track of changes, It will be difficult for us to keep
>> track of email for the details.
>>
>> --
>> Regards,
>> Murtuza Zabuawala
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> On Wed, Mar 21, 2018 at 2:28 PM, Aditya Toshniwal <
>> aditya.toshni...@enterprisedb.com> wrote:
>>
>>>
>>> *Hi Team,*
>>>
>>> This is regarding the position of error icon of a pgAdmin form control.
>>> Below are the screenshots. As we can see, the error icon is overlapping the
>>> control buttons like the drop down button, spinner up down buttons, etc.
>>>
>>>
>>>
>>>
>>> We propose that we can move the error icon to the front of the label of
>>> the form control. Below are screenshots.
>>>
>>>
>>>
>>>
>>> Attached is the patch for the above changes.
>>> Kindly review.
>>> --
>>> Thanks and Regards,
>>> Aditya Toshniwal
>>> Software Engineer | EnterpriseDB Software Solutions
>>> Pune | Mob - 8055837949 <(805)%20583-7949>
>>>
>>
>>
>
>
> --
> Thanks and Regards,
> Aditya Toshniwal
> Software Engineer | EnterpriseDB Software Solutions
> Pune | Mob - 8055837949 <(805)%20583-7949>
>



-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgAdmin 4 commit: Move the field error indicators in front of the affec

[Dave Page]

Move the field error indicators in front of the affected fields so they don't 
obscure spinners or drop downs etc. Fixes #3226

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=1f84285d99003d1d26ab2cb5fdc7d149a9e9f719
Author: Aditya Toshniwal 

Modified Files
--
docs/en_US/release_notes_3_0.rst | 3 ++-
web/pgadmin/static/css/bootstrap.overrides.css   | 2 +-
web/pgadmin/static/css/pgadmin.css   | 2 +-
web/pgadmin/static/scss/_backform.overrides.scss | 6 +++---
4 files changed, 7 insertions(+), 6 deletions(-)

Re: v3.0 release on hold

[Khushboo Vashi]

On Fri, Mar 23, 2018 at 3:21 PM, Dave Page  wrote:

>
>
> On Fri, Mar 23, 2018 at 5:43 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 3:42 PM, Dave Page  wrote:
>>
>>>
>>>
>>> On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>
>>> We've run into a number of unexpected issues with the v3.0 release
>>> that I think we need to resolve before moving forwards. For the time 
>>> being,
>>> only patches critical to fix these issues should be committed.
>>>
>>> I'll try to look at 1, though I do have another deadline I need to
>>> meet.
>>> Akshay, can you look at 2 please?
>>> Fahar is already looking at 3.
>>> Khushboo, can you look at 4 please?
>>>
>>> Thanks all.
>>>
>>> 1) There is no longer a system tray in Gnome 3.26 and later, and
>>> thus the runtime won't initialise in Fedora 27 and later. We need an
>>> alternative for this, either a tray replacement that the RPM can depend 
>>> on,
>>> or better yet, support whatever it is Gnome expect such apps to use 
>>> these
>>> days.
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't
>>> always open a new pgAdmin window as it should. It works fine in the
>>> debugger, or if you start the app with a command like:
>>> "/Applications/pgAdmin\ 4.app/Contents/MacOS/pgAdmin4". It doesn't
>>> work if you double-click the appbundle or use a command like "open
>>> /Applications/pgAdmin\ 4.app"
>>>
>>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
>>> copy, but apparently his is a fresh installation.
>>>
>>> 4) On my Windows 7 machine, after running a backup I get no status
>>> window, and see the following in the logs:
>>>
>>>
>> We have tried to reproduce this issue on Windows 7 and Windows 8, but
>> couldn't reproduce it, It is working fine on both the environments.
>> Can you please provide the options which you have selected while
>> taking a backup?
>>
>
> They were all the default options - I just selected a database,
> right-clicked to select backup, and entered a filename.
>
>
 With the default options, it is working fine.

>>>
>>> Can you see any  way in which the exception below could conceivably
>>> happen? Perhaps if run on a system that has process logs from an older
>>> version of pgAdmin?
>>>
>>>
>> Not sure as this issue was fixed by Ashesh 1 year back as per git logs.
>>
>
> Well the VM I was testing in did have some process logs from over a year
> ago. Removing them, and truncating the process table in the sqlite DB seems
> to have resolved the issue.
>
> So, I think that's something to watch for if people have backup issues and
> have used older versions of pgAdmin...
>
> yes, we should keep in mind this.

> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Showstopper desktop runtime issue

[Magnus Hagander]

On Thu, Mar 22, 2018 at 5:28 PM, Dave Page  wrote:

>
>>
>> 3) Electron
>>>
>>> Pros:
>>> - Full Javascript runtime, no more C++ code to handle
>>> - Self packaging for all the environments
>>> Cons:
>>> - No fully supported on Linux based OS with old libstdc++, (This might
>>> solve the problem: https://github.com/mattermost/desktop/issues/312)
>>>
>>
>>
>> Losing support for things like RHEL6 would make it completely unworkable
>> for several of my largest customers. Particularly in large enterprise
>> organisations, this would be a very substantial issue.
>>
>
> That's good to know. There are clunky workarounds (shipping different
> libcs for example, but that potentially adds licensing issues).
>
> Sidenote: It would only be an issue for desktop mode. Web mode should not
> be affected.
>

Right.



> - CPU/RAM high utilization (Found a issues around and the majority of them
>>> have solutions like CSS animations running or settings on the created
>>> windows)
>>>
>>
>> This does sound bad. But do we actually know if this is worse in Electron
>> than it is in the option #2? I mean sure, we point to things like Slack,
>> but that may not be because of electron, it may be because the app running
>> inside it?
>>
>
> We don't know for sure, but we do know that Chrome in general is a bit of
> a hog. It's certainly not a stretch to think a combination of those things
> are why people (correctly) see browser based apps as being more resource
> hungry.
>

It is, but is it more of a hog than other modern browsers? :) (I mean,
every single Electron app I've ever used has been absolutely horrible from
a CPU/RAM/Battery utilization, to the point that I've deleted them all, but
blame needs to be assigned to the right place)



> - Electron does not support tabs by default, only HTML tabs
>>>
>>
>> I think that also makes it a showstopper. This was another one of the
>> main complaints I have personally heard from people going from pgadmin3 ->
>> pgadmin4, and enough to make people not want to use it at all. It would be
>> really bad to go back to that.
>>
>
> To clarify; it would mean no tabs, but not single window. That was already
> working in the PoC. In other words, helpfiles, the debugger and query tools
> could all be opened in new windows, just not tabs on the same window that
> could be docked and un-docked.
>
> I suspect for most people that would be enough.
>

What people want, in my experience, is it for different queries. Haven't
really seen requests for it when it comes to anything other than that. But
people do definitely want the ability to do those both in tabs and in
windows, by their choice, if at all possible.


3) Electron can to play, first when we though about removing QTWebkit,
>>> because it always packs a browser with it and also and there is a very big
>>> Open Source Community being it. It came back again when when we saw that we
>>> were ready to ditch the browser. (As a personal note I dislike applications
>>> that I install in my machine and pop browser open to do anything, this is a
>>> personal issue that I would like to see if it was shared by others that was
>>> why we decided to park Electron for a second time. Because if our users are
>>> ok with it there is no need to add extra complexity to the product)
>>> The most interesting thing about the cons that I found in Electron there
>>> is an issue open for them and a bunch of different solutions to try to
>>> handle it, or even advises on how to handle it. This option also allow us
>>> to focus less on browser compatibility as the main target of our
>>> development will become Chromium which is the base of browsers like UC
>>> Browser, Vivaldi, Opera, Google Chrome.
>>>
>>
>> Please don't ever give up browser independence for the *web* version of
>> pgadmin. Don't be That Project (TM).
>>
>
> Not on my watch!
>

:)


(And don't give up on proper tabs either, but I'm sure Electron might catch
>> up in that eventually -- and the issue around RHEL6 will also go away
>> eventually)
>>
>
> RHEL 6 is in support until 2024, though it's already halfway through the
> maintenance 2 phase. It's definitely going, but we really don't know how
> many folks might still be using it in production on systems they're
> updating and using pgAdmin on. That last bit is important; many folks will
> continue to run production servers on RHEL/CentOS 6 for years, but how many
> are using them for client-side stuff or actively updating things like
> pgAdmin on them?
>

I doubt RHEL will very much be used on desktop systems all the way until
2024. But definitely still is in my experience, but it won't be used *that*
long. I still see it, but it's starting to go away, but it's the usual case
of large enterprises shifting platform and needing to certify a gazillion
little desktop apps and hardware gizmos before they can move...

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Showstopper desktop runtime issue

[Magnus Hagander]

On Thu, Mar 22, 2018 at 5:38 PM, Robert Eckhardt 
wrote:

>
>
> On Thu, Mar 22, 2018 at 12:28 PM, Dave Page  wrote:
>
>>
>>> (And don't give up on proper tabs either, but I'm sure Electron might
>>> catch up in that eventually -- and the issue around RHEL6 will also go away
>>> eventually)
>>>
>>
>> RHEL 6 is in support until 2024, though it's already halfway through the
>> maintenance 2 phase. It's definitely going, but we really don't know how
>> many folks might still be using it in production on systems they're
>> updating and using pgAdmin on. That last bit is important; many folks will
>> continue to run production servers on RHEL/CentOS 6 for years, but how many
>> are using them for client-side stuff or actively updating things like
>> pgAdmin on them?
>>
>
> RHEL 6 is the #1 OS for GPDB so if we have customers installing server
> side or wanting to we'd be on this pretty quickly.
>
> As an aside, I'm interested in who and how people are using the Linux
> version. How many are using Linux on the desktop and how many are
> installing the server. My assumption is that people using the linux distro
> are installing the server but I have no actual information to base that on.
>

My experience is actually the opposite in a lot of cases. The server
pgadmin is used primarily by those of my customers who are using Windows --
mainly as a workaround for the fact that the performance experience of the
desktop app on Windows was horrible.

On Mac I don't think I've seen anybody choose the server version if it's a
primary tool for them (some still have a shared pgadmin for people who only
touch it at very infrequent cases, but it's not common). On Linux, I see a
mix.



-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: Experiencing issues

[Dave Page]

On Fri, Mar 23, 2018 at 6:17 AM, Khushboo Vashi <
khushboo.va...@enterprisedb.com> wrote:

> Hi,
>
> On Wed, Mar 21, 2018 at 9:31 PM, Dave Page  wrote:
>
>>
>>
>> On Wed, Mar 21, 2018 at 3:57 PM, Joao De Almeida Pereira <
>> jdealmeidapere...@pivotal.io> wrote:
>>
>>> Sorry I did not understand what you said.
>>> This configuration:
>>>
>>> DEFAULT_SERVER = '0.0.0.0'
>>> SESSION_COOKIE_DOMAIN = DEFAULT_SERVER
>>> COOKIE_DEFAULT_DOMAIN = DEFAULT_SERVER
>>>
>>> If the application lives in the domain pgadmin.somedomain.com do I need
>>> to have in config_local:
>>> DEFAULT_SERVER = '0.0.0.0'
>>> SESSION_COOKIE_DOMAIN = 'pgadmin.somedomain.com'
>>> COOKIE_DEFAULT_DOMAIN = 'pgadmin.somedomain.com'
>>> ?
>>>
>>> Does this mean that if for some reason I have a second domain like
>>> pgadmin.somedomain2.com that I want to use I cannot?
>>>
>>> The issue of 127.0.0.1 to localhost is very cumbersome, and somehow we
>>> should be able to disable this, because when we are developing doesn't make
>>> sense to not being able to use localhost and 127.0.0.1
>>>
>>
>> +1. I didn't realise we'd added this restriction when I tested the patch.
>>
>> Perhaps a better approach would be to leave the default cookie handling
>> as it was, and just expose the domain and path via config options that the
>> user can set if appropriate for their installation.
>>
>> Please find the attached updated patch as discussed.
>
> If one has to set cookie domain and path then below *config variables*
> should be changed.
>
> COOKIE_DEFAULT_PATH
> COOKIE_DEFAULT_DOMAIN
> SESSION_COOKIE_DOMAIN
>

Thanks, applied.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgAdmin 4 commit: Simplify cookie domain/path settings, per discussion.

[Dave Page]

Simplify cookie domain/path settings, per discussion. Instead of trying to be 
smart, just let the user specify them in the config, e.g.

COOKIE_DEFAULT_DOMAIN = None
SESSION_COOKIE_DOMAIN = None

Branch
--
master

Details
---
https://git.postgresql.org/gitweb?p=pgadmin4.git;a=commitdiff;h=413709fc78f5d671ade9bea7975912a5f1fa4110
Author: Khushboo Vashi 

Modified Files
--
web/config.py   |  4 ++--
web/pgadmin/__init__.py | 11 ++-
web/pgadmin/browser/__init__.py |  3 ++-
web/pgadmin/preferences/__init__.py |  3 ++-
4 files changed, 8 insertions(+), 13 deletions(-)

Re: v3.0 release on hold

[Ashesh Vashi]

On Fri, Mar 23, 2018 at 3:21 PM, Dave Page  wrote:

>
>
> On Fri, Mar 23, 2018 at 5:43 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Thu, Mar 22, 2018 at 3:42 PM, Dave Page  wrote:
>>
>>>
>>>
>>> On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>


 On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:

> Hi
>
> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi Dave,
>>
>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page  wrote:
>>
>>> We've run into a number of unexpected issues with the v3.0 release
>>> that I think we need to resolve before moving forwards. For the time 
>>> being,
>>> only patches critical to fix these issues should be committed.
>>>
>>> I'll try to look at 1, though I do have another deadline I need to
>>> meet.
>>> Akshay, can you look at 2 please?
>>> Fahar is already looking at 3.
>>> Khushboo, can you look at 4 please?
>>>
>>> Thanks all.
>>>
>>> 1) There is no longer a system tray in Gnome 3.26 and later, and
>>> thus the runtime won't initialise in Fedora 27 and later. We need an
>>> alternative for this, either a tray replacement that the RPM can depend 
>>> on,
>>> or better yet, support whatever it is Gnome expect such apps to use 
>>> these
>>> days.
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't
>>> always open a new pgAdmin window as it should. It works fine in the
>>> debugger, or if you start the app with a command like:
>>> "/Applications/pgAdmin\ 4.app/Contents/MacOS/pgAdmin4". It doesn't
>>> work if you double-click the appbundle or use a command like "open
>>> /Applications/pgAdmin\ 4.app"
>>>
>>> 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
>>> copy, but apparently his is a fresh installation.
>>>
>>> 4) On my Windows 7 machine, after running a backup I get no status
>>> window, and see the following in the logs:
>>>
>>>
>> We have tried to reproduce this issue on Windows 7 and Windows 8, but
>> couldn't reproduce it, It is working fine on both the environments.
>> Can you please provide the options which you have selected while
>> taking a backup?
>>
>
> They were all the default options - I just selected a database,
> right-clicked to select backup, and entered a filename.
>
>
 With the default options, it is working fine.

>>>
>>> Can you see any  way in which the exception below could conceivably
>>> happen? Perhaps if run on a system that has process logs from an older
>>> version of pgAdmin?
>>>
>>>
>> Not sure as this issue was fixed by Ashesh 1 year back as per git logs.
>>
>
> Well the VM I was testing in did have some process logs from over a year
> ago. Removing them, and truncating the process table in the sqlite DB seems
> to have resolved the issue.
>
> So, I think that's something to watch for if people have backup issues and
> have used older versions of pgAdmin...
>
Should we have a job to purge them on a timely basis? (Of course -
configurable)

-- Thanks, Ashesh

>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: Showstopper desktop runtime issue

[Dave Page]

Hi

On Thu, Mar 22, 2018 at 6:27 PM, Joao De Almeida Pereira <
jdealmeidapere...@pivotal.io> wrote:

> Hello Hackers
>
> In the PoC we did with Electron last month this was the point where we
> stopped
>
> What did we accomplish:
>  - Use Electron as a runtime and packaging solution for the application
>  - Support opening new windows when the preferences ask for them
>  - Make the application generally work
>  - Use Chrome as a default browser for the application
>  - Building scripts for all platforms using `yarn`, please review Readme
>  - The packaged Python version is 3.6 to Mac and Linux, and 3.4 to Windows
>  - In our point of view it is a simpler way to generate the installers
>
> Work in progress:
>  - No random port for the server, so you can only start 1 instance per
> machine
>  - Tab support, there is no native support for tabs in Electron. It is
> possible to do that, and eventually you will see a option in the menu to
> create a new tab, but for this PoC we decided to disable the creation of
> tabs. Tabs need to be implemented using HTML and cannot be ripped of from
> the current window, like in Chrome
>  - Did not test in CentOS, but tested in Ubuntu and it is working (We
> tried but the electron required GLIBC 2.25 that was not on the version of
> CentOS that we had)
>  - In Linux despite the fact that we close the window, the application is
> still running and need to be killed by hand
>  - We didn't test Debugger opening in new window
>  - Loading screen has no reference to pgAdmin
>  - No logging file for the runtime
>  - Windows we are using python 3.4 and using prior version of psycopg2
> 2.5.6 and pycrypto 2.6.1 (The version of psycopg2 is not the correct one,
> this is because we couldn't find a precompile version of psycopg2)
>  - This is just a spike and the code looks pretty messy. This need to be
> changed in order to make it more readable and have some tests around it
>  - Murtuza and Fahar were not able to run the application in Windows
>  - Khushboo was not able to run Ubuntu version
>
> Given this was the status at the time, we need to pick and choose what we
> really want to implement right out of the box and what could be postponed.
> In order to generate Windows build and ensure that the Linux build is
> working we need so help. If we could have access to the machines that you
> use to build pgAdmin or access to the venv folder that is generated in
> these machines we could try to create a build from that.
>
> The changes we produced still applies cleanly on master and can be found
> in: https://github.com/greenplum-db/pgadmin4/tree/electron-over-master
>
>
I just tried building the PoC again, and got much further than before - in
fact I did get a working app bundle out at the end, however the dist build
did spew out the errors below:

piranha:electron dpage$ yarn dist
yarn run v1.3.2
$ ./node_modules/.bin/electron-builder
  • electron-builder version=20.0.7
  • loaded configuration file=package.json ("build" field)
  • writing effective config file=dist/electron-builder.yaml
  • no native production dependencies
  • asar using is disabled — it is strongly not recommended solution=enable
asar and use asarUnpack to unpack files that must be externally available
  • packaging   platform=darwin arch=x64 electron=1.8.2
appOutDir=dist/mac
  • signing file=dist/mac/pgAdmin 4.app identityName=Developer ID
Application:  identityHash=
Error: Command failed: codesign --verify --deep --strict --verbose=2
/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin 4.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper NP.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper NP.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper EH.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper.app
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/pgAdmin 4 Helper EH.app
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Mantle.framework/Versions/Current/.
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--validated:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/Squirrel.framework/Versions/Current/.
--prepared:/Users/dpage/git/pgadmin4-electron/electron/dist/mac/pgAdmin
4.app/Contents/Frameworks/ReactiveCocoa.framework/Versions/Current/.
--validated:/Use

Re: Showstopper desktop runtime issue

[Dave Page]

On Thu, Mar 22, 2018 at 4:58 PM, Dave Page  wrote:

>
>
> On Thu, Mar 22, 2018 at 4:28 PM, Dave Page  wrote:
>
>>
>> 2) This option is not very appealing to me, because we would be pilling
 code into the QT portion of the application, that I hope we remove in the
 future, that currently is untested to solve a problem caused by a Window
 Manager..
 I would be more in favor of creating a Application Indicator that would
 support 2 actions, Kill running pgAdmins and launch the browser to access
 them. There is a lot of interesting websites that talk about this, and how
 to develop. I had to download one to have a docker indicator. But as I
 said in a previous thread, I believe that this should be a 3rd party
 application and not a first class citizen on pgAdmin, as the majority of
 the ones that I found are.

>>>
>>> I can't comment on the specific ways to sort it out, but I think
>>> *basing* things in option 2 is by far the best option. If it's just an
>>> additional add-on that can be made a dependency of the packages it's not a
>>> huge problem (provided this add-on is available on the major platforms like
>>> rhel, ubuntu, debian of course)
>>>
>>
>> It would just be a modified version of what we have. Instead of having an
>> icon in the system tray, we'd probably have multiple Start Menu icons to
>> replace the tray icon menu. They would have to signal a running instance to
>> do something, or become a new instance and then do the something if nothing
>> is running already.
>>
>
> Of course, another option here might be to figure out that we're running
> under Gnome/GTK at runtime, and if so, create an indicator icon and menu
> instead of the tray icon. That is, apparently, what Skype and other similar
> apps do now. The indicator icons go on the right of the top menu bar (kinda
> like where tray icons go on macOS).
>

I investigated this, and have failed to find anything about how to do this
so far.

However, the following does fix the problem:

1) # dnf install gnome-shell-extension-topicons-plus
2) Run gnome-tweak-tool
3) Enable TopIcons Plus

There are apparently ways to enable the extension globally from the command
line. Need to test that (and figure out if it would be considered bad form
to do so).

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: v3.0 release on hold

[Dave Page]

On Fri, Mar 23, 2018 at 11:27 AM, Ashesh Vashi <
ashesh.va...@enterprisedb.com> wrote:

> On Fri, Mar 23, 2018 at 3:21 PM, Dave Page  wrote:
>
>>
>>
>> On Fri, Mar 23, 2018 at 5:43 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>>
>>>
>>> On Thu, Mar 22, 2018 at 3:42 PM, Dave Page  wrote:
>>>


 On Thu, Mar 22, 2018 at 9:58 AM, Khushboo Vashi <
 khushboo.va...@enterprisedb.com> wrote:

>
>
> On Thu, Mar 22, 2018 at 3:20 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Thu, Mar 22, 2018 at 9:25 AM, Khushboo Vashi <
>> khushboo.va...@enterprisedb.com> wrote:
>>
>>> Hi Dave,
>>>
>>> On Wed, Mar 21, 2018 at 9:05 PM, Dave Page 
>>> wrote:
>>>
 We've run into a number of unexpected issues with the v3.0 release
 that I think we need to resolve before moving forwards. For the time 
 being,
 only patches critical to fix these issues should be committed.

 I'll try to look at 1, though I do have another deadline I need to
 meet.
 Akshay, can you look at 2 please?
 Fahar is already looking at 3.
 Khushboo, can you look at 4 please?

 Thanks all.

 1) There is no longer a system tray in Gnome 3.26 and later, and
 thus the runtime won't initialise in Fedora 27 and later. We need an
 alternative for this, either a tray replacement that the RPM can 
 depend on,
 or better yet, support whatever it is Gnome expect such apps to use 
 these
 days.

 2) Starting a second instance of the app bundle on Mac doesn't
 always open a new pgAdmin window as it should. It works fine in the
 debugger, or if you start the app with a command like:
 "/Applications/pgAdmin\ 4.app/Contents/MacOS/pgAdmin4". It doesn't
 work if you double-click the appbundle or use a command like "open
 /Applications/pgAdmin\ 4.app"

 3) Fahar saw a crash on Windows 7. I couldn't reproduce this on my
 copy, but apparently his is a fresh installation.

 4) On my Windows 7 machine, after running a backup I get no status
 window, and see the following in the logs:


>>> We have tried to reproduce this issue on Windows 7 and Windows 8,
>>> but couldn't reproduce it, It is working fine on both the environments.
>>> Can you please provide the options which you have selected while
>>> taking a backup?
>>>
>>
>> They were all the default options - I just selected a database,
>> right-clicked to select backup, and entered a filename.
>>
>>
> With the default options, it is working fine.
>

 Can you see any  way in which the exception below could conceivably
 happen? Perhaps if run on a system that has process logs from an older
 version of pgAdmin?


>>> Not sure as this issue was fixed by Ashesh 1 year back as per git logs.
>>>
>>
>> Well the VM I was testing in did have some process logs from over a year
>> ago. Removing them, and truncating the process table in the sqlite DB seems
>> to have resolved the issue.
>>
>> So, I think that's something to watch for if people have backup issues
>> and have used older versions of pgAdmin...
>>
> Should we have a job to purge them on a timely basis? (Of course -
> configurable)
>

Hmm, not sure if it's worth it. We should make sure that future changes in
that code can cope with older format logs and DB entries though.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: v3.0 release on hold

[Akshay Joshi]

Hi Dave

On Fri, Mar 23, 2018 at 11:06 AM, Akshay Joshi <
akshay.jo...@enterprisedb.com> wrote:

>
>
> On Thu, Mar 22, 2018 at 10:24 PM, Dave Page  wrote:
>
>> Hi
>>
>> On Thu, Mar 22, 2018 at 1:13 PM, Dave Page  wrote:
>>
>>>
>>> 2) Starting a second instance of the app bundle on Mac doesn't
>>> always open a new pgAdmin window as it should. It works fine in the
>>> debugger, or if you start the app with a command like:
>>> "/Applications/pgAdmin\ 4.app/Contents/MacOS/pgAdmin4". It doesn't
>>> work if you double-click the appbundle or use a command like "open
>>> /Applications/pgAdmin\ 4.app"
>>>
>>
>>   Still working on this, not found any solution yet.
>>
>
  Not able to figure out the solution yet. I have tried to debug
 the code, but every time it will create a new instance(tray icon). Do I
 need to look into the code or something related to app bundle may be some
 settings in info.plist or any other pointer?

>>>
>>> Have a look at the code around line 85 an onwards of pgAdmin4.cpp. It
>>> creates the shared memory interlock (and log/address files) based on the
>>> current username and a hash of the executable name/path. My suspicion is
>>> that the path hash (which is calculated from argv[0] on line 72) is for
>>> some reason getting a different value each time when launched via the
>>> Finder or "open", thus the interlock is failing.
>>>
>>
>> So I took a look at this, and it seems the code is just fine. What is
>> happening is that macOS only allows a single instance of an app to run at
>> once. Whilst that is what we want of course, macOS is causing the new
>> instance to exit before it has a change to open a new pgAdmin window. Using
>> "open -n ..." or calling the embedded executable directly resolves that
>> issue.
>>
>> So, there's another challenge to figure out... :-(
>>
>
> OK. Will try to figure that out.
>

After googled I have tried following solution:

   1. Create a shell script "launch.sh" and kept it in  "/Applications/pgAdmin\
   4.app/Contents/MacOS" folder. That shell script will contain the command
   "open -n /Applications/pgAdmin\ 4.app/Contents/MacOS/pgAdmin4". Change
   the "CFBundleExecutable" parameter of Info.plist from "pgAdmin4" to
   "launch.sh".  It didn't work, shall script didn't launch.
   2. Create one apple script with command like "do shell execute
"/Applications/pgAdmin\
   4.app", compile it and save it as Application. It create the app bundle,
   copy contents of pgAdmin4 app to this newly created application. But the
   problem is it opens and having icon in the dock and no response on double
   click (second time).

   Will continue to figure out some other solutions tomorrow.

>
>> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>
>
> --
> *Akshay Joshi*
>
> *Sr. Software Architect *
>
>
>
> *Phone: +91 20-3058-9517Mobile: +91 976-788-8246*
>



-- 
*Akshay Joshi*

*Sr. Software Architect *



*Phone: +91 20-3058-9517Mobile: +91 976-788-8246*