Bug#545139: Re: Bug#545139: fixed in akonadi 1.3.1-4
21:59, Magnus Holmgren rašė: On lördagen den 30 april 2011, you stated the following: Changes: akonadi (1.3.1-4) unstable; urgency=low . * Add patch 04_socket_location.diff to allow akonadi-server to run when HOME is mounted to the network filesystem (Closes: #545139). Thanks to Ansgar Burchardt for the patch. After upgrading to that version, kmail stopped working because it (or rather libakonadi-kde4, or libakonadiprivate1?) still tries to use the old socket path. To be honest, your statement is conflicting. kmail *stopped* working because it still tries to use *old* socket path. It is either kmail worked before (with old path) or it didn't (hence you need new path). Sorry, but I don't understand. What have I missed regarding how clients find the socket? (No socket path is defined in ~/.config/akonadi/akonadiserverrc, so the new default is used.) Akonadi is supposed to create a socket in /tmp only if it can't do that in $HOME. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545139: Re: Bug#545139: fixed in akonadi 1.3.1-4
Modestas Vainius mo...@debian.org writes: 21:59, Magnus Holmgren rašė: On lördagen den 30 april 2011, you stated the following: Changes: akonadi (1.3.1-4) unstable; urgency=low . * Add patch 04_socket_location.diff to allow akonadi-server to run when HOME is mounted to the network filesystem (Closes: #545139). Thanks to Ansgar Burchardt for the patch. After upgrading to that version, kmail stopped working because it (or rather libakonadi-kde4, or libakonadiprivate1?) still tries to use the old socket path. To be honest, your statement is conflicting. kmail *stopped* working because it still tries to use *old* socket path. It is either kmail worked before (with old path) or it didn't (hence you need new path). Sorry, but I don't understand. What have I missed regarding how clients find the socket? (No socket path is defined in ~/.config/akonadi/akonadiserverrc, so the new default is used.) Akonadi is supposed to create a socket in /tmp only if it can't do that in $HOME. No, with the patch akonadi will always create the socket in /tmp and only place a symlink in $HOME (unless SocketDirectory is set in the configuration). This means that new processes will not be able to connect to the old socket after an upgrade; it should work correctly once the database process is restarted. I did not bother with caring about the upgrade case when I wrote the initial patch, but for a stable update we might want to look for an already existing socket in the old location first. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545139: Re: Bug#545139: fixed in akonadi 1.3.1-4
Hello, On antradienis 07 Birželis 2011 16:05:06 Ansgar Burchardt wrote: Modestas Vainius mo...@debian.org writes: 21:59, Magnus Holmgren rašė: On lördagen den 30 april 2011, you stated the following: Changes: akonadi (1.3.1-4) unstable; urgency=low . * Add patch 04_socket_location.diff to allow akonadi-server to run when HOME is mounted to the network filesystem (Closes: #545139). Thanks to Ansgar Burchardt for the patch. After upgrading to that version, kmail stopped working because it (or rather libakonadi-kde4, or libakonadiprivate1?) still tries to use the old socket path. To be honest, your statement is conflicting. kmail *stopped* working because it still tries to use *old* socket path. It is either kmail worked before (with old path) or it didn't (hence you need new path). Sorry, but I don't understand. What have I missed regarding how clients find the socket? (No socket path is defined in ~/.config/akonadi/akonadiserverrc, so the new default is used.) Akonadi is supposed to create a socket in /tmp only if it can't do that in $HOME. No, with the patch akonadi will always create the socket in /tmp and only place a symlink in $HOME (unless SocketDirectory is set in the configuration). This means that new processes will not be able to connect to the old socket after an upgrade; it should work correctly once the database process is restarted. I did not bother with caring about the upgrade case when I wrote the initial patch, but for a stable update we might want to look for an already existing socket in the old location first. Stable update has been requested a month and a half ago [1] and, apparently, already is a pretty complicated decision for release team. So please make this as painless as possible or it may never get to stable. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624647 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
