Re: [gentoo-user] Postgresql upgrade

[Andreas K. Huettel]

Am Sonntag, 30. Juli 2017, 01:44:27 CEST schrieb Peter Humphrey:
>
> They are trying though. Daniel Vratil wrote this on the KDE-PIM list
> 
> yesterday:
> > If you use KMail (or Kontact), please help us, the KDE PIM developers, to
> > get a better picture of how you use it so that we know which parts of the
> > software we should focus on, and how we should evolve it in the future. We
> > will use the results of the survey to make the experience of using KMail
> > as best as possible for everyone.
> > 
> > You can fill the survey here: https://survey.kde.org/index.php/852475. It
> > won't take you more than 5 minutes.

If that's the survey I've already filled out then it is a joke. The most 
important points, fault tolerance and stability, are not even mentioned.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Postgresql upgrade

[Mick]

On Sunday 30 Jul 2017 00:44:27 Peter Humphrey wrote:
> They are trying though. Daniel Vratil wrote this on the KDE-PIM list 
> 
> yesterday:
> > If you use KMail (or Kontact), please help us, the KDE PIM developers, to
> > get a better picture of how you use it so that we know which parts of the 
> > software we should focus on, and how we should evolve it in the future.
> > We 
> > will use the results of the survey to make the experience of using KMail
> > as best as possible for everyone.
> > 
> > You can fill the survey here: https://survey.kde.org/index.php/852475. It 
> > won't take you more than 5 minutes.
> 
> -- 
> Regards
> Peter

Thank you Peter, I posted my feedback in the hope they may listen to it and 
not make KMail/KDEPIM worse ...  :-)
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Postgresql upgrade

[Peter Humphrey]

On Saturday 29 Jul 2017 13:03:45 Alan McKinnon wrote:

> Don't use kmail
> 
> Seriously, why are putting up with the pain that POS is causing you?
> You've been posting about serious kmail and akonadi issues for about 4
> years now if memory serves, and it has never gotten better. It probably
> never will :-)

They are trying though. Daniel Vratil wrote this on the KDE-PIM list 
yesterday:

> If you use KMail (or Kontact), please help us, the KDE PIM developers, to
> get a better picture of how you use it so that we know which parts of the 
> software we should focus on, and how we should evolve it in the future. We 
> will use the results of the survey to make the experience of using KMail
> as best as possible for everyone.

> You can fill the survey here: https://survey.kde.org/index.php/852475. It 
> won't take you more than 5 minutes.

-- 
Regards
Peter

Re: [gentoo-user] Postgresql upgrade

[Alan McKinnon]

On 29/07/2017 14:27, Mick wrote:
> 
> On 29 July 2017 at 12:19, Mick  > wrote:
> 
> 
> 
> On 29 July 2017 at 12:03, Alan McKinnon  > wrote:
> 
> 
> Don't use kmail
> 
> Seriously, why are putting up with the pain that POS is causing you?
> You've been posting about serious kmail and akonadi issues for
> about 4
> years now if memory serves, and it has never gotten better. It
> probably
> never will :-)
> 
> It must be well more than 4 years.  What can I say, you are right, I
> must be glutton for punishment. LOL!
> 
> TBH, it has been serving me fine for quite a few years now, although
> the migration to akonadi was a painful affair by all accounts.  This
> was originally caused by me using POP3 and a tonne of filters.  I
> moved to IMAP4 and few filters and it all worked relatively
> painlessly since.
> 
> This however must be a postgresql related error, as it worked fine
> before I removed version 9.5.  Any idea what this "Invalid database
> object during initial database connection" might be and how to
> recover from it?
> 
> 
> Hmm, even more symlinks have been broken,  This time I spotted
> /usr/bin/psql pointing to a non-existent
> ../lib64/postgresql-9.5/bin/psql.  I came across it when I tried to
> connect to the database manually and couldn't run psql, but could run
> psql96.  I'm still not sure if I did something wrong this time during
> the upgrade and migration and what it might have been, of if something
> else is amiss and merits a bug report.
> 
> akonadi is still uncooperative.  :-(
> 
> It must be related to whatever it runs to start postgres.

Ah wait. Ignore my last mail from 1 minute ago. I mis-read what you were
saying. Sorry for the noise



-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Postgresql upgrade

[Alan McKinnon]

On 29/07/2017 14:27, Mick wrote:
> 
> On 29 July 2017 at 12:19, Mick  > wrote:
> 
> 
> 
> On 29 July 2017 at 12:03, Alan McKinnon  > wrote:
> 
> 
> Don't use kmail
> 
> Seriously, why are putting up with the pain that POS is causing you?
> You've been posting about serious kmail and akonadi issues for
> about 4
> years now if memory serves, and it has never gotten better. It
> probably
> never will :-)
> 
> It must be well more than 4 years.  What can I say, you are right, I
> must be glutton for punishment. LOL!
> 
> TBH, it has been serving me fine for quite a few years now, although
> the migration to akonadi was a painful affair by all accounts.  This
> was originally caused by me using POP3 and a tonne of filters.  I
> moved to IMAP4 and few filters and it all worked relatively
> painlessly since.
> 
> This however must be a postgresql related error, as it worked fine
> before I removed version 9.5.  Any idea what this "Invalid database
> object during initial database connection" might be and how to
> recover from it?


