Re: [Cooker] ATI AIW 7500 tuner config???
On Monday 27 January 2003 10:17 pm, Robert martin scribbled in crayon on a yellow legal pad: im mostly looking for what needs to be done to get xawtv going (but i will take any tv thing) gatos is a joke! I found everything I needed for the video card (and tuner) in /usr/src/linux/Documentation/video4linux/bttv. Kwintv (now QTview) seems nice. -- Hoyt http://www.maximumhoyt.com A -- Top posting. Q -- What's the most annoying habit in email and usenet?
[Cooker] [Bug 1120] [drakxtools] New: Display not set to expected resolution.
https://qa.mandrakesoft.com/show_bug.cgi?id=1120 Product: drakxtools Component: XFdrake Summary: Display not set to expected resolution. Version: 9.1-0.16mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hardware is a ATI Radeon All-In-Wonder 8500DV (64M), Dell 2000FP. During Install and running drakxconf the monitor is correctly detected as a dell2000FP. The default resolution as set in the install is 1600x1200 which is the monitors rated resolution. When X is started the monitor ( connected DVI ) reports 1280x1024 at 75hz. I select generic flat panel at 1600x1200 and restart X the display resolution remains the same. (the monitor is rated at 1600x1200 @ 60hz). (With 9.0 the display is set to the right resolution, but lot's of video noise, The only way to get a usable display in 9.0 is to use the ATI driver). --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
[Cooker] [Bug 1121] [xine-ui] New: Xine ratio's are wrong on a Rage Mobility 128
https://qa.mandrakesoft.com/show_bug.cgi?id=1121 Product: xine-ui Component: xine-ui Summary: Xine ratio's are wrong on a Rage Mobility 128 Version: 0.9.17-2mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: normal Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When Xine starts up the Xine logo only shows the X and part of the I in the logo. Movies look out of proportion. (This is on a IBM Thinkpad A22p. No issues with 9.0 in this machine) --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: [Cooker] A build for Athlon 64/Opteron
On Mon, 27 Jan 2003, Jure Repinc wrote: Well I sure hope there will be a port to x86-64. There is, and there will be a port to x86-64. Actually, the current focus is i586, x86-64, ia64, ppc. Per current partnerships and business. People should stop thinking MDK has to officially support ports just for fun. AFAIK, let's face it, this is demand-driven according to what we could get in back. We simply don't have the resources to do things just for personal pleasure (personal opinion, of course). Bye, Gwenole.
Re: [Cooker] drakxservices doesn't run from controlcenter
Jason Komar [EMAIL PROTECTED] writes: I can confirm this one. i can *unconfirm* this one with french, english and italian locales. using drakconf-9.1-0.12mdk, i can run drakxservices both in embedded and in standalone modes
[Cooker] Bad flash performance under cooker mozilla build
In my experience, Shockwave flash performance under mandrake has always been not smooth. Ie, image fade in and out is jerky, and animations are jerky. You can see this if you browse to www.flash.com. The main animation, if you play a bit with it, is not perfectly smooth. I have tried installing the latest player from macromedia, and have the same result. If, however, I install mozilla 1.3a from ftp.mozilla.org, and install the same flash player, playback is perfectly smooth, and I cannot see any jerkiness. I have tried using netscape compiled 6.2.3, and playback is also perfect. What else can I test to determine the cause of bad flash playback using cooker mozilla/galeon? -- Chris Picton [EMAIL PROTECTED] Tangent Systems
[Cooker] PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on media change wth busy files
Folks, unfortunately patch in 9.0/updates (or supermount/2.4.20) is buggy; it has the same bug as in 9.0. BTW, I just integrated all your patches in kernel for updates (will be in next cooker kernel). I just didn't delete put_inode() as your patch does. andrey Strange. For all I can tell it was the exact reason for disappearing andrey files. Nope, you need it to have a working: extract cd, change cd, make it working. Nope, it is just an accidental side effect. Put_inode (as it was) is buggy and not needed. ESTALE was my fault, I did not expect that the same superblock is reused on remount with busy files. The attached patch plugs the hole (reinitialize s_media_changed) until I find a proper fix. Also patch does - mode parameter was forgotten for ext2 - move setting of s_media_changed to where it belongs - check_disk_change - add MS_SUPERMOUNTED flag for future use - use MS_SUPERMOUNTED to properly respect reference count on CD eject instead of blindly disabling it - self destroying message is back, it is fixed for supermount and we should not hide errors for other cases. Now I am able to eject the cd in the middle of one operation, insert again the cd, and the operation continues with only some I/O Errors (as expected). Please, test it with this patch. Your version gives no such file or directory error again :( That now it never shows -ESTALE errors :p It still does with my patch in one case: cd /mnt/cdrom/foo eject ls /mnt/cdrom will show /mnt/cdrom/foo as ESTALE. It is because d_invalidate never invalidates busy directory. I think I know how to fix it. TODO - really fix ejecting with busy files - fix the last case of improper ESTALE - some more vague ideas cheers -andrey 2.4.21-0.pre3.1mdk.supermount.patch Description: Binary data
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
On Mon, 27 Jan 2003, HoytDuff wrote: Doesn't the holding Alt- key while grabbing the window allow you to move it around? Awkward, but useful as a workaround. Now, imagine explaining this procedure time and again to desperate users (with different WM's) calling your helpdesk about this? -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
Re: [Cooker] drakxtools drakconf
Pascal Cavy [EMAIL PROTECTED] writes: nice but can scannerdrake be fixed too ? i do not maintain it, see with till
[Cooker] [Bug 1121] [xine-ui] Xine ratio's are wrong on a Rage Mobility 128
https://qa.mandrakesoft.com/show_bug.cgi?id=1121 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 09:55 --- I don't have that video board, so I cannot test it myself. Could you please try this: -remove your configuration files ~/.xine* and let xine recreate them -change the video output device (there are a few: sdl, xv, x11,...) --- 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] description: When Xine starts up the Xine logo only shows the X and part of the I in the logo. Movies look out of proportion. (This is on a IBM Thinkpad A22p. No issues with 9.0 in this machine)
[Cooker] [Bug 790] [urpmi] Unable to install package
https://qa.mandrakesoft.com/show_bug.cgi?id=790 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|52 |12 Product ID|946 |1418 Component ID|4726|7086 Status|UNCONFIRMED |new Resolution||ASSIGNED [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Version|2.1-2mdk|4.2-12mdk --- Additional Comments From [EMAIL PROTECTED] 2003-01-24 16:20 --- ok, thanks for the information --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 10:56 --- This bug has been fixed in urpmi-4.2-13mdk. --- 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] description: 9.1 Beta1 - From Mandrake Control Center, Software Management | Install Software Using rpmdrake 9.0 I was trying to install the 'cvs' package. I did a search on 'cvs' and selected the cvs-1.11.4-1mdk package and selected install and get the following error message: There was a problem during the installation: medium Installation CD 1 (x86) (cdrom1) is not selected I thought it might be that the CD wasn't inserted at the time but that doesn't appear to be the problem. I checked the Software Sources Manager and Installation CD 1... is enabled. I was unable to install the 'cvs' package.
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes itimpossible to use!
Reinout van Schouwen [EMAIL PROTECTED] writes: Please reconsider your stance on this, I believe it is really important that the control center can be used in 640x480! mcc is usable in 800x600. making it usuable in 640x480 would mean dropping features in tools. as for tools written interactive, they can be run in text mode, which is the solution for too low resolution boxes.
Re: [Cooker] lspcidrake, sweet feature
Todd Lyons [EMAIL PROTECTED] writes: I don't know when it snuck in there, but lspcidrake also shows usb equipment, including hubs. Have I just not been paying attention? Or is this pretty new? this feature was implemented a long time ago, nearly since december 2000 :-)
Re: [Cooker] Latin-2 characters in drakxtools again
Guillaume Cottenceau [EMAIL PROTECTED] writes: Titi, I think the problem is probably that you should do the same than what I did to rpmdrake.pm to fix mcc. mcc uses libDrakX, aka common.pm and c.xs, so if mcc is broken, drakxtools are broken too
Re: [Cooker] Latin-2 characters in drakxtools again
Guillaume Cottenceau [EMAIL PROTECTED] writes: Titi, I think the problem is probably that you should do the same than what I did to rpmdrake.pm to fix mcc. mcc uses libDrakX, aka common.pm and c.xs, so if mcc is broken, drakxtools are broken too sub sprintf_fixutf8 { my $need_upgrade;
Re: [Cooker] Sources Manager == Repositories Manager
Combelles, Christophe (MED, ALTEN) [EMAIL PROTECTED] writes: In DrakConf, what do you think of replacing and in *rpmdrake* !!! Software Sources Manager with Software Repositories Manager This could avoid confusion between source code and source media ? (And I think the confusion can also occur in other languages : ex in french : gestionnaire des sources de logiciels -- gestionnaire des dépôts de logiciels) i agree. let's wait for gc thoughts on this point, so that we alter both rpmdrake and mcc if we go on on this.
[Cooker] KDE control center gone from panel(kicker)?
-- John Allen, Email: mailto:[EMAIL PROTECTED]
[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files
borzenkov == Borzenkov Andrey [EMAIL PROTECTED] writes: borzenkov Folks, unfortunately patch in 9.0/updates (or supermount/2.4.20) is buggy; borzenkov it has the same bug as in 9.0. BTW, I just integrated all your patches in kernel for updates (will be in next cooker kernel). I just didn't delete put_inode() as your patch does. andrey Strange. For all I can tell it was the exact reason for disappearing andrey files. Nope, you need it to have a working: extract cd, change cd, make it working. borzenkov Nope, it is just an accidental side effect. Put_inode (as borzenkov it was) is buggy and not needed. Are you sure? We are using put_inode() to _never_ cache inodes of supermounted media after use. Supermount relies on that behaviour. borzenkov ESTALE was my fault, I did not expect that the same borzenkov superblock is reused on remount with busy files. The borzenkov attached patch plugs the hole (reinitialize borzenkov s_media_changed) until I find a proper fix. Just saw that :( We have to reuse the superblock because we need a place to store the generation value. borzenkov Also patch does borzenkov - mode parameter was forgotten for ext2 Applied. borzenkov - move setting of s_media_changed to where it belongs - check_disk_change Done. borzenkov - add MS_SUPERMOUNTED flag for future use Done but see below. borzenkov - use MS_SUPERMOUNTED to properly respect reference count on CD eject borzenkov instead of blindly disabling it Nice, adopted. borzenkov - self destroying message is back, it is fixed for supermount and we borzenkov should not hide errors for other cases. It was just a hack :p borzenkov cd /mnt/cdrom/foo borzenkov eject borzenkov ls /mnt/cdrom borzenkov will show /mnt/cdrom/foo as ESTALE. It is because d_invalidate never borzenkov invalidates busy directory. I think I know how to fix it. will look at that. borzenkov TODO borzenkov - really fix ejecting with busy files It shouldn't be that problem, we are supposed to have the door closed if we have busy files. If you are using a floppy that don't have a locking mechanism and you retire the floppy in the middle of a write, well, you get what you asked for (an error). borzenkov - fix the last case of improper ESTALE I thought this one should been fixed, will look at it. borzenkov - some more vague ideas Humm, that is really vague. later, Juan. Now some comments about the patch: +#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE) +#define MS_SUPERMOUNTED (129) +#endif That is a bad idea, changing it to (1 17) next unused value, MS_ACTIVE MS_NOUSER are supposed to be very, very big numbers with respect to the rest of the flags. diff -ru -x '*~' -x '*.[oas]' -x '*.[oa].flags' -x .depend -x .config -x modversions.h -x '*.ver' -x autoconf.h -x version.h /usr/src/linux-2.4.21-0.pre3.1mdk/fs/inode.c linux-2.4.21-0.pre3.1mdk/fs/inode.c --- /usr/src/linux-2.4.21-0.pre3.1mdk/fs/inode.c2003-01-16 19:18:14.0 +0300 +++ linux-2.4.21-0.pre3.1mdk/fs/inode.c 2003-01-27 23:04:24.0 +0300 @@ -704,9 +704,6 @@ int res = 0; if (sb) { -#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE) - sb-s_media_changed = 1; -#endif res = invalidate_inodes(sb); drop_super(sb); } We lacked here also a shrink_dcache_sb(sb); :p -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] A build for Athlon 64/Opteron
with the way mdk is currently working they won't be able to handle it. Who said we were going to? I suppose ia64 and x64 are likely, With the way things are going now, I doubt that mdk has the manpower to maintain anything more than i586 at the moment. I think you've got it pretty much on the nose, so I don't see why this conversation is taking place, unless we're looking longterm future. So, when is the right time to talk about the long term future? We've got PPC and x86 in the works for 9.1... I sincerely doubt anything else will come of that. 9.2? Who knows. I would suspect some 64bit port, whether x86-64 or ia64, I suppose remains to be seen. but alpha and sparc? Those I sincerely doubt. That's why it was typed between ( ) and a question mark was added. With a little fantasy I could add a list of other archs that could be done, but mdk had already brought out alpha and sparc port before. Alpha is still being maintained a bit by me -- just to prove that it _can_ be done -- one you have a kernel, c library, and the compiler for an arch you can (re-)build the distro on it, automated. Well sure. I'm not saying it's a difficult thing to do, but you're implying official Mandrake development here. What do you call official? Redhat still compiles alpha (and sparc) in the rawhide distro (== redhat's cooker). These packages are available. But they don't provide official support alpha since 6.2, and sparc even longer. Keeping a port alive (community driven or not) is different from providing official support. Mdk can probably only support i586 at the moment, an reading Ben Reser's article last week, I'm wondering how well mdk is able to actually excecute. Alpha and sparc have typically been community-driven.. we've never had an official alpha port (IIRC), and sparc was last done for 7.0. Asking Mandrake to officially support more archs is one thing... nevermind the actual development cost, what about support life? If we committed to putting out 9.2 on x86, PPC, ia64, x86-64, sparc, and alpha, that's 5 ports (with x86 as main) to develop... and 5 ports to maintain for the life of the product. My theory is that buildin a port doesn't have to be very expensive, at least, if you make the investment to keep your RPMs in good working order. The complete build process can be automated. Thus, building an extra arch should cost close to nothing. Officially supporting it is a totally different ballgame. That's a *lot*. And expensive. And for what gain? I could see it for a Mandrake Server OS, but we're typically used as a desktop/workstation OS. To absorb the costs of alpha/sparc/*64, which won't be used by many for the desktop, is cost prohibitive. Now, that isn't to say something can't be done to make a community-driven port, completely unofficial and 100% community-driven. Any patches to software that need to be included to accomodate another arch can be folded into the x86 main tree so that in the end the distrib is more portable than what we would want. But I think asking Mandrake to do this officially is ludicrous. Point is, if you want to support more than one port, in a serious way, then you need to start doing things differently. I think they need to further automate the build process, bring in more regression testing of the packages, etc. Forget uploading binaries. Only upload the src.rpm's and let the backend build the binaries (on multiple platforms). I understand your point. But you make the assumption that we want to support more than one port, in a serious way. I don't recall anyone saying that this was the case. Correct me if I'm wrong, but I really don't believe anyone has ever said that Mandrake was officially interested in doing this. Not for the alpha and sparc port, and that's why I put them between hooks. But when x86 and ia64 come into the picture you will need to support them in a serious way. Is mdk going to maintain those ports like the way they doing right now with the other non-mdk ports? Or is the time ripe to rethink the way this process is done. Again, I think it's a good idea, don't get me wrong. I think this could work very well if it is community driven. There just aren't the resources to do this officially and internally. Surely you must see that. Yes, I see that. Mdk is more interested in wasting resources with tonnes of manual labour, while things could should be automated... FYI: HP just brought out new alpha machines this week... EV7 based CPU's, blows ia64 out of the water -- nothing new in that respect. HP is trying to downplay keep quite the performance numbers of the alpha in favour of ia64. It's true that alpha and sparc are used as workstation and servers, not as consumer desktops. Right. Do you have some comparison numbers? Ie. compare the typical x86 machine to an entry-level ia64 or x86-64. Then compare that to a similar Alpha or Sparc machine. The cost of those
[Cooker] RE: Konqueror vs. supermount or my CD is snapping on me!
andrey I know. For this reason disabling autoclose seems to be less evil to andrey me. But this is a driver thing, and I think that it is quite possible that a lot of hardware has it hardcoded: if you try to read cd cd is open, first close. Not sure. drivers/cdrom/cdrom.c:open_for_data() ... if (ret == CDS_TRAY_OPEN) { cdinfo(CD_OPEN, the tray is open...\n); /* can/may i close it? */ if (CDROM_CAN(CDC_CLOSE_TRAY) cdi-options CDO_AUTO_CLOSE) { cdinfo(CD_OPEN, trying to close the tray.\n); ret=cdo-tray_move(cdi,0); I do not say there is no drives that implement it in hardware. In which case disabling autoclose makes no difference. But in all cases I know of it is software, and not generic driver. -andrey
Re: [Cooker] A build for Athlon 64/Opteron
I've something running here at the moment, rebuilding alpha + i586 and uploading the alpha packages it builds. I'll be happy to set it up for mdk. Do we have a way to automate rebuilding? Reliably? I have it running on my systems for a while now. There are still some events that happen occaisionally which require human intervention, but these have been identified and I think they can be fixed. All the alpha packages being uploaded are done with the automatic rebuilding and uploading scripts. I think it's time to put up a sourceforge project for them. You'd be better off talking to Stew or Gwenole about this... they deal with the PPC and IA64 archs respectively. I'm shooting in the dark here... I don't deal with the development end of things; just the end result of a distro already built for updates. =) OK.. I'll get in touch with Stew and Gwenole. Stefan
[Cooker] RE: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on media change wth busy files
BTW, I just integrated all your patches in kernel for updates (will be in next cooker kernel). I just didn't delete put_inode() as your patch does. andrey Strange. For all I can tell it was the exact reason for disappearing andrey files. Nope, you need it to have a working: extract cd, change cd, make it working. borzenkov Nope, it is just an accidental side effect. Put_inode (as borzenkov it was) is buggy and not needed. Are you sure? We are using put_inode() to _never_ cache inodes of supermounted media after use. Supermount relies on that behaviour. No. It relies on inode generation number. When you hit stale (obsolete) inode you get ESTALE. When you hit file on NFS that has been removed on other side you get ESTALE. Same for both. Inodes not busy go away with invalidate_inodes. Inodes that _are_ busy won't ever execute your code anyway. Besides it contained spinlock bug (not that I care on UP :) The only problem is that shrink_dcache_sb does not remove reference to busy directories that explains the last case of ESTALE I described. As much as I hate to do it I am afraid subfs_umount must do it manually (check for childs of root dentry, unlink them and let them die when last reference is gone). May be shrink_dcache_parent does it, have to check. As long as current state does not show obvious bugs do not waste time with it, you have something better to do :) Cheers -andrey borzenkov ESTALE was my fault, I did not expect that the same borzenkov superblock is reused on remount with busy files. The borzenkov attached patch plugs the hole (reinitialize borzenkov s_media_changed) until I find a proper fix. Just saw that :( We have to reuse the superblock because we need a place to store the generation value. borzenkov Also patch does borzenkov - mode parameter was forgotten for ext2 Applied. borzenkov - move setting of s_media_changed to where it belongs - check_disk_change Done. borzenkov - add MS_SUPERMOUNTED flag for future use Done but see below. borzenkov - use MS_SUPERMOUNTED to properly respect reference count on CD eject borzenkov instead of blindly disabling it Nice, adopted. borzenkov - self destroying message is back, it is fixed for supermount and we borzenkov should not hide errors for other cases. It was just a hack :p borzenkov cd /mnt/cdrom/foo borzenkov eject borzenkov ls /mnt/cdrom borzenkov will show /mnt/cdrom/foo as ESTALE. It is because d_invalidate never borzenkov invalidates busy directory. I think I know how to fix it. will look at that. borzenkov TODO borzenkov - really fix ejecting with busy files It shouldn't be that problem, we are supposed to have the door closed if we have busy files. If you are using a floppy that don't have a locking mechanism and you retire the floppy in the middle of a write, well, you get what you asked for (an error). borzenkov - fix the last case of improper ESTALE I thought this one should been fixed, will look at it. borzenkov - some more vague ideas Humm, that is really vague. later, Juan. Now some comments about the patch: +#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE) +#define MS_SUPERMOUNTED (129) +#endif That is a bad idea, changing it to (1 17) next unused value, MS_ACTIVE MS_NOUSER are supposed to be very, very big numbers with respect to the rest of the flags. diff -ru -x '*~' -x '*.[oas]' -x '*.[oa].flags' -x .depend -x .config -x modversions.h -x '*.ver' -x autoconf.h -x version.h /usr/src/linux-2.4.21- 0.pre3.1mdk/fs/inode.c linux-2.4.21-0.pre3.1mdk/fs/inode.c --- /usr/src/linux-2.4.21-0.pre3.1mdk/fs/inode.c 2003-01-16 19:18:14.0 +0300 +++ linux-2.4.21-0.pre3.1mdk/fs/inode.c 2003-01-27 23:04:24.0 +0300 @@ -704,9 +704,6 @@ int res = 0; if (sb) { -#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE) - sb-s_media_changed = 1; -#endif res = invalidate_inodes(sb); drop_super(sb); } We lacked here also a shrink_dcache_sb(sb); :p -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
Re: [Cooker] Latin-2 characters in drakxtools again
Thierry Vignaud [EMAIL PROTECTED] writes: Guillaume Cottenceau [EMAIL PROTECTED] writes: Titi, I think the problem is probably that you should do the same than what I did to rpmdrake.pm to fix mcc. mcc uses libDrakX, aka common.pm and c.xs, so if mcc is broken, drakxtools are broken too Hum, LANGUAGE=el LC_ALL=el drakconf just proved me the opposite.. --- /tmp/drakconf.real 2003-01-28 12:13:45.0 +0100 +++ /usr/sbin/drakconf.real 2003-01-28 12:13:21.0 +0100 @@ -40,6 +40,8 @@ #- # i18n : IMPORTANT to get correct namespace (drakconf instead of libDrakX) unshift @::textdomains, 'drakconf'; +c::bind_textdomain_codeset($_, 'UTF8') foreach 'libDrakX', @::textdomains; +$::need_utf8_i18n = 1; my ($version, $conffile, $class_install) = (9.1, /etc/mcc.conf, /etc/sysconfig/system); -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Sources Manager == Repositories Manager
Thierry Vignaud [EMAIL PROTECTED] writes: Combelles, Christophe (MED, ALTEN) [EMAIL PROTECTED] writes: In DrakConf, what do you think of replacing and in *rpmdrake* !!! Software Sources Manager with Software Repositories Manager This could avoid confusion between source code and source media ? (And I think the confusion can also occur in other languages : ex in french : gestionnaire des sources de logiciels -- gestionnaire des dépôts de logiciels) i agree. let's wait for gc thoughts on this point, so that we alter both rpmdrake and mcc if we go on on this. why not -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Sources Manager == Repositories Manager
--- Guillaume Cottenceau [EMAIL PROTECTED] wrote: i agree. let's wait for gc thoughts on this point, so that we alter both rpmdrake and mcc if we go on on this. why not If I'm interpreting you right, by that you mean ok, I see no good reason not to do it, and will. I direct you to the following message: http://www.mail-archive.com/cooker@linux-mandrake.com/msg82587.html __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
[Cooker] [Bug 1103] [drakconf] harddrake don't run by controlcenter
https://qa.mandrakesoft.com/show_bug.cgi?id=1103 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 11:19 --- unreproductable --- 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] description: But , in a console , when i lauch harddrake2 , no probleme Sorry for my english
[Cooker] [Bug 643] [drakconf] userdrake remains active when mcc is closed
https://qa.mandrakesoft.com/show_bug.cgi?id=643 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 11:26 --- current mcc nicely kill embedded app on theme change (mcc restart) and exit --- 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] description: Using current cooker (the problem exists in Mandrake 9.0 too) : - open userdrake in the mandrake control center - use file/exit in the _mandrake control center_ menu; or close the mandrake control center window directly. - restart userdrake : /etc/gtmp and /etc/ptmp problem. userdrake remains in memory. If mcc is started from the command line, a bunch of gtk error messages about destroyed windows is displayed. Workaround allowing mcc to close userdrake in this case : --- drakconf.real.orig 2002-11-27 10:52:50.0 +0100 +++ drakconf.real 2002-12-15 22:22:47.0 +0100 @@ -656,7 +656,8 @@ } sub quit_global { -foreach (@pid_launched,@pid_exp) { kill 'TERM', $_ if defined $_ } +clean_socket(); +foreach (@pid_exp) { kill 'TERM', $_ if defined $_ } setVarsInSh($conffile, { EMBEDDED = bool2text($embedded), LOGS = bool2text($logs),
[Cooker] [Bug 985] [drakconf] 9.1beta2 MCC System subpanel icons fail or do not update display
https://qa.mandrakesoft.com/show_bug.cgi?id=985 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 12:30 --- forgot to close (was fixed in 0.10mdk) --- 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] description: In 9.1beta2, if you open MCC and select System, clicking on just about anything (font, date/time, servers) gets you a Please Wait display that stays there forever. Launching the individual service, e.g. drakfont, from a command line works fine. In the case of drakfont, drakfont is actually started but the display is not updated. If you transfer focus to another window and then back to MCC, the display updates and the drakfont dialog is visible. In the case of date/time, the same procedure causes MCC to update the display back to the icon list. Here is the stderr obtained by launching drakconf from the command line, selecting System, Date/Time, and then switching focus to cause the display update: Use of uninitialized value in split at /usr/lib/libDrakX/detect_devices.pm line 111 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, that $foo is usually optimized into that . $foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program. Use of uninitialized value in string eq at /usr/lib/libDrakX/detect_devices.pm line 200 (#1) Use of uninitialized value in concatenation (.) or string at /usr/lib/libDrakX/detect_devices.pm line 533 (#1) BUG with LANGUAGE en_US:en TODO: XSetInputFocus if force_focus TODO: ensure focus stuff (drakconf.real:2573): Gdk-CRITICAL **: file ../../gdk/gdkdraw.c: line 238 (gdk_drawable_get_display): assertion `GDK_IS_DRAWABLE (drawable)' failed (clock.pl:2587): Gtk-CRITICAL **: file ../../gtk/gtkwidget.c: line 5209 (gtk_widget_set_events): assertion `!GTK_WIDGET_REALIZED (widget)' failed Can't call method draw_rectangle on an undefined value at /usr/sbin/clock.pl line 234. (drakconf.real:2573): Gtk-CRITICAL **: file ../../gtk/gtkwidget.c: line 1626 (gtk_widget_destroy): assertion `GTK_IS_WIDGET (widget)' failed
[Cooker] [Bug 1085] [Installation] Unable to Install due to partition table format error
https://qa.mandrakesoft.com/show_bug.cgi?id=1085 --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 12:34 --- I have done some more testing on this problem to ensure it is not to do with dodgy disks. I created 2 partitions on a blank 8gb disk at work, 2gb primary, rest extended, drive d 2gb. I then ran the install on a pc at work and it had no complaints about the disk. I aborted the installation once it had formatted the disk, took the drive home and attached it to my primary raid channel as the boot disk. Once again upon trying to install Mandrake it was unable to read my partition table info. --- 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] description: I am using Cooker-9.1-i586 20030117 19:04 I have 2 60GB IDE drives connected to seperate channels on a Highpoint 372 Raid controller on an Abit KX7-333R motherboard. I am not using the Raid controller for Raid functionality but for performance. I have set aside 20gb to install Beta 2 on the 2nd disk. I have a dualboot with WinXP installed on Disk 1 and WinME on Disk 2. The installer detects the drives ok as far as i can tell however after accepting the license the installer complains that both drives have unknown partition table formats. the log shows : test_for_hard_drives (/dev/hde) error reading magic number on disk hde at /usr/bin/perl-install/partition_table/empty.pm line 28 error while reading partition table in sector 0 at /usr/bin/perl-install/partition_table/dos.pm line 63 it then goes on to fail reading sector 0 in bsd.pm, sun.pm mac.pm I have got Powerquest Bootmagic installed however i was suffering this fault before i installed it. The installer fails on both my drives which are seen has HDE HDG. I have tried adding a 3rd IDE disk as HDG which is unformatted and it doesn't complain about this. Partiomagic's Partition Info utility gives the following details about my partition tables PowerQuest PartitionInfo 8.0 -- Windows NT/2000 Version Date Generated: 01/26/03 17:34:46 Copyright (c)1994-2002, PowerQuest Corporation Permission is granted for this utility to be freely copied so long as it is not modified in any way. All other rights are reserved. PowerQuest, makers of PartitionMagic(r), Drive Image(tm), and DriveCopy(tm), can be reached at: Voice: 801-437-8900 Fax: 801-226-8941 Web site: http://www.powerquest.com/support/ E-mail: [EMAIL PROTECTED] General System Information: Total Physical Memory (bytes): 536,334,336 Used Physical Memory: (bytes): 339,365,888 Maximum Page File Size: (bytes): 1,311,584,256 Current Page File Size: (bytes): 375,005,184 === Disk Geometry Information for Disk 1:7297 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINXP 0 0 80 011 0C1023 254 63 63 81,931,437 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 80 011 0C 5099 254 6363 81931437 0 1 00 102301 0F1023 254 63 81,931,500 35,294,805 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 1 00 510001 0F 7296 254 63 81931500 35294805 81,931,500 0 00 102311 0B1023 254 63 81,931,563 35,294,742 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 81931500 0 00 510011 0B 7296 254 63 81931563 35294742 === Disk Geometry Information for Disk 2:7476 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINME 0 0 00 011 0C1023 254 63 63 39,809,007 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 00 011 0C 2477 254 6363 39809007 DOS STUFF 0 1 00 102301 0C1023 254 63 39,809,070 40,965,750 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large
[Cooker] [Bug 1085] [Installation] Unable to Install due to partition table format error
https://qa.mandrakesoft.com/show_bug.cgi?id=1085 --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 12:47 --- Try passing pci=noacpi at boot. Stef --- 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] description: I am using Cooker-9.1-i586 20030117 19:04 I have 2 60GB IDE drives connected to seperate channels on a Highpoint 372 Raid controller on an Abit KX7-333R motherboard. I am not using the Raid controller for Raid functionality but for performance. I have set aside 20gb to install Beta 2 on the 2nd disk. I have a dualboot with WinXP installed on Disk 1 and WinME on Disk 2. The installer detects the drives ok as far as i can tell however after accepting the license the installer complains that both drives have unknown partition table formats. the log shows : test_for_hard_drives (/dev/hde) error reading magic number on disk hde at /usr/bin/perl-install/partition_table/empty.pm line 28 error while reading partition table in sector 0 at /usr/bin/perl-install/partition_table/dos.pm line 63 it then goes on to fail reading sector 0 in bsd.pm, sun.pm mac.pm I have got Powerquest Bootmagic installed however i was suffering this fault before i installed it. The installer fails on both my drives which are seen has HDE HDG. I have tried adding a 3rd IDE disk as HDG which is unformatted and it doesn't complain about this. Partiomagic's Partition Info utility gives the following details about my partition tables PowerQuest PartitionInfo 8.0 -- Windows NT/2000 Version Date Generated: 01/26/03 17:34:46 Copyright (c)1994-2002, PowerQuest Corporation Permission is granted for this utility to be freely copied so long as it is not modified in any way. All other rights are reserved. PowerQuest, makers of PartitionMagic(r), Drive Image(tm), and DriveCopy(tm), can be reached at: Voice: 801-437-8900 Fax: 801-226-8941 Web site: http://www.powerquest.com/support/ E-mail: [EMAIL PROTECTED] General System Information: Total Physical Memory (bytes): 536,334,336 Used Physical Memory: (bytes): 339,365,888 Maximum Page File Size: (bytes): 1,311,584,256 Current Page File Size: (bytes): 375,005,184 === Disk Geometry Information for Disk 1:7297 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINXP 0 0 80 011 0C1023 254 63 63 81,931,437 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 80 011 0C 5099 254 6363 81931437 0 1 00 102301 0F1023 254 63 81,931,500 35,294,805 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 1 00 510001 0F 7296 254 63 81931500 35294805 81,931,500 0 00 102311 0B1023 254 63 81,931,563 35,294,742 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 81931500 0 00 510011 0B 7296 254 63 81931563 35294742 === Disk Geometry Information for Disk 2:7476 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINME 0 0 00 011 0C1023 254 63 63 39,809,007 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 00 011 0C 2477 254 6363 39809007 DOS STUFF 0 1 00 102301 0C1023 254 63 39,809,070 40,965,750 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 1 00 247801 0C 5027 254 63 39809070 40965750 === Partition Information for Disk 1:57,239.4 Megabytes Volume PartTypeStatusSize MBPartSect # StartSect TotalSects
Re: [Cooker] Latin-2 characters in drakxtools again
Guillaume Cottenceau [EMAIL PROTECTED] writes: Titi, I think the problem is probably that you should do the same than what I did to rpmdrake.pm to fix mcc. mcc uses libDrakX, aka common.pm and c.xs, so if mcc is broken, drakxtools are broken too Hum, LANGUAGE=el LC_ALL=el drakconf just proved me the opposite.. --- /tmp/drakconf.real 2003-01-28 12:13:45.0 +0100 +++ /usr/sbin/drakconf.real 2003-01-28 12:13:21.0 +0100 @@ -40,6 +40,8 @@ #- # i18n : IMPORTANT to get correct namespace (drakconf instead of libDrakX) unshift @::textdomains, 'drakconf'; +c::bind_textdomain_codeset($_, 'UTF8') foreach 'libDrakX', @::textdomains; +$::need_utf8_i18n = 1; my ($version, $conffile, $class_install) = (9.1, /etc/mcc.conf, /etc/sysconfig/system); after discussing with gc, the real solution if to move the init stuff from interactive-vnew int standalone.pm module.
[Cooker] Re: [Contrib-Rpm] vsftpd-1.2.0-1mdk
Brook Humphrey wrote: [Contrib-RPM] --=-=-= Name: vsftpd Relocations: (not relocateable) Version : 1.2.0 Vendor: MandrakeSoft Release : 1mdk Build Date: Tue Jan 28 10:24:34 2003 --=-=-= * Thu Jan 16 2003 Brook Humphrey [EMAIL PROTECTED] 1.2.0-1mdk - Packaged for Mandrake already included in main ! please *remove* it from *contrib*. [yves@klama yves]$ rpm -qp --changelog /SRPMS/vsftpd-1.2.0-1mdk.src.rpm * Tue Jan 14 2003 Damien Chaumette [EMAIL PROTECTED] 1.2.0-1mdk - 1.2.0 version * Tue Oct 15 2002 Damien Chaumette [EMAIL PROTECTED] 1.1.1-1mdk - 1.1.1 version * Sun May 26 2002 Yves Duret [EMAIL PROTECTED] 1.0.1-1mdk - first mandrake version
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
Hello Thierry, On Tue, 28 Jan 2003, Thierry Vignaud wrote: making it usuable in 640x480 would mean dropping features in tools. Or redesigning them to be usable in 640x480. I'm not saying this is easy, but I am saying it is necessary. as for tools written interactive, they can be run in text mode, which is the solution for too low resolution boxes. I'm sorry, but from an unexperienced user point of view, this is no solution, but a reason to throw that stupid difficult Linux thing aside. regards, -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
[Cooker] Monitor to add to MonitorsDB
Could you please add this one: LG Electronics Inc.; LG StudioWorks 995E; gsm4a4c; 30.0-96.0; 50.0-160.0; 1 Thanks. -- Live long and prosper!
[Cooker] Re: [Contrib-Rpm] vsftpd-1.2.0-1mdk
On Tue, Jan 28, 2003 at 12:58:42PM +0100, Yves Duret wrote: Brook Humphrey wrote: Name: vsftpd Relocations: (not relocateable) Version : 1.2.0 Vendor: MandrakeSoft * Thu Jan 16 2003 Brook Humphrey [EMAIL PROTECTED] 1.2.0-1mdk - Packaged for Mandrake already included in main ! please *remove* it from *contrib*. Sorry. Done. lenny
Re: [Cooker] Eterm 0.9.2-1 problems
On Mon, Jan 27, 2003 at 06:52:37PM -0800, Quel Qun wrote: I disagree, here. I have been using cooker for years, before the birth of urpmi. I still prefer using rpm (with simple additional scripts) than urpmi. I use urpmf extensively but don't trust urpmi enough for something sometimes as delicate as cooker. That's backwards - for using cooker urpmi is nearly essential. Trying to do it with rpm alone is a step backwards. In every case of bad RPM installs I've helped fix it was NOT because of a flaw in urpmi but because of misuse of --force or --nodeps with plain old rpm. urpmi may refuse to install something due to some idiotic dep that only a moron would invent (msec for drak tools?) but I've never seen it install something it shouldn't. -- Murray J. Root
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
--- Reinout van Schouwen [EMAIL PROTECTED] wrote: Hello Thierry, On Tue, 28 Jan 2003, Thierry Vignaud wrote: making it usuable in 640x480 would mean dropping features in tools. Or redesigning them to be usable in 640x480. I'm not saying this is easy, but I am saying it is necessary. as for tools written interactive, they can be run in text mode, which is the solution for too low resolution boxes. I'm sorry, but from an unexperienced user point of view, this is no solution, but a reason to throw that stupid difficult Linux thing aside. You're being totally unreasonable. If someone's got a monitor so crappy that they can't even run at 800x600, they use a different frontend to the draktools. That's part of the reason different frontends exist! The point isn't that every frontend is supported on every single machine, the point is that all machines are covered by at least one frontend, so nobody can bitch about their machine not being supported. Are you gonna whine and complain to us when you find Gnome and Evolution unusable on a P133 with 16MB RAM??? I sure hope not. Doesn't mean Mandrake doesn't support the machine, but you have to use tools more fit to it (IceWM and mutt maybe). __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Cooker] A build for Athlon 64/Opteron
Le Mardi 28 Janvier 2003 09:45, Gwenole Beauchesne a écrit : On Mon, 27 Jan 2003, Jure Repinc wrote: Well I sure hope there will be a port to x86-64. There is, and there will be a port to x86-64. Actually, the current focus is i586, x86-64, ia64, ppc. Per current partnerships and business. People should stop thinking MDK has to officially support ports just for fun. AFAIK, let's face it, this is demand-driven according to what we could get in back. We simply don't have the resources to do things just for personal pleasure (personal opinion, of course). That's why, I pupose contributors help you, and that's why I actually rebuild contrib for ppc. Maybe you didn't notice, but I uploaded yesterday samba3 for ppc ! I agree porting is not only for fun, and you can't do all for fun, but give a place to poeple who seriously want to help you if you can't doing more. Contrib is unsupported - Some poeple who have the good hardware can do this, think contrib is often a good place for testing apps too (apache2, samba3 actually). Why not contributors start to rebuild stuff for x86-64, and switch to offical ports later ? Contributors a not here only to report bugs, Somes really want to help ! I you talk about place on mirror, removing sparc (someone use/follow it ?), cookfire (obsolete ?) will give about 5 GB ! -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] Eterm 0.9.2-1 problems
Murray J. Root [EMAIL PROTECTED] writes: some idiotic dep that only a moron would invent (msec for drak tools?) draksec needs msec.
Re: [Cooker] Eterm 0.9.2-1 problems
On Tue, Jan 28, 2003 at 02:01:01PM +0100, Thierry Vignaud wrote: Murray J. Root [EMAIL PROTECTED] writes: some idiotic dep that only a moron would invent (msec for drak tools?) draksec needs msec. I don't use draksec. Now, due to this dep, I don't use drak tools at all. -- Murray J. Root
[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files
Juan you take care to integrate them ,
Re: [Cooker] Bad md5sums on 91 ISO's; CHECK yours
I mirror from ftp.uninett.no with rsync. I get: [nanardon@virgo i586]$ md5sum MandrakeLinux-9.1beta2-CD1.i586.iso 174db6ae3032ea1f48445a725427bd50 MandrakeLinux-9.1beta2-CD1.i586.iso Then all is ok here. Copy on this mirror is maybe bad. It is to slow for me to make more test (7 kB/s) :(. ftp://raven.cslab.vt.edu/pub/linux/mandrake-iso/i586/MandrakeLinux-9.1beta2 -CD1.i586.iso cf739ac78ca83b312d5969eb3241d453 MandrakeLinux-9.1beta2-CD1.i586.iso then your copy is bogus, like mine. The only number that you should see for an md5sum on the first cd is 174db6ae3032ea1f48445a725427bd50 -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files
chmouel == Chmouel Boudjnah [EMAIL PROTECTED] writes: chmouel Juan you take care to integrate them , will be there, integrating them in the kernel for updates. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy
[Cooker] [Bug 1107] [squid] doesn't work. Seems like initialisation didn't happen.
https://qa.mandrakesoft.com/show_bug.cgi?id=1107 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 13:50 --- squid-2.5.STABLE1-5mdk it works here: /etc/init.d/squid status squid (pid 12295) is running... 12293 (pid ) is running... tail -f /var/log/messages Jan 28 13:48:03 sunlight squid[12293]: Squid Parent: child process 12295 started --- 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] description: It appears the directories weren't created with proper permission and the initialisation didn't happen properly. I'm running NIS+. It can very much be a problem in my setup too. I'll let someone else decide if this is a valid problem. Also this is my first bug posting. Please let me know any etiquette that i need to follow to post bugs. Thanks, -Ramesh. Jan 26 13:46:50 rameshms-lnx squid: init_cache_dir /var/spool/squid... Jan 26 13:46:50 rameshms-lnx squid: Failed to make swap directory /var/spool/squid/00: (13) Permission denied Jan 26 13:46:50 rameshms-lnx squid: Starting squid: Jan 26 13:46:50 rameshms-lnx squid: ^[[65G[^[[1;32m Jan 26 13:46:50 rameshms-lnx squid[4870]: Squid Parent: child process 4873 started Jan 26 13:46:50 rameshms-lnx (squid): Cannot open '/var/log/squid/access.log' for writing. ^IThe parent directory must be writeable by the ^Iuser 'squid', which is the cache_effective_user ^Iset in squid.conf. Jan 26 13:46:50 rameshms-lnx squid[4870]: Squid Parent: child process 4873 exited due to signal 6 Jan 26 13:46:50 rameshms-lnx squid: Jan 26 13:46:50 rameshms-lnx rc: Starting squid: succeeded Jan 26 13:46:50 rameshms-lnx echo: 0 Jan 26 13:46:50 rameshms-lnx rc: Disabling Boot logo succeeded Jan 26 13:46:53 rameshms-lnx squid[4870]: Squid Parent: child process 4898 started Jan 26 13:46:53 rameshms-lnx (squid): Cannot open '/var/log/squid/access.log' for writing. ^IThe parent directory must be writeable by the ^Iuser 'squid', which is the cache_effective_user ^Iset in squid.conf.
[Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
https://qa.mandrakesoft.com/show_bug.cgi?id=1048 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 13:53 --- Reinout - MCC is just exactly NOT useable in 800x600 under gnome. Gnome eliminates 50 pixels top and bottom, making it impossible to click on the buttons on drakconnect, for example. KDE also eliminates 50 pixels unless you slide the toolbar away. --- 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] description: Our computers run with 800x600 screens. Some of our computers are 640x480 - and all setup screens should work at that resolution! Under gnome, I cannot get to the buttons on a number of the panels, as they are laid out too big. The big blue stripe should be removed - it hogs all the screen space. A good example is the network startup screen.
[Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
https://qa.mandrakesoft.com/show_bug.cgi?id=1048 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Version|9.1-0.9mdk |9.1-0.7mdk --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 14:03 --- instead of reopening fixed bug, test latest version. if you would have do, you would have saw that mcc is currently 720x523 pixels without wm decoration, 722*555 with windowmaker decoration --- 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] description: Our computers run with 800x600 screens. Some of our computers are 640x480 - and all setup screens should work at that resolution! Under gnome, I cannot get to the buttons on a number of the panels, as they are laid out too big. The big blue stripe should be removed - it hogs all the screen space. A good example is the network startup screen.
[Cooker] [Bug 1122] [kdenetwork] New: Pop attachment makes kmail crash
https://qa.mandrakesoft.com/show_bug.cgi?id=1122 Product: kdenetwork Component: program Summary: Pop attachment makes kmail crash Version: 3.1-0.rc6.3mdk Platform: PC OS/Version: All Status: UNCONFIRMED Severity: major Priority: P2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've had this problem since 9.1beta1 (I'm keeping in sync with cooker). Whenever I try to download email messages with any number of file attached kmail hangs in death. It starts downloading the message, but suddenly the progress bar (as well as the download itself) stops, apparently when it comes to manage the very attachment. It downloads fine if there are no attachments in the messages to be retrieved, anyhow. I've tried to enable/disable pop filters, as well as to enable/disable pipelining, but it wouldn't change. Daniele --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is.
Re: [Cooker] [Bug 1104] [Installation] New: No device nodes for cdrom drive
[Bug 1104] [EMAIL PROTECTED] writes: Installed on a system with hard disk as hda and cdrom as hdb (slave on 1st ide channel). is /dev/scd0 there?
Re: [Cooker] [Bug 1113] [Installation] New: ISA cards not detected.
[Bug 1113] [EMAIL PROTECTED] writes: @resolution=wontfix
Re: [Cooker] [Bug 1114] [drakxtools] New: DiskDrake during Install can lock up.
[Bug 1114] [EMAIL PROTECTED] writes: After I assigned mount points to all paritions, the system prompted for permission to format the sdb partitions. It appears that the format fo the sdb partitions was started in parallel with the fsck of the sda partitions. nothing is done in parallel. When the errors on sda1 were detected, the system locked up with the fdisk repair prompt at the top of the screen, and the formatting status box in the middle of the screen. A hard reset was needed. is it a text install? a lost dialog box bug was found causing this.
Re: [Cooker] [Bug 1115] [Installation] New: No boot floppy created during install.
[Bug 1115] [EMAIL PROTECTED] writes: I'm installing 9.1beta2 on sdb on a system that has a working RH6.2 installation on sda. I placed the boot sector in the first sector of the root partition on sdb (sdb1). I was never prompted to create a boot floppy, so I was unable to boot cleanly to test the 9.1 beta2 install. in cooker, you can choose to install the bootloader on floppy. It should do what you want. @resolution=fixed
Re: [Cooker] [Bug 1119] [Installation] New: Installer does not provide a prompt to create a boot floppy.
[Bug 1119] [EMAIL PROTECTED] writes: In expert mode there is not option to create a boot floppy ( or any other form of removable media) fixed in cooker (and so in upcoming beta3) @resolution=fixed
Re: [Cooker] [Bug 1120] [drakxtools] New: Display not set to expected resolution.
[Bug 1120] [EMAIL PROTECTED] writes: When X is started the monitor ( connected DVI ) reports 1280x1024 at 75hz. I select generic flat panel at 1600x1200 and restart X the display resolution remains the same. (the monitor is rated at 1600x1200 @ 60hz). (With 9.0 the display is set to the right resolution, but lot's of video noise, The only way to get a usable display in 9.0 is to use the ATI driver). please have a look at the differences between /etc/X11/XF86Config-4 from 9.0 and 9.1beta. if there is none, the pb is hardware and you should assign this pb to product XFree86
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
On Tue, 2003-01-28 at 12:52, David Walser wrote: I'm sorry, but from an unexperienced user point of view, this is no solution, but a reason to throw that stupid difficult Linux thing aside. You're being totally unreasonable. If someone's got a monitor so crappy that they can't even run at 800x600, they use a different frontend to the draktools. That's part of the reason different frontends exist! The point isn't that every frontend is supported on every single machine, the point is that all machines are covered by at least one frontend, so nobody can bitch about their machine not being supported. *sigh* Are you just wilfully ignoring the actual experience that's been posted to this list? For the fourth time, I use a laptop. It's perfectly powerful enough to run KDE or GNOME (I use GNOME). Because it's a cunning small laptop, it has a half-height screen, whose resolution is 1024x480. The biggest obstacle to using Mandrake on this laptop is the fact the most Mandrake tools use large windows with no scrollbars. This is a fixable problem. -- adamw
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
Hello David, On Tue, 28 Jan 2003, David Walser wrote: Or redesigning them to be usable in 640x480. I'm not You're being totally unreasonable. If someone's got a I'm sorry that you find me acting unreasonable, I have no such intention. monitor so crappy that they can't even run at 800x600, they use a different frontend to the draktools. At the risk of repeating myself, two points: 1. Being able to run at 800x600 doesn't necessarily mean someone actually uses that resolution. Is it so difficult to see that, as long as a user can switch resolution to 640x480 using mcc, he should be able to revert back using that same tool?! 2. Requiring different frontends makes things more complicated than needed, thus putting off users on the one hand, and generating support requests on the other. It's details like these why reviewers keep saying that Mandrake always has a little unfinished feel about it. are covered by at least one frontend, so nobody can bitch about their machine not being supported. You are effectively saying that a user running at 640x480 should use a different frontend. Then why doesn't launching mcc in a low resolution automatically switch to framebuffer (DrakX) mode to enable the user to change his settings instead of forcing him to find out about the different frontends himself? Are you gonna whine and complain to us when you find Gnome and Evolution unusable on a P133 with 16MB RAM??? I sure hope not. Doesn't mean No, but that's totally besides the point. We're discussing a *configuration tool* here, which almost by definition needs to support the lowest common denominator. regards, -- Reinout van SchouwenArtificial Intelligence student email: [EMAIL PROTECTED] mobile phone: +31-6-44360778 GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
[Cooker] After Upgrade - service dm doesn't start
I have upgraded several machines with the latest Cooker install and after restart - it dumps me to a console. Apparently the service dm is not starting. When I start it manually - it works fine. It is also check to start at boot under DrakXservices. Thx, R.Fox -- Robert Fox [EMAIL PROTECTED] Fox Consulting Services
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes itimpossible to use!
Adam Williamson [EMAIL PROTECTED] writes: Are you just wilfully ignoring the actual experience that's been posted to this list? For the fourth time, I use a laptop. It's perfectly powerful enough to run KDE or GNOME (I use GNOME). Because it's a cunning small laptop, it has a half-height screen, whose resolution is 1024x480. The biggest obstacle to using Mandrake on this laptop is the fact the most Mandrake tools use large windows with no scrollbars. This is a fixable problem. No it isn't. at least not easily. i've used scrolled windows and viewports in the past in tests, and these widgets're basically often unusable. look at draksec bug on click on pull-down menus. or remember the scrolling bugs of pre mdk9.0 harddrake2 ? too few gtk+ widget have native scrolling support. so as i have stated to people who directly mailed me : - if screen resolution is at least 800x600, then one can use embedded apps. note than for some tools, i'have to hide the logdrake logs. - if one has a smaller screen, a lot of tools will fits, but drakxconf shall be used instead of drakconf. the difference being that drakxconf use the interactive widget that enable to use text and http frontends whereas drakconf is a pure gtk+ app. so when one hasn't enough space, one can: - use drakxconf - use tools in text mode (so no harddrake, ...) btw: having *ONE* tool usable at 640x480 resolution does *NOT* imply it'll still fits when embedded in the mcc, where there'll be mcc decorations around it plus logdrake plug for the logs. one uses the right tool in the right place. there're http and text frontends for most important tools. this is always the same debat as: - rpm vs urpmi vs rpmdrake/MandrakeUpdate - kde vs icewm/wm/... - links-graphic vs mozilla - ...
[Cooker] typo in DrakX
in standalone.pm myfyle -- myfile
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
Thierry Vignaud wrote: Adam Williamson [EMAIL PROTECTED] writes: so as i have stated to people who directly mailed me : - if screen resolution is at least 800x600, then one can use embedded apps. note than for some tools, i'have to hide the logdrake logs. - if one has a smaller screen, a lot of tools will fits, but drakxconf shall be used instead of drakconf. the difference being that drakxconf use the interactive widget that enable to use text and http frontends whereas drakconf is a pure gtk+ app. so when one hasn't enough space, one can: - use drakxconf - use tools in text mode (so no harddrake, ...) btw: having *ONE* tool usable at 640x480 resolution does *NOT* imply it'll still fits when embedded in the mcc, where there'll be mcc decorations around it plus logdrake plug for the logs. one uses the right tool in the right place. And how are people supposed to use it if it's not visible??? there're http and text frontends for most important tools. this is always the same debat as: - rpm vs urpmi vs rpmdrake/MandrakeUpdate - kde vs icewm/wm/... - links-graphic vs mozilla - ... Mutt: Start-Networking-Mail-Mutt Links:Start-Networking-WWW-links drakxconf? How about: Start-Configuration-Mandrake Tools (low resolution) Of course, if you could use it without a mouse (so one could configure a mouse when the mouse isn't working!) that would be much better ... How difficult would it be to make drakxconf take keyboard input (probably easier than drakconf). Buchan -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] fix for ncurses spec file
Nick Brown [EMAIL PROTECTED] writes: the ncurses spec file contains this nasty hack; # # FIXME # OK do not time to debbug it now # cp /$RPM_BUILD_ROOT/%{_datadir}/terminfo/x/xterm /$RPM_BUILD_ROOT/%{_datadir}/terminfo/x/xterm2 cp /$RPM_BUILD_ROOT/%{_datadir}/terminfo/x/xterm-new /$RPM_BUILD_ROOT/%{_datadir}/terminfo/x/xterm # # FIXME # the real problem is these lines (2923-2926) in terminfo.src ; # This is xterm for ncurses. xterm|xterm terminal emulator (X Window System), use=xterm-r6, # use=xterm-xfree86, so xterm is using xterm-r6 which among others things does not do color. so you cp xterm-new entry on top of xterm. thats not the way to fix things. You should instead patch the above part of terminfo.src. I suggest using the xterm-xfree86 entry that is commented out, or as you seem to want use xterm-new, patch it to that. Thus you can get rid of that hack. I will have a look -- Warly
[Cooker] Re: [drakconf] Screen layout makes it impossible to use!
On Tue Jan 28 16:47 +0200, Buchan Milne wrote: - if screen resolution is at least 800x600, then one can use embedded apps. note than for some tools, i'have to hide the logdrake logs. - if one has a smaller screen, a lot of tools will fits, but drakxconf shall be used instead of drakconf. the difference being that drakxconf use the interactive widget that enable to use text and http frontends whereas drakconf is a pure gtk+ app. so when one hasn't enough space, one can: - use drakxconf - use tools in text mode (so no harddrake, ...) btw: having *ONE* tool usable at 640x480 resolution does *NOT* imply it'll still fits when embedded in the mcc, where there'll be mcc decorations around it plus logdrake plug for the logs. one uses the right tool in the right place. And how are people supposed to use it if it's not visible??? At the very least, when someone sets resolution to 640x480 (which is a resolution that does not, under any circumstances work with mcc without wm workarounds...), pop up a box saying something to the effect of drakconf may not be usable at the selected resolution. To change the resolution from this resolution to something else, please use drakxconf or text-mode tools. with a checkbox for do not show this again. This way, any users who do set the resolution to 640x480 are at least informed that drakconf may not work and that there are tools that will do the job better in this situation. -- -- Levi Ramsey [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Fingerprint: 354C 7A02 77C5 9EE7 8538 4E8D DCD9 B4B0 DC35 67CD Currently playing: Metallica - Fixxxer Linux 2.4.21pre3-2mdk 09:42:33 up 1 min, 0 users, load average: 1.18, 0.31, 0.10
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes itimpossible to use!
Buchan Milne [EMAIL PROTECTED] writes: Of course, if you could use it without a mouse (so one could configure a mouse when the mouse isn't working!) that would be much better ... drakxconf is usable without a mouse since it works smoothly as a gui well as on the console How difficult would it be to make drakxconf take keyboard input (probably easier than drakconf). it's already the case :-)
Re: [Cooker] broken packages on the mirrors (cups-drivers and vlc)
Kim Schulz [EMAIL PROTECTED] writes: hi Found two broken files on the mirrors (I have tested serval mirrors in primarily North Europe). This is what I get: 4:cups-drivers error: unpacking of archive failed on file /usr/share/cups/model/Kyocera-PostScript/FS-1700.ppd.gz;3e31c364: cpio: MD5 sum mismatch 6:vlcerror: unpacking of archive failed on file /usr/lib/vlc/audio_output/libaout_file_plugin.so;3e31c364: cpio: MD5 sum mismatch [root@ken warly]# rpm -K /contrib/RPMS/vlc-0.5.0-0.20030128.1mdk.i586.rpm /contrib/RPMS/vlc-0.5.0-0.20030128.1mdk.i586.rpm: md5 OK [root@ken warly]# rpm -K /RPMS/cups-drivers-1.1-88mdk.i586.rpm /RPMS/cups-drivers-1.1-88mdk.i586.rpm: md5 gpg OK -- Warly
Re: [Cooker] typo in DrakX
Combelles, Christophe (MED, ALTEN) [EMAIL PROTECTED] writes: in standalone.pm myfyle -- myfile oops! thanks.
Re: [Cooker] A build for Athlon 64/Opteron
On Tuesday 28 January 2003 02:49 am, Stefan van der Eijk wrote: I've something running here at the moment, rebuilding alpha + i586 and uploading the alpha packages it builds. I'll be happy to set it up for mdk. Do we have a way to automate rebuilding? Reliably? I have it running on my systems for a while now. There are still some events that happen occaisionally which require human intervention, but these have been identified and I think they can be fixed. All the alpha packages being uploaded are done with the automatic rebuilding and uploading scripts. Hm would you mind sharing? Honestly I would not mind starting up project athlon again and already have have space to support it and for others to download. Who knows maybe even we can someday get to the point were at least the kernel is for the arch it's running on. Another comment for the others not you Stefan. If it is so hard to do all this how come ark linux run by maybe one or two guys can (bero for sure who started mandrake on the i586 builds) have builds for i586, i686, athlon, pentium3, and pentium4. Admittedly they are all x86 but they still have builds for all those and they are very few. I think it's time to put up a sourceforge project for them. You'd be better off talking to Stew or Gwenole about this... they deal with the PPC and IA64 archs respectively. I'm shooting in the dark here... I don't deal with the development end of things; just the end result of a distro already built for updates. =) OK.. I'll get in touch with Stew and Gwenole. Stefan -- -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, [EMAIL PROTECTED], [EMAIL PROTECTED] Holiness unto the Lord -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
Re: [Cooker] typo in DrakX (another)
Another one: in standalone.pm directry -- directory Combelles, Christophe (MED, ALTEN) wrote: in standalone.pm myfyle -- myfile
Re: [Cooker] After Upgrade - service dm doesn't start
On Tue, 2003-01-28 at 07:34, Robert Fox wrote: I have upgraded several machines with the latest Cooker install and after restart - it dumps me to a console. Apparently the service dm is not starting. When I start it manually - it works fine. It is also check to start at boot under DrakXservices. Thx, R.Fox Robert, When I upgraded X yesterday, the upgrade changed my runlevel from 5 to 3. Check /etc/inittab to see if it did the same to you. Switch it to 5 and you should be good to go. -- Jason Komar [EMAIL PROTECTED] Lubetec
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
Thierry Vignaud wrote: Buchan Milne [EMAIL PROTECTED] writes: Of course, if you could use it without a mouse (so one could configure a mouse when the mouse isn't working!) that would be much better ... drakxconf is usable without a mouse since it works smoothly as a gui well as on the console Sure, but I was meaning in X! How difficult would it be to make drakxconf take keyboard input (probably easier than drakconf). it's already the case :-) Please. Consider something that affects new users who have only ever used Windows (and Windows has had this since Windows 95, yes, that's 7 years ago!). 1)Windows almost always gives you a GUI. In the worst cases, you may have to use safe mode. Only if you're an MCSE are you supposed to know about things like the recovery console (on win2k). 2)You can fix anything from the gui without a mouse. Even the mouse. 3)90% of new users of Mandrake are lost if X doesn't start (see some of the recent bug reports for examples where people think the installation failed because X didn't start). So, how about addressing some of this, by: a)If X keeps crashing, start X in vesa mode, starting up XFdrake or drakxconf or similar to try and fix the config b)Allow a user to configure a mouse in this mode without a mouse c)Have the failsafe boot option pass a parameter to the dm service which starts it like this by default. For a distribution aiming at converting existing windows users, you really need to make it *seem* bullet-proof. We all know it is, convincing point-and-clickers that it is means ensuring that if they wanted a GUI, they *always* get one, and can fix *anything* (besides fsck of course, which even windows can't do in a GUI) with GUI tools. Buchan -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] broken packages on the mirrors (cups-drivers and vlc)
Warly wrote: Kim Schulz [EMAIL PROTECTED] writes: hi Found two broken files on the mirrors (I have tested serval mirrors in primarily North Europe). This is what I get: 4:cups-drivers error: unpacking of archive failed on file /usr/share/cups/model/Kyocera-PostScript/FS-1700.ppd.gz;3e31c364: cpio: MD5 sum mismatch 6:vlcerror: unpacking of archive failed on file /usr/lib/vlc/audio_output/libaout_file_plugin.so;3e31c364: cpio: MD5 sum mismatch [root@ken warly]# rpm -K /contrib/RPMS/vlc-0.5.0-0.20030128.1mdk.i586.rpm /contrib/RPMS/vlc-0.5.0-0.20030128.1mdk.i586.rpm: md5 OK [bgmilne@printserver bgmilne]$ rpm -K /var/ftp/pub/mandrake/contrib/RPMS/vlc-0.5.0-0.20030124.1mdk.i586.rpm /var/ftp/pub/mandrake/contrib/RPMS/vlc-0.5.0-0.20030124.1mdk.i586.rpm: MD5 NOT OK This is from ftp.sun.ac.za/mandrake/mandrake-devel/contrib/RPMS, which mirrors from ftp0.sunet.se [root@ken warly]# rpm -K /RPMS/cups-drivers-1.1-88mdk.i586.rpm /RPMS/cups-drivers-1.1-88mdk.i586.rpm: md5 gpg OK We still have -87mdk on our mirror. Buchan -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] sshd slapd bite each other
On Mon, 27 Jan 2003 15:08:20 -0800 (PST) David Walser [EMAIL PROTECTED] wrote: Strange, how does one reproduce the problem exactly? I have a user that's only in LDAP and I can ssh to them just fine. On my system, setting 'ssl on' or 'ssl start_tls' in /etc/ldap.conf causes ssh (or sshd) to segfault when run as a user who is only in ldap. With 'ssl off' it works just find.
RE: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossibleto use!
So, how about addressing some of this, by: a)If X keeps crashing, start X in vesa mode, starting up XFdrake or drakxconf or similar to try and fix the config I think that would help ALLOT of newbies! b)Allow a user to configure a mouse in this mode without a mouse Just to be able to move around in X without a mouse would be a plus. Keyboard shortcuts and strokes can be faster than reaching over and using a mouse. c)Have the failsafe boot option pass a parameter to the dm service which starts it like this by default. For a distribution aiming at converting existing windows users, you really need to make it *seem* bullet-proof. We all know it is, convincing point-and-clickers that it is means ensuring that if they wanted a GUI, they *always* get one, and can fix *anything* (besides fsck of course, which even windows can't do in a GUI) with GUI tools. I couldn't have said it better myself. Hil Let this be the year Linux takes a big-o-bite into the desktop! Ignore the stuff below. \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ Confidentiality Notice This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any unauthorized review, use, disclosure or distribution of this email message, including any attachment, is prohibited. If you are not the intended recipient, please advise the sender by reply email and destroy all copies of the original message. Thank you.
Re: [Cooker] After Upgrade - service dm doesn't start
On Tuesday 28 January 2003 15:05, Jason Komar wrote: On Tue, 2003-01-28 at 07:34, Robert Fox wrote: I have upgraded several machines with the latest Cooker install and after restart - it dumps me to a console. Apparently the service dm is not starting. When I start it manually - it works fine. It is also check to start at boot under DrakXservices. Thx, R.Fox If you are using the NVIDIA drivers you will need to recompile them. Robert, When I upgraded X yesterday, the upgrade changed my runlevel from 5 to 3. Check /etc/inittab to see if it did the same to you. Switch it to 5 and you should be good to go. -- John Allen, Email: mailto:[EMAIL PROTECTED]
Re: [Cooker] proftpd don't work
Varas Jim [EMAIL PROTECTED] writes: I have proftpd 1.2.7 Stable , it is not working, my file of configuration has been always the same. What may I to do ? It is not working has never be any kind of valid bug report. -- Warly
[Cooker] [Bug 1085] [Installation] Unable to Install due to partition table format error
https://qa.mandrakesoft.com/show_bug.cgi?id=1085 --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 15:44 --- I tried passing pci=noacpi but it didn't fix the problem. It meant my USB mouse stopped working at the license screen and it took longer to get to the errors. I also tried noapic but that didn't help. From Alt-F4 i did see some error messages hde dma_initr status = 0xff {busy} dma disabled ide2 reset timedout drive not ready for command David --- 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] description: I am using Cooker-9.1-i586 20030117 19:04 I have 2 60GB IDE drives connected to seperate channels on a Highpoint 372 Raid controller on an Abit KX7-333R motherboard. I am not using the Raid controller for Raid functionality but for performance. I have set aside 20gb to install Beta 2 on the 2nd disk. I have a dualboot with WinXP installed on Disk 1 and WinME on Disk 2. The installer detects the drives ok as far as i can tell however after accepting the license the installer complains that both drives have unknown partition table formats. the log shows : test_for_hard_drives (/dev/hde) error reading magic number on disk hde at /usr/bin/perl-install/partition_table/empty.pm line 28 error while reading partition table in sector 0 at /usr/bin/perl-install/partition_table/dos.pm line 63 it then goes on to fail reading sector 0 in bsd.pm, sun.pm mac.pm I have got Powerquest Bootmagic installed however i was suffering this fault before i installed it. The installer fails on both my drives which are seen has HDE HDG. I have tried adding a 3rd IDE disk as HDG which is unformatted and it doesn't complain about this. Partiomagic's Partition Info utility gives the following details about my partition tables PowerQuest PartitionInfo 8.0 -- Windows NT/2000 Version Date Generated: 01/26/03 17:34:46 Copyright (c)1994-2002, PowerQuest Corporation Permission is granted for this utility to be freely copied so long as it is not modified in any way. All other rights are reserved. PowerQuest, makers of PartitionMagic(r), Drive Image(tm), and DriveCopy(tm), can be reached at: Voice: 801-437-8900 Fax: 801-226-8941 Web site: http://www.powerquest.com/support/ E-mail: [EMAIL PROTECTED] General System Information: Total Physical Memory (bytes): 536,334,336 Used Physical Memory: (bytes): 339,365,888 Maximum Page File Size: (bytes): 1,311,584,256 Current Page File Size: (bytes): 375,005,184 === Disk Geometry Information for Disk 1:7297 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINXP 0 0 80 011 0C1023 254 63 63 81,931,437 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 80 011 0C 5099 254 6363 81931437 0 1 00 102301 0F1023 254 63 81,931,500 35,294,805 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 1 00 510001 0F 7296 254 63 81931500 35294805 81,931,500 0 00 102311 0B1023 254 63 81,931,563 35,294,742 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 81931500 0 00 510011 0B 7296 254 63 81931563 35294742 === Disk Geometry Information for Disk 2:7476 Cylinders, 255 Heads, 63 Sectors/Track System PartSect # Boot BCyl Head Sect FSECyl Head Sect StartSect NumSects === WINME 0 0 00 011 0C1023 254 63 63 39,809,007 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 0 00 011 0C 2477 254 6363 39809007 DOS STUFF 0 1 00 102301 0C1023 254 63 39,809,070 40,965,750 Info: Begin C,H,S values were large drive placeholders. Info: End C,H,S values were large drive placeholders. Actual values are: 0 1 00 247801 0C 5027 254 63 39809070 40965750
[Cooker] [Bug 1104] [Installation] No device nodes for cdrom drive
https://qa.mandrakesoft.com/show_bug.cgi?id=1104 --- Additional Comments From [EMAIL PROTECTED] 2003-01-28 16:31 --- no, scd0 nor any other scd files in /dev --- 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] description: Installed on a system with hard disk as hda and cdrom as hdb (slave on 1st ide channel). Installation went fine. However, after the install in the /dev folder there were no hdb files, nor any hdc or hdd files. The only files were for hda, hda1, hda2 and hda5 for the drive, the primary ext3 partition, the extended partition and the swap partition respectively. So after the install, I cannot mount the cdrom anymore. fstab has the correct entry however. SuperMount also does not work in this case. This system ram v9.0 fine, as well as Xandros.
Re: [Cooker] After Upgrade - service dm doesn't start
On Tue, 2003-01-28 at 15:28, John Allen wrote: On Tuesday 28 January 2003 15:05, Jason Komar wrote: On Tue, 2003-01-28 at 07:34, Robert Fox wrote: I have upgraded several machines with the latest Cooker install and after restart - it dumps me to a console. Apparently the service dm is not starting. When I start it manually - it works fine. It is also check to start at boot under DrakXservices. Thx, R.Fox If you are using the NVIDIA drivers you will need to recompile them. Nice guess, but if that were the case, then when I type service dm start it wouldn't start properly if the NVidia stuff wasn't working - but it does. I know better to recompile the NVidia stuff when the kernel is updated. Thanks anyway. It does look as thought the /etc/inittab is changed to init 3 as default somehow after the upgrade. Thanks, R.Fox -- Robert Fox [EMAIL PROTECTED] Fox Consulting Services
Re: [Cooker] proftpd don't work
Warly wrote: Varas Jim [EMAIL PROTECTED] writes: I have proftpd 1.2.7 Stable , it is not working, my file of configuration has been always the same. What may I to do ? It is not working has never be any kind of valid bug report. service proftpd start Avvio proftpd: - Fatal: unknown configuration directive 'ShowDotFiles' on line 70 of '/etc/proftpd.conf'. [FALLITO ] [root@vete vete]# always the same for me too regard francesco
Re: [Cooker] typo in DrakX (another)
in standalone.pm : show version name -- show version number ? show version name Combelles, Christophe (MED, ALTEN) wrote: Another one: in standalone.pm directry -- directory Combelles, Christophe (MED, ALTEN) wrote: in standalone.pm myfyle -- myfile
[Cooker] mimetypes in the menu
Hi everyone, my newest rox package has an updated menu-method. This creates context menu entries based on the 'mimetypes' field in the menu files. During my tests I found some packages that don't use commas to separate the mime types but semicolons. My menu method can deal with this, but shouldn't a rpmlint check dump an error if the format of the menu file is wrong? If semicolons are also OK, the mdk-rpm howto should be updated. CU -- Götz Waschk master of computer science University of Rostock http://wwwtec.informatik.uni-rostock.de/~waschk/waschk.asc for PGP key -- Logout Fascism! --
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
one uses the right tool in the right place. And how are people supposed to use it if it's not visible??? which tools are unusable when embedded in mc at 640x480? is there a possibility to add a few lines to mcc, when the user clicks to run those, to check for screen resolution, and if it's =640x480, run it in a separated window? At least the tool would be usable.. Better yet, when the user clicks on the tool, make a dialog pop up: --- At your current screen resolution, I cannot embed this tool, or it will not fit your screen. Do you want to run it in a separate window? O Don't ask me again ___ |Yes| |No| --- Just trying to be helpful... Damian
Re: USB disk drive problems - was Re: [Cooker] kernel panic debugging
Can't locate the original URL but here is the patch file anyway: Owen John Danielson, II wrote: Chmouel Boudjnah wrote: Owen Savill [EMAIL PROTECTED] writes: 3) There is a kernel patch for the SanDisk USB disk caddies but this does not appear to have been incorporated into the Mandrake kernel. look weird, i don't have such beast to test, but if you point me to it i will maybe integrated. Might be very useful to look at the code for that-- SanDisk can use memory cards as virtual disks. Some IBM Microdisks work on a similar theme driver-wise, as there are both PCMCIA and memory card reader adapters for same. Essentially, SanDisk has what they call\classify as a virtual drive adapter, but it is mostly an IC memory module reader for one of their module lines. Large IC cards with 256 MB and up were made for high-density digital cameras, and it was convenient to have readers that handled them as HDs for older PCs that were USB capable but not USB 2.0 capable. In the US, about 5 variants of this theme exist (IC card as virtual HD, reversing the SWAP idea for portability of data convenience). Take a pocket sized reader, floppy or CD with drivers, and high capacity card to any USB capable box, install drivers, run and carry decent sized chunks of data in tiny package about size of a CD Business card to any box that will take the data and has USB capable O/S. Some of these run at USB 2.0 rates. John. diff -u --recursive linux-2.4.18-pre3/drivers/usb/storage/transport.c linux/drivers/usb/storage/transport.c --- linux-2.4.18-pre3/drivers/usb/storage/transport.c Thu Jan 10 13:08:18 2002 +++ linux/drivers/usb/storage/transport.c Thu Jan 10 13:13:36 2002 @@ -1157,7 +1157,7 @@ le32_to_cpu(bcs.Signature), bcs.Tag, bcs.Residue, bcs.Status); if (bcs.Signature != cpu_to_le32(US_BULK_CS_SIGN) || - bcs.Tag != bcb.Tag || + ((bcs.Tag != bcb.Tag ) (!(us-flags US_FL_SL_IDE_BUG))) || bcs.Status US_BULK_STAT_PHASE || partial != 13) { US_DEBUGP(Bulk logical error\n); return USB_STOR_TRANSPORT_ERROR; diff -u --recursive linux-2.4.18-pre3/drivers/usb/storage/unusual_devs.h linux/drivers/usb/storage/unusual_devs.h --- linux-2.4.18-pre3/drivers/usb/storage/unusual_devs.hThu Jan 10 13:08:18 2002 +++ linux/drivers/usb/storage/unusual_devs.hThu Jan 10 13:13:36 2002 @@ -110,6 +110,28 @@ LS-120 Camera, US_SC_UFI, US_PR_CBI, NULL, 0), +/* Reported by Peter Wächtler [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04ce, 0x0002, 0x0074, 0x0074, + ScanLogic, + SL11R-IDE 0049SQFP-1.2 A002, + US_SC_SCSI, US_PR_BULK, NULL, + US_FL_FIX_INQUIRY ), + +/* Reported by Leif Sawyer [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04ce, 0x0002, 0x0240, 0x0240, + H45 ScanLogic, + SL11R-IDE 9951SQFP-1.2 K004, + US_SC_SCSI, US_PR_BULK, NULL, + US_FL_FIX_INQUIRY | US_FL_SL_IDE_BUG ), + +/* Reported by Rene Engelhard [EMAIL PROTECTED] and +Dylan Egan [EMAIL PROTECTED] */ +UNUSUAL_DEV( 0x04ce, 0x0002, 0x0260, 0x0260, + ScanLogic, + SL11R-IDE unknown HW rev, + US_SC_SCSI, US_PR_BULK, NULL, + US_FL_SL_IDE_BUG ), + /* Most of the following entries were developed with the help of * Shuttle/SCM directly. */ diff -u --recursive linux-2.4.18-pre3/drivers/usb/storage/usb.h linux/drivers/usb/storage/usb.h --- linux-2.4.18-pre3/drivers/usb/storage/usb.h Thu Nov 22 10:49:34 2001 +++ linux/drivers/usb/storage/usb.h Thu Jan 10 13:13:36 2002 @@ -101,6 +101,7 @@ #define US_FL_IGNORE_SER 0x0010 /* Ignore the serial number given */ #define US_FL_SCM_MULT_TARG 0x0020 /* supports multiple targets */ #define US_FL_FIX_INQUIRY 0x0040 /* INQUIRY response needs fixing */ +#define US_FL_SL_IDE_BUG 0x0100 /* ScanLogic usb-ide workaround */ #define USB_STOR_STRING_LEN 32
Re: [Cooker] Re: [Contrib-Rpm] chkrootkit-0.38-2mdk
Oden Eriksson [EMAIL PROTECTED] writes: måndagen den 27 januari 2003 22.54 skrev Todd Lyons: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vincent will correct me if I'm wrong, but there are only three keys that are used to officially sign packages in Main. Those three keys get installed automatically into root's keyring when the gnupg package is installed. If a developer happens to also package some Contrib rpm, the sig will be good. If a community contributor packages the Contrib rpm, then the end user who's installing it must go and manually retrieve (just once) the packager's public key. So I guess resigning my packages while the upload procedure is running with one of this 3 keys is out of the question then? At present contrib are not signed. One of the idea for future is to have different keys and allow the user to select which keys are valid for packages, for example: - Stable release - Contrib stable release - Development release - Security updates e.g. the user will have to explicitely select development key to be able to install cooker packages on a stable release. It is not likely that we have time to do this for 9.1. -- Warly
Re: [Cooker] kernel panic debugging
Pascal Cavy [EMAIL PROTECTED] writes: 6. reboot this time the boot stops (in harddrake ?) I absolutly cannot have a complete boot this time until I replugged the mouse and harddrake configures it. would you reproduce when removing completely hardrake ?
[Cooker] Re: XFS merge in mandrake kernel.
Russell Cattelan [EMAIL PROTECTED] writes: I you are concerned the I_NEW flag... only xfs uses that so everybody else should just ignore it, setting it shouldn't be a problem. look sane thanks, i have merged the latest xfs patch with our kernel and it look at first view pretty usable.
Re: [Cooker] proftpd don't work
francesco.melo [EMAIL PROTECTED] writes: Warly wrote: Varas Jim [EMAIL PROTECTED] writes: I have proftpd 1.2.7 Stable , it is not working, my file of configuration has been always the same. What may I to do ? It is not working has never be any kind of valid bug report. service proftpd start Avvio proftpd: - Fatal: unknown configuration directive 'ShowDotFiles' on line 70 of '/etc/proftpd.conf'. [FALLITO ] [root@vete vete]# always the same for me too [root@proca mnt]# grep ShowDotFiles /usr/share/doc/proftpd-1.2.7/NEWS - Removed the deprecated AllowChmod and ShowDotFiles configuration directives. -- Warly
[Cooker] urpmi - hdlist cannot be symlink
I was trying to upgrade a 9.0 installation. Given the limits of the hardware I tried to put the 9.1rc2 cds into one machine, nfs mount them on the upgraded machine, and use lndir to merge the directories. Adding the sources using the --distrib did not work. I had to copy the hdlist?.cz to the local filesystem. -- Michal Suchanek [EMAIL PROTECTED]
[Cooker] kdebase*, kdelibs* 3.1-1mdk
Current (daily) cooker install. After an update this mornin (15:20 GMT), which involved these kde updates, Konqueror web browser would not start. From a terminal, konqueror file manager would run normally, the web browser would not. The fm would also not function as a web browser. Never got as far as an error mesg in the term, just froze up. I --forced these kde rc6 rpms back in from my beta2 CD's and now konqueror is fine again. I put /kde*.mdk/ in skip.list. Hopefully that's the right syntax. -- Tom Brinkman Corpus Christi, Texas
Re: [Cooker] Re: [Contrib-Rpm] chkrootkit-0.38-2mdk
Warly wrote: Oden Eriksson [EMAIL PROTECTED] writes: At present contrib are not signed. One of the idea for future is to have different keys and allow the user to select which keys are valid for packages, for example: - Stable release - Contrib stable release - Development release - Security updates The hope was that it would be implemented per-urpmi-source, so that for example if I was maintaining a bunch of desktops with 3rd-party software, I could associate a company key with the company urpmi source, and packages would be updated automatically (if I run urpmi --update from cron). PLF would also gain from this? e.g. the user will have to explicitely select development key to be able to install cooker packages on a stable release. That's also a good thing, seen too many cdbakeoven-1.8.9-5mdk doesn't work on 9.0 when I have -4mdk in club for 9.0 and -5mdk in cooker contrib ... It is not likely that we have time to do this for 9.1. Pity. Buchan -- |--Another happy Mandrake Club member--| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Re: XFS merge in mandrake kernel.
On Tuesday 28 January 2003 08:19 am, Chmouel Boudjnah wrote: Russell Cattelan [EMAIL PROTECTED] writes: I you are concerned the I_NEW flag... only xfs uses that so everybody else should just ignore it, setting it shouldn't be a problem. look sane thanks, i have merged the latest xfs patch with our kernel and it look at first view pretty usable. This is great. So xfs should be in cooker soon? my main testing box uses xfs and well it's hard to install onto it with no xfs support. Or at least impossible without wiping the hard drives which isn't going to happen. -- -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~- Brook Humphrey Mobile PC Medic, 420 1st, Cheney, WA 99004, 509-235-9107 http://www.webmedic.net, [EMAIL PROTECTED], [EMAIL PROTECTED] Holiness unto the Lord -~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-~`'~-
Re: [Cooker] typo in DrakX (another)
Combelles, Christophe (MED, ALTEN) [EMAIL PROTECTED] writes: in standalone.pm : show version name -- show version number ? indeed in that place. thanks.
Re: [Cooker] Re: XFS merge in mandrake kernel.
Brook Humphrey [EMAIL PROTECTED] writes: This is great. So xfs should be in cooker soon? my main testing box uses xfs and well it's hard to install onto it with no xfs support. Or at least impossible without wiping the hard drives which isn't going to happen. yep it will very soon, just launching some bonnie++ to see if it handle the charge and will upload it.
[Cooker] typo in DrakX (other)
in harddrake/sound.pm ...your card use -- ...your card uses Thierry Vignaud wrote: Combelles, Christophe (MED, ALTEN) [EMAIL PROTECTED] writes: in standalone.pm : show version name -- show version number ? indeed in that place. thanks.
[Cooker] Quanta in KDE 3.1
Just a note to Laurent when you get around to updating Quanta for KDE 3.1, I wanted to make sure you didn't miss this note from one of the head Quanta developers on the Dot: http://news.kde.org/1043732923/1043736980/ (The gist of it is Quanta is now included as part of KDE, but they weren't quite done when 3.1 was tagged, and they'll have a patch for it tomorrow) __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Cooker] drakxservices doesn't run from controlcenter
On Tue, 2003-01-28 at 02:09, Thierry Vignaud wrote: Jason Komar [EMAIL PROTECTED] writes: I can confirm this one. i can *unconfirm* this one with french, english and italian locales. using drakconf-9.1-0.12mdk, i can run drakxservices both in embedded and in standalone modes Having now updated to that version of drakconf, it is working. Thanks Thierry. -- Jason Komar [EMAIL PROTECTED] Lubetec
Re: [Cooker] proftpd don't work
On Tue Jan 28, 2003 at 04:53:01PM +0100, francesco.melo wrote: I have proftpd 1.2.7 Stable , it is not working, my file of configuration has been always the same. What may I to do ? It is not working has never be any kind of valid bug report. service proftpd start Avvio proftpd: - Fatal: unknown configuration directive 'ShowDotFiles' on line 70 of '/etc/proftpd.conf'. [FALLITO ] [root@vete vete]# always the same for me too Just a guess, but maybe try commenting out or removing ShowDotFiles in your config? So you don't have to go hunting for it, it's on line 70 of /etc/proftpd.conf. -- MandrakeSoft Security; http://www.mandrakesecure.net/ lynx -source http://linsec.ca/vdanen.asc | gpg --import {FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD} msg88456/pgp0.pgp Description: PGP signature
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
--- Adam Williamson [EMAIL PROTECTED] wrote: Are you just wilfully ignoring the actual experience that's been posted to this list? For the fourth time, I use a laptop. It's perfectly powerful enough to run KDE or GNOME (I use GNOME). Because it's a cunning small laptop, it has a half-height screen, whose resolution is 1024x480. That's reasonable. The biggest obstacle to using Mandrake on this laptop is the fact the most Mandrake tools use large windows with no scrollbars. This is a fixable problem. Almost anything is a fixable problem. The right question to ask, especially when you're in a situation with limited resources is, is it worth fixing? Maybe at some point if time permits yes, but there are definatly more important things to do right now. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Cooker] [Bug 1048] [drakconf] Screen layout makes it impossible to use!
--- Reinout van Schouwen [EMAIL PROTECTED] wrote: Hello David, On Tue, 28 Jan 2003, David Walser wrote: Or redesigning them to be usable in 640x480. I'm not You're being totally unreasonable. If someone's got a I'm sorry that you find me acting unreasonable, I have no such intention. Whoops, I should be more clear. I don't find your behavior unreasonable, just your expecatations. monitor so crappy that they can't even run at 800x600, they use a different frontend to the draktools. At the risk of repeating myself, two points: 1. Being able to run at 800x600 doesn't necessarily mean someone actually uses that resolution. Is it so difficult to see that, as long as a user can switch resolution to 640x480 using mcc, he should be able to revert back using that same tool?! True enough. The fact is though that they can. They can use a different frontend. 2. Requiring different frontends makes things more complicated than needed, thus putting off users on the one hand, and generating support requests on the other. It's details like these why reviewers keep saying that Mandrake always has a little unfinished feel about it. No, having more frontends has more machines, more people's needs, and more people's tastes and configurations that we can't think of beforehand able to be supported. It gives things a more finished feeling. are covered by at least one frontend, so nobody can bitch about their machine not being supported. You are effectively saying that a user running at 640x480 should use a different frontend. Yes, just like someone with a P133 shouldn't run Gnome. Then why doesn't launching mcc in a low resolution automatically switch to framebuffer (DrakX) mode to enable the user to change his settings instead of forcing him to find out about the different frontends himself? Valid question, that would be neat actually (all it'd really have to do is launch a terminal and run the non-X version of the tool). Neatness doesn't always equal importance though. The way it works now, detecting if you're in X and launching the X version if so, otherwise not, is really easy to program. Adding this neat idea would take a lot more work, and probably isn't worth all of the effort right now. Are you gonna whine and complain to us when you find Gnome and Evolution unusable on a P133 with 16MB RAM??? I sure hope not. Doesn't mean No, but that's totally besides the point. We're discussing a *configuration tool* here, which almost by definition needs to support the lowest common denominator. And the point of the different frontends is so that we can support the lowest common denominator. It's also part of the benefit to having things like IceWM and mutt in the distro (the other being even people with fast machines like those). __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Cooker] After Upgrade - service dm doesn't start
Pixel wrote: Jason Komar [EMAIL PROTECTED] writes: On Tue, 2003-01-28 at 07:34, Robert Fox wrote: I have upgraded several machines with the latest Cooker install and after restart - it dumps me to a console. Apparently the service dm is not starting. When I start it manually - it works fine. It is also check to start at boot under DrakXservices. Thx, R.Fox Robert, When I upgraded X yesterday, the upgrade changed my runlevel from 5 to 3. Check /etc/inittab to see if it did the same to you. Switch it to 5 and you should be good to go. maybe you should enter it in bugzilla for package initscripts? I noticed this when I was merging .rpmnew files this morning. I wound up deleting the new version because I didn't notice anything other than that and a change in running some update script. Scott
Re: [Cooker] sshd slapd bite each other
--- Brian Smith [EMAIL PROTECTED] wrote: On Mon, 27 Jan 2003 15:08:20 -0800 (PST) David Walser [EMAIL PROTECTED] wrote: Strange, how does one reproduce the problem exactly? I have a user that's only in LDAP and I can ssh to them just fine. On my system, setting 'ssl on' or 'ssl start_tls' in /etc/ldap.conf causes ssh (or sshd) to segfault when run as a user who is only in ldap. With 'ssl off' it works just find. Ahh, I have ssl off. If DrakX becomes usable again and I can reinstall my Cooker box, I'll have to give it a shot with ssl on (I could try it on my 8.x box, but I don't know how useful a test case that is). __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [Cooker] A build for Athlon 64/Opteron
Okay, more precisely: not yet, but I am going to. The Alpha is a retired server. Do you plan on resurecting the alpha machine as another server or as a workstation? Workstation fits it better, I presume. The correct term would be playground ;-) I do much C/C++ stuff, so besides testing things out, I probably will use it to assure the stuff I write is 64-bit safe. I think that is do-able. Hm. Always presumed I find the time, is there anything I can do to contribute via this machine? Testing? Recompiling something? Whatever? That I don't know. I don't even know how you would bootstrap to begin the build... that's a little beyond my area of expertise. =) Well, it already has Linux (RedHat 5.2 based *grin*) on it, so I am confident to get it up-to-date some way. I don't think the installer that comes with the mdk alpha distro works at the moment. Haven't tried for a long time it to be totally honest. But if you take RedHat 6.2 you should be able to upgrade it (manually) to alpha cooker. Stefan smime.p7s Description: S/MIME Cryptographic Signature