[Cooker] [Bug 5308] [subversion-repos] svnadmin create seems to be creating wrong repository format
http://qa.mandrakesoft.com/show_bug.cgi?id=5308 --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 03:06 --- I think I am missing something here, because I do not see where you (Oden) read that 0.29.0 can handle old repositories. So just to be sure: In 0.28.0 an incompatible database format change has been introduced, changing the format from version 1 to 2. A 0.29.0 svnadmin can only handle format version 2, i.e. all repositories created by 0.28.0 or later, but will fail on those created by 0.27.0 or earlier. (insert disclamer about about coming changes). The same goes the other way around, e.g. 0.26.0 can only read format version 1, that is repositories created by versions up to 0.27.0, not any created by 0.28.0 or later. So, in order to upgrade, every format version 1 repository has to be dumped, preferably with the version it has been last used with. And has to be re-created with the new version of svnadmin. The official announcement can be found here: http://subversion.tigris.org/servlets/NewsItemView?newsItemID=461 This behaviour is by intention. The dump format has been chosen as the invariant in the upgrade process, so that upgrades to Subversion's internals are possible without having to carry around compatibility layers around for the centuries to come (well, that's my interpretation, the Subversion developers wording would probably differ ;-). With the tarballs, it is not much of a problem, because if one reads the release announcement, and learns about the dump-load cycle, the old svnadmin is usually still lying around. It mainly becomes a problem with automatic package updates, because it may be difficult to downgrade again. Sorry, if all this was already obvious to you all. I had the impression it might not and thought the explanation can't hurt. I have no solution to offer, either. One idea would be to create a subversion-admin0.27 package, i.e. a special package only containing everything needed for executing svnadmin dump (statically compiled?). Could be a complete subversion, if it is easier to do for you. Disadvantage is that it is not the recommended procedure (which is to use the currently used version for the dump, which is not necessarily 0.27.0), but is probably better than nothing. Best would be if you could save the installed svnadmin before installing the new version, but with an dynamic binary, that will be too cumbersome, I fear (all the dependencies - particularly the repos lib has to be the format 1 one). Thinking about it, it would be probably had been good, if it was like a major version upgrade (like gnome1.2 and gnome2.0), so that we got subversion0.28 instead of subversion-0.28.0 and people would have to take an active role for the upgrade (and the old version would still be installed). Yes, I am aware that the subversion0.28 name is already non-fitting anymore. Call it after0.27 or so. You are the bright guys here, I am sure you can come up with something. ;-) Anyhow, that doesn't help us now, because the packages are already out. The good news is, that they don't plan (but give no guarantee either) another incompatible format change up to, and including, 1.0 (hopefully out on sylvester ;-). The compatibility garantuee is only given for the coming 1.x series. Oops, that got a bit longer, than I meant. I am always a bit too wordy. Sorry. -- Configure bugmail: http://qa.mandrakesoft.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: trying to do a dump and restore svnadmin create etc [EMAIL PROTECTED] svn]# svnadmin load etc /mnt/disk/backups/etc.svn.dmp.20030906 svn: Unsupported repository version svn: Expected version '2' of repository; found version '1' [EMAIL PROTECTED] svn]# looking at etc/format shows a format number of 1 and not 2
[Cooker] [Bug 3385] [MySQL] mysql does not start
http://qa.mandrakesoft.com/show_bug.cgi?id=3385 --- Additional Comments From [EMAIL PROTECTED] 2003-03-28 01:27 --- This is after a fresh install of 9.1 on an separate partition, where MySQL has been selected during the package selection stage: $ ls -ld /var/lib/mysql/ drwxr-xr-x4 mysqlmysql4096 Mar 25 06:32 /var/lib/mysql/ $ ls -l /var/lib/mysql/ drwx--x--x2 mysqlmysql4096 Mar 6 11:31 mysql drwxr-xr-x2 mysqlmysql4096 Mar 6 11:31 test Looks fine to me (and runs fine). Btw, the version is 4.0.11a-5mdk. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: /etc/init.d/mysql start MySQL can not start ... even through there is no other mysql-server running. Actually it says [OK] after running mysql start but in the logfile you see that it didn´t. /log/lib/mysql/mymaschine.err === 030316 23:48:36 mysqld started 030316 23:48:37 Can't start server : Bind on unix socket: Permission denied 030316 23:48:37 Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ? 030316 23:48:37 Aborting 030316 23:48:37 /usr/sbin/mysqld: Shutdown Complete 030316 23:48:37 mysqld ended
[Cooker] [Bug 3207] [urpmi] conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 12:49 --- Works fine for me (and even does something sensible for urpmi MySQL-Max MySQL: choosing the not-installed one over the installed one). Thanks! --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: CLOSED creation_date: description: I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.)
[Cooker] [Bug 3207] [MySQL-Max] conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 11:48 --- Funny, I wondered if I should consider that an urpmi problem. Anyhow the versions I am using: $ rpm -q urpmi perl-URPM rpmtools urpmi-4.2-30mdk perl-URPM-0.81-12mdk rpmtools-4.5-9mdk Let me know, if you need anything else. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.)
[Cooker] [Bug 3207] [MySQL-Max] conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 12:49 --- Oops, I thought the problem was gone once I installed the newest package (at that time MySQL-4.0.11a-4mdk), but it just happened again with the next version: $ urpmi MySQL-Max To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-5mdk.i586 MySQL-Max-4.0.11a-5mdk.i586 MySQL-common-4.0.11a-5mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-5mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-5mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-5mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-5mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-5mdk (packages from http://people.mandrakesoft.com/~warly/doc/rpms/) That is with MySQL being installed. If I do urpmi MySQL it works again. So the conflicts only work against the other package from the same version for some reason. Beside the main issue about upgrading from ML 9.0, this means that this there is bug to be fixed also for current versions. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.)
[Cooker] [Bug 3208] [MySQL-client] mysql_install_db doesn't look for mysqld-max
http://qa.mandrakesoft.com/show_bug.cgi?id=3208 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|UNCONFIRMED --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 13:30 --- The 4.0.11a-5mdk RPMs work for reported problem. I tested the install process in several variants and did some basic SQL queries (just to be sure). I will apply this patch after 9.1 is finished, and if needed made a 9.1 update. No problem. The report may have sounded more urgent from my side as it was meant (actually, I don't use the Max-version at all, currently). I just wanted to make sure you aware of it and can consider the implications. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: This belongs to the MySQL-common package, but it was not in the selection list. Problem: mysql_install_db fails to look for mysqld-max and therefore does not initialize /var/lib/mysql/mysql properly. Sorry that I only noticed this so late, but since /var/lib/mysql is kept on uninstall, the problem only happens when you never installed MySQL before *and* install MySQL-Max before MySQL. It is a bug in the original script and not by Mandrake's package, but only became visible when MySQL-Max became undependend of MySQL package. And reporting it the ordinary way would propagate to late for the 9.1 release. I will attach a patch.
[Cooker] [Bug 3207] [urpmi] conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 13:54 --- I just reproduced it by downgrading to the MySQL-4.0.11a-4mdk version (also all related packages) and then doing urpmi MySQL-Max again. With --bug the output changed to Everything already installed. Is that expected? Anyhow, without --bug I get exactly the same message as in comment #6. I sent you an mail (to [EMAIL PROTECTED]) with the resulting directory in a tar.gz file. Since I recently got bounces from addresses @mandrakesoft in CC's (looks like some weird TLS problem on our side), I write this bug entry additionally. Let me know, if you don't get the mail (the bounces have some days delay). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.)
[Cooker] [Bug 3207] [urpmi] conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 15:16 --- Created an attachment (id=341) -- (http://qa.mandrakesoft.com/attachment.cgi?id=341action=view) debug directly of urpmi --bug MySQL-Max Okay, tar.gz is attached. I just tried to reproduce it and interestingly got no message at all (but it works for about 5 seconds). I then deinstalled MySQL completely and can reproduce this: The first time I call it with --bug I get Everything already installed, the second time (and thereafter) I get an empty message. I can reset the status by calling it without --bug. Then the next with --bug will have the message. I assured that I also get if I try immediately after an deinstall (with --bug). All the time the output from a call without --bug stays the same. Well, because this sounds extremely like a broken installation of urpmi, I did an uninstall and reinstall (only of urpmi and dependecies, deinstalling rpm is a bit too much for now). Also did rpm --rebuild and urpmi.update -a. Arggg! Still all the same, exept that the cases when Everything already installed appears is exactly the other way around. *bangingheadagainstwall* --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEEDINFO creation_date: description: I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.)
[Cooker] [Bug 3013] [MySQL] wants to install info page, but that has moved to MySQL-common
http://qa.mandrakesoft.com/show_bug.cgi?id=3013 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 04:58 --- Oops. There is my comment missing. (sorry about the noise) Setting to CLOSED as confirmation that it is fixed. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: CLOSED creation_date: description: The postinstall script start with if [[ -f /usr/share/info/mysql.info.bz2 ]];then /sbin/install-info /usr/share/info/mysql.info.bz2 --dir=/usr/share/info/dir;fi although that part is now done by MySQL-common. I presume that it has no bad effect. But I am not sure about it, that's why I am reporting it. Feel free to postpone it to whenever you want. ;-)
[Cooker] [Bug 1404] [MySQL] mysql_fix_privilege_tables is not called
http://qa.mandrakesoft.com/show_bug.cgi?id=1404 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 07:25 --- Verified for 4.0.11a-4mdk. Tested that the privileges database (/var/lib/myslq/mysql), copied from a 3.23 installation gets correctly updated on both: upgrade of either MySQL or MySQL-Max. (Sorry about the delay, but I did not get my hands on -4mdk earlier.) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: See the mentioned URL. There are some steps to be taken in order to upgrade from 3.23 to 4.0 (4.0 will work on a 3.23 database without those, but not all features are available). The most notable is the one give in the Summary. Of course, it is arguable, if all those steps should be automatic, and I would surely be fine with only printing a message that the user has to run the steps (maybe cite the mentioned URL). But I think if neither is done, there will be a lot of questions coming back why certain features of 4.0 do not work after upgrading.
[Cooker] [Bug 1371] [MySQL-Max] requires for base MySQL package missing?
http://qa.mandrakesoft.com/show_bug.cgi?id=1371 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 07:35 --- Wondering if I will manage to have a decent set of scripts before the final...:( Well, you did it! Perfectly! And I mean it. Teamwork at its best. For completeness, I tested the following: - looked at --scripts, --requires of all MySQL packages (including diff'ing) - misc. upgrades, installs and removes (also partially) of all MySQL packages - installing MySQL-Max on top of MySQL and vice versa (I am only so explicit because the release will be soon.) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: CLOSED creation_date: description: MySQL-Max (4.0.9-1mdk) is packaged in a way that it expects a MySQL (base) package to be installed, but does not require it, as far as I can see. I just managed to install MySQL-Max-4.0.9 alongside of MySQL-3.23.55-1mdk, which of course did not work: 030207 06:02:14 mysqld started 030207 6:02:14 Error message file '/usr/share/mysql/english/errmsg.sys' had only 218 error messages, but it should contain at least 237 error messages. Check that the above file is the right version for this program! 030207 6:02:14 Aborting Yeah, I am aware that mixed Cooker installs are not supported (I am running full Cooker, I just did choose MySQL-Max as first thing to update), but as far as the requires look like, it would be even possible to install MySQL-Max without having any MySQL base package installed, but the mysql-max server needs at least the translation file, which is in the base package. Btw, I am referring only to the above error, because I am currently not in the mood to try MySQL-Max alone and screw up my install completely. ;-) If Requires is not the Right Way to solve this, ignore this part (I am only basically familiar with RPM packaging) and do it in whatever is the Right Way. For completness the requires: rpm -qp --requires MySQL-Max-4.0.9-1mdk.i586.rpm rpmlib(VersionedDependencies) = 3.0.3-1 /bin/sh rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 ld-linux.so.2 libc.so.6 libcrypt.so.1 libdl.so.2 libgcc_s.so.1 libm.so.6 libnsl.so.1 libpthread.so.0 librt.so.1 libstdc++.so.5 libz.so.1 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libcrypt.so.1(GLIBC_2.0) libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libgcc_s.so.1(GCC_3.0) libgcc_s.so.1(GLIBC_2.0) libm.so.6(GLIBC_2.0) libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.2) libstdc++.so.5(GLIBCPP_3.2)
[Cooker] [Bug 3207] [MySQL-Max] New: conflict MySQL vs MySQL-Max only partially works
http://qa.mandrakesoft.com/show_bug.cgi?id=3207 Product: MySQL-Max Component: packaging Summary: conflict MySQL vs MySQL-Max only partially works Version: 4.0.11a-4mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: minor Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I just had some problem installing MySQL-Max due to the new conflict to MySQL 4.0.11. I am not certain, if this happens in an upgrade from ML 9.0, but you may want to check it out. In short, urpmi MySQL-Max [MySQL] only handles the conflict properly (i.e. suggesting uninstalling the MySQL package), after I upgraded to the newest MySQL package (MySQL-4.0.11a-4mdk). It looks that the installed RPM needs to have the conflict marker in order for it to be honored completely. This is only of interest for people who installed the -Max version of 3.23.x, which was supposed to have MySQL-Max installed alongside (more presicly: after) MySQL. From my observations (see below), I fear people having used MySQL-Max in this way, will run into the same conflict I had. But I am not sure about it and unfortunately don't have an v3.23 installation to test with. As this is a problem with the different packaging used before (also in ML9.0), it may be possible/probable that the problem will also happen for a full upgrade from 9.0 to 9.1, depending how similar the installer works to urpmi. With MySQL 4.0.11a-3mdk installed as this $ rpm -qa | grep -i mysql MySQL-client-4.0.11a-3mdk libmysql10-3.23.55-1mdk libmysql12-4.0.11a-3mdk MySQL-common-4.0.11a-3mdk MySQL-4.0.11a-3mdk php-mysql-4.3.0-2mdk I get the following: $ urpmi MySQL-Max MySQL To satisfy dependencies, the following packages are going to be installed (17 MB): MySQL-4.0.11a-4mdk.i586 MySQL-Max-4.0.11a-4mdk.i586 MySQL-common-4.0.11a-4mdk.i586 Is this OK? (Y/n) installing /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-Max-4.0.11a-4mdk.i586.rpm /var/local/mirror/mandrake/cooker-tree/Mandrake/RPMS/MySQL-common-4.0.11a-4mdk.i586.rpm Installation failed: MySQL-Max 4.0.11 conflicts with MySQL-4.0.11a-4mdk MySQL 4.0.11 conflicts with MySQL-Max-4.0.11a-4mdk The same happens with urpmi MySQL-Max. As I said, the problem went away when I upgraded MySQL beforehand: Now I am asked that MySQL-Max resp. MySQL has to be removed in order to install the other packet. As I said, I am not sure how the installer will handle this, but I fear that it will try the equivalent of urpmi MySQL-Max MySQL. If you are sure that is no problem for a full install, feel free to close this bug as invalid, of course. Severity: minor, because only users of MySQL-Max are affected (and people seem to not install it that much). (And yes, I am aware that my environment is signicantly different from ML 9.0, but the package conflict should be the same. I would love if someone could test with the ML 9.0 packages.) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3208] [MySQL-client] New: mysql_install_db doesn't look for mysqld-max
http://qa.mandrakesoft.com/show_bug.cgi?id=3208 Product: MySQL-client Component: program Summary: mysql_install_db doesn't look for mysqld-max Version: 4.0.11a-4mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] This belongs to the MySQL-common package, but it was not in the selection list. Problem: mysql_install_db fails to look for mysqld-max and therefore does not initialize /var/lib/mysql/mysql properly. Sorry that I only noticed this so late, but since /var/lib/mysql is kept on uninstall, the problem only happens when you never installed MySQL before *and* install MySQL-Max before MySQL. It is a bug in the original script and not by Mandrake's package, but only became visible when MySQL-Max became undependend of MySQL package. And reporting it the ordinary way would propagate to late for the 9.1 release. I will attach a patch. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 3208] [MySQL-client] mysql_install_db doesn't look for mysqld-max
http://qa.mandrakesoft.com/show_bug.cgi?id=3208 --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 07:56 --- Created an attachment (id=335) -- (http://qa.mandrakesoft.com/attachment.cgi?id=335action=view) makes it look also for mysqld-max, not only mysqld The patch fixes the reported problem for me. The check for mysqld-max is heavily based on the one in mysqld_safe in order to reduce the risk. I was careful to not brake anything and tested it with both packages MySQL-Max and MySQL for 4.0.11a-4mdk. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: This belongs to the MySQL-common package, but it was not in the selection list. Problem: mysql_install_db fails to look for mysqld-max and therefore does not initialize /var/lib/mysql/mysql properly. Sorry that I only noticed this so late, but since /var/lib/mysql is kept on uninstall, the problem only happens when you never installed MySQL before *and* install MySQL-Max before MySQL. It is a bug in the original script and not by Mandrake's package, but only became visible when MySQL-Max became undependend of MySQL package. And reporting it the ordinary way would propagate to late for the 9.1 release. I will attach a patch.
[Cooker] [Bug 3009] [grpmi] New: improve handling of MD5 sum mismatch
http://qa.mandrakesoft.com/show_bug.cgi?id=3009 Product: grpmi Component: grpmi Summary: improve handling of MD5 sum mismatch Version: 9.1-11mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Did a search on md5 which found no existing bugs. AFAICT, the application in question is grpmi, but I saw the error when installing from rpmdrake. On signature check, I got an error like: The signature of the package 'fluxbox-0.1.14-6mdk.i586.rpm' is not correct: MD5 sum mismatch Expected: 7e4859c86a7e4be85508c4863340f368 Saw : c9e8488fde20be2576d39f33afdde80e Do you want to install it anyway? (yes, the second line displays shifted, probably due to spaces in a proportional font.) This message will not appear, if you chose Yes to all beforehand on a GPG signature mismatch. Since GPG signature are mainly about authentication and often lacking on contrib package, but MD5 checksum are mainly about integrity, it would be reasonable to handle them differently. In other words: I am missing some explanation that the most probable reason for this error means, my download was broken (I am aware that the text has to be more general to apply to CD installs, too). And second, pressing yes to all on a missing GPG signature shouldn't ignore failed checksums (i.e. if possible differentiate between missing and invalid signatures). Not sure if this should be targeted for 9.1, but please make sure it gets picked up later if it is delayed for after-release. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 1371] [MySQL-Max] requires for base MySQL package missing?
http://qa.mandrakesoft.com/show_bug.cgi?id=1371 --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 04:59 --- Created an attachment (id=302) -- (http://qa.mandrakesoft.com/attachment.cgi?id=302action=view) How the output of rpm -q --scripts MySQL-Max should look like Sorry, still some minor issues... $ /usr/sbin/urpmi MySQL-Max The following packages have to be removed for others to be upgraded: MySQL-4.0.11a-3mdk (due to conflicts with MySQL-Max[ 4.0.11]) libmysql12-devel-4.0.11a-3mdk (due to unsatisfied MySQL == 4.0.11a-3mdk) That is after a full install of MySQL. The dependency for libmysql12-devel should be fullfilled by MySQL-Max, shouldn't it? The post-install script removes mysql instead of mysql-max. It should be: /usr/share/rpm-helper/del-service MySQL $1 mysql-max (should this have gone to a new bug report?) And initialisation of database is missing in MySQL-Max (compared to MySQL): # Initiate databases su - mysql -c mysql_install_db -IN-RPM /dev/null --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: MySQL-Max (4.0.9-1mdk) is packaged in a way that it expects a MySQL (base) package to be installed, but does not require it, as far as I can see. I just managed to install MySQL-Max-4.0.9 alongside of MySQL-3.23.55-1mdk, which of course did not work: 030207 06:02:14 mysqld started 030207 6:02:14 Error message file '/usr/share/mysql/english/errmsg.sys' had only 218 error messages, but it should contain at least 237 error messages. Check that the above file is the right version for this program! 030207 6:02:14 Aborting Yeah, I am aware that mixed Cooker installs are not supported (I am running full Cooker, I just did choose MySQL-Max as first thing to update), but as far as the requires look like, it would be even possible to install MySQL-Max without having any MySQL base package installed, but the mysql-max server needs at least the translation file, which is in the base package. Btw, I am referring only to the above error, because I am currently not in the mood to try MySQL-Max alone and screw up my install completely. ;-) If Requires is not the Right Way to solve this, ignore this part (I am only basically familiar with RPM packaging) and do it in whatever is the Right Way. For completness the requires: rpm -qp --requires MySQL-Max-4.0.9-1mdk.i586.rpm rpmlib(VersionedDependencies) = 3.0.3-1 /bin/sh rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 ld-linux.so.2 libc.so.6 libcrypt.so.1 libdl.so.2 libgcc_s.so.1 libm.so.6 libnsl.so.1 libpthread.so.0 librt.so.1 libstdc++.so.5 libz.so.1 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libcrypt.so.1(GLIBC_2.0) libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libgcc_s.so.1(GCC_3.0) libgcc_s.so.1(GLIBC_2.0) libm.so.6(GLIBC_2.0) libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.2) libstdc++.so.5(GLIBCPP_3.2)
[Cooker] [Bug 1404] [MySQL] mysql_fix_privilege_tables is not called
http://qa.mandrakesoft.com/show_bug.cgi?id=1404 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 05:10 --- Sorry about the default for datadir. I noticed it, but forgot to include it in my report. And a second sorry for nitpicking (and somehow hijacking this bug step by step), but IMHO datadir=`my_print_defaults mysqld | grep '^--datadir' | cut -d \ -f2-` has to be datadir=`my_print_defaults mysqld | grep '^--datadir=' | cut -d= -f2-` i.e. the key and values are seperated by a = sign (The cut is the relevant part. Appending = to the grep is just some future-safety while I am at it). From a production server of mine: $ my_print_defaults mysqld | grep '^--datadir' | cut -d \ -f2- --datadir=/var/lib/mysql $ my_print_defaults mysqld | grep '^--datadir=' | cut -d= -f2- /var/lib/mysql So I am not sure why you changed my example -d= to -d \ . Do I missing something? (And ignore that in the example above the variable happens to be set to the default, /var/lib/mysql). Aside from that, the changes work fine. Thanks. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: REOPENED creation_date: description: See the mentioned URL. There are some steps to be taken in order to upgrade from 3.23 to 4.0 (4.0 will work on a 3.23 database without those, but not all features are available). The most notable is the one give in the Summary. Of course, it is arguable, if all those steps should be automatic, and I would surely be fine with only printing a message that the user has to run the steps (maybe cite the mentioned URL). But I think if neither is done, there will be a lot of questions coming back why certain features of 4.0 do not work after upgrading.
[Cooker] [Bug 3013] [MySQL] New: wants to install info page, but that has moved to MySQL-common
http://qa.mandrakesoft.com/show_bug.cgi?id=3013 Product: MySQL Component: packaging Summary: wants to install info page, but that has moved to MySQL- common Version: 4.0.11a-3mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: trivial Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The postinstall script start with if [[ -f /usr/share/info/mysql.info.bz2 ]];then /sbin/install-info /usr/share/info/mysql.info.bz2 --dir=/usr/share/info/dir;fi although that part is now done by MySQL-common. I presume that it has no bad effect. But I am not sure about it, that's why I am reporting it. Feel free to postpone it to whenever you want. ;-) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 1371] [MySQL-Max] requires for base MySQL package missing?
http://qa.mandrakesoft.com/show_bug.cgi?id=1371 --- Additional Comments From [EMAIL PROTECTED] 2003-03-05 20:43 --- The originally reported problem is fixed (that is, de-installing all MySQL packages and doing urpmi MySQL-Max results in a working MySQL server with version 4.0.11a-2mdk). Thanks! But the Requires still look are a bit strange: $ rpm -q --requires MySQL-4.0.11a-2mdk ! ~/tmp/MySQL.requires $ rpm -q --requires MySQL-Max-4.0.11a-2mdk ! ~/tmp/MySQL-Max.requires $ diff ~/tmp/MySQL.requires ~/tmp/MySQL-Max.requires 1,3d0 rpm-helper MySQL-client perl-DBI 8d4 /bin/sh 13a10 libcrypto.so.0.9.7 18a16,17 librt.so.1 libssl.so.0.9.7 Okay, the SSL-part is obvious, but why does only the MySQL package, but not MySQL-Max require rpm-helper, MySQL-client, /bin/sh and perl-DBI? Since both packages contain only variants of the same binary, both should require all or none of those four packages, IMHO. At least for perl-DBI I am sure that it is not required for the server at all, but only for benchmark and helper scripts, so it's at most required for MySQL-common or MySQL-client. Fun part is, neither of both do require it. I presume it is simply a left-over from before splitting the packages? Not critical, of course. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: MySQL-Max (4.0.9-1mdk) is packaged in a way that it expects a MySQL (base) package to be installed, but does not require it, as far as I can see. I just managed to install MySQL-Max-4.0.9 alongside of MySQL-3.23.55-1mdk, which of course did not work: 030207 06:02:14 mysqld started 030207 6:02:14 Error message file '/usr/share/mysql/english/errmsg.sys' had only 218 error messages, but it should contain at least 237 error messages. Check that the above file is the right version for this program! 030207 6:02:14 Aborting Yeah, I am aware that mixed Cooker installs are not supported (I am running full Cooker, I just did choose MySQL-Max as first thing to update), but as far as the requires look like, it would be even possible to install MySQL-Max without having any MySQL base package installed, but the mysql-max server needs at least the translation file, which is in the base package. Btw, I am referring only to the above error, because I am currently not in the mood to try MySQL-Max alone and screw up my install completely. ;-) If Requires is not the Right Way to solve this, ignore this part (I am only basically familiar with RPM packaging) and do it in whatever is the Right Way. For completness the requires: rpm -qp --requires MySQL-Max-4.0.9-1mdk.i586.rpm rpmlib(VersionedDependencies) = 3.0.3-1 /bin/sh rpmlib(PayloadFilesHavePrefix) = 4.0-1 rpmlib(CompressedFileNames) = 3.0.4-1 ld-linux.so.2 libc.so.6 libcrypt.so.1 libdl.so.2 libgcc_s.so.1 libm.so.6 libnsl.so.1 libpthread.so.0 librt.so.1 libstdc++.so.5 libz.so.1 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libcrypt.so.1(GLIBC_2.0) libdl.so.2(GLIBC_2.0) libdl.so.2(GLIBC_2.1) libgcc_s.so.1(GCC_3.0) libgcc_s.so.1(GLIBC_2.0) libm.so.6(GLIBC_2.0) libpthread.so.0(GLIBC_2.0) libpthread.so.0(GLIBC_2.1) libpthread.so.0(GLIBC_2.2) libstdc++.so.5(GLIBCPP_3.2)
[Cooker] [Bug 1404] [MySQL] mysql_fix_privilege_tables is not called
http://qa.mandrakesoft.com/show_bug.cgi?id=1404
--- Additional Comments From [EMAIL PROTECTED] 2003-03-05 23:18 ---
The 3.23 tables are not updated and stopping MySQL fails somehow:
$ urpmi MySQL-Max
installing /var/cache/urpmi/rpms/MySQL-Max-4.0.11a-2mdk.i586.rpm
Preparing...##
1:MySQL-Max ##
cat: /var/lib/mysql/mysql.pid: No such file or directory
AFAICS, the error is from the following line in the postin script's failing:
kill `cat $pid_file` /dev/null
Afterwards, the pid file is still lying around and manually executing the line
indeed kills the MySQL daemon. So I guess it is some race condition.
The disturbing result is that MySQL is still running with --skip-grant-tables
and service mysql stop will fail to stop the service (because the
/etc/init.d/mysql script is looking for a pid file with the hostname encoded).
-
Ah, after some trial and error I found the culprit: detaching mysqld returns too
early. mysql_fix_privilege_tables cannot open the connection and the cat
$pid_file fails because there is no pid_file yet. A sleep would probably help.
A cleaner solution would be to have a waitfor command (seen on QNX) that
blocks until a file/socket exists. Could be easily emulated by a loop:
waitfor()
{
while [ ! -e $1 ]; do
usleep 10
done
}
Not sure, if a timeout is needed for the case at hand, i.e. whether mysqld could
fail after detaching. Probably yes.
Another thing is that hard-coding /var/lib/mysql in postin is not that pretty.
my_print_defaults is made for this purpose. How about something like:
datadir=`my_print_defaults mysqld | grep '^--datadir' | cut -d= -f2-`
cd $datadir
pid_file=$datadir/mysql.pid
I am aware that grep isn't in the core-utils and therefore potentially
problematic, but you get the idea.
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
--- Reminder: ---
assigned_to: [EMAIL PROTECTED]
status: ASSIGNED
creation_date:
description:
See the mentioned URL. There are some steps to be taken in order to upgrade from
3.23 to 4.0 (4.0 will work on a 3.23 database without those, but not all
features are available). The most notable is the one give in the Summary. Of
course, it is arguable, if all those steps should be automatic, and I would
surely be fine with only printing a message that the user has to run the steps
(maybe cite the mentioned URL).
But I think if neither is done, there will be a lot of questions coming back why
certain features of 4.0 do not work after upgrading.
[Cooker] [Bug 1916] [kdebase] USB memory stick not mounted: RC1
https://qa.mandrakesoft.com/show_bug.cgi?id=1916 --- Additional Comments From [EMAIL PROTECTED] 2003-02-23 10:43 --- Well, Wim, if you call yourself Bugzilla, too, you are right to feel offended. In the more probable case that you do not, understand that Warly was speaking with the underlying bug reporting system, which is called Bugzilla, which obviously did not behave as he wanted it to. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: NEW creation_date: description: As in all the beta's also in RC1 an USB memory stick (highly popular and can at least in Holland and Germany bought at the supermarket !) is not automatically detected and mounted.
[Cooker] [Bug 448] [sudo] Sudo does not give root's path when issuing a command
https://qa.mandrakesoft.com/show_bug.cgi?id=448 --- Additional Comments From [EMAIL PROTECTED] 2003-02-22 22:20 --- *** Bug 2151 has been marked as a duplicate of this bug. *** --- Additional Comments From [EMAIL PROTECTED] 2003-02-23 11:29 --- After seeing Bug 2151 being marked dup of this one, I wanted to comment a bit. As an little side-point, Debian Woody has solved this in an interesting way: I am not completely sure how, but it seems that they manipulate the search path *only* for the command being executed by sudo itself, not the PATH variable for the resulting shell/command. Working on both systems daily, I can only say, sudo not searching */sbin is indeed a major PITA. I would like to reopen the bug (which I unable to do, it seems) with the request to get at least SECURE_PATH working which it does not for me (using tcsh, but same result with bash and sh): $ env PATH=/bin SECURE_PATH=/sbin /usr/bin/sudo /bin/env | grep '^PATH' PATH=/bin Sorry, if I am simply ignorant and using it the wrong way, but IIRC I read somewhere that SECURE_PATH requires some compile time configure option in order to work. --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: RESOLVED creation_date: description: if you were to issue the command sudo echo $PATH you will see that the path givin is NOT root's. This gets very annoying since the whole point of sudo is mostly to run commands as root, and for me alot of them are only in root's path. I grabbed the tarball from the website and did the generic ./configure make, then I issued the same command using the newly built binary and all was fixed. I noticed in your spec file you define some flags for ./configure, i didnt use any when i built the binary from source. Perhaps one of those is screwing it up.
[Cooker] [Bug 1417] [nagios-plugins] check_mysql plugin segfaults
https://qa.mandrakesoft.com/show_bug.cgi?id=1417 --- Additional Comments From [EMAIL PROTECTED] 2003-02-15 01:41 --- Created an attachment (id=180) -- (https://qa.mandrakesoft.com/attachment.cgi?id=180action=view) Fix illegal memory access in mysql_check.c Oh, of course, I tried without additional parameters first: $ cd /usr/lib/nagios/plugins/ $ ./check_mysql Can't connect to MySQL server on '127.0.0.1' (111) I only tried with parameters after that (btw, error 111 can't connect is expected because I am running with skip-networking and using 127.0.0.1 tries to use a TCP socket). Btw, this was with glibc-2.3.1-7mdk. I just updated (by hand) everything to be more like your versions: $ rpm -q nagios-plugins libmysql10 glibc MySQL nagios-plugins-1.3.0-0.beta2.4mdk libmysql10-3.23.55-1mdk glibc-2.3.1-9mdk MySQL-4.0.10-1mdk and now I get the same problem. Sorry about misleading you. It was urpmi which preferred to install the older nagios-plugins-1.3b1-2mdk.i586 instead of the current nagios-plugins-1.3.0-0.beta2.4mdk.i586 and I did not look closely enough to notice that this was not a newer, but older version. Hm. I just had a look at the source code check_mysql.c (of nagios-plugins-1.3.0-0.beta2.2mdk, I was unable to find the SRPM for beta2.4mdk) and got a shiver. Has a lot of logical errors. The segfault is because it calls is_intnonneg() on a non-existing argument. I attached a patch which fixes that. Can you apply the patch and try again? If not, you can test if this was your problem this way: Try calling $ ./check_mysql a.-b Invalid host nameUsage: check_mysql [-d database] [-H host] [-P port] [-u user] [-p password] check_mysql --help check_mysql --version This should give an error, because it exits before the bug. Alternatively specify all arguments (the relevant is the last one): $ ./check_mysql localhost user password db 3306 Uptime: 6894 Threads: 1 Questions: 5 Slow queries: 0 Opens: 6 Flush tables: 1 Open tables: 0 Queries per second avg: 0.001 Oden, can you care about getting the patch upstream? I don't use this package nor know anything about it (and after looking at the source, I'll stay with mon ;-). I just looked into the matter because I am familiar with MySQL. PS: Hm. This package requires a lot of stuff which is only needed if I really want to monitor the resp. software. For example, I do not have samba installed, but installing nagios-plugins required the samba client library (same for postgre, snmp, radius, ...). Not nice, if I'd run it on a server (I like to keep servers to a minimal install). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: I don't know, but I suspect it has to do with recent MySQL changes. If MySQL v4.x is due to 9.1 I belive many packages has to be rebuilt against it.