That's the fancy, decorated, code equivalent of "something went wrong".
It's semantically meaningless, but it does say that something went wrong
at the beginning steps somewhere...


> Hmm, even more symlinks have been broken,  This time I spotted
> /usr/bin/psql pointing to a non-existent
> ../lib64/postgresql-9.5/bin/psql.  I came across it when I tried to
> connect to the database manually and couldn't run psql, but could run
> psql96.  I'm still not sure if I did something wrong this time during
> the upgrade and migration and what it might have been, of if something
> else is amiss and merits a bug report.
> 
> akonadi is still uncooperative.  :-(
> 
> It must be related to whatever it runs to start postgres.

Backup the postgres configs and database files, emerge -C all postgres
versions, make sure there are no files left with postgres in the name,
and emerge the version back that you want. Restore your backed up
configs just in case the ebuild wreaked them. Start postgres, the db
should be unaffected as all you did was replace binary code files.


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Postgresql upgrade

[Mick]

On 29 July 2017 at 12:19, Mick  wrote:

>
>
> On 29 July 2017 at 12:03, Alan McKinnon  wrote:
>
>>
>> Don't use kmail
>>
>> Seriously, why are putting up with the pain that POS is causing you?
>> You've been posting about serious kmail and akonadi issues for about 4
>> years now if memory serves, and it has never gotten better. It probably
>> never will :-)
>>
>> It must be well more than 4 years.  What can I say, you are right, I must
> be glutton for punishment. LOL!
>
> TBH, it has been serving me fine for quite a few years now, although the
> migration to akonadi was a painful affair by all accounts.  This was
> originally caused by me using POP3 and a tonne of filters.  I moved to
> IMAP4 and few filters and it all worked relatively painlessly since.
>
> This however must be a postgresql related error, as it worked fine before
> I removed version 9.5.  Any idea what this "Invalid database object during
> initial database connection" might be and how to recover from it?
>

Hmm, even more symlinks have been broken,  This time I spotted
/usr/bin/psql pointing to a non-existent ../lib64/postgresql-9.5/bin/psql.
I came across it when I tried to connect to the database manually and
couldn't run psql, but could run psql96.  I'm still not sure if I did
something wrong this time during the upgrade and migration and what it
might have been, of if something else is amiss and merits a bug report.

akonadi is still uncooperative.  :-(

It must be related to whatever it runs to start postgres.
-- 
Regards,
Mick

Re: [gentoo-user] Postgresql upgrade

[Mick]

On 29 July 2017 at 12:03, Alan McKinnon  wrote:

>
> Don't use kmail
>
> Seriously, why are putting up with the pain that POS is causing you?
> You've been posting about serious kmail and akonadi issues for about 4
> years now if memory serves, and it has never gotten better. It probably
> never will :-)
>
> It must be well more than 4 years.  What can I say, you are right, I must
be glutton for punishment. LOL!

TBH, it has been serving me fine for quite a few years now, although the
migration to akonadi was a painful affair by all accounts.  This was
originally caused by me using POP3 and a tonne of filters.  I moved to
IMAP4 and few filters and it all worked relatively painlessly since.

This however must be a postgresql related error, as it worked fine before I
removed version 9.5.  Any idea what this "Invalid database object during
initial database connection" might be and how to recover from it?
-- 
Regards,
Mick

Re: [gentoo-user] Postgresql upgrade

[Alan McKinnon]

