[Cooker] [Bug 6057] [Installation] no internet connection after install (RC1)
http://qa.mandrakesoft.com/show_bug.cgi?id=6057 --- Additional Comments From [EMAIL PROTECTED] 2003-11-11 08:17 --- I get connect: no buffer space avialable errors perodically with ssh and ping from a MDK9.2 final system. -- 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: RESOLVED creation_date: description: It's not a big problem, but I thought I'd report it anyway ... I installed Mdk 9.2 RC1, and during the installation I set up the connection through lan card - dns gateway = 10.1.1.1. When I logged in for the first time and tried to enter some page with konqueror, it failed. I tried ping 10.1.1.1 from the konsole and it said something like connect: no buffer available. I ran control center and then the internet connection wizard, and clicked on the top button (change computer name, or sth like that). And I saw there that dns was set to 127.0.0.1. When I set it back to 10.1.1.1 the connection was established. But why did it change at all?
[Cooker] [Bug 4732] [kernel] No way of installing MandRake 9.2beta on a PC with everything USB
http://qa.mandrakesoft.com/show_bug.cgi?id=4732 --- Additional Comments From [EMAIL PROTECTED] 2003-08-10 07:33 --- Similar problem here with latest cooker (sync'ed about an hour ago). I don't have a usb keyboard. However, my usb mouse, usb hub, usb printer, usb storage devices, etc. get lost sometime after the loading second stage part of the install. My hub dies completely and my mouse is intermittent. Unfortunately I did not write down the kernel errors I was seeing when this happened. I can try another install and get the kernel messages if needed. -- 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: NEW creation_date: description: This is really an umbrella bug for a number of problems I've encountered while trying to install Mandrake 9.2beta on my machine. The situation doesn't look as a generic Linux problem since all other major distributions (SuSe 8.1, RedHat9) were able to install themselves without any problems. The main charecteristics of my PC is that everything is connected via USB to it. Keyboard, mouse, scanner, USB mass storage. And I guess that's the root cause of what I'm seeing. I haven't had success with Mandrake 9 line at all. All minor versions are affected. Please give this bug a serious consideration since USB mouse/keyboard are getting popular these days and without considering such configurations you might lose a number of potential users. Ok here are the problems. They are all realted to installation phase: 1.During install USB keyboard/mouse could get lost at any stage making further progress with installation impossible (I can't answer installer's questions without keyboard, right?). 2. Even when they are functional I'm getting a flood of: 4 usb_control/bulk_msg: timeout kernel messages. 3. Each splash screen during an installation freezes for 3-7 minutes before getting any further. So all I left to stare at for that period of time is a gray rectangle on the left without any text or even -- Wait. Operation in progress message. 4. Since keyboar/mouse could be lost during any stage of install it could be very helpfull if installer could resume after reboot instead of going from the start. 5. Even when I used PS/2 keyboard dueing install and swithed my regular USB one later on when the system booted up for the first time it didn't help. Kernel loses track of USB keyboard and all I can do is reboot. Thanks, Roman.
[Cooker] [Bug 5398] [apache-conf] New: Apache should not specify a default character set for text/* types
http://qa.mandrakesoft.com/show_bug.cgi?id=5398 Product: apache-conf Component: apache-conf Summary: Apache should not specify a default character set for text/* types Product: apache-conf Version: 2.0.47-5mdk Platform: All OS/Version: All Status: UNCONFIRMED Severity: minor Priority: P2 Component: apache-conf AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] According to http://www.w3.org/TR/html401/charset.html#h-5.2.2 and http://httpd.apache.org/docs-2.0/mod/core.html#adddefaultcharset when a charset parameter is specified in the Content-Type HTTP header sent by the server, it overrides the charset specified in the meta tag of the HTML document. Apache shipped with Cooker has the directive AddDefaultCharset set to ISO-8859-1 (see commonhttpd.conf). Consequently, all HMTL documents are considered as ISO-8859-1 documents by conforming web browsers such as Mozilla, even if they are UTF-8 or Windows-1252 documents according to their meta tag. This behavior, though not severe, is a bit irritating because in most case (if not all) the meta tag reflects the correct character set for the document. Therefore, the AddDefaultCharset directive should be set back to its default value (Off). -- 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.
[Cooker] [Bug 5398] [apache-conf] Apache should not specify a default character set for text/* types
http://qa.mandrakesoft.com/show_bug.cgi?id=5398 --- Additional Comments From [EMAIL PROTECTED] 2003-08-09 16:42 --- OK. There's an issue with text files, but there are many ways to solve this. For example, we could add this directive in commonhttpd.conf : AddCharset ISO-8859-1 .txt which adds the charset parameters to all files with a .txt extension. Changing the DefaultType directive would be a more definitive solution : DefaultType text/plain changed to DefaultType text/plain; charset=ISO-8859-1 But remember that specifying a default value for the charset is not necessarily a good thing because it may be different from the charset really used in the text file. I think setting AddDefaultCharset to Off would bring more beneficits than drawbacks. -- 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: NEW creation_date: description: According to http://www.w3.org/TR/html401/charset.html#h-5.2.2 and http://httpd.apache.org/docs-2.0/mod/core.html#adddefaultcharset when a charset parameter is specified in the Content-Type HTTP header sent by the server, it overrides the charset specified in the meta tag of the HTML document. Apache shipped with Cooker has the directive AddDefaultCharset set to ISO-8859-1 (see commonhttpd.conf). Consequently, all HMTL documents are considered as ISO-8859-1 documents by conforming web browsers such as Mozilla, even if they are UTF-8 or Windows-1252 documents according to their meta tag. This behavior, though not severe, is a bit irritating because in most case (if not all) the meta tag reflects the correct character set for the document. Therefore, the AddDefaultCharset directive should be set back to its default value (Off).
[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 3059] [SysVinit] Shutdown ends with some sort of UTF8 error.
http://qa.mandrakesoft.com/show_bug.cgi?id=3059 --- Additional Comments From [EMAIL PROTECTED] 2003-03-16 23:33 --- Another Me to but I did look a bit closer at the problem. I have locale en_US.UTF-8 and /etc/init.d/mandrake_consmap is installed and I guess triggers the problem. When shutting down /etc/rc.d/rc calls /etc/init.d/mandrake_consmap and in there it executes 'vt-is-UTF8 --quiet || unicode_start'. vt-is-UTF8 sends a unicode sequence that includes ;2R to the screen and expect some characters back to check if it's unicode enabled. It suppose to remove it also but when 'init' runs the command something fails and it behaves like you have typed it directly. When you type a few characters on the keyboard (backspace, return, whatever) vt-is-UTF8 receives that and tries to understand it, fails with an io error and the script continues. if you start with hitting enter you get a shell error ';2R' not found because the shell tries to interpret it. From what I see the problem is with 'init', 'vt-is-UTF8' and the io handling between them. As a workaround, when shutting down I just hit a few keys and ignore whatever error I get. --- 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: Configuration: - AMD Duron 1.2, 512Mb, Shuttle XPC SN41G2 Nforce2, Maxtor 120Gb - Fresh MDK 9.1 RC2 installation, no NVIDIA drivers installed Problem 1: SysVinit % shutdown -r now ;2R - bash: syntax error near unexpected token ';' % shutdown -r now is_in_UTF8_mode: Input/Output error - in installation I checked Force UTF8 mode or what was it...
[Cooker] [Bug 3020] [initscripts] shutdown aborting with a bash syntax error
http://qa.mandrakesoft.com/show_bug.cgi?id=3020 --- Additional Comments From [EMAIL PROTECTED] 2003-03-16 23:37 --- Another Me to but I did look a bit closer at the problem. I have locale en_US.UTF-8 and /etc/init.d/mandrake_consmap is installed and I guess triggers the problem. When shutting down /etc/rc.d/rc calls /etc/init.d/mandrake_consmap and in there it executes 'vt-is-UTF8 --quiet || unicode_start'. vt-is-UTF8 sends a unicode sequence that includes ;2R to the screen and expect some characters back to check if it's unicode enabled. It suppose to remove it also but when 'init' runs the command something fails and it behaves like you have typed it directly. When you type a few characters on the keyboard (backspace, return, whatever) vt-is-UTF8 receives that and tries to understand it, fails with an io error and the script continues. if you start with hitting enter you get a shell error ';2R' not found because the shell tries to interpret it. From what I see the problem is with 'init', 'vt-is-UTF8' and the io handling between them. As a workaround, when shutting down I just hit a few keys and ignore whatever error I get. --- 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: Hello, I'm using 9.1 RC2. Here's what I get when I run `shutdown -r|-h now' or `init 6' from a console session([Ctrl][Alt][F1]): ... INIT: Sending processes the TERM signal ;2R -bash: syntax error near unexpected token `;' This happens with or without ACPI set at boot time. Is there a syntax error in init scripts? Here's my hardware configuration (Keynux Agora eV laptop): 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 11) 00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02) 00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility 9000 M9] (rev 01) 02:04.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) 02:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:07.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller 02:0a.0 USB Controller: VIA Technologies, Inc. USB (rev 50) 02:0a.1 USB Controller: VIA Technologies, Inc. USB (rev 50) 02:0a.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) Don't hesitate to get back to me! Thank you for your support. Cheers, Mike.
[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 1997] [Installation] No RAID support on rescue mode
http://qa.mandrakesoft.com/show_bug.cgi?id=1997 --- Additional Comments From [EMAIL PROTECTED] 2003-02-26 05:26 --- FYI. On MDK 9.1 RC1, tried to do the install to raid1 and mailed on mkraid. modprobe md gave a pile of unresolved symboles, something is broken here. --- 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've all my Filesistems on RAID 1. Also root filesystem. A mistake on /etc/fstab manipulation makes the system unbootable. I've tried to use install rescue mode to edit the /etc/fstab and resolve the problem, but RAID devices are not supported on rescue mode.
[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 1967] [galaxy-gnome] No way to get the Color Scheme to Match KDE's.
https://qa.mandrakesoft.com/show_bug.cgi?id=1967 --- Additional Comments From [EMAIL PROTECTED] 2003-02-21 06:26 --- Rather than close it, push it forward to 9.2. Too much work involved to get it done before 9.1 but eventually a necessary step. --- 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: Hi, I noticed that Mandrake Galaxy gtk, while much nicer looking atm than Mandrake Galaxy KDE, does not seem to be able to change colors, at least that I've noticed. The issue being that if I'm using KDE, like many of your users are, I may choose to change the color scheme, which inturn causes GTK stuff to stick out really badly. There is a very easy way to solve this, which is why I am reporting this. libqtpixmap, a derivative of the libpixmap engine employed by most GTK themes, does color matching with KDE's color settings. Now, I'm not sure how Galaxy's theme engine works, but I'm assuming importing the code for this other engine (which is the one used for Geramik, by the way) would be relatively easy. If, on top of that, you made a little tool to adjust the color settings from Gnome, Mandrake would be the FIRST distribution (afaik) to offer both KDE and Gnome users and easy way to keep all major applications using the same color scheme! This would dramatically improve Galaxy and fix a major usability bug between KDE and Gnome that has never been solved before right out of the box. Using a static color palate in GTK apps is alright, but the whole unified look is only good so long as no one changes the KDE color scheme. I noted this in my review of Red Hat Linux 8 (at OfB.biz) and marked down the visual apperance somewhat because of that problem. In a way unified widgets giving the appearance of all the applications being the same, will probably confuse users MORE when the color palates won't change all of the applications. It'll probably result in support headaches, I'd suspect. Anyway, libqtpixmap is available for both GTK1 and GTK2. I can't say how much I think this would be a great thing, and everyone who has ever wanted to be able to easily adjust GTK color schemes (probably most Windows migrants) will thank-you for making the change. -Tim
[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.
Re: [Cooker] Re: I've made sdd SRPMs - where / how / to whom toupload ?
as Dan Scott has noted, the instructions on that page are not very easily followable. What should I do with these packages this time ? (Until a followable page exists.) Could someone more knowledgeable / experienced take *please* take over these [src].rpm's and stick them into contribs / cooker / somewhere ? -- Thanks ! John On Sun, 12 Jan 2003, Mark Scott wrote: [EMAIL PROTECTED] wrote: On Sat, 11 Jan 2003 [EMAIL PROTECTED] wrote: I've made sdd SRPMs: one older, one newer. The newer seems pretty stable, so it might be enough to stick that one into contribs. Somebody please let me know where / how / to whom to upload it, so it gets into contribs, or, better, please take it (recompile) and put it where it should be, and just let me know, so I can use the diskspace on the website again. The two packages can be found at: http://Honza.Vicherek.com/sdd-1.31-1.src.rpm http://Honza.Vicherek.com/sdd-1.22-2.src.rpm OK, I've also uploaded the i586.rpm's: http://Honza.Vicherek.com/sdd-1.31-1.i586.rpm http://Honza.Vicherek.com/sdd-1.22-2.i586.rpm John In case you hadn't read them, this page gives an outline of the process (scroll down to How to contribute some packages to Cooker?): http://www.mandrakelinux.com/en/cookerdevel.php3 And did you read this before packaging the RPMs? It deals with Mandrake-specific rules and methods for RPM packaging. http://www.mandrakelinux.com/en/howtos/mdk-rpm/ In particular, you seem to have missed something about the package name: The release is a number followed by mdk (stands for Mandrake; this is absolutely mandatory) which is incremented at each new build of the package. http://www.mandrakelinux.com/en/howtos/mdk-rpm/building.html#AEN204 So, your package should be sdd-1.31-1mdk.i586.rpm.
[Cooker] Re: I've made sdd SRPMs - where / how / to whom to upload ?
OK, I've also uploaded the i586.rpm's: http://Honza.Vicherek.com/sdd-1.31-1.i586.rpm http://Honza.Vicherek.com/sdd-1.22-2.i586.rpm John On Sat, 11 Jan 2003 [EMAIL PROTECTED] wrote: Hi, I've made sdd SRPMs: one older, one newer. The newer seems pretty stable, so it might be enough to stick that one into contribs. Somebody please let me know where / how / to whom to upload it, so it gets into contribs, or, better, please take it (recompile) and put it where it should be, and just let me know, so I can use the diskspace on the website again. The two packages can be found at: http://Honza.Vicherek.com/sdd-1.31-1.src.rpm http://Honza.Vicherek.com/sdd-1.22-2.src.rpm Thanks, John -- -- Gospel of Jesus' kingdom = saving power of God for all who believe -- ## To some, nothing is impossible. ## http://Honza.Vicherek.com/
Re: [Cooker] Re: [Contrib-Rpm] crimson-0.1.6-1mdk
Guillaume Rousse wrote: * Sun Aug 26 2001 Lenny Cartier [EMAIL PROTECTED] 0.1.6-1mdk - updated to 0.1.6 Should be renamed to crimson-field, to not be confused with java xml parser (even if not in Mandrake). Good idea. I will. lenny -- Lenny Cartier | Iptoip project : http://iptoip.sourceforge.net [EMAIL PROTECTED]| MandrakeSoft : http://www.mandrakesoft.com Informatique: Excel, Word, chef de projet informatique. (c) Serious resume
[Cooker] rsync site for mdk+updates ?
Hi, Where is there an rsync server I could get the latest Mdk8.0+UPDATES off of, so I can rsync to local machine and make an installationw/current updates via NFS from my local maschine ? Thx, Jan -- -- Gospel of Jesus is the saving power of God for all who believe -- ## To some, nothing is impossible. ## http://Honza.Vicherek.com/
Re: New Aurora - is it a joke? Re: [Cooker] Aurora developmentdead?
On 6/1/01 3:54 PM, Andrej Borsenkow [EMAIL PROTECTED] wrote: May be, Aurora development is not under Mandrake control, but packaging? Maybe so, but doesn't anyone at Mandrakesoft *use* Aurora, at least during the beta cycle? Particularly if such a problem was reported before? Harry
Re: [Cooker] Sympa missing on LM 8.0 (std. Ed.)
On 6/4/01 12:40 PM, Paul Cox [EMAIL PROTECTED] wrote: Personally, I think that starting with 8.1, that they should go ahead and go to 3 cd's for the core distribution. Agreed, since the Standard Edition comes with 3 CDs, but the third is just some varied Applications. Granted, it's a double-edged sword, seeing as how there is a lot Mandrake wants to include, and there's just a limit to how much fits on a CD-ROM. Of course, they could always offer an alternate distro on DVD-ROM. I have a feeling if they did, they would drive a lot of DVD-ROM purchases... :-) Harry
Re: [Cooker] Sympa missing on LM 8.0 (std. Ed.)
On 5/28/01 11:19 PM, Yves Duret [EMAIL PROTECTED] wrote: Any idea why this is, or am I missing something? look in contribs So, then, it *is* missing from the standard distribution n the CDs, right? Any particular reason why it was dropped over inclusion in 7.2? Thanks for the response, Harry
[Cooker] Software Manager - LM 8.0 (std. Ed.)
There appear to be some problems with Software Manager under 8.0. Logged in as root: * When changing sources (adding or deleting), and re-opening the 'sources' dialog, none of the changes 'took'. No matter how many times it is being re-entered, the changes never take hold. * I should be able to double-click on any source, and have the window come up that allows me to edit the source, instead of having to delete and create new if I want to make changes (this is a feature request). * When doing an 'install' from a remote location (doing upgrades), only the first installation appears to work. Subsequent ones *say* they installed correctly, but haven't done anything (it claims it downloaded and installed a 4 megs file in 2 seconds) - sometimes it doesn't even provide the download feedback, but just claims the installation went fine. All of this is on an entirely freshly installed system, using ReiserFS, from a bought copy of Mandrake 8.0 standard edition - selecting pretty much everything for the installation. Doing a regular (non-expert) installation. Any idea how to fix this? Harry
[Cooker] Sympa missing on LM 8.0 (std. Ed.)
LM 8.0 no longer appears to include the sympa mail list manager, that was nevertheless included under LM 7.2 - why is that? T is on an entirely freshly installed system, using ReiserFS, from a bought copy of Mandrake 8.0 standard edition - selecting pretty much everything for the installation. Doing a regular (non-expert) installation. Any idea why this is, or am I missing something? Harry
[Cooker] PowerPack Deluxe doesn't install DrakConf..?
Just had a weird issue with a user who bought and installed Linux Mandrake 7.2 PowerPack Deluxe. After installation, I tried to help him configure his system, leading him to DrakConf - but apparently DrakConf was not installed on his system at all. What configuration or condition can lead to an essential configuration utility not being installed? Harry
Re: [Cooker] 8.0 and cooker
to answer my own question : nope, contents of Cooker-i586 20010418 12:13 and of Mandrake-8 are not the same. I just did an rsync from one of the sites, and found out that the distros are not same. Attached is .bz2 output of : # diff -qr current_cooker just_released8 | grep -v /Mandrake/RPMS.cooker ( grep because RPMS.cooker is a symlink pointing to RPMS ) later, Jan PS: there are also some wierdities, such as : Files current_cooker/Mandrake/RPMS/kde-i18n-eo-2.1.1-1mdk.noarch.rpm and just_released8/Mandrake/RPMS/kde-i18n-eo-2.1.1-1mdk.noarch.rpm differ Files current_cooker/Mandrake/RPMS/kde-i18n-pt-2.1.1-1mdk.noarch.rpm and just_released8/Mandrake/RPMS/kde-i18n-pt-2.1.1-1mdk.noarch.rpm differ Files current_cooker/Mandrake/RPMS/kde-i18n-tr-2.1.1-1mdk.noarch.rpm and just_released8/Mandrake/RPMS/kde-i18n-tr-2.1.1-1mdk.noarch.rpm differ Files current_cooker/Mandrake/RPMS/kdoc-2.1.1-1mdk.noarch.rpm and just_released8/Mandrake/RPMS/kdoc-2.1.1-1mdk.noarch.rpm differ -- same RPM name, different contents ... this shouldn't happen ! On Thu, 19 Apr 2001, Jan Vicherek wrote: I have the same question. If anybody has the answer, please let us know ! I would hate to see unnecessarily overburdened FTP servers, and frustrated downloaders (especially if we *already* have 8.0 anyway). My latest rsynced cooker ./VERSION says : Linux-Mandrake Cooker-i586 20010418 12:13 . Do I then have the same content as 8.0 ? Thanx, Jan (please Cc: me on your reply) On Thu, 19 Apr 2001, Greg Sarsons wrote: Is what is in the cooker right now what is in 8.0? I've got cooker in sync right now, rsync, and don't want to download the same thing again. -- -- Gospel of Jesus is the saving power of God for all who believe -- ## To some, nothing is impossible. ## http://Honza.Vicherek.com/ diff.cooker.8.out.bz2
Re: [Cooker] Apache fixed in 8.0? (issue solved)
On 4/13/01 9:39 AM, "Paul Cox" [EMAIL PROTECTED] wrote: 127.0.0.1localhost.localdomainlocalhost Was that in there already and you had to add your specific information, or was it empty? I'm curious because I have a dynamic ip address. Technically, for a working configuration, what you have should be enough, but apparently a dynaic config via localhost is no longer blessed. I soolved it by setting a static IP address, giving the machine a name, and adding that entry into the hosts files. Harry
Re: [Cooker] Apache fixed in 8.0?
On 4/12/01 1:15 AM, "John Allen" [EMAIL PROTECTED] wrote: php-common isn't in the hdlists so it ends up on the last CD, and you have to install it manually later. That sounds like a fix that MUST be done before final release ships. Harry
Re: [Cooker] RC1 feedback
On 4/12/01 1:08 AM, "John Allen" [EMAIL PROTECTED] wrote: No don't! it's muich too late you should have done this with beta 1-3 they were made especially for those things. Changing strings so late will break That would have been rather hard, seeing as these changes only appeared on RC1! MeThinks we're having another issue where the right hand doesn't know what the left hand is doing - no surprise by now, or for a project of the complexity of a distro. Fortunately, nothing major will break because of a bad spelling, or bad capitalization - besides, by now the improper use of English has become part of Mandrake's charm. Harry
Re: [Cooker] Apache fixed in 8.0? (glory./sarcasm)
On 4/12/01 5:38 AM, "Sergio P.Korlowsky" [EMAIL PROTECTED] wrote: Well finished installing RC1 and this what I got tring to start apache: httpd Segmentation fault (core dumped) Which is exactly what I had been getting with beta 3 - I'm glad that we're only dealing with a minor app, like one of those new-fangled web-server that are hardly used by any people - I shudder to think if this lack of detail were applied to a really important app/server. You know this hasn't been working since Beta2...? Harry
Re: [Cooker] Apache fixed in 8.0? (could be dhcp)
On 4/12/01 6:45 AM, "Jason Straight" [EMAIL PROTECTED] wrote: So anyway - I checked /etc/hosts and the only entry was for 127.0.0.1, I added in an entry for the eth0 interface address and it started apache ok. A) This was never an issue with prior installations, so this should be looked into. Not many people will have DNS services and domains for their setups. B) First thing I did was update my hosts file, but I'll fuck around with it some more. Harry
Re: [Cooker] Apache fixed in 8.0? (issue solved)
B) First thing I did was update my hosts file, but I'll fuck around with it some more. By specifically and manually entering the information of the local box into the hosts file, I was able to make apache behave and run properly (Thanks "Jason Straight" [EMAIL PROTECTED]). My suggestion, since this was never an issue before, and why the heck apache would segfault because it can't find DNS information is beyond me - make sure that the installer enters the local box name (and IP, if needed) into the hosts file, based on the information the user provides during installation) Then all is fine, at least in regards to Mandrake. Oh yeah, and make sure Joe is part of the standard installation. Harry
[Cooker] MandrakeUpdate errors in Beta 3
I run MandrakeUpdate. I select one of the files I want updated. It loads the 'installer' sub-program, and it return an error. Machine is hooked up to network, and can acccess the net. The error type is NOT given. Harry
Re: [Cooker] Traktopel installation time
On 4/13/01 5:16 AM, "Guillaume Cottenceau" [EMAIL PROTECTED] wrote: "Nguyen Hung.Takeshi" [EMAIL PROTECTED] writes: hi all! I ve chosen full installation for Traktopel3 (install all packages), it took about 3.5 hours ;) Several reasons for this? Did you do an 'upgrade' of an 'install'? Let's assume you did an install. I bet you made your own CD and didn't purchase one :-) Some burners have a severe problem reading certain CD emulsions - I had the same issue with 7.2 with CDs that someone from Mandrake sent me. Only happened on one system. Took roughly 3.5 hours as well. I reburnt the CD to another media (gold CD) and tried again, and it installed in less than 45 minutes. Try an alternate media - gold being best. Harry
Re: [Cooker] further comments on Traktopel (beta3)
On 4/13/01 9:38 AM, "Elton Woo" [EMAIL PROTECTED] wrote: But where are the beautiful Princess Narda, and Lothar? ;-)) Lothar's there - check the name of some of the packages/projects they worked on. Harry
[Cooker] Apache fixed in 8.0?
Does anyone know if the installation of Apache has been fixed in 8.0 beta yet? In Beta 3 installation, it would not work out of the gate. Harry
[Cooker] Beta 3 doesn't have 'Joe'
Just to avoid a repeat of an earlier fiasco, I'd like to point out that the present beta 3 seems to lack 'joe', the text editor. Seeing as how there was inconsistent support for joe under the various versions of 7.2, it would be very pleasant to see 'joe' returned to Mandrake 8.0 in all release versions (in fact, it would be nice to see consistent release versions this time).
[Cooker] Mandrake 8. Beta 3 probs
Virgin install of mandrake 8 beta ona dual Celeron BP6 board. Installation by itself went off without too many problems: * The text editor joe, as previously mentioned, is not part of the installation. * Apache/httpd does not work AT ALL after this install (the usual (defunct) message during a ps ax, and problems with what appears to be mod_ssl, guessing from the logs. Commenting the mod_ssl configuration out of the httpd.conf file won't make it work. I realize apache is a minor, hardly every used application known as a 'web-server' so it could have easily slipped through the cracks of intensive earlier beta testing, but myself, and 56% of the world's web-server users would appreciate a functional httpd installation :-) In addition, does this still use the sgi patches, or has that finally been removed? Harry
Re: [Cooker] Why don't recent kernels build initrd?
On 2/27/01 12:59 AM, "Thomas Mangin" [EMAIL PROTECTED] wrote: No it is not that simple you must - postuninstall : insert loop.o - install the kernel - postinstall : mkinitrd - remove the loop.o RedHat does it on its latest kernel if you want to get an easy spec file .. Yeah, but obviosuly it *can* be done, and as yourself confirmed, RedHat does do it - so the original question still applies - why isn't it done by Mandrake? Harry
[Cooker] What version of Apache on Cooker?
What is the version of Apache in cooker right now. Simple question - just need a simple answer. Harry
[Cooker] Mod_gzip and cooker...
Has anyone tried mod_gzip (www.remotecommunications.com) under cooker's httpd server to see if it works? Harry
[Cooker] Mod_gzip and Mandrake....
Mod_gzip is a content encoding module for Apache. When properly installed it can provide some tremendous savings on bandwidth, and improvements in performance. Problem is, it doesn't properly install under LM (v7.2) - apapche errors out at restart. This might be due to some of the existing patches. Has anyone managed to get mod_gzip to work under Mandrake, are there efforts underway, and will cooker include mod_gzip? Harry
Re: [Cooker] stop mailing me
On 2/23/01 4:25 PM, "andre" [EMAIL PROTECTED] wrote: In the headerfiles of your cooker emails are writen This requires lamerz actually knowing how to read their headers - not the most intuitive location for such information. Harry
[Cooker] slocate freezes system on Reiser system...!!
Has anyone else encountered this: This is on a virgin, new install of a Mandrake 7.2 system. Every morning, same time (4:02am) the system locks up and freezes hard, requiring a power cycle. Suspecting a cron job, I ran each manually in the cron.daily directory, until the same lock-up happened with the slocate cron.daily job. Since nothing has been customized or changed versus a standard system, I'm wondering if anyone else has encountered his, and what the possible fix would be. This is a similar problem that has also happened on an identically configured RedHat 7.0 system. The common factor between the two systems is that both are configured with ReiserFS, which is, BTW, what I suspect to be the relevant factor. Any ideas? Harry
Re: [Cooker] Why no Official KDE 2.0.1 Update?
on 12/7/00 3:15 AM, Vadim Plessky at [EMAIL PROTECTED] wrote: | Now I must be serious. Mandrake Comp. said that no final Kde-2.0.1 will | be available for users of Mandrake 7.2. How charming - have they given a reason as to why? Harry
Re: [Cooker] Why no Official KDE 2.0.1 Update? (cool, thanksChristopher)
on 12/7/00 2:41 PM, Christopher Molnar at [EMAIL PROTECTED] wrote: Guys, please give them a few more days! They are working on it, I've been told by my manager. The packagers on the project have not worked with kde2 that often before (remember I was doing the packaging) and it is taking a little longer. Great news, and thanks for the positive update - so where do those nasty rumors get started that Mandrake won't be making those available? Thanks, again. Harry
[Cooker] slocate cron job freezes/crashes system regularly...
Has anyone else encountered this: This is on a virgin, new install of a Mandrake 7.2 system. Every morning, same time (4:02am) the system locks up and freezes hard, requiring a power cycle. Suspecting a cron job, I ran each manually in the cron.daily directory, until the same lock-up happened with the slocate cron.daily job. Since nothing has been customized or changed versus a standard system, I'm wondering if anyone else has encountered his, and what the possible fix would be. This is a similar problem that has also happened on an identically configured RedHat 7.0 system. The common factor between the two systems is that both are configured with ReiserFS, which is, BTW, what I suspect to be the relevant factor. Any ideas? Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/28/00 7:09 AM, Charles R. Hurley at [EMAIL PROTECTED] wrote: Even after I installed all the many updates I'm still having problems with this OS. For example, I cannot connect to my http://localhost, and any other app that tries to connect to port 80 can't either. I installed the Apache updates, so why am I having such dam trouble? This might have next tonothing to do with the release issue or version numbr of your distro: * What is your security level set to? * Is your localhost entry in /etc/hosts? * Is your httpd running (check with ntsysv)? - Set your security level to medium. - /etc/rc.d/init/httpd restart See if this helps. Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/27/00 11:28 AM, stephen at [EMAIL PROTECTED] wrote: should i be glad or dismayed ?? As 'nice' as it is for MacMillan to distribute Mandrake products, with all the recent snafus (most of them deliberate decisions by marketing) I think it's about time that MacMillan be abandonned as a reliable source of distributions, and that those needing the latest Mandrake either just download it (time notwithstanding -- this is what Mandrake folks are suggesting anyway) or buy the cheap burnt CDs from providers like LinuxCentral. In fact, I received latest version CD-ROMs from their US distribution support guy (Thanks, Christopher), and those worked fine, after the MacMillan package I paid good money for proved useless. The only problem with that scenario is that because of this, Mandrake will obviously no longer make any money from those US sales it loses this way - thus, it would be preferable if Mandrake installed some system to either sell directly to end users, or accept some sort of electronic payment for those using their products, that downloaded them, and that want Mandrake to get some money. My prediction on that front : Marketing won't have *ANY* clue what to do, and will not address this. Accounting will dance around the issue, because they don't know what to do, or how to handle such income. Legal won't let them, because "That's not how things get done". (insert appropriate French translations here -- but essentially this is how this would break within a US infrastructure). Change probably won't happen until the first really bad reviews of MacMillan distros start hitting, and sales decline sharply - which could be a while since Mandrake has built some good momentum. I'd actually hope the above scenario would not play out, and they figure some way to address them... Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/27/00 3:14 PM, Vincent Danen at [EMAIL PROTECTED] wrote: what Ron mistakenly called the "real 7.2" and is in fact 7.2 (what you have) Well, considering there are at least *3* versions out there, as of last count, all labeled '7.2' and all different, I think refering to something as 7.2 is no longer a clear identifier. Seriously, based on this experience, I think a better versioning or identifying scheme needs to be come up with. Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/27/00 3:12 PM, Vincent Danen at [EMAIL PROTECTED] wrote: Please let's not start this whole thread over again... Macmillan never released a "pre-release" 7.2 and that is that. Uhm... yes, I guess WalMart notwithstanding... ...or MacMillan's Linux-Mandrake 7.2 'complete' notwithstanding ...any others I missed? Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/27/00 9:16 PM, Ron Stodden at [EMAIL PROTECTED] wrote: Í'm sorry, but you are misinformed. No he's not, Ron. He works for Mandrake. His word is law. His word distorts reality. His word is the truth. Heretics like you must be silenced. (Sarcasm intended) Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/28/00 5:28 PM, Vincent Danen at [EMAIL PROTECTED] wrote: I don't want to seem rude, but I am no longer replying to any messages in this or any similar threads. I no longer have time for this debate. Understood, and I can see why - as long as MandrakeSoft has time to address the issues that been exposed in these threads in their next release, instead of 'not having time for them' (not in reference to you, but those responsible for the latest boneheaded decisions). Harry
Re: [Cooker] HELP: Macmillan's packaging a pre-release ofMandrake 7.2
on 11/28/00 7:09 AM, Charles R. Hurley at [EMAIL PROTECTED] wrote: A pray: Let's keep Mandrake the best Linux OS ever. Let's support these great Linux and Mandrake programmers, and let's sell the truth. Agreed on all of that, but bear in mind, that the last part refers to marketing, and I thing regardless of what country they are in, asking marketing to sell the truth simply does not compute in their minds - after all, that's why they went into marketing. Harry
[Cooker] lm_sensors...
Does the latest Mandrake (7.2, cooker) include lm_sensors, lm_sensors support, or is it at least 'ready' for lm_sensors? If not, are there any plans to support that? Harry
Re: OT Re: [Cooker] mdk 7.2 running IE 5, kind of
on 11/23/00 5:02 AM, Matthew Brealey at [EMAIL PROTECTED] wrote: followed by Netscape 6, Why does Netscape 6 even feature in any list of 'best' browsers. It's a piece of total crap. Harry
Re: [Cooker] YOU DID IT TO ME AGAIN!! FIX THE SENDMAIL PACKAGERIGHT NOW!!I c
on 11/24/00 2:44 PM, Brian J. Murrell at [EMAIL PROTECTED] wrote: WELL I GOT NEWS FOR YA!! I lost about another dozen mail messages again today becuase IT IS NOT FIXED!! It's just their gentle way of trying to convince you to switch to Posrfix... Harry
Re: [Cooker] Macmillan and Pre-release
on 11/22/00 9:08 AM, Charles R. Hurley at [EMAIL PROTECTED] wrote: Is it true that Macmillan packaged a pre-release copy of 7.2? Yes, but they didn't do it alone. Harry
[Cooker] 'complete' Mandrake small issues...
Do you get all working ? I think that now we could forget the arrogance problem . the problem need to be the center of the discution Agreed, thank you. I'm waiting for a functional 4-disk set to be sent to me, once I have those, I will attempt a reinstall. so there was problem with the download version comercialised by macmillan ? Quite so, particularly since MacMillan's 'complete' omitted (as we found out) the extensions CD, and thus tried to force edited content from the extensions CD onto the others. This is primarily a problem with MacMillan, but I'm sure Mandrake created the disks for them, so it is also Mandrake's issue - overall, though, it appears to be a marketing issue, and one of having several morons in charge in that group, apparently. it is simple to download these two small rpms from mirrors (get the 7.2 verion no 8 ;-) Well, I downloaded both from the cooker, and while I was able to install joe, ncftp refuses becauses it complains about libgd.so.1. Mind you, this was NOT an issue before I applied all updates with MandrakeUpdate - apparently the upgrades munched libgd.so.1 Any ideas about that? thanks to pixel for doing so great works ;-) Yeah, thanks again go out out to Pixel. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 9:09 PM, Ron Stodden at [EMAIL PROTECTED] wrote: Harry, how big is the partition you are installing to? Oh, about 10 gigabytes. If it is too small, the installer gives you a percent representing all that it can install in that space. Did you see this? Nope, all I saw was three options, one at 300mb, one at 500mb, one at 800mb, and the custome one, which I selected, with 'ALL' selected. Did you OK it at less than 100%? If yes, then it is helpfully doing exactly what you requested it to do, ie, leave out sufficient of the lower-ranked packages, including joe. Well, it turns out that contrary to Geoffrey's arrogant statement, joe can not be found on ANY of the 4 CDs that I purchased. Neither can ncftp. Neither can a corrective response from Geoffrey. Try again with a bigger partition? Don't think that's the issue here. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 9:28 PM, Alexander Skwar at [EMAIL PROTECTED] wrote: If you can't stand the responses, GET LOST! Hmmm, do you work for Mandrake? I doubt that the marketing will even response when YOU ARE always so arrogant! That's right! The person being arrogant in the first place is *YOU*! Look, I'll be the first one to retract my words if it turns out that I was wrong. After Geoffery's response, I was looking for joe in the location he mentioned, ready to apologize to this list. Turns out that joe is INDEED nowhere to be found on the disks, validating my original rant/question - and Pixel was the only person who answered it in a knowledgeable way (thanks, Pixel). Yeah, you are free to feel that my response was arrogant, but it was obviously naive of me to assume that something billed as 'complete' actually would be so. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 9:25 PM, Ron Stodden at [EMAIL PROTECTED] wrote: In your situation, I would take it back and get your $32 back. Then download or buy the REAL Mandrake 7.2 Well, I certainly will try to return it, albeit the issue with returning opened software boxes is a tricky one... Either way, this, of course, begs the question: What *IS* the 'real' Mandrake 7.2? The box states 'Linux-Mandrake 7.2 complete'. It's published by MacMillan (MandrakeSoft's US distributor). You can't get any more 'real' than that, at least by appearance. Seeing as how Mandrake whines on about how they have to make money to pay for their salaries (a legitimate concern) I figured that $32 isn't going to break me, and that at least I'd be contributing a bit. I made sure that this was not the WalMart version, and figured I would therefore be 'safe'. After all, if I were to download Mandrake, I would spend no money, but neither would Mandrake earn any. Buy the 'real' Mandrake? Would the real Mandrake please stand up? I'm certainly not going to risk and additional $79.95 on another 'experiment, only to find out that this is an incomplete release version as well. Besides, I stopped purchasing RedHat when they jacked their prices up in the $79.95 range, so if I'm going to spend that kind of money, I'm going to buy RedHat - at least their distro works. So, what to do? Yes, the promotion is misleading (or worse) to an experienced Mandrake User Yeah, seeing as how I'm not the only one having versioning problems, I'd say that's about accurate. Seeing as how Mandrake's attitude appears to be that most users who have this problem are either stpid or lazy, I don't see that changing soon. (probably none of which are to be found in Macmillan, WalMart, Mandrake(?) marketing). Apparently, the one constant in the Universe are marketing people - just like in the US, if you prove incompetent at much else, you go to marketing. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
Think about this, I didn't tell you to look through the CD Well, seeing as how I was specifically talking about the CD, that miscommunication is understandable. it's still available for downlaod and yes I admit the marketing is probably bad, and I can understand why you must be frustrated but: at leaset please search through the Mandrake ftp directory before you decidly try to flame the list for having removed joe. yes, that's where I grabbed it from and downloaded it - unfortunately, it appears that not all is fine in the 'complete' version. I installed all the upgrades with MandrakeUpdate, and as a result now my libgd.so.1 is either no longer to be foud, or incorrect, as installation of something like ncftp fails for that reason. So, there appear to be more problems. My point in my "arrogance" (as you call it) is because you decide to flame the list, at least try to be a bit polite? You know people here are all trying to help, and langague may differ (depending on humour and mood) I hope you understnad people on this list are not dummys for you to bash. Fair enough, Geoffrey, and thanks for the reply. Harry
[Cooker] **Why is joe missing from 7.2!!!???**
So, I have been using joe since day-one of using Linux. So, every version of Mandrake (not to mention every other distro) includes joe. So, I installed Mandrake 7.2 (the complete, 4-cd version). I actually bought it to see what the new version's all about. So, I do an installation with 'ALL', custom to use ReiserFS. Upon rebooting, going back into a terminal window, and trying to edit the hosts file, I type in 'joe hosts'. I get a 'command not found'. I do a locate for joe. I use the find function to find joe. Joe's gone. What the fuck? Why is it that everytime I'm about to re-think my position on Mandrake, and actually am about ready to say to myself "Hey, this rocks!", some idiot over at MandrakeSoft makes a decision to just leave out a totally standard text editor - and not tell anyone??? Sure, undoubtedly the responses from MandrakeSoft will be the usual arrogance infused "Well, why don't you just download joe and install it - you know how to do it, obviously... hrumph!", but that's not the point (as I will do just that). The issue here is one of consistency, which seems to be overun by one of politics/arrogance (maybe someone believes that all users should only use emacs, or vi), one of poor oversight, or what have you. Fact is, I was checking out 7.2, and I was severely impressed by it so far, and I was about to write up a relatively lauding review of it, when I came to a screeching halt because of this. So, is there any sort of explanation for this? Will this be addressed in a future revision? Will joe be added to MandrakeUpdate as an update after the fact? Why did this happen? Who made this decision? I'd really like to know! Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 9:28 AM, Zeljko Vukman at [EMAIL PROTECTED] wrote: So appologize to Mandrakes, they deserve it. Let me get this straight: I'm supposed to 'apologize' to Mandrake because they replied: It's gone because you're too lazy to install it: Oh, yeah, I certainly should be grateful as heck for some excellent support of that caliber... Oh boy, the customer-service Gods in Valhalla sure are smiling down on Mandrake. Get real! Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 8:49 AM, Geoffrey Lee at [EMAIL PROTECTED] wrote: It's gone because you're too lazy to install it: Obviously we must be talking about some strange language/translation idiosyncrasy. In English, a language that apparently is quite complex and difficult to understand, the word 'ALL' means 'Everything'. Mind you, while I definitely appreciate that Mandrake has FINALLY added the 'ALL' option to the install, I do also kinda (and obviously, naively) except that to mean 'everything that can be installed'. Silly me. Obviously, in French 'ALL' must mean something else. Now, what's the reason that ncftp is gone as well, or has that just been neglected to be installed as well? SERIOUSLY - some people on this list are claiming that they have joe working just fine. Obviously, I don't. Could it be that the scripts for 'Complete 800mb' installation, and 'Custom/ALL' installation have some differences in them, and thus cause different packages to be installed? If that's the case, this should be addressed - unless you will continue to assume that all users that make the grave error to select 'Custom' must be lazy, n'est ce pas? Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 10:58 AM, Chmouel Boudjnah at [EMAIL PROTECTED] wrote: do you want i get you in contact with a marketing guy to inflate your egocentric ? Sure, if you feel that it will do any good... The fact remains: I installed mandrake on a virin system, as a straightforward installation. I selected 'custom' and 'all'. I ended up with an installation that is missing joe (and ncftp as well). Upon pointing that out (with some irritation, I might add) the response from this list is condescension and arrogance, instead of realizing that there is a problem somewhere in the installation (which would not be a first for Mandrake). Granted, the recent snafu of refusing to identify properly the various versions of Mandrake 7.2 which are floating around is already bad enough (but I understand that this is a unique marketing problem), but having the various versions (obviously) perform different installations makes the problem more of an issue. If this is a marketing issue, then by all means, let me talk to one of your marketroids. Still, I doubt very much that your marketing drone can do much to fix this installation issue - that might be more in your domain. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 1:31 PM, Alexander Skwar at [EMAIL PROTECTED] wrote: But that's just because YOU started to fight. I actually think that Chris's response was apropriate, and it even was gentle IMO. And when you get an answer *HERE* *ON* *THIS* *LIST*, it's just because the Mandrake people feal like it. Fine, I'll accept that - but it does not distract from the fact that (as it turns out) joe is NOT on the distribution disks I just paid $32 for, and neither is ncftp. More on that later. Well, *I* did not pay anything to be on this list, did you? If not, then you *HAVE* to mind your words! I didn't pay to be on this list, obviously, but I just paid $32 for a Linux Mandrake 7.2 complete that I would expect to be 'complete'. Particularly so when some punk like Geoffrey gets arrogant about me being too lazy to install it from the RPMS directory, and, as it turns out, the file really is *NOT* anywhere in the RPMS directory on my distribution disks (genuine MacMillan product). So, the point still remains as my original query - WHERE THE HECK IS JOE? And while I was originally under the impression "Golly, gee whiz, I shoulda looked in RPMS...", now after looking, and still not finding it, I do have to ask the same question with renewed fervor - and also ask how the heck is one supposed to differentiate between Mandrake packages now, since they are all labeled as 7.2??? Harry
[Cooker] **Why is joe *REALLY* missing from this version of 7.2!!!???
on 11/19/00 8:49 AM, Geoffrey Lee at [EMAIL PROTECTED] wrote: It's gone because you're too lazy to install it: [snailtalk@ke RPMS]$ ls joe* joe-2.8-21mdk.i586.rpm Hmmm Interesting, after I initially thought that I was wrong, and I'm going to need to apologize to you, I did a search of ALL 4 CDs that came with me Linux Mandrake 7.2 Complete installation (MacMillan), and, guess what - joe is nowhere to be found (along with ncftp, and I'm sure others as well). So, not only will I request an apology from you, my friend, but I will ask again: "WHY IS JOE MISSING from this Mandrake 7.2 'complete'?" (and ncftp as well), and who made this decision? This does beg the question - how many different versions of Mandrake 7.2 are out there, all labeled as 7.2, with no way for the consumer to differentiate them? I bought mine from a hardware dealer, it is a legitimate MacMaillan package, listed as 'Linux-Mandrake 7.2 Complete'. The KDE shipped with it, though is billed as 2.0 prerelease candidate 1 (in other words, 1.99), yet it clearly is NOT the single disk set from Wal-Mart. So, while I was willing to buy the various rationales for having to ship to WalMart on time, what is the reason behind the package that I have, which is clearly inferior to the distro that others are using, as well as the copies that certain reviewers have received...? I think this is a valid question, now that it turns out that I was apparently gipped in the money that I just spent! -Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 11:14 AM, Pixel at [EMAIL PROTECTED] wrote: Complete doesn't mean 'All', it's much more subjective. Understood, with that I have no problem at all. But when one selects 'ALL', at least it should install what one expects. As it turns out, the installation *WAS* correctly installing 'ALL', as Geoffrey's assumption (that I was being lazy for not installing joe from the RPMS directory) is false - since I just looked in the RPMS directories of all 4 CD-ROMs of the Linux Mandrake 7.2 Complete package I just bought, and none contain so much as a hint of joe, or of ncftp. Which brings me back to my original question "Why is joe missing from 7.2?" (and makes me want to bitch-slap Geoffrey for his stupid response -- unless he can show me where it is supposed to be hidden). Thanks for your answer. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 11:25 AM, Pascal Grossé at [EMAIL PROTECTED] wrote: If you chose to install in 800 Mb, the installer automatically removed some packages, using an order of importance defined by the developpers for each package. I bet joe is not of the highest priority in that list.. I understand completely, and that wasn't my problem - it's when I do a custom installation, and select 'ALL' I should be able to expect 'all' to be installed, shouldn't I? Now, as it turns out, unlike Geoffrey's arrogant statement that I was toolzy to install from the RPMS directory, it turns out that the 7.2 distribution I bought doesn't have joe on ANY of the CD-ROMs that came with it - which brings the possible number of different, but identically named 7.2 distributions to at least 3. So, what's up with that? Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 3:39 PM, Pixel at [EMAIL PROTECTED] wrote: see http://www.linux-mandrake.com/en/72faq.php3 Pixel, THANK YOU very much. This is a valid and good explanation of the differences, and I appreciate that. Now, to avoid such issues in the future, may I suggest you tell your marketing people to add an extra information box on the back of EVERY package, simply titled: "Other Products by Mandrake" in which you list the other products, and soem short differences between them (Mandrake Complete: 4 disks/850mb; PowerPack Deluxe: 7 disks/2,300mb). This would avoid the kind of problmes people (not just myself) are having with this versioning system on this list, and in the real world. Harry
Re: [Cooker] **Why is joe missing from 7.2!!!???**
on 11/19/00 4:48 PM, Meir Faraj at [EMAIL PROTECTED] wrote: what did u said here I've the 7.2 and joe is installed the very complete installation of two cd only take me 3G!!! not 800M it is in the first CD I think.. Well, as we are all discovering right now, that is because there are different 'versions' of 7.2, all of them clearly marked as '7.2', with no real way of differentiating them, and what you get when you get them. Thus, *your* 7.2 *has* joe, and thus *my* 7.2 does *not* have joe. Thanks to Pixel for pointing to the faq that somehow explains this, albeit it still lacks a list of what files are missing from the 'complete' version from MacMillan. Decidedly, bsed on this experience, this is the last time I will have spent any sort of money on a MacMillan, and particularly a Mandrake product - after all, the free downloads *ARE* more complete, so why am I spending my money on something that only provides partially what's needed. Too bad, truly, since I really wanted to send some money Mandrake's way. It's not missing from 7.2. It's missing from the MacMillian "complete" boxed copy of Mandrake. I guess, once again, some meaning of the word 'complete' was undoubtedly lost in translation. Read the FAQ that Pixel pointed you too earlier. I did, and it was the only truly helpful post in this exchange. Harry
Re: [Cooker] Sad state of pre-releasing to consumers
on 11/1/00 7:36 PM, Chmouel Boudjnah at [EMAIL PROTECTED] wrote: funny thing, you took us as amatory, and you have no clue of what the words 'operating-system development' mean... Note I didn't use the word 'amatur', and regarding the troubling and complex task of operating system developmnet, it seems other are well able to put out versions of Linux that are not as trouble-prone as any new release of Mandrake appears to be. I just love it when they gloss over their very real troubles (a quick look at the subjects in this mailing lists corroborates that), and decide to get glib with people pointing out their issues. Harry
Re: [Cooker] Sad state of pre-releasing to consumers
on 10/31/00 11:07 PM, Randy Welch at [EMAIL PROTECTED] wrote: I also installed it on my dual at work without no incident. With 7.1: Install made my dual BP6 run extremely slow, and freeze several times. Install with RedHat has no problems at all, and zipped along. Overall, it required far more tweaks out of the box to work properly. I still use Mandrake to play with, but can't rely on it for actual production machines - which run RedHat. Harry
Re: [Cooker] Sad state of pre-releasing to consumers
on 10/31/00 9:13 PM, Franck Martin at [EMAIL PROTECTED] wrote: At least this is a real company, with real people, no automatic cleanatised answering machines. I'll give you that. Harry
Re: [Cooker] I am puzzled by people's behaviour...
on 11/1/00 3:48 AM, Pixel at [EMAIL PROTECTED] wrote: - name the updated-7.2 7.2.1, but marketing people don't accept this. Granted, the problem most likely lies with the mktg people, and not the developers - and apparently the idea of a different nukbering scheme didn't fly with marketing either. Harry
Re: [Cooker] Sad state of pre-releasing to consumers
on 10/31/00 9:43 PM, Vincent Danen at [EMAIL PROTECTED] wrote: This is disgusting. Think about what you're saying here. We're comparing a small company of just over 100 employees to a software monopoly. If anyone can afford to ignore marketing time tables for stable products, it should be Microsoft. Yeah, but the point is that MS bases their shipping dates (read: shipping based on dates, not software completion) on marketing factors, and it appears Mandrake did the same. Yes, granted, they believe that the difference between RC1 and Final is not significant enough, but the fact remains that the box misrepresents this. You know, it's all nice and dandy that people say that MandrakeSoft should not release a product with bugs in it but, realistically, that will never happen. It has nothing to do with buddy product - albeit that's one issues as well - but representing a not-ready product as a final in a retail box that implies this. This could have been avoided by an announcement to the list BEFORE people shopping at WalMart discovered this, as well as an appropriate sticker on the WalMart packaging like "Contains version 7.2rc1. Update your package with a free dwnload from MandrakeSoft." Unfortunately, people don't realize that all 100+ employees of MandrakeSoft need to eat as well and not all of us can work for free to create this quality distribution for you. There is nothing wrong with that, and again, this has nothing to do with the necessity of having to hit a delivery window. Harry
