Re: [Cooker] [Bug 2846] [mtools] Floppy formatter incompatible with supermount
On Tuesday 29 July 2003 11:00, François Pons wrote: tell Juan to include my supermount to make it possible :) Ah, does it means the current kernel doesn't support this functionnalities ? Well, I have been trying to harrass Juan about this for a few months now. It would probably fix all the supermount bugs in bugzilla in one sweep. Plus it gives us some nice features like this one. But for some of these features apps have to be adepted. So we really need it a considerable time before a freeze. Juan, please? Patch for latest kernel is already done for you... d.
Re: [Cooker] Contrib package: zero-inst
On Thursday 05 June 2003 11:32, Buchan Milne wrote: (What if you're using kernel-multimedia? kernel-multimedia-source should provide kernel-source. Danny? In 9.1 it provides alsa-source and kernel-multimedia-source. (BTW, I require kernel-source for the win4lin kernel packages I am working on, so if we're going to consider win4lin-multimedia kernel images you need to provide kernel-source so other users don't need to - --nodeps on build ...) But if you run kernel-multimedia, you will need to build against kernel-multimedia-source. If i just require kernel-source there is a risk it builds against wrong kernel? win4lin-multimedia should just require kernel-source-multimedia? Or alternatively i can let the source conflict with normal kernel. wdyt? d.
Re: [Cooker] Contrib package: zero-inst
On Thursday 05 June 2003 21:02, you wrote: Once again, win4lin-multi-media is a bit different, from say ltmodem, NVIDIA etc kernel modules, which should be able to build against any kernel-source. I see kernel-multimedia does not provide kernel, is there any reason why I should not be able to have only a multimedia kernel? no, you can only have the multimedia kernel. But if you build against kernel-multimedia-source the modules will ofcourse not work on a normal kernel. d.
Re: [Cooker] Contrib package: zero-inst
On Friday 06 June 2003 12:23, you wrote: Unless kernel-multimedia provides kernel, which AFAIK it doesn't. My logic was that if kernel-multimedia provides kernel, then kernel-multimedia-source should provide kernel-source ... it does provides kernel But at present, one has to --nodeps to build say an NVIDIA kernel-module RPM if the SRPM BuildRequires: kernel-source ... hmm..well..it might be sensible to provide kernel-source. will do on next update. but I am a little bit afraid that people start building modules against the the normal kernel source instead of the mm kernel source. d.
Re: [Cooker] Contrib package: zero-inst
On Friday 06 June 2003 13:24, Buchan Milne wrote: You sure? no :) $ rpm -qp --provides /var/ftp/pub/mandrake/9.1/contrib/RPMS/kernel-multimedia-2.4.21.0.16mdk-1-1 mdk.i586.rpm kernel-multimedia = 2.4.21 alsa module-info kernel-multimedia-2.4.21.0.16mdk = 1-1mdk well, seems i was wrong. Stupid me. will fix as well. d.
Re: [Cooker] Re: Cooker HowTo
On Friday 30 May 2003 00:24, Steffen Barszus wrote: Do you have any pointers how to do this ? I would love to lay this on my alt-ctrl-- or similar. If it can be done on commandline it can be done in a script right ;)? shouldn't have to tell you this? man xrandr? bye d.
Re: [Cooker] Re: Cooker HowTo
On Wednesday 28 May 2003 14:28, Steffen Barszus wrote: *** RandR *** What I have not found yet is a RandR applet for KDE. Has someone experience here yet. How functional is RandR support yet ? This would be a nice thing to have. You can try it from the commandline. Still has a few bugs however. But agreed, the kde applet would be nice. d.
Re: [Cooker] ramdisk
hmm.. did you already got an answer? whats wrong with: mke2fs -i 1024 /dev/ram0 4096 mount -n -t ext2 -o defaults, nocheck /dev/ram0 /mnt/ram ? you might want to think abit about decent checks on the size, the amount of memory available and whether there already is a ramdisk, etc Ofcourse, is it really a good idea to let an rpm do this? Why not the startup script of the program? Also, I think that any app that needs tmp space to be on a ramdisk should consider not using tmp files at all for that data (ie: its a bug). d. On Thursday 22 May 2003 19:08, Austin wrote: No answer yesterday, let me reword this... Does anyone know an easy way to create and mount a ramdisk filesystem in a %pre/%post macro? Austin
Re: [Cooker] Re: Re: Re: [CHRPM] mplayer-0.90-0.rc5.2mdk
I agree with David, default fullscreen sucks. It is not usefull at all. d. On Friday 04 April 2003 08:43, David Walser wrote: Götz Waschk wrote: Am Mittwoch, 2. April 2003, 20:07:19 Uhr MET, schrieb David Walser: framedrop by default is maybe OK, but fullscreen by default is really bad. You specify a different dimension (-xy 2 for instance) and it ignores it. This is really bad. It wouldn't be so bad if it didn't do that. I've heard from people that this badly affects mplayer GUI mode too. No problems here. If I use mplayer -xy 2 video.mpg and switch from fullscreen to windowed mode with f, I get the desired Exactly. Why, when you asked for -xy 2, should it give you fullscreen and make you switch out of it? effect of a window with double x and y dimensions. The same happens if I use mplayer -nofs -xy 2 video.mpg. Maybe you don't have xv or it's a bug. For me the default configuration is working fine. Mine's working the same as yours. I disagree that it's fine. Ultimately it's your package, and you can do whatever you want. As an mplayer user, I'm just trying to say that the current behavior makes absolutely no sense, and just wastes time.
Re: [Cooker] kernel
On Friday 04 April 2003 01:09, Guillaume Cottenceau wrote: Danny Tholen [EMAIL PROTECTED] writes: - on some videocards/mobo's there is a panic when using framebuffer if you have above 1GB memory. Booting vga=normal tends to work well for these people. known at least since #3198 :(. I think this will be a problem in 9.1, but I don't know what to do. we couldn't reproduce here, to add more problems :(. Yes its a strange problem. There is a thread on club about it. Some people have it, some people do not. Perhaps it is related to some bios option. In anycase, the workaround should go into the errata? d.
Re: [Cooker] Re: Fatal crash of X server with i810
On Thursday 03 April 2003 23:19, Gary Lawrence Murphy wrote: G == Gary Lawrence Murphy [EMAIL PROTECTED] writes: G .. in all 4 cases, I found the following in the syslog just 9 G seconds before the crash G kernel: [drm:i810_wait_ring] *ERROR* space: 65520 wanted 65528 well, the error seems to come from the i810 drm module. What if you disable dri? What if you disable drm? d.
Re: [Cooker] mplayer: several small probs
On Friday 04 April 2003 14:50, Giuseppe Ghibò wrote: rcc wrote: current cooker but applies to 9.1 too mplayer always plays web URLs twice. Happens both in standalone (via konq) and embedded (galeon) mode. Moz plugin also has the odd habit of scaling up to browser page size (fs=no) which looks terrible and is extremely slow on X11. Lastly, the wmv format opens in kwrite when the x11 is needed because otherwise xv dont support multiple mplayer instance, and furthermore many chipset don't support xv extensions at all. what about sdl? It seems better that x11? d.
Re: [Cooker] Emulators menu stuff esp VICE and XWine
On Friday 04 April 2003 20:01, rcc wrote: About XWine, even though people might see XWine as only a configuration frontend for wine, I think it is a proper app in its own right and should be moved out of Configuration/Other into Applications/Emulators. Since I packaged it I am responsible for putting it there. But if nobody objects I will move it to apps/emu... d.
Re: [Cooker] Re: [XFree86] Fatal crash of X server with i810
On Thursday 03 April 2003 07:33, Gary Lawrence Murphy wrote: G == Gary Lawrence Murphy [EMAIL PROTECTED] writes: G .. in all 4 cases, I found the following in the syslog just G 9 seconds before the crash G kernel: [drm:i810_wait_ring] *ERROR* space: 65520 wanted 65528 Google seems to think this has something to do with VideoRam settings, and sure enough, my XF86Config-4 has no such setting, and that means the default which is a paultry 8MB. I've upped it to 32MB and if you don't hear back from me on this, it probably means it worked. Which means it is XFdrakes fault. It should try to detect/set the memory size. If it is not detectable, it should ask for this on your card d.
[Cooker] kernel
Just to summerize some intteresting 9.1 kernel problems. I strongly encourage the kernel team to give comments ;) Perhaps an update will come or some errata? - No ACL support - on some videocards/mobo's there is a panic when using framebuffer if you have above 1GB memory. Booting vga=normal tends to work well for these people. - the APIC problem routing IRQs to 1 CPU only (although haven't heard about this one lately) - various people reporting a stopping boot on depmod stage for some reason (also with default kernel, not only with kernel-mm as Götz reported in the past). (detail: seems to be scsi related, one person only had scsi devices, one had a camara plugged in when it failed, the camera was mounted as scsi device) Some other things: - should we make a list of working/non-working ACPI machines for 9.2? - Any comments on Andrey's (supermount) patches? d.
Re: [Cooker] [Bug 3606] [kernel-source] New: kernel has too many patches, should be closer to standard kernel
On Monday 31 March 2003 14:38, Bruno Prior wrote: I think Simon has a point. There are plenty of occasions (e.g. IDE problems in the past) when the recommended solution is to get hold of a vanilla kernel, that's why there is kernel-linus? If there were a clear path that showed which patches the Mandrake guys had applied, in what order, then it might be possible to construct a all you need to do is look at in the src.rpm. d.
Re: [Cooker] [Bug 3615] [xfsprogs] no acls in XFS
On Monday 31 March 2003 20:13, Buchan Milne wrote: Ha, and why didn't anybody notice this before?! Also, you can't mount ext3 with the acl option, so I guess acls are toasted on ext3 too. Not really toasted, just not enabled. Patches are applied, but ACL is missing from the 2.4.21-pre4q13/configs/ files. I do see some GRKERNSEC acl stuff though. Perhaps it was omitted on purpose? d.
Re: [Cooker] [Bug 3615] [xfsprogs] no acls in XFS
On Monday 31 March 2003 20:26, Danny Tholen wrote: Not really toasted, just not enabled. Patches are applied, but ACL is missing from the 2.4.21-pre4q13/configs/ files. oops, mea culpa, the addition CONFIG_FS_POSIX_ACL itself is not in any patch anymore it seems. d.
Re: [Cooker] wish list for 9.2
On Sunday 30 March 2003 12:02, Per Øyvind Karlsen wrote: dosemu? Requires proprietary C compiler to build. huh? no, that's incorrect, but it just won't compile under mandrake ATM, and the project does'nt really seem to be that active, no stable release since 2001... no it is only sligtly incorrect: dosemu builds with gcc. But the dos kernel and dos commands (the exe files) of freedos require a 16bit compiler. There is no GPL 16bit compiler that is currectly capable of compiling these commands. I did make a version for of dosemu 1.1.4 for club, but have not put it up yet because it needs a major cleaning and some config tweaks (and I have really forgotten how to use dos anyway). d. Also, DosBox promises to be a little less savage on the CPU useage. Cheers; Leon
Re: [Cooker] [RFC][PATCH] New supermount
And at least to up to 1.1.3 I have tested it (sorry Andrey that I did not yet got back to you, was a bit busy) on a number of different hardware, and have to say it works much better and stabler than 9.1 supermount :) I have not yet found a way to break it. Although I recall that Jan Ciger reported his 750 MB zip reverted to only reporting 100 MB suddenly (this was with version 1.1.1 IIRC). But he did not reply when I asked for more info. d.
Re: [Cooker] [RFC][PATCH] New supermount
On Sunday 30 March 2003 19:49, Andrey Borzenkov wrote: - fs=.. option now takes list of filesystem types like fs=ext2:vfat. Using auto gave large delay sometimes (specifically for floppy). Pixel, if you're reading this, and the patch gets applied, it would be good to make it default for floppies in diskdrake, it really speeds it up (checking for udf takes to long). Also, when device is locked neither manual (eject button) nor program (eject /dev/cdrom) eject are possible. It does not work well for sd unfortunately. what exactly does not work? - new option no_tray_lock. It is intended for ro media to overcome problems with such programs like Konqueror that constantly poll directory for changes thus blocking any eject possibility. This would be a nice default for ro devices. (It is possible to lock device only on rw operations. Suggestions are welcome). why not? subfs (rw) reading it gives status of subfs; writing it allows you to unmount and/or disable subfs preventing any attempt to mount it. Intended usage is - mkfs/fsck/CD burning when you need to make sure nothing disrupts operation this would be great. As far as I understand this will finally make it easy to format a floppy or burn a disk while using supermount. Here is the current TODO: I would like to add something more ambitious. So shoot me down if you think that this proposal is _not_ what supermount should be doing. I'd like to see a transparent way of access to audio cds (and vcd and the like). There is something already doing this called cdfs IIRC, haven't looked at it for some time. But currently GUI apps try to do this kinda thing by implementing things like audiocd:// io_slaves and the like. A very silly solution, why doesn't the kernel handle this? As I said, perhaps it is better to improve cdfs and let supermount use this as subfs (if possible). d.
Re: [Cooker] wish list for 9.2
On Saturday 29 March 2003 12:57, Leon Brooks wrote: * Falling-off-a-log-easy WINE, with useful help on getting Windows apps to work under WINE (even if this is a link to an internet site, good general help for getting things working should be available, both in the form of a newbie recipe set and a more terse and technical FAQ-type document tree). What about Xwine (is now in contribs)?, guess I could add a link to some docs in that program. d.
Re: [Cooker] mmx and such
On Friday 21 March 2003 18:26, Oden Eriksson wrote: If this bug hasn't been fixed yet, Pentium compatiblity doesn't seem to be that important for Mandrake :-) Exactly. And my point is that Mandrake cannot state i586 compability. runs fine here on a k6-2, which is definately not i686 d.
Re: [Cooker] kernel-source and kernel-source-includes
On Tuesday 18 March 2003 17:52, Austin wrote: Also, a win4lin/multimedia kernel would be impossible (I tried it, with much hand-editing). They both try to patch the scheduler, and I couldn't find any way to get the two patches to apply against each other. can I have a look at this win4lin patch? Where can I find it? d.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Monday 17 March 2003 08:56, Götz Waschk wrote: Am Sonntag, 16. März 2003, 19:11:15 Uhr MET, schrieb Danny Tholen: On Sunday 16 March 2003 18:59, Götz Waschk wrote: what if you turn off depmod at boot and run it manually + verbose later? normal/smp, any special drivers? Hmm, after booting with nomodules I could run depmod -a without problems. weird so it is fixed now? d.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Friday 14 March 2003 15:38, Adam Williamson wrote: * Thu Mar 13 2003 Danny Tholen [EMAIL PROTECTED] 2.4.21.0.16mdk - supermount 1.1.1 (a great job, by Andrey Borzenkov) - small snd-emu10k1 patch - dmi_scan fixes (Thomas Backlund) - custom config should now have patches enabled I don't like this at all. Read the description. Bad luck for you. This kernel was supposed to be simply the Mandrake kernel, with specific patches - pre-empt and lowlatency - for multimedia use. By whom it was supposed so? Instead it seems to have become the Danny Tholen Let's Include Any Patches That Look Fun kernel. The patches are not what I think is fun. They: a) fix a bloody oops with snd-emu10k1, tested and verified, and will probably also in the final kernel for main (if we get an alsa update). b) supermount in main sucks more than the one i included. But main kernel should be QAed, this kernel not. I expect these patches to go in main after release. Furthermore, this patch solves some minor problem between supermount and preemption. c) various people have been saying that Thomas patch fixed the acpi problems they had. Possibly Juan will/has already included it in 14mdk for main. It just disables ACPI on a few more mobos. I will not include just random unrelated patches that will not go in main, I will just try to keep up with main. Do you actually know what you are talking about? I don't think this is a good idea, even in contribs. IMO, it should just stick to being the stock Mandrake kernel with those specific audio-application-helping patches in it. If you do not like it, you can always build your own kernel. I'm sure it will suck more than mine. Danny
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Sunday 16 March 2003 18:59, Götz Waschk wrote: what if you turn off depmod at boot and run it manually + verbose later? normal/smp, any special drivers? d.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Sunday 16 March 2003 19:14, Andi Payn wrote: On Sunday 16 March 2003 09:51, Adam Williamson wrote: It's just that the kernel is an important package, and I think it gets a bit confusing if there's one that's getting quite a bit away from the other five versions...sure it's in contribs, but kernel is so important maybe it needs stricter control than most contribs packages... No i do not want it to move away from the official kernel. Only I had to anticipate what patches Juan would add to final kernel, because I contribs was being finished up. By the way, one minor problem with the -mm kernel (at least as of the 2.4.21-0.14mdk release): If you build a custom kernel starting from kernel-multimedia-source, the label it tries to install in lilo is too long, and you get a lilo error; you have to go in and edit lilo.conf manually. Since I always rename and reorder all my kernels anyway, I'm not complaining--and I doubt anyone who builds and installs custom kernels, especially starting from anything but the standard kernel source, is likely to have a problem editing lilo.conf. yes this is annoying. Lilo labels are limited to 10 chars IIRC. I have not found a nice solution yet :( I am also a bit dependent on the installkernel script d.
Re: [Cooker] Re: [Contrib-Rpm] kernel-multimedia-2.4.21.0.16mdk-1-1mdk
On Sunday 16 March 2003 19:31, Adam Williamson wrote: Ah, in that case, apologies - I thought you were adding stuff that wasn't going to be in main kernel. If it's all stuff that's going to end up in main anyway then I don't see a problem, cool =) And my apologies for my , as usual, agitated replies. I think, sometimes, main kernel goes a bit to slow (especially before release), which is understandable because of QA testing. Contribs afaik does not have QA, so I may include some fixes more early, for everyone to test. If I will really add a feature, I will discuss on list first. d.
Re: [Cooker] [Bug 3245] [Hardware] New: No sound since 8.2
On Thursday 13 March 2003 20:07, Jason wrote: but that doesn't work anymore either, (though it used to). When I run sndconfig and choose my card and run the probe and it says: An error occurred opening /dev/audio if I try the SB16 test which used to work for the same card it says the same. I need a solution too as I am tired of having no sound in Mandrake. so...does /dev/audio exist, and do you have access rights? d.
Re: [Cooker] [Bug 3284] [drakxtools] New: add windows fonts fails -perms wrong on ttf2pt1
On Thursday 13 March 2003 22:17, Thierry Vignaud wrote: sh: line 1: /usr/sbin/ttf2pt1: Permission denied. An ls -l for the file shows permissions of -rw-r--r--. @resolution=fixed fixed in -10mdk haha, some bugs are really annoying. Third try should work:) cheers, d.
Re: [Cooker] [NEW] freetype2 library + OpenOffice.org
On Wednesday 12 March 2003 10:07, Gwenole Beauchesne wrote: 1) Should we let in new freetype2 which fixes crashes with 3rd-party fonts, i.e. not provided by MDK? well, IMO fixing crashes is more important than (a few) badly readable fonts. So by all means, try to get it in. d.
Re: [Cooker] New Testkernel for SMP...
On Wednesday 12 March 2003 11:30, Thomas Backlund wrote: Could someone verify this,... is the IRQ routing problem only P4 / Xeon specific... or does it happend on dual P3 too... if it does fix the problems, can you send a patch to me? I'll try to get it in kernel-multimedia. If it is to late for that I will put an update at mdk-club. d.
Re: [Cooker] 9.1RC1 - acrobat plugins + Galeon
On Wednesday 12 March 2003 18:36, Buchan Milne wrote: When one of them has a working find function (try the ~1600-page wxWindows manual for example). kghostview does not seem to handle landscape well (xpdf does it ok). True, I find the free pdf view tools useless, because they do not have a find function. d.
Re: [Cooker] Bug fixed, how to get it upstream ? (634,3142)
mail patch to maintainer? d. On Wednesday 12 March 2003 15:38, Steffen Barszus wrote: Hi! I fixed a bug in isdn4net. isdn4net is a package of shellscript and actually 29k big. Is there any way to get this in ? I have even the source-rpm ready to send it to somebody to get it in. It solves actually bug 634 and bug 3142.
Re: [Cooker] font tools/conversion
On Monday 10 March 2003 21:38, Austin wrote: When I run drakfont, I get the error many times: sh: line 1: /usr/sbin/ttf2pt1: No such file or directory eh..Austin, you did not study the list well enough:-P I reported this a long while back, and Thierry promised to fix, but misunderstood me and added a second dependency to drakxtools for font tools. Today I send him an email again but he did not yet reply. Someone with access to main, please fix this, it seems trivial. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Monday 10 March 2003 21:33, George Mitchell wrote: I have nothing against proprietary software in general or soundfonts in particular. I only find it odd that cards that provide /dev/sequencer support under free software should see that support discontinued when the source is freely available. So now the question becomes 'Does anybody out there have /dev/sequencer support without having to use soundfonts?' You have it backwards. AFAIK: On the sblive, you *have* to use soundfonts. It cannot synthesise notes itself. AFAIK it is a hardware limitation. On other cards, it might be different.
Re: [Cooker] Re: drakxtools dependencies/font-tools
Thierry, you forgot!!! ;-P Danny On Thursday 27 February 2003 10:02, Thierry Vignaud wrote: Danny Tholen [EMAIL PROTECTED] writes: drakfont depends on ttf2pt1, which should be in font-tools. It is not, only the man page is. Thierry, my rpmmon says font-tools has no maintainer, which is why I bug you with it:) ok. will be in 8mdk
Re: [Cooker] Re: [Contrib-Rpm] ati.2-4.3.20030307-1mdk
On Saturday 08 March 2003 23:12, Spencer Anderson wrote: It is almost impossible to keep that straightened. There are four drivers that ati.2 replace and XFree86 will overwrite them everytime. The only thing I can think of when we are in beta or RC stage like now, is to add ati.2 to urpmi skiplist and them update them separately. At any rate, ati.2 won't be updated again until after 9.1 final but if Frederic updates XFree86 again, you'll have to reinstall ati.2. Ok, not really have followed this thread but: Perhaps with some dirty rpm hackery you can solve this: use a trigger script that will copy the correct driver to the correct place again upon xfree install/update? d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 20:32, Adam Williamson wrote: Sorry, but this characterisation is wrong. There's some trivial bugs currently; there's also some that ought to delay the distribution on their own. See the bug which means anyone who has a PPP connection and tries to activate Mandrake's own firewall will lose their internet connection with no explanation...which has been marked as WONTFIX. This is NOT a spelling mistake or wrong titlebar colour. very true. But I think I also learned in the past that it is useless to keep trying to convince mdk of this. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Friday 07 March 2003 12:37, Guillaume Cottenceau wrote: Danny Tholen [EMAIL PROTECTED] writes: Maybe more overworked than I am? People may also have different views on how cooperation must happen with external contributors.. Or maybe they use ineffective mail client programs? :) yes ofcourse, I hope it was clear it was *not* an attack on these people. I was merely stating that I think it is counterproductive. And I tried to come up with a possible solution. Well, the initiative shows your support for Mandrake. But I think it would be uneffective. First, here at Mandrake we are paid for what we're doing, so it enforces a behaviour and assume some tasks that are sometimes not immediately pleasant (again, that's only my point of view). Ok, so you are basically saying that everybody should be responsive. Well, perhaps restate that policy next meeting:) Also note that this statement does not say anything about the proposed remedy. Second, I think time from external contributors is precious (especially concerns the talented external contributor), and it's better spent doing real tests/patches/suggestions/etc (not counting the fact that what you describe demands much motivation). true enough. But, perhaps some people will be more suitable for replying to emails than for writing patches. Certainly considering the volume of this list. Third, we can't rely on external contributors as much as employees, for the simple fact that people are free to stop contributing, anytime. Yes ofcourse. But debian is still a distro. I'd like to thank you again for this proposal, which shows how much you want Mandrake to be a good distro. thanks ;-) But, what I would have liked more is that you provided an alternative solution. Because you do not dispute that a (small) problem exists. And there is some truth in your critic, however, without alternative solution, why not try it. Than again, perhaps you will do something internally, and do not want it on the list. That is also ok. ok..i think i'm ranting- go to sleep now. d.
Re: [Cooker] kernel-multimedia 13mdk
On Friday 07 March 2003 18:21, Jan Ciger wrote: I originally thought that my bash is acting up, because on 'ls' I have got tar: *.spec: Not found in archive :-))) well, I am looking at 14mdk now, but there is really no such file in the rpm... d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Thursday 06 March 2003 14:45, Guillaume Cottenceau wrote: Let it clear: we all want the most bug-free release possible. Generally, I agree with all your points. What you say is as far as I can just mostly right. And people on this list will probably always complains about certain desission. However, there is one thing that I sometimes see and which annoys me a bit. Some mandrakesoft people have a habit of not, or only rarely reply on emails, even when there are patches for the problem in it. Some people (like yourself) are very cooperative. This shows. There are components of the distro which are buggy only (IMO) because of this fact. I perfectly understand that reading/answering a 1000 mails a day is not something you generally like doing. Certainly not when you are already stressed with trying to fix your packages bugs. Not everybody can handle that. That's fine. But, I would like to propose. For the people that hate reading all their mail/answering it. Appoint some volunteer from this list to be the interface between the packager and the users. If someone sends a patch to fix, lets say, ugly colors in frozen bubble, and sends a fix to this list. I can than pick it up, and forward it to Guillaume. And he will perhaps reply to me, saying: ok, or simply :no way. And I than can try to explain it again to the reporter. It sounds a bit cumbersome I agree, but it is better than waiting in vain to see your patch being lost. I could have given at least 2 examples in this mail. I did not because I think it is perfectly understandable that the maintainer did not fix the issues (either because he did not read his mail, or that he planned to fix it with an update later in the process). However, it is frustrating, and it might cause people not to send patches anymore next time. d.
Re: [Cooker] still alsa sound and KDEInit problems
On Thursday 06 March 2003 20:44, Serge Plüss wrote: Hi Still with the latest cooker sound on SB Live is awfully choppy. I had read that some of the latest alsa is supposed to fix this but as of kernel-2.4.21.0.12mdk-1-1mdk it is still reporting using alsa 0.9.0RC6 Juan knows. I cannot help it, I did send a patch. Fix did go in kernel-multimedia. Thierry, will you kick the kernel team again? Or just ask them to ensure some people that a fix will come. Not commenting on it will just fill my mailbox with duplicate messages (yes I am in a foul mood today). o..Serge, for FYI: the libs number is rc6, rc7 is the driver release. d.
Re: [Cooker] kernel-multimedia 13mdk
oopssounds like I screwed up. will check if the patch went in... ...patch went in. checking if it was enabled... ooops CONFIG_CAP_SETPCAP is not set. waaa..it is even worse, also preempt and lowlat seem disabled. (so much for doing things in a hurry). will rebuild asap (possibly with juans 12mdk) d. On Thursday 06 March 2003 19:00, Austin wrote: On 2003.03.06 12:20 Elliott Martin wrote: I'm getting the same thing with 13mdk... $ jackstart jackstart: cannot get realtime capabilities, current capabilities are: =ep cap_setpcap-ep probably running under a kernel with capabilities disabled, a suitable kernel would have printed something like =eip I tired my previous jackit-realtime, and I get the same error, so it must be a kernel problem. Two nights ago I guess I was still using -12mdk. Danny... any ideas? Austin
Re: [Cooker] Re: RC2, first impression
On Wednesday 05 March 2003 07:32, Oden Eriksson wrote: As far as the problem being XFree drivers, I find that strange...I wouldn't expect driver display bugs to show up in a screenshot that goes through software and shows what what the system is really trying to display... Yes it's really strange, maybe I find time tonight and reinstall Cooker to try again. It seems to me that only the fonts are screwed up. This would also explain it showing up on a screenshot. So my guess it is in the XRENDER acceleration of the nv driver. Perhaps you can turn of XRENDER acceleration. This will make font rendering slower, but perhaps useful again. I do not know whether turning this off is available for all drivers, but I'm sure you can find it in the xfree docs. d.
Re: [Cooker] Mandrake 9.1 Should be Delayed
On Wednesday 05 March 2003 22:07, Timothy R. Butler wrote: For instance, since he has an integrated AC97 sound card, Mandrake won't let his SB Live! work properly that has worked in every other GNU/Linux distro he has tried (including 8.2). what exactly are you referring to here? Or could you give me a bug number? danny
Re: [Cooker] (Cooker] kernel-multimedia problem building vmware modules
yeah I know. Try with 13mdk. It should work now. Danny On Tuesday 04 March 2003 11:32, Torstein Hernes Dybdahl wrote: The kernel-multimedia-preempt source kode says it is smp but the kernel is built for uniprocessor. This makes vmware to refuse to build new kernel modules. Vennlig Hilsen Torstein Hernes Dybdahl --- Haldensgate 21 7014 Trondheim NORWAY Stud. Tech. ved Elektroteknikk og Telekommunikasjon, NTNU ---
Re: [Cooker] Upload frozen
On Tuesday 04 March 2003 16:01, Eric Fernandez wrote: Maybe, but there is a problem with emu10k1 Sound Blaster cards and mplayer. I would be sad if any reviewer reported that problem after the final release... Actually I don't know if that problem is because of some compilation options rather than the alsa version. I hope it can be fixed before final. well I think I fixed the problem is fixed the kernel-multimedia. Juan knows about it, I think he will update the main kernel as well. d.
[Cooker] kernel-multimedia 13mdk
If all goes well, this should be on mirrors soon. - It will fix module building - drakfont+ntfs hangs (untested) - low snd-emu10k1 pcm stream size causing sound artifacts I did not include highmem for smp (sorry): if you have a workstation with more than 900 MB, you can build it from kernel-multimedia-source;) Bugs, critisism and latency timings welcome. d.
Re: [Cooker] Re: [CHRPM] mozilla-1.3-0.final.20030228.1mdk
On Monday 03 March 2003 10:37, Frederic Crozat wrote: Mozilla package is already taking care of a lot of plugin package (look at the triggers...) yes, but not correctly for at least java. Anyway, I'll probably move the non-versioned directory naming but AFTER 9.1 is out.. hmm, ok:( So I will make a trigger again on instal of mozilla to fix it. d.
Re: [Cooker] kernel-multimedia
On Monday 03 March 2003 12:23, Charles A Edwards wrote: kernel-multimedia-preempt-2.4.21.0.12mdk-1-1mdk Why is this 0.12mdk rather than 0.11mdk as is current kernel? With it set as 0.12mdk, unless it is added to skip list, --auto-select requires that a kernel-multimedia be installed. Charles I wondered whether this would be a problem. But sometimes i do need to fix bugs, so I need to increase the version number? Unless I complex the versioning even more by going 2.4.21.0.0.12mdk. I was planning to upload a 13mdk soon, but I'll wait. What would be the proper solution? d.
Re: [Cooker] kernel-multimedia
On Monday 03 March 2003 14:23, Marcel Pol wrote: If it's based on kernel-blah-0.11mdk, call yours kernel-blah-multimedia-preempt-0.11mdk, that should be clear enough, right? yes it is clear. But not possible. I need to be able to make several updates per 'juan-version' 11. So I need a way to increase the version number. For instance, in this 12mdk there is a problem when you want to compile 3rd party modules (like nvidia). This is a bit better in (unreleased) 13mdk. But apparently I should name it differently. I just do not know how. d.
Re: [Cooker] kernel-multimedia
On Monday 03 March 2003 15:21, Charles A Edwards wrote: Would it not work as kernel-2.4.21.0.11mdk-multimedia-prempt-1-#mdk if we do that, it is not possible to keep old kernel when installing new one. (ie 2mdk will replace 1mdk). That was the whole point of this silly 1-1mdk naming scheme. But then, for an extra kernel, this might be not so important? d.
Re: [Cooker] Xfree 4.3 and RandR
On Monday 03 March 2003 13:39, andre wrote: name one? tsk... Loki's Kohan runs only in 1024x768, but I hate using my desktop in that resolution (low refresh, small fonts). Switching during session would be nice. And certainly easier compared to starting a new xserver. Also, since many programmers do not believe 800x600 does make sense for some monitors, I can at least switch to a higher res as a work around. Hopefully, changing on the fly will also make it easier for these programmers to actually test on lower resolutions. Also this feature will hopefully induce some nice KDE/GNOME/whatever gui apps for setting the resolution/refresh you want by clicking on the desktop. Instead of searching through XFdrake. Also, it makes sense for some apps which want to resize the view screen (movieplayers, some games) previously you could use SDL to do this more or less. Now perhaps I can look to a movie in my rootwin, which is scaled appropiate, and still can use my panel. Probably could cook up some more. Point is: it is not neccesary, but it does make life easier. anyway, I am happy with the commandline tool already. Just it seems that the KDE panel is not randr aware. Well...There are more important things for Laurent to fix (like konq insisting on hanging up your system for 10 secs when you browse into /mnt and use supermount). d.
Re: [Cooker] Upload frozen
I think that was the sblive problem? I send a patch to the list a while ago, it is a one liner. Just bug juan with it. d. On Monday 03 March 2003 18:31, Adam Williamson wrote: On Mon, 2003-03-03 at 16:24, Thierry Vignaud wrote: Adam Williamson [EMAIL PROTECTED] writes: Are we going to get a new kernel before final? The current one seems to have serious problems with ALSA, as I mentioned (and others confirmed) in a previous thread. Someone said they fixed it by updating to the latest RC7 release of ALSA. Someone please confirm this will be fixed. why do you mean by latest rc7 ? rc8 ? That's what the message said =). I presume they just downloaded all the stuff that was current on the site when the message was sent. Let me find it: I have found a solution to that problem : updating alsa to the latest RC7 release. The sound then works perfectly with mplayer after recompiling alsaRC7 myself, using the source of the latest kernel (2.4.21.0.11mdk). It recompiled without any problem. (comment on Bugzilla bug 2432, which isn't exactly my problem, but is clearly another problem with the ALSA in the current kernel).
Re: [Cooker] Upload frozen
On Monday 03 March 2003 19:18, Eric Fernandez wrote: It is probably an issue with the way emu10k1 drivers are loaded/managed by the kernel, don't know more. a bit vague? I posted a fix here: http://marc.theaimsgroup.com/?l=mandrake-cookerm=104567821415024w=2 d.
Re: [Cooker] NVIDIA - kernel-multimedia
On Monday 03 March 2003 19:09, Jan Ciger wrote: I tried to compile the Nvidia driver with the multimedia kernel and have got unresolved symbols on loading the NVdriver module :-( Yes, I know. It is because /etc/init.d/kheader does not know about kernels with a preempt tag. I will try to drop the tag in a next release. But I make sure that the modules dir etc. have a disctict naming (to prevent conflicting with regular kernels). In the meantime you could try editing rhconfig.h from the kernel-multimedia-source and change __module_up into __module_preempt (or __module_preemptsmp when using the smp kernel) Moreover, would it be possible to recompile the SMP version of the multimedia kernel with the high memory option enabled ? It is not uncommon to have 1GB RAM on a machine used for high end audio/video processing and now the hmm..I do not have an smp machine. high mem is known to cause problems now and then. I can try, be sure to test it well. d.
Re: [Cooker] Upload frozen
On Monday 03 March 2003 20:01, Adam Williamson wrote: Try playing a sound with xmms, with the ALSA output plugin enabled. xmms just freezes solid. Someone else confirmed this happens to them, also. For me it does not happen. Which sound card? Trying to run Quakeforge (Quake source port) in ALSA mode gives a segfault. IIRC does quake use mmapped sound? there was some problem with that and i think it was quakes fault, not alsa. But could be wrong. d.
Re: [Cooker] Status of multimedia kernel?
On Friday 28 February 2003 19:26, Buchan Milne wrote: How about just jackstart in contrib, requiring jackit and (assuming we can get the multimedia kernel in) kernel-multimedia? yes, split off a small package into contrib, with the script. Does the script need to be setuid root? Why not become root to use it? The jackd itself can still run as the current user? btw: Wrote: /home/dtholen/rpm/SRPMS/kernel-multimedia-2.4.21.0.11mdk-1-1mdk.src.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-preemptsmp-2.4.21.0.11mdk-1-1mdk.i586.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-preempt-2.4.21.0.11mdk-1-1mdk.i586.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-source-2.4.21-0.11mdk.i586.rpm Austin: can you test the smp version? d.
Re: [Cooker] Re: [CHRPM] mozilla-1.3-0.final.20030228.1mdk
On Friday 28 February 2003 20:33, rcc wrote: On Fri, 28 Feb 2003 17:47:05 +0100 (CET) oh no, not again a change of the dirname. Wouldn't it be possible to have /usr/lib/mozilla/plugins and a symlink to that in *agree* it would be a lot easier for my java rpms on mdk club as well. d.
Re: [Cooker] Status of multimedia kernel?
On Friday 28 February 2003 19:36, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I have read something about a kernel patch that makes it possible to use jackit with capabilities without running it as root. eh thac, you might have missed we already did this. The only problem was getting the stuff actually uploaded to contrib... d.
Re: [Cooker] Re: [CHRPM] mozilla-1.3-0.final.20030228.1mdk
On Saturday 01 March 2003 01:36, Todd Lyons wrote: mozilla finds the plugins that I have in /usr/lib/mozilla/plugins. I don't have to do anything in /usr/lib/mozilla-1.3b/plugins for it to find the other ones (though it does symlink to /usr/lib/netscape/plugins for a few things). yes, but does it 'find' them or 'copy' them? if it copies the java symlink it will probably put java in /usr/lib/mozilla-1.3b/plugins. Suns java depends on the dir structure, so it is a good way to crash your browser on entering a page using java. d. Blue skies... Todd
Re: [Cooker] Status of multimedia kernel?
On Thursday 27 February 2003 17:34, Buchan Milne wrote: I was wanting to answer that most of the software is already in Mandrake contribs in preparation for 9.1, but it seems we do not have the low latency/multimedia kernel in contrib yet. well, I do hardly have the time to put up with contrib sillyness: My permissions on my homedir on klama keep changing to 99, I do not get error messages when a package is not acccepted, according to chmouel I uploaded them to main, while I'm 100% sure that I uploaded them to contrib. I have to keep mailing lenny to add me to maintainers list so that I at least know when something gets refused. And still I am not on that list. Actually, IMO this sucks. It is far easier to put it in clubcontribs. Amazing everybody puts up with this. danny
Re: [Cooker] Cannot change volume in any multimedia programs (snd-emu10k1)
From Kmix I can use the following sliders to adjust the volume: Wave, Emu10k1 PCM only changes the volume on the left speaker. All other sliders (including master/base/treble) don't do anything at all. Ok, do I get it correctly that 'wave' is adjusting the volume of both speakers? In that case you can use /proc/asound/card0/oss_mixer to bind OSS PCM to Wave something like this: echo 'PCM Wave 0' /proc/asound/card0/oss_mixer should enable volume control in OSS emulation. For bass/treble you did unmute tone-control? I'm not sure bass/treble works on digital speakers though, because alsa still uses AC97 and not the digital mixer AFAIK (hope this changes soon and all will be solved). d. So i wanted to try the oss driver and tried emu10k1 and afterwards audigy and couldn't get any sound with them at all. So now I am back with Alsa but can't adjust the volume from within the applications. I think for that indeed you need to use emu10k1-tools. d.
Re: [Cooker] Status of multimedia kernel?
On Friday 28 February 2003 16:50, Buchan Milne wrote: Austin Acton wrote: Chmouel/Juan, are you guys able to give an answer on this? I am sure if you Danny can be told This will be the final kernel for 9.1 a few days in advance, he should be able to get a the multimedia kernel working. I am also sure that if he has problems uploading it, or has to repatch/rebuild often he will not be keen . I do not necessarily need to know in advance. At the release moment I can build a preempt version, only someone has to move it to 9.1 contrib at that moment. Since also in main only bugfixes are allowed this kernel could also be considered a bugfix (since it is exactly the same as in main, only with the lowlat/preempt patches) As for jackd with capabilities, I had to make it a compile-time option. Why? Does it need the mutli-media kernel, or is there some other issue? yes why? Also, I've almost finished ardour, only to learn that 'the author' doesn't want binary copies distributed, because he's afraid users will pester him and/or us about bugs/limitations which he already know about. If it is GPL, the author cannot ask this from you. He should either make it non-GPL or allow it. Danny, where can I get your latest SRPM? Can I give it a try uploading to contrib on klama? on klama, actually, I am going to update it to latest cooker kernel _now_ (so give me a few hours). d.
Re: [Cooker] Status of multimedia kernel?
On Friday 28 February 2003 19:26, Buchan Milne wrote: How about just jackstart in contrib, requiring jackit and (assuming we can get the multimedia kernel in) kernel-multimedia? yes, split off a small package into contrib, with the script. Does the script need to be setuid root? Why not become root to use it? The jackd itself can still run as the current user? btw: Wrote: /home/dtholen/rpm/SRPMS/kernel-multimedia-2.4.21.0.11mdk-1-1mdk.src.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-preemptsmp-2.4.21.0.11mdk-1-1mdk.i586.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-preempt-2.4.21.0.11mdk-1-1mdk.i586.rpm Wrote: /home/dtholen/rpm/RPMS/i586/kernel-multimedia-source-2.4.21-0.11mdk.i586.rpm Austin: can you test the smp version? d.
Re: [Cooker] Cannot change volume in any multimedia programs (snd-emu10k1)
known problem (sort of). We really need some configuring for the alsa mixer, but I do not have the time to do it before 9.1. Also, I do not own digital speakers, so I'm not sure which mixer setting you should use. Can you try 'wave surround' in kmix to see if it helps? d.
[Cooker] drakxtools dependencies/font-tools
drakfont depends on ttf2pt1, which should be in font-tools. It is not, only the man page is. Thierry, my rpmmon says font-tools has no maintainer, which is why I bug you with it:) Danny
Fwd: [Cooker] [Bug 1280] [XFree86-libs] /tmp/.ICE-unix/ not owned by root
This has been brought up so many times now, that I wonder why it does not get fixed? It really is trivial to do so? Danny -- Forwarded Message -- Subject: [Cooker] [Bug 1280] [XFree86-libs] /tmp/.ICE-unix/ not owned by root Date: Sunday 23 February 2003 19:02 From: ndeb [EMAIL PROTECTED] To: [EMAIL PROTECTED] https://qa.mandrakesoft.com/show_bug.cgi?id=1280 --- Additional Comments From [EMAIL PROTECTED] 2003-02-23 18:29 --- The same bug is there for mandrake-9.1rc1. If the libICE bug that creates /tmp/.ICE-unix with the wrong ownership/group cannot be removed, I suggest a workaround in /etc/rc.sysinit, where the lines: # Delete ICE locks rm -rf /tmp/.ICE-unix should be replaced with: # Delete ICE locks chown root:root /tmp/.ICE-unix rm -rf /tmp/.ICE-unix/* --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. --- Reminder: --- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Changing the ownership to root:root does not help as after a reboot, the script /etc/rc.sysinit deletes this directory by this command rm -rf /tmp/.ICE-unix. So when /tmp/.ICE-unix/ is recreated it has ownership of the non-root user. According to http://mail.gnome.org/archives/gnome-hackers/2001-September/msg00176.html , this adds 5 secs to the startup of the desktop (KDE, GNOME) and is also a security risk. Also, the page https://listman.redhat.com/pipermail/enigma-list/2002-June/014027.html claims this to be a bug of libICE (which is part of XFree86-libs). Please fix this so that /tmp/.ICE-unix has default ownership of root:root. ---
Re: [Cooker] Two questions on font rendering
Hope this makes you feel slightly better: On Thursday 20 February 2003 09:30, Frederic Crozat wrote: And I'm almost sure this problem is not the same as the previous one, since Xrender doesn't care AT ALL of encoding.. have to admit I didn't check on the previous bug. But i think freetype2 does care about encoding? It is just no Xrender bug. Then fix OpenOffice.. :) hmm..yes..I do not even *try* to understand that stuff. A vote will NEVER convince me to add something which can break rendering, so don't lose your time on that.. People can vote whatever they want, if it means adding instability to part I maintain, I won't follow their votes.. Just because something is pretty don't mean it should be in.. Well..that is sensible. But it also depends a lot on what exactly is changed in a new freetype2. If it is bugfixes, it is perhaps safe to do. Is it so hard to understand we can't just add any patches (or new features) which have not YET been released as stable, just because it MIGHT enhanced rendering for some people and BREAK rendering for other ?? Hmm...AFAIK these patches have been around for a while, and it was discussed here as well, a long time ago. Everybody agreed that it looked good and seemed stable IIRC. However, I cannot remember if you gave a reason for not incorporating it back then. I'm tired to have to justify myself EACH time !! Don't, and sorry if it came on a bad moment. However, sometimes I see that you have to make a lot of noise to attract some attention. That is certainly not true for all maintainers of main, but for some. If you do not shout hard enough you are certain to be ignored. This is a drawback of the current system. So, my guess is: more justifiying to come for you:( It comes with the job it seems, but I do not blame you for not liking it. Actually, you are being relatively spared here on cooker-ml. Ask some clubvolunteers on how they have to defend descisions (that we do not even make!!) to a lot of complaining clubmembers, who are sometimes much more unpolite that we are:) Danny
[Cooker] rpmdrake 100%cpu: an observation
I noticed something about this bug that I think did not get noticed yet (I do not know if you already know what goes wrong gc, so perhaps this is not of use): rpmdrakes _only_ hangs when the dependencies it tries to resolve are not actually visible in the window. My dirty guess is that when tries to put these small 'v' symbols to mark that these packages will also get installed, that something is screwed up when it cannot put the v on the visible screen, and it ends up in a endless loop. The work around is: buy a huge monitor and maximize your window. This way, all rpms will be in view and things will go ok. Danny
[Cooker] kxine
Kxine crashes with a dcop communication error on startup. It also needs libfam-devel and libart_lgpl2-devel as a buildreq. The 0.5rc1 version (http://kxine.sourceforge.net/kxine-0.5-rc1.tar.gz) crahes with a segfault:( haven't tried cvs yet. Danny
[Cooker] Re: preempt rejected?
On Wednesday 19 February 2003 14:23, you wrote: Danny Tholen [EMAIL PROTECTED] writes: What is *this*? putting this kernel in contrib or update the version number? kernel-preempt may works in contrib, but not for the main preemption in kernel is not a feature we can get for now Hmm, but it is not in the main kernel. I patched all the config stuff, so that if you would build the src.rpm with build_up enabled you build a clean main kernel without preempt, Like smp and secure, etc. But I understand this might give confusion, so I will change the name of the src.rpm, source and kernel-doc rpms so that there is no confusion. ok? d.
[Cooker] preempt rejected?
On Wednesday 19 February 2003 12:10, you wrote: The following message is a courtesy copy of an article that has been posted to liste.maintainers as well. thanks for forwarding it ;) [EMAIL PROTECTED] writes: These packages are already in main uh,no they are not. The version in main wass 2.4.21-0.pre4.6mdk. But I can change the name completely if that makes everybody happy? I take it that this rejected message not only applies to kernel-doc but also to kernel-preempt and source? * Mon Feb 17 2003 Danny Tholen [EMAIL PROTECTED] 2.4.21-0.pre4.6.1mdk you cannot do stuff like this sorry What is *this*? putting this kernel in contrib or update the version number? Danny
Re: [Cooker] alsa bug
On Wednesday 19 February 2003 14:26, Thierry Vignaud wrote: Aurélien Bompard [EMAIL PROTECTED] writes: Same thing here. It occurs also when switching worspaces. x11 probably eats too much pci bandwith, thus competiting with the app that fill the sound buffer you may want the pcinotry option of xf86config perhaps, It sounds a bit like PCI problems. but why did it only start with latest alsa? I seems more likely that alsa suddenly wants a lot more PCI bandwidth. d.
Re: [Cooker] alsa bug
On Wednesday 19 February 2003 15:40, John Allen wrote: On Tuesday 18 February 2003 22:47, Danny Tholen wrote: Latest alsa driver contains a bug, at least for emu10k1: heavy scrolling causes sounds artifacts (possibly quick windows resising to). I get the same problem using XMMS and the KDE aRts driver, but not using the OSS driver. With the OSS driver the audio never skips/freezes. It is not freezing/skipping. It sounds a bit like static. Small 'hiccups' in the audio stream. For me, it doesn't matter which xmms plugin I use. d.
Re: [Cooker] RC1 issues thoughts
On Wednesday 19 February 2003 15:48, Buchan Milne wrote: Warly wrote: I do not really favor the fact of using proprietary things to lead user to mandrakeclub. Mandrakeclub is mainly to help Mandrakesoft develop free software, and if we need to use proprietary arguments to have enough money to live, maybe the fight is already lost. I am sure spare cash at Mandrakesoft would not do any harm to the development of free software? Instead of letting hardware makers use proprietary drivers to make linux more difficult to use, you can use their proprietary drivers to help fund free software! True enough. All the GPL is about is creating freedom in a non-free world. Otherwise we would all be running *BSD :-P Wary, I think you confuse the aim/purpose of the club with the way to get there. The purpose is to help development, the way to get there is by getting members by providing content. Danny
Re: [Cooker] alsa bug
On Wednesday 19 February 2003 14:26, Thierry Vignaud wrote: Aurélien Bompard [EMAIL PROTECTED] writes: Same thing here. It occurs also when switching worspaces. x11 probably eats too much pci bandwith, thus competiting with the app that fill the sound buffer you may want the pcinotry option of xf86config I ripped the emu10k1 driver from alsa cvs (only the em10k1 dir) and fixed it to make it compile with current alsa: it fixes the bug! Do you think we get an alsa driver update before release or should I try and isolate the code that fixes it? Danny
[Cooker] kopete jabber plugin?
Any reason why the only really free protocol is not in mandrakes kopete? Danny
[Cooker] PATCH: alsa-emu10k1 pcmstream size
I found the bug that causes the emu10k1 to sound bad when X is busy with other things. The fix is a one liner (below). Danny diff -Paru linux-2.4.20/sound/pci/emu10k1/emupcm.c emu10k1/emupcm.c --- linux-2.4.20/sound/pci/emu10k1/emupcm.c 2003-02-17 15:46:22.0 +0100 +++ emu10k1/emupcm.c2003-02-10 12:53:50.0 +0100 @@ -989,7 +989,7 @@ emu-pcm = pcm; for (substream = pcm-streams[SNDRV_PCM_STREAM_PLAYBACK].substream; substream; substream = substream-next) - if ((err = snd_pcm_lib_preallocate_sg_pages(emu-pci, substream, 64*128, 128*1024)) 0) + if ((err = snd_pcm_lib_preallocate_sg_pages(emu-pci, substream, +64*1024, 64*1024)) 0) return err; for (substream = pcm-streams[SNDRV_PCM_STREAM_CAPTURE].substream; substream; substream = substream-next)
Re: [Cooker] Two questions on font rendering
On Wednesday 19 February 2003 19:55, Michal Bukovjan wrote: Frederic Crozat wrote: On Wed, 19 Feb 2003 19:22:34 +0100, Michal Bukovjan wrote: You don't use cooker, do you ? I *DO* use cooker. And it is not fixed - try to go to that (any) site in the bug report - http://underground.cz ; the coding is fixed (Mozilla will use iso-8859-2 correctly), but if you manually switch to UTF-8, still the same - mostly empty lines. seems Fred is not using cooker ;) I won't integrate hacks from Freetype CVS in our Freetype (except if some fonts don't load with our Freetype).. I don't think Freetype 2.1.4 will be in Mdk 9.1, except if it is released this week.. Now that would be pity - I used the hack for some time, it is very stable and current Cooker rendering just looks mediocre when compared :-(. It is a pity, generally KDE/GNOME looks OK, but OO.org looks like shit. But it's your decision - I hope someone will release an updated rpm then, so that font rendering is pleasant again. If they are staying stubborn, I will post a bug fix for freetype2 on all mirrors via mandrakeclub, if nobody beats me to it. Or we can have a vote. Would you be conviced by a vote Frederic? Danny
Re: [Cooker] preempt/lowlat kernel
On Monday 17 February 2003 19:30, Buchan Milne wrote: +1 just uploaded d.
[Cooker] alsa bug
Latest alsa driver contains a bug, at least for emu10k1: heavy scrolling causes sounds artifacts (possibly quick windows resising to). It is not a heavy load issue, it only occurs for some screen activities (scrolling, perhaps resizing). It occurs with both nvidia and nv drivers. It does not occur with alsa from 2.4.21pre4-1mdk kernel (rc6 IIRC). nvidia and emu10k1 use different IRQs. Can anyone confirm? Danny
Re: [Cooker] alsa bug
All of you using a sblive? Or also other cards? If so, I will try newer and older cvs versions of ALSAs emu10k1 to see if it gets fixed. d. On Wednesday 19 February 2003 07:02, Aurélien Bompard wrote: Latest alsa driver contains a bug, at least for emu10k1: heavy scrolling causes sounds artifacts (possibly quick windows resising to). It is not a heavy load issue, it only occurs for some screen activities (scrolling, perhaps resizing). It occurs with both nvidia and nv drivers. It does not occur with alsa from 2.4.21pre4-1mdk kernel (rc6 IIRC). nvidia and emu10k1 use different IRQs. Can anyone confirm? Same thing here. It occurs also when switching worspaces. Gauret
Re: [Cooker] Re: Creation of a community
On Monday 17 February 2003 10:30, Warly wrote: Currently the machine running bugzilla is quite underpowered (PIII 700 with 256 MB of ram). As soon as I find some time and a more powerfull computer, I switch it and decrease the processing to something like 5 minutes). While you are at it. Can you find a more powerfull machine for me to? :-P Danny
[Cooker] dosemu in contrib: license problem?
I had a look at dosemu recently. And although I never really used this software I think I can put it back in contrib. Question is: Debian put freedos in non-free because the dos programs are compiled with a very old borland compiler, and supposedly therefore link against a (closed source) C library from borland. However, from the GPL: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. So the question is, if this c library is a major component of the OS Freedos, it's source does not need to be included if I am correct? Danny
[Cooker] nvtv
I accidently build nvtv, but than I saw it was already in contribs. I think
it could be improved a bit:
- libgtk+1.2-devel should be added to build requires
- Currently the binaries are setuid root, I think this is a bad idea (its easy
to crash your machine with it). Perhaps using conselehelper would be better:
# add:
Requires: usermode usermode-consoleonly
# in the install section remove:
cp ${RPM_BUILD_DIR}/%{name}-%{version}/src/nvtv
${RPM_BUILD_ROOT}/%{_bindir}/nvtv
chmod +s ${RPM_BUILD_ROOT}/%{_bindir}/nvtv
cp ${RPM_BUILD_DIR}/%{name}-%{version}/src/nvtvd
${RPM_BUILD_ROOT}/%{_bindir}/nvtvd
#and add:
install -D -m755 src/nvtv $RPM_BUILD_ROOT/%_sbindir/nvtv
install -D -m755 src/nvtvd $RPM_BUILD_ROOT/%_sbindir/nvtvd
#Lets make a nice dialog box asking for root perms:
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/{pam.d,security/console.apps}
cat EOF $RPM_BUILD_ROOT%{_sysconfdir}/pam.d/%{name}
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth required/lib/security/pam_stack.so service=system-auth
sessionoptional /lib/security/pam_xauth.so
accountrequired /lib/security/pam_permit.so
EOF
)
cat EOF $RPM_BUILD_ROOT%{_sysconfdir}/security/console.apps/%{name}
USER=root
PROGRAM=/usr/sbin/nvtv
SESSION=true
FALLBACK=true
EOF
mkdir -p $RPM_BUILD_ROOT%{_bindir}
ln -s %{_bindir}/consolehelper $RPM_BUILD_ROOT%{_bindir}/%name
#the files become:
%files
%defattr (-,root,root)
%doc doc/* README TODO INSTALL BUGS ChangeLog FAQ ANNOUNCE LICENSE
README.binary
%_sbindir/%{name}
%_bindir/%{name}
%_sbindir/%{name}d
%config(noreplace) %{_sysconfdir}/security/console.apps/*
%config(noreplace) %{_sysconfdir}/pam.d/*
%{_prefix}/share/pixmaps/%{name}.png
%{_datadir}/applnk/Multimedia/%{name}.desktop
%{_menudir}/*
hmm...a diff would have been nicer
Danny
Re: [Cooker] nvtv
On Monday 17 February 2003 17:42, Thierry Vignaud wrote: Danny Tholen [EMAIL PROTECTED] writes: - Currently the binaries are setuid root, I think this is a bad idea (its easy to crash your machine with it). Perhaps using conselehelper would be better: i would not. it *is* You lost me Thierry: it is *what* Danny
[Cooker] preempt/lowlat kernel
I have a preemptive lowlatency kernel (2.4.21pre4-6.1mdkpreempt) sitting on klama (including capabilities patch for getting lowlatency with jack). It works stable here, with very low latencies. I hope nobody objects to putting a kernel into contrib? Chmouel, you are welcome to take a look at it if your time permits. Danny
Re: [Cooker] Restart problem
On Sunday 16 February 2003 18:08, Buchan Milne wrote: On Sun, 16 Feb 2003, Jon wrote: I'm running a frequently updated cooker and for the past week or so attempting to restart the machine logs me out and sends me to a konsole requiring me to re-log in and then typing 'reboot' in order to reboot the machine. You need to give a *lot* more detail on this. I assume this is in X. Which window manager/desktop? KDE? Gnome? Which login manager? kdm, mdkkdm (the one with the Mandrake images on the buttons) or gdm (gnome/gtk one)? I see it too: KDE (will try gnome later), KDM. It both occurs when rebooting /poweroff from KDE itself or from KDM. Do you use autologin or not? I do not. 'reboot' or 'rebootin' works normally. I guess it's a kdm problem Danny
Re: [Cooker] Restart problem
On Sunday 16 February 2003 21:14, Jon wrote: running KDE. The problem happened with both mdkkdm and kdm and the problem was as rcc stated in the paths to the RebootCmd. When I replaced: RebootCmd=/usr/sbin/rebootin with: RebootCmd=/sbin/reboot things acted as they should and the computer restarted. Ok, but what happens when you first log offf, and than try reboot in KDM itself, there is should give you a series of options what to reboot. This probably does not work anymore now? I guess the rebootin script needs to be modified to do a normal reboot if no arguments are given. Danny
Re: [Cooker] 2 Problems: Mozilla (crash) OpenOffice (badly displayed fonts)
On Friday 14 February 2003 01:17, Pedro Soria-Rodriguez wrote: Hello, I am using a MDK 9.0 system that I have been updating with cooker RPMs since I installed 9.0. No, you do not update your 9.0 system with cooker. Instead, it is called 'screwing your system'. cooker rpms were never made for the purpose of updating 9.0. It is unsupported and questions about it do not belong on this list. If you want updated 9.0 rpms, ask on mandrakeclub. sorry, Danny
Re: [Club-Volunteers] Re: [Cooker] urpmi.setup in main ?
I agree with you. Opening a bug is a good idea. I do not give it much change to be fixed however :( Danny On Thursday 13 February 2003 16:51, Narfi Stefansson wrote: On Thursday 13 February 2003 05:33, Denis HAVLIK wrote: On Wed, 12 Feb 2003, Buchan Milne wrote: + Furthermore, I think it might be modified to be able to easily get a + mirror list from MandrakeClub, specifically so that Club Members could + easily setup a urpmi source for MandrakeClub, for things like getting + the NVidia drivers. FYI, MandrakeFirsttime will let folks declare that they are Club members and even subscribe directly (trial accounts with boxes) and automatically configure Club downloads in 9.1. cu Denis Then there have to be some changes made to MandrakeFirsttime. The way MandrakeFirsttime is right now, it triggers my panic nerves: I see a explanation which is too long to fit on one screenful: we will not use this data to ... we do use this data for ... [too long for me to read] followed by a request for personal information. I automatically click cancel. [More about the text below] There are alternative designs: Don't show the screen with the long explanations, jump straight to the user setup screen and have a checkbox: Share this data with MandrakeSoft and a button next to it which brings up the explanations of what is involved if one chooses to do the sharing. Has anyone here ever read the text? Here's a copy of the first 4 lines as they are in 9.0, I believe it is the same in cooker: What personal data do we collect ? Various information is collected in different areas of the website; what follows is an overview of the data we keep: Firstly, we record your email address, name and postal address. 1) website??? This seems completely inappropriate for mandrakefirsttime. 2) we record your ... and no opt-out? This makes me hit cancel right away. I suspect the text was simply copied without modifications from mandrakeexpert or some other website! If anybody replies in support of this usability issue, I'll open a 2 bugreports on Mandrakefirsttime in bugzilla, one for the text and one for the lack of a share/do not share this info with mandrake checkbox. Narfi.
Re: [Cooker] No Audio with SBlive and digital Speakers
Perhaps it works with this info: Module snd-emu10k1 -- Module for EMU10K1/EMU10k2 based PCI soundcards. * Sound Blaster Live! * Sound Blaster PCI 512 * Emu APS (partially supported) * Sound Blaster Audigy extin - bitmap of available external inputs for FX8010 (see bellow) extout - bitmap of available external outputs for FX8010 (see bellow) seq_ports - allocated sequencer ports (4 by default) max_synth_voices - limit of voices used for wavetable (64 by default) max_buffer_size - specifies the maximum size of wavetable/pcm buffers given in MB unit. Default value is 128. enable_ir - enable IR Module supports up to 8 cards and autoprobe. Input Output configurations [extin/extout] * Creative Card wo/Digital out [0x0003/0x1f03] * Creative Card w/Digital out [0x0003/0x1f0f] * Creative Card w/Digital CD in [0x000f/0x1f0f] * Creative Card wo/Digital out + LiveDrive [0x3fc3/0x1fc3] * Creative Card w/Digital out + LiveDrive [0x3fc3/0x1fcf] * Creative Card w/Digital CD in + LiveDrive [0x3fcf/0x1fcf] * Creative Card wo/Digital out + Digital I/O 2 [0x0fc3/0x1f0f] * Creative Card w/Digital out + Digital I/O 2 [0x0fc3/0x1f0f] * Creative Card w/Digital CD in + Digital I/O 2 [0x0fcf/0x1f0f] * Creative Card 5.1/w Digital out + LiveDrive [0x3fc3/0x1fff] * Creative Card all ins and outs[0x3fff/0x1fff] So basically you seem to have to tell it when it has a digital out... I think you can even fill in the extin/out numbers in soundrake/draksound (I never can remember the names). But be sure to check if your modules.conf was modified correctly. After doing this you might have to play with the mixer *again* d. On Thursday 13 February 2003 22:56, Nathan A. Smith wrote: On Wed, 2003-02-12 at 04:34, Thierry Vignaud wrote: Murray J. Root [EMAIL PROTECTED] writes: Use alsamixer (or alsamixergui) to enable digital and set the levels. or gnome-alsamixer. kde mixer might be aware of alsa now but i'm not sure Thanks for the hint -- kmix is a lot simpler to use, But even so I still have no love. I have turned off the (muted) the sblive analog /digital output jack and unumted the tone control. Everything else is unmuted. But still no sound. I have read the alsa website documentation -- no help (I have posted my modules.conf file below, if that may be helpful). I have done a 'lsmod' and everything seems to be loaded. I would love any other ideas -- thanks Nasa # Sound # ALSA portion options snd snd_major=116 snd_cards_limit=1 options snd-emu10k1 snd_index=0 snd_id=emu10K1 post-install snd-card-ymfpci alsactl restore pre-remove snd-card-ymfpci alsactl store alias char-major-116 snd alias sound-slot-0 snd-emu10k1 alias snd-card-0 snd-emu10k1 # OSS/Free portion alias char-major-14 soundcore alias sound-slot-0 snd-card-0 #card 1 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss options snd-pcm-oss snd_dsp_map=0 snd_adsp_map=3 alias sound-slot-1 off alias sound-services-1-0 off #End Sound
Re: [Cooker] urpmi.setup in main ?
On Wednesday 12 February 2003 18:34, Chmouel Boudjnah wrote: Olivier Thauvin [EMAIL PROTECTED] writes: What about puting this package on main instead contrib. It seems lot of poeple want or need it: why is not done in rpmdrake ? Do you mean 'why is it not done in rpmdrake'? I think it would be a valuable addition to rpmdrake. Or at least to the software entry in drakconf. You keep getting people not even understanding that they can add mirrors as a source for rpmdrake (typing the exact url is apparently to hard). Alternatively, it would be good to be able to click on a webpage, resulting in rpmdrake being started, asking you if you want to add this resource for downloading software from (sort of urpmi://). It sounds a bit insecure, but I'm sure many users are already copying the urpmi.addmedia lines from the club or naradon without thinking or knowing what those commands do, so automating the whole process with proper warnings would be better. d.
[Cooker] PATCH: check tmp permissions for xfs + Xsetup_0 should be updated
Since this message seems to have been ignored I just sent it again. Also, since the KDE team doesn't care to comment on whether (ugly) new kdm is there to stay: /etc/X11/xdm/Xsetup_0 checks for kdmdesktop, which does not exist anymore... the message about xfs: There have been some reports of X not starting because xfs silently fails when it cannot write to its socket (unsticky dir, not writable, no tmp dir, caused by user/program errors, or fs corruption). It might be a good idea to set correct ownership/permissions before starting xfs. This patch is doing that. I'm not sure if xfs is the correct place to do this, perhaps somewhere else in init.d would be better, but I leave you to decide that. Danny --- xfs 2002-09-13 08:49:01.0 +0200 +++ xfs 2003-01-17 00:11:39.0 +0100 @@ -18,6 +18,12 @@ case $1 in start) gprintf Starting X Font Server: + #Be sure we can use tmp: + if [ \!'find / -perm 1777 -name tmp -user root -group root -type d -maxdepth 1' ] ; then + mkdir -p tmp + chmod 1777 /tmp + chown root.root /tmp + fi rm -fr /tmp/.font-unix daemon --check xfs xfs -port -1 -daemon -droppriv -user xfs touch /var/lock/subsys/xfs
Re: [Cooker] Contributing a non-contrib package
bug [EMAIL PROTECTED] with it :) I think he has his reasons for not configuring it like this though. Danny On Saturday 01 February 2003 12:35, Daniele Pighin wrote: I've just rebuilt a kde package fort qt (qt3-3.1.1-9mdk.src.rpm and binaries) adding full xcursor support to qt. This is not a contrib package, as it is intended to be an upgrade over the actually-shipped-in-cooker qt3-3.1.1-8 package. I'd like to know what should I do to have the package into cooker, thanks Daniele
Re: [Cooker] Re: [cooker] PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on media change wth busy files
On Wednesday 29 January 2003 11:01, Borzenkov Andrey wrote: 0.pre3.1mdk has the same supermount. Version that was intended for 9.0 update has the same bug as 9.0. ha...seems that I make better updates than Juan :-P Not that I understand much of supermount anyways. Thanks for investing your time btw Andrey. I remember you claiming you could not participate on cooker. As small not about the konq problem: I played with it a bit on 9.0 and there at least it seems to use fam. Wouldn't it be possible to modify fam _not_ to monitor devices mounted by supermount? (like it is not possible for nfs ?) Danny
Re: [Cooker] HOWTO help adding new hardware to ldetect-lst ??
another monitor for the list: Iiyama; Iiyama HM704UTC, Diamondtron; 0; 30.0-96.0; 50-160; 1 d.