On 29/07/2017 13:01, Mick wrote:
> Right, I would report it, except I can't recall if I ran eselect after
> isntalling 9.6. ... I am *almost* sure I did.
>  
> 
> Meanwhile fix the symlinks to what they should be using "ln -sfn" and
> all will be good in the world.
> 
> --
> Alan McKinnon
> alan.mckin...@gmail.com 
> 
> Thanks Alan, I was hoping this would be the case.  However, the blasted
> akonadi, which is why I am running a database on a laptop in the first
> place, refuses to start:

Don't use kmail

Seriously, why are putting up with the pain that POS is causing you?
You've been posting about serious kmail and akonadi issues for about 4
years now if memory serves, and it has never gotten better. It probably
never will :-)


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] Postgresql upgrade

[Mick]

On 29 July 2017 at 11:12, Alan McKinnon  wrote:

> On 29/07/2017 11:59, Mick wrote:
> > It seems this is one of these things I keep forgetting how to perform
> > correctly, despite taking notes and reading the documentation.  I
> thought I
> > had upgraded postgresql from 9.5.7 to 9.6.3-r1 a couple of weeks ago.
> >
> > Today depclean asked me to remove 9.5.7 and after a moment's hesitation
> I went
> > along with it.  To my surprise I got this at the end of it:
> >
> > [snip...]
> > <<<  dir /usr/include/postgresql-9.5/server/catalog
> > <<<  dir /usr/include/postgresql-9.5/server/bootstrap
> > <<<  dir /usr/include/postgresql-9.5/server/access
> > <<<  dir /usr/include/postgresql-9.5/server
> > <<<  dir /usr/include/postgresql-9.5/libpq
> > <<<  dir /usr/include/postgresql-9.5/internal/libpq
> > <<<  dir /usr/include/postgresql-9.5/internal
> > <<<  dir /usr/include/postgresql-9.5/informix/esql
> > <<<  dir /usr/include/postgresql-9.5/informix
> > <<<  dir /usr/include/postgresql-9.5
> > --- !empty   dir /usr/include
> > --- !empty   dir /usr/bin
> > --- !empty   dir /usr
> > --- !empty   dir /etc/postgresql-9.5
> > --- !empty   dir /etc/pam.d
> > --- !empty   dir /etc/init.d
> > --- !empty   dir /etc/conf.d
> > --- !empty   dir /etc
> > Unsetting 9.5 as default...done.
> > Setting 9.6 as the default...ln: failed to create symbolic link
> > '/usr/include/libpq-fe.h': File exists
> > !!! Error: Unable to create link! postgresql-9.6/libpq-fe.h ->
> > /usr/include/libpq-fe.h
> > exiting
>  Regenerating /etc/ld.so.cache...
> > Packages installed:   1321
> > Packages in world:216
> > Packages in system:   44
> > Required packages:1321
> > Number removed:   1
> >
> >
> > Looking at /usr/include/ I see this:
> >
> > lrwxrwxrwx   1 root root 29 Jul 16 13:56 postgres_ext.h ->
> > postgresql-9.5/postgres_ext.h
> > lrwxrwxrwx   1 root root 14 Jul 29 10:34 postgresql -> postgresql-9.6
> > drwxr-xr-x   6 root root   4096 Jul 16 13:55 postgresql-9.6
> >
> > Although the old /usr/include/postgresql-9.5 directory and file
> postgres_ext.h
> > have been removed, the symlink is still pointint to the old file, rather
> than
> > having been replaced with a symlink to
> > /usr/include/postgresql-9.6/postgres_ext.h:
> >
> > $ ls -la /usr/include/postgresql-9.6/postgres_ext.h
> > -rw-r--r-- 1 root root 2151 Jul 16 13:54
> > /usr/include/postgresql-9.6/postgres_ext.h
> >
> >
> > I'm trying to understand why this might have happened.  Which
> process/action
> > is responsible for setting this symlink?
> >
> > Also, the entry run by depclean above also confused me:
> >
> > Unsetting 9.5 as default...done.
> > Setting 9.6 as the default...
> >
> > How is the default version of postgresql being set in a system?  What
> specific
> > actions do these two entries entail?  I thought with openrc at least it
> is a
> > matter of setting up the latest postgresql version to start up in
> rc-update.
> >
> > I've replaced the symlink with the live postgresql manually for now - I
> hope I
> > haven't borked the database ...
> >
>
>
> postgresql is slotted, so various headers files and such need symlinks
> installed so postgresql uses the correct versioned file. You have 2
> versions, which one is correct? - the one the symlink points to.
>
> Yes, but what confused me is that this symlink was correct:

 postgresql -> postgresql-9.6

