Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Le mercredi 16 avril 2008 à 17:28 +0200, Alexander Klauer a écrit : Olivier Berger: Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit : # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1 web based groupware system written in PHP Strange... it seems the phpgroupware package isn't installed... as an epoch 1 package. Correct. The phpgroupware version 0.9.16.012+dfsg-1 (non-epoch) package was installed for quite some time, and then marked as to-be-removed by aptitude for unsatisfied dependencies two days ago (this happens sometimes, as new packages appear in lenny and their dependencies change); I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? the current version of the phpgroupware binary package is only transitional anyway, it being replaced by phpgroupware-0.9.16. Hmmm... I'm afraid it's not exactly that. But it's a bit too complex maybe : From the description of the new phpgroupware package : This empty package is a transition package to the new phpgroupware-0.9.16-* (epoch 1) packages for phpGroupware. . See package phpgroupware-0.9.16 instead. . Note that all phpgroupware apps previously packaged (epoch 0) may no longer be available. . After successful upgrade, this package can be safely removed. Thus, it's meant to be upgraded first, and then maybe afterwards removed, as the last sentence explains it. The problem seems to be that such procedure can be avoided... and I couldn't find a way to avoid that without adding too many dependencies for cases of new installations drom scratch. It was difficult to do it any other way I'm afraid :( Is this clear ? So I selected phpgroupware-0.9.16-calendar, phpgroupware-0.9.16-manual and phpgroupware-0.9.16-doc for installation. All the other packages were selected by aptitude to satisfy dependencies. phpgroupware-0.9.16 was NOT among them. Right : it's only a meta package now. This one is not really necessary now maybe... but it prepares a path for appearance of a future phpgroupware-0.9.18 package some day. (Both would conflict with eachother probably, being in the distro at the same time) Maybe a missing dependency in the package? No. The one which others depend on is now phpgroupware-0.9.16-core-base. It's the one which now provides the debconf scripts and stuff for Debianisation of phpGW (which used to be provided by the phpgroupware package). Installing this package would pull in the phpgroupware-0.9.16-core package, which in turn would pull in a lot of other phpgroupware modules through Recommends. Yes indeed. The idea is that phpgroupware-0.9.16-core is too a meta package (depending on all core groupware modules). I'd expect to see phpgroupware (1:0.9.16.012+dfsg-2) there (see http://packages.debian.org/lenny/phpgroupware) ... Maybe that explains the issue that you had ? I think you mean phpgroupware-0.9.16, not phpgroupware. Well, maybe yes, but then phpgroupware-0.9.16-calendar etc. should Depends on phpgroupware-0.9.16 somewhere down the chain. No, as I explained above. I hope the picture is a bit clearer now... still a schema may be necessary for a better explanation ? ;) I'm not exactly sure what rc means... removed+unconfigured ? Package removed, configuration files still installed. Thanks. That's what I guessed it was. (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. So I'd say the bug may be fixed then. It worked just fine until the reboot. I cannot rule out that I inadvertently tested the old installation (or parts of it) somehow before the reboot. In any case, aptitude had finished the installation, of course, before I began testing. Do you have an idea of what happened during the upgrade (which apt frontend used, also) ? aptitude, see above. Maybe you should reinstall the phpgroupware package (version 1:0.9.16.012+dfsg-2), and maybe remove it once it's installed OK, just for the sake of a clean system ? I'm quite content that it works now. From what you told me above, my guess is a Depends or a Replaces was missing somewhere. If it's an issue of the phpgroupware - phpgroupware-0.9.16 transition only, this bug may be quite irrelevant in testing, but please make sure the etch-lenny transition works flawlessly, once lenny becomes stable. Thank you! Yes, that's a concern we have with this upgrade process... Hmmm... I guess we may need a second think about all this, and your comments were definitely valuable. Maybe I devised the dependency scheme for the new packages with a bit too many constraints at the same time... I'll try and do more upgrade tests, but
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Le mercredi 16 avril 2008 à 23:23 +0200, Olivier Berger a écrit : Le mercredi 16 avril 2008 à 17:28 +0200, Alexander Klauer a écrit : Olivier Berger: Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit : # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1 web based groupware system written in PHP Strange... it seems the phpgroupware package isn't installed... as an epoch 1 package. Correct. The phpgroupware version 0.9.16.012+dfsg-1 (non-epoch) package was installed for quite some time, and then marked as to-be-removed by aptitude for unsatisfied dependencies two days ago (this happens sometimes, as new packages appear in lenny and their dependencies change); I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? SNIP Anyway, all this rant may not have been the cause for the rights problem with the sessions directory... I was just puzzled by the status of the package in your report. I'll try and investigate the rights problem and see what's the real cause. Bets regards, -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Olivier Berger: I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? aptitude chose to remove it (instead of upgrading), presumably because otherwise some packages would have been broken. I then selected the calendar and manual modules only, missing the core package. As it is with the testing release, the initial breakage may have been caused by who knows what. Anyway, all this rant may not have been the cause for the rights problem with the sessions directory... I was just puzzled by the status of the package in your report. I'll try and investigate the rights problem and see what's the real cause. Thanks! Also thanks for your previous email, explaining things. I dug around in my system and found an aptitude log: Aptitude 0.4.10: log report Mon, Apr 14 2008 10:18:30 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 163 packages, and remove 17 packages. 7057kB of disk space will be freed === [REMOVE, NOT USED] lapack3 [REMOVE, NOT USED] libc-client2007 [REMOVE, NOT USED] libneon27-gnutls [REMOVE, NOT USED] libsndfile1 [REMOVE, NOT USED] libsuitesparse [REMOVE, NOT USED] mlock [REMOVE, NOT USED] openoffice.org-style-hicontrast [REMOVE, NOT USED] openoffice.org-style-industrial [REMOVE, NOT USED] php5-imap [REMOVE, NOT USED] phpgroupware [INSTALL, DEPENDENCIES] libblas3gf [INSTALL, DEPENDENCIES] libcurl3 [INSTALL, DEPENDENCIES] libgfortran3 [INSTALL, DEPENDENCIES] liblapack3gf [INSTALL, DEPENDENCIES] libssh2-1 [INSTALL, DEPENDENCIES] libstlport4.6ldbl [INSTALL, DEPENDENCIES] libsuitesparse-3.1.0 [INSTALL, DEPENDENCIES] libtotem-plparser10 [INSTALL, DEPENDENCIES] openoffice.org-writer2latex [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-admin [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-core-base [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-phpgwapi [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-preferences [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-setup [REMOVE, DEPENDENCIES] libstlport4.6c2 [REMOVE, DEPENDENCIES] phpgroupware-admin [REMOVE, DEPENDENCIES] phpgroupware-calendar [REMOVE, DEPENDENCIES] phpgroupware-manual [REMOVE, DEPENDENCIES] phpgroupware-phpgwapi [REMOVE, DEPENDENCIES] phpgroupware-preferences [REMOVE, DEPENDENCIES] phpgroupware-setup [INSTALL] phpgroupware-0.9.16-calendar [INSTALL] phpgroupware-0.9.16-doc [INSTALL] phpgroupware-0.9.16-manual [UPGRADE] aspell 0.60.5-2 - 0.60.5-2.1 ... snip lotsa unrelated upgrades ... [UPGRADE] wwwconfig-common 0.0.48 - 0.1.0 === Log complete. I'm not entirely fluent with aptitude's dependency stuff, but what might have happened is this: 1. Once upon a time, I decided to install phpgroupware-calendar (among some other modules, but for simplicity let's pretend it's only the calendar). 2. aptitude resolved the dependencies and selected the phpgroupware package for installation, marking it automatic. 3. Then April 14th came: I pressed u, then U for complete system upgrade and a lot of phpgroupware dependencies were broken, so aptitude decided to select calendar for removal in order to preserve an unbroken system state. 4. Seeing that all installed packages which depend on phpgroupware were selected for removal, aptitude also selected phpgroupware for removal because it was marked automatic. 5. Me, seeing phpgroupware is about to be removed, selects phpgroupware-0.9.16-calendar. However, phpgroupware-0.9.16 is not selected, as it's not in the dependency list (this is what's not intended in this situation, but difficult to fix, right?). How, in this situation, it came to be that the permissions were broken, I cannot tell. I hope this info helps you a little anyway. Best regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Hi. By testing a bit further the upgrade path from epoch0 to epoch1 packages, I have discovered a nasty bug (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476559) which can lead to loss of all phpgroupware data :( So, please DO NOT PURGE the removed phpgroupware (epoch 0) package. Thanks for helping me isolate that one. I'm doing my best to upload a fixed package ASAP. Best regards, Le jeudi 17 avril 2008 à 11:53 +0200, Alexander Klauer a écrit : Olivier Berger: I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? aptitude chose to remove it (instead of upgrading), presumably because otherwise some packages would have been broken. I then selected the calendar and manual modules only, missing the core package. As it is with the testing release, the initial breakage may have been caused by who knows what. Anyway, all this rant may not have been the cause for the rights problem with the sessions directory... I was just puzzled by the status of the package in your report. I'll try and investigate the rights problem and see what's the real cause. Thanks! Also thanks for your previous email, explaining things. I dug around in my system and found an aptitude log: Aptitude 0.4.10: log report Mon, Apr 14 2008 10:18:30 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 163 packages, and remove 17 packages. 7057kB of disk space will be freed === [REMOVE, NOT USED] lapack3 [REMOVE, NOT USED] libc-client2007 [REMOVE, NOT USED] libneon27-gnutls [REMOVE, NOT USED] libsndfile1 [REMOVE, NOT USED] libsuitesparse [REMOVE, NOT USED] mlock [REMOVE, NOT USED] openoffice.org-style-hicontrast [REMOVE, NOT USED] openoffice.org-style-industrial [REMOVE, NOT USED] php5-imap [REMOVE, NOT USED] phpgroupware [INSTALL, DEPENDENCIES] libblas3gf [INSTALL, DEPENDENCIES] libcurl3 [INSTALL, DEPENDENCIES] libgfortran3 [INSTALL, DEPENDENCIES] liblapack3gf [INSTALL, DEPENDENCIES] libssh2-1 [INSTALL, DEPENDENCIES] libstlport4.6ldbl [INSTALL, DEPENDENCIES] libsuitesparse-3.1.0 [INSTALL, DEPENDENCIES] libtotem-plparser10 [INSTALL, DEPENDENCIES] openoffice.org-writer2latex [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-admin [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-core-base [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-phpgwapi [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-preferences [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-setup [REMOVE, DEPENDENCIES] libstlport4.6c2 [REMOVE, DEPENDENCIES] phpgroupware-admin [REMOVE, DEPENDENCIES] phpgroupware-calendar [REMOVE, DEPENDENCIES] phpgroupware-manual [REMOVE, DEPENDENCIES] phpgroupware-phpgwapi [REMOVE, DEPENDENCIES] phpgroupware-preferences [REMOVE, DEPENDENCIES] phpgroupware-setup [INSTALL] phpgroupware-0.9.16-calendar [INSTALL] phpgroupware-0.9.16-doc [INSTALL] phpgroupware-0.9.16-manual [UPGRADE] aspell 0.60.5-2 - 0.60.5-2.1 ... snip lotsa unrelated upgrades ... [UPGRADE] wwwconfig-common 0.0.48 - 0.1.0 === Log complete. I'm not entirely fluent with aptitude's dependency stuff, but what might have happened is this: 1. Once upon a time, I decided to install phpgroupware-calendar (among some other modules, but for simplicity let's pretend it's only the calendar). 2. aptitude resolved the dependencies and selected the phpgroupware package for installation, marking it automatic. 3. Then April 14th came: I pressed u, then U for complete system upgrade and a lot of phpgroupware dependencies were broken, so aptitude decided to select calendar for removal in order to preserve an unbroken system state. 4. Seeing that all installed packages which depend on phpgroupware were selected for removal, aptitude also selected phpgroupware for removal because it was marked automatic. 5. Me, seeing phpgroupware is about to be removed, selects phpgroupware-0.9.16-calendar. However, phpgroupware-0.9.16 is not selected, as it's not in the dependency list (this is what's not intended in this situation, but difficult to fix, right?). How, in this situation, it came to be that the permissions were broken, I cannot tell. I hope this info helps you a little anyway. Best regards, Alexander -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry
Bug#476559: Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Hi. I think more appropriate to continue this discussion in bug #476559 as it's the one which I filed for this upgrade problems. Le jeudi 17 avril 2008 à 11:53 +0200, Alexander Klauer a écrit : Olivier Berger: I'm surprised that it would have been to be removed, instead of upgraded by the new phpgroupware package (yes, the transition one). Maybe you chose to remove it instead of upgrading it ? aptitude chose to remove it (instead of upgrading), presumably because otherwise some packages would have been broken. Indeed, there was an explicit conflict in phpgroupware-0.9.16-core-base with epoch0 versions of the 'phpgroupware' package to have the two sets of package mutually exclusive. I then selected the calendar and manual modules only, missing the core package. As it is with the testing release, the initial breakage may have been caused by who knows what. Anyway, all this rant may not have been the cause for the rights problem with the sessions directory... I was just puzzled by the status of the package in your report. I'll try and investigate the rights problem and see what's the real cause. Thanks! Also thanks for your previous email, explaining things. Thanks alot. It's a bit too much maybe for the BTS... but may help in the future in case of maintainer change for instance ;) I dug around in my system and found an aptitude log: Aptitude 0.4.10: log report Mon, Apr 14 2008 10:18:30 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 163 packages, and remove 17 packages. 7057kB of disk space will be freed === [REMOVE, NOT USED] lapack3 [REMOVE, NOT USED] libc-client2007 [REMOVE, NOT USED] libneon27-gnutls [REMOVE, NOT USED] libsndfile1 [REMOVE, NOT USED] libsuitesparse [REMOVE, NOT USED] mlock [REMOVE, NOT USED] openoffice.org-style-hicontrast [REMOVE, NOT USED] openoffice.org-style-industrial [REMOVE, NOT USED] php5-imap [REMOVE, NOT USED] phpgroupware [INSTALL, DEPENDENCIES] libblas3gf [INSTALL, DEPENDENCIES] libcurl3 [INSTALL, DEPENDENCIES] libgfortran3 [INSTALL, DEPENDENCIES] liblapack3gf [INSTALL, DEPENDENCIES] libssh2-1 [INSTALL, DEPENDENCIES] libstlport4.6ldbl [INSTALL, DEPENDENCIES] libsuitesparse-3.1.0 [INSTALL, DEPENDENCIES] libtotem-plparser10 [INSTALL, DEPENDENCIES] openoffice.org-writer2latex [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-admin [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-core-base [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-phpgwapi [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-preferences [INSTALL, DEPENDENCIES] phpgroupware-0.9.16-setup [REMOVE, DEPENDENCIES] libstlport4.6c2 [REMOVE, DEPENDENCIES] phpgroupware-admin [REMOVE, DEPENDENCIES] phpgroupware-calendar [REMOVE, DEPENDENCIES] phpgroupware-manual [REMOVE, DEPENDENCIES] phpgroupware-phpgwapi [REMOVE, DEPENDENCIES] phpgroupware-preferences [REMOVE, DEPENDENCIES] phpgroupware-setup [INSTALL] phpgroupware-0.9.16-calendar [INSTALL] phpgroupware-0.9.16-doc [INSTALL] phpgroupware-0.9.16-manual [UPGRADE] aspell 0.60.5-2 - 0.60.5-2.1 ... snip lotsa unrelated upgrades ... [UPGRADE] wwwconfig-common 0.0.48 - 0.1.0 === Log complete. I'm not entirely fluent with aptitude's dependency stuff, but what might have happened is this: 1. Once upon a time, I decided to install phpgroupware-calendar (among some other modules, but for simplicity let's pretend it's only the calendar). 2. aptitude resolved the dependencies and selected the phpgroupware package for installation, marking it automatic. 3. Then April 14th came: I pressed u, then U for complete system upgrade and a lot of phpgroupware dependencies were broken, so aptitude decided to select calendar for removal in order to preserve an unbroken system state. 4. Seeing that all installed packages which depend on phpgroupware were selected for removal, aptitude also selected phpgroupware for removal because it was marked automatic. Not exactly as I explained above, but same result. 5. Me, seeing phpgroupware is about to be removed, selects phpgroupware-0.9.16-calendar. However, phpgroupware-0.9.16 is not selected, as it's not in the dependency list (this is what's not intended in this situation, but difficult to fix, right?). No. phpgroupware-0.9.16-calendar should only depend on phpgroupware-0.9.16-core-base, whereas phpgroupware-0.9.16 is just a meta-package. How, in this situation, it came to be that the permissions were broken, I cannot tell. I hope this info helps you a little anyway. The permission problem had nothing to do with the fact that 'phpgroupware' was removed instead of upgraded... but I hope that the investigation, which lead to the present #476559, was worth the questioning... let's hope that nobody
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Hello. Le mercredi 16 avril 2008 à 13:33 +, Debian Bug Tracking System a écrit : Processing commands for [EMAIL PROTECTED]: found 327249 1:0.9.16.012+dfsg-2 Bug#327249: phpgroupware: php session doesn't work Bug marked as found in version 1:0.9.16.012+dfsg-2 and reopened. Can you elaborate a little bit on what's happening exactly (logs, permissions of files/dirs) ? Many thanks in advance. -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Hi, Olivier Berger: Can you elaborate a little bit on what's happening exactly (logs, permissions of files/dirs) ? sure. The machine is running lenny, Debian kernel 2.6.24-1-686, no frills. On Monday (i.e. two days ago) I upgraded, installing the new phpgroupware: # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1web based groupware system written in PHP ii phpgroupware-0.9.16-admin1:0.9.16.012+dfsg-2 phpGroupWare administration module ii phpgroupware-0.9.16-calendar 1:0.9.16.012+dfsg-2 phpGroupWare calendar management module ii phpgroupware-0.9.16-core-base1:0.9.16.012+dfsg-2 Base components of the phpGroupware applica ii phpgroupware-0.9.16-doc 1:0.9.16.012+dfsg-2 Documentation of phpGroupware 0.9.16 ii phpgroupware-0.9.16-manual 1:0.9.16.012+dfsg-2 phpGroupWare on-line manual module ii phpgroupware-0.9.16-phpgwapi 1:0.9.16.012+dfsg-2 library of common phpGroupWare functions ii phpgroupware-0.9.16-preferences 1:0.9.16.012+dfsg-2 phpGroupWare preferences management module ii phpgroupware-0.9.16-setup1:0.9.16.012+dfsg-2 phpGroupWare setup III module (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. Today, a colleague restarted the machine and phpgroupware stopped working: when trying to log in, the error message Your session could not be verified appeared. The corresponding apache2 error log messages looked like [Wed Apr 16 14:55:35 2008] [error] [client X.X.X.X] PHP Warning: session_start() [a href='function.session-start'function.session-start/a]: open(/var/lib/phpgroupware/sessions/sess_a919fffee984f34236ae320f3bc67123, O_RDWR) failed: Permission denied (13) in /usr/share/phpgroupware/phpgwapi/inc/class.sessions_php4.inc.php on line 44, referer: https://our.phpgroupware.host/phpgroupware/login.php [Wed Apr 16 14:55:35 2008] [error] [client X.X.X.X] PHP Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/phpgroupware/sessions) in Unknown on line 0, referer: https://our.phpgroupware.host/phpgroupware/login.php I checked the BTS and found #327249. Doing a chmod -R www-data.www-data /var/lib/phpgroupware immediately solved the problem, so I marked the bug as found. Previous permissions were root.root. HTH regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Please keep [EMAIL PROTECTED] in CC: of further exchanges, Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit : # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1web based groupware system written in PHP Strange... it seems the phpgroupware package isn't installed... as an epoch 1 package. I'd expect to see phpgroupware (1:0.9.16.012+dfsg-2) there (see http://packages.debian.org/lenny/phpgroupware) ... Maybe that explains the issue that you had ? I'm not exactly sure what rc means... removed+unconfigured ? (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. So I'd say the bug may be fixed then. Do you have an idea of what happened during the upgrade (which apt frontend used, also) ? Maybe you should reinstall the phpgroupware package (version 1:0.9.16.012+dfsg-2), and maybe remove it once it's installed OK, just for the sake of a clean system ? Regards, -- Olivier BERGER [EMAIL PROTECTED] (*NEW ADDRESS*) http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM / TELECOM Management SudParis (http://www.it-sudparis.eu/), Evry
Bug#327249: Processed: /var/lib/phpgroupware owned by root instead of www-data
Olivier Berger: Please keep [EMAIL PROTECTED] in CC: of further exchanges, (sending to [EMAIL PROTECTED] only, as BTS says it's forwarding these messages to you.) Le mercredi 16 avril 2008 à 16:19 +0200, Alexander Klauer a écrit : # dpkg -l | grep phpgroupware rc phpgroupware 0.9.16.012+dfsg-1 web based groupware system written in PHP Strange... it seems the phpgroupware package isn't installed... as an epoch 1 package. Correct. The phpgroupware version 0.9.16.012+dfsg-1 (non-epoch) package was installed for quite some time, and then marked as to-be-removed by aptitude for unsatisfied dependencies two days ago (this happens sometimes, as new packages appear in lenny and their dependencies change); the current version of the phpgroupware binary package is only transitional anyway, it being replaced by phpgroupware-0.9.16. So I selected phpgroupware-0.9.16-calendar, phpgroupware-0.9.16-manual and phpgroupware-0.9.16-doc for installation. All the other packages were selected by aptitude to satisfy dependencies. phpgroupware-0.9.16 was NOT among them. Maybe a missing dependency in the package? Installing this package would pull in the phpgroupware-0.9.16-core package, which in turn would pull in a lot of other phpgroupware modules through Recommends. I'd expect to see phpgroupware (1:0.9.16.012+dfsg-2) there (see http://packages.debian.org/lenny/phpgroupware) ... Maybe that explains the issue that you had ? I think you mean phpgroupware-0.9.16, not phpgroupware. Well, maybe yes, but then phpgroupware-0.9.16-calendar etc. should Depends on phpgroupware-0.9.16 somewhere down the chain. I'm not exactly sure what rc means... removed+unconfigured ? Package removed, configuration files still installed. (configuration files of the old phpgroupware still exist; maybe that's the source of the problem). I also tested the new installation with a test account. Everything worked just fine. So I'd say the bug may be fixed then. It worked just fine until the reboot. I cannot rule out that I inadvertently tested the old installation (or parts of it) somehow before the reboot. In any case, aptitude had finished the installation, of course, before I began testing. Do you have an idea of what happened during the upgrade (which apt frontend used, also) ? aptitude, see above. Maybe you should reinstall the phpgroupware package (version 1:0.9.16.012+dfsg-2), and maybe remove it once it's installed OK, just for the sake of a clean system ? I'm quite content that it works now. From what you told me above, my guess is a Depends or a Replaces was missing somewhere. If it's an issue of the phpgroupware - phpgroupware-0.9.16 transition only, this bug may be quite irrelevant in testing, but please make sure the etch-lenny transition works flawlessly, once lenny becomes stable. Thank you! Best regards, Alexander