while all others weren't.


> Installing 9.6 on a host with 9.5 present does only that - installs it.
> It doesn't run it or set it as default, it only installs it. To run it
> or set it as default is an extra step that you decide yourself when you
> want to do it.
>
> depcleaning 9.5 removes the default version, so the obvious thing for
> the code to do is set 9.6 as the new default. Maybe the ebuild does it,
> maybe it's eselect. Doesn't matter, because something should have
> removed those stale symlinks and didn't. This is a reportable bug
>
> Right, I would report it, except I can't recall if I ran eselect after
isntalling 9.6. ... I am *almost* sure I did.


> Meanwhile fix the symlinks to what they should be using "ln -sfn" and
> all will be good in the world.
>
> --
> Alan McKinnon
> alan.mckin...@gmail.com
>
> Thanks Alan, I was hoping this would be the case.  However, the blasted
akonadi, which is why I am running a database on a laptop in the first
place, refuses to start:

[11:34:27] ~ $ akonadictl start
Starting Akonadi Server...
   done.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
[11:34:38] ~ $ QSqlDatabase: QPSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QPSQL7 QPSQL
Invalid database object during initial database connection
"[
0: akonadiserver(_Z11akBacktracev+0x4a) [0x463ada]
1: akonadiserver() [0x463dab]
2: /lib64/libc.so.6(+0x33170) [0x7f454d39d170]
3: /lib64/libc.so.6(gsignal+0x38) 

Re: [gentoo-user] Postgresql upgrade

[Alan McKinnon]

On 29/07/2017 11:59, Mick wrote:
> It seems this is one of these things I keep forgetting how to perform 
> correctly, despite taking notes and reading the documentation.  I thought I 
> had upgraded postgresql from 9.5.7 to 9.6.3-r1 a couple of weeks ago.
> 
> Today depclean asked me to remove 9.5.7 and after a moment's hesitation I 
> went 
> along with it.  To my surprise I got this at the end of it:
> 
> [snip...]
> <<<  dir /usr/include/postgresql-9.5/server/catalog
> <<<  dir /usr/include/postgresql-9.5/server/bootstrap
> <<<  dir /usr/include/postgresql-9.5/server/access
> <<<  dir /usr/include/postgresql-9.5/server
> <<<  dir /usr/include/postgresql-9.5/libpq
> <<<  dir /usr/include/postgresql-9.5/internal/libpq
> <<<  dir /usr/include/postgresql-9.5/internal
> <<<  dir /usr/include/postgresql-9.5/informix/esql
> <<<  dir /usr/include/postgresql-9.5/informix
> <<<  dir /usr/include/postgresql-9.5
> --- !empty   dir /usr/include
> --- !empty   dir /usr/bin
> --- !empty   dir /usr
> --- !empty   dir /etc/postgresql-9.5
> --- !empty   dir /etc/pam.d
> --- !empty   dir /etc/init.d
> --- !empty   dir /etc/conf.d
> --- !empty   dir /etc
> Unsetting 9.5 as default...done.
> Setting 9.6 as the default...ln: failed to create symbolic link 
> '/usr/include/libpq-fe.h': File exists
> !!! Error: Unable to create link! postgresql-9.6/libpq-fe.h -> 
> /usr/include/libpq-fe.h
> exiting
 Regenerating /etc/ld.so.cache...
> Packages installed:   1321
> Packages in world:216
> Packages in system:   44
> Required packages:1321
> Number removed:   1
> 
> 
> Looking at /usr/include/ I see this:
> 
> lrwxrwxrwx   1 root root 29 Jul 16 13:56 postgres_ext.h -> 
> postgresql-9.5/postgres_ext.h
> lrwxrwxrwx   1 root root 14 Jul 29 10:34 postgresql -> postgresql-9.6
> drwxr-xr-x   6 root root   4096 Jul 16 13:55 postgresql-9.6
> 
> Although the old /usr/include/postgresql-9.5 directory and file 
> postgres_ext.h 
> have been removed, the symlink is still pointint to the old file, rather than 
> having been replaced with a symlink to 
> /usr/include/postgresql-9.6/postgres_ext.h:
> 
> $ ls -la /usr/include/postgresql-9.6/postgres_ext.h 
> -rw-r--r-- 1 root root 2151 Jul 16 13:54 
> /usr/include/postgresql-9.6/postgres_ext.h
> 
> 
> I'm trying to understand why this might have happened.  Which process/action 
> is responsible for setting this symlink?  
> 
> Also, the entry run by depclean above also confused me:
> 
> Unsetting 9.5 as default...done.
> Setting 9.6 as the default...
> 
> How is the default version of postgresql being set in a system?  What 
> specific 
> actions do these two entries entail?  I thought with openrc at least it is a 
> matter of setting up the latest postgresql version to start up in rc-update. 
> 
> I've replaced the symlink with the live postgresql manually for now - I hope 
> I 
> haven't borked the database ...
> 



postgresql is slotted, so various headers files and such need symlinks
installed so postgresql uses the correct versioned file. You have 2
versions, which one is correct? - the one the symlink points to.

Installing 9.6 on a host with 9.5 present does only that - installs it.
It doesn't run it or set it as default, it only installs it. To run it
or set it as default is an extra step that you decide yourself when you
want to do it.

depcleaning 9.5 removes the default version, so the obvious thing for
the code to do is set 9.6 as the new default. Maybe the ebuild does it,
maybe it's eselect. Doesn't matter, because something should have
removed those stale symlinks and didn't. This is a reportable bug

Meanwhile fix the symlinks to what they should be using "ln -sfn" and
all will be good in the world.

-- 
Alan McKinnon
alan.mckin...@gmail.com

[gentoo-user] Postgresql upgrade

[Mick]

It seems this is one of these things I keep forgetting how to perform 
correctly, despite taking notes and reading the documentation.  I thought I 
had upgraded postgresql from 9.5.7 to 9.6.3-r1 a couple of weeks ago.

Today depclean asked me to remove 9.5.7 and after a moment's hesitation I went 
along with it.  To my surprise I got this at the end of it:

[snip...]
<<<  dir /usr/include/postgresql-9.5/server/catalog
<<<  dir /usr/include/postgresql-9.5/server/bootstrap
<<<  dir /usr/include/postgresql-9.5/server/access
<<<  dir /usr/include/postgresql-9.5/server
<<<  dir /usr/include/postgresql-9.5/libpq
<<<  dir /usr/include/postgresql-9.5/internal/libpq
<<<  dir /usr/include/postgresql-9.5/internal
<<<  dir /usr/include/postgresql-9.5/informix/esql
<<<  dir /usr/include/postgresql-9.5/informix
<<<  dir /usr/include/postgresql-9.5
--- !empty   dir /usr/include
--- !empty   dir /usr/bin
--- !empty   dir /usr
--- !empty   dir /etc/postgresql-9.5
--- !empty   dir /etc/pam.d
--- !empty   dir /etc/init.d
--- !empty   dir /etc/conf.d
--- !empty   dir /etc
Unsetting 9.5 as default...done.
Setting 9.6 as the default...ln: failed to create symbolic link 
'/usr/include/libpq-fe.h': File exists
!!! Error: Unable to create link! postgresql-9.6/libpq-fe.h -> 
/usr/include/libpq-fe.h
exiting
>>> Regenerating /etc/ld.so.cache...
Packages installed:   1321
Packages in world:216
Packages in system:   44
Required packages:1321
Number removed:   1


Looking at /usr/include/ I see this:

lrwxrwxrwx   1 root root 29 Jul 16 13:56 postgres_ext.h -> 
postgresql-9.5/postgres_ext.h
lrwxrwxrwx   1 root root 14 Jul 29 10:34 postgresql -> postgresql-9.6
drwxr-xr-x   6 root root   4096 Jul 16 13:55 postgresql-9.6

Although the old /usr/include/postgresql-9.5 directory and file postgres_ext.h 
have been removed, the symlink is still pointint to the old file, rather than 
having been replaced with a symlink to 
/usr/include/postgresql-9.6/postgres_ext.h:

$ ls -la /usr/include/postgresql-9.6/postgres_ext.h 
-rw-r--r-- 1 root root 2151 Jul 16 13:54 
/usr/include/postgresql-9.6/postgres_ext.h


I'm trying to understand why this might have happened.  Which process/action 
is responsible for setting this symlink?  

Also, the entry run by depclean above also confused me:

Unsetting 9.5 as default...done.
Setting 9.6 as the default...

How is the default version of postgresql being set in a system?  What specific 
actions do these two entries entail?  I thought with openrc at least it is a 
matter of setting up the latest postgresql version to start up in rc-update. 

I've replaced the symlink with the live postgresql manually for now - I hope I 
haven't borked the database ...
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.